Merge branch 'ics'
percpu: zero memory more efficiently in mm/percpu.c::pcpu_mem_alloc()

Don't do vmalloc() + memset() when vzalloc() will do.

tj: dropped unnecessary temp variable ptr.

Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Tejun Heo <tj@kernel.org>

============
Tuned drivers/cpufreq/cpufreq_ondemand.c

============
leveled voltage for CPU as for all normal 1Ghz cpu phones

============
Added new lowmemkiller advanced with swap support from Shooter-2.6.35-MR

===========
Tuned the shrinker function as in 2.6.35 kernel.
mm: remove unused get_vm_area_node

get_vm_area_node() is unused in the kernel and can thus be removed.

Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mm: convert sprintf_symbol to %pS

Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Pekka Enberg <penberg@kernel.org>
Cc: Jiri Kosina <trivial@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mmc: core: Increase write data timeout value for bad SDHC cards

SD2.0 specification says the max. timeout for writes is 250msecs
for SDHC cards. But when the card is almost full and there are too few
free sectors, the garbage collectors inside SD card  may take more time
and hence delaying the write more than 250msecs. This typically happens
with cards that don't adhere to specification. Based on this the timeout
is increased to 300msecs but still for some cards this is not sufficient.

Few SanDisk class4 SD cards violate the spec. and may take more time than
expected when the card is full. So increase the data timeout to 800msecs,
otherwise we might see file system corruption due to loss of important FS
metadata in timeouts.

Change-Id: Ie8f0616dbbb2a15d7dbe95cd49eeb2308a5badd1
Signed-off-by: Sujith Reddy Thumma <sthumma@codeaurora.org>
pmem: fix buddy free memory corruption bug

Enforce explicit upper limit for buddy index during memory free
operations. This index is generated during memory free operations of
the buddy bestfit allocator. The index points to each free buddy that
should be coalesced into a greater free memory area. The upper limit
now enforced is the number of entries in the current PMEM region.

Without this fix, pmem_buddy_bestfit_free would continue to corrupt
bytes in ever higher addresses, by power of 2, of memory until
stopped by the high bit being set in the currently examined byte.
Unless the high bit was set immediately at the first invalid byte,
this could have caused memory corruption past the current pmem region
metadata in kernel memory space.

One manifestation of this problem was a corner case where
non-existent buddies were incorrectly coalesced.

In a 12MB region, the buddy free for 8MB tried to coalesce the freed
buddy metadata with a non-existent 8MB buddy which actually belonged
to the following region. This caused the order number in the metadata
belonging to the following region to be incorrectly incremented past
the region boundary. Soon after, there was a subsequent invalid
allocation in that following region past the region boundary.

Signed-off-by: Stephen Biggs <sbiggs@quicinc.com>
mm: add vzalloc() and vzalloc_node() helpers

Add vzalloc() and vzalloc_node() to encapsulate the
vmalloc-then-memset-zero operation.

Use __GFP_ZERO to zero fill the allocated memory.

Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Cc: Christoph Lameter <cl@linux-foundation.org>
Acked-by: Greg Ungerer <gerg@snapgear.com>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[mm] various memory bugfixes and tweaks

ARM: 6941/1: cache: ensure MVA is cacheline aligned in flush_kern_dcache_area

    commit a248b13b21ae00b97638b4f435c8df3075808b5d upstream.

    The v6 and v7 implementations of flush_kern_dcache_area do not align
    the passed MVA to the size of a cacheline in the data cache. If a
    misaligned address is used, only a subset of the requested area will
    be flushed. This has been observed to cause failures in SMP boot where
    the secondary_data initialised by the primary CPU is not cacheline
    aligned, causing the secondary CPUs to read incorrect values for their
    pgd and stack pointers.

    This patch ensures that the base address is cacheline aligned before
    flushing the d-cache.

    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

