Received-SPF: pass (google.com: domain of linux-kernel+bounces-215282-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <4b875158-1aa7-402e-8861-860a493c49cd@I-love.SAKURA.ne.jp>
 <3e9b2a54-73d4-48cb-a510-d17984c97a45@I-love.SAKURA.ne.jp> <52d3d784-47ad-4190-920b-e5fe4673b11f@I-love.SAKURA.ne.jp>
In-Reply-To: <52d3d784-47ad-4190-920b-e5fe4673b11f@I-love.SAKURA.ne.jp>
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date: Fri, 14 Jun 2024 09:40:12 -0700
Message-ID: <CAADnVQLB6Zt1QjW+BeUmQJnWzGeCr7b2r0KKfygsJPzo0Rq+4A@mail.gmail.com>
Subject: Re: [PATCH] bpf: don't call mmap_read_trylock() from IRQ context
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Alexei Starovoitov <ast@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, 
	Andrii Nakryiko <andrii@kernel.org>, Martin KaFai Lau <martin.lau@linux.dev>, 
	Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>, 
	Yonghong Song <yonghong.song@linux.dev>, John Fastabend <john.fastabend@gmail.com>, 
	KP Singh <kpsingh@kernel.org>, Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>, 
	Jiri Olsa <jolsa@kernel.org>, bpf <bpf@vger.kernel.org>, 
	LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 14, 2024 at 8:15=E2=80=AFAM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> On 2024/06/08 20:04, Tetsuo Handa wrote:
> > On 2024/06/08 19:53, Tetsuo Handa wrote:
> >> inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
> >
> > Oops, "inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage." example wa=
s
> > found at https://syzkaller.appspot.com/text?tag=3DCrashReport&x=3D14f01=
79a980000 .
> >
> > Then, do we want to
> >
> > -     if (in_hardirq()) {
> > +     if (!in_task()) {
> >
> > instead?
> >
>
> "inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage." upon unlock from I=
RQ work
> was reported at https://syzkaller.appspot.com/bug?extid=3D40905bca570ae67=
84745 .

imo the issue is elsewhere. syzbot reports:
local_lock_acquire include/linux/local_lock_internal.h:29 [inline]
 __mmap_lock_do_trace_released+0x9c/0x620 mm/mmap_lock.c:243
 __mmap_lock_trace_released include/linux/mmap_lock.h:42 [inline]

it complains about:
local_lock(&memcg_paths.lock);
in TRACE_MMAP_LOCK_EVENT.
which looks like a false positive.