On 3/27/17, David Sterba wrote:
> On Sat, Mar 25, 2017 at 09:48:28AM +0300, Denis Kirjanov wrote:
>> On 3/25/17, Jeff Mahoney 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.
>
On Sat, Mar 25, 2017 at 09:48:28AM +0300, Denis Kirjanov wrote:
> On 3/25/17, Jeff Mahoney 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
On 3/25/17, Jeff Mahoney 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'
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 execut
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!
--
To un