Re: [LTP] [PATCH] readahead01: pass on pidfd

Re: [LTP] [PATCH] readahead01: pass on pidfd

[Petr Vorel]

Hi Lee,

> On Tue, 23 Apr 2024, Murphy Zhou wrote:

> > Linux kernel added pidfs via commit b5683a37c881 in v6.9-rc1
> > release. This patchset ignores readahead request instead of
> > returning EINVAL, so mark the test pass.

> > https://lkml.iu.edu/hypermail/linux/kernel/2403.2/00762.html

> > Signed-off-by: Murphy Zhou <jencce.kernel@gmail.com>
> > ---
> >  testcases/kernel/syscalls/readahead/readahead01.c | 1 +
> >  1 file changed, 1 insertion(+)

> > diff --git a/testcases/kernel/syscalls/readahead/readahead01.c b/testcases/kernel/syscalls/readahead/readahead01.c
> > index d4b3f306f..aed8e7f31 100644
> > --- a/testcases/kernel/syscalls/readahead/readahead01.c
> > +++ b/testcases/kernel/syscalls/readahead/readahead01.c
> > @@ -53,6 +53,7 @@ static void test_invalid_fd(struct tst_fd *fd)
> >  	case TST_FD_MEMFD:
> >  	case TST_FD_MEMFD_SECRET:
> >  	case TST_FD_PROC_MAPS:
> > +	case TST_FD_PIDFD:
> >  		return;
> >  	default:
> >  		break;

> Any movement on this?

Back to Christian Brauner discussing with Cyril Hrubis [1]

	> Wouldn't it make more sense to actually return EINVAL instead of
	> ignoring the request if readahead() is not implemented?

	It would change the return value for a whole bunch of stuff. I'm not
	sure that wouldn't cause regressions but is in any case a question for
	the readahead maintainers. For now I'd just remove that test for pidfds
	imho.

That's why I would like to get ack / oppinion of the readahead maintainers.
I already asked them under this patch.

@Andrew gently ping.

Kind regards,
Petr

[1] https://lore.kernel.org/lkml/20240318-fegen-bezaubern-57b0a9c6f78b@brauner/

Below the patch I have asked kernel maintainers to ack if 

> Android pre-submit CI testing is failing due to the new unconditional
> enable of PIDFD.  I believe this patch is required in order to bring it
> back to a passing state.