Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
From:   Qian Cai <cai@lca.pw>
Mime-Version: 1.0 (1.0)
Date:   Fri, 28 Feb 2020 06:30:26 -0500
Subject: Re: [PATCH] mm/swap: annotate data races for lru_rotate_pvecs
Message-Id: <463BBB2A-8F9A-4CF1-80AE-677ACD21A3C6@lca.pw>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Linux Memory Management List <linux-mm@kvack.org>,
        LKML <linux-kernel@vger.kernel.org>,
        kasan-dev <kasan-dev@googlegroups.com>
To:     Marco Elver <elver@google.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Feb 28, 2020, at 5:49 AM, Marco Elver <elver@google.com> wrote:
>=20
> Note that, the fact that the writer has local interrupts disabled for
> the write is irrelevant because it's the interrupt that triggered
> while the read was happening that led to the concurrent write.

I was just to explain that concurrent writers are rather unlikely as people m=
ay ask.

>=20
> I assume you ran this with CONFIG_KCSAN_INTERRUPT_WATCHER=3Dy?  The
> option is disabled by default (see its help-text). I don't know if we
> want to deal with data races due to interrupts right now, especially
> those that just result in 'data_race' annotations. Thoughts?

Yes, I somehow got quite a bit clean runs lately thanks to the fix/annotatio=
ns efforts for the last a few weeks (still struggling with the flags things a=
 bit), so I am naturally expanding the testing coverage here.

Right now the bottleneck is rather some subsystem maintainers are not so kee=
n to deal with data races (looking forward to seeing more education opportun=
ities for all), but the MM subsystem is not one of them.=