Thread (45 messages) 45 messages, 7 authors, 2019-07-19

Re: [PATCH v9 05/10] namei: O_BENEATH-style path resolution flags

From: Al Viro <viro@zeniv.linux.org.uk>
Date: 2019-07-13 02:42:24
Also in: linux-alpha, linux-api, linux-arch, linux-arm-kernel, linux-fsdevel, linux-kselftest, linux-mips, linux-s390, linux-sh, lkml, sparclinux

On Fri, Jul 12, 2019 at 04:00:26PM +0100, Al Viro wrote:
On Fri, Jul 12, 2019 at 02:25:53PM +0100, Al Viro wrote:
quoted
	if (flags & LOOKUP_BENEATH) {
		nd->root = nd->path;
		if (!(flags & LOOKUP_RCU))
			path_get(&nd->root);
		else
			nd->root_seq = nd->seq;
BTW, this assignment is needed for LOOKUP_RCU case.  Without it
you are pretty much guaranteed that lazy pathwalk will fail,
when it comes to complete_walk().

Speaking of which, what would happen if LOOKUP_ROOT/LOOKUP_BENEATH
combination would someday get passed?
I don't understand what's going on with ->r_seq in there - your
call of path_is_under() is after having (re-)sampled rename_lock,
but if that was the only .. in there, who's going to recheck
the value?  For that matter, what's to guarantee that the thing
won't get moved just as you are returning from handle_dots()?

IOW, what does LOOKUP_IN_ROOT guarantee for caller (openat2())?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help