linux-kernel - Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

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]

Message-ID: <56424BF4.2040207@codeaurora.org>
Date:	Tue, 10 Nov 2015 14:56:36 -0500
From:	Sinan Kaya <okaya@...eaurora.org>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	Arnd Bergmann <arnd@...db.de>,
	linux-arm-kernel@...ts.infradead.org,
	Abhijit Mahajan <abhijit.mahajan@...gotech.com>,
	Nagalakshmi Nandigama <nagalakshmi.nandigama@...gotech.com>,
	linux-scsi@...r.kernel.org, jcm@...hat.com, timur@...eaurora.org,
	linux-kernel@...r.kernel.org,
	Sreekanth Reddy <sreekanth.reddy@...gotech.com>,
	Praveen Krishnamoorthy <praveen.krishnamoorthy@...gotech.com>,
	cov@...eaurora.org, linux-arm-msm@...r.kernel.org,
	agross@...eaurora.org, MPT-FusionLinux.pdl@...gotech.com,
	Hannes Reinecke <hare@...e.de>
Subject: Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA
 fails



On 11/10/2015 2:43 PM, James Bottomley wrote:
> The Issue, as stated by LSI is
>
>          Initially set the consistent DMA mask to 32 bit and then change
>          it
>          to 64 bit mask after allocating RDPQ pools by calling the
>          function
>          _base_change_consistent_dma_mask. This is to ensure that all the
>          upper 32 bits of RDPQ entries's base address to be same.
>

Need somebody from mpt to confirm that this behavior is still valid for 
the recent cards besides altix.

> If you set a 64 bit coherent mask before this point, you're benefiting
> from being lucky that all the upper 32 bits of the allocations are the
> same ... we can't code a driver to rely on luck.  Particularly not when
> the failure mode looks like it would be silent and deadly.

Of course nobody wants unreliable code.

I'm wondering if I was just lucky during my testing or the 92xx and 93xx 
hardware supports full 64 bit range. I don't have any insight into what 
the endpoint does or what it is capable of.

>
>> >Another comment here from you.
>> >https://lkml.org/lkml/2015/4/2/28
>> >
>> >"Well, it was originally a hack for altix, because they had no regions
>> >below 4GB and had to specifically manufacture them.  As you know, in
>> >Linux, if Intel doesn't need it, no-one cares and the implementation
>> >bitrots."
>> >
>> >Maybe, it is time to fix the code for more recent (even decent) hardware?
> What do you mean "fix the code"?  The code isn't broken, it's
> parametrising issues with particular hardware.  There's no software work
> around (except allocating memory with the correct characteristics).

Need confirmation. I'm questioning if we are stuck with this behavior 
because of altix or something else. If the latter case, the code could 
have used PCI ID to do something special for it.

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project
--
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/