From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752573AbcEWVft (ORCPT ); Mon, 23 May 2016 17:35:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56463 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752540AbcEWVfq (ORCPT ); Mon, 23 May 2016 17:35:46 -0400 Date: Mon, 23 May 2016 17:35:41 -0400 From: Jessica Yu To: Petr Mladek Cc: jpoimboe@redhat.com, mbenes@suse.cz, jikos@kernel.org, jslaby@suse.cz, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, huawei.libin@huawei.com, minfei.huang@yahoo.com Subject: Re: livepatch: Avoid possible race when releasing the patch Message-ID: <20160523213540.GC12954@packer-debian-8-amd64.digitalocean.com> References: <1464018848-4303-1-git-send-email-pmladek@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <1464018848-4303-1-git-send-email-pmladek@suse.com> X-OS: Linux eisen.io 3.16.0-4-amd64 x86_64 User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 23 May 2016 21:35:45 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org +++ Petr Mladek [23/05/16 17:54 +0200]: >There was a long discussion about a possible race with sysfs, kobjects >when removing an unused livepatch, see >https://lkml.kernel.org/g/%3C1462190242-24731-1-git-send-email-mbenes@suse.cz%3E > >This patch set tries to implement what looked the most preferred solution >from the discussion. I did my best to keep the patch definition simple. >But I am not super happy with the result. > >I send the current state before I spent even more time on different >approaches. > >I personally think that we might get better result if we declare >some limited structures, define them statically and then copy all >data into the final structures in a single call. I did not implement >this because it was weird on the first look but I am not sure now. > >But even more I would prefer the solution with the completion. >It is already used by the module framework. It does not look >that hacky to me after all. Hi Petr, thanks a lot for the RFC and for exploring this possible solution. I haven't reviewed the patches thoroughly yet, but at first glance I admit that I did not think through how much this approach would complicate the livepatch API, and the new intermediary functions do seem like overkill in response to the original kobject problem.. I looked at how the module loader used the completion, and in fact it is used to remedy a nearly identical problem with DEBUG_KOBJ_RELEASE (see commit 942e443 "Fix mod->mkobj.kobj potentially freed too early"), and Miroslav's original solution pretty much took the same approach. We could even mirror that approach and have something like klp_kobject_put() (much like mod_kobject_put()) to package up the kobject_put/wait_for_completion calls, but that is purely a matter of taste. Anyway, I am just beginning to lean towards the completion solution again (sorry for jumping back and forth :-/), but we can play with this patchset a bit more and see if we can come up with something reasonable. Thanks, Jessica