From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754944AbdERTxE (ORCPT ); Thu, 18 May 2017 15:53:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59092 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752020AbdERTxB (ORCPT ); Thu, 18 May 2017 15:53:01 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 206973DBC9 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=oleg@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 206973DBC9 Date: Thu, 18 May 2017 21:52:56 +0200 From: Oleg Nesterov To: Miroslav Benes Cc: jpoimboe@redhat.com, jeyu@redhat.com, jikos@kernel.org, pmladek@suse.com, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/3] livepatch: send a fake signal to all blocking tasks Message-ID: <20170518195255.GA2518@redhat.com> References: <20170518120043.7205-1-mbenes@suse.cz> <20170518120043.7205-3-mbenes@suse.cz> <20170518164909.GA939@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 18 May 2017 19:53:01 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/18, Miroslav Benes wrote: > > On Thu, 18 May 2017, Oleg Nesterov wrote: > > > > > exit_to_usermode_loop() calls do_signal(), then klp_update_patch_state(). > > So it won't be cleared here. > > Ok, so maybe I misunderstand the code. I see the loop in > exit_to_usermode_loop() for processing ALLWORK_MASK. There we call > do_signal(). We go to get_signal(). The infinite loop there is relevant > for us. We call dequeue_signal(). There, if I am not mistaken > __dequeue_signal() would return 0 Yes, sorry, I didn't bother to read the code when I looked at your patch and my memory fooled me. > If not, we get back to exit_to_usermode_loop() and TIF_PATCH_PENDING is > cleared. Yes, it is true that TIF_SIGPENDING is still set and we get to > do_signal() once more. But for the last time. Yes, slightly sub-optimal but not really wrong and you can swap do_signal() and klp_update_patch_state(). > If the syscall is restarted, it may be different. I have to think about > this one. But... Afaics, there are no problems. In short. Thanks for correcting me and sorry for noise! Oleg.