Re: [uml-devel] Host panic when UML reads host /dev/shm

[BlaisorBlade <blaisorblade_spam@yahoo.it>]

Alle 23:47, giovedì 20 novembre 2003, Frank Dekervel ha scritto:
> Op Thursday 20 November 2003 23:32, schreef Frank Dekervel:
> > > Only an oops on linux or the same oops? If the second, it's useful news
> >
> > the second ... exactly the same backtrace iirc. i'll try to find the
> > oops, but i'm almost sure. i've posted here to uml-devel once (subject
> > hostfs-crash i believe) but google cannot find it.
> >
> > > In fact, I'm seeing now 4:40, the time the oops happens, is when the
> > > slackware every day runs updatedb.
> >
> > a-ha ! exactly the same, my oops also happent when doing updatedb...
>
> my original post was here
> http://sourceforge.net/mailarchive/forum.php?thread_id=2984656&forum_id=364
>8
By the way, try the archive at http://marc.theaimsgroup.com/, it's commonly 
believed to be better than the sourceforge one... However don't worry, I 
found the post.
>
> but contrary to what i tought, it is not exactly the same oops.
There is also a filldir64 trace, or better EIP points into it. But then 
filldir64 should also appear in the trace.
>  Trace; c0149048 <sys_getdents+90/98>
>  Trace; c0139ea4 <sys_read+5c/100>
>  Trace; c01089f3 <system_call+33/38>
> if ksymoops is right. i also sent it to lkml, without response. And i was
> also using tmpfs then (for uml memory as described in howto)
I.e. your /tmp was under tmpfs? That may explain the fact that the oops is 
different.

However, I think the call trace is wrong, (below I explain why), so if you are 
able to reproduce the bug, this would be great.
Thanks!

However, I've looked at 2.4.22 sources, and either the related functions were 
almost rewritten, or the ksymoops output is bodged. sys_getdents doesn't call 
filldir64; it calls vfs_readdir(and this could actually be inlined, but it 
wouldn't get at the 90/98 position inside sys_getdents), but then it does a 
call to a readdir "method"(i.e. through a function pointer, so this can't be 
inlined and must appear in the trace) and then it does another call, which 
could be to filldir64, through a function pointer. You said maybe you didn't 
copy all the output of ksymoops, but the stack trace is never more than 3 
calls. I'll maybe check by disassembly if the output makes sense in that 
point, though this is not very meaningful if not done on the original vmlinux 
file.
-- 
cat <<EOSIGN
Paolo Giarrusso, aka Blaisorblade
Linux Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729
EOSIGN



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel