linux-kernel - Re: [PATCH AUTOSEL for 3.18 16/16] EDAC, i5000, i5400: Fix use of MTR_DRAM

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:   Thu, 30 Nov 2017 21:33:01 +0000
From:   alexander.levin@...izon.com
To:     Jérémy Lefaure <jeremy.lefaure@....epita.fr>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        linux-edac <linux-edac@...r.kernel.org>,
        Borislav Petkov <bp@...e.de>
Subject: Re: [PATCH AUTOSEL for 3.18 16/16] EDAC, i5000, i5400: Fix use of
 MTR_DRAM_WIDTH macro

On Wed, Nov 29, 2017 at 08:34:30PM -0500, Jérémy Lefaure wrote:
>On Wed, 29 Nov 2017 17:22:22 +0000
>alexander.levin@...izon.com wrote:
>
>> From: Jérémy Lefaure <jeremy.lefaure@....epita.fr>
>>
>> [ Upstream commit e61555c29c28a4a3b6ba6207f4a0883ee236004d ]
>>
>> The MTR_DRAM_WIDTH macro returns the data width. It is sometimes used
>> as if it returned a boolean true if the width if 8. Fix the tests where
>> MTR_DRAM_WIDTH is misused.
>>
>> Signed-off-by: Jérémy Lefaure <jeremy.lefaure@....epita.fr>
>> Cc: linux-edac <linux-edac@...r.kernel.org>
>> Link: https://urldefense.proofpoint.com/v2/url?u=http-3A__lkml.kernel.org_r_20170309011809.8340-2D1-2Djeremy.lefaure-40lse.epita.fr&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=4TjC-mjd8VhY5QwakbfRNaavseTL9EjNAamdg2F3LVk&s=A9D_GzYRdnb8lLzbBJnHwOFg4fTkGFZ_91MSxIRVMlg&e=
>> Signed-off-by: Borislav Petkov <bp@...e.de>
>> Signed-off-by: Sasha Levin <alexander.levin@...izon.com>
>>
>Hi Sasha,
>I noticed that you want to backport this commit to 3.18, 4.4 and 4.9.
>Is there any reason for not backporting it to 4.1 ?

No reason, I just scripted it this way to address Greg's trees. It'll
go in 4.1.

>Also, I don't know if you saw my other patch on those files, upstream
>commit a8c8261425649d ("EDAC, i5000, i5400: Fix definition of NRECMEMB
>register"). Maybe it should be backported to stable too ?

Sure, I'll include it in 4.9/4.4/3.18 as well, thanks!

-- 

Thanks,
Sasha