linux-kernel - Re: [PATCH] i2c: designware: Fix corrupted memory seen in the ISR

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: <2657e064-c537-c898-668f-b5e82228ec5a@kalrayinc.com>
Date:   Wed, 13 Sep 2023 13:54:24 +0200
From:   Yann Sionneau <ysionneau@...rayinc.com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Jan Bottorff <janb@...amperecomputing.com>,
        Jarkko Nikula <jarkko.nikula@...ux.intel.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Jan Dabros <jsd@...ihalf.com>,
        Andi Shyti <andi.shyti@...nel.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] i2c: designware: Fix corrupted memory seen in the ISR


On 13/09/2023 13:32, Yann Sionneau wrote:
>
> On 13/09/2023 13:22, Andy Shevchenko wrote:
>> On Wed, Sep 13, 2023 at 11:04:00AM +0200, Yann Sionneau wrote:
>>> On 13/09/2023 03:03, Jan Bottorff wrote:
>> ...
>>
>>>> +    /*
>>>> +     * To guarantee data written by the current core is visible to
>>>> +     * all cores, a write barrier is required. This needs to be
>>>> +     * before an interrupt causes execution on another core.
>>>> +     * For ARM processors, this needs to be a DSB barrier.
>>>> +     */
>>>> +    wmb();
>>> Apart from the commit message it looks good to me.
>>>
>>> If I understand correctly without this wmb() it is possible that the 
>>> writes
>>> to dev->msg_write_idx , dev->msg_read_idx = 0 etc would not yet be 
>>> visible
>>> to another CPU running the ISR handler right after enabling those.
>> If this is the case, shouldn't we rather use READ_ONCE()/WRITE_ONCE() 
>> where
>> appropriate?
>>
> To my knowledge the READ_ONCE()/WRITE_ONCE() only imply the use of 
> volatile to access memory thus preventing the compiler to do weird 
> optimizations like merging store/loads, moving store/loads, removing 
> them etc
>
> They don't imply a memory barrier.
>
> Some systems need a memory barrier, to emit a "fence" like 
> instruction, so that the pipeline stalls waiting for the store to 
> "finish", for systems where the writes are posted.
>
> Regards,
>
Well, for the READ_ONCE() actually I'm wrong, it's overloaded for Alpha 
and arm64 https://elixir.bootlin.com/linux/latest/C/ident/__READ_ONCE

-- 

Yann