Re: linux-next: Tree for May 23 (uml)

[Stephen Rothwell]

Hi Al,

On Wed, 23 May 2012 20:37:07 +0100 Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
> On Wed, May 23, 2012 at 07:19:17PM +0100, Al Viro wrote:
> 
> > Grr...  That's a conflict between uml gaining TIF_NOTIFY_RESUME (needed
> > prereq to task_work_add() series) and patch in said series doing away
> > with explicit calls of key_replace_session_keyring().  Fixup is to remove
> > those two lines in arch/um/process.c, same as done on other architectures
> > by "keys: kill the dummy key_replace_session_keyring()" (commit c1cb001).
> > 
> > Not an issue for mainline merge, since task_work_add patchset goes later,
> > but I think I'll have to cherry-pick that series into signal.git.  And
> > probably reorder it a bit, moving the calls into tracehook_notify_resume()
> > first, with "kill the dummy..." commit removing just that single call.
> 
> Hmm...  Two solutions, take your pick:
> 
> 1)
> 	I think the minimal solution is this: I add the "move
> key_replace_session_keyring() into tracehook_notify_resume()" into signal.git
> for-next, which yields one conflict with next/akpm.  With conflict resolution
> being "take tracehook_notify_resume() from next/akpm".  I've put that
> into for-next-variant1
> 
> 2)
> 	Cherry-picked these guys into signal.git, along with the rest
> of signal prereqs for them.  Merge with next/akpm-base yields a couple
> of trivial conflicts in kernel/fork.c (with
> 	sched, mm: Rework sched_{fork,exec} node assignment
> removing INIT_LIST_HEAD right next to the place where we add one; conflict
> resolution being just keep the one Oleg adds and remove the one Peter removes)
> and in kernel/irq/manage.c (with
> 	genirq: Be more informative on irq type mismatch
> changing a couple of printks in there; conflict resolution: just remove
> exit_irq_thread() in merged variant).  That's for-next-variant2.  With that
> variant we get 5 more duplicates with next/akpm, obviously.
> 
> Stephen, which way would you prefer it handled?

So variant2 sits on top of variant1 and you are intending to push the
work in variant2 in this merge window anyway?   In that case variant2
makes sense.  The number of small conflicts don't matter to much (up to a
point anyway :-)).  Also, these cherry-picks are out of Andrew's tree,
right (so they are already in linuc-next)?  In which case I would
probably go with variant2.

-- 
Cheers,
Stephen Rothwell                    sfr@xxxxxxxxxxxxxxxx

Attachment: pgp00000.pgp
Description: PGP signature