On Tue, Dec 8, 2015 at 9:32 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
> Any help with review and testing would be welcome. FWIW, it seems to survive
> the beating here.
It looks ok to me, but I *hate* that "cookie" thing we have. And I
don't actually see any reason for it.
Every single user except for a couple seem to just put the resulting
symlink address into the cookie (and then put_link() will kfree it or
put_page() it). And the calling convention would be *so* much clearer
if we just made things be
char *get_link(dentry, inode);
put_link(dentry, inode, char *);
and get rid of that cookie entirely.
The only users of the cookie seem to be
- we currently use it for the page pointer vs the page data address.
That's because of the HIGHMEM crap that you removed. Without
highmem, the page data address specifies the page fine without any
cookie.
- overlayfs, which uses it to create a temporary data storage.
Why? Mainly because it wants to hide the cookie in there. D'oh!
- proc, which uses it to save the proc_dir_entry
Why? The reason seems to be that we don't call put_link() with the
dentry that get_link got, so it can't look it up the sane way.
In other words, as far as I can tell, the cookie is just garbage now.
But maybe I missed something.
Other than that, I like the series. And I realize that technically the
"cookie removal" would be a separate thing, but since you're changing
the calling convention from "follow_link()" to "get_link()" in this
series, I _really_ think that as part of that calling convention
change we should just get rid of the cookie, rather than have
*another* calling convention change later.
Hmm?
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
