linux-kernel - Re: [PATCH bpf v2] lib/buildid: use __kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAEf4BzY2YYJJsMx8BgkKk7BG67pj52stv_GRGwZkj3jnuipw+Q@mail.gmail.com>
Date: Fri, 19 Dec 2025 09:42:13 -0800
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Shakeel Butt <shakeel.butt@...ux.dev>
Cc: Matthew Wilcox <willy@...radead.org>, Andrew Morton <akpm@...ux-foundation.org>, 
	Andrii Nakryiko <andrii@...nel.org>, Shaurya Rane <ssrane_b23@...vjti.ac.in>, 
	"Darrick J . Wong" <djwong@...nel.org>, Christoph Hellwig <hch@...radead.org>, 
	Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, 
	Meta kernel team <kernel-team@...a.com>, bpf@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	linux-mm@...ck.org, linux-kernel@...r.kernel.org, 
	syzbot+09b7d050e4806540153d@...kaller.appspotmail.com, 
	Christoph Hellwig <hch@....de>
Subject: Re: [PATCH bpf v2] lib/buildid: use __kernel_read() for sleepable context

On Thu, Dec 18, 2025 at 9:59 PM Shakeel Butt <shakeel.butt@...ux.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.