In mount_checkdirs you can find a loop:
mutex_enter(proc_lock);
PROCLIST_FOREACH(p, &allproc) {
if ((cwdi = p->p_cwdi) == NULL)
continue;
if (cwdi->cwdi_cdir != olddp &&
cwdi->cwdi_rdir != olddp)
continue;
> My inclination is that it is wrong [...]
It looks strange to me, but that doesn't tell much.
Could it have been added as a quick fix for the behaviour of some (then)
standard daemon or the like?
> The logic was added to 4.4 by Kirk McKusick but without much in the
> way of rationale:
Perhaps th
On Jul 9, 12:27am, Rhialto wrote:
} On Mon 06 Jul 2015 at 09:58:59 +, David Holland wrote:
}
} > Also it's occasionally useful to mount over things and leave a process
} > underneath, which this logic seems to complicate.
}
} If I read the code correctly, it looks for processes that have a cu
immediately.
What I saw in practice with an "ls" after point 4 was "ls: fts_read:
operation not permitted" so there is some detail that prevents the exact
scenario that I tried. But it doesn't seem to be in mount_checkdirs().
It could be something /bin/sh does.
-Olaf.
-
On Mon 06 Jul 2015 at 09:58:59 +, David Holland wrote:
> Also it's occasionally useful to mount over things and leave a process
> underneath, which this logic seems to complicate.
If I read the code correctly, it looks for processes that have a current
working directory or root directory exac
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
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
