[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1521204767.20126.123.camel@infradead.org>
Date: Fri, 16 Mar 2018 12:52:47 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Joakim Tjernlund <Joakim.Tjernlund@...inera.com>,
"yuyufen@...wei.com" <yuyufen@...wei.com>
Cc: "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>
Subject: Re: [PATCH] jffs2: remove fd from the f->dents list immediately.
On Fri, 2018-03-16 at 12:39 +0000, Joakim Tjernlund wrote:
>
> > After reverting the commit, we test 'rm -r', which can remove all
> > files, and all seems OK!
>
> UHH, this is mine (and Davids work from 2007)!
> I cannot remember any details this long afterwards but I guess you cannot just
> revert that part as it triggers some other bug, David?
Right, the issue was with f_pos in the directory.
The 'rm' we were testing with at the time would delete a bunch of
directory entries, then continue with its readdir() to work out what
else to delete. But when we were handling f_pos on directories merely
as the position on the list, and when we were *deleting* things from
that list as we went, some dirents ended up moving so that they were
*before* the position that 'rm' had got to with its readdir().
But... the list we're traversing is *already* ordered by CRC, and that
could be a much saner thing to use as f_pos. We just have to make sure
we cope with hash collisions. Shifting left by 4 bits and using the low
4 bits would allow us to cope with 16 names with the same hash... but
I'm not sure that's good enough.
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)
Powered by blists - more mailing lists