mm/page_alloc.c: prevent unending loop in __alloc_pages_slowpath()

    commit cfa54a0fcfc1017c6f122b6f21aaba36daa07f71 upstream.

    I believe I found a problem in __alloc_pages_slowpath, which allows a
    process to get stuck endlessly looping, even when lots of memory is
    available.

    Running an I/O and memory intensive stress-test I see a 0-order page
    allocation with __GFP_IO and __GFP_WAIT, running on a system with very
    little free memory.  Right about the same time that the stress-test gets
    killed by the OOM-killer, the utility trying to allocate memory gets stuck
    in __alloc_pages_slowpath even though most of the systems memory was freed
    by the oom-kill of the stress-test.

    The utility ends up looping from the rebalance label down through the
    wait_iff_congested continiously.  Because order=0,
    __alloc_pages_direct_compact skips the call to get_page_from_freelist.
    Because all of the reclaimable memory on the system has already been
    reclaimed, __alloc_pages_direct_reclaim skips the call to
    get_page_from_freelist.  Since there is no __GFP_FS flag, the block with
    __alloc_pages_may_oom is skipped.  The loop hits the wait_iff_congested,
    then jumps back to rebalance without ever trying to
    get_page_from_freelist.  This loop repeats infinitely.

    The test case is pretty pathological.  Running a mix of I/O stress-tests
    that do a lot of fork() and consume all of the system memory, I can pretty
    reliably hit this on 600 nodes, in about 12 hours.  32GB/node.

    Signed-off-by: Andrew Barry <abarry@cray.com>
    Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
    Reviewed-by: Rik van Riel<riel@redhat.com>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

vmalloc: remove redundant unlikely()

    IS_ERR() already implies unlikely(), so it can be omitted here.

    Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
    Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: remove likely() from mapping_unevictable()

    The mapping_unevictable() has a likely() around the mapping parameter.
    This mapping parameter comes from page_mapping() which has an unlikely()
    that the page will be set as PAGE_MAPPING_ANON, and if so, it will return
    NULL.  One would think that this unlikely() means that the mapping
    returned by page_mapping() would not be NULL, but where page_mapping() is
    used just above mapping_unevictable(), that unlikely() is incorrect most
    of the time.  This means that the "likely(mapping)" in
    mapping_unevictable() is incorrect most of the time.

    Running the annotated branch profiler on my main box which runs firefox,
    evolution, xchat and is part of my distcc farm, I had this:

     correct incorrect  %        Function                  File              Line
     ------- ---------  -        --------                  ----              ----
    12872836 1269443893  98 mapping_unevictable            pagemap.h            51
    35935762 1270265395  97 page_mapping                   mm.h                 659
    1306198001   143659   0 page_mapping                   mm.h                 657
    203131478   121586   0 page_mapping                   mm.h                 657
     5415491     1116   0 page_mapping                   mm.h                 657
    74899487     1116   0 page_mapping                   mm.h                 657
    203132845      224   0 page_mapping                   mm.h                 659
     5415464       27   0 page_mapping                   mm.h                 659
       13552        0   0 page_mapping                   mm.h                 657
       13552        0   0 page_mapping                   mm.h                 659
      242630        0   0 page_mapping                   mm.h                 657
      242630        0   0 page_mapping                   mm.h                 659
    74899487        0   0 page_mapping                   mm.h                 659

    The page_mapping() is a static inline, which is why it shows up multiple
    times.  The mapping_unevictable() is also a static inline but seems to be
    used only once in my setup.

    The unlikely in page_mapping() was correct a total of 1909540379 times and
    incorrect 1270533123 times, with a 39% being incorrect.  Perhaps this is
    enough to remove the unlikely from page_mapping() as well.

    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Acked-by: Nick Piggin <npiggin@kernel.dk>
    Acked-by: Rik van Riel <riel@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: remove unlikely() from page_mapping()

    page_mapping() has a unlikely that the mapping has PAGE_MAPPING_ANON set.
    But running the annotated branch profiler on a normal desktop system doing
    vairous tasks (xchat, evolution, firefox, distcc), it is not really that
    unlikely that the mapping here will have the PAGE_MAPPING_ANON flag set:

     correct incorrect  %        Function                  File              Line
     ------- ---------  -        --------                  ----              ----
    35935762 1270265395  97 page_mapping                   mm.h                 659
    1306198001   143659   0 page_mapping                   mm.h                 657
    203131478   121586   0 page_mapping                   mm.h                 657
     5415491     1116   0 page_mapping                   mm.h                 657
    74899487     1116   0 page_mapping                   mm.h                 657
    203132845      224   0 page_mapping                   mm.h                 659
     5415464       27   0 page_mapping                   mm.h                 659
       13552        0   0 page_mapping                   mm.h                 657
       13552        0   0 page_mapping                   mm.h                 659
      242630        0   0 page_mapping                   mm.h                 657
      242630        0   0 page_mapping                   mm.h                 659
    74899487        0   0 page_mapping                   mm.h                 659

    The page_mapping() is a static inline, which is why it shows up multiple
    times.

    The unlikely in page_mapping() was correct a total of 1909540379 times and
    incorrect 1270533123 times, with a 39% being incorrect.  With this much of
    an error, it's best to simply remove the unlikely and have the compiler
    and branch prediction figure this out.

    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Nick Piggin <npiggin@kernel.dk>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: remove likely() from grab_cache_page_write_begin()

    Running the annotated branch profiler on a box doing average work
    (firefox, evolution, xchat, distcc farm), the likely() used in
    grab_cache_page_write_begin() was incorrect most of the time:

     correct incorrect  %        Function                  File              Line
     ------- ---------  -        --------                  ----              ----
     1924262 71332401  97 grab_cache_page_write_begin    filemap.c           2206

    Adding a trace_printk() and running the function tracer limited to
    just this function I can see:

            gconfd-2-2696  [000]  4467.268935: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=7
            gconfd-2-2696  [000]  4467.268946: grab_cache_page_write_begin <-ext3_write_begin
            gconfd-2-2696  [000]  4467.268947: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=8
            gconfd-2-2696  [000]  4467.268959: grab_cache_page_write_begin <-ext3_write_begin
            gconfd-2-2696  [000]  4467.268960: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=9
            gconfd-2-2696  [000]  4467.268972: grab_cache_page_write_begin <-ext3_write_begin
            gconfd-2-2696  [000]  4467.268973: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=10
            gconfd-2-2696  [000]  4467.268991: grab_cache_page_write_begin <-ext3_write_begin
            gconfd-2-2696  [000]  4467.268992: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=11
            gconfd-2-2696  [000]  4467.269005: grab_cache_page_write_begin <-ext3_write_begin

    Which shows that a lot of calls from ext3_write_begin will result in the
    page returned by "find_lock_page" will be NULL.

    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Acked-by: Nick Piggin <npiggin@kernel.dk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

