linux-kernel - Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

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]

Date:	Tue, 18 Dec 2007 11:50:59 +0900
From:	Tejun Heo <htejun@...il.com>
To:	shyam_iyer@...l.com
CC:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

Hello,

shyam_iyer@...l.com wrote:
> --- sata_nv.c.orig	2007-12-17 21:08:12.000000000 +0530
> +++ sata_nv.c	2007-12-17 21:08:25.000000000 +0530
> @@ -2407,6 +2407,12 @@
>  			type = GENERIC;
>  	}
>  
> +	/* set 64bit dma masks, may fail */
> +	if (type == ADMA) {
> +		if (pci_set_dma_mask(pdev, DMA_64BIT_MASK) == 0)
> +			pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
> +	}
> +
>  	ppi[0] = &nv_port_info[type];
>  	rc = ata_pci_prepare_sff_host(pdev, ppi, &host);
>  	if (rc)
> @@ -2418,12 +2424,6 @@
>  	hpriv->type = type;
>  	host->private_data = hpriv;
>  
> -	/* set 64bit dma masks, may fail */
> -	if (type == ADMA) {
> -		if (pci_set_dma_mask(pdev, DMA_64BIT_MASK) == 0)
> -			pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
> -	}
> -

This is weird.  IIRC, the problem is caused by allocating consistent
memory for legacy DMA over 32bit limit.  Your patch moves setting 64bit
DMA mask upward but it doesn't affect anything because
ata_pci_prepare_sff_host() and hpriv allocation are not DMA memory
allocations and thus unaffected by DMA mask.

Robert's last patch seems correct to me.  I have no idea why it doesn't
work for you tho.  Another interesting point is that you are reporting
data corruption instead of time out or HSM violation, which indicates
that the PRD table is accessible but what it contains is incorrect.

I guess it's time to print out some memory addresses.  I'll prep a debug
patch soon.

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/