Hello!

I've applied your patch and thankfully the bug was triggered on the
next shutdown (after I had installed the new kernel on the first
workstation).

Andrew Morton schrieb:
> It's interesting that this only happens during shutdown: something may be
> racing against an unmount.

I doubt that. It appears that the bug is triggered somewhere in this
sequence:

K10arpwatch@
K10fbset@
K10powersaved@
K10running-kernel@
K10sshd@
K10update-client@

i.e. after (during) arpwatch shutdown, and before update-client is
run. The latter is an administration script which performs some
lengthy operations on mounted filesystems (fetch updates for packages
and configuration files from a central location).

> I'd suggest that you run with the below patch which, if it's right, will
> display the offending path and will then pause for ten seconds.  If we can
> identify which filesystem type that path lives on then perhaps we can make
> some progress.

Dec  2 17:03:11 kermit arpwatch: exiting
Dec  2 17:03:12 kermit sshd[4564]: Received signal 15; terminating.
Dec  2 17:03:12 kermit kernel: __d_path: skipping NULL vfsmnt
Dec  2 17:03:22 kermit kernel: path: `'
Dec  2 17:03:22 kermit kernel: device eth0 left promiscuous mode

I bet an empty string isn't quite helpful here, or is it?

I'm not quite sure how to proceed now. I'd like to try out 2.6.10rc2
as Alan Cox proposed + maybe we could get some more useful information
out of __d_path

Kind regards
     FDF
--
Friedrich Delgado Friedrichs (IT-Services), DFN-CERT Services GmbH
https://www.dfn-cert.de, +49 40 808077-555 (Hotline)
12. DFN-CERT Workshop und Tutorien, CCH Hamburg, 2-3. Maerz 2005