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;
Date:   Mon, 7 May 2018 03:15:54 +0100
From:   Al Viro <viro@ZenIV.linux.org.uk>
To:     John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc:     Martin Steigerwald <martin@lichtvoll.de>,
        Matthew Wilcox <willy@infradead.org>, dsterba@suse.cz,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        Jens Axboe <axboe@kernel.dk>, linux-m68k@lists.linux-m68k.org,
        Debian m68k <debian-68k@lists.debian.org>
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>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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...