On 10/15, Thomas Gleixner wrote: > > On Thu, Oct 15 2020 at 16:37, Oleg Nesterov wrote: > > On 10/15, Jens Axboe wrote: > >> On 10/15/20 8:31 AM, Oleg Nesterov wrote: > >> > 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 ;) > > Yeah, we proliferate crap on that basis forever. _ALL_ architectures > have the very same entry/exit ordering problems (or subsets and > different ones) which we fixed on x86. > > So no, we don't want to have 24 different variants of the same thing > again. That's what common code is for. > > Not doing that is making the life of everyone working on core > infrastructure pointlessly harder. Architecture people still have enough > ways to screw everyone up. Sure, it would be nice to change them all to use kernel/entry/common.c. Until then (until never), how can we kill JOBCTL_TASK_WORK ? How can we remove freezing/klp_patch_pending from recalc_sigpending() ? Oleg.
