On Sat, Sep 21, 2019 at 09:21:46AM -0700, Linus Torvalds wrote:
> On Sat, Sep 21, 2019 at 7:07 AM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> >
> > FWIW, #next.dcache has the straight conversion to hlist. It definitely
> > wants at least nfsd, er... misconception dealt with, though: list_head
> > or hlist, this
>
> Well, yeah. But is there really any downside except for the warning?
>
> Looks like the code should just do
>
> if (!simple_positive(dentry))
> continue;
>
> and just ignore non-positive dentries - whether cursors or negative
> ones (which may not happen, but still).
FWIW, I really want to do a unified helper for "rm -rf from kernel"
kind of thing. We have too many places trying to do that and buggering
it up in all kinds of ways. This is one of those places; I agree
that the first step is to get rid of that WARN_ONCE, and it's the
right thing to do so that two series would be independent, but it
will need attention afterwards.
> > No "take cursors out of the list" parts yet.
>
> Looking at the commits, that "take it off the list" one seems very
> nice on its own. It actually seems to simplify the logic regardless of
> the whole "don't need to add it to the end"..
>
> Only this:
>
> if (next)
> list_move_tail(&cursor->d_child, &next->d_child);
> else
> list_del_init(&cursor->d_child);
>
> is a slight complication, and honestly, I think that should just have
> its own helper function there ("dcache_update_cursor(cursor, next)" or
> something).
I want to see what will fall out of switching cursors to separate
type - the set of primitives, calling conventions for those, etc.
will become more clear once I have something to tweak. And I would
rather use here the calling conventions identical to the final ones...
> That helper function would end up meaning one less change in the hlist
> conversion too.
>
> The hlist conversion looks straightforward except for the list_move()
> conversions that I didn't then look at more to make sure that they are
> identical, but the ones I looked at looked sane.
BTW, how much is the cost of smp_store_release() affected by a recent
smp_store_release() on the same CPU? IOW, if we have
smp_store_release(p, v1);
<some assignments into the same cacheline>
r = *q; // different cacheline
smp_store_release(q, v2);
how much overhead will the second smp_store_release() give?
