All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <olsajiri@gmail.com>
To: Hao Luo <haoluo@google.com>
Cc: Jiri Olsa <olsajiri@gmail.com>,
	linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
	Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Song Liu <song@kernel.org>, Yonghong Song <yhs@fb.com>,
	KP Singh <kpsingh@kernel.org>,
	John Fastabend <john.fastabend@gmail.com>,
	Stanislav Fomichev <sdf@google.com>
Subject: Re: [PATCH bpf-next v1] bpf, iter: clean up bpf_seq_read().
Date: Wed, 3 Aug 2022 13:50:15 +0200	[thread overview]
Message-ID: <Yupg989wWYl4kmdZ@krava> (raw)
In-Reply-To: <CA+khW7iGQyoxRuOR=fHFzjpXLnHKraJ6=brktaZw6Rqkg85a6g@mail.gmail.com>

On Tue, Aug 02, 2022 at 05:15:50PM -0700, Hao Luo wrote:
> On Tue, Aug 2, 2022 at 4:14 AM Jiri Olsa <olsajiri@gmail.com> wrote:
> >
> > On Mon, Aug 01, 2022 at 01:50:39PM -0700, Hao Luo wrote:
> >
> > SNIP
> >
> > > +static int do_seq_show(struct seq_file *seq, void *p, size_t offs)
> > > +{
> > > +     int err;
> > > +
> > > +     WARN_ON(IS_ERR_OR_NULL(p));
> > > +
> > > +     err = seq->op->show(seq, p);
> > > +     if (err > 0) {
> > > +             /* object is skipped, decrease seq_num, so next
> > > +              * valid object can reuse the same seq_num.
> > > +              */
> > > +             bpf_iter_dec_seq_num(seq);
> > > +             seq->count = offs;
> > > +             return err;
> > > +     }
> > > +
> > > +     if (err < 0 || seq_has_overflowed(seq)) {
> > > +             seq->count = offs;
> > > +             return err ? err : -E2BIG;
> > > +     }
> > > +
> > > +     /* err == 0 and no overflow */
> > > +     return 0;
> > > +}
> > > +
> > > +/* do_seq_stop, stops at the given object 'p'. 'p' could be an ERR or NULL. If
> > > + * 'p' is an ERR or there was an overflow, reset seq->count to 'offs' and
> > > + * returns error. Returns 0 otherwise.
> > > + */
> > > +static int do_seq_stop(struct seq_file *seq, void *p, size_t offs)
> > > +{
> > > +     if (IS_ERR(p)) {
> > > +             seq->op->stop(seq, NULL);
> > > +             seq->count = offs;
> >
> > should we set seq->count to 0 in case of error?
> >
> 
> Thanks Jiri. To be honest, I don't know. There are two paths that may
> lead to an error "p".
> 
> First, seq->op->start() could return ERR, in that case, '"offs'" is
> zero and we set it to zero already. This is fine.

ah right, offs is zero at that time, looks good then

> 
> The other one, seq->op->next() could return ERR. This is a case where
> bpf_seq_read() fails to handle right now, so I am not sure what to do.

but maybe we don't need to set seq->count in here, like:

	static int do_seq_stop(struct seq_file *seq, void *p, size_t offs)
	{
		if (IS_ERR(p)) {
			seq->op->stop(seq, NULL);
			return PTR_ERR(p);
		}

because it's already set by error path of do_seq_show

> 
> Based on my understanding reading the code, if seq->count isn't
> zeroed, the current read() will not copy data, but the next read()
> will copy data (see the "if (seq->count)" at the beginning of
> bpf_seq_read). If seq->count is zeroed, the data in buffer will be
> discarded. I don't know what is right.

I think we should return the buffer up to the point there's an error,
that's why we set seq->count to previous offs value after failed
show callback

jirka

  reply	other threads:[~2022-08-03 11:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-01 20:50 [PATCH bpf-next v1] bpf, iter: clean up bpf_seq_read() Hao Luo
2022-08-02 11:14 ` Jiri Olsa
2022-08-03  0:15   ` Hao Luo
2022-08-03 11:50     ` Jiri Olsa [this message]
2022-08-03 11:53 ` Jiri Olsa

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=Yupg989wWYl4kmdZ@krava \
    --to=olsajiri@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=sdf@google.com \
    --cc=song@kernel.org \
    --cc=yhs@fb.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.