From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B645CC33C8C for ; Mon, 6 Jan 2020 15:45:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9270520672 for ; Mon, 6 Jan 2020 15:45:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726677AbgAFPpr (ORCPT ); Mon, 6 Jan 2020 10:45:47 -0500 Received: from mx2.suse.de ([195.135.220.15]:37174 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726448AbgAFPpr (ORCPT ); Mon, 6 Jan 2020 10:45:47 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id C9B28ACC9; Mon, 6 Jan 2020 15:45:45 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id BC0ACDA78B; Mon, 6 Jan 2020 16:45:35 +0100 (CET) Date: Mon, 6 Jan 2020 16:45:34 +0100 From: David Sterba To: Qu Wenruo Cc: dsterba@suse.cz, Qu Wenruo , linux-btrfs@vger.kernel.org Subject: Re: [PATCH 0/6] btrfs-progs: Fixes for github issues Message-ID: <20200106154534.GJ3929@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Qu Wenruo , Qu Wenruo , linux-btrfs@vger.kernel.org References: <20191218011942.9830-1-wqu@suse.com> <20200102171056.GM3929@twin.jikos.cz> <20200103152719.GZ3929@twin.jikos.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Sat, Jan 04, 2020 at 09:26:25AM +0800, Qu Wenruo wrote: > > > On 2020/1/3 下午11:27, David Sterba wrote: > > On Fri, Jan 03, 2020 at 08:43:01AM +0800, Qu Wenruo wrote: > >> > >> > >> On 2020/1/3 上午1:10, David Sterba wrote: > >>> On Wed, Dec 18, 2019 at 09:19:36AM +0800, Qu Wenruo wrote: > >>>> There are a new batch of fuzzed images for btrfs-progs. They are all > >>>> reported by Ruud van Asseldonk from github. > >>>> > >>>> Patch 1 will make QA life easier by remove the extra 300s wait time. > >>>> Patch 2~5 are all the meat for the fuzzed images. > >>>> > >>>> Just a kind reminder, mkfs/020 test will fail due to tons of problems: > >>>> - Undefined $csum variable > >>>> - Undefined $dev1 variable > >>> > >>> These are fixed in devel now. > >>> > >>>> - Bad kernel probe for support csum > >>>> E.g. if Blake2 not compiled, it still shows up in supported csum algo, > >>>> but will fail to mount. > >>> > >>> The list of supported is from the point of view of the filesystem. > >>> Providing the module is up to the user. > >> > >> IIRC, doing such probe at btrfs module load time would be more user > >> friendly though. > > > > I don't understand how you think this could be improved. The list of > > algorithms is provided by the filesystem, the implementations are > > provided by the crypto subsystem (either compiled in or as modules). Two > > different things. > > > > So you mean that at btrfs module load time, all hash algorithms are > > probed? > > Yes, that's why I mean. > > > What if some of them gets unloaded, or loaded later (so modprobe > > won't see it at btrfs load time). This would require keeping the state > > up to date and this is out of scope what filesystem should do. > > > Isn't there any mechanism to load the module when necessary? Yes, that's what we rely on, once a filesystem is mounted it will instantiate the crypto shash, that in turn will trigger module load if necessary. Probing all algorithms would load more modules than needed, for the only reason to store/print list of what succeeded at that time. Whatever happens to the system later will not be reflected here. And that's why I don't want to do that, so we list checksums understood by btrfs module.