On Wed 04-03-20 14:02:09, Oleg Nesterov wrote: > On 03/04, Michal Hocko wrote: > > > > /* > > - * Flush all pending signals for this kthread. > > + * Flush all pending signals for this kthread. Please note that this interface > > + * shouldn't be and if there is a need for it then it should be clearly > > + * documented why. > > + * > > + * Existing users should be double checked because most of them are likely > > + * obsolete. Kernel threads are not on the receiving end of signal delivery > > + * unless they explicitly request that by allow_signal() and in that case > > + * flush_signals is almost always a bug > ^^^^^^^^^^^^^^^^^^^^^^ > I still think this is too strong statement... > > Even if it seems that most current users of flush_signals() are wrong. > > > because signal should be processed > > + * by kernel_dequeue_signal rather than dropping them on the floor. > > Yes, but to remind we need some cleanups to ensure that > s/flush_signals/kernel_dequeue_signal/ is always "safe" even when only a > single signal is allowed, > > > The only > > + * exception when flush_signals could be used is a micro-optimization when > > + * only a single signal is allowed when retreiving the specific signal number > > + * is not needed. Please document this usage. > > */ > > Agreed. Care to send a patch? I am pretty sure you would provide a more fitting wording. All I want to achieve is clarification what people should do. THis is a terrible interface and many bogus users are just proving the fact so the more specific about expected usage the better. -- Michal Hocko SUSE Labs
