Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7084170imu; Mon, 3 Dec 2018 07:30:55 -0800 (PST) X-Google-Smtp-Source: AFSGD/WPUpTdQDxZ4kTvctKLrKWOt629UYy0gCETY8tr3crWIbma5s0Un1q+a/NavefX/M7LIVYv X-Received: by 2002:a17:902:7848:: with SMTP id e8mr16751249pln.100.1543851054949; Mon, 03 Dec 2018 07:30:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543851054; cv=none; d=google.com; s=arc-20160816; b=ZEuQZkVzXSBhzQtZqxvPDJ/53jft4Pujq2bDifjeF8JVCc7t3VBwByMnh1aYKcGenf y9AAdAHZ7M1Fl4hClCyysOlU+H70OFw2ye42mRe/MRFpincXfZiYQzBDTHI+goCJcJVj 34HUgv0dUrtFgj6QSF3zcRBnXymQsfZKE3GbYBo5JObNt+cn0GzKBN5JJ0dTtswo3ETq q630R0BLCk59WqJsjkDsBBTnxKBOEi9OTJ6ggFaScsWOPq7be3fZKTOOhvUdPWgkUyUo zIIKs9S1rEycNQAuD8mBXjFXejlD+/kSMUJxPfCToVHOZRLDCae6tWRErsS5dxtIH1Fd dTQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=gAMDd6RwCvUxGHVG/13wmDOunkJiO5j3SWz9Yrl4DfE=; b=iF+blk+Ta8dybhMtc0Npi9Q8FPhWj39jaZYK85s+slLfaFwe6oPOjj5cAU2I1AHioK 0dE+vz9J5l1wF33N7gcSAav7LHWG0fkfINBchUjHiqFDSv4GNOxKTB/7ctecT0MjCU0T gD4VcxJwpM+/y7bVOJycJ75Oe9ugKa2Yap37PgCAV2LWhdpKS9cMI/eUkUkKV0fZo+tk R35EI/pEZS+kO1DMz2waNeyhFwG4kzZ5tHu4Et8RPG7inYuU9mI7hjxU2hdVEkWWaXmb kxEAl6AkwaPBzYvtDUnDKpU+0jgZGhDi+/J3M8L/Ke6oibdCPU1B1txAmy3DJQsfjWLP 1tew== 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 c4si13618253pfi.110.2018.12.03.07.30.33; Mon, 03 Dec 2018 07:30:54 -0800 (PST) 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 S1726717AbeLCP3h (ORCPT + 99 others); Mon, 3 Dec 2018 10:29:37 -0500 Received: from mx2.suse.de ([195.135.220.15]:41766 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726549AbeLCP3h (ORCPT ); Mon, 3 Dec 2018 10:29:37 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id A3EF0ADF2; Mon, 3 Dec 2018 15:29:33 +0000 (UTC) Date: Mon, 3 Dec 2018 16:29:32 +0100 (CET) From: Miroslav Benes To: Petr Mladek cc: Jiri Kosina , Josh Poimboeuf , Jason Baron , Joe Lawrence , Evgenii Shatokhin , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v14 04/11] livepatch: Refuse to unload only livepatches available during a forced transition In-Reply-To: <20181129094431.7801-5-pmladek@suse.com> Message-ID: References: <20181129094431.7801-1-pmladek@suse.com> <20181129094431.7801-5-pmladek@suse.com> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org You probably forgot to replace the subject with Josh's proposal. > module_put() is currently never called in klp_complete_transition() when > klp_force is set. As a result, we might keep the reference count even when > klp_enable_patch() fails and klp_cancel_transition() is called. Correct. > This might make an assumption that a module might get blocked in some > strange init state. Fortunately, it is not the case. The reference count > is ignored when mod->init fails and erroneous modules are always removed. I do not understand the paragraph and its connection to the problem (and I don't remember if I understood it previously or not and forgot to mention it). > Anyway, this might make some confusion. Instead, this patch moves > the global klp_forced flag into struct klp_patch. As a result, > we block only modules that might still be in use after a forced > transition. Newly loaded livepatches might be eventually completely > removed later. It makes sense by itself only. > It is not a big deal. But the code is at least consistent with > the reality. > > Signed-off-by: Petr Mladek > @@ -633,5 +632,7 @@ void klp_force_transition(void) > for_each_possible_cpu(cpu) > klp_update_patch_state(idle_task(cpu)); > > - klp_forced = true; > + /* Refuse unloading all livepatches. The code might be in use. */ > + list_for_each_entry(patch, &klp_patches, list) > + patch->forced = true; Is the comment necessary? If yes, I'd change it to something similar to the new subject. Thanks, Miroslav