linux-kernel - "scsi: convert host_busy to atomic_t" series causes regressions for some hardware configurations

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: <55DB4F5D.4070604@gmail.com>
Date:	Mon, 24 Aug 2015 19:07:41 +0200
From:	Sergio Callegari <sergio.callegari@...il.com>
To:	Christoph Hellwig <hch@...radead.org>
CC:	Borislav Petkov <bp@...en8.de>, linux-kernel@...r.kernel.org
Subject: "scsi: convert host_busy to atomic_t" series causes regressions for
 some hardware configurations

Thanks Christoph for the answer!

Apparently I missed a piece of the thread where the test patch was originally 
proposed . Now, I have gone through it and I see how the patch was not meant to 
be a final correction.

My (possibly naive) understanding is that:

- Even if this might be due to hardware that not fully conforms to the standard 
(but we do not know right now), commit 74665016086615bbaa3fa6f83af410a0a4e029ee 
( scsi: convert host_busy to atomic_t ) certainly breaks the kernel for some 
hardware configurations causing a regression.

- If the regression was immediately spotted, the patch would probably have been 
revised right after proposal. Unfortunately, another bug - that got fixed only 
much later with 045065d8a300a37218c - hid the original issue for a long time.

- Now that a lot of time has passed with the "scsi: convert host_busy to 
atomic_t" series in the kernel, going back to look into it is much more 
difficult. Libata people might not be very interested as they moved to other 
topics and might need a lot of time to go through it (it has been known since 
November 2014 - 9 months ago), possibly due to the race like nature of the issue 
and the fact that the bug might not be reproducible on their hardware...

Is this correct?

Aren't commits that cause regressions confirmed by multiple users expected (at 
least in principle) to be reverted?

If reverting is too costy, wouldn't your "papering over" or making the scsi 
delay configurable be an acceptable solution?

Even better: can in some way the libata-people be helped find the real culprit, 
given that there are at least two hardware setups that are known to trigger the 
regression (mine and Barto's)?

I have tried the linux-ide mailing list, but got silence.

Best,

Sergio



On 20/08/2015 10:08, Christoph Hellwig wrote:
> Hi Sergio,
>
> On Tue, Aug 18, 2015 at 09:44:28AM +0200, Sergio Callegari wrote:
>> Hi,
>>
>> I have bisected the issue down to
>>
>> [045065d8a300a37218c548e9aa7becd581c6a0e8] [SCSI] fix qemu boot hang problem
>>
>> Bisecting has been a painful job due to the fact that the bug may show only
>> many hours after the system boot.
>>
>> The commit above in fact is not the culprit, but a fix to an issue that was
>> hiding the real bug on my system.  See
>>
>> http://marc.info/?l=linux-kernel&m=143973820612978&w=2
>>
>> The real issue is with sata host lock and seems to be biting a few other
>> people as well
>>
>> https://bbs.archlinux.org/viewtopic.php?id=189324
>>
>> A patch fixing the issue was sent to the LKML back in Nov 2014 by Christoph
>> Hellwig (who is reading in CC)
>>
>> https://lkml.org/lkml/2014/11/20/581
>>
>> I have tested the patch and it works for me.
>>
>> What is expected to happen now?
> As mentioned in that thread we need more input from the libata people
> on what kind of race this is papering over.

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