linux-kernel - Re: [PATCH v2] MIPS: ralink: fix booting on mt7621

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: <a27180db-4fcf-7b6d-2cac-03aab25a71a6@mips.com>
Date:   Wed, 21 Mar 2018 08:51:58 +0000
From:   Matt Redfearn <matt.redfearn@...s.com>
To:     NeilBrown <neil@...wn.name>, John Crispin <john@...ozen.org>,
        Ralf Baechle <ralf@...ux-mips.org>,
        James Hogan <jhogan@...nel.org>
CC:     <linux-mips@...ux-mips.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] MIPS: ralink: fix booting on mt7621

Hi Neil,

On 21/03/18 03:00, NeilBrown wrote:
> On Tue, Mar 20 2018, Matt Redfearn wrote:
> 
>> Hi Neil,
>>
>>
>> On 20/03/18 08:22, NeilBrown wrote:
>>>
>>> Further testing showed that the original version of this
>>> patch wasn't 100% reliable.  Very occasionally the read
>>> of SYSC_REG_CHIP_NAME0 returns garbage.  Repeating the
>>> read seems to be reliable, but it hasn't happened enough
>>> for me to be completely confident.
>>> So this version repeats that first read.
>>
>> You almost certainly need a sync() to ensure that the write to gcr_reg0
>> has completed before attempting to read sysc + SYSC_REG_CHIP_NAME0.
> 
> That sound like exactly the right sort of thing to do, though
> I assume you mean __sync().

Indeed I did :-)

> 
> I tried to reproduce the problem so I could test the fix, and of course
> I failed. Over 700 reboot cycles and never read any garbage from
> SYSC_REG_CHIP_NAME0.

Funny how things conspire like that :-) __sync() is definitely the 
correct barrier required to ensure the write completes before the read 
begins and will guarantee that the memory operations are ordered.

Thanks,
Matt

> 
> So I cannot test that this works, but I have tested that it doesn't
> cause any obvious regression.
> I'll send the v3 patch separately.
> 
> Thanks a lot,
> NeilBrown
>