writeback: avoid unnecessary determine_dirtyable_memory call

    I think determine_dirtyable_memory() is a rather costly function since it
    need many atomic reads for gathering zone/global page state.  But when we
    use vm_dirty_bytes && dirty_background_bytes, we don't need that costly
    calculation.

    This patch eliminates such unnecessary overhead.

    NOTE : newly added if condition might add overhead in normal path.
           But it should be _really_ small because anyway we need the
           access both vm_dirty_bytes and dirty_background_bytes so it is
           likely to hit the cache.

    [akpm@linux-foundation.org: fix used-uninitialised warning]
    Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
    Cc: Wu Fengguang <fengguang.wu@intel.com>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

brk: fix min_brk lower bound computation for COMPAT_BRK

    Even if CONFIG_COMPAT_BRK is set in the kernel configuration, it can still
    be overriden by randomize_va_space sysctl.

    If this is the case, the min_brk computation in sys_brk() implementation
    is wrong, as it solely takes into account COMPAT_BRK setting, assuming
    that brk start is not randomized.  But that might not be the case if
    randomize_va_space sysctl has been set to '2' at the time the binary has
    been loaded from disk.

    In such case, the check has to be done in a same way as in
    !CONFIG_COMPAT_BRK case.

    In addition to that, the check for the COMPAT_BRK case introduced back in
    a5b4592c ("brk: make sys_brk() honor COMPAT_BRK when computing lower
    bound") is slightly wrong -- the lower bound shouldn't be mm->end_code,
    but mm->end_data instead, as that's where the legacy applications expect
    brk section to start (i.e.  immediately after last global variable).

    [akpm@linux-foundation.org: fix comment]
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm/page_alloc.c: simplify calculation of combined index of adjacent buddy lists

    The previous approach of calucation of combined index was

    	page_idx & ~(1 << order))

    but we have same result with

    	page_idx & buddy_idx

    This reduces instructions slightly as well as enhances readability.

    [akpm@linux-foundation.org: coding-style fixes]
    [akpm@linux-foundation.org: fix used-unintialised warning]
    Signed-off-by: KyongHo Cho <pullip.cho@samsung.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm/dmapool.c: take lock only once in dma_pool_free()

    dma_pool_free() scans for the page to free in the pool list holding the
    pool lock.  Then it releases the lock basically to acquire it immediately
    again.  Modify the code to only take the lock once.

    This will do some additional loops and computations with the lock held in
    if memory debugging is activated.  If it is not activated the only new
    operations with this lock is one if and one substraction.

    Signed-off-by: Rolf Eike Beer <eike-kernel@sf-tec.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm/dmapool.c: use TASK_UNINTERRUPTIBLE in dma_pool_alloc()

    As it stands this code will degenerate into a busy-wait if the calling task
    has signal_pending().

    Cc: Rolf Eike Beer <eike-kernel@sf-tec.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
