Messages in this thread | | | Date | Thu, 15 Oct 2020 16:37:29 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH 3/5] kernel: add support for TIF_NOTIFY_SIGNAL |
| |
On 10/15, Jens Axboe wrote: > > On 10/15/20 8:31 AM, Oleg Nesterov wrote: > > On 10/15, Jens Axboe wrote: > >> > >> static inline int signal_pending(struct task_struct *p) > >> { > >> +#if defined(CONFIG_GENERIC_ENTRY) && defined(TIF_NOTIFY_SIGNAL) > >> + /* > >> + * TIF_NOTIFY_SIGNAL isn't really a signal, but it requires the same > >> + * behavior in terms of ensuring that we break out of wait loops > >> + * so that notify signal callbacks can be processed. > >> + */ > >> + if (unlikely(test_tsk_thread_flag(p, TIF_NOTIFY_SIGNAL))) > >> + return 1; > >> +#endif > >> return task_sigpending(p); > >> } > > > > I don't understand why does this version requires CONFIG_GENERIC_ENTRY. > > > > Afaics, it is very easy to change all the non-x86 arches to support > > TIF_NOTIFY_SIGNAL, but it is not trivial to change them all to use > > kernel/entry/common.c ? > > I think that Thomas wants to gate TIF_NOTIFY_SIGNAL on conversion to > the generic entry code?
Then I think TIF_NOTIFY_SIGNAL will be never fully supported ;)
Oleg.
| |