Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp4244983ybl; Tue, 20 Aug 2019 09:02:57 -0700 (PDT) X-Google-Smtp-Source: APXvYqyKM1qqeIBPMXu3uWN1QVu+6yNs9GvmPn/Iz61ioyKxq8SanGDPKkJRg5RkVsrAFMAK0Lej X-Received: by 2002:a17:90a:bb89:: with SMTP id v9mr753899pjr.88.1566316976834; Tue, 20 Aug 2019 09:02:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566316976; cv=none; d=google.com; s=arc-20160816; b=qbZHNvmWA5kNw6/xLuelY4H3bogv5a0lmH2D/j3vBS9xlye63Ecj7pPFW1etEX8TiO Xydv1ikpItrGURStqDDgHFyE+GfmaxMHMfF3vL5MBT0GB7PvN5OQSO8dXm3EikG+76zO 2J/fmLH9zHQ7VuSnQbClqjLsqvWVdADh8IltZK3T/DXlKh+BEHV2O3xtG5hCN2ElcN51 xukLV0qN0dIh5ml/ZvlF0Rj9EDwiSGqhIwBamLvv5EC4STVGWQwHvSxppzcVaPhG/3fF LHEDdIuVvC7r+Q3LIdFsz/oi3o6gze1qI6V/oV1dvBDD/whB4wIecJ1IP+NxPtIRtNE2 JseQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date; bh=ks/I3vsSMKIpiXY2budnXnoVBxFkBWhcnK1LSEJRDt4=; b=fHp5IMT24ej4xAGV1lLArlKwkOXvG+669SMjbaiuI5OWwjejSgJHNawUXFgnj9+T+W B1JULvMLkEzsIgp+zlPieFF9IATaV7IDN2nPocJiR6e6Webk+f7QTGqrGBj4eXQp9x1+ MfAb1uaEXpNT5H1wdkktsS4JYuj5nFmnABdqF54Rr0PjkBViZ26MIlw50y3yAartdv7z PJb4/3XxUHilx8lxDrIFF0xyioMfzhBDg1j51rlfWdKty35KKgLUEsP2CW+FIVcIqH/r iQUD6mJ+uhZI4/lwoTc/3PYI0mVRkic2Ak52vK35BGOzeGle8qvzMepyeKDLzBh8pRzO TPKA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 186si13254079pfd.44.2019.08.20.09.02.34; Tue, 20 Aug 2019 09:02:56 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730211AbfHTQAR (ORCPT + 99 others); Tue, 20 Aug 2019 12:00:17 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:42188 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727006AbfHTQAR (ORCPT ); Tue, 20 Aug 2019 12:00:17 -0400 Received: from callcc.thunk.org (wsip-184-188-36-2.sd.sd.cox.net [184.188.36.2]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7KFx2Xh012879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Aug 2019 11:59:06 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 4037D420843; Tue, 20 Aug 2019 11:56:23 -0400 (EDT) Date: Tue, 20 Aug 2019 11:56:23 -0400 From: "Theodore Y. Ts'o" To: Chao Yu Cc: Qu Wenruo , Gao Xiang , "Darrick J. Wong" , Christoph Hellwig , Eric Biggers , Richard Weinberger , Greg Kroah-Hartman , Jan Kara , Dave Chinner , David Sterba , Miao Xie , devel , Stephen Rothwell , Amir Goldstein , linux-erofs , Al Viro , Jaegeuk Kim , linux-kernel , Li Guifu , Fang Wei , Pavel Machek , linux-fsdevel , Andrew Morton , torvalds Subject: Re: [PATCH] erofs: move erofs out of staging Message-ID: <20190820155623.GA10232@mit.edu> Mail-Followup-To: "Theodore Y. Ts'o" , Chao Yu , Qu Wenruo , Gao Xiang , "Darrick J. Wong" , Christoph Hellwig , Eric Biggers , Richard Weinberger , Greg Kroah-Hartman , Jan Kara , Dave Chinner , David Sterba , Miao Xie , devel , Stephen Rothwell , Amir Goldstein , linux-erofs , Al Viro , Jaegeuk Kim , linux-kernel , Li Guifu , Fang Wei , Pavel Machek , linux-fsdevel , Andrew Morton , torvalds References: <20190818161638.GE1118@sol.localdomain> <20190818162201.GA16269@infradead.org> <20190818172938.GA14413@sol.localdomain> <20190818174702.GA17633@infradead.org> <20190818181654.GA1617@hsiangkao-HP-ZHAN-66-Pro-G1> <20190818201405.GA27398@hsiangkao-HP-ZHAN-66-Pro-G1> <20190819160923.GG15198@magnolia> <20190819203051.GA10075@hsiangkao-HP-ZHAN-66-Pro-G1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 20, 2019 at 10:24:11AM +0800, Chao Yu wrote: > Out of curiosity, it looks like every mainstream filesystem has its own > fuzz/injection tool in their tool-set, if it's really such a generic > requirement, why shouldn't there be a common tool to handle that, let specified > filesystem fill the tool's callback to seek a node/block and supported fields > can be fuzzed in inode. It can help to avoid redundant work whenever Linux > welcomes a new filesystem.... The reason why there needs to be at least some file system specific code for fuzz testing is because for efficiency's sake, you don't want to fuzz every single bit in the file system, but just the ones which are most interesting (e.g., the metadata blocks). For file systems which use checksum to protect against accidental corruption, the file system fuzzer needs to also fix up the checksums (since you can be sure malicious attackers will do this). What you *can* do is to make the file system specific portion of the work as small as possible. Great work in this area is Professor Kim's Janus[1][2] and Hydra[2] work. (Hydra is about to be published at SOSP 19, and was partially funded from a Google Faculty Research Work.) [1] https://taesoo.kim/pubs/2019/xu:janus.pdf [2] https://github.com/sslab-gatech/janus [3] https://github.com/sslab-gatech/hydra > > Personally speaking, debugging tool is way more important than a running > > kernel module/fuse. > > It's human trying to write the code, most of time is spent educating > > code readers, thus debugging tool is way more important than dead cold code. I personally find that having a tool like e2fsprogs' debugfs program to be really handy. It's useful for creating regression test images; it's useful for debugging results from fuzzing systems like Janus; it's useful for examining broken file systems extracted from busted Android handsets during dogfood to root cause bugs which escaped xfstests testing; etc. Cheers, - Ted