From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Jiri Kosina <jikos@kernel.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
Seth Jennings <sjenning@redhat.com>,
Vojtech Pavlik <vojtech@suse.com>,
linux-kernel@vger.kernel.org, live-patching@vger.kernel.org,
Miroslav Benes <mbenes@suse.cz>
Subject: Re: [PATCH v4] livepatch: Cleanup module page permission changes
Date: Fri, 4 Dec 2015 07:27:24 -0600 [thread overview]
Message-ID: <20151204132724.GH11394@treble.redhat.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1512040105280.9922@cbobk.fhfr.pm>
On Fri, Dec 04, 2015 at 01:11:29AM +0100, Jiri Kosina wrote:
> On Thu, 3 Dec 2015, Josh Poimboeuf wrote:
>
> > Calling set_memory_rw() and set_memory_ro() for every iteration of the
> > loop in klp_write_object_relocations() is messy, inefficient, and
> > error-prone.
> >
> > Change all the read-only pages to read-write before the loop and convert
> > them back to read-only again afterwards.
> >
> > Suggested-by: Miroslav Benes <mbenes@suse.cz>
> > Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
> > ---
> > Based on the following branches:
> > - git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching.git for-4.5/core
> > - git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git modules-next
> >
> > - v4: rebase onto Chris's sympos changes
> > - v3: use new module_{disable,enable}_ro() functions (in linux-next)
>
> Rusty,
>
> how would you like to handle this cross-tree dependency?
>
> My proposals:
>
> (1) I pull your 'modules-next' branch, apply this patch on top, and wait
> for your merge with Linus and send merge request afterwards
> (2) If you are okay with rebasing your tree (seems like this is
> ocassionally happening), how about you prepare a branch that'd have
> just b3212ec77 ("module: keep percpu symbols in module's symtab") on
> top of some common base, I merge it, and the cross-dependency is gone
> (3) I cherry-pick b3212ec77 ("module: keep percpu symbols in
> module's symtab") from your tree, and apply this on top. git will
> handle duplicate commits when Linus merges both just fine
> (4) I sign this patch off and you merge it
>
> (4) seems really outside the regular process. (1) is really tricky wrt.
> coordination of timing during the merge window. I'd prefer (2) (more
> git-ish way of doing things, but would require you rebasing your tree) or
> eventually (3) (git will handle this with grace).
[ off-list ]
Quick question. Just curious, because I'm new at this...
My impression was that #1 was standard operating procedure. Merge a
(non-rebasable) modules branch into livepatch, and then make sure to
submit the livepatch pull request after Rusty sends his, with a note in
the mail to Linus stating the dependency. That seems pretty
straightforward to me. Or am I missing something?
--
Josh
next prev parent reply other threads:[~2015-12-04 13:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-03 22:33 [PATCH v4] livepatch: Cleanup module page permission changes Josh Poimboeuf
2015-12-04 0:11 ` Jiri Kosina
2015-12-04 1:45 ` Rusty Russell
2015-12-04 21:54 ` Jiri Kosina
2015-12-04 13:27 ` Josh Poimboeuf [this message]
2015-12-04 13:30 ` Josh Poimboeuf
2015-12-04 21:57 ` Jiri Kosina
2015-12-04 22:07 ` Josh Poimboeuf
2015-12-04 14:17 ` Petr Mladek
2015-12-04 21:54 ` Jiri Kosina
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=20151204132724.GH11394@treble.redhat.com \
--to=jpoimboe@redhat.com \
--cc=jikos@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=rusty@rustcorp.com.au \
--cc=sjenning@redhat.com \
--cc=vojtech@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