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

[Shakeel Butt <shakeel.butt@linux.dev>]

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()).