On Wed, Apr 09, 2014 at 05:23:23PM -0400, Jeff Mahoney wrote:
2 locks held by kswapd0/169:
#0: (shrinker_rwsem){..}, at: [81159e8a]
shrink_slab+0x3a/0x160
#1: (type-s_umount_key#27){..}, at: [811bac6f]
grab_super_passive+0x3f/0x90
Signed-off-by: Jeff Mahoney
On Wed, Mar 26, 2014 at 6:11 PM, Jeff Mahoney je...@suse.com wrote:
When encountering memory pressure, testers have run into the following
lockdep warning. It was caused by __link_block_group calling kobject_add
with the groups_sem held. kobject_add calls kvasprintf with GFP_KERNEL,
which gets
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/9/14, 12:05 PM, Filipe David Manana wrote:
On Wed, Mar 26, 2014 at 6:11 PM, Jeff Mahoney je...@suse.com
wrote:
When encountering memory pressure, testers have run into the
following lockdep warning. It was caused by __link_block_group
When encountering memory pressure, testers have run into the following
lockdep warning. It was caused by __link_block_group calling kobject_add
with the groups_sem held. kobject_add calls kvasprintf with GFP_KERNEL,
which gets us into reclaim context. The kobject doesn't actually need
to be added
When encountering memory pressure, testers have run into the following
lockdep warning. It was caused by __link_block_group calling kobject_add
with the groups_sem held. kobject_add calls kvasprintf with GFP_KERNEL,
which gets us into reclaim context. The kobject doesn't actually need
to be added
On Wed, Mar 26, 2014 at 02:11:26PM -0400, Jeff Mahoney wrote:
When encountering memory pressure, testers have run into the following
lockdep warning. It was caused by __link_block_group calling kobject_add
with the groups_sem held. kobject_add calls kvasprintf with GFP_KERNEL,
which gets us
