linux-kernel - Re: [PATCH 5/5] task_work: use TIF_NOTIFY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 15 Oct 2020 12:39:31 -0600
From:   Jens Axboe <axboe@...nel.dk>
To:     Oleg Nesterov <oleg@...hat.com>
Cc:     linux-kernel@...r.kernel.org, io-uring@...r.kernel.org,
        peterz@...radead.org, tglx@...utronix.de,
        Roman Gershman <romger@...zon.com>
Subject: Re: [PATCH 5/5] task_work: use TIF_NOTIFY_SIGNAL if available

On 10/15/20 9:49 AM, Oleg Nesterov wrote:
> On 10/15, Jens Axboe wrote:
>>
>> Reviewed-by: Oleg Nesterov <oleg@...hat.com>
> 
> 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