Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp8277198imu; Tue, 4 Dec 2018 06:01:06 -0800 (PST) X-Google-Smtp-Source: AFSGD/UyJ1KY6Eo76ji1nQQB5Rp19Ui1jN1I1lZK/NqGqB6CoJBycf77VAfs9gJxRZ4zfW8st+Pf X-Received: by 2002:a62:c185:: with SMTP id i127mr15759825pfg.43.1543932066374; Tue, 04 Dec 2018 06:01:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543932066; cv=none; d=google.com; s=arc-20160816; b=yC2SJmoir4Easkmfo+p4BY7t1rxJ6vq9GSGr3QWjABvpfjfS+rhwEJFdfkh0x6/Rpf g3NHnlllSlNet5i/JChRxU0b3lb+COJziMF22dzl4JBKD8G79o9gE0GLA3sXfldJKcHI Rw1IRmgapLHGnVOjgSywcedqFxpJpma8MuTVWOGSQNAipIks32JyvwpSvk9gQtm9KD/N 6Wv6TlY0GgWb6W5SWaMacPeDhv0OsI7OYI7oeT8lIgSXqAraACkv3fmL7PnqaHXmsViY 3h626xkxJ+EXrIv0MkefNrzhyTvNgUSycu2Obo+WDjMP9eenUj+BTQz20koQ+47Nom9Y mjiw== 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=sC0wD3WUl2GCL/hScrQGGnRGSkW2cxCfcLio+Mnjdsc=; b=eqGYbSGVJb8GSzz00b2ahLHlpo2ypX1ysnJvYscpGK5+2HQH4wL7I6gVz15ESLoyoR 1chxgIhC23kxWauvtuLUFg5sngWjYH8t5AHGLR5Kg/eyXCP9L0jKFeW292TQ3fc2H8S8 T5dihiyuCGgUqzaYDhmHBtVslCCjMPcv+cHB33xN/FhtJTv6KiJLenddY16bU0MiiGAE 7y02Cm7JTNZvpEqgevs3cMpbhCVmPzUkNOfTW1pSZC2dmUZv0vPqb2euljlPIMsuNkYu 21u3CEoUjeCIS/JZ+JbgFX1F/W7j8EHa+8E46a7isePfHITHaXbHemtGS4gJZ8Qn9p37 3MFg== 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 37si14950910pgw.590.2018.12.04.06.00.49; Tue, 04 Dec 2018 06:01:06 -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 S1726377AbeLDOAL (ORCPT + 99 others); Tue, 4 Dec 2018 09:00:11 -0500 Received: from mx2.suse.de ([195.135.220.15]:45606 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726045AbeLDOAL (ORCPT ); Tue, 4 Dec 2018 09:00:11 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id A9DB5ADD6; Tue, 4 Dec 2018 14:00:07 +0000 (UTC) Date: Tue, 4 Dec 2018 15:00:07 +0100 From: Petr Mladek To: Miroslav Benes Cc: Jiri Kosina , Josh Poimboeuf , 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: <20181204140007.si7l2glbsgaj2dbf@pathway.suse.cz> References: <20181129094431.7801-1-pmladek@suse.com> <20181129094431.7801-4-pmladek@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Mon 2018-12-03 15:59:57, Miroslav Benes wrote: > On Thu, 29 Nov 2018, Petr Mladek wrote: > > > -static int klp_init_patch(struct klp_patch *patch) > > +/* Init operations that must succeed before klp_free_patch() can be called. */ > > +static int klp_init_patch_before_free(struct klp_patch *patch) > > There is no klp_free_patch() now, so the comment is not correct. Also I > don't know if the function name is ideal, but I don't have a better one. > > > { > > struct klp_object *obj; > > - int ret; > > + struct klp_func *func; > > > > if (!patch->objs) > > return -EINVAL; > > > > - mutex_lock(&klp_mutex); > > - > > + INIT_LIST_HEAD(&patch->list); > > + patch->kobj_alive = false; > > patch->enabled = false; > > init_completion(&patch->finish); > > > > - ret = kobject_init_and_add(&patch->kobj, &klp_ktype_patch, > > - klp_root_kobj, "%s", patch->mod->name); > > + klp_for_each_object(patch, obj) { > > + if (!obj->funcs) > > + return -EINVAL; > > + > > + obj->kobj_alive = false; > > + > > + klp_for_each_func(obj, func) > > + func->kobj_alive = false; > > + } > > + > > + return 0; > > +} > > + > > +static int klp_init_patch(struct klp_patch *patch) > > +{ > > + struct klp_object *obj; > > + int ret; > > + > > + mutex_lock(&klp_mutex); > > + > > + ret = klp_init_patch_before_free(patch); > > if (ret) { > > mutex_unlock(&klp_mutex); > > return ret; > > } > > > > + ret = kobject_init_and_add(&patch->kobj, &klp_ktype_patch, > > + klp_root_kobj, "%s", patch->mod->name); > > + if (ret) > > + goto free; > > Is this intentional? It should be sufficient (and it was before the patch) to > unlock the mutex and return ret. We do not need to free anything here. Only > klp_patch instance was initialized and that is all. It will get needed later when try_module_get() is moved into klp_init_patch_before_free(), see the 5th patch. I'll do it in the right order in v15. BTW: I remember that I did this by intention. I updated the patchset step by step according to the feedback. The init_before_free() was growing and growing. I did many rebases, shuffling changes between patches, just wanted to be on the safe side, and maybe save one hunk. But it seems that no shortcut can slip the careful review ;-) > Otherwise it looks good. kobj_alive feels safer than state_initialized. Yup. Best Regards, Petr