signal: add the "int si_code" arg to prepare_kill_siginfo()

So that do_tkill() can use this helper too. This also simplifies the next patch.

TODO: perhaps we can kill prepare_kill_siginfo() and change the callers to use SEND_SIG_NOINFO, but this needs some changes in __send_signal_locked() and TP_STORE_SIGINFO().

Signed-off-by Oleg Nesterov <[email protected]>

---

Turn kill_pid_info() into kill_pid_info_type(), this allows to pass any pid_type to group_send_sig_info(), despite its name it should work fine even if type = PIDTYPE_PID.

Change pidfd_send_signal() to use PIDTYPE_PID or PIDTYPE_TGID depending on PIDFD_THREAD.

While at it kill another TODO comment in pidfd_show_fdinfo(). As Christian expains fdinfo reports f_flags, userspace can already detect PIDFD_THREAD.

Signed-off-by Oleg Nesterov <[email protected]>

---

Turn kill_pid_info() into kill_pid_info_type(), this allows to pass any pid_type to group_send_sig_info(), despite its name it should work fine even if type = PIDTYPE_PID.

Change pidfd_send_signal() to use PIDTYPE_PID or PIDTYPE_TGID depending on PIDFD_THREAD.

While at it kill another TODO comment in pidfd_show_fdinfo(). As Christian expains fdinfo reports f_flags, userspace can already detect PIDFD_THREAD.

Signed-off-by Oleg Nesterov <[email protected]>

---

How do you feel about the following (untested...) addition?

I've played with PIDFD_SIGNAL_PROCESS_GROUP as well but that code is fairly new to me so I would need some more time.

Quoted 2 lines · Christian Brauner

How do you feel about the following (untested...) addition?

LGTM, but let me read this patch once again tomorrow, I have a headache today.

Quoted 3 lines

I've played with PIDFD_SIGNAL_PROCESS_GROUP as well but that code is fairly new to me so I would need some more time.

Heh, I was going to send another email to discuss this ;)

Should be simple, but may be need some simple preparations.

Especially if we also want PIDFD_SIGNAL_SESSION_GROUP.

So the question: do you think we also want PIDFD_SIGNAL_SESSION_GROUP?

Quoted 2 lines · Oleg Nesterov

So the question: do you think we also want PIDFD_SIGNAL_SESSION_GROUP?

Thought about this as well and my feeling is to wait until someone asks for it. Right now, we have a reason to add PIDFD_SIGNAL_PROCESS_GROUP because of Andy's use-case. If someone has a use-case for session groups then yes. Otherwise I'd just not bother?

So that do_tkill() can use this helper too. This also simplifies the next patch.

TODO: perhaps we can kill prepare_kill_siginfo() and change the callers to use SEND_SIG_NOINFO, but this needs some changes in __send_signal_locked() and TP_STORE_SIGINFO().

[...]

Could you can pass in the destination type instead of the si_code? Something like I have shown below?

	info->si_code = (type == PIDTYPE_PID) ? SI_TKILL : SI_USER;

So that do_tkill() can use this helper too. This also simplifies the next patch.

TODO: perhaps we can kill prepare_kill_siginfo() and change the callers to use SEND_SIG_NOINFO, but this needs some changes in __send_signal_locked() and TP_STORE_SIGINFO().

Signed-off-by Oleg Nesterov <[email protected]>

---
 kernel/signal.c | 15 +++++----------
 1 file changed, 5 insertions(+), 10 deletions(-)

kernel/signal.c +0 -0

index c3fac06937e2..a8199fda0d61 100644
@@ -3793,12 +3793,12 @@ COMPAT_SYSCALL_DEFINE4(rt_sigtimedwait_time32, compat_sigset_t __user *, uthese,
 #endif

kernel/signal.c +3 -8

 	info->si_pid = task_tgid_vnr(current);
 	info->si_uid = from_kuid_munged(current_user_ns(), current_uid());
 }

@@ -3812,7 +3812,7 @@ SYSCALL_DEFINE2(kill, pid_t, pid, int, sig)
 {
 	struct kernel_siginfo info;
 
-	prepare_kill_siginfo(sig, &info);
+	prepare_kill_siginfo(sig, &info, SI_USER);
 
 	return kill_something_info(sig, &info, pid);
 }

