Message ID | tencent_3B1BE2B20183906E56D9E58C4AE4EBC62806@qq.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2010:b0:403:3b70:6f57 with SMTP id fe16csp1113051vqb; Fri, 20 Oct 2023 07:57:24 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGBg1spuoDxG1NsnzndWOn6ezyzOGaeizK+k22wy1TCJaq8llx/Jj7cVq+chd6BBFjLKwmu X-Received: by 2002:a05:6a21:a593:b0:15e:b8a1:57b0 with SMTP id gd19-20020a056a21a59300b0015eb8a157b0mr2082790pzc.39.1697813844064; Fri, 20 Oct 2023 07:57:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697813844; cv=none; d=google.com; s=arc-20160816; b=exVtg5nHrgeN6LiAJKlD9jGrtJ+Hm7Muemg8ScS8iThLYKlsuBCh4nL8+ianXOjW7F IhuVjL4MO6OKrl6qiAg7yP5jrb7fxsnCxuTDuqTVbGsuDWZAl2YrqbNcvQcMoY9KhkZw fhX7QGcdXADVX3lWwIh8k/+OjwBpAy2mYn0yP4IqEYAf9XXXgbtrnbUl45iBWyrdhwxD AFq+Ww53WAlyRWaKq0DHi+wgH75gyzPu4ZY1tOnL7DUAftcqhQmATC0qPGOi7z9+S+fn gK6PQ4I0bddc5w1xzy2NWgPQVKG7awyAVrHEb9lTead3ylliujIqXPjxlPnpwDfuC8ki ivpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:date:subject:to:from:message-id :dkim-signature; bh=JHbwUQb8lD1tTuEb5a8cmghLPuMYhOm9x0/pntObncg=; fh=PGaP26rljTYcjLituiXWjvRiYsB22YGWGH+YkC/057Y=; b=AW46Bdz3Z/gVHY4aIie4fZlNUxQFYWL4H++W9k3e4vz3iJgf6vNqEZNZUPoyyUGfD2 7rxFO3OKeELeAQZ4O9b677LIEgrbox1M5KYxnd3eXxH3e+PbR7VRVSzpwsWnBTHaWtbA dZEfL55HHjgg3fk7aY6Sj/axd39bpbL6agcpxvObKAn4S2Km4k1nmexji11qoW/Idq1n hJuNw743a5x7DagCED/9gMg8hCbMarnDKEQeCbluFSVIgLVvUFF7zMqkx/yi7zdaHPa9 QKNfbPiyzv3tsRcH4sgvfE0IAPq7zanYzbQnhhlOd/gVPRYThgyKhE4doTOYM0bRUxja rD3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@foxmail.com header.s=s201512 header.b=uxSF6Wrw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=foxmail.com Received: from morse.vger.email (morse.vger.email. [2620:137:e000::3:1]) by mx.google.com with ESMTPS id n1-20020a170902d2c100b001ca336f48bdsi2027363plc.556.2023.10.20.07.57.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Oct 2023 07:57:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1; Authentication-Results: mx.google.com; dkim=pass header.i=@foxmail.com header.s=s201512 header.b=uxSF6Wrw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=foxmail.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id E1D6D836B4C6; Fri, 20 Oct 2023 07:57:21 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1377597AbjJTO5P (ORCPT <rfc822;a1648639935@gmail.com> + 26 others); Fri, 20 Oct 2023 10:57:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46414 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377529AbjJTO5O (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 20 Oct 2023 10:57:14 -0400 Received: from out203-205-221-149.mail.qq.com (out203-205-221-149.mail.qq.com [203.205.221.149]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A43C2D46 for <linux-kernel@vger.kernel.org>; Fri, 20 Oct 2023 07:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1697813828; bh=JHbwUQb8lD1tTuEb5a8cmghLPuMYhOm9x0/pntObncg=; h=From:To:Subject:Date:In-Reply-To:References; b=uxSF6WrwYctZlChw7piyjZL3T4n6sMLbQzZCeEN9haHN1R+4FLXl5giJKUIfsDX3B ZwWrXq+FpQL+s2EKqcEylSpnyveny9DxZJohfQINChYEP4Wbv8oJleucEzHieUP4xt tNw+N9W6JUcyHe9MvaSCM0G3MlM42BX8NOJOwn+k= Received: from rtoax.lan ([120.245.114.36]) by newxmesmtplogicsvrszb6-0.qq.com (NewEsmtp) with SMTP id AE3AEEEC; Fri, 20 Oct 2023 22:43:35 +0800 X-QQ-mid: xmsmtpt1697813020tebywjqps Message-ID: <tencent_3B1BE2B20183906E56D9E58C4AE4EBC62806@qq.com> X-QQ-XMAILINFO: N7h1OCCDntujuOVB48/Os70qsluFoiNYAhE4QPkzGQOyy7m7FTfareKCeYGFHS HihtYz16ET3FQGu+TcR4ZrkeLHMvR6w0pcQuzzfvQSdHaRxbOo6o1yPVU5pTQ5QlVkiMKQv5dAMn GhJXqifhL+hBkHmCIgvbYC3GAZRl2sKa7cUz5mJRxRJQ0Nt/sH/UlofAUWa40yiF19hmfF/niNg7 gNmRK68X9WtPa1HhNrnUBUvm9204LQXbd3Yinskj+MuYafHaHmeCcmcPzGIRNhAKP7HgWfLcZoLh 2CrOg1vLWd34j2oLvek9cUbR9DmfBrS2C6T56Hd2yXLQhDr4T8g+oeAtmvGM7O9OqXJyILhhDz0A x+fsPRqLJIudCt7PLGnLb2YUqCycL7DM5SWvbKedg3mb6KXqbzhjcng6qaqxQmqfQP14vUB087WW XoR6VbsEq+FL6IzFREdS4dSQNY3M2Cy50PlRzk5C4c8uz79jAmf9aNQotrjTxFrYeVfLxbQ/renI HCYl27eHbP0yTzUEdcAP595is+6SVJcN14Sz0J61IqSUaPeTTg/VBVlGRMxKOpKBWJwUTgpmrxHs jtSnuOmausx72KeWPXeRVaI0lvxIAoJWJwMIEHSw4tMARTnlEf0zma9MQksyAY3dXaKo5UfaU6nF o4k7VZZzeeFkglSuRcNWx7w0GubTN6Skng3sEHlxUEiAxpyHMhd+Xz9WpI6VbJq5qsjCExPg1YVB ZjhJgBsiiq7GxSZkTDyd9bt6OlHPcKC8mgradRT9aHlCgWnUwHddtbS/FSghaiXD+NSHIjHaaudd 7PVrtsasopKMr2nV8y3JVb7Q2e0Bv0h5SKEQw/fevxCLUTX0rVvvd3KtRsVIiZXDP7oViUuNOBT8 u846eVq0Griww4+dqLJUXrKJT0RA2VE3WI1v1+9TIAj/97l0xTL7TVPfvT7P/ikzhBWxzh+Jpvn/ tyrheEl15NJr2PttV3SBFZd9vEHMF0DYojW0yW/X7+BlU1c5GndAU7K1di62v2uvp2kp7Fma6dYE GzVLxEq0PW5O52yLfX8/BAqN9xunw= X-QQ-XMRINFO: NS+P29fieYNw95Bth2bWPxk= From: Rong Tao <rtoax@foxmail.com> To: mark.rutland@arm.com, elver@google.com, linux-kernel@vger.kernel.org, peterz@infradead.org, rongtao@cestc.cn, rtoax@foxmail.com, tglx@linutronix.de Subject: [PATCH 2/2] stop_machine: Apply smp_store_release() to multi_stop_data::state Date: Fri, 20 Oct 2023 22:43:34 +0800 X-OQ-MSGID: <f86cefda1e6d0b29a444c5b7451d0222d686fd36.1697811778.git.rongtao@cestc.cn> X-Mailer: git-send-email 2.41.0 In-Reply-To: <cover.1697811778.git.rongtao@cestc.cn> References: <cover.1697811778.git.rongtao@cestc.cn> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 morse.vger.email 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 (morse.vger.email [0.0.0.0]); Fri, 20 Oct 2023 07:57:21 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780286849552783894 X-GMAIL-MSGID: 1780286849552783894 |
Series |
[1/2] stop_machine: Use non-atomic read multi_stop_data::state clearly
|
|
Commit Message
Rong Tao
Oct. 20, 2023, 2:43 p.m. UTC
From: Rong Tao <rongtao@cestc.cn> Replace smp_wmb()+WRITE_ONCE() with smp_store_release() and add comment. Signed-off-by: Rong Tao <rongtao@cestc.cn> --- kernel/stop_machine.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
Comments
On Fri, Oct 20, 2023 at 10:43:34PM +0800, Rong Tao wrote: > From: Rong Tao <rongtao@cestc.cn> > > Replace smp_wmb()+WRITE_ONCE() with smp_store_release() and add comment. > > Signed-off-by: Rong Tao <rongtao@cestc.cn> > --- > kernel/stop_machine.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c > index 268c2e581698..cdf4a3fe0348 100644 > --- a/kernel/stop_machine.c > +++ b/kernel/stop_machine.c > @@ -183,8 +183,10 @@ static void set_state(struct multi_stop_data *msdata, > { > /* Reset ack counter. */ > atomic_set(&msdata->thread_ack, msdata->num_threads); > - smp_wmb(); > - WRITE_ONCE(msdata->state, newstate); > + /* This smp_store_release() pair with READ_ONCE() in multi_cpu_stop(). > + * Avoid potential access multi_stop_data::state race behaviour. > + */ > + smp_store_release(&msdata->state, newstate); This doesn't match coding style: /* * Block comments should look like this, with a leading '/*' line * before the text and a traling '*/' line afterwards. */ See https://www.kernel.org/doc/html/v4.10/process/coding-style.html#commenting I don't think the "Avoid potential access multi_stop_data::state race behaviour." text is all that helpful, and I think we can drop that. In general, it's unusual to pair a smp_store_release() with READ_ONCE(), and for that to work it relies on dependency ordering and/or hazarding on the reader side (e.g. the atomic_dec_and_test() is ordered after the READ_ONCE() since it's an RMW and there's a control dependency, but a plain read could be reordered w.r.t. the READ_ONCE()). So we probably need to explain that if we're going to comment on that smp_store_release(). Peter, might it be worth replacing the READ_ONCE() with smp_load_acquire() at the same time? I know it's not strictly necessary given the ordering we have today, but it would at least be obvious. Mark. > } > > /* Last one to ack a state moves to the next state. */ > -- > 2.41.0 >
On 10/24/23 7:01 PM, Mark Rutland wrote: > On Fri, Oct 20, 2023 at 10:43:34PM +0800, Rong Tao wrote: >> From: Rong Tao <rongtao@cestc.cn> >> >> Replace smp_wmb()+WRITE_ONCE() with smp_store_release() and add comment. >> >> Signed-off-by: Rong Tao <rongtao@cestc.cn> >> --- >> kernel/stop_machine.c | 6 ++++-- >> 1 file changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c >> index 268c2e581698..cdf4a3fe0348 100644 >> --- a/kernel/stop_machine.c >> +++ b/kernel/stop_machine.c >> @@ -183,8 +183,10 @@ static void set_state(struct multi_stop_data *msdata, >> { >> /* Reset ack counter. */ >> atomic_set(&msdata->thread_ack, msdata->num_threads); >> - smp_wmb(); >> - WRITE_ONCE(msdata->state, newstate); >> + /* This smp_store_release() pair with READ_ONCE() in multi_cpu_stop(). >> + * Avoid potential access multi_stop_data::state race behaviour. >> + */ >> + smp_store_release(&msdata->state, newstate); > This doesn't match coding style: > > /* > * Block comments should look like this, with a leading '/*' line > * before the text and a traling '*/' line afterwards. > */ > > See https://www.kernel.org/doc/html/v4.10/process/coding-style.html#commenting Thanks, Mark, I'll fix the comment in next patch version. > > I don't think the "Avoid potential access multi_stop_data::state race > behaviour." text is all that helpful, and I think we can drop that. > > In general, it's unusual to pair a smp_store_release() with READ_ONCE(), and > for that to work it relies on dependency ordering and/or hazarding on the > reader side (e.g. the atomic_dec_and_test() is ordered after the READ_ONCE() > since it's an RMW and there's a control dependency, but a plain read could be > reordered w.r.t. the READ_ONCE()). So we probably need to explain that if we're > going to comment on that smp_store_release(). > > Peter, might it be worth replacing the READ_ONCE() with smp_load_acquire() at > the same time? I know it's not strictly necessary given the ordering we have > today, but it would at least be obvious. After I wait for Peter to reply to this message, I will write a patch based on Peter's suggestion. Rong Tao. > > Mark. > >> } >> >> /* Last one to ack a state moves to the next state. */ >> -- >> 2.41.0 >>
diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c index 268c2e581698..cdf4a3fe0348 100644 --- a/kernel/stop_machine.c +++ b/kernel/stop_machine.c @@ -183,8 +183,10 @@ static void set_state(struct multi_stop_data *msdata, { /* Reset ack counter. */ atomic_set(&msdata->thread_ack, msdata->num_threads); - smp_wmb(); - WRITE_ONCE(msdata->state, newstate); + /* This smp_store_release() pair with READ_ONCE() in multi_cpu_stop(). + * Avoid potential access multi_stop_data::state race behaviour. + */ + smp_store_release(&msdata->state, newstate); } /* Last one to ack a state moves to the next state. */