From: Al Viro <viro@ZenIV.linux.org.uk>
To: Nix <nix@esperi.org.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: NFS/lazy-umount/path-lookup-related panics at shutdown (at kill of processes on lazy-umounted filesystems) with 3.9.2 and 3.9.5
Date: Wed, 12 Jun 2013 02:23:04 +0100 [thread overview]
Message-ID: <20130612012304.GF4165@ZenIV.linux.org.uk> (raw)
In-Reply-To: <871u89vp46.fsf@spindle.srvr.nix>
On Mon, Jun 10, 2013 at 06:42:49PM +0100, Nix wrote:
> Yes, my shutdown scripts are panicking the kernel again! They're not
> causing filesystem corruption this time, but it's still fs-related.
>
> Here's the 3.9.5 panic, seen on an x86-32 NFS client using NFSv3: NFSv4
> was compiled in but not used. This happened when processes whose
> current directory was on one of those NFS-mounted filesystems were being
> killed, after it had been lazy-umounted (so by this point its cwd was in
> a disconnected mount point).
>
> [ 251.246800] BUG: unable to handle kernel NULL pointer dereference at 00000004
> [ 251.256556] IP: [<c01739f6>] path_init+0xc7/0x27f
> [ 251.256556] *pde = 00000000
> [ 251.256556] Oops: 0000 [#1]
> [ 251.256556] Pid: 748, comm: su Not tainted 3.9.5+ #1
> [ 251.256556] EIP: 0060:[<c01739f6>] EFLAGS: 00010246 CPU: 0
> [ 251.256556] EIP is at path_init+0xc7/0x27f
Apparently that's set_root_rcu() with current->fs being NULL. Which comes from
AF_UNIX connect done by some twisted call chain in context of hell knows what.
> [ 251.256556] [<c02ef8da>] ? unix_stream_connect+0xe1/0x2f7
> [ 251.256556] [<c026a14d>] ? kernel_connect+0x10/0x14
> [ 251.256556] [<c031ecb1>] ? xs_local_connect+0x108/0x181
> [ 251.256556] [<c031c83b>] ? xprt_connect+0xcd/0xd1
> [ 251.256556] [<c031fd1b>] ? __rpc_execute+0x5b/0x156
> [ 251.256556] [<c0128ac2>] ? wake_up_bit+0xb/0x19
> [ 251.256556] [<c031b83d>] ? rpc_run_task+0x55/0x5a
> [ 251.256556] [<c031b8bc>] ? rpc_call_sync+0x7a/0x8d
> [ 251.256556] [<c0325127>] ? rpcb_register_call+0x11/0x20
> [ 251.256556] [<c032548a>] ? rpcb_v4_register+0x87/0xf6
> [ 251.256556] [<c0321187>] ? svc_unregister.isra.22+0x46/0x87
> [ 251.256556] [<c03211d0>] ? svc_rpcb_cleanup+0x8/0x10
> [ 251.256556] [<c03213df>] ? svc_shutdown_net+0x18/0x1b
> [ 251.256556] [<c01cb1f3>] ? lockd_down+0x22/0x97
> [ 251.256556] [<c01c89df>] ? nlmclnt_done+0xc/0x14
> [ 251.256556] [<c01b9064>] ? nfs_free_server+0x7f/0xdb
> [ 251.256556] [<c016e776>] ? deactivate_locked_super+0x16/0x3e
> [ 251.256556] [<c0187e17>] ? free_fs_struct+0x13/0x20
> [ 251.256556] [<c011a009>] ? do_exit+0x224/0x64f
> [ 251.256556] [<c016d51f>] ? vfs_write+0x82/0x108
> [ 251.256556] [<c011a492>] ? do_group_exit+0x3a/0x65
> [ 251.256556] [<c011a4ce>] ? sys_exit_group+0x11/0x11
> [ 251.256556] [<c0332b3d>] ? syscall_call+0x7/0xb
Why is it done in essentially random process context, anyway? There's such thing
as chroot, after all, which would screw that sucker as hard as NULL ->fs, but in
a less visible way...
next prev parent reply other threads:[~2013-06-12 1:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-10 17:42 NFS/lazy-umount/path-lookup-related panics at shutdown (at kill of processes on lazy-umounted filesystems) with 3.9.2 and 3.9.5 Nix
2013-06-11 3:15 ` Al Viro
2013-06-11 11:11 ` Nix
2013-06-12 1:23 ` Al Viro [this message]
2013-06-12 12:08 ` Nix
2013-06-12 15:54 ` Al Viro
2013-06-12 21:27 ` Nix
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130612012304.GF4165@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=nix@esperi.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.