Linux 3.0.85

commit 2d0ed86595ca3a101c710efaec7aab0ca69c76da
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Jul 3 11:03:56 2013 -0700

    Linux 3.0.85

commit db61e4ec623437237d05b5ab8ce97d9377682de2
Author: Liang Li <liang.li@windriver.com>
Date:   Sat Jan 19 17:52:10 2013 +0800

    pch_uart: fix a deadlock when pch_uart as console

    commit 384e301e3519599b000c1a2ecd938b533fc15d85 upstream.

    When we use pch_uart as system console like 'console=ttyPCH0,115200',
    then 'send break' to it. We'll encounter the deadlock on a cpu/core,
    with interrupts disabled on the core. When we happen to have all irqs
    affinity to cpu0 then the deadlock on cpu0 actually deadlock whole
    system.

    In pch_uart_interrupt, we have spin_lock_irqsave(&priv->lock, flags)
    then call pch_uart_err_ir when break is received. Then the call to
    dev_err would actually call to pch_console_write then we'll run into
    another spin_lock(&priv->lock), with interrupts disabled.

    So in the call sequence lead by pch_uart_interrupt, we should be
    carefully to call functions that will 'print message to console' only
    in case the uart port is not being used as serial console.

    Signed-off-by: Liang Li <liang.li@windriver.com>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6c46477761504a89d5c68331f3b86fe31b51338
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Fri Jun 28 14:15:15 2013 +0300

    UBIFS: fix a horrid bug

    commit 605c912bb843c024b1ed173dc427cd5c08e5d54d upstream.

    Al Viro pointed me to the fact that '->readdir()' and '->llseek()' have no
    mutual exclusion, which means the 'ubifs_dir_llseek()' can be run while we are
    in the middle of 'ubifs_readdir()'.

    This means that 'file->private_data' can be freed while 'ubifs_readdir()' uses
    it, and this is a very bad bug: not only 'ubifs_readdir()' can return garbage,
    but this may corrupt memory and lead to all kinds of problems like crashes an
    security holes.

    This patch fixes the problem by using the 'file->f_version' field, which
    '->llseek()' always unconditionally sets to zero. We set it to 1 in
    'ubifs_readdir()' and whenever we detect that it became 0, we know there was a
    seek and it is time to clear the state saved in 'file->private_data'.

    I tested this patch by writing a user-space program which runds readdir and
    seek in parallell. I could easily crash the kernel without these patches, but
    could not crash it with these patches.

    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Tested-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f4f917e5e882de1e701d7b26955884ed16604d5
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Fri Jun 28 14:15:14 2013 +0300

    UBIFS: prepare to fix a horrid bug

    commit 33f1a63ae84dfd9ad298cf275b8f1887043ced36 upstream.

    Al Viro pointed me to the fact that '->readdir()' and '->llseek()' have no
    mutual exclusion, which means the 'ubifs_dir_llseek()' can be run while we are
    in the middle of 'ubifs_readdir()'.

    First of all, this means that 'file->private_data' can be freed while
    'ubifs_readdir()' uses it.  But this particular patch does not fix the problem.
    This patch is only a preparation, and the fix will follow next.

    In this patch we make 'ubifs_readdir()' stop using 'file->f_pos' directly,
    because 'file->f_pos' can be changed by '->llseek()' at any point. This may
    lead 'ubifs_readdir()' to returning inconsistent data: directory entry names
    may correspond to incorrect file positions.

    So here we introduce a local variable 'pos', read 'file->f_pose' once at very
    the beginning, and then stick to 'pos'. The result of this is that when
    'ubifs_dir_llseek()' changes 'file->f_pos' while we are in the middle of
    'ubifs_readdir()', the latter "wins".

    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Tested-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5d28835c59b02d4389003bbfa7c4276375f39ed6
Author: Stephane Eranian <eranian@google.com>
Date:   Thu Jun 20 11:36:28 2013 +0200

    perf: Disable monitoring on setuid processes for regular users

    commit 2976b10f05bd7f6dab9f9e7524451ddfed656a89 upstream.

    There was a a bug in setup_new_exec(), whereby
    the test to disabled perf monitoring was not
    correct because the new credentials for the
    process were not yet committed and therefore
    the get_dumpable() test was never firing.

    The patch fixes the problem by moving the
    perf_event test until after the credentials
    are committed.

    Signed-off-by: Stephane Eranian <eranian@google.com>
    Tested-by: Jiri Olsa <jolsa@redhat.com>
    Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 806f529730af538c2edbb805589c48cc19ad169b
