Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1855538imu; Fri, 14 Dec 2018 01:34:24 -0800 (PST) X-Google-Smtp-Source: AFSGD/Uh8g6YCbmK7VAInp14DAYNG2XFdADE/iTdbvhbzMnsPrRxj5kmjrAs2Tw7Oa1Rv/5dYb+a X-Received: by 2002:a17:902:1008:: with SMTP id b8mr2121201pla.252.1544780064068; Fri, 14 Dec 2018 01:34:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544780064; cv=none; d=google.com; s=arc-20160816; b=LZSF84ISdomZGe/C21SRnp0gMv8PKoTj8QQY1HJqNDLGKelPi9AkUj9cM3NnGiwU9o x/C+InSMBJgYXKxoMHd8XGxfON3oTd++BR2hp/CNiG8sEhlLynDWjcVZ/msU2V5Pzz7s 0OKILiZUC0p1VfhOQLAyw38vQ00XX13k9rrjsDJH3kqJf32CryeeQxxmTsEc/A11bK4S 5OVX+vMk02BQ9JlgSKevNGtg0Ru0jyUEgJWXfHPpHE14m2xC7HAg05jI9zP8/i9NxbcF O6UCuT1lzEqWv8gtP8lghRN5Zf0kjaeIJhwEBwQBSHWV8E03fGSwMCF1JiLZzA8js674 MWlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=YI72wU9h+SVPedtBFitMO6BUOQ/Fqy2f+hVCDEPFCqY=; b=nb8LrsKd+15CXr490gC1TNdxUHwoWtSyUWJ/0lRNIiOBRT9lcAiQBmNsDcnJYqibxu dGtcZeaISsFBzArSYEvXlENrHZuvEYVFWfuhqvsqrtxd7oZxvm1DBH+s3Fu0Sn2Tfz6U DGOAK7R0j81/Eoiksi5nGECSr5xQKegYgFJ+y/PL7ipQtmk2PAYP11+oy7NCQpzkX9Q+ Li0LRnb+7veT4vM9d79CsxqMAs+4na5RNqeMF+iylsHQFFzyren+VeraJhStu8kT8wOI kNini08gU+MeeARUAC5NbDEN1HgsE3617uAo0XYyScUavhQ81Vipm/6QElbeQO9Ilbu9 nbWA== 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 g19si3693101pgj.358.2018.12.14.01.34.09; Fri, 14 Dec 2018 01:34:24 -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 S1729117AbeLNJcE (ORCPT + 99 others); Fri, 14 Dec 2018 04:32:04 -0500 Received: from mx2.suse.de ([195.135.220.15]:45358 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727579AbeLNJcE (ORCPT ); Fri, 14 Dec 2018 04:32:04 -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 864D2AD02; Fri, 14 Dec 2018 09:32:02 +0000 (UTC) Date: Fri, 14 Dec 2018 10:32:01 +0100 From: Petr Mladek To: Josh Poimboeuf Cc: Jiri Kosina , Miroslav Benes , Jason Baron , Joe Lawrence , Evgenii Shatokhin , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Jessica Yu Subject: Re: [PATCH v14 03/11] livepatch: Consolidate klp_free functions Message-ID: <20181214093201.otrr7irvigrhwlzu@pathway.suse.cz> References: <20181129094431.7801-1-pmladek@suse.com> <20181129094431.7801-4-pmladek@suse.com> <20181213221037.qaxd5jswdrbv5oxz@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181213221037.qaxd5jswdrbv5oxz@treble> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 2018-12-13 16:10:37, Josh Poimboeuf wrote: > On Thu, Nov 29, 2018 at 10:44:23AM +0100, Petr Mladek wrote: > > +static void klp_free_funcs(struct klp_object *obj) > > { > > struct klp_func *func; > > > > - for (func = obj->funcs; func->old_name && func != limit; func++) > > - kobject_put(&func->kobj); > > + klp_for_each_func(obj, func) { > > + /* Might be called from klp_init_patch() error path. */ > > + if (func->kobj_alive) { > > + func->kobj_alive = false; > > + kobject_put(&func->kobj); > > + } > > Why does it set 'kobj_alive' to false? The value will never be read > again anyway, right? You are right. I'll remove it in v15. My intention was that it might signalize that the kobject is being freed and eventually affect the behavior of sysfs-related callbacks. But in reality, it should be handled by some per-patch flag instead of a per-object one. > Also, the name isn't quite right. The kobject is technically still > alive here, and may even continue to be alive after the kobject_put(), > if there's a sysfs reference to it somewhere. > > Maybe it should be called something like 'kobj_initialized' instead. > Then it doesn't ever need to be set to false -- unless I'm missing > something. This might cause confusion with kobj.state_initialized. This internal kobject flag is set when the reference counter is initialized. But it is true even before kobject_add() is called. We need a flag that signalizes that kobject_add() succeeded and we can and must call kobject_put(). What about calling it 'kobj_added'? Best Regards, Petr