* __link_block_group uses GFP_KERNEL @ 2017-03-24 9:02 Denis Kirjanov 2017-03-24 23:13 ` Jeff Mahoney 0 siblings, 1 reply; 5+ messages in thread From: Denis Kirjanov @ 2017-03-24 9:02 UTC (permalink / raw) To: linux-btrfs; +Cc: linux-kernel, chris.mason Hi guys, Looks like that current code does GFP_KERNEL allocation inside __link_block_group. the function invokes kobject_add and internally creates sysfs files with the GFP_KERNEL flag set. But since do_chunk_alloc executes insides the btrfs transaction it's not allowed to sleep. Thanks! ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: __link_block_group uses GFP_KERNEL 2017-03-24 9:02 __link_block_group uses GFP_KERNEL Denis Kirjanov @ 2017-03-24 23:13 ` Jeff Mahoney 2017-03-25 6:48 ` Denis Kirjanov 0 siblings, 1 reply; 5+ messages in thread From: Jeff Mahoney @ 2017-03-24 23:13 UTC (permalink / raw) To: Denis Kirjanov, linux-btrfs; +Cc: linux-kernel, chris.mason [-- Attachment #1.1: Type: text/plain, Size: 661 bytes --] On 3/24/17 5:02 AM, Denis Kirjanov wrote: > Hi guys, > > Looks like that current code does GFP_KERNEL allocation inside > __link_block_group. > the function invokes kobject_add and internally creates sysfs files > with the GFP_KERNEL flag set. Yep, that's a bug. > But since do_chunk_alloc executes insides the btrfs transaction it's > not allowed to sleep. It's allowed to sleep but isn't allowed to do reclaim that involves file system writeback. Michal Hocko's allocation context idea would fix this, but it's not there yet, so we'll need to defer the kobject_add until we can use GFP_KERNEL. -Jeff -- Jeff Mahoney SUSE Labs [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: __link_block_group uses GFP_KERNEL 2017-03-24 23:13 ` Jeff Mahoney @ 2017-03-25 6:48 ` Denis Kirjanov 2017-03-27 17:18 ` David Sterba 0 siblings, 1 reply; 5+ messages in thread From: Denis Kirjanov @ 2017-03-25 6:48 UTC (permalink / raw) To: Jeff Mahoney; +Cc: linux-btrfs, linux-kernel, chris.mason On 3/25/17, Jeff Mahoney <jeffm@suse.com> wrote: > On 3/24/17 5:02 AM, Denis Kirjanov wrote: >> Hi guys, >> >> Looks like that current code does GFP_KERNEL allocation inside >> __link_block_group. >> the function invokes kobject_add and internally creates sysfs files >> with the GFP_KERNEL flag set. > > Yep, that's a bug. > >> But since do_chunk_alloc executes insides the btrfs transaction it's >> not allowed to sleep. > > It's allowed to sleep but isn't allowed to do reclaim that involves file > system writeback. Michal Hocko's allocation context idea would fix > this, but it's not there yet, so we'll need to defer the kobject_add > until we can use GFP_KERNEL. Ok, I see. Can you point out to the initial patchset? Thanks! > > -Jeff > > -- > Jeff Mahoney > SUSE Labs > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: __link_block_group uses GFP_KERNEL 2017-03-25 6:48 ` Denis Kirjanov @ 2017-03-27 17:18 ` David Sterba 2017-03-28 8:16 ` Denis Kirjanov 0 siblings, 1 reply; 5+ messages in thread From: David Sterba @ 2017-03-27 17:18 UTC (permalink / raw) To: Denis Kirjanov; +Cc: Jeff Mahoney, linux-btrfs, linux-kernel, chris.mason On Sat, Mar 25, 2017 at 09:48:28AM +0300, Denis Kirjanov wrote: > On 3/25/17, Jeff Mahoney <jeffm@suse.com> wrote: > > On 3/24/17 5:02 AM, Denis Kirjanov wrote: > >> Hi guys, > >> > >> Looks like that current code does GFP_KERNEL allocation inside > >> __link_block_group. > >> the function invokes kobject_add and internally creates sysfs files > >> with the GFP_KERNEL flag set. > > > > Yep, that's a bug. > > > >> But since do_chunk_alloc executes insides the btrfs transaction it's > >> not allowed to sleep. > > > > It's allowed to sleep but isn't allowed to do reclaim that involves file > > system writeback. Michal Hocko's allocation context idea would fix > > this, but it's not there yet, so we'll need to defer the kobject_add > > until we can use GFP_KERNEL. > > Ok, I see. Can you point out to the initial patchset? https://lwn.net/Articles/716323/ Fixing this properly is a lot of work so we might need to add a temporary workaround, as Jeff suggests, to move calling into sysfs to a later time. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: __link_block_group uses GFP_KERNEL 2017-03-27 17:18 ` David Sterba @ 2017-03-28 8:16 ` Denis Kirjanov 0 siblings, 0 replies; 5+ messages in thread From: Denis Kirjanov @ 2017-03-28 8:16 UTC (permalink / raw) To: dsterba, Denis Kirjanov, Jeff Mahoney, linux-btrfs, linux-kernel, chris.mason On 3/27/17, David Sterba <dsterba@suse.cz> wrote: > On Sat, Mar 25, 2017 at 09:48:28AM +0300, Denis Kirjanov wrote: >> On 3/25/17, Jeff Mahoney <jeffm@suse.com> wrote: >> > On 3/24/17 5:02 AM, Denis Kirjanov wrote: >> >> Hi guys, >> >> >> >> Looks like that current code does GFP_KERNEL allocation inside >> >> __link_block_group. >> >> the function invokes kobject_add and internally creates sysfs files >> >> with the GFP_KERNEL flag set. >> > >> > Yep, that's a bug. >> > >> >> But since do_chunk_alloc executes insides the btrfs transaction it's >> >> not allowed to sleep. >> > >> > It's allowed to sleep but isn't allowed to do reclaim that involves >> > file >> > system writeback. Michal Hocko's allocation context idea would fix >> > this, but it's not there yet, so we'll need to defer the kobject_add >> > until we can use GFP_KERNEL. >> >> Ok, I see. Can you point out to the initial patchset? > > https://lwn.net/Articles/716323/ > > Fixing this properly is a lot of work so we might need to add a > temporary workaround, as Jeff suggests, to move calling into sysfs to a > later time. > Care to send a patch? Or I can dig a bit. Thanks! ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-03-28 8:16 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-03-24 9:02 __link_block_group uses GFP_KERNEL Denis Kirjanov 2017-03-24 23:13 ` Jeff Mahoney 2017-03-25 6:48 ` Denis Kirjanov 2017-03-27 17:18 ` David Sterba 2017-03-28 8:16 ` Denis Kirjanov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®