Re: mount_checkdirs

[Taylor R Campbell]

   Date: Mon, 6 Jul 2015 09:58:59 +
   From: David Holland 

   My inclination is that it is wrong, and if we care about not starting
   lookups in the middle of mount stacks that the logic should moved to
   namei; and if we don't, it should just be removed. Thoughts?

Doing it in namei sounds reasonable to me.  But first we should try to
cook up some test cases that distinguish the different behaviour, or
sketch a proof that we can't.  Some tests to exercise possible races
in mount/fork/*at over the cwd might be worth writing.

Re: Improving use of rt_refcnt

[David Young]

On Sun, Jul 05, 2015 at 11:50:12AM +0200, Joerg Sonnenberger wrote:
> I think the main point that David wanted to raise is that the normal
> path for packets should *not* do any ref count changes at all.

I wasn't trying to make a point.  I wanted to make sure that I properly
understood Ryota's plans.

Dave

-- 
David Young
dyo...@pobox.comUrbana, IL(217) 721-9981

mount_checkdirs

[David Holland]

It has been brought to my attention that the logic in
mount_checkdirs() both (a) races with fork and (b) is probably
compromised by the *at() syscalls.

The purpose of the code is to update all processes' current dirs and
root dirs that have just been mounted over, so nobody ends up sitting
on an intermediate vnode in the middle of a mount stack.

However, in fork we first copy the parent's cwd structure and then
assign the copy, during which time the copy is invisible to
mount_checkdirs; so in theory some process's current dir (or root dir,
too) could be skipped.

Also, since you can't chdir (even fchdir) to the middle of a mount
stack, this logic was sufficient to avoid using the middle of a mount
stack as the starting point for a path lookup, even if someone had an
fd open. But the *at() system calls break this invariant wide open.

So the question is: does it matter? Do we actually care? It seems to
me that no great harm arises (other than perhaps some confusion) if
one is sitting in the middle of a mount stack, and in fact it might
even be desirable if the mount stack is a union mount.

Also it's occasionally useful to mount over things and leave a process
underneath, which this logic seems to complicate.

The logic was added to 4.4 by Kirk McKusick but without much in the
way of rationale:
https://svnweb.freebsd.org/csrg/sys/kern/vfs_syscalls.c?revision=67974&view=markup

My inclination is that it is wrong, and if we care about not starting
lookups in the middle of mount stacks that the logic should moved to
namei; and if we don't, it should just be removed. Thoughts?

-- 
David A. Holland
dholl...@netbsd.org