Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH 1/3] signals: Allow generation of SIGKILL to exiting task.
To:     "Eric W. Biederman" <ebiederm@xmission.com>
Cc:     linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
        Alexander.Deucher@amd.com, Christian.Koenig@amd.com,
        David.Panariti@amd.com, oleg@redhat.com, akpm@linux-foundation.org
References: <1524583836-12130-1-git-send-email-andrey.grodzovsky@amd.com>
 <1524583836-12130-2-git-send-email-andrey.grodzovsky@amd.com>
 <87y3hca73s.fsf@xmission.com>
From:   Andrey Grodzovsky <Andrey.Grodzovsky@amd.com>
Message-ID: <e371e586-0859-adb0-6666-d40a909d0b22@amd.com>
Date:   Tue, 24 Apr 2018 12:51:13 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <87y3hca73s.fsf@xmission.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Received-SPF: None (protection.outlook.com: amd.com does not designate
 permitted sender hosts)
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Apr 2018 16:51:18.5998 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 115c33ba-246f-4a0e-c8f5-08d5aa039a5b
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1201MB0126
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 04/24/2018 12:42 PM, Eric W. Biederman wrote:
> Andrey Grodzovsky <andrey.grodzovsky@amd.com> writes:
>
>> Currently calling wait_event_killable as part of exiting process
>> will stall forever since SIGKILL generation is suppresed by PF_EXITING.
>>
>> In our partilaur case AMDGPU driver wants to flush all GPU jobs in
>> flight before shutting down. But if some job hangs the pipe we still want to
>> be able to kill it and avoid a process in D state.
> I should clarify.  This absolutely can not be done.
> PF_EXITING is set just before a task starts tearing down it's signal
> handling.
>
> So delivering any signal, or otherwise depending on signal handling
> after PF_EXITING is set can not be done.  That abstraction is gone.

I see, so you suggest it's the driver responsibility to avoid creating 
such code path that ends up
calling wait_event_killable from exit call stack (PF_EXITING == 1) ?

Andrey

>
> Eric
>
>> Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
>> ---
>>   kernel/signal.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/signal.c b/kernel/signal.c
>> index c6e4c83..c49c706 100644
>> --- a/kernel/signal.c
>> +++ b/kernel/signal.c
>> @@ -886,10 +886,10 @@ static inline int wants_signal(int sig, struct task_struct *p)
>>   {
>>   	if (sigismember(&p->blocked, sig))
>>   		return 0;
>> -	if (p->flags & PF_EXITING)
>> -		return 0;
>>   	if (sig == SIGKILL)
>>   		return 1;
>> +	if (p->flags & PF_EXITING)
>> +		return 0;
>>   	if (task_is_stopped_or_traced(p))
>>   		return 0;
>>   	return task_curr(p) || !signal_pending(p);