lkml.org 
[lkml]   [2006]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] [5/6] Handle TIF_RESTORE_SIGMASK for i386
David Woodhouse <dwmw2@infradead.org> wrote:
>
> On Thu, 2006-01-12 at 19:59 -0800, Andrew Morton wrote:
> > applied, or with all of David's patches applied, an FC5-test1 machine hangs
> > during the login process (local vt or sshd). An FC1 machine doesn't
> > exhibit the problem.
>
> So the 'successful' login reported at 19:21:45 never actually completed
> and gave you a shell?

Yup.

> I can't make out which process it is that's misbehaving... and your
> login was pid 2292 but I don't see your SysRq-T output going up that
> far. Am I missing something?

Yes, that dmesg output seems to have been truncated.

Here's another one, better:

http://www.zip.com.au/~akpm/linux/patches/stuff/dmesg

Note that I have /bin/zsh in /etc/passwd.

> I note you're running auditd -- FC5-test1 enabled syscall auditing by
> default.

This is basically the fc5-t1 .config, only it has selinux turned off due to
earlier problems. Suggest you base testing on my config-sony.

> Does the problem persist if you prevent the auditd initscript
> from starting up?

<chkconfig auditd off>
<reboot>
<problem persists>

> If so, let's turn auditing back on

<chkconfig auditd on>

> and actually make
> use of it -- assuming the offending process is actually one of your own
> after the login has changed uid, can you set an audit rule to log all
> syscalls from your own userid? (add '-Aexit,always -Fuid=500'
> to /etc/audit.rules, assuming 500 is your own uid). Then show me the
> appropriate section from /var/log/audit/audit.log.

<does that>
<reboots>
<logs in>

You wouldn't believe how much stuff that produces. Or maybe you would.

<several minutes pass, disk LED flashing>

<crap starts scrolling past too fast to read. Some complaint from auditd, afaict>

<does alt-SUB>

<grabs the last bit of auditd.log>

http://www.zip.com.au/~akpm/linux/patches/stuff/auditd.log

That looks like the crap I saw scrolling past. How come it came out on the
console after a few minutes?

> I tested both with and without audit on PPC -- David, did you test this
> patch with auditing enabled on i386?
>
> Will attempt to reproduce locally... I've _also_ seen login hangs on
> current linus trees but they've been different (and on that machine I
> haven't had the TIF_RESTORE_SIGMASK patches either). It happens on disk
> activity though -- after 'rpm -i <kernelpackage>' the whole machine
> locks up and I have no more file system access. If your SysRq-T got to
> the disk, I suspect you aren't seeing the same problem.

Sounds like the jens-barrier-bug. Fixed in current -linus.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-01-13 05:58    [W:0.090 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site