From: Marco Elver <firstname.lastname@example.org> To: Mark Rutland <email@example.com> Cc: "Paul E. McKenney" <firstname.lastname@example.org>, Boqun Feng <email@example.com>, Will Deacon <firstname.lastname@example.org>, Alexander Potapenko <email@example.com>, Dmitry Vyukov <firstname.lastname@example.org>, kasan-dev <email@example.com>, LKML <firstname.lastname@example.org> Subject: Re: [PATCH 0/7] kcsan: Introduce CONFIG_KCSAN_PERMISSIVE Date: Wed, 9 Jun 2021 16:48:33 +0200 [thread overview] Message-ID: <CANpmjNMvvdaBsN4QFVQ2CW7mB0yW2J0EF9aMd7RFg-K8BMkdgw@mail.gmail.com> (raw) In-Reply-To: <20210609123810.GA37375@C02TD0UTHF1T.local> On Wed, 9 Jun 2021 at 14:38, Mark Rutland <email@example.com> wrote: > Hi Marco, > > On Mon, Jun 07, 2021 at 02:56:46PM +0200, Marco Elver wrote: > > While investigating a number of data races, we've encountered data-racy > > accesses on flags variables to be very common. The typical pattern is a > > reader masking all but one bit, and the writer setting/clearing only 1 > > bit (current->flags being a frequently encountered case; mm/sl[au]b.c > > disables KCSAN for this reason currently). > > As a heads up, I just sent out the series I promised for > thread_info::flags, at: > > https://firstname.lastname@example.org/T/#t > > ... which I think is complementary to this (IIUC it should help with the > multi-bit cases you mention below), and may help to make the checks more > stringent in future. Nice, glad to see this. And yes, this series isn't a permission to let the 'flags' variables be forgotten, but perhaps not every subsystem wants to go through this now. So seeing any progress on this front helps and we can also use it to give concrete suggestions how to approach it (e.g. your accessors). > FWIW, for this series: > > Acked-by: Mark Rutland <email@example.com> Thank you!
next prev parent reply other threads:[~2021-06-09 14:50 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-07 12:56 Marco Elver 2021-06-07 12:56 ` [PATCH 1/7] kcsan: Improve some Kconfig comments Marco Elver 2021-06-07 12:56 ` [PATCH 2/7] kcsan: Remove CONFIG_KCSAN_DEBUG Marco Elver 2021-06-07 12:56 ` [PATCH 3/7] kcsan: Introduce CONFIG_KCSAN_STRICT Marco Elver 2021-06-07 12:56 ` [PATCH 4/7] kcsan: Reduce get_ctx() uses in kcsan_found_watchpoint() Marco Elver 2021-06-07 12:56 ` [PATCH 5/7] kcsan: Rework atomic.h into permissive.h Marco Elver 2021-06-07 12:56 ` [PATCH 6/7] kcsan: Print if strict or non-strict during init Marco Elver 2021-06-07 12:56 ` [PATCH 7/7] kcsan: permissive: Ignore data-racy 1-bit value changes Marco Elver 2021-06-09 12:38 ` [PATCH 0/7] kcsan: Introduce CONFIG_KCSAN_PERMISSIVE Mark Rutland 2021-06-09 14:48 ` Marco Elver [this message] 2021-06-15 18:19 ` Paul E. McKenney 2021-06-15 18:51 ` Marco Elver 2021-06-15 20:39 ` Paul E. McKenney
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CANpmjNMvvdaBsN4QFVQ2CW7mB0yW2J0EF9aMd7RFg-K8BMkdgw@mail.gmail.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 0/7] kcsan: Introduce CONFIG_KCSAN_PERMISSIVE' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).