From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zeniv.linux.org.uk ([195.92.253.2]:51230 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751831AbeEGCQG (ORCPT ); Sun, 6 May 2018 22:16:06 -0400 Date: Mon, 7 May 2018 03:15:54 +0100 From: Al Viro To: John Paul Adrian Glaubitz Cc: Martin Steigerwald , Matthew Wilcox , dsterba@suse.cz, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Jens Axboe , linux-m68k@lists.linux-m68k.org, Debian m68k Subject: Re: moving affs + RDB partition support to staging? Message-ID: <20180507021554.GN30522@ZenIV.linux.org.uk> References: <20180425154602.GA8546@bombadil.infradead.org> <20180425203029.GQ21272@twin.jikos.cz> <20180426025717.GA32430@bombadil.infradead.org> <1613268.lKBQxPXt8J@merkaba> <76ca15e2-7b43-8b02-43e1-9ee65ab85356@physik.fu-berlin.de> <20180506005946.GI30522@ZenIV.linux.org.uk> <20180506073955.GJ30522@ZenIV.linux.org.uk> <20180506204622.GL30522@ZenIV.linux.org.uk> <20180506213247.GM30522@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180506213247.GM30522@ZenIV.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, May 06, 2018 at 10:32:47PM +0100, Al Viro wrote: > On Sun, May 06, 2018 at 09:46:23PM +0100, Al Viro wrote: > > > I'm fixing that pile of crap (along with the NFS exports > > one and, hopefully, rename mess as well). HOWEVER, I am not going > > to take over the damn thing - David has violated the 11th > > commandment (Thou Shalt Never Volunteer), so he gets to joy of > > learning that codebase and taking care of it from now on. > > Same scenario on link(2) ends up with > * ST_LINKFILE created, inserted into the link chain and left around, > without being present in any hash chain > * target becoming positive hashed dentry, as if link(2) has succeeded, > so dcache lookups will be finding it (for a while) > * unlink(2) on source will have very interesting effects, what with > the attempts to move ST_FILE entry into the directory presumed to > contain ST_LINKFILE one, removing ST_LINKFILE from it at the same time. Oh, lovely... Looks like that thing wants the hash chains sorted by block number. affs_insert_hash() doesn't give a toss - it always adds to the very end of chain. Maintaining that requirement (and I can understand the rationale - they don't want too many back-and-forth seeks on directory lookups) is going to be great fun on rename(), especially for the case when the target of rename happens to be a primary name for a file with additional hardlinks. I think I see how to deal with that sanely, but... ouch. Incidentally, we'd better verify that hash chains are not looped - as it is, there's no checks whatsoever, and it *will* happily loop if you feed it an image with such braindamage. I really hope that no fan of desktop experience has set the things up for e.g. USB sticks with that on them being recognized and automounted on insertion...