Re: [PATCH] CRED: Further fix execve error handling

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

On Wed, 20 Aug 2008 18:21:59 +0400
"Alexander Beregalov" <a.beregalov@gmail.com> wrote:

> 2008/8/20 David Howells <dhowells@redhat.com>:
> > Further fix [compat_]do_execve() error handling.  free_bprm() will release the
> > cred_exec_mutex, but only if bprm->cred is not NULL.
> >
> > Signed-off-by: David Howells <dhowells@redhat.com>
> 
> David, I applied this patch and got the following.
> Is it a different problem?
> I think it is. If yes I will create another topic.
> 
> [   91.266507] [ INFO: possible recursive locking detected ]
> [   91.266862] 2.6.27-rc3-next-20080820-dirty #3

Looks like a false trip of the lock debugging code. I've seen the same
and having dumped the values in tty_do_resize plus the entry/exit paths
it seems to be bogus.

> [   91.267170] ---------------------------------------------
> [   91.267522] sshd/1455 is trying to acquire lock:
> [   91.267840]  (&tty->termios_mutex){--..}, at: [<00000000005b8ca0>]
> tty_do_resize+0x44/0x128
> [   91.268405]
> [   91.268411] but task is already holding lock:
> [   91.268885]  (&tty->termios_mutex){--..}, at: [<00000000005b8c74>]
> tty_do_resize+0x18/0x128

Note that the lock is only acquired in one place in this code and that
the second lock is only take if the two locks differ. Also the second
lock take is not &tty->termios_mutex at all but real_tty.

So I'd say either broken compiler or broken lock debug tools but hey I
could be wrong ;)

Alan