From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752407AbdHPNbU (ORCPT ); Wed, 16 Aug 2017 09:31:20 -0400 Received: from mx2.suse.de ([195.135.220.15]:49163 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751578AbdHPNbS (ORCPT ); Wed, 16 Aug 2017 09:31:18 -0400 Date: Wed, 16 Aug 2017 15:31:15 +0200 From: Petr Mladek To: Miroslav Benes Cc: jpoimboe@redhat.com, jeyu@kernel.org, jikos@kernel.org, lpechacek@suse.cz, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Andy Lutomirski , "H. Peter Anvin" , Ingo Molnar , Michael Ellerman , Oleg Nesterov , Thomas Gleixner Subject: Re: [PATCH v2 0/3] livepatch: Introduce force sysfs attribute Message-ID: <20170816133115.GB601@pathway.suse.cz> References: <20170810104815.14727-1-mbenes@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170810104815.14727-1-mbenes@suse.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 2017-08-10 12:48:12, Miroslav Benes wrote: > Currently, livepatch gradually migrate the system from an unpatched to a > patched state (or vice versa). Each task drops its TIF_PATCH_PENDING > itself when crossing the kernel/user space boundary or it is cleared > using the stack checking approach. If there is a task which sleeps on a > patched function, the whole transition can get stuck indefinitely. > > TODO: > Now there is a sysfs attribute called "force", which provides two > functionalities, "signal" and "force" (previously "unmark"). I haven't > managed to come up with better names. Proposals are welcome. On the > other hand I do not mind it much. What about calling the attribute? transition-speedup transition-urge In each case, I would make it more clear that the attribute is related to the transition attribute of each patch. Best Regards, Petr