Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8;
Secumail-id: <9b85.65019dde.d9678.0>
Message-ID: <038e40c8-d6cd-150e-933e-5b2d2d7af7c5@kalrayinc.com>
Date:   Wed, 13 Sep 2023 13:32:43 +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
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>
From:   Yann Sionneau <ysionneau@kalrayinc.com>
In-Reply-To: <ZQGbaXTnIk0NIZbK@smile.fi.intel.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: UabJUu16zVTLvgfbjm/EVTYqK8RKreOFg3hPLlmlh/dRZ/paqavgrqfyXQPYcXYbALHzLIK/qHXXTQyXKEyJiAx765JgrIevF9GMr+VAFStBeHeKAlbZYR3igKHHemTPebAc3DkGE72dPKN7MZHwtG2OOmBSHv4qXxRBRVcWX1Ui2AQWWjbWErmiEQhWppwVW5E74uGQ0F+6KFToVebw2pLUXRY/XkHCqVIiYevuEoFWKN8XPkVHdGFxG9Fkw6gtvmYKtP1O5wRabEbRikOufDrTavBhgUtGNEwlcuWhB/Y9cl4xJ3o+Y+We4bafTiGe1D5X0mRKt/cm0ux4Cm3YHgpuGdinV+kQd+DAffq67RQ2TCW3GJ/tQArH9GzyZK87yLSaeZ3SXeuvDyLVCmqnwyEKYHwHWlu/vyjlHIWRL2HlC8Kjf6XTjfFCwNwRE1QMav44jaQaUEHt6sqGHIw4LsbQl4LQWGAcUKhHAQ5uMBosOFDykwrY9hdFvES7AYx5AmMoaAFI2fxFL3oqNVfuwZcfidKHrwaC+KGh8XMoLibtLNL0s9PTQL3R5OzZ9NMzdrqkIG1Vn5D0gQycBAZa6oq3izEvEvvly5GJGCFxLIxxQ+T6oI84pDxNYa9/NYI1tGuVEG7vIzuaJzaEO1yYinS2fpb0W43Ej4Olz/irLajYwBXyixPnU2FX0bsVPWjflk5gxwUkK9l1UmiTjap0JgFKMYDu4C/yHuzP8RMZBkd4yWxvDBgMJRgIW26OlLGX0DL5VKyBoM1DSI/15y+bgA3wxd7T5N0N7qQM8w1RbowYYsEhjqmtWH4TfcOpMWfJA3LNzerpmouGqOfOqb235kQWzUI0/SDbVN9cThYmheWzMhLv2BfTY4PNFZCdUGiXvAEXTYB+sM091rZgWAoidPIf8VbAUMJnEKUOshisZBNGkUAWktNJKcOQRGzDw55R
 hr6jiviaI5AVBxI4wUHYDIxRxfyN8KEDKDA+PwMJcmsKaQsWSiJ85lJGsBG77YWnQwELnumLLVbTQf576LOB+hykrQnAC0YR13BoGqLxQEHHHw5vn1gSKaGIg0y6OFNIh1ouSizwj+xYPri8a9k/wTXCoA6pCKyAxPpxS/fI4YeQCN11dYcZNwkiVVcc3QRJEG2da1JEW6OyYJEU+Y3hwTNGeCYKlSGvU0cDSJbLR47xSel7V9D9T4X8vGBv3rBqj40NMrTcPQpJrOLeVRotldjkkwBqqb2fxYlhEB4boAU0PTzeGiZ2eT3O5xiJZOKNcYIz7l1hsOZDtWCL6O7JS0kqyqYjj+O+FCCuCp6g76NHBPgKRhKftYaI/yI0kKhrT78psA5y00stQucmQxA4UhCPS4f/VZKVOV2MTJZ3Sx3uidIF8M+uYmXLRbi/ObfZvGrI7MdG2UFUN4X6/zlAyyMipHa8zd+1y33ssadnOT6JWGkRvm4Vm4TvEDOUn9eVvS9fuFKtG2q4cGI4QVj7bCVt6D1/DmxQ2g3s7VhXjB5Tya3ADR8wAob5wcieTK0a4Aw0KKbAaBqd/bLuMJ4+NsenQKkKM7T6krkN6eDbhXEguihbmeEWmkEBA1hd/CBj1Nb2wC1T9BrwZKtOeBIViXYt67Dv1YRUQrfYllB9QLTAMA5Q35kmydREeiL6bSGASg+uC8tLPTQjE0/ck3jmcQ==
X-OriginatorOrg: kalrayinc.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5fafa474-35e8-4b24-24e0-08dbb44d2636
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:32:45.5130
 (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: ueiTytRGPiH3WvvgrH+LbbTchjsDn4f++jwUrnHL+snDvL0y+rw02mhYranEnYNS0P9ZKy+DEDhxBQgWBQqCng==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR0P264MB3388
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 (fry.vger.email [0.0.0.0]); Wed, 13 Sep 2023 04:32:56 -0700 (PDT)
X-Spam-Status: No, score=-2.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS autolearn=unavailable
	autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email


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,

-- 

Yann