On 10/15/20 9:49 AM, Oleg Nesterov wrote: > On 10/15, Jens Axboe wrote: >> >> Reviewed-by: Oleg Nesterov <oleg@xxxxxxxxxx> > > Yes, but ... > >> +static void task_work_notify_signal(struct task_struct *task) >> +{ >> +#if defined(CONFIG_GENERIC_ENTRY) && defined(TIF_NOTIFY_SIGNAL) > > as long as defined(CONFIG_GENERIC_ENTRY) goes away ;) > > Thomas, I strongly, strongly disagree with you. But even if you are right > and only CONFIG_GENERIC_ENTRY arches should use TIF_NOTIFY_SIGNAL, why should > this series check CONFIG_GENERIC_ENTRY ? > > You can simply nack the patch which adds TIF_NOTIFY_SIGNAL to > arch/xxx/include/asm/thread_info.h. This seems to be the biggest area of contention right now. Just to summarize, we have two options: 1) We leave the CONFIG_GENERIC_ENTRY requirement, which means that the rest of the cleanups otherwise enabled by this series will not be able to move forward until the very last arch is converted to the generic entry code. 2) We go back to NOT having the CONFIG_GENERIC_ENTRY requirement, and archs can easily opt-in to TIF_NOTIFY_SIGNAL independently of switching to the generic entry code. I understand Thomas's reasoning in wanting to push archs towards the generic entry code, and I fully support that. However, it does seem like the road paved by #1 is long and potentially neverending, which would leave us with never being able to kill the various bits of code that we otherwise would be able to. Thomas, I do agree with Oleg on this one, I think we can make quicker progress on cleanups with option #2. This isn't really going to hinder any arch conversion to the generic entry code, as arch patches would be funeled through the arch trees anyway. Thomas? -- Jens Axboe