Received: by 10.223.164.221 with SMTP id h29csp3780579wrb; Tue, 31 Oct 2017 04:53:11 -0700 (PDT) X-Google-Smtp-Source: ABhQp+T9bs2nbOs8Xw3Ik4Mjm+gzu+eEYuRyTQEGFgPJ0OpIO1PW3kLLx9hrdnkWWdcm0NyY8Cvx X-Received: by 10.98.223.72 with SMTP id u69mr1829080pfg.305.1509450791360; Tue, 31 Oct 2017 04:53:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1509450791; cv=none; d=google.com; s=arc-20160816; b=Uzbv/jZDQNo2H8CGX1FLG/V7DPCaGVp4gNH49KCFEsciV7Y6LPgV70lAxSunKG89N9 vkPeh+wP8stoNNW9qrBHl0xS3e+2uKtMUsQGAI2qhzJ3Sn5lRn0oWlrwQhfGNN/8rhwh RjkVHDGDvF5Z9yN62MExVR+J0ZakNmaVH+HEvpcnAcWWXAgBR3a06ViVA4hIA8/4j0co oHiDVIpspafCyQmFBtMw2tuGWsgBhrIxnB3sDI8ufJrdIjuZYcBrh/BhVt2ALSRmqV// A0WoGdVf+cMBAzLmRzT7D576mlth8p4fa9nybb+z/5otNtf+wXz2cWhrVmqyVko5kkHr tpMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=CP5FojTjduX1CeR8243S/U0Z0kaYxjgXI/z27xx2ZYg=; b=O6BBf0OHkkC9tlxGR228PZr4gOR29JO0G43IJIqRGvBS+XCtllvYeU7CtwqGdeNQ2A Bc7azSjt5Ta1VA9lBJK+Nn5M8dd5Gen7qVmAnNmA/NHuQH2fMdSJoFYBrsyKgaXNeTio o2xdTL03u5ixIKmSQjfR2QTeA5JeuShK6XE12vudJVpCbIfnzXmRKozSYp1kxryzkVVM hNILNDEivEcsMyz0bLMCazUmmmMo7ITmbP+gepYDjF1IdJPvQ5tWpONYMQ+EkNp4AAAv FMBHtqPCn3ILALbXw5nxqo9KaeR2xnDW1Q/oQ/YI4eay1wzokKIB2XF/O4sceLVcs3ng w0EA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q3si1351283pgf.680.2017.10.31.04.52.58; Tue, 31 Oct 2017 04:53:11 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932669AbdJaLu7 (ORCPT + 99 others); Tue, 31 Oct 2017 07:50:59 -0400 Received: from mx2.suse.de ([195.135.220.15]:57276 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932286AbdJaLtX (ORCPT ); Tue, 31 Oct 2017 07:49:23 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 7907CAD6D; Tue, 31 Oct 2017 11:49:21 +0000 (UTC) From: Miroslav Benes To: jpoimboe@redhat.com, jeyu@kernel.org, jikos@kernel.org Cc: pmladek@suse.com, lpechacek@suse.cz, pavel@ucw.cz, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Miroslav Benes Subject: [PATCH v3 2/2] livepatch: force transition process to finish Date: Tue, 31 Oct 2017 12:48:53 +0100 Message-Id: <20171031114853.841-3-mbenes@suse.cz> X-Mailer: git-send-email 2.14.3 In-Reply-To: <20171031114853.841-1-mbenes@suse.cz> References: <20171031114853.841-1-mbenes@suse.cz> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org If a task sleeps in a set of patched functions uninterruptedly, it could block the whole transition process indefinitely. Thus it may be useful to clear its TIF_PATCH_PENDING to allow the process to finish. Admin can do that now by writing to force sysfs attribute in livepatch sysfs directory. TIF_PATCH_PENDING is then cleared for all tasks and the transition can finish successfully. Important note! Use wisely. Admin must be sure that it is safe to execute such action. This means that it must be checked that by doing so the consistency model guarantees are not violated. Signed-off-by: Miroslav Benes --- Documentation/ABI/testing/sysfs-kernel-livepatch | 10 +++++++++ Documentation/livepatch/livepatch.txt | 24 +++++++++++++++------ kernel/livepatch/core.c | 27 ++++++++++++++++++++++++ kernel/livepatch/transition.c | 25 ++++++++++++++++++++++ kernel/livepatch/transition.h | 1 + 5 files changed, 81 insertions(+), 6 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-kernel-livepatch b/Documentation/ABI/testing/sysfs-kernel-livepatch index 22f6267836c2..105f617008f1 100644 --- a/Documentation/ABI/testing/sysfs-kernel-livepatch +++ b/Documentation/ABI/testing/sysfs-kernel-livepatch @@ -42,6 +42,16 @@ Contact: live-patching@vger.kernel.org course of an existing transition. Writing 1 sends a signal to all remaining blocking tasks. +What: /sys/kernel/livepatch//force +Date: Oct 2017 +KernelVersion: 4.15.0 +Contact: live-patching@vger.kernel.org +Description: + A writable attribute that allows administrator to affect the + course of an existing transition. Writing 1 clears + TIF_PATCH_PENDING flag of all tasks and thus forces the tasks to + the patched or unpatched state. + What: /sys/kernel/livepatch// Date: Nov 2014 KernelVersion: 3.19.0 diff --git a/Documentation/livepatch/livepatch.txt b/Documentation/livepatch/livepatch.txt index 6694530d0894..a5f60b96e7b9 100644 --- a/Documentation/livepatch/livepatch.txt +++ b/Documentation/livepatch/livepatch.txt @@ -179,10 +179,22 @@ can be signaled with SIGSTOP and SIGCONT to force them to change their patched state. Administrator can also affect a transition through -/sys/kernel/livepatch//signal attribute. Writing 1 to the attribute sends -a signal to all remaining blocking tasks. This is an alternative for -SIGSTOP/SIGCONT approach mentioned in the previous paragraph. It should also be -less harmful to the system. +/sys/kernel/livepatch//signal and /sys/kernel/livepatch//force +attributes. Writing 1 to the signal attribute sends a signal to all remaining blocking +tasks. This is an alternative for SIGSTOP/SIGCONT approach mentioned in the +previous paragraph. It should also be less harmful to the system. Writing 1 to +the force attribute clears TIF_PATCH_PENDING flag of all tasks and thus forces +the tasks to the patched state. + +Important note! Use "force" attribute wisely. Administrator must be sure that +it is safe to execute such action. This means that it must be checked that by +doing so the consistency model guarantees are not violated. First, administrator +needs to check which tasks are not yet (un)patched (see /proc//patch_state) +and why (which functions they're sleeping on. /proc//stack may help here.). +Second, the decision depends on which functions are (un)patched and what is the +nature of a livepatch. If there is a relation between the two points, "force" +may cause bad things to your system. Generally, administrator should not use +this feature without being advised to do so by the livepatch author (vendor). 3.1 Adding consistency model support to new architectures @@ -441,8 +453,8 @@ Information about the registered patches can be found under /sys/kernel/livepatch. The patches could be enabled and disabled by writing there. -/sys/kernel/livepatch//signal attribute allows administrator to affect a -patching operation. +/sys/kernel/livepatch//signal and /sys/kernel/livepatch//force +attributes allow administrator to affect a patching operation. See Documentation/ABI/testing/sysfs-kernel-livepatch for more details. diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c index b7c60662baf3..674ebdf34085 100644 --- a/kernel/livepatch/core.c +++ b/kernel/livepatch/core.c @@ -441,6 +441,7 @@ EXPORT_SYMBOL_GPL(klp_enable_patch); * /sys/kernel/livepatch//enabled * /sys/kernel/livepatch//transition * /sys/kernel/livepatch//signal + * /sys/kernel/livepatch//force * /sys/kernel/livepatch// * /sys/kernel/livepatch/// */ @@ -539,13 +540,39 @@ static ssize_t signal_store(struct kobject *kobj, struct kobj_attribute *attr, return count; } +static ssize_t force_store(struct kobject *kobj, struct kobj_attribute *attr, + const char *buf, size_t count) +{ + int ret; + bool val; + + /* + * klp_mutex lock is not grabbed here intentionally. It is not really + * needed. The race window is harmless and grabbing the lock would only + * hold the action back. + */ + if (!klp_transition_patch) + return -EINVAL; + + ret = kstrtobool(buf, &val); + if (ret) + return ret; + + if (val) + klp_force_transitions(); + + return count; +} + static struct kobj_attribute enabled_kobj_attr = __ATTR_RW(enabled); static struct kobj_attribute transition_kobj_attr = __ATTR_RO(transition); static struct kobj_attribute signal_kobj_attr = __ATTR_WO(signal); +static struct kobj_attribute force_kobj_attr = __ATTR_WO(force); static struct attribute *klp_patch_attrs[] = { &enabled_kobj_attr.attr, &transition_kobj_attr.attr, &signal_kobj_attr.attr, + &force_kobj_attr.attr, NULL }; diff --git a/kernel/livepatch/transition.c b/kernel/livepatch/transition.c index 6700d3b22615..7b17a8889697 100644 --- a/kernel/livepatch/transition.c +++ b/kernel/livepatch/transition.c @@ -617,3 +617,28 @@ void klp_force_signals(void) } read_unlock(&tasklist_lock); } + +/* + * Drop TIF_PATCH_PENDING of all tasks on admin's request. This forces an + * existing transition to finish. + * + * NOTE: klp_update_patch_state(task) requires the task to be inactive or + * 'current'. This is not the case here and the consistency model could be + * broken. Administrator, who is the only one to execute the + * klp_force_transitions(), has to be aware of this. + */ +void klp_force_transitions(void) +{ + struct task_struct *g, *task; + unsigned int cpu; + + pr_warn("forcing remaining tasks to the patched state\n"); + + read_lock(&tasklist_lock); + for_each_process_thread(g, task) + klp_update_patch_state(task); + read_unlock(&tasklist_lock); + + for_each_possible_cpu(cpu) + klp_update_patch_state(idle_task(cpu)); +} diff --git a/kernel/livepatch/transition.h b/kernel/livepatch/transition.h index 6c480057539a..da3be48d36bb 100644 --- a/kernel/livepatch/transition.h +++ b/kernel/livepatch/transition.h @@ -11,5 +11,6 @@ void klp_start_transition(void); void klp_try_complete_transition(void); void klp_reverse_transition(void); void klp_force_signals(void); +void klp_force_transitions(void); #endif /* _LIVEPATCH_TRANSITION_H */ -- 2.14.3 From 1583568388868345922@xxx Thu Nov 09 06:21:40 +0000 2017 X-GM-THRID: 1583495974916316527 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread