linux-kernel - Re: [PATCH RFC] libata: FUA updates

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:	Wed, 21 Feb 2007 16:57:54 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Robert Hancock <hancockr@...w.ca>
CC:	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-ide@...r.kernel.org, Jeff Garzik <jeff@...zik.org>
Subject: Re: [PATCH RFC] libata: FUA updates

Robert Hancock wrote:
> This updates libata FUA support to be more more in line with reality.
> FUA support remains off by default.
> 
> Add a setting for the fua command-line parameter on libata which enables
> FUA only on NCQ-supporting disks.
> 
> Update the ata_dev_supports_fua function to remove the blacklisting of
> Maxtor BANC1G10 firmware, as there is no conclusive evidence it was ever
> needed.
> 
> Centralize all of the FUA on/off decisions in this function.
> 
> Bypass the checks for FUA command support bit for NCQ disks, since that
> bit only applies to non-NCQ FUA, and FUA is part of the spec for NCQ
> commands.
> 
> When queue depth is set by the user resulting in enabling/disabling
> NCQ, trigger a revalidate so that the FUA state will be rechecked,
> since disabling/enabling NCQ may also affect FUA support on some disks.
> 
> Add a controller flag to indicate it doesn't support FUA commands, and
> set this flag for Silicon Image 311x (since that one is known to have
> problems) as well as for ITE821x when in smart mode.
> 
> Signed-off-by: Robert Hancock <hancockr@...w.ca>

Yeap, I like the clean up.  Just a few comments.

* s/if(/if (/

* The patch adds a number of trailing white spaces.  I suggest using git
or quilt for patch management.  They complain when they see such things.

I'm still not so sure about NCQ FUA.  I still think that separate opcode
for FUA ops is the right thing to do (tm), well, or the safer thing to
do (tm).  Regarding drives which support NCQ but not separate opcode for
FUA, unless many drives are like that, I don't think the loss is too
great.  Also, I'm more uncomfortable with trusting those drives doing
NCQ FUA properly.

Let's talk about this on the other thread.

Thanks.

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