vmalloc: remove confusing comment on vwrite()

KM_USER1 is never used for vwrite() path so the caller doesn't need to
guarantee it is not used.  Only the caller should guarantee is KM_USER0
and it is commented already.

Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

+fix for last commit missing endif
Ported init/calibrate.c from 3.0.8 kernel
Adjusted some more the voltage, now all alighned as planed.
Added shrinker missing code
ext3: speed up file creates by optimizing rec_len functions

The addition of 64k block capability in the rec_len_from_disk
and rec_len_to_disk functions added a bit of math overhead which
slows down file create workloads needlessly when the architecture
cannot even support 64k blocks, thanks to page size limits.

Similar changes already exist in the ext4 codebase.

The directory entry checking can also be optimized a bit
by sprinkling in some unlikely() conditions to move the
error handling out of line.

bonnie++ sequential file creates on a 512MB ramdisk speeds up
from about 77,000/s to about 82,000/s, about a 6% improvement.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
ext2: speed up file creates by optimizing rec_len functions

The addition of 64k block capability in the rec_len_from_disk
and rec_len_to_disk functions added a bit of math overhead which
slows down file create workloads needlessly when the architecture
cannot even support 64k blocks, thanks to page size limits.

The directory entry checking can also be optimized a bit
by sprinkling in some unlikely() conditions to move the
error handling out of line.

bonnie++ sequential file creates on a 512MB ramdisk speeds up
from about 2200/s to about 2500/s, about a 14% improvement.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
dm io: remove BIO_RW_SYNCIO flag from kcopyd

Remove the REQ_SYNC flag to improve write throughput when writing
to the origin with a snapshot on the same device (using the CFQ I/O
scheduler).

Sequential write throughput (chunksize of 4k, 32k, 512k)
  unpatched:  8.5,  8.6,  9.3 MB/s
  patched:   15.2, 18.5, 17.5 MB/s

Snapshot exception reallocations are triggered by writes that are
usually async, so mark the associated dm_io_request as async as well.
This helps when using the CFQ I/O scheduler because it has separate
queues for sync and async I/O.  Async is optimized for throughput; sync
for latency.  With this change we're consciously favoring throughput over
latency.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
arch: arm: updates from ruby source
(smp/process/idle/fault/flush)
lockdep: print lock name for lockdep_init_error

From: Ming Lei <tom.leiming@gmail.com>

This patch prints the name of the lock which is acquired
before lockdep_init is called, so that user can easily find
which lock trigged the lockdep init error warning.

This patch also removes the lockdep_init_error message
of "Arch code didn't call lockdep_init() early enough?" since
lockdep_init is called in arch independent code now.

