Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
Secumail-id: <5512.6501a2f3.6f044.0>
Message-ID: <2657e064-c537-c898-668f-b5e82228ec5a@kalrayinc.com>
Date:   Wed, 13 Sep 2023 13:54:24 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Subject: Re: [PATCH] i2c: designware: Fix corrupted memory seen in the ISR
Content-Language: en-us
From:   Yann Sionneau <ysionneau@kalrayinc.com>
To:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc:     Jan Bottorff <janb@os.amperecomputing.com>,
        Jarkko Nikula <jarkko.nikula@linux.intel.com>,
        Mika Westerberg <mika.westerberg@linux.intel.com>,
        Jan Dabros <jsd@semihalf.com>,
        Andi Shyti <andi.shyti@kernel.org>,
        Philipp Zabel <p.zabel@pengutronix.de>,
        linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20230913010313.418159-1-janb@os.amperecomputing.com>
 <4537fa1c-b622-674c-026e-8453eda0a4d1@kalrayinc.com>
 <ZQGbaXTnIk0NIZbK@smile.fi.intel.com>
 <038e40c8-d6cd-150e-933e-5b2d2d7af7c5@kalrayinc.com>
In-Reply-To: <038e40c8-d6cd-150e-933e-5b2d2d7af7c5@kalrayinc.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: M7b0I1W/oue3En6XIhlVhNRgQgrk6IwLBUwZHGGnjohCA5HH6PvkBYMnXWVrD8te4j1HMSouAiI+lkVxv/RLH/a7U8+itma5iDm8mLgwsx1T/W7aC6cw4jr+BvOA4rRLwKpiUV03P03x5UVjoi8hcra094OTH7QCg+Uzp5uTV1JVk4dpPV4A5iesurQS0cv2/Iy+BODevN6vhKQhcLHs1a6ROieTEcWAhKAL6XP74wflH0LWRStosqN9ZL0G45lhh0Leg28Xl8nVFsbnAuhqL1J/xMbjDt6Nq9mVuSwvsVQ2Vux5S18O/LR3shNqnV5F+JV++H6hPohQIA+2MtgMzu54l8P/XE0vRjxegXzy/3xvPicNAItd73MduNAgcr0I4WFByQOTW8lZLUxk9iTNJQkpor2yZwhbJvjB6Vl4vLtSKd4wiTZEuachJ3l/0kN5P4xDFJncRhWyKNMxmfbGcdouMhJkou9dV/Wa5Inl4/e6AthVE9naDtRYE2l6nktlkOQKloSv6IO0ncuFdHThODaD6cD73LHr7OFhwvF5nY+CEVWqCmVQp4RL5wIhwEKvauqGJprC7CyHTt/qZWWvhhNx8fNy80oWMEkXp4WI8uRjqH8uJefKpqHTplqGXw42y15hio3yR2KWp37GevuiQnMpuynoEFQgBcWWoU/bhBKQxbLNLRO2iaSO94JvU/RGdMOf9lyAbgzBq7QJU+UvZYvz6hXskiVGm7HsG2hZHGhx4tHfLE0KunrRp0AsaGpl6yFRjfv2yIM8BbHF2ABLQ9I4XgdvQCQmyP7pRYPnPsB5VgF1cOfSCqAsdTZlvPPBkrqYUPk5idjz1Q5Fiq3Dolw9Gg1kN6rcfJxT8VQDfBEW3loTYSkdKg4zBAtfphGcgjG5minmApd5e+g7+h2tMQlR99IwPAl2xKktwBp+u53zQRZ0ODYRTrvn7cLncrtS
 HqeBBQRwgXLAcwThxNqZ/2XGsdXc09rFbbWzSqc9ZawSjvVagM7RwQMKKNGifTnNyG9NVlx826J+osON6MiqqHYyjBo+uDKVMhlVLMGEArxFPFswYdkTWsUTBZhEFDrgE/TjFyA3D8TVLqBFB+j4+1zyOipq3CAcKwzDHkt54H3sszx5OPkltiFOhkxOF4mect4WUJFay0ENoRoH2Qst/sAsn/ChNrH9VRMzEKefQ/h0DJhVY/q3WGrhqmGi3g3GGuTLZn3IvGlVhmDgxKnFVSf/dqVZ2Hja/K0WYgWe7ZN6dpF9uS2cfnjSF1HCkgiQZgkm0mHu/6EYHNzATVJDi5/Fvw4DtOptPdMLA/g09hXx1+2pTcYYtGjttz6mm7jOL9O+VcCy2YpiCRVIYNnVKkvt3bmgFXIyrlxBrOT2dwLSRTqTuFwltegmVolgwfjzRE1H+AcxlXDqfFnzJalos48CewBUOnV/pHan9LLBsJEt3DB711uHQNlXOCRvFhhkvJtLd+3t98mgTsEN3mY+6BtFXTQwLplFEjQpHdXUWHV+l0WvEbTYuOAcVtGp9cvMeG8O+V++WWb3IgOfAwumNiJ35J2FKPnAnVYX0dNaiFKZ1bri3eIU3ZLlCkE0Vf/vtoIOILwcDi9Gwdm7MMNGoLfbcGijizjOIgVDGI+iF1cVqacBZVkkdRBVCiiNcMBjVjOrOqIc8ETGjvfDs56Y5A==
X-OriginatorOrg: kalrayinc.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b948251a-0dac-4ef3-7bed-08dbb4502dc4
X-MS-Exchange-CrossTenant-AuthSource: MR1P264MB1890.FRAP264.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Sep 2023 11:54:26.2821
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 8931925d-7620-4a64-b7fe-20afd86363d3
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: q399y4DJQ8dgIBl8ogtwtv7fu5YnvsXRfv7CSiVD4gdrlfgBV2juMzJxosmJfHzmaNlpcY4zpBTUIGCD+3bkfQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MRZP264MB1669
X-ALTERMIMEV2_out: done
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Wed, 13 Sep 2023 04:54:36 -0700 (PDT)


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