linux.git/drivers/staging/zram, branch v3.10

zram: fix zram_bvec_read duplicate dump failure message and stat accumulation

2013-03-19T00:42:34+00:00

When zram decompress fails, the code unnecessarily dumps failure messages and
does stat accumulation in function zram_decompress_page(), this work is already
done in function zram_decompress_page, the patch skips the redundant work.

Signed-off-by: Wanpeng Li 
Signed-off-by: Greg Kroah-Hartman

staging: Remove unnecessary OOM messages

2013-02-11T18:10:33+00:00

alloc failures already get standardized OOM
messages and a dump_stack.

For the affected mallocs around these OOM messages:

Converted kzallocs with multiplies to kcalloc.
Converted kmallocs with multiplies to kmalloc_array.
Converted a kmalloc/strlen/strncpy to kstrdup.
Moved a spin_lock below a removed OOM message and
removed a now unnecessary spin_unlock.
Neatened alignment and whitespace.

Signed-off-by: Joe Perches 
Signed-off-by: Greg Kroah-Hartman

staging: zram: __zram_reset_device() can be static

2013-02-08T20:20:22+00:00

Signed-off-by: Fengguang Wu 
Cc: Minchan Kim 
Signed-off-by: Greg Kroah-Hartman

zram: get rid of lockdep warning

2013-02-06T02:01:24+00:00

Lockdep complains about recursive deadlock of zram->init_lock.
[1] made it false positive because we can't request IO to zram
before setting disksize. Anyway, we should shut lockdep up to
avoid many reporting from user.

[1] : zram: force disksize setting before using zram

Acked-by: Jerome Marchand 
Acked-by: Nitin Gupta 
Signed-off-by: Minchan Kim 
Signed-off-by: Greg Kroah-Hartman

zram: fix warning of print format

2013-02-06T02:01:24+00:00

kbuild bot whinges due to print format mistmatch caused by
zram: force disksize setting before using zram.

This patch fixes it.

Reported-by: Wu Fengguang 
Signed-off-by: Minchan Kim 
Signed-off-by: Greg Kroah-Hartman

zram: give up lazy initialization of zram metadata

2013-02-04T01:52:49+00:00

1) User of zram normally do mkfs.xxx or mkswap before using
   the zram block device(ex, normally, do it at booting time)
   It ends up allocating such metadata of zram before real usage so
   benefit of lazy initialzation would be mitigated.

2) Some user want to use zram when memory pressure is high.(ie, load zram
   dynamically, NOT booting time). It does make sense because people don't
   want to waste memory until memory pressure is high(ie, where zram is really
   helpful time). In this case, lazy initialzation could be failed easily
   because we will use GFP_NOIO instead of GFP_KERNEL for avoiding deadlock.
   So the benefit of lazy initialzation would be mitigated, too.

3) Metadata overhead is not critical and Nitin has a plan to diet it.
   4K : 12 byte(64bit machine) -> 64G : 192M so 0.3% isn't big overhead
   If insane user use such big zram device up to 20, it could consume 6% of ram
   but efficieny of zram will cover the waste.

So this patch gives up lazy initialization and instead we initialize metadata
at disksize setting time.

Acked-by: Jerome Marchand 
Acked-by: Nitin Gupta 
Signed-off-by: Minchan Kim 
Signed-off-by: Greg Kroah-Hartman

zram: force disksize setting before using zram

2013-02-04T01:52:49+00:00

Now zram document syas "set disksize is optional"
but partly it's wrong. When you try to use zram firstly after
booting, you must set disksize, otherwise zram can't work because
zram gendisk's size is 0. But once you do it, you can use zram freely
after reset because reset doesn't reset to zero paradoxically.
So in this time, disksize setting is optional.:(
It's inconsitent for user behavior and not straightforward.

This patch forces always setting disksize firstly before using zram.
Yes. It changes current behavior so someone could complain when
he upgrades zram. Apparently it could be a problem if zram is mainline
but it still lives in staging so behavior could be changed for right
way to go. Let them excuse.

Acked-by: Jerome Marchand 
Acked-by: Nitin Gupta 
Acked-by: Dan Magenheimer 
Signed-off-by: Minchan Kim 
Signed-off-by: Greg Kroah-Hartman

zram: Fix deadlock bug in partial read/write

2013-02-04T01:52:49+00:00

Now zram allocates new page with GFP_KERNEL in zram I/O path
if IO is partial. Unfortunately, It may cause deadlock with
reclaim path like below.

write_page from fs
fs_lock
allocation(GFP_KERNEL)
reclaim
pageout
				write_page from fs
				fs_lock <-- deadlock

This patch fixes it by using GFP_NOIO.  In read path, we
reorganize code flow so that kmap_atomic is called after the
GFP_NOIO allocation.

Cc: stable@vger.kernel.org
Acked-by: Jerome Marchand 
Acked-by: Nitin Gupta 
[ penberg@kernel.org: don't use GFP_ATOMIC ]
Signed-off-by: Pekka Enberg 
Signed-off-by: Minchan Kim 
Signed-off-by: Greg Kroah-Hartman

staging: zsmalloc: remove unused pool name

2013-01-30T17:22:41+00:00

zs_create_pool() currently takes a name argument which is
never used in any useful way.

This patch removes it.

Signed-off-by: Seth Jennings 
Acked-by: Nitin Gupta 
Acked-by: Rik van Riel 
Signed-off-by: Greg Kroah-Hartman

Merge 3.8-rc5 into staging-next

2013-01-26T05:25:02+00:00

This resolves a merge issue with a iio driver, and the zram code.

Signed-off-by: Greg Kroah-Hartman