linux-kernel - Re: [PATCH AUTOSEL for-4.9 04/53] spi: imx: adjust watermark level according to transfer length

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:   Wed, 8 Nov 2017 22:48:14 +0000
From:   "Levin, Alexander (Sasha Levin)" <alexander.levin@....verizon.com>
To:     Mark Brown <broonie@...nel.org>
CC:     "Levin, Alexander (Sasha Levin)" <alexander.levin@....verizon.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Jiada Wang <jiada_wang@...tor.com>
Subject: Re: [PATCH AUTOSEL for-4.9 04/53] spi: imx: adjust watermark level
 according to transfer length

On Wed, Nov 08, 2017 at 10:11:02PM +0000, Mark Brown wrote:
>On Wed, Nov 08, 2017 at 09:39:11PM +0000, Levin, Alexander (Sasha Levin) wrote:
>> >On Wed, Nov 08, 2017 at 08:49:55PM +0000, Levin, Alexander (Sasha Levin) wrote:
>> >This seems like an optimization not a bug fix...
>
>> Hm, is it? I read it as "DMA is not being used at all even though we
>> thought we're using it".
>
>Yes, that's how I read it too.
>
>> Yes, the impact is "just" performance, but doesn't it result in quite
>> a significat impact?
>
>Only about double according to the initial commit adding DMA support
>which is frankly a bit disappointing although yeah, it's a big win.  My
>worry is that if there's a problem with DMA on some device for which a
>fix wasn't backported (or where we're using a fallback) this could
>expose problems if we start using it.  If you look at the history of the
>driver there's some quirks were added later on for example, and I didn't
>check the DMA controller drivers or anything and obviously can't see any
>out of tree code users may have.
>
>*Probably* it doesn't break anything but since it's not fixing anything
>and the risk is data corruption I'd be much more comfortable with a more
>thorough risk analysis.

I'm considering these commits to be on the safer side because they're
much older than the ones Greg usually grabs. There were no upstream
fixes to this commit for 10 months now, and given the code changes
upstream in that subsystem, this patch seemed to be safe to backport.

-- 

Thanks,
Sasha