Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH 5/5] task_work: use TIF_NOTIFY_SIGNAL if available
To:     Oleg Nesterov <oleg@redhat.com>
Cc:     linux-kernel@vger.kernel.org, io-uring@vger.kernel.org,
        peterz@infradead.org, tglx@linutronix.de,
        Roman Gershman <romger@amazon.com>
References: <20201015131701.511523-1-axboe@kernel.dk>
 <20201015131701.511523-6-axboe@kernel.dk> <20201015154953.GM24156@redhat.com>
From:   Jens Axboe <axboe@kernel.dk>
Message-ID: <e17cd91e-97b2-1eae-964b-fc90f8f9ef31@kernel.dk>
Date:   Thu, 15 Oct 2020 12:39:31 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <20201015154953.GM24156@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

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