linux-kernel - Re: HDD problem, software bug, bios bug, or hardware ?

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20547.48101.900727.735398@pilspetsen.it.uu.se>
Date:	Sun, 2 Sep 2012 22:04:53 +0200
From:	Mikael Pettersson <mikpe@...uu.se>
To:	Adko Branil <adkobranil@...oo.com>
Cc:	Borislav Petkov <bp@...en8.de>, Jeff Garzik <jgarzik@...ox.com>,
	Mikael Pettersson <mikpe@...uu.se>,
	linux-ide <linux-ide@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: HDD problem, software bug, bios bug, or hardware ?

Adko Branil writes:
 > >Right near the end there's a lockdep warning about a deadlock
 > 
 > >between sata_promise's hardreset thing and the machine getting a
 > >ata_bmdma_interrupt.
 > 
 > >But since I don't know this code, it would be nice if you could take a
 > >look at it.
 > 
 > I picked up 3 more dmesg after rebooting, and 2 more oopses.
 >  I will put here just pieces from dmesgs about these locks, they differs slightly each-other:
 > 
 > ***********************************************************************************
 > 1.
 > 
 > 
 > [    1.859215] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input1
 > [    1.943678] 
 > [    1.943679] =================================
 > [    1.943680] [ INFO: inconsistent lock state ]
 > [    1.943682] 3.5.2 #4 Not tainted
 > [    1.943683] ---------------------------------
 > [    1.943684] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
 > [    1.943686] swapper/1/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
 > [    1.943687]  (&(&host->lock)->rlock){?.+...}, at: [<ffffffff818f4e47>] ata_bmdma_interrupt+0x27/0x1d0
 > [    1.943695] {HARDIRQ-ON-W} state was registered at:
 > [    1.943696]   [<ffffffff810998fb>] __lock_acquire+0x61b/0x1af0
 > [    1.943701]   [<ffffffff8109b31a>] lock_acquire+0x8a/0x110
 > [    1.943703]   [<ffffffff81b4d051>] _raw_spin_lock+0x31/0x40
 > [    1.943708]   [<ffffffff8190b3c5>] pdc_sata_hardreset+0x85/0x100
 > [    1.943711]   [<ffffffff818eabba>] ata_do_reset+0x3a/0x90
 > [    1.943713]   [<ffffffff818edd72>] ata_eh_reset+0x372/0xe00
 > [    1.943716]   [<ffffffff818eec25>] ata_eh_recover+0x2a5/0x13d0
 > [    1.943718]   [<ffffffff818f073d>] ata_do_eh+0x4d/0xb0
 > [    1.943721]   [<ffffffff818f33ba>] ata_sff_error_handler+0xca/0x120
 > [    1.943723]   [<ffffffff8190a9e4>] pdc_error_handler+0x24/0x30
 > [    1.943725]   [<ffffffff818f029c>] ata_scsi_port_error_handler+0x47c/0x800
 > [    1.943728]   [<ffffffff818f06be>] ata_scsi_error+0x9e/0xd0
 > [    1.943730]   [<ffffffff816732e8>] scsi_error_handler+0xf8/0x500
 > [    1.943734]   [<ffffffff810654fe>] kthread+0xae/0xc0
 > [    1.943737]   [<ffffffff81b4f5f4>] kernel_thread_helper+0x4/0x10
 > [    1.943740] irq event stamp: 51304
 > [    1.943741] hardirqs last  enabled at (51301): [<ffffffff8100ab7d>] default_idle+0x5d/0x1b0
 > [    1.943745] hardirqs last disabled at (51302): [<ffffffff81b4da67>] common_interrupt+0x67/0x6c
 > [    1.943748] softirqs last  enabled at (51304): [<ffffffff810498d3>] _local_bh_enable+0x13/0x20
 > [    1.943752] softirqs last disabled at (51303): [<ffffffff8104a355>] irq_enter+0x75/0x90
 > [    1.943754] 
 > [    1.943754] other info that might help us debug this:
 > [    1.943755]  Possible unsafe locking scenario:
 > [    1.943755] 
 > [    1.943755]        CPU0
 > [    1.943755]        ----
 > [    1.943756]   lock(&(&host->lock)->rlock);
 > [    1.943757]   <Interrupt>
 > [    1.943758]     lock(&(&host->lock)->rlock);

I was initially able to reproduce the lockdep warning, and wrote
a crude test patch, but now I can't seem to reproduce the warning
with or without that patch, so I'm not sure what to make of it.

pdc_hard_reset_port needs to serialize because hard reset has to flip
a port-specific bit in a controller register that's shared by all ports,
so it takes the host lock. But now an interrupt occurs during the hard
reset, and pdc_interrupt also has to take the host lock. (I don't know
why the interrupt occurs, hotplug events are supposed to have been masked
by ->freeze before ->hardreset. It might come from a different device,
my test machine has multiple ATA controllers from different vendors,
and some of them do share IRQ.)

Jeff: ->hardreset is called with the host lock NOT held, right?

I think I'll have to introduce a new private lock just for serializing
pdc_hard_reset_port. Expect a patch next weekend (I'll be away from
my Promise test equipment until then.)

/Mikael
--
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/