Pending patches

[Rob Landley]

On Friday 31 October 2008 04:29:54 Denys Vlasenko wrote:
> On Friday 31 October 2008 03:57, Rob Landley wrote:
> > Ok, when you said "free loop devices", I thought you meant "losetup -d".
> > You're talking about unmounting loop devices, which is a standard
> > unmounting problem.
>
> Ok, an example where I don't even mount a loopdevice,
> but still can't remount my root RO as long
> as loopdevice eixsts:

Yup, losetup associating the file with the loop device node pins the device, 
just like any other process having an open file in the filesystem would.

> > There's a umount -a in there already, which was there in busybox 1.2.  If
> > the busybox umount -a isn't unmounting everything properly, that's a
> > separate bug.
>
> What "umount -r -a" should do if remounting RO fails? "losetup -d"
> every possible loopdevice and retry?

This is really a kernel issue.  (I do note the existence of umount -f, but 
that's probably not something you want to do on /.)  Ask the kernel guys.  
Being unable to remount / read only seems like a bug to me, no matter what 
the reason.

> > Note that mounts are process context these days, so if you kill all
> > proccesses except PID 1, it should naturally reference count those
> > per-process mounts down to zero and free them, which just leaves the PID
> > 1 mounts that umount -a should be able to get.
>
> In the case we are using per-process mounts, yes,
> killing processes helps with umount.

Just having _files_ open prevents umounting a mount without -f:

sudo /bin/bash
mkdir walrus
mount -t ramfs walrus walrus
touch walrus/walrus
sleep 999 < walrus/walrus
umount walrus

A process has a file open in it.  The filesystem is pinned until the process 
closes that file, unless you want to force the unmount (so the file starts 
getting a -ESOMETHINGOROTHER).

(Having a process with its current working directory in that filesystem also 
pins it.)

> > Note that if you try to do this from a process _other_ than PID 1, or
> > without having killed all the other processes on the system, then you're
> > not guaranteed to have umounted every active filesystem.
>
> We do it not from process 1 but from it's children anyway.
> Not much difference.

So instead of signaling PID 1 to do the work, you signal PID 1 to stop 
respawning processes and have some other script do it.  Hoping that script 
isn't in a chroot, hoping that script isn't running in a process context with 
per process mounts...

> > See the bit about about some resources being per-processes, so you have
> > to kill all the processes other than PID 1 in order to make sure the
> > reference counts of those resources drop to zero and the system can be
> > quiesced?
>
> Yes, I have to kill all processes. killall5 does that nicely.

killall5 can't kill PID 1, and if your non-init process doesn't kill itself 
then you didn't kill all processes.

PID 1 is the only process that can ever be the only process on the system.  By 
definition.  Therefore, unless PID 1 is quiescing the system you have two 
sets of per-process resources to free.

> --
> vda

Rob