lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 17 Mar 2014 17:43:58 +0300
From:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To:	Minchan Kim <minchan@...nel.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Nitin Gupta <ngupta@...are.org>,
	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	Jerome Marchand <jmarchan@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: zram: zsmalloc calls sleeping function from atomic context

Hello gents,

I just noticed that starting from commit

commit 3d693a5127e79e79da7c34dc0c776bc620697ce5
Author: Andrew Morton <akpm@...ux-foundation.org>
Date:   Mon Mar 17 11:23:56 2014 +1100

    mm-vmalloc-avoid-soft-lockup-warnings-when-vunmaping-large-ranges-fix
    
    add a might_sleep() to catch atomic callers more promptly


and


commit 032dda8b6c4021d4be63bcc483b47fd26c6f48a2
Author: David Vrabel <david.vrabel@...rix.com>
Date:   Mon Mar 17 11:23:56 2014 +1100

    mm/vmalloc: avoid soft lockup warnings when vunmap()'ing large ranges
    
    If vunmap() is used to unmap a large (e.g., 50 GB) region, it may take
    sufficiently long that it triggers soft lockup warnings.
    
    Add a cond_resched() into vunmap_pmd_range() so the calling task may be
    resheduled after unmapping each PMD entry.  This is how zap_pmd_range()
    fixes the same problem for userspace mappings.
    
    All callers may sleep except for the APEI GHES driver (apei/ghes.c) which
    calls unmap_kernel_range_no_flush() from NMI and IRQ contexts.  This
    driver only unmaps a single pages so don't call cond_resched() if the
    unmap doesn't cross a PMD boundary.


w/ CONFIG_PGTABLE_MAPPING=y zs_unmap_object() calls unmap_kernel_range() under rwlock,
producing the following warning (basically we perform every read()/write() under
rwlock, so I can see lots of these warnings):

[  631.541177] BUG: sleeping function called from invalid context at mm/vmalloc.c:74
[  631.541181] in_atomic(): 1, irqs_disabled(): 0, pid: 94, name: kworker/u8:2
[  631.541183] Preemption disabled at:[<ffffffffa00ca0ad>] zram_bvec_rw.isra.14+0x2be/0x4fc [zram]

[  631.541193] CPU: 2 PID: 94 Comm: kworker/u8:2 Tainted: G           O  3.14.0-rc6-next-20140317-dbg-dirty #182
[  631.541195] Hardware name: Acer             Aspire 5741G    /Aspire 5741G    , BIOS V1.20 02/08/2011
[  631.541202] Workqueue: writeback bdi_writeback_workfn (flush-254:0)
[  631.541205]  0000000000000000 ffff88015211b748 ffffffff813ba01d 0000000000000000
[  631.541208]  ffff88015211b768 ffffffff81057ecb ffffc9000003e000 ffffc9000003e000
[  631.541212]  ffff88015211b7d8 ffffffff810cc491 ffffc9000003dfff ffff88015211b800
[  631.541216] Call Trace:
[  631.541223]  [<ffffffff813ba01d>] dump_stack+0x4e/0x7a
[  631.541229]  [<ffffffff81057ecb>] __might_sleep+0x14e/0x153
[  631.541234]  [<ffffffff810cc491>] vunmap_page_range+0x133/0x25d
[  631.541237]  [<ffffffff810cd81b>] unmap_kernel_range+0x16/0x26
[  631.541241]  [<ffffffff810de6f6>] zs_unmap_object+0xd8/0xff
[  631.541245]  [<ffffffffa00ca120>] zram_bvec_rw.isra.14+0x331/0x4fc [zram]
[  631.541248]  [<ffffffffa00ca439>] zram_make_request+0x14e/0x228 [zram]
[  631.541252]  [<ffffffff810a8088>] ? mempool_alloc+0x6d/0x130
[  631.541257]  [<ffffffff811e9395>] generic_make_request+0x97/0xd6
[  631.541259]  [<ffffffff811e94c6>] submit_bio+0xf2/0x131
[  631.541263]  [<ffffffff81106306>] _submit_bh+0x1c1/0x1eb
[  631.541266]  [<ffffffff8110633b>] submit_bh+0xb/0xd
[  631.541269]  [<ffffffff811078d9>] __block_write_full_page+0x1ad/0x2c8
[  631.541273]  [<ffffffff8110a118>] ? I_BDEV+0xd/0xd
[  631.541276]  [<ffffffff81105041>] ? end_buffer_write_sync+0x61/0x61
[  631.541278]  [<ffffffff8110a118>] ? I_BDEV+0xd/0xd
[  631.541282]  [<ffffffff81107bb4>] block_write_full_page_endio+0xdc/0xe8
[  631.541284]  [<ffffffff81107bd0>] block_write_full_page+0x10/0x12
[  631.541287]  [<ffffffff8110a6e5>] blkdev_writepage+0x13/0x15
[  631.541292]  [<ffffffff810acfb8>] __writepage+0xe/0x2c
[  631.541295]  [<ffffffff810ad35f>] write_cache_pages+0x25c/0x367
[  631.541297]  [<ffffffff810acfaa>] ? mapping_tagged+0xf/0xf
[  631.541301]  [<ffffffff810ad4a3>] generic_writepages+0x39/0x51
[  631.541304]  [<ffffffff810ae6d4>] do_writepages+0x19/0x27
[  631.541307]  [<ffffffff810ff6d4>] __writeback_single_inode+0x3c/0xee
[  631.541310]  [<ffffffff811000d7>] writeback_sb_inodes+0x1bf/0x2f9
[  631.541313]  [<ffffffff8110028b>] __writeback_inodes_wb+0x7a/0xb0
[  631.541316]  [<ffffffff811003c0>] wb_writeback+0xff/0x190
[  631.541319]  [<ffffffff810595f3>] ? get_parent_ip+0xd/0x3c
[  631.541322]  [<ffffffff811008f5>] bdi_writeback_workfn+0xcd/0x28d
[  631.541325]  [<ffffffff8105b32b>] ? try_to_wake_up+0x1f4/0x203
[  631.541330]  [<ffffffff8104d213>] process_one_work+0x1c9/0x2e9
[  631.541332]  [<ffffffff8104d7ad>] worker_thread+0x1d3/0x2bd
[  631.541335]  [<ffffffff8104d5da>] ? rescuer_thread+0x27d/0x27d
[  631.541338]  [<ffffffff81051e75>] kthread+0xd6/0xde
[  631.541341]  [<ffffffff81051d9f>] ? kthread_create_on_node+0x162/0x162
[  631.541345]  [<ffffffff813bf8bc>] ret_from_fork+0x7c/0xb0
[  631.541348]  [<ffffffff81051d9f>] ? kthread_create_on_node+0x162/0x162

	-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