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:	Fri, 27 Jun 2008 02:41:01 -0400
From:	Jeff Garzik <jgarzik@...ox.com>
To:	Pavel Machek <pavel@...e.cz>
CC:	Tejun Heo <tj@...nel.org>, Andreas Schwab <schwab@...e.de>,
	kernel list <linux-kernel@...r.kernel.org>,
	benh@...nel.crashing.org,
	IDE/ATA development list <linux-ide@...r.kernel.org>,
	Trivial patch monkey <trivial@...nel.org>
Subject: Re: sata_svw data corruption, strange problems

Pavel Machek wrote:
> Clarify comment in sata_svw.c.
> 
> Signed-off-by: Pavel Machek <pavel@...e.cz>
> 
> diff --git a/drivers/ata/sata_svw.c b/drivers/ata/sata_svw.c
> index 16aa683..fb13b82 100644
> --- a/drivers/ata/sata_svw.c
> +++ b/drivers/ata/sata_svw.c
> @@ -253,21 +253,29 @@ static void k2_bmdma_start_mmio(struct a
>  	/* start host DMA transaction */
>  	dmactl = readb(mmio + ATA_DMA_CMD);
>  	writeb(dmactl | ATA_DMA_START, mmio + ATA_DMA_CMD);
> -	/* There is a race condition in certain SATA controllers that can
> -	   be seen when the r/w command is given to the controller before the
> -	   host DMA is started. On a Read command, the controller would initiate
> -	   the command to the drive even before it sees the DMA start. When there
> -	   are very fast drives connected to the controller, or when the data request
> -	   hits in the drive cache, there is the possibility that the drive returns a part
> -	   or all of the requested data to the controller before the DMA start is issued.
> -	   In this case, the controller would become confused as to what to do with the data.
> -	   In the worst case when all the data is returned back to the controller, the
> -	   controller could hang. In other cases it could return partial data returning
> -	   in data corruption. This problem has been seen in PPC systems and can also appear
> -	   on an system with very fast disks, where the SATA controller is sitting behind a
> -	   number of bridges, and hence there is significant latency between the r/w command
> -	   and the start command. */
> -	/* issue r/w command if the access is to ATA*/
> +	/* This works around possible data corruption.
> +
> +	   On certain SATA controllers that can be seen when the r/w
> +	   command is given to the controller before the host DMA is
> +	   started.
> +
> +	   On a Read command, the controller would initiate the
> +	   command to the drive even before it sees the DMA
> +	   start. When there are very fast drives connected to the
> +	   controller, or when the data request hits in the drive
> +	   cache, there is the possibility that the drive returns a
> +	   part or all of the requested data to the controller before
> +	   the DMA start is issued.  In this case, the controller
> +	   would become confused as to what to do with the data.  In
> +	   the worst case when all the data is returned back to the
> +	   controller, the controller could hang. In other cases it
> +	   could return partial data returning in data
> +	   corruption. This problem has been seen in PPC systems and
> +	   can also appear on an system with very fast disks, where
> +	   the SATA controller is sitting behind a number of bridges,
> +	   and hence there is significant latency between the r/w
> +	   command and the start command. */
> +	/* issue r/w command if the access is to ATA */
>  	if (qc->tf.protocol == ATA_PROT_DMA)
>  		ap->ops->sff_exec_command(ap, &qc->tf);
>  }
> 
> 

applied

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