Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Jiri Olsa <olsajiri@gmail.com>
Date:   Wed, 7 Sep 2022 09:17:15 +0200
To:     Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc:     Jiri Olsa <olsajiri@gmail.com>,
        syzbot <syzbot+2251879aa068ad9c960d@syzkaller.appspotmail.com>,
        Andrii Nakryiko <andrii@kernel.org>,
        Alexei Starovoitov <ast@kernel.org>, bpf <bpf@vger.kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Hao Luo <haoluo@google.com>,
        John Fastabend <john.fastabend@gmail.com>,
        KP Singh <kpsingh@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Martin KaFai Lau <martin.lau@linux.dev>,
        Stanislav Fomichev <sdf@google.com>,
        Song Liu <song@kernel.org>,
        syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
        Yonghong Song <yhs@fb.com>
Subject: Re: [syzbot] WARNING in bpf_bprintf_prepare (2)
Message-ID: <YxhFe3EwqchC/fYf@krava>
References: <0000000000008be47905e7e08b85@google.com>
 <YxXZT6NxSSLufivZ@krava>
 <CAADnVQKthoffNDuO8TsjyCx1JF8jvsyh_pvmT+Q3yB493OeQeA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAADnVQKthoffNDuO8TsjyCx1JF8jvsyh_pvmT+Q3yB493OeQeA@mail.gmail.com>
Precedence: bulk

On Tue, Sep 06, 2022 at 08:02:39PM -0700, Alexei Starovoitov wrote:

SNIP

> > >  __mutex_lock_common kernel/locking/mutex.c:605 [inline]
> > >  __mutex_lock+0x13c/0x1350 kernel/locking/mutex.c:747
> > >  __pipe_lock fs/pipe.c:103 [inline]
> > >  pipe_write+0x132/0x1be0 fs/pipe.c:431
> > >  call_write_iter include/linux/fs.h:2188 [inline]
> > >  new_sync_write fs/read_write.c:491 [inline]
> > >  vfs_write+0x9e9/0xdd0 fs/read_write.c:578
> > >  ksys_write+0x1e8/0x250 fs/read_write.c:631
> > >  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> > >  do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
> > >  entry_SYSCALL_64_after_hwframe+0x63/0xcd
> >
> > looks like __bpf_trace_contention_begin needs bpf_prog_active check
> > (like below untested), which would prevent the recursion and bail
> > out after 2nd invocation
> >
> > should be easy to reproduce, will check
> >
> > jirka
> >
> >
> > ---
> > diff --git a/include/trace/bpf_probe.h b/include/trace/bpf_probe.h
> > index 6a13220d2d27..481b057cc8d9 100644
> > --- a/include/trace/bpf_probe.h
> > +++ b/include/trace/bpf_probe.h
> > @@ -4,6 +4,8 @@
> >
> >  #ifdef CONFIG_BPF_EVENTS
> >
> > +DECLARE_PER_CPU(int, bpf_prog_active);
> > +
> >  #undef __entry
> >  #define __entry entry
> >
> > @@ -82,7 +84,11 @@ static notrace void                                                  \
> >  __bpf_trace_##call(void *__data, proto)                                        \
> >  {                                                                      \
> >         struct bpf_prog *prog = __data;                                 \
> > +       if (unlikely(__this_cpu_inc_return(bpf_prog_active) != 1))      \
> > +               goto out;                                               \
> >         CONCATENATE(bpf_trace_run, COUNT_ARGS(args))(prog, CAST_TO_U64(args));  \
> > +out:                                                                   \
> > +        __this_cpu_dec(bpf_prog_active);
> 
> I don't think we can use this big hammer here.
> raw_tp progs attached to different hooks need to
> run on the same cpu otherwise we will lose events.

might be good place to use prog->active
I managed to reproduce it localy, will try that

jirka