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=-7.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable 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 07CF5C3A59D for ; Tue, 20 Aug 2019 16:00:19 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 557EB2070B for ; Tue, 20 Aug 2019 16:00:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 557EB2070B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=mit.edu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-erofs-bounces+linux-erofs=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 46Cb9D2HltzDrNV for ; Wed, 21 Aug 2019 02:00:16 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=mit.edu (client-ip=18.9.28.11; helo=outgoing.mit.edu; envelope-from=tytso@mit.edu; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=mit.edu Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 46Cb8s46RDzDrG2 for ; Wed, 21 Aug 2019 01:59:56 +1000 (AEST) 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 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) X-BeenThere: linux-erofs@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development of Linux EROFS file system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jan Kara , Amir Goldstein , Dave Chinner , linux-kernel , Miao Xie , devel , Christoph Hellwig , "Darrick J. Wong" , Richard Weinberger , Qu Wenruo , Eric Biggers , torvalds , Stephen Rothwell , Al Viro , Jaegeuk Kim , Pavel Machek , David Sterba , Greg Kroah-Hartman , linux-fsdevel , Andrew Morton , linux-erofs Errors-To: linux-erofs-bounces+linux-erofs=archiver.kernel.org@lists.ozlabs.org Sender: "Linux-erofs" 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