Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Alois Wohlschlager <alwoju@gmx.de>
To:     Christian Brauner <brauner@kernel.org>
Cc:     "Eric W. Biederman" <ebiederm@xmission.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Alexey Gladkov <legion@kernel.org>,
        Jens Axboe <axboe@kernel.dk>,
        David Hildenbrand <david@redhat.com>,
        Rolf Eike Beer <eb@emlix.com>,
        Ran Xiaokai <ran.xiaokai@zte.com.cn>,
        Matthew Bobrowski <repnop@google.com>, Jan Kara <jack@suse.cz>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] pid: Allow creation of pidfds to threads
Date:   Fri, 01 Apr 2022 11:00:27 +0200
Message-ID: <5392366.5i5WIIk9Ns@genesis>
In-Reply-To: <20220401070942.odjbuc5wecfayyok@wittgenstein>
References: <3412128.IC5jYiYEAv@genesis> <20220401070942.odjbuc5wecfayyok@wittgenstein>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart36927791.vr0k8ECSMx"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Precedence: bulk

--nextPart36927791.vr0k8ECSMx
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"; protected-headers="v1"
From: Alois Wohlschlager <alwoju@gmx.de>
To: Christian Brauner <brauner@kernel.org>
Subject: Re: [PATCH] pid: Allow creation of pidfds to threads
Date: Fri, 01 Apr 2022 11:00:27 +0200
Message-ID: <5392366.5i5WIIk9Ns@genesis>
In-Reply-To: <20220401070942.odjbuc5wecfayyok@wittgenstein>

Hello Christian,

> We originally blocked this because it is not as easy as simply allowing
> pidfds to be created for non-thread-group leaders.
> For a start, pidfd_poll() currently doens't work if pidfd_task() isn't a
> thread-group leader

I did notice the hang there, that's why my patch changes pidfd_poll to ret=
urn
error on tasks which are not thread-group leaders. IIRC, waiting on specif=
ic
threads is not supported by Linux at all, so I don't see a problem with no=
t
supporting it here either.

> and you'll just hang for CLONE_PIDFD | CLONE_THREAD.

No, CLONE_PIDFD | CLONE_THREAD behavior is unchanged, it will still fail w=
ith
EINVAL. I actually confirmed this by double-checking right now.

> So at least that needs to be adapated as well and there's likely a bunch
> of other corner-cases I'm forgetting about.

I'd be happy to hear about other corner-cases so I can fix them.

> Do you have a concrete use-case you want this for?

My use-case is basically making pidfd_getfd actually useful for its intend=
ed
purpose: there is a seccomp_unotify-based supervisor that wants to obtain =
a
file descriptor from its guest. This currently does not work if the action=
 to
be forwarded to the supervisor is performed in a secondary thread, since t=
here
is no way to obtain the required pidfd.

> Christian

Alois

--nextPart36927791.vr0k8ECSMx
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEypeoIv8kJdR0rz5L4PWepeUhaRQFAmJGvysACgkQ4PWepeUh
aRSBhQ/8CXQauAadNg4smYJongj+K9af3RvKzcgoGNZ7inOUDRBADIyDIMkiP4QH
1LxDeWn36uwVju5R+lIrW1nbO/aKEh+wEkQz8yQun4saQfehfGDydnk+TPXMPmlw
E575TuBN7qncn2sR0eiOB0QecN8sO1pGHZbM6ZBTndFl9UR+3hMSse/vD9zbfiuP
HhdTRY/Um/GHLTl1KTWua4v7GPLUVpDRh1nTSWaP366jwKX0xkeTqZ7hg1xTmEqz
8c36+TAKS3MEOTt68hTFM3H7VfhzdxJuZRwP5++MlWfAk0B46zDMtRJKykQr9uH5
Lx3BHmnDMt6XB+c9d4sgp+IOt/7HmSA/bEqKTIdb1Ea5eiChwPzQjbLo22L8U1hZ
IxYeStwGSG0fgTPSrBlC+vad8FdTfSNHxNXPTMCmiLawhyXFWnSmfpqmhA6ots+I
G4Ei5duX06BaL4Swwv/f4IxZQVfNIR5nhLsyRrgamh2+K7oakUmoxRLXScpGY9o4
Ghh9+vjSnOB/b0lFtrjorFbYb5w8McSEGLigXfSHXnLfTdIA9a8t/2ojQDWfXIl2
VA58qchxSuXhHPx76Strh3GmT1RLwgzA3qDMCpjdEvwHq5pvC6W5SOOiziNSRx19
Igxi1fXGhJCkKE7krdS4/lqqNxucoaJVvtr1I55CbEd8WzjcgE4=
=PTKU
-----END PGP SIGNATURE-----

--nextPart36927791.vr0k8ECSMx--