From: Miroslav Benes <mbenes@suse.cz>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Jiri Slaby <jslaby@suse.cz>, Seth Jennings <sjenning@redhat.com>,
Jiri Kosina <jkosina@suse.cz>, Vojtech Pavlik <vojtech@suse.cz>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 8/9] livepatch: allow patch modules to be removed
Date: Tue, 17 Feb 2015 17:38:14 +0100 (CET) [thread overview]
Message-ID: <alpine.LNX.2.00.1502171728520.29490@pobox.suse.cz> (raw)
In-Reply-To: <20150217155547.GG11861@treble.redhat.com>
On Tue, 17 Feb 2015, Josh Poimboeuf wrote:
> On Mon, Feb 16, 2015 at 05:06:15PM +0100, Miroslav Benes wrote:
> > On Fri, 13 Feb 2015, Josh Poimboeuf wrote:
> >
> > > On Fri, Feb 13, 2015 at 05:17:10PM +0100, Miroslav Benes wrote:
> > > > On Fri, 13 Feb 2015, Josh Poimboeuf wrote:
> > > > > Hm, even with Jiri Slaby's suggested fix to add the completion to the
> > > > > unregister path, I still get a lockdep warning. This looks more insidious,
> > > > > related to the locking order of a kernfs lock and the klp lock. I'll need to
> > > > > look at this some more...
> > > >
> > > > Yes, I was afraid of this. Lockdep warning is a separate bug. It is caused
> > > > by taking klp_mutex in enabled_store. During rmmod klp_unregister_patch
> > > > takes klp_mutex and destroys the sysfs structure. If somebody writes to
> > > > enabled just after unregister takes the mutex and before the sysfs
> > > > removal, he would cause the deadlock, because enabled_store takes the
> > > > "sysfs lock" and then klp_mutex. That is exactly what the lockdep tells us
> > > > below.
> > > >
> > > > We can look for inspiration elsewhere. Grep for s_active through git log
> > > > of the mainline offers several commits which dealt exactly with this. Will
> > > > browse through that...
> > >
> > > Thanks Miroslav, please let me know what you find. It wouldn't surprise
> > > me if this were a very common problem.
> > >
> > > One option would be to move the enabled_store() work out to a workqueue
> > > or something.
> >
> > Yes, that is one possibility. It is not the only one.
> >
> > 1. we could replace mutex_lock in enabled_store with mutex_trylock. If the
> > lock was not acquired we would return -EBUSY. Or could we 'return
> > restart_syscall' (maybe after some tiny msleep)?
>
> Hm, doesn't that still violate the locking order rules? I thought locks
> always had to be taken in the same order -- always sysfs before klp, or
> klp before sysfs. Not sure if there would still be any deadlocks
> lurking, but lockdep might still complain.
Yes, but in this case you break the possible deadlock order. From the
lockdep report...
CPU0 CPU1
---- ----
lock(klp_mutex);
lock(s_active#70);
lock(klp_mutex);
lock(s_active#70);
CPU0 called klp_unregister_patch and CPU1 possible enabled_store in a race
window. Deadlock wouldn't be there because trylock(klp_mutex) on CPU1
would return 0 and enabled_store thus EBUSY. And in every other scenario
trylock would prevent deadlock too or klp_unregister_patch would wait on
klp_mutex (I hope I did not miss anything).
I tried it and lockdep did not complain.
And you can look at 36c38fb7144aa941dc072ba8f58b2dbe509c0345 or
5e33bc4165f3edd558d9633002465a95230effc1. They dealt with it the same way
(but it does not mean anything).
It would need more testing to be sure though.
> > 2. we could reorganize klp_unregister_patch somehow and move sysfs removal
> > out of mutex protection.
>
> Yeah, I was thinking about this too. Pretty sure we'd have to remove
> both the sysfs add and the sysfs removal from mutex protection. I like
> this option if we can get it to work.
Yes, why not.
Maybe someone else will share his opinion on this...
Miroslav
next prev parent reply other threads:[~2015-02-17 16:38 UTC|newest]
Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-09 17:31 [RFC PATCH 0/9] livepatch: consistency model Josh Poimboeuf
2015-02-09 17:31 ` [RFC PATCH 1/9] livepatch: simplify disable error path Josh Poimboeuf
2015-02-13 12:25 ` Miroslav Benes
2015-02-18 17:03 ` Petr Mladek
2015-02-18 20:07 ` Jiri Kosina
2015-02-09 17:31 ` [RFC PATCH 2/9] livepatch: separate enabled and patched states Josh Poimboeuf
2015-02-10 16:44 ` Jiri Slaby
2015-02-10 17:21 ` Josh Poimboeuf
2015-02-13 12:57 ` Miroslav Benes
2015-02-13 14:39 ` Josh Poimboeuf
2015-02-13 14:46 ` Miroslav Benes
2015-02-09 17:31 ` [RFC PATCH 3/9] livepatch: move patching functions into patch.c Josh Poimboeuf
2015-02-10 18:27 ` Jiri Slaby
2015-02-10 18:50 ` Josh Poimboeuf
2015-02-13 14:28 ` Miroslav Benes
2015-02-13 15:09 ` Josh Poimboeuf
2015-02-09 17:31 ` [RFC PATCH 4/9] livepatch: get function sizes Josh Poimboeuf
2015-02-10 18:30 ` Jiri Slaby
2015-02-10 18:53 ` Josh Poimboeuf
2015-02-09 17:31 ` [RFC PATCH 5/9] sched: move task rq locking functions to sched.h Josh Poimboeuf
2015-02-10 10:48 ` Masami Hiramatsu
2015-02-10 14:54 ` Josh Poimboeuf
2015-02-09 17:31 ` [RFC PATCH 6/9] livepatch: create per-task consistency model Josh Poimboeuf
2015-02-10 10:58 ` Masami Hiramatsu
2015-02-10 14:59 ` Josh Poimboeuf
2015-02-10 15:59 ` Miroslav Benes
2015-02-10 16:56 ` Josh Poimboeuf
2015-02-11 16:28 ` Miroslav Benes
2015-02-11 20:23 ` Josh Poimboeuf
2015-02-10 19:27 ` Seth Jennings
2015-02-10 19:32 ` Josh Poimboeuf
2015-02-11 10:21 ` Miroslav Benes
2015-02-11 20:19 ` Josh Poimboeuf
2015-02-12 10:45 ` Miroslav Benes
2015-02-12 3:21 ` Josh Poimboeuf
2015-02-12 11:56 ` Peter Zijlstra
2015-02-12 12:25 ` Jiri Kosina
2015-02-12 12:36 ` Peter Zijlstra
2015-02-12 12:39 ` Jiri Kosina
2015-02-12 12:39 ` Peter Zijlstra
2015-02-12 12:42 ` Jiri Kosina
2015-02-12 13:01 ` Josh Poimboeuf
2015-02-12 12:51 ` Josh Poimboeuf
2015-02-12 13:08 ` Peter Zijlstra
2015-02-12 13:16 ` Jiri Kosina
2015-02-12 14:20 ` Josh Poimboeuf
2015-02-12 14:27 ` Jiri Kosina
2015-02-12 13:16 ` Jiri Slaby
2015-02-12 13:35 ` Peter Zijlstra
2015-02-12 14:08 ` Jiri Kosina
2015-02-12 15:24 ` Josh Poimboeuf
2015-02-12 14:20 ` Jiri Slaby
2015-02-12 14:32 ` Jiri Kosina
2015-02-18 20:17 ` Ingo Molnar
2015-02-18 20:44 ` Vojtech Pavlik
2015-02-19 9:52 ` Peter Zijlstra
2015-02-19 10:11 ` Vojtech Pavlik
2015-02-19 10:51 ` Peter Zijlstra
2015-02-12 13:26 ` Jiri Slaby
2015-02-12 15:48 ` Josh Poimboeuf
2015-02-14 11:40 ` Jiri Slaby
2015-02-17 14:59 ` Josh Poimboeuf
2015-02-16 14:19 ` Miroslav Benes
2015-02-17 15:10 ` Josh Poimboeuf
2015-02-17 15:48 ` Miroslav Benes
2015-02-17 16:01 ` Josh Poimboeuf
2015-02-18 12:42 ` Miroslav Benes
2015-02-18 13:15 ` Josh Poimboeuf
2015-02-18 13:42 ` Miroslav Benes
2015-02-09 17:31 ` [RFC PATCH 7/9] proc: add /proc/<pid>/universe to show livepatch status Josh Poimboeuf
2015-02-10 18:47 ` Jiri Slaby
2015-02-10 18:57 ` Josh Poimboeuf
2015-02-09 17:31 ` [RFC PATCH 8/9] livepatch: allow patch modules to be removed Josh Poimboeuf
2015-02-10 19:02 ` Jiri Slaby
2015-02-10 19:57 ` Josh Poimboeuf
2015-02-11 10:55 ` Jiri Slaby
2015-02-11 18:39 ` Josh Poimboeuf
2015-02-12 15:22 ` Miroslav Benes
2015-02-13 12:44 ` Josh Poimboeuf
2015-02-13 16:04 ` Josh Poimboeuf
2015-02-13 16:17 ` Miroslav Benes
2015-02-13 20:49 ` Josh Poimboeuf
2015-02-16 16:06 ` Miroslav Benes
2015-02-17 15:55 ` Josh Poimboeuf
2015-02-17 16:38 ` Miroslav Benes [this message]
2015-02-09 17:31 ` [RFC PATCH 9/9] livepatch: update task universe when exiting kernel Josh Poimboeuf
2015-02-16 10:16 ` Jiri Slaby
2015-02-17 14:58 ` Josh Poimboeuf
2015-02-09 23:15 ` [RFC PATCH 0/9] livepatch: consistency model Jiri Kosina
2015-02-10 3:05 ` Josh Poimboeuf
2015-02-10 7:21 ` Jiri Kosina
2015-02-10 8:57 ` Jiri Kosina
2015-02-10 14:43 ` Josh Poimboeuf
2015-02-10 11:16 ` Masami Hiramatsu
2015-02-10 15:59 ` Josh Poimboeuf
2015-02-10 17:29 ` Josh Poimboeuf
2015-02-13 10:14 ` Jiri Kosina
2015-02-13 14:19 ` Josh Poimboeuf
2015-02-13 14:22 ` Jiri Kosina
2015-02-13 14:40 ` Miroslav Benes
2015-02-13 14:55 ` Josh Poimboeuf
2015-02-13 14:41 ` Josh Poimboeuf
2015-02-24 11:27 ` Masami Hiramatsu
2015-03-10 16:23 ` Josh Poimboeuf
2015-03-10 21:02 ` Jiri Kosina
2015-03-10 21:30 ` Josh Poimboeuf
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=alpine.LNX.2.00.1502171728520.29490@pobox.suse.cz \
--to=mbenes@suse.cz \
--cc=jkosina@suse.cz \
--cc=jpoimboe@redhat.com \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=sjenning@redhat.com \
--cc=vojtech@suse.cz \
/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;
as well as URLs for NNTP newsgroup(s).