On Mon, Feb 29, 2016 at 5:09 AM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
> The more I look at the situation with d_is_...() wrt barriers and ->d_seq,
> the less I understand it; outside of RCU mode we don't really need the
> barriers for that stuff and in RCU mode ->d_flags handling had been
> a serious headache all along...
Yeah, one of my least favorite "recent" vfs improvements.
> I'm tempted to do as below .. [ changing it to be unde the seqlock ]
>
> David, Linus, do you see any problems with that? To me it looks saner
> that way and as cheap as the current code, but I might be missing something
> here...
I'd absolutely love to see this. The memory ordering for the flags
updates and reading was always really confusing, and I hated how it
was hidden inside the random access functions. And apparently it
wasn't just confusing, it was buggy too.
But I'd love it _more_ if this also means that we can get rid of the
rmb's, which your patch didn't. Can we? Or does the ordering still
remain for some other issue?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
