linux-kernel - Re: Storage related regression in linux-next 20120824

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 09 Sep 2012 16:28:19 -0400
From:	Jeff Garzik <jgarzik@...ox.com>
To:	Arvydas Sidorenko <asido4@...il.com>
CC:	Hugh Dickins <hughd@...gle.com>, Zheng Liu <wenqing.lz@...bao.com>,
	linux-kernel@...r.kernel.org,
	IDE/ATA development list <linux-ide@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Storage related regression in linux-next 20120824

On 09/09/2012 04:11 PM, Arvydas Sidorenko wrote:
>> I think you know your way around SCSI/libata much better than I do.
>>
>> I just bisected linux-next, and it comes down to the commit below, which
>> introduces the regression for me, and I'm guessing for you also.  Maybe
>> it can be fixed up to satisfy us, but otherwise will have to be reverted:
>> we don't invert a default if it's going to break older working systems.
>>
>> A good workaround for me meanwhile is to add boot option "libata.fua=0":
>> please try that (or reverting the commit) and let us know the result.
>>
>> Thanks,
>> Hugh
>>
>> commit 91895b786e631ab47b618c901231f22b5a44115b
>> Author: Zheng Liu <wenqing.lz@...bao.com>
>> Date:   Tue May 8 11:24:03 2012 +0800
>>
>>      libata: enable SATA disk fua detection on default
>>
>>      Currently, SATA disk fua detection is disabled on default because most of
>>      devices don't support this feature at that time.  With the development of
>>      technology, more and more SATA disks support this feature.  So now we can enable
>>      this detection on default.
>>
>>      Although fua detection is defined as a kernel module parameter, it is too hard
>>      to set its value because it must be loaded and set before system starts up.
>>      That needs to modify initrd file.  So it is inconvenient for administrator who
>>      needs to manage a huge number of servers.
>>
>>      Signed-off-by: Zheng Liu <wenqing.lz@...bao.com>
>>      Signed-off-by: Jeff Garzik <jgarzik@...hat.com>
>>
>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
>> index 5eee1c1..c3fbdca 100644
>> --- a/drivers/ata/libata-core.c
>> +++ b/drivers/ata/libata-core.c
>> @@ -135,9 +135,9 @@ int atapi_passthru16 = 1;
>>   module_param(atapi_passthru16, int, 0444);
>>   MODULE_PARM_DESC(atapi_passthru16, "Enable ATA_16 passthru for ATAPI devices (0=off, 1=on [default])");
>>
>> -int libata_fua = 0;
>> +int libata_fua = 1;
>>   module_param_named(fua, libata_fua, int, 0444);
>> -MODULE_PARM_DESC(fua, "FUA support (0=off [default], 1=on)");
>> +MODULE_PARM_DESC(fua, "FUA support (0=off, 1=on [default])");
>>
>>   static int ata_ignore_hpa;
>>   module_param_named(ignore_hpa, ata_ignore_hpa, int, 0644);
>
> Indeed, disabling FUA explicitly solved the issue on my disk as well.
> Hugh, what hard drive you have this issue on?
>
> I believe there are two solutions:
> - Revert FUA default back to '0'
> - Start filling SATA drive blacklist in function:

I think the right thing to do for release is disable it (again), then we 
can try again later with better logic.

I'll send Linus a patch to disable.

It is entirely possible that this is a software problem, where we 
missing some detail turning on FUA (thereby engaging some less traveled 
core block layer machinery), or even a remote possibility of triggering 
a filesystem bug.

	Jeff





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