Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp5131176ybl; Wed, 22 Jan 2020 10:54:41 -0800 (PST) X-Google-Smtp-Source: APXvYqzIoKdJiXy74WwaYR1a2MAU0w6EkfYem9cH0Weoyn+Gm3W58l3j0cGowy5uxAXWN1g3Q00L X-Received: by 2002:a9d:24e8:: with SMTP id z95mr8550186ota.5.1579719281599; Wed, 22 Jan 2020 10:54:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579719281; cv=none; d=google.com; s=arc-20160816; b=yqcAJolSBUd8hCzUyiKziltc2o4Pbe8691Z5VulcXyaaCTPaHFDwNle5vn8ILi9Pui A91cFadfq0v/roWN8GeQwHLIvbLoUjKW4cIZYmfKXBnyoyJXlNHmZK1B9rVwmZg7+BPF fGZA7dL8GAX+Z12JfcHXhBeYgzP6+yWMHOtqRhBHrpwk5SvsvpwL4uT5WqzcJeasOiae +Ed/oIxmh1wwJPgCEj278VX4Xxat/Ev2i16s7EdksrM6x8xjMEbv9dozCSSWxl01eqWU tYt9TrRfXM2B61G+CiwzDbfj/l5YNvxLPKCZjZgTRNgh67Jr6CuL/Fc5+MP6GQU3egKO KrKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=AacXIVvW/L9Wi/tQd6CQ3WlW5xZVTV3hdmJ5WDrZQuI=; b=eBRqGTm08Ba6euZ8gUAahHVldd+pQRL2xz09bnysW0taSyJic6jZEFh+EGQe0VNTLo 6esD74AnTTKIpOI4USB/WejbJ+fVCWtCUqKjqbj1OrYHsjBHHZBzSw2xNFmceO5hRSRX JBI1QUHSVRnjRsdwilLuVeXx2yU1UufNw3O/iE5IWHYnijaj9roifwhoWVvs7wrjA/6A spbXIGiWVo2RKTjMEFOais2aeBS0YqLf40ztOwTIDKB8ZheaC8Bx1AgfD8zGCrBrt1XK ssaNZyNWFSX8reHvFuEPa7B0v3trkhqciWDJgu8bEup9TfDqoWnpjk68LSvzUScqMrb1 rNNg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TcMDoz2b; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s22si21547572oij.35.2020.01.22.10.54.29; Wed, 22 Jan 2020 10:54:41 -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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TcMDoz2b; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728900AbgAVSvz (ORCPT + 99 others); Wed, 22 Jan 2020 13:51:55 -0500 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:39479 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726026AbgAVSvy (ORCPT ); Wed, 22 Jan 2020 13:51:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579719113; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AacXIVvW/L9Wi/tQd6CQ3WlW5xZVTV3hdmJ5WDrZQuI=; b=TcMDoz2b4nBj2FRpVN1NNbovfP2YxQIlUTNtZogjsxVvl4H6Mrf5XvEM7oEzS+vSl7ohc0 WfZ8ExiyLgHm2RUscPMgedOvNTP0YUbQqursZR/tdqe4DwUYfj81sY7mIQw3cwGnf1+IIa UCpFlNFiOy3wvT1/zE8oezHmL1q7Tpg= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-38-2slksOrWPoOmy2_535dE_w-1; Wed, 22 Jan 2020 13:51:50 -0500 X-MC-Unique: 2slksOrWPoOmy2_535dE_w-1 Received: by mail-wr1-f71.google.com with SMTP id c6so376910wrm.18 for ; Wed, 22 Jan 2020 10:51:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=AacXIVvW/L9Wi/tQd6CQ3WlW5xZVTV3hdmJ5WDrZQuI=; b=kW1dS2Q/Grm/4axaROvZXFRQax3UWOSXDoNOkiT3UtVOftCc+fdfM2+Wx3zZrqPUCx dm6ePNQSZ46RDl04qzsgp//gL/I6Tg74rR370tzz88y5pcd4Xc8ObLVAEClpW0vDEbUd Ib3xfyNtZXwanKz7nw50vVn3QmqCifCZhV62bCsbI0YobAHaectMKz1ALJOBTD7VJbMs ZbickFpFQ6t7Jzxa+a36ga4GBKtLMUyUKmA8SO7nvv5jxh6/foiPOQX+64MDGyOIFjcx axGNZiAy0DLAP9nTrbRMd/v9LEOAiErIN/sF245tpucURLTKiCjRyh28trCaz1U5ofEX r31A== X-Gm-Message-State: APjAAAWCPvWMyV/4HV08hq+P+eaEuEh4kB0w0GlwuwaictIPQi4P7NIB 8QfQici7HkFnG7Kvu4w2OmjZpa8pSdlVq6yCZ3msdMrRbod0lV44Bh6PNO6QmgmxqKrMzxgnyFL mUaJRvXrMCD0o4goYyssQM3I9 X-Received: by 2002:a7b:cf0d:: with SMTP id l13mr4555116wmg.13.1579719109389; Wed, 22 Jan 2020 10:51:49 -0800 (PST) X-Received: by 2002:a7b:cf0d:: with SMTP id l13mr4555090wmg.13.1579719109177; Wed, 22 Jan 2020 10:51:49 -0800 (PST) Received: from [192.168.1.81] (host81-140-166-164.range81-140.btcentralplus.com. [81.140.166.164]) by smtp.gmail.com with ESMTPSA id v17sm58395781wrt.91.2020.01.22.10.51.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Jan 2020 10:51:48 -0800 (PST) Subject: Re: [POC 09/23] livepatch: Handle race when livepatches are reloaded during a module load To: Petr Mladek , Jiri Kosina , Josh Poimboeuf , Miroslav Benes Cc: Joe Lawrence , Kamalesh Babulal , Nicolai Stange , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org References: <20200117150323.21801-1-pmladek@suse.com> <20200117150323.21801-10-pmladek@suse.com> From: Julien Thierry Message-ID: <9f79bff4-42b2-ad1e-6ca6-a3464ab56ef4@redhat.com> Date: Wed, 22 Jan 2020 18:51:47 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: <20200117150323.21801-10-pmladek@suse.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Petr, On 1/17/20 3:03 PM, Petr Mladek wrote: > klp_module_coming() might fail to load a livepatch module when > the related livepatch gets reloaded in the meantime. > > Detect this situation by adding a timestamp into struct klp_patch. > local_clock is enough because klp_mutex must be released and taken > several times during this scenario. > > Signed-off-by: Petr Mladek > --- > include/linux/livepatch.h | 2 ++ > kernel/livepatch/core.c | 9 +++++---- > 2 files changed, 7 insertions(+), 4 deletions(-) > > diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h > index a4567c17a9f2..feb33f023f9f 100644 > --- a/include/linux/livepatch.h > +++ b/include/linux/livepatch.h > @@ -155,6 +155,7 @@ struct klp_state { > * @obj_list: dynamic list of the object entries > * @enabled: the patch is enabled (but operation may be incomplete) > * @forced: was involved in a forced transition > + * ts: timestamp when the livepatch has been loaded Nit: Missing '@'. > * @free_work: patch cleanup from workqueue-context > * @finish: for waiting till it is safe to remove the patch module > */ > @@ -171,6 +172,7 @@ struct klp_patch { > struct list_head obj_list; > bool enabled; > bool forced; > + u64 ts; > struct work_struct free_work; > struct completion finish; > }; > diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c > index 34e3ee2be7ef..8e693c58b736 100644 > --- a/kernel/livepatch/core.c > +++ b/kernel/livepatch/core.c > @@ -20,6 +20,7 @@ > #include > #include > #include > +#include > #include > #include "core.h" > #include "patch.h" > @@ -854,6 +855,7 @@ static int klp_init_patch_early(struct klp_patch *patch) > kobject_init(&patch->kobj, &klp_ktype_patch); > patch->enabled = false; > patch->forced = false; > + patch->ts = local_clock(); > INIT_WORK(&patch->free_work, klp_free_patch_work_fn); > init_completion(&patch->finish); > > @@ -1324,6 +1326,7 @@ int klp_module_coming(struct module *mod) > { > char patch_name[MODULE_NAME_LEN]; > struct klp_patch *patch; > + u64 patch_ts; > int ret = 0; > > if (WARN_ON(mod->state != MODULE_STATE_COMING)) > @@ -1339,6 +1342,7 @@ int klp_module_coming(struct module *mod) > continue; > > strncpy(patch_name, patch->obj->patch_name, sizeof(patch_name)); > + patch_ts = patch->ts; > mutex_unlock(&klp_mutex); > > ret = klp_try_load_object(patch_name, mod->name); > @@ -1346,14 +1350,11 @@ int klp_module_coming(struct module *mod) > * The load might have failed because the patch has > * been removed in the meantime. In this case, the > * error might be ignored. > - * > - * FIXME: It is not fully proof. The patch might have be > - * unloaded and loaded again in the mean time. > */ > mutex_lock(&klp_mutex); > if (ret) { > patch = klp_find_patch(patch_name); > - if (patch) > + if (patch && patch->ts == patch_ts) > goto err; If the timestamps differ, we have found the klp_patch, feels a bit of a waste to go through the list again without trying to load it right away. Admittedly this is to solve a race condition which should not even happen very often... > ret = 0; > } > Cheers, -- Julien Thierry