From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f68.google.com ([74.125.83.68]:32821 "EHLO mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754957AbeFNNNP (ORCPT ); Thu, 14 Jun 2018 09:13:15 -0400 Received: by mail-pg0-f68.google.com with SMTP id e11-v6so2917800pgq.0 for ; Thu, 14 Jun 2018 06:13:15 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: 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> <20180509165321.3b2b1313fde0f007c1a5a015@linux-foundation.org> <9ef86114-02d6-b243-203d-fbbdab95a6fa@I-love.SAKURA.ne.jp> From: Dmitry Vyukov Date: Thu, 14 Jun 2018 15:12:53 +0200 Message-ID: Subject: Re: [PATCH] bfs: add sanity check at bfs_fill_super(). To: Tigran Aivazian Cc: Tetsuo Handa , Andrew Morton , linux-fsdevel , syzbot , syzkaller-bugs Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Jun 14, 2018 at 3:05 PM, Tigran Aivazian wrote: > On 14 June 2018 at 13:38, Dmitry Vyukov wrote: >> Consider, currently we can have a bfs image that works fine on one >> kernel, but fails to mount on another just because it happens so that >> one could allocate 4MB with kmalloc, but another can't (different >> allocator/different settings/different kernel revision). > > Yes, but this would only happen _without_ the validation proposed by > Tetsuo Handa. If we check s_start then the invalid enormous allocation > request will not be made and what you describe won't not happen. Agree. If we do a sanity check first, then __GFP_NOWARN is actually useful: it will detect the cases where a filesystem can be mounted on one machine but not on another (and will also double check that our sanity is really sane).