Author: Zefan Li <lizefan@huawei.com>
Date:   Wed Jun 26 15:31:58 2013 +0800

    dlci: validate the net device in dlci_del()

    commit 578a1310f2592ba90c5674bca21c1dbd1adf3f0a upstream.

    We triggered an oops while running trinity with 3.4 kernel:

    BUG: unable to handle kernel paging request at 0000000100000d07
    IP: [<ffffffffa0109738>] dlci_ioctl+0xd8/0x2d4 [dlci]
    PGD 640c0d067 PUD 0
    Oops: 0000 [#1] PREEMPT SMP
    CPU 3
    ...
    Pid: 7302, comm: trinity-child3 Not tainted 3.4.24.09+ 40 Huawei Technologies Co., Ltd. Tecal RH2285          /BC11BTSA
    RIP: 0010:[<ffffffffa0109738>]  [<ffffffffa0109738>] dlci_ioctl+0xd8/0x2d4 [dlci]
    ...
    Call Trace:
      [<ffffffff8137c5c3>] sock_ioctl+0x153/0x280
      [<ffffffff81195494>] do_vfs_ioctl+0xa4/0x5e0
      [<ffffffff8118354a>] ? fget_light+0x3ea/0x490
      [<ffffffff81195a1f>] sys_ioctl+0x4f/0x80
      [<ffffffff81478b69>] system_call_fastpath+0x16/0x1b
    ...

    It's because the net device is not a dlci device.

    Reported-by: Li Jinyue <lijinyue@huawei.com>
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72ad35befc4715ebb0d715b90f27572ef11a15e2
Author: Zefan Li <lizefan@huawei.com>
Date:   Wed Jun 26 15:29:54 2013 +0800

    dlci: acquire rtnl_lock before calling __dev_get_by_name()

    commit 11eb2645cbf38a08ae491bf6c602eea900ec0bb5 upstream.

    Otherwise the net device returned can be freed at anytime.

    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e2652ea43028e5409c2fd2b585dc8388a6e75bd0
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Thu Jun 20 17:50:09 2013 +0200

    hw_breakpoint: Use cpu_possible_mask in {reserve,release}_bp_slot()

    commit c790b0ad23f427c7522ffed264706238c57c007e upstream.

    fetch_bp_busy_slots() and toggle_bp_slot() use
    for_each_online_cpu(), this is obviously wrong wrt cpu_up() or
    cpu_down(), we can over/under account the per-cpu numbers.

    For example:

        # echo 0 >> /sys/devices/system/cpu/cpu1/online
        # perf record -e mem:0x10 -p 1 &
        # echo 1 >> /sys/devices/system/cpu/cpu1/online
        # perf record -e mem:0x10,mem:0x10,mem:0x10,mem:0x10 -C1 -a &
        # taskset -p 0x2 1

    triggers the same WARN_ONCE("Can't find any breakpoint slot") in
    arch_install_hw_breakpoint().

    Reported-by: Vince Weaver <vincent.weaver@maine.edu>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
    Link: http://lkml.kernel.org/r/20130620155009.GA6327@redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ddc55287a4505a5634643fec8e02f887498ffc8
Author: Anderson Lizardo <anderson.lizardo@openbossa.org>
Date:   Sun Jun 2 16:30:40 2013 -0400

    Bluetooth: Fix crash in l2cap_build_cmd() with small MTU

    commit 300b962e5244a1ea010df7e88595faa0085b461d upstream.

    If a too small MTU value is set with ioctl(HCISETACLMTU) or by a bogus
    controller, memory corruption happens due to a memcpy() call with
    negative length.

    Fix this crash on either incoming or outgoing connections with a MTU
    smaller than L2CAP_HDR_SIZE + L2CAP_CMD_HDR_SIZE:

    [   46.885433] BUG: unable to handle kernel paging request at f56ad000
    [   46.888037] IP: [<c03d94cd>] memcpy+0x1d/0x40
    [   46.888037] *pdpt = 0000000000ac3001 *pde = 00000000373f8067 *pte = 80000000356ad060
    [   46.888037] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
    [   46.888037] Modules linked in: hci_vhci bluetooth virtio_balloon i2c_piix4 uhci_hcd usbcore usb_common
    [   46.888037] CPU: 0 PID: 1044 Comm: kworker/u3:0 Not tainted 3.10.0-rc1+ #12
    [   46.888037] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
    [   46.888037] Workqueue: hci0 hci_rx_work [bluetooth]
    [   46.888037] task: f59b15b0 ti: f55c4000 task.ti: f55c4000
    [   46.888037] EIP: 0060:[<c03d94cd>] EFLAGS: 00010212 CPU: 0
    [   46.888037] EIP is at memcpy+0x1d/0x40
    [   46.888037] EAX: f56ac1c0 EBX: fffffff8 ECX: 3ffffc6e EDX: f55c5cf2
    [   46.888037] ESI: f55c6b32 EDI: f56ad000 EBP: f55c5c68 ESP: f55c5c5c
    [   46.888037]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
    [   46.888037] CR0: 8005003b CR2: f56ad000 CR3: 3557d000 CR4: 000006f0
    [   46.888037] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
    [   46.888037] DR6: ffff0ff0 DR7: 00000400
    [   46.888037] Stack:
    [   46.888037]  fffffff8 00000010 00000003 f55c5cac f8c6a54c ffffffff f8c69eb2 00000000
    [   46.888037]  f4783cdc f57f0070 f759c590 1001c580 00000003 0200000a 00000000 f5a88560
    [   46.888037]  f5ba2600 f5a88560 00000041 00000000 f55c5d90 f8c6f4c7 00000008 f55c5cf2
    [   46.888037] Call Trace:
    [   46.888037]  [<f8c6a54c>] l2cap_send_cmd+0x1cc/0x230 [bluetooth]
    [   46.888037]  [<f8c69eb2>] ? l2cap_global_chan_by_psm+0x152/0x1a0 [bluetooth]
    [   46.888037]  [<f8c6f4c7>] l2cap_connect+0x3f7/0x540 [bluetooth]
    [   46.888037]  [<c019b37b>] ? trace_hardirqs_off+0xb/0x10
    [   46.888037]  [<c01a0ff8>] ? mark_held_locks+0x68/0x110
    [   46.888037]  [<c064ad20>] ? mutex_lock_nested+0x280/0x360
    [   46.888037]  [<c064b9d9>] ? __mutex_unlock_slowpath+0xa9/0x150
    [   46.888037]  [<c01a118c>] ? trace_hardirqs_on_caller+0xec/0x1b0
    [   46.888037]  [<c064ad08>] ? mutex_lock_nested+0x268/0x360
    [   46.888037]  [<c01a125b>] ? trace_hardirqs_on+0xb/0x10
    [   46.888037]  [<f8c72f8d>] l2cap_recv_frame+0xb2d/0x1d30 [bluetooth]
    [   46.888037]  [<c01a0ff8>] ? mark_held_locks+0x68/0x110
    [   46.888037]  [<c064b9d9>] ? __mutex_unlock_slowpath+0xa9/0x150
    [   46.888037]  [<c01a118c>] ? trace_hardirqs_on_caller+0xec/0x1b0
    [   46.888037]  [<f8c754f1>] l2cap_recv_acldata+0x2a1/0x320 [bluetooth]
    [   46.888037]  [<f8c491d8>] hci_rx_work+0x518/0x810 [bluetooth]
    [   46.888037]  [<f8c48df2>] ? hci_rx_work+0x132/0x810 [bluetooth]
    [   46.888037]  [<c0158979>] process_one_work+0x1a9/0x600
    [   46.888037]  [<c01588fb>] ? process_one_work+0x12b/0x600
    [   46.888037]  [<c015922e>] ? worker_thread+0x19e/0x320
    [   46.888037]  [<c015922e>] ? worker_thread+0x19e/0x320
    [   46.888037]  [<c0159187>] worker_thread+0xf7/0x320
    [   46.888037]  [<c0159090>] ? rescuer_thread+0x290/0x290
    [   46.888037]  [<c01602f8>] kthread+0xa8/0xb0
    [   46.888037]  [<c0656777>] ret_from_kernel_thread+0x1b/0x28
    [   46.888037]  [<c0160250>] ? flush_kthread_worker+0x120/0x120
    [   46.888037] Code: c3 90 8d 74 26 00 e8 63 fc ff ff eb e8 90 55 89 e5 83 ec 0c 89 5d f4 89 75 f8 89 7d fc 3e 8d 74 26 00 89 cb 89 c7 c1 e9 02 89 d6 <f3> a5 89 d9 83 e1 03 74 02 f3 a4 8b 5d f4 8b 75 f8 8b 7d fc 89
    [   46.888037] EIP: [<c03d94cd>] memcpy+0x1d/0x40 SS:ESP 0068:f55c5c5c
    [   46.888037] CR2: 00000000f56ad000
    [   46.888037] ---[ end trace 0217c1f4d78714a9 ]---

    Signed-off-by: Anderson Lizardo <anderson.lizardo@openbossa.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fuse: fix nlink after unlink

Anand Avati reports that the following sequence of system calls fail on a fuse
filesystem:

 	create("filename") => 0
 	link("filename", "linkname") => 0
 	unlink("filename") => 0
 	link("linkname", "filename") => -ENOENT ### BUG ###

vfs_link() fails with ENOENT if i_nlink is zero, this is done to prevent
resurrecting already deleted files.

Fuse clears i_nlink on unlink even if there are other links pointing to the
file.

Reported-by: Anand Avati <avati@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
fuse: O_DIRECT support for files

Implement ->direct_IO() method in aops. The ->direct_IO() method combines
the existing fuse_direct_read/fuse_direct_write methods to implement
O_DIRECT functionality.

Reaching ->direct_IO() in the read path via generic_file_aio_read ensures
proper synchronization with page cache with its existing framework.

Reaching ->direct_IO() in the write path via fuse_file_aio_write is made
to come via generic_file_direct_write() which makes it play nice with
the page cache w.r.t other mmap pages etc.

On files marked 'direct_io' by the filesystem server, IO always follows
the fuse_direct_read/write path. There is no effect of fcntl(O_DIRECT)
and it always succeeds.

On files not marked with 'direct_io' by the filesystem server, the IO
path depends on O_DIRECT flag by the application. This can be passed
at the time of open() as well as via fcntl().

Note that asynchronous O_DIRECT iocb jobs are completed synchronously
always (this has been the case with FUSE even before this patch)

Signed-off-by: Anand Avati <avati@redhat.com>
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
fuse: remove the second argument of k[un]map_atomic()

Signed-off-by: Cong Wang <amwang@redhat.com>
fuse: allow nanosecond granularity

Derrik Pates reports that an utimensat with a NULL argument results in the
current time being sent from the kernel with 1 second granularity.

Reported-by: Derrik Pates <demon@now.ai>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
fuse: fix stat call on 32 bit platforms

commit 45c72cd73c788dd18c8113d4a404d6b4a01decf1 upstream.

Now we store attr->ino at inode->i_ino, return attr->ino at the
first time and then return inode->i_ino if the attribute timeout
isn't expired. That's wrong on 32 bit platforms because attr->ino
is 64 bit and inode->i_ino is 32 bit in this case.

Fix this by saving 64 bit ino in fuse_inode structure and returning
it every time we call getattr. Also squash attr->ino into inode->i_ino
explicitly.

Signed-off-by: Pavel Shilovsky <piastry@etersoft.ru>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fuse: don't WARN when nlink is zero

commit dfca7cebc2679f3d129f8e680a8f199a7ad16e38 upstream.

drop_nlink() warns if nlink is already zero.  This is triggerable by a buggy
userspace filesystem.  The cure, I think, is worse than the disease so disable
the warning.

Reported-by: Tero Roponen <tero.roponen@gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dynamic fsync: add reboot notifier to force flush outstanding data

this should further prevent data corruption from kernel panics and
forced reboots

bump version to 1.2

Signed-off-by: Paul Reioux <reioux@gmail.com>
dynamic fsync: add kernel panic notifier to force flush outstanding data

more paranoia safety checks

Signed-off-by: Paul Reioux <reioux@gmail.com>
dynamic fsync: don't disable fdatasync()

Signed-off-by: Paul Reioux <reioux@gmail.com>
mm: pass readahead info down to the i/o scheduler

Some i/o schedulers (i.e. row-iosched, cfq-iosched) deploy an idling
algorithm in order to be better synced with the readahead algorithm.
Idling is a prediction algorithm for incoming read requests.

In this patch we mark pages which are part of a readahead window, by
setting a newly introduced flag. With this flag, the i/o scheduler can
identify a request which is associated with a readahead page. This
enables the i/o scheduler's idling mechanism to be en-sync with the
readahead mechanism and, in turn, can increase read throughput.

Change-Id: I0654f23315b6d19d71bcc9cc029c6b281a44b196
Signed-off-by: Lee Susman <lsusman@codeaurora.org>
Signed-off-by: Paul Reioux <reioux@gmail.com>
block: row-iosched idling triggered by readahead pages

In the current implementation idling is triggered only by request
insertion frequency. This heuristic is not very accurate and may hit
random requests that shouldn't trigger idling. This patch uses the
PG_readahead flag in struct page's flags, which indicates that the page
is part of a readahead window, to start idling upon dispatch of a request
associated with a readahead page.

The above readehead flag is used together with the existing
insertion-frequency trigger. The frequency timer will catch read requests
which are not part of a readahead window, but are still part of a
sequential stream (and therefore dispatched in small time intervals).

Change-Id: Icb7145199c007408de3f267645ccb842e051fd00
Signed-off-by: Lee Susman <lsusman@codeaurora.org>
staging: zsmalloc: zsmalloc memory allocation library

This patch creates a new memory allocation library named
zsmalloc.

NOTE: zsmalloc currently depends on SPARSEMEM for the MAX_PHYSMEM_BITS
value needed to determine the format of the object handle. There may
be a better way to do this.  Feedback is welcome.

Signed-off-by: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Seth Jennings <sjenning@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: fix powerpc linux-next break on zsmalloc

linux/vmalloc.h added to zsmalloc-main.c to resolve implicit
declaration errors.

X86 dependency added to zsmalloc and dependent drivers zcache and zram.

This X86 only requirement is not ideal.  Working to find portable
functions for __flush_tlb_one and set_pte.

Signed-off-by: Seth Jennings <sjenning@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paul Reioux <reioux@gmail.com>

Conflicts:
	drivers/staging/zcache/Kconfig
	drivers/staging/zram/Kconfig
staging: zsmalloc: move object/handle masking defines

This patch moves the definitions of _PFN_BITS, OBJ_INDEX_BITS
and OBJ_INDEX_MASK from zsmalloc-main.c to zsmalloc_int.h

They will be needed to determine ZS_MIN_ALLOC_SIZE in the next
patch

Signed-off-by: Seth Jennings <sjenning@linux.vnet.ibm.com>
Acked-by: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: zsmalloc: add ZS_MAX_PAGES_PER_ZSPAGE

This patch moves where max_zspage_order is declared and
changes its meaning.  "Order" typically implies 2^order
of something; however, it is currently being used as the
"maximum number of single pages in a zspage".  To add clarity,
ZS_MAX_ZSPAGE_ORDER is now used to calculate ZS_MAX_PAGES_PER_ZSPAGE,
which is 2^ZS_MAX_ZSPAGE_ORDER and is the upper bound on the number
of pages in a zspage.

Signed-off-by: Seth Jennings <sjenning@linux.vnet.ibm.com>
Acked-by: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: zsmalloc: calculate MAX_PHYSMEM_BITS if not defined

This patch provides a way to determine or "set a
reasonable value for" MAX_PHYSMEM_BITS in the case that
it is not defined (i.e. !SPARSEMEM)

Signed-off-by: Seth Jennings <sjenning@linux.vnet.ibm.com>
Acked-by: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: zsmalloc: change ZS_MIN_ALLOC_SIZE

This patch ensures that the value of ZS_MIN_ALLOC_SIZE, for the
PAGE_SIZE and MAX_PHYSMEM_BITS on the system, allows for all
possible object ids in the lowest storage class to be encoded
in the object handle.

Signed-off-by: Seth Jennings <sjenning@linux.vnet.ibm.com>
Acked-by: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: zsmalloc: remove SPARSEMEM dep from Kconfig

This patch removes the SPARSEMEM from the zsmalloc
Kconfig

Signed-off-by: Seth Jennings <sjenning@linux.vnet.ibm.com>
Acked-by: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: zsmalloc: fix memory leak

This patch fixes a memory leak in zsmalloc where the first
subpage of each zspage is leaked when the zspage is freed.

Signed-off-by: Nitin Gupta <ngupta@vflare.org>
Acked-by: Seth Jennings <sjenning@linux.vnet.ibm.com>
Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>