@@ -3925,7 +3925,7 @@ SYSCALL_DEFINE4(pidfd_send_signal, int, pidfd, int, sig,
 		    (kinfo.si_code >= 0 || kinfo.si_code == SI_TKILL))
 			goto err;
 	} else {
-		prepare_kill_siginfo(sig, &kinfo);
+		prepare_kill_siginfo(sig, &kinfo, SI_USER);
 	}
 
 	/* TODO: respect PIDFD_THREAD */

@@ -3970,12 +3970,7 @@ static int do_tkill(pid_t tgid, pid_t pid, int sig)
 {
 	struct kernel_siginfo info;
 
-	clear_siginfo(&info);
-	info.si_signo = sig;
-	info.si_errno = 0;
-	info.si_code = SI_TKILL;
-	info.si_pid = task_tgid_vnr(current);
-	info.si_uid = from_kuid_munged(current_user_ns(), current_uid());
+	prepare_kill_siginfo(sig, &info, SI_TKILL);
 
 	return do_send_specific(tgid, pid, sig, &info);
 }

Turn kill_pid_info() into kill_pid_info_type(), this allows to pass any pid_type to group_send_sig_info(), despite its name it should work fine even if type = PIDTYPE_PID.

Change pidfd_send_signal() to use PIDTYPE_PID or PIDTYPE_TGID depending on PIDFD_THREAD.

While at it kill another TODO comment in pidfd_show_fdinfo(). As Christian expains fdinfo reports f_flags, userspace can already detect PIDFD_THREAD.

Signed-off-by Oleg Nesterov <[email protected]>

Quoted 3 lines · Eric W. Biederman

Could you can pass in the destination type instead of the si_code? Something like I have shown below?

...

Quoted 1 line

	info->si_code = (type == PIDTYPE_PID) ? SI_TKILL : SI_USER;

Yes, I considered this option too.

OK, will send V3 tomorrow.

Quoted 7 lines · Oleg Nesterov

Quoted 3 lines · Eric W. Biederman

Could you can pass in the destination type instead of the si_code? Something like I have shown below?

...

Quoted 5 lines

Quoted 1 line

	info->si_code = (type == PIDTYPE_PID) ? SI_TKILL : SI_USER;

Yes, I considered this option too.

OK, will send V3 tomorrow.

Hm, I don't think that's necessary if you're happy to have me just fix that up in tree.

but I have a baby on my lap so double check, please:

Quoted 5 lines · Oleg Nesterov

Quoted 3 lines · Eric W. Biederman

Could you can pass in the destination type instead of the si_code? Something like I have shown below?

Quoted 7 lines

...

Quoted 1 line

	info->si_code = (type == PIDTYPE_PID) ? SI_TKILL : SI_USER;

Yes, I considered this option too.

OK, will send V3 tomorrow.

Hm, I don't think that's necessary if you're happy to have me just fix that up in tree. Here's the two patches updated. It was straightforward but I have a baby on my lap so double check, please:

From 05ffda39f6f5c887cae319274366cbf856c88fe5 Mon Sep 17 00:00:00 2001
From: Oleg Nesterov <[email protected]>
Date: Fri, 9 Feb 2024 14:06:20 +0100
Subject: [PATCH 1/2] signal: fill in si_code in prepare_kill_siginfo()

So that do_tkill() can use this helper too. This also simplifies the next patch.

TODO: perhaps we can kill prepare_kill_siginfo() and change the callers to use SEND_SIG_NOINFO, but this needs some changes in __send_signal_locked() and TP_STORE_SIGINFO().

Signed-off-by Oleg Nesterov <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Christian Brauner <[email protected]>

and I forgot to mention, if you want to add PIDFD_SIGNAL_PRGP you can look at __kill_pgrp_info().

(1) kill(-1234) => kill process group with id 1234
(2) kill(0) => kill process group of @current

which implementation wise is indicated by

__kill_pgrp_info(..., pid ? find_vpid(-pid) ? task_pgrp(current))

We're obviously not going to implement (2) as that doesn't really make a sense for pidfd_send_signal().

But (1) is also wrong for pidfd_send_signal(). If we'd ever implement
(1) it should be via pidfd_open(1234, PIDFD_PROCESS_GROUP).

Quoted 10 lines · Christian Brauner

(1) kill(-1234) => kill process group with id 1234
(2) kill(0) => kill process group of @current

which implementation wise is indicated by

__kill_pgrp_info(..., pid ? find_vpid(-pid) ? task_pgrp(current))

We're obviously not going to implement (2) as that doesn't really make a sense for pidfd_send_signal().

Sure,

Quoted 2 lines

But (1) is also wrong for pidfd_send_signal(). If we'd ever implement
(1) it should be via pidfd_open(1234, PIDFD_PROCESS_GROUP).

Why do you think we need another flag for open() ?

To me it looks fine if we allow to send the signal to pgrp if flags & PIDFD_SIGNAL_PROCESS_GROUP.

And pidfd_send_signal() can just do

	if (PIDFD_SIGNAL_THREAD_GROUP)
		ret = __kill_pgrp_info(sig, kinfo, pid);
	else
		ret = kill_pid_info_type(...);

(yes, yes, this needs tasklist, just a pseudo code to simpliy)

Now lets recall about PIDFD_THREAD.

If the target task is a group leader - there is no difference.

If it is not a leader - then __kill_pgrp_info() will always return -ESRCH, do_each_pid_task(PIDTYPE_PGID) won't find any task.

And personally I think this is all we need.

------------------------------------------------------------------------------
But if you want to make PIDFD_SIGNAL_THREAD_GROUP work even if the target task is not a leader, then yes, we need something like

task_pgrp(pid_task(pid, PIDTYPE_PID))

like you did in the new kill_pgrp_info() helper in this patch.

I won't argue, but do you think this makes a lot of sense?

Oleg.

Christian,

Thanks again! the last 2 commits in vfs.pidfd look good to me.

As for this patch, I am not sure I understand your concerns, and I have another concern, please see below.

For the moment, please forget about PIDFD_THREAD.

Quoted 10 lines · Christian Brauner

(1) kill(-1234) => kill process group with id 1234
(2) kill(0) => kill process group of @current

which implementation wise is indicated by

__kill_pgrp_info(..., pid ? find_vpid(-pid) ? task_pgrp(current))

We're obviously not going to implement (2) as that doesn't really make a sense for pidfd_send_signal().

Sure,

Quoted 2 lines

But (1) is also wrong for pidfd_send_signal(). If we'd ever implement
(1) it should be via pidfd_open(1234, PIDFD_PROCESS_GROUP).

Why do you think we need another flag for open() ?

To me it looks fine if we allow to send the signal to pgrp if flags & PIDFD_SIGNAL_PROCESS_GROUP.

And pidfd_send_signal() can just do

	if (PIDFD_SIGNAL_THREAD_GROUP)
		ret = __kill_pgrp_info(sig, kinfo, pid);
	else
		ret = kill_pid_info_type(...);

(yes, yes, this needs tasklist, just a pseudo code to simpliy)

Now lets recall about PIDFD_THREAD.

If the target task is a group leader - there is no difference.

If it is not a leader - then __kill_pgrp_info() will always return -ESRCH, do_each_pid_task(PIDTYPE_PGID) won't find any task.

And personally I think this is all we need.

------------------------------------------------------------------------------
But if you want to make PIDFD_SIGNAL_THREAD_GROUP work even if the target task is not a leader, then yes, we need something like

task_pgrp(pid_task(pid, PIDTYPE_PID))

like you did in the new kill_pgrp_info() helper in this patch.

I won't argue, but do you think this makes a lot of sense?

The question is what is more useful for userspace when they do:
pidfd_send_signal(1234, PIDFD_SEND_PROCESS_GROUP)?

(1) They either mean to signal a process group that is headed by 1234.

(2) Or they want to signal a process group of which 1234 is a member or the leader.

From a usability perspective (1) is a lot more restrictive because it requires @pidfd to refer to a process group leader.

Quoted 5 lines · Christian Brauner

The question is what is more useful for userspace when they do:
pidfd_send_signal(1234, PIDFD_SEND_PROCESS_GROUP)?

(1) They either mean to signal a process group that is headed by 1234.

Yes, this is what I had in mind, see also another email from me. Simple, clear, and matches kill(-1234).

Quoted 5 lines · Oleg Nesterov

Quoted 4 lines · Christian Brauner

The question is what is more useful for userspace when they do:
pidfd_send_signal(1234, PIDFD_SEND_PROCESS_GROUP)?

Quoted 4 lines

Quoted 1 line

(1) They either mean to signal a process group that is headed by 1234.

Yes, this is what I had in mind, see also another email from me. Simple, clear, and matches kill(-1234).

I went for a walk and kept thinking about this and I agree with you. It will require that 1234 will be a process group leader but I think that this is ok to require that.

Quoted 7 lines · Christian Brauner

Quoted 5 lines · Oleg Nesterov

Quoted 4 lines · Christian Brauner

The question is what is more useful for userspace when they do:
pidfd_send_signal(1234, PIDFD_SEND_PROCESS_GROUP)?

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

(1) They either mean to signal a process group that is headed by 1234.

Yes, this is what I had in mind, see also another email from me. Simple, clear, and matches kill(-1234).

I went for a walk and kept thinking about this and I agree with you. It will require that 1234 will be a process group leader but I think that this is ok to require that.

Yes... but I am starting to understand why you mentioned the new open PIDFD_PROCESS_GROUP flag... perhaps we can do something like this later, but this needs more thinking.

kernel/signal.c SYSCALL_DEFINE4(pidfd_send_signal, int, pidfd, int, sig, · line 3967

Quoted 2 lines

kernel/signal.c +2 -0

+	if (type == PIDFD_SIGNAL_PROCESS_GROUP)
+		ret = kill_pgrp_info(sig, &kinfo, pid);

I guess you meant

	if (type == PIDTYPE_PGID)

other than that,

Reviewed-by Oleg Nesterov <[email protected]>

kernel/signal.c SYSCALL_DEFINE4(pidfd_send_signal, int, pidfd, int, sig, · line 3967

Quoted 3 lines · Christian Brauner

kernel/signal.c +2 -0

+	if (type == PIDFD_SIGNAL_PROCESS_GROUP)
+		ret = kill_pgrp_info(sig, &kinfo, pid);

I guess you meant

	if (type == PIDTYPE_PGID)

other than that,

Reviewed-by Oleg Nesterov <[email protected]>

Quoted 8 lines · Oleg Nesterov

Review

Quoted 3 lines · Christian Brauner

(quoted diff) +2 -0

+	if (type == PIDFD_SIGNAL_PROCESS_GROUP)
+		ret = kill_pgrp_info(sig, &kinfo, pid);

I guess you meant

Quoted 5 lines

	if (type == PIDTYPE_PGID)

other than that,

Reviewed-by Oleg Nesterov <[email protected]>

Yes, but there is another thing I hadn't thought of...

sys_pidfd_send_signal() does

	/* Only allow sending arbitrary signals to yourself. */
	ret = -EPERM;
	if ((task_pid(current) != pid) &&
	    (kinfo.si_code >= 0 || kinfo.si_code == SI_TKILL))
		goto err;

and I am not sure that task_pid(current) == pid should allow the "arbitrary signals" if PIDFD_SIGNAL_PROCESS_GROUP.

Perhaps

	/* Only allow sending arbitrary signals to yourself. */
	ret = -EPERM;
	if ((task_pid(current) != pid || type == PIDTYPE_PGID) &&
	    (kinfo.si_code >= 0 || kinfo.si_code == SI_TKILL)
		goto err;

Quoted 11 lines · Oleg Nesterov

and I am not sure that task_pid(current) == pid should allow the "arbitrary signals" if PIDFD_SIGNAL_PROCESS_GROUP.

Perhaps

	/* Only allow sending arbitrary signals to yourself. */
	ret = -EPERM;
	if ((task_pid(current) != pid || type == PIDTYPE_PGID) &&
	    (kinfo.si_code >= 0 || kinfo.si_code == SI_TKILL)
		goto err;

Honestly, we should probably just do:

if (kinfo->si_code != SI_USER)
goto err

SI_USER means that the target can trust the values of si_pid/si_uid in siginfo.

Quoted 3 lines

SI_USER means that the target can trust the values of si_pid/si_uid in siginfo.

Bah, what an annoying nonsense. I see that this can be used to emulate stuff like SI_TIMER and SI_ASYNCIO. But I very much doubt the value of e.g., emulating SI_DETHREAD. Maybe I'm missing something very obvious.

So wouldn't be better of just writing this as?

if ((task_pid(current) != pid || type > PIDTYPE_TGID) &&

    (kinfo.si_code >= 0 || kinfo.si_code == SI_TKILL))
        goto err;

So that we don't have to repeat the same exercise if we extend this to anything above PIDTYPE_PGID?

Quoted 7 lines · Christian Brauner

Quoted 3 lines

SI_USER means that the target can trust the values of si_pid/si_uid in siginfo.

Bah, what an annoying nonsense. I see that this can be used to emulate stuff like SI_TIMER and SI_ASYNCIO. But I very much doubt the value of e.g., emulating SI_DETHREAD. Maybe I'm missing something very obvious.

I don't understand...

Quoted 9 lines · Oleg Nesterov

Quoted 7 lines · Christian Brauner

Quoted 3 lines

SI_USER means that the target can trust the values of si_pid/si_uid in siginfo.

Bah, what an annoying nonsense. I see that this can be used to emulate stuff like SI_TIMER and SI_ASYNCIO. But I very much doubt the value of e.g., emulating SI_DETHREAD. Maybe I'm missing something very obvious.

Quoted 1 line

I don't understand...

My question was what the purpose of being able to to set si_code to e.g., SI_DETHREAD is and then to send a signal to yourself? Because it looks like that's what rt_{tg}sigqueueinfo() and pidfd_send_signal() allows the caller to do. I'm just trying to understand use-cases for this.

Quoted 11 lines · Christian Brauner

Quoted 9 lines · Oleg Nesterov

Quoted 7 lines · Christian Brauner

Quoted 3 lines

SI_USER means that the target can trust the values of si_pid/si_uid in siginfo.

Bah, what an annoying nonsense. I see that this can be used to emulate stuff like SI_TIMER and SI_ASYNCIO. But I very much doubt the value of e.g., emulating SI_DETHREAD. Maybe I'm missing something very obvious.

Quoted 7 lines

Quoted 1 line

I don't understand...

My question was what the purpose of being able to to set si_code to e.g., SI_DETHREAD is and then to send a signal to yourself? Because it looks like that's what rt_{tg}sigqueueinfo() and pidfd_send_signal() allows the caller to do. I'm just trying to understand use-cases for this.

Ah. IIRC criu uses this hack to restore the pending (arbitrary) signals collected at dump time.

I was a bit surprise sys_pidfd_send_signal() allows this hack too, I don't

think that criu uses pidfd at restore time, but I do not know.

Quoted 5 lines · Oleg Nesterov

Ah. IIRC criu uses this hack to restore the pending (arbitrary) signals collected at dump time.

I was a bit surprise sys_pidfd_send_signal() allows this hack too, I don't

I think that we simply mirrored the restrictions in the other system calls.

Quoted 1 line

think that criu uses pidfd at restore time, but I do not know.

Hm, I just checked and it doesn't use pidfd_send_signal(). It uses pidfds but only for pid reuse detection for RPC clients.

So right now si_code is blocked for >= 0 and for SI_TKILL. If we were to simply ensure that si_code can't be < 0 then this amounts to effectively blocking @info from being filled in by userspace at all. Because 0 is a valid value.

Quoted 8 lines · Christian Brauner

Quoted 5 lines · Oleg Nesterov

Ah. IIRC criu uses this hack to restore the pending (arbitrary) signals collected at dump time.

I was a bit surprise sys_pidfd_send_signal() allows this hack too, I don't

Quoted 7 lines

I think that we simply mirrored the restrictions in the other system calls.

Quoted 1 line

think that criu uses pidfd at restore time, but I do not know.

Hm, I just checked and it doesn't use pidfd_send_signal(). It uses pidfds but only for pid reuse detection for RPC clients.

But perhaps something else already uses pidfd_send_signal() with info != NULL or with info->si_code == SI_USER, we can't know. Please see below.

Quoted 4 lines

So right now si_code is blocked for >= 0 and for SI_TKILL. If we were to simply ensure that si_code can't be < 0 then this amounts to effectively blocking @info from being filled in by userspace at all. Because 0 is a valid value.

I'am afraid I misunderstand you again... 0 == SI_USER is not a valid value when siginfo != NULL.

Perhaps we can kill the "task_pid(current) != pid" check and just return EPERM if "kinfo.si_code >= 0 || kinfo.si_code == SI_TKILL", I don't think anobody needs pidfd_send_send_signal() to signal yourself. See below.

Review

Quoted 4 lines

(quoted diff) +3 -0

+       /* Currently unused. */
+       if (info)
+               return -EINVAL;

Well, to me this looks like the unnecessary restriction... And why?

But whatever we do,

Review

Quoted 5 lines

(quoted diff) +0 -5

-               /* Only allow sending arbitrary signals to yourself. */
-               ret = -EPERM;
-               if ((task_pid(current) != pid) &&
-                   (kinfo.si_code >= 0 || kinfo.si_code == SI_TKILL))
-                       goto err;

Can I suggest to fix this check in your tree (add type > PIDTYPE_TGID as we discussed) first, then do other changes on top?

Quoted 4 lines · Oleg Nesterov

Perhaps we can kill the "task_pid(current) != pid" check and just return EPERM if "kinfo.si_code >= 0 || kinfo.si_code == SI_TKILL", I don't think anobody needs pidfd_send_send_signal() to signal yourself. See below.

Yeah.

Quoted 5 lines

Review

Quoted 3 lines

(quoted diff) +3 -0

+       /* Currently unused. */
+       if (info)
+               return -EINVAL;

Well, to me this looks like the unnecessary restriction... And why?

Because right now we aren't sure that it's used

and we aren't sure what use-cases are there.

Yes, absolutely. That was always the plan. See appended patch I put on top. I put you as author since you did spot this. Let me know if you don't want that.

Quoted 8 lines · Christian Brauner

Quoted 4 lines · Oleg Nesterov

Perhaps we can kill the "task_pid(current) != pid" check and just return EPERM if "kinfo.si_code >= 0 || kinfo.si_code == SI_TKILL", I don't think anobody needs pidfd_send_send_signal() to signal yourself. See below.

Yeah.

You have my ack in advance

Quoted 6 lines

Quoted 5 lines

Review

Quoted 3 lines

(quoted diff) +3 -0

+       /* Currently unused. */
+       if (info)
+               return -EINVAL;

Well, to me this looks like the unnecessary restriction... And why?

Quoted 1 line

Because right now we aren't sure that it's used

Yes, but...

Quoted 1 line

and we aren't sure what use-cases are there.

the same use-cases as for rt_sigqueueinfo() ?

Christian, I won't really argue but I still disagree.

Let me first repeat once again, I do not know what people do with pidfd and pidfd_send_signal() in particular, so I won't be surprised if this change won't cause any regression report.

But at the same time, I can easily imagine the following scenario: a userspace programmer tries to use pidfd_send_signal(info != NULL), gets -EINVAL, decides it can't/shouldn't work, and switches to sigqueueinfo() without any report to lkml.

Quoted 3 lines

Yes, absolutely. That was always the plan. See appended patch I put on top. I put you as author since you did spot this. Let me know if you don't want that.

Ah. Thanks Christian. I am fine either way, whatever is more convenient for you.

But just in case, I won't mind at all if you simply fold this minor fix into your PIDFD_SEND_PROCESS_GROUP patch, I certainly don't care about the "From" tag ;)

A really, really minor/cosmetic nit below, feel free to ignore:

kernel/signal.c SYSCALL_DEFINE4(pidfd_send_signal, int, pidfd, int, sig, · line 3959

Quoted 2 lines

kernel/signal.c +1 -1

-		if ((task_pid(current) != pid) &&
+		if (((task_pid(current) != pid) || type > PIDTYPE_TGID) &&

we can remove the unnecessary parens around "task_pid(current) != pid" or add the extra parens aroung "type > PIDTYPE_TGID".

I mean, the 1st operand of "&&" is

	(task_pid(current) != pid) || type > PIDTYPE_TGID

and this looks a bit inconsistent to me.

Quoted 9 lines · Oleg Nesterov

Quoted 8 lines

Quoted 6 lines

Review

Quoted 4 lines

(quoted diff) +3 -0

+       /* Currently unused. */
+       if (info)
+               return -EINVAL;

Well, to me this looks like the unnecessary restriction... And why?

Because right now we aren't sure that it's used

Quoted 5 lines

Yes, but...

Quoted 1 line

and we aren't sure what use-cases are there.

the same use-cases as for rt_sigqueueinfo() ?

Specifically for pidfd_send_signal() I mean. To me it seems very unlikely that anyone would be opening a pidfd to itself

Quoted 15 lines · Christian Brauner

Quoted 13 lines · Oleg Nesterov

Quoted 8 lines

Quoted 6 lines

Review

Quoted 4 lines

(quoted diff) +3 -0

+       /* Currently unused. */
+       if (info)
+               return -EINVAL;

Well, to me this looks like the unnecessary restriction... And why?

Because right now we aren't sure that it's used

Yes, but...

Quoted 1 line

and we aren't sure what use-cases are there.

Quoted 4 lines

Quoted 1 line

the same use-cases as for rt_sigqueueinfo() ?

Specifically for pidfd_send_signal() I mean. To me it seems very unlikely that anyone would be opening a pidfd to itself

Ah, with this, I do agree. And that is why (I think) we can remove the "task_pid(current) != pid" check in the "info != NULL" branch.