Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936059AbdCYGsh (ORCPT ); Sat, 25 Mar 2017 02:48:37 -0400 Received: from mail-qt0-f179.google.com ([209.85.216.179]:34096 "EHLO mail-qt0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753150AbdCYGsa (ORCPT ); Sat, 25 Mar 2017 02:48:30 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Denis Kirjanov Date: Sat, 25 Mar 2017 09:48:28 +0300 Message-ID: Subject: Re: __link_block_group uses GFP_KERNEL To: Jeff Mahoney Cc: linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, chris.mason@fusionio.com Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 785 Lines: 31 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'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 > >