On June 24, 2026 4:52:09 PM GMT+01:00, Oleg Nesterov <[email protected]> wrote: >On 06/24, Eric W. Biederman wrote: >> >> Oleg Nesterov <[email protected]> writes: >> >> > Add Eric. >> > >> > OK, I agree, it seems we need a simple fix. >> > >> > Acked-by: Oleg Nesterov <[email protected]> >> > >> > >------------------------------------------------------------------------- >> > But let me add some "offtopic" notes... Why do we actually need this >fix? >> > >> > kill_something_info(). But at first glance >sys_kill/kill_something_info >> > can simply use SEND_SIG_NOINFO? If yes, this makes sense anyway, I >will >> > re-check... > >.... > >> So I think tracing the basic kill syscall is interesting. >> >> It uses an explicit siginfo. It does that so it can choose >> between setting si_code to SI_TKILL and SI_USER. >> >> If the signal number is -1 it sends to every process in the >> system (or at least the pid namespace). >> >> That will require translation. > >Most probably I was wrong, I didn't try to re-check yet. > >But at first glance kill_something_info() never use SI_TKILL, and >__send_signal_locked(SEND_SIG_NOINFO) will do the necessary translation, >in this case si_pid/si_uid are the current task's pid/uid. > >But again, I am not sure. Didn't have to to actually look at this code. > >> I suspect just fixing send_signal_locked looks the easiest, >> especially if you make the siginfo parameter const. > >Yes, agreed, and I have already acked this patch. > >I think we can improve this unconditional rewrite later, on top of this >fix. > >Oleg. > >
Hey you two, sorry to impede in your conversation, but could we write your "conflicting" patch over my Patch 2? It's fine if you don't want to, it kind of kills two birds with one stone. Thanks!
