Re: [PATCH] libata: fix DMA to stack in reading devslp_timing parameters

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2013-03-29 at 11:54 +0000, David Woodhouse wrote:
> Commit 803739d25c2343da6d2f95eebdcbc08bf67097d4 ("[libata] replace
> sata_settings with devslp_timing"), which was also Cc: stable, used a
> stack buffer to receive data from ata_read_log_page()...

That commit also changes from using ata_id_has_ncq() to
ata_id_has_devslp() as the condition for reading the SATA settings log
page (log 0x30 page 0x08), because of compatibility issues with some
drives which *do* implement NCQ but not DEVSLP.

It's not entirely clear to me that this change was correct. Even if the
drive does support DEVSLP, the timings in the SATA settings log page are
optional, and we're supposed to use default values if they are not
provided. I can imagine some DEVSLP-capable drives not having that page
either.

Shouldn't we be reading page zero of the 0x30 log, which *is* mandatory,
and looking there to see which pages are supported?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@xxxxxxxxx                              Intel Corporation

Attachment: smime.p7s
Description: S/MIME cryptographic signature


[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux