lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 27 Aug 2007 07:54:26 +0200
From:	Jarek Poplawski <jarkao2@...pl>
To:	Mariusz Kozlowski <m.kozlowski@...land.pl>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, netdev@...r.kernel.org,
	Jeff Garzik <jgarzik@...ox.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.23-rc3-mm1] request_irq fix DEBUG_SHIRQ handling Re: 2.6.23-rc2-mm1: rtl8139 inconsistent lock state

On Sat, Aug 25, 2007 at 11:43:08AM +0200, Mariusz Kozlowski wrote:
> > > =================================
> > > [ INFO: inconsistent lock state ]
> > > 2.6.23-rc2-mm1 #7
> > > ---------------------------------
> > > inconsistent {in-hardirq-W} -> {hardirq-on-W} usage.
> > > ifconfig/5492 [HC0[0]:SC0[0]:HE1:SE1] takes:
> > >  (&tp->lock){+...}, at: [<de8706e0>] rtl8139_interrupt+0x27/0x46b [8139too]
...
> I tested your patch and it still happens. Dmesg info from patched kernel attached.
> I coulnd't reproduce that on 2.6.23-rc3-mm1 - but on 2.6.23-rc2-mm2 it is easily
> reproducible.
> 
> If you need more info, test some patches, etc. - just mail me.
> 
...
> =========================================================
> [ INFO: possible irq lock inversion dependency detected ]
> 2.6.23-rc2-mm2 #2
> ---------------------------------------------------------
> runscript.sh/5065 just changed the state of lock:
>  (_xmit_ETHER){-+..}, at: [<c03cb659>] dev_watchdog+0x17/0xcc
> but this lock took another, soft-irq-unsafe lock in the past:
>  (&tp->lock){--..}
> 
> and interrupts could create inverse lock ordering between them.

It's OK! These're 2 different warnings. As a matter of fact, my patch
wasn't supposed to fix any of them, but something similar to the first
one, which was possible, but for some reason wasn't reported by
lockdep.

The first warning was fixed by Andrew Morton's patch to free_irq(),
so it shouldn't happen in -rc3-mm. The second warning could have been
fixed too, I don't know, but since it's quite long, I would prefer to
think about it only if it still happens in current -mm's.

Thanks,
Jarek P.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