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]

Date:   Wed, 21 Mar 2018 14:00:44 +1100
From:   NeilBrown <neil@...wn.name>
To:     Matt Redfearn <matt.redfearn@...s.com>,
        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

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().

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.

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

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)