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... > > do_pidfd_send_signal(PIDFD_SIGNAL_PROCESS_GROUP) allows to call > kill_pgrp_info() if si_code < 0... Not that I think this would be better, > but we could move this "rewrite" logic into __kill_pgrp_info()... > > Anything else needs this change? Most probably yes, but after the quick > grep I don't see other group senders with !is_si_special(info). > > Eric, what do you think?
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. So either we need to add another special siginfo value to handle SI_TKILL, or we need to fix this the way that was suggested. I suspect just fixing send_signal_locked looks the easiest, especially if you make the siginfo parameter const. It would likely help to have a self test that detects the problem before this is fixed and passes afterwards so we have some chance of detecting if someone makes a similar mistake in the future. Eric
