Re: [PATCH bpf v2] lib/buildid: use __kernel_read() for sleepable context

[Andrii Nakryiko <andrii.nakryiko@gmail.com>]

On Thu, Dec 18, 2025 at 9:59 PM Shakeel Butt <shakeel.butt@linux.dev> wrote:
>
> On Fri, Dec 19, 2025 at 04:07:51AM +0000, Matthew Wilcox wrote:
> > On Thu, Dec 18, 2025 at 04:16:40PM -0800, Shakeel Butt wrote:
> > > On Thu, Dec 18, 2025 at 11:55:39PM +0000, Matthew Wilcox wrote:
> > > > On Thu, Dec 18, 2025 at 12:55:05PM -0800, Shakeel Butt wrote:
> > > > > +       do {
> > > > > +               ret = __kernel_read(r->file, buf, sz, &pos);
> > > > > +               if (ret <= 0) {
> > > > > +                       r->err = ret ?: -EIO;
> > > > > +                       return NULL;
> > > > > +               }
> > > > > +               buf += ret;
> > > > > +               sz -= ret;
> > > > > +       } while (sz > 0);
> > > >
> > > > Why are you doing a loop around __kernel_read()?  eg kernel_read() does
> > > > not do a read around __kernel_read().  The callers of kernel_read()
> > > > don't do a loop either.  So what makes you think it needs to have a loop
> > > > around it?
> > >
> > > I am assuming that __kernel_read() can return less data than the
> > > requested. Is that assumption incorrect?
> >
> > I think it can, but I don't think a second call will get any more data.
> > For example, it could hit EOF.  What led you to think that calling it in
> > a loop was the right approach?
>
> I am kind of following the convention of a userspace application doing
> read() syscall i.e. repeatedly call read() until you hit an error or EOF
> in which case 0 will be returned or you successfully read the amount of
> data you want. I am handling negative error and 0 and for 0, I am
> returning -EIO as that would be unexpected end of an ELF file.
>
> Anyways the question is if __kernel_read() returns less amount of data
> than requested, should we return error instead of retrying? I looked
> couple of callers of __kernel_read() & kernel_read(). Some are erroring
> out if received data is less than requested (e.g. big_key_read()) and
> some are calling in the loop (e.g. kernel_read_file()).

From a user perspective, I'd very much appreciate it if I get exactly
the requested amount of bytes from freader_fetch_sync(), so yeah,
let's please keep the loop. It does seem that ret <= 0 handling is
correct and should not result in an endless loop.