Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Crash Utility (http://www.linux-archive.org/crash-utility/)
-   -   mount cmd crashes crash (http://www.linux-archive.org/crash-utility/414961-mount-cmd-crashes-crash.html)

Bob Montgomery 08-18-2010 08:41 PM

mount cmd crashes crash
 
I'm working on a dump of a system that did not have a PID 1. I don't
think it's relevant to the crash itself, but it does cause crash get
a seg fault.

crash> ps | head
PID PPID CPU TASK ST %MEM VSZ RSS COMM
0 0 0 ffffffff805144c0 RU 0.0 0 0 [swapper]
0 -1 1 ffff81012bc0a100 RU 0.0 0 0 [swapper]
2 -1 0 ffff81012bd3c040 IN 0.0 0 0 [migration/0]
3 -1 0 ffff81012bd3e7c0 RU 0.0 0 0 [ksoftirqd/0]
4 -1 0 ffff81012bd3e080 IN 0.0 0 0 [watchdog/0]
5 -1 1 ffff81012bd3f800 IN 0.0 0 0 [migration/1]
6 -1 1 ffff81012bd3f0c0 RU 0.0 0 0 [ksoftirqd/1]
7 -1 1 ffff81012bc0a840 IN 0.0 0 0 [watchdog/1]
8 -1 0 ffff81012af02880 IN 0.0 0 0 [events/0]
crash> mount
Segmentation fault (core dumped)

In cmd_mount, this returns null and subsequent use causes the seg fault:

1156
1157 namespace_context = pid_to_context(1);

I don't know if it was important to have the context of pid 1 for
reporting mounts, or just any context, but this hack makes the problem
go away, although not a very efficient way to find the lowest existing
PID above 0.

--- filesys.c.orig 2010-08-18 14:03:26.000000000 -0600
+++ filesys.c 2010-08-18 14:10:02.000000000 -0600
@@ -1153,8 +1153,12 @@ cmd_mount(void)
ulong vfsmount = 0;
int flags = 0;
int save_next;
+ ulong pid;

- namespace_context = pid_to_context(1);
+ /* find a context */
+ pid = 1;
+ while ((namespace_context = pid_to_context(pid)) == NULL)
+ pid++;

while ((c = getopt(argcnt, args, "ifn:")) != EOF) {
switch(c)

Bob Montgomery
At HP




--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Dave Anderson 08-18-2010 08:57 PM

mount cmd crashes crash
 
----- "Bob Montgomery" <bob.montgomery@hp.com> wrote:

> I'm working on a dump of a system that did not have a PID 1. I don't
> think it's relevant to the crash itself, but it does cause crash get
> a seg fault.
>
> crash> ps | head
> PID PPID CPU TASK ST %MEM VSZ RSS COMM
> 0 0 0 ffffffff805144c0 RU 0.0 0 0 [swapper]
> 0 -1 1 ffff81012bc0a100 RU 0.0 0 0 [swapper]
> 2 -1 0 ffff81012bd3c040 IN 0.0 0 0 [migration/0]
> 3 -1 0 ffff81012bd3e7c0 RU 0.0 0 0 [ksoftirqd/0]
> 4 -1 0 ffff81012bd3e080 IN 0.0 0 0 [watchdog/0]
> 5 -1 1 ffff81012bd3f800 IN 0.0 0 0 [migration/1]
> 6 -1 1 ffff81012bd3f0c0 RU 0.0 0 0 [ksoftirqd/1]
> 7 -1 1 ffff81012bc0a840 IN 0.0 0 0 [watchdog/1]
> 8 -1 0 ffff81012af02880 IN 0.0 0 0 [events/0]
> crash> mount
> Segmentation fault (core dumped)
>
> In cmd_mount, this returns null and subsequent use causes the seg fault:
>
> 1156
> 1157 namespace_context = pid_to_context(1);
>
> I don't know if it was important to have the context of pid 1 for
> reporting mounts, or just any context, but this hack makes the problem
> go away, although not a very efficient way to find the lowest existing
> PID above 0.

Yeah, it's not important to use the context of pid 1, but it just needs
some context, and I had presumed that init would always exist. I thought
that the panic("Attempted to kill the idle task!") in do_exit() would
prevent pid 1 from ever going away -- but apparently your kernel figured
out how to do it elsewhere... ;-)

Your patch would pick a kernel thread pid, and apparently everything still
works OK? That being the case, it's fine with me.

Thanks,
Dave


> --- filesys.c.orig 2010-08-18 14:03:26.000000000 -0600
> +++ filesys.c 2010-08-18 14:10:02.000000000 -0600
> @@ -1153,8 +1153,12 @@ cmd_mount(void)
> ulong vfsmount = 0;
> int flags = 0;
> int save_next;
> + ulong pid;
>
> - namespace_context = pid_to_context(1);
> + /* find a context */
> + pid = 1;
> + while ((namespace_context = pid_to_context(pid)) == NULL)
> + pid++;
>
> while ((c = getopt(argcnt, args, "ifn:")) != EOF) {
> switch(c)
>
> Bob Montgomery
> At HP
>
>
>
>
>
> --
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Bob Montgomery 08-18-2010 09:43 PM

mount cmd crashes crash
 
Sorry, forgot to reply all:
---------------------------

On Wed, 2010-08-18 at 20:57 +0000, Dave Anderson wrote:
> ----- "Bob Montgomery" <bob.montgomery@hp.com> wrote:
>
> > I'm working on a dump of a system that did not have a PID 1. I
don't
> > think it's relevant to the crash itself, but it does cause crash get
> > a seg fault.

> >
> > I don't know if it was important to have the context of pid 1 for
> > reporting mounts, or just any context, but this hack makes the
problem
> > go away, although not a very efficient way to find the lowest
existing
> > PID above 0.
>
> Yeah, it's not important to use the context of pid 1, but it just
needs
> some context, and I had presumed that init would always exist. I
thought
> that the panic("Attempted to kill the idle task!") in do_exit() would
> prevent pid 1 from ever going away -- but apparently your kernel
figured
> out how to do it elsewhere... ;-)

That test is for PID 0, not PID 1 (at least on the kernel I'm
debugging.) However, there is this also:

if (unlikely(tsk == child_reaper))
panic("Attempted to kill init!");

And child_reaper in the dump points to a task struct for init that isn't
in the ps listing. Hmmm. Maybe that part *is* interesting in this
dump...

>
> Your patch would pick a kernel thread pid, and apparently everything
still
> works OK? That being the case, it's fine with me.

With the patch, these commands all produce the same output:
crash-5.0.6-fix> mount >mount.out
crash-5.0.6-fix> mount -n 2 >mount2.out
crash-5.0.6-fix> mount -n 1459 >mount1459.out

I discovered the -n option as my first workaround.

Bob M.


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Dave Anderson 08-19-2010 12:45 PM

mount cmd crashes crash
 
----- "Bob Montgomery" <bob.montgomery@hp.com> wrote:

> Sorry, forgot to reply all:
> ---------------------------
>
> On Wed, 2010-08-18 at 20:57 +0000, Dave Anderson wrote:
> > ----- "Bob Montgomery" <bob.montgomery@hp.com> wrote:
> >
> > > I'm working on a dump of a system that did not have a PID 1. I don't
> > > think it's relevant to the crash itself, but it does cause crash get
> > > a seg fault.
>
> > >
> > > I don't know if it was important to have the context of pid 1 for
> > > reporting mounts, or just any context, but this hack makes the problem
> > > go away, although not a very efficient way to find the lowest existing
> > > PID above 0.
> >
> > Yeah, it's not important to use the context of pid 1, but it just needs
> > some context, and I had presumed that init would always exist. I thought
> > that the panic("Attempted to kill the idle task!") in do_exit() would
> > prevent pid 1 from ever going away -- but apparently your kernel figured
> > out how to do it elsewhere... ;-)
>
> That test is for PID 0, not PID 1 (at least on the kernel I'm
> debugging.) However, there is this also:
>
> if (unlikely(tsk == child_reaper))
> panic("Attempted to kill init!");

That's the one I *meant*... ;-)

>
> And child_reaper in the dump points to a task struct for init that isn't
> in the ps listing. Hmmm. Maybe that part *is* interesting in this dump...
>
> >
> > Your patch would pick a kernel thread pid, and apparently everything still
> > works OK? That being the case, it's fine with me.
>
> With the patch, these commands all produce the same output:
> crash-5.0.6-fix> mount >mount.out
> crash-5.0.6-fix> mount -n 2 >mount2.out
> crash-5.0.6-fix> mount -n 1459 >mount1459.out
>
> I discovered the -n option as my first workaround.

Actually, it looks like pid 0 could be used as well.

Anyway, queued for the next release.

Thanks,
Dave


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility


All times are GMT. The time now is 06:05 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.