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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E7ED8C001DC for ; Fri, 21 Jul 2023 01:03:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229570AbjGUBDi (ORCPT ); Thu, 20 Jul 2023 21:03:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42468 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229452AbjGUBDi (ORCPT ); Thu, 20 Jul 2023 21:03:38 -0400 Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 44EE5E75; Thu, 20 Jul 2023 18:03:36 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E369A5C00F4; Thu, 20 Jul 2023 21:03:32 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Thu, 20 Jul 2023 21:03:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1689901412; x=1689987812; bh=R4ZNGlYIzZjqT Kdh2uUCCHfXsCMNde46ZsMLHyedF/I=; b=X26iwK3gCgmCENMCp/fW1ETWcUzEN 9rwLuq4E33Zo0dhDnC7nZvOCLnw3oA8kr5MhSLJ14LNMtTJlvQdeKciQl4R51mU5 OjD/BSnJTKaA3e102aHkf3HKi/xD/nWE1sQP9GaWV0hJhSKdElBPI77oiLieA6/0 oUKi90TVMJ92HpZCZ4gDOHLzl4q9Llaqfl1yiulga84go00d47fg1yFWgL8XpwSU uykfbLG4c3SPEQHR2Ok/FuAN8NS7ns+9n9zY3uJDEugcaSMXhmiarDaaTGrpc/zk 6qmwkuQde+Fbb2VlewWSj5CSduAOjRvxdeh1f1dw/dXeSZewpMzlPx0ZQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrhedugdegtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefujgfkfhggtgesthdtredttddtvdenucfhrhhomhephfhinhhnucfv hhgrihhnuceofhhthhgrihhnsehlihhnuhigqdhmieekkhdrohhrgheqnecuggftrfgrth htvghrnhepleeuheelheekgfeuvedtveetjeekhfffkeeffffftdfgjeevkeegfedvueeh ueelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepfh hthhgrihhnsehlihhnuhigqdhmieekkhdrohhrgh X-ME-Proxy: Feedback-ID: i58a146ae:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 20 Jul 2023 21:03:28 -0400 (EDT) Date: Fri, 21 Jul 2023 11:03:28 +1000 (AEST) From: Finn Thain To: Dave Chinner cc: Jeff Layton , Matthew Wilcox , John Paul Adrian Glaubitz , Dmitry Vyukov , Viacheslav Dubeyko , Arnd Bergmann , Linus Torvalds , syzbot , Andrew Morton , christian.brauner@ubuntu.com, Damien Le Moal , Linux FS Devel , LKML , syzkaller-bugs@googlegroups.com, ZhangPeng , linux-m68k@lists.linux-m68k.org, debian-ports Subject: Re: [syzbot] [hfs?] WARNING in hfs_write_inode In-Reply-To: Message-ID: <60b57ae9-ff49-de1d-d40d-172c9e6d43d5@linux-m68k.org> References: <2575F983-D170-4B79-A6BA-912D4ED2CC73@dubeyko.com> <46F233BB-E587-4F2B-AA62-898EB46C9DCE@dubeyko.com> <50D6A66B-D994-48F4-9EBA-360E57A37BBE@dubeyko.com> <2d0bd58fb757e7771d13f82050a546ec5f7be8de.camel@physik.fu-berlin.de> <868611d7f222a19127783cc8d5f2af2e42ee24e4.camel@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Fri, 21 Jul 2023, Dave Chinner wrote: > > I suspect that this is one of those catch-22 situations: distros are > > going to enable every feature under the sun. That doesn't mean that > > anyone is actually _using_ them these days. I think the value of filesystem code is not just a question of how often it gets executed -- it's also about retaining access to the data collected in archives, museums, galleries etc. that is inevitably held in old formats. > > We need to much more proactive about dropping support for unmaintained > filesystems that nobody is ever fixing despite the constant stream of > corruption- and deadlock- related bugs reported against them. > IMO, a stream of bug reports is not a reason to remove code (it's a reason to revert some commits). Anyway, that stream of bugs presumably flows from the unstable kernel API, which is inherently high-maintenance. It seems that a stable API could be more appropriate for any filesystem for which the on-disk format is fixed (by old media, by unmaintained FLOSS implementations or abandoned proprietary implementations). Being in userspace, I suppose FUSE could be a stable API though I imagine it's not ideal in the sense that migrating kernel code there would be difficult. Maybe userspace NFS 4 would be a better fit? (I've no idea, I'm out of my depth in /fs...) Ideally, kernel-to-userspace code migration would be done with automatic program transformation -- otherwise it would become another stream of bugs.