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.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 63130C3A589 for ; Sun, 18 Aug 2019 16:22:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 365B5206DF for ; Sun, 18 Aug 2019 16:22:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="LM+w7i3N" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726478AbfHRQWR (ORCPT ); Sun, 18 Aug 2019 12:22:17 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:35550 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726115AbfHRQWQ (ORCPT ); Sun, 18 Aug 2019 12:22:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=N0aKd3kbobOVM+ja2qXPqQEy6PJXskjZ3fNW6CYKznA=; b=LM+w7i3N+Q7emAXcFs7q/xvtc LwYBK72c0UsD7+mZtVDq2ehkyG8sRdB/QM4oWWhXa7TvYK4mNCXln2gua/Hr0suUTXsMyHjeABY4B LfiObpOBKlFJIUXS5IcHU0+lAfxM9IFPNXLfwQjCjurgwPar/NOd7sJsEnxmJpZoy2nj1QMUCxgkE hibZO4GddXdRUF+BvG5lHCrttPsXkdjjbdBA4RSbWYLE5JJ8vHitpoCCKzfp2k6sZ4KOGLjyF29zh OtL1O2BwpaLQGyhTKkFrbt4yyOfDRQOTEqdXKt22YCxIxcuJJl7M6aoMf9gW9nxwtL3eY9xOl0rKO lyHSgKIYQ==; Received: from hch by bombadil.infradead.org with local (Exim 4.92 #3 (Red Hat Linux)) id 1hzNwP-0005So-3L; Sun, 18 Aug 2019 16:22:01 +0000 Date: Sun, 18 Aug 2019 09:22:01 -0700 From: Christoph Hellwig To: Christoph Hellwig , "Theodore Y. Ts'o" , Richard Weinberger , Greg Kroah-Hartman , Gao Xiang , Jan Kara , Chao Yu , Dave Chinner , David Sterba , Miao Xie , devel , Stephen Rothwell , Darrick , 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: <20190818162201.GA16269@infradead.org> References: <1163995781.68824.1566084358245.JavaMail.zimbra@nod.at> <20190817233843.GA16991@hsiangkao-HP-ZHAN-66-Pro-G1> <1405781266.69008.1566116210649.JavaMail.zimbra@nod.at> <20190818084521.GA17909@hsiangkao-HP-ZHAN-66-Pro-G1> <1133002215.69049.1566119033047.JavaMail.zimbra@nod.at> <20190818090949.GA30276@kroah.com> <790210571.69061.1566120073465.JavaMail.zimbra@nod.at> <20190818151154.GA32157@mit.edu> <20190818155812.GB13230@infradead.org> <20190818161638.GE1118@sol.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190818161638.GE1118@sol.localdomain> User-Agent: Mutt/1.11.4 (2019-03-13) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Sun, Aug 18, 2019 at 09:16:38AM -0700, Eric Biggers wrote: > Ted's observation was about maliciously-crafted filesystems, though, so > integrity-only features such as metadata checksums are irrelevant. Also the > filesystem version is irrelevant; anything accepted by the kernel code (even if I think allowing users to mount file systems (any of ours) without privilege is a rather bad idea. But that doesn't mean we should not be as robust as we can. Optionally disabling support for legacy formats at compile and/or runtime is something we should actively look into as well. > it's legacy/deprecated) is open attack surface. > > I personally consider it *mandatory* that we deal with this stuff. But I can > understand that we don't do a good job at it, so we shouldn't hold a new > filesystem to an unfairly high standard relative to other filesystems... I very much disagree. We can't really force anyone to fix up old file systems. But we can very much hold new ones to (slightly) higher standards. Thats the only way to get the average quality up. Some as for things like code style - we can't magically fix up all old stuff, but we can and usually do hold new code to higher standards. (Often not to standards as high as I'd personally prefer, btw).