initrd: couldn't umount

initrd: couldn't umount

[Daniel Wagner]

hi.

we try to setup an initrd for diskless nodes, which allows us a
modular kernelconfiguration (especially the net-drivers). it work
quite well, but ...

the problem is that a "rpciod" kernel-thread references the initrd,
and so umounting and freeing it, isn't possible.

has anybody an idea how to fix this problem, cause it would be nice,
to free the initrd ram on a diskless node.

this is what comes after processing the initrd:

---
Looking up port of RPC 100003/2 on 192.168.162.201
Looking up port of RPC 100005/1 on 192.168.162.201
VFS: Mounted root (NFS filesystem).
change_root: old root has d_count=3
Mounted devfs on /dev
Trying to unmount old root ... <3>error -16
Change root to /initrd: error -2
Freeing unused kernel memory: 56k
freed                                                                                                    
---

Regards,
  Daniel

-- 
Daniel Wagner                      | mailto:daniel@xss.co.at
*x Software + Systeme              | http://www.xss.co.at/
Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
A-1100 Vienna, Austria             | Fax: +43-1-6060114-71

Re: initrd: couldn't umount

[Alan Cox]

> the problem is that a "rpciod" kernel-thread references the initrd,
> and so umounting and freeing it, isn't possible.
> 
> has anybody an idea how to fix this problem, cause it would be nice,
> to free the initrd ram on a diskless node.

It shouldnt be keeping a reference. daemonize() should have dropped its
resources

Re: initrd: couldn't umount

[Daniel Wagner]

Alan Cox wrote:
> 
> > the problem is that a "rpciod" kernel-thread references the initrd,
> > and so umounting and freeing it, isn't possible.
> >
> > has anybody an idea how to fix this problem, cause it would be nice,
> > to free the initrd ram on a diskless node.
> 
> It shouldnt be keeping a reference. daemonize() should have dropped its
> resources

hmm, i've now created a /initrd directory to let the the change_root of
the
initrd work correctly.

and then i looked with fuser, what processes reference the initrd:

---
root@ws4:~ $ fuser -mv /initrd/
 
                     USER        PID ACCESS COMMAND
/initrd/             root         67 .rc.. 
rpciod                                                                                         
---

only the rpciod references the initrd, none of the other
kernel-threads.

Regards,
  Daniel

-- 
Daniel Wagner                      | mailto:daniel@xss.co.at
*x Software + Systeme              | http://www.xss.co.at/
Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
A-1100 Vienna, Austria             | Fax: +43-1-6060114-71

Re: initrd: couldn't umount

[Andreas Haumer]

Hi!

Daniel Wagner wrote:
> 
> Alan Cox wrote:
> >
> > > the problem is that a "rpciod" kernel-thread references the initrd,
> > > and so umounting and freeing it, isn't possible.
> > >
> > > has anybody an idea how to fix this problem, cause it would be nice,
> > > to free the initrd ram on a diskless node.
> >
> > It shouldnt be keeping a reference. daemonize() should have dropped its
> > resources
> 
> hmm, i've now created a /initrd directory to let the the change_root of
> the
> initrd work correctly.
> 
> and then i looked with fuser, what processes reference the initrd:
> 
> ---
> root@ws4:~ $ fuser -mv /initrd/
> 
>                      USER        PID ACCESS COMMAND
> /initrd/             root         67 .rc..
> rpciod
> ---
> 
> only the rpciod references the initrd, none of the other
> kernel-threads.
> 
Could it be because, when executed, rpciod() calls 
exit_files(current) and exit_mm(current), but doesn't
call exit_fs(current) (as, for instance, md_thread() does)? 
(we are talking 2.2.19 here)

We well try it in a few minutes... :-)

- andreas

-- 
Andreas Haumer                     | mailto:andreas@xss.co.at
*x Software + Systeme              | http://www.xss.co.at/
Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
A-1100 Vienna, Austria             | Fax: +43-1-6060114-71

Re: initrd: couldn't umount

[Andreas Haumer]

Hi!

(added okir@monad.swb.de to CC: list, as he is listed in the 
header of linux/net/sunrpc/sched.c as author of this file)

To answer my own question... ;-)

Andreas Haumer wrote:
> 
> Hi!
> 
> Daniel Wagner wrote:
> >
> > Alan Cox wrote:
[...]
> > > It shouldnt be keeping a reference. daemonize() should have dropped its
> > > resources
> >
> > hmm, i've now created a /initrd directory to let the the change_root of
> > the
> > initrd work correctly.
> >
> > and then i looked with fuser, what processes reference the initrd:
> >
> > ---
> > root@ws4:~ $ fuser -mv /initrd/
> >
> >                      USER        PID ACCESS COMMAND
> > /initrd/             root         67 .rc..
> > rpciod
> > ---
> >
> > only the rpciod references the initrd, none of the other
> > kernel-threads.
> >
> Could it be because, when executed, rpciod() calls
> exit_files(current) and exit_mm(current), but doesn't
> call exit_fs(current) (as, for instance, md_thread() does)?
> (we are talking 2.2.19 here)
> 
Yes, an additional call to exit_fs(current) when initializing
the rpciod thread solves this problem without creating other 
(obvious) problems (as it seems after a short test).

The inital ramdisk can now be unmounted cleanly even in case
of NFS root

The suggested patch is:

andreas@ws1:~/cvsdir {625} % cvs diff -C5 -rR_2-2-19~11 -rR_2-2-19~12
linux/net/sunrpc/sched.c
Index: linux/net/sunrpc/sched.c
===================================================================
RCS file:
/raid5/cvs/repository/distribution/Base/linux/net/sunrpc/sched.c,v
retrieving revision 1.1.1.6
retrieving revision 1.12
diff -C5 -r1.1.1.6 -r1.12
*** linux/net/sunrpc/sched.c    2001/03/25 16:37:42     1.1.1.6
--- linux/net/sunrpc/sched.c    2001/08/17 11:53:48     1.12
***************
*** 1066,1075 ****
--- 1066,1076 ----
        rpciod_pid = current->pid;
        up(&rpciod_running);
 
        exit_files(current);
        exit_mm(current);
+       exit_fs(current);
 
        spin_lock_irq(&current->sigmask_lock);
        siginitsetinv(&current->blocked, sigmask(SIGKILL));
        recalc_sigpending(current);
        spin_unlock_irq(&current->sigmask_lock); 


Alan, would you consider adding this patch to 2.2.20?

Thanks!

- andreas

-- 
Andreas Haumer                     | mailto:andreas@xss.co.at
*x Software + Systeme              | http://www.xss.co.at/
Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
A-1100 Vienna, Austria             | Fax: +43-1-6060114-71