linux-kernel - Re: [RFC PATCH] livepatch: allow removal of a disabled patch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 3 May 2016 21:39:48 -0500
From:	Josh Poimboeuf <jpoimboe@...hat.com>
To:	Jiri Kosina <jikos@...nel.org>
Cc:	Miroslav Benes <mbenes@...e.cz>, jeyu@...hat.com, pmladek@...e.com,
	jslaby@...e.cz, live-patching@...r.kernel.org,
	linux-kernel@...r.kernel.org, huawei.libin@...wei.com,
	minfei.huang@...oo.com
Subject: Re: [RFC PATCH] livepatch: allow removal of a disabled patch

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