From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:58624 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964863AbeEIXxW (ORCPT ); Wed, 9 May 2018 19:53:22 -0400 Date: Wed, 9 May 2018 16:53:21 -0700 From: Andrew Morton To: Tetsuo Handa Cc: linux-fsdevel@vger.kernel.org, Tigran Aivazian , syzbot Subject: Re: [PATCH] bfs: add sanity check at bfs_fill_super(). Message-Id: <20180509165321.3b2b1313fde0f007c1a5a015@linux-foundation.org> In-Reply-To: <201805092346.w49NkINl045657@www262.sakura.ne.jp> References: <1525862104-3407-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> <20180509160658.c37bef542a8ee5245a13917b@linux-foundation.org> <201805092346.w49NkINl045657@www262.sakura.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, 10 May 2018 08:46:18 +0900 Tetsuo Handa wrote: > > page-allocation-fauilure warning and a nice backtrace, etc. Why > > suppress all of that and add our custom warning instead? > > the intent of this patch is to avoid panic() by panic_on_warn == 1 > due to hitting > > struct kmem_cache *kmalloc_slab(size_t size, gfp_t flags) > { > unsigned int index; > > if (unlikely(size > KMALLOC_MAX_SIZE)) { > WARN_ON_ONCE(!(flags & __GFP_NOWARN)); /* <= this line */ > return NULL; > } > > when size to allocate is controlled by the filesystem image. Well, the same could happen with many many memory-allocation sites. What's special about BFS? If someone sets panic_on_warn=1 then presumably this panic is the behaviour they wanted in this case.