Re: [PATCH] [5/6] Handle TIF_RESTORE_SIGMASK for i386

[Andrew Morton <akpm@osdl.org>]

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/