Signed-off-by: Ming Lei <tom.leiming@gmail.com>
init/main.c: execute lockdep_init as early as possible

From: Ming Lei <tom.leiming@gmail.com>

This patch removes the lockdep warning[1] on ARM platform.
The warning is caused by printk inside smp_setup_processor_id.

It is safe to do this because lockdep_init doesn't depend on
smp_setup_processor_id, so make printk can be called as early
as possible without lockdep complainment.

[1], lockdep warning
[    0.000000] WARNING: lockdep init error! Arch code didn't call
lockdep_init() early enough?
[    0.000000] Call stack leading to lockdep invocation was:
[    0.000000]  [<c00164bc>] save_stack_trace_tsk+0x0/0x90
[    0.000000]  [<ffffffff>] 0xffffffff
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
sched: Do not block when waiting to free old root domain

Instead of calling synchronize_sched(), directly invoke
call_rcu_sched() which will not block the cpu hotplug
operation but will call free_rootdomain when the rcu
process is complete. This is safe because the root
domains are allocated dynamically so any new readers
will have pointers to the new data and the new data
does not overwrite the old data.

This is a partial backport from 3.0.0 kernel.
I did not backport the dynamic allocation of the sched
domain and sched group data structures.  This would
require inclusion of 10 other patches and would not be
stable.

dce840a08702bd13a9a186e07e63d1ef82256b5e
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date:   Thu Apr 7 14:09:50 2011 +0200

    sched: Dynamically allocate sched_domain/sched_group data-structures

    Instead of relying on static allocations for the sched_domain and
    sched_group trees, dynamically allocate and RCU free them.

    Allocating this dynamically also allows for some build_sched_groups()
    simplification since we can now (like with other simplifications) rely
    on the sched_domain tree instead of hard-coded knowledge.

    One tricky to note is that detach_destroy_domains() needs to hold
    rcu_read_lock() over the entire tear-down, per-cpu is not sufficient
    since that can lead to partial sched_group existance (could possibly
    be solved by doing the tear-down backwards but this is much more
    robust).

    A concequence of the above is that we can no longer print the
    sched_domain debug stuff from cpu_attach_domain() since that might now
    run with preemption disabled (due to classic RCU etc.) and
    sched_domain_debug() does some GFP_KERNEL allocations.

    Another thing to note is that we now fully rely on normal RCU and not
    RCU-sched, this is because with the new and exiting RCU flavours we
    grew over the years BH doesn't necessarily hold off RCU-sched grace
    periods (-rt is known to break this). This would in fact already cause
    us grief since we do sched_domain/sched_group iterations from softirq
    context.

    This patch is somewhat larger than I would like it to be, but I didn't
    find any means of shrinking/splitting this.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Nick Piggin <npiggin@kernel.dk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
    Link: http://lkml.kernel.org/r/20110407122942.245307941@chello.nl
Signed-off-by: Ingo Molnar <mingo@elte.hu>

Signed-off-by: Maya Spivak <mspivak@codeaurora.org>
(cherry picked from commit 09d39b8ade298ffed33597926a1b30f4609400a6)

Change-Id: I7305af949900919f06cf3444daf1183370aa07b7
Signed-off-by: Swetha Basineni <sbasin@codeaurora.org>
drivers: base: squashed commit: Add generic cross-process locking API

Add a generic locking API for situations where multiple user-space
processes and/or kernel drivers need to cooordinate access to a
shared resource such as a graphics buffer.

Change-Id: Ic0dedbad74b970d7bd1a6624a845b5b1b9847443
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>

base: genlock: Properly destroy handle resources

The resources allocated for a handle were not being freed on device
release.  This included releasing the lock.  Unfortunately, the
lock release had a fput() too many which was screwing up the
reference counting on the file descriptors.  When attaching a lock,
we only need the file pointer for a short time so fput() it back
immediately.  That way, only there will only be one reference to
the lock per process, and the process will be responsible for
closing the fd directly and the fput() in genlock_release_lock
is no longer needed.

CRs-fixed: 322645
Change-Id: Ic0dedbad55300a2f8463c800cf8361719583b0b8
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>