From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754962AbdKAQnW (ORCPT ); Wed, 1 Nov 2017 12:43:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38366 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751831AbdKAQnT (ORCPT ); Wed, 1 Nov 2017 12:43:19 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 0C3165F15C Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=oleg@redhat.com Date: Wed, 1 Nov 2017 17:43:14 +0100 From: Oleg Nesterov To: Petr Mladek Cc: Miroslav Benes , jpoimboe@redhat.com, jeyu@kernel.org, jikos@kernel.org, lpechacek@suse.cz, pavel@ucw.cz, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Michael Ellerman , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andy Lutomirski , linuxppc-dev@lists.ozlabs.org, x86@kernel.org Subject: Re: [PATCH v3 1/2] livepatch: send a fake signal to all blocking tasks Message-ID: <20171101164314.GA32760@redhat.com> References: <20171031114853.841-1-mbenes@suse.cz> <20171031114853.841-2-mbenes@suse.cz> <20171101151355.GG20040@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171101151355.GG20040@pathway.suse.cz> 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.25]); Wed, 01 Nov 2017 16:43:19 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/01, Petr Mladek wrote: > > On Tue 2017-10-31 12:48:52, Miroslav Benes wrote: > > + if (task->flags & PF_KTHREAD) { > > + /* > > + * Wake up a kthread which still has not been migrated. > > + */ > > + wake_up_process(task); > > I have just noticed that freezer used wake_up_state(p, TASK_INTERRUPTIBLE); > IMHO, we should do so as well. I won't argue, but... > wake_up_process() wakes also tasks in TASK_UNINTERRUPTIBLE state. > These might not be ready for an unexpected wakeup. For example, > see concat_dev_erase() in drivers/mtd/mtdcontact.c. I'd say that concat_dev_erase() should be fixed, any code should be ready for spurious wakeup. Note also that wake_up_state(TASK_INTERRUPTIBLE) won't wakeup the TASK_IDLE kthreads, and most of the kthreads which use TASK_INTERRUPTIBLE should use TASK_IDLE today, because in most cases TASK_INTERRUPTIBLE was used to not contribute to loadavg. Oleg.