From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.codeaurora.org by pdx-caf-mail.web.codeaurora.org (Dovecot) with LMTP id 0BfHChBjGVuIZQAAmS7hNA ; Thu, 07 Jun 2018 16:55:06 +0000 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 7C763607E7; Thu, 7 Jun 2018 16:55:06 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by smtp.codeaurora.org (Postfix) with ESMTP id CA13C605A2; Thu, 7 Jun 2018 16:55:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org CA13C605A2 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934335AbeFGQzD (ORCPT + 25 others); Thu, 7 Jun 2018 12:55:03 -0400 Received: from mx2.suse.de ([195.135.220.15]:40524 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932987AbeFGQzA (ORCPT ); Thu, 7 Jun 2018 12:55:00 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 103DFAAC3; Thu, 7 Jun 2018 16:54:59 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 8303EDAD20; Thu, 7 Jun 2018 18:52:13 +0200 (CEST) Date: Thu, 7 Jun 2018 18:52:13 +0200 From: David Sterba To: Dmitry Vyukov Cc: dsterba@suse.cz, Anand Jain , syzbot , clm@fb.com, dsterba@suse.com, Josef Bacik , linux-btrfs@vger.kernel.org, LKML , syzkaller-bugs Subject: Re: kernel BUG at fs/btrfs/volumes.c:LINE! Message-ID: <20180607165213.GI3215@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Dmitry Vyukov , Anand Jain , syzbot , clm@fb.com, dsterba@suse.com, Josef Bacik , linux-btrfs@vger.kernel.org, LKML , syzkaller-bugs References: <00000000000096009b056df92dc1@google.com> <70a3c2d1-3f53-d4c0-13b3-29f836ec46d9@oracle.com> <20180607153450.GF3215@twin.jikos.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 07, 2018 at 06:28:02PM +0200, Dmitry Vyukov wrote: > > Normally the GFP_NOFS allocations do not fail so I think the fuzzer > > environment is tuned to allow that, which is fine for coverage but does > > not happen in practice. This will be fixed eventually. > > Isn't GFP_NOFS more restricted than normal allocations? Are these > allocations accounted against memcg? It's easy to fail any allocation > within a memory container. https://lwn.net/Articles/723317/ The 'too small to fail' and some unwritten semantics of GFP_NOFS but I think you're right about the memory controler that can fail any allocation though. Error handling is being improved over time, the memory allocation failures are in some cases hard and this one would need to update some logic so it's not a oneliner.