lkml.org 
[lkml]   [2015]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCHSET v2] ->follow_link() without dropping from RCU mode
On Wed, Dec 09, 2015 at 06:23:09PM +0000, Al Viro wrote:

> What's more, that dentry might very well have gone negative by that
> point. Think what happens if, during the symlink traversal, we run
> into the hard "restart from scratch in non-RCU mode". We'll need to
> do ->put_link() on everything we have in stack. Regardless of what
> might've happened to dentries/inodes of symlinks involved - all we
> are really promised is that RCU-delayed parts of their destruction hadn't
> been entered yet.
>
> Note, BTW, that *all* ->put_link() instances ignore the inode argument
> and I seriously considered dropping it completely.

PS: I toyed with the idea of replacing cookie a struct callback_head, to make
it really obvious what's going on - we are leaving a closure to be evaluated
once the caller is done with our return value. That way ->put_link() as a
method would've been gone and we would've had something like
init_callback(destructor, page_put_link, page);
instead of
*cookie = page;
plus
.put_link = page_put_link,
we have right now, etc.

The reason not to go that way (and not all that strong, at that) is that
we get an extra pointer in struct saved, i.e. slightly heavier nameidata
(there are two struct saved embedded into it). That, or play silly buggers
with
union {
struct callback_head callback;
struct inode *inode;
};
in struct saved - we need to stash a pointer to inode between pick_link()
and get_link().

Hell knows, still might make sense to go there... What we want is to set
a closure to be evaluated once the caller of ->get_link() is done with
the string ->get_link() returns. We end up picking the function to be
called at saved->inode->i_op->put_link and store its argument in
saved->cookie. Might as well just use the representation we use for such
stuff (rcu_head, etc.) and be done with that...


\
 
 \ /
  Last update: 2015-12-10 01:21    [W:0.059 / U:2.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site