From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Jiri Kosina <jikos@kernel.org>
Cc: Miroslav Benes <mbenes@suse.cz>,
jeyu@redhat.com, pmladek@suse.com, jslaby@suse.cz,
live-patching@vger.kernel.org, linux-kernel@vger.kernel.org,
huawei.libin@huawei.com, minfei.huang@yahoo.com
Subject: Re: [RFC PATCH] livepatch: allow removal of a disabled patch
Date: Tue, 3 May 2016 21:39:48 -0500 [thread overview]
Message-ID: <20160504023948.ttb3ko2wnicwruwy@treble> (raw)
In-Reply-To: <alpine.LNX.2.00.1605040024010.27942@cbobk.fhfr.pm>
On Wed, May 04, 2016 at 12:31:12AM +0200, Jiri Kosina wrote:
> On Tue, 3 May 2016, Josh Poimboeuf wrote:
>
> > > 1. Do we really need a completion? If I am not missing something
> > > kobject_del() always waits for sysfs callers to leave thanks to kernfs
> > > active protection.
> >
> > What do you mean by "kernfs active protection"? I see that
> > kernfs_remove() gets the kernfs_mutex lock, but I can't find anywhere
> > that a write to a sysfs file uses that lock.
> >
> > I'm probably missing something...
>
> I don't want to speak on Miroslav's behalf, but I'm pretty sure that what
> he has on mind is per-kernfs_node active refcounting kernfs does (see
> kernfs_node->active, and especially it's usage in __kernfs_remove()).
>
> More specifically, execution of store() and show() sysfs callbacks is
> guaranteed (by kernfs) to happen with that particular attribute's active
> reference held for reading (and that makes it impossible for that
> attribute to vanish prematurely).
Thanks, that makes sense.
So what exactly is the problem the completion is trying to solve? Is it
to ensure that the kobject has been cleaned up before it returns to the
caller, in case the user wants to call klp_register() again after
unregistering?
If so, that's quite an unusual use case which I think we should just
consider unsupported. In fact, if you try to do it, kobject_init()
complains loudly because kobj->state_initialized is still 1 because
kobjects aren't meant to be reused like that.
--
Josh
next prev parent reply other threads:[~2016-05-04 2:39 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-02 11:57 Miroslav Benes
2016-05-02 15:08 ` Josh Poimboeuf
2016-05-03 8:16 ` Miroslav Benes
2016-05-31 23:13 ` Jiri Kosina
2016-05-03 21:37 ` Josh Poimboeuf
2016-05-03 22:31 ` Jiri Kosina
2016-05-04 2:39 ` Josh Poimboeuf [this message]
2016-05-04 3:36 ` Josh Poimboeuf
2016-05-04 11:58 ` Miroslav Benes
2016-05-04 13:14 ` Josh Poimboeuf
2016-05-04 14:35 ` Miroslav Benes
2016-05-04 16:14 ` Josh Poimboeuf
2016-05-05 8:28 ` Miroslav Benes
2016-05-05 13:27 ` Josh Poimboeuf
2016-05-05 14:25 ` Miroslav Benes
2016-05-05 15:04 ` Josh Poimboeuf
2016-05-05 21:08 ` Jiri Kosina
2016-05-06 0:42 ` Jessica Yu
2016-05-06 7:51 ` Miroslav Benes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160504023948.ttb3ko2wnicwruwy@treble \
--to=jpoimboe@redhat.com \
--cc=huawei.libin@huawei.com \
--cc=jeyu@redhat.com \
--cc=jikos@kernel.org \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=minfei.huang@yahoo.com \
--cc=pmladek@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®