[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190410043135.GX2217@ZenIV.linux.org.uk>
Date: Wed, 10 Apr 2019 05:31:35 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Eric Biggers <ebiggers@...nel.org>
Cc: linux-fscrypt@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [PATCH] fscrypt: cache decrypted symlink target in ->i_link
On Tue, Apr 09, 2019 at 09:04:15PM -0700, Eric Biggers wrote:
> > What's to stop you from doing just that right now? You'd need to take
> > care with barriers, but you'd need that anyway... As soon as ->i_link is set
> > you'll get no more ->get_link() on that sucker, using the cached value
> > from that point on. IDGI...
>
> 1.) The VFS won't know to drop of RCU-walk mode, so waiting an RCU grace period
> before freeing the symlink target becomes mandatory. (Which I'd like to do
> for fscrypt anyway, but doing it sanely appears to require implementing
> .destroy_inode() for ext4, f2fs, and ubifs. I hoped I could do non-RCU mode
> as a simpler first step.)
You might want to check those filesystems. All three you've mentioned *have*
->destroy_inode() already.
> 2.) The VFS won't know to use a read memory barrier when loading i_link.
> The VFS could issue one unconditionally, but it would be unnecessary for
> regular fast symlinks.
Not really. All we need on the read side is READ_ONCE(); it will supply
smp_read_barrier_depends() (which is a no-op except for alpha). On the
write side we need smp_store_release() to set ->i_link (in addition to
whatever serialization we want for actual calculation of the value to
be cached, of course).
Powered by blists - more mailing lists