Hi James,
Today's linux-next merge of the security-testing tree got a conflicts in
arch/arm/kernel/signal.c between commit
369842658a36bcea28ecb643ba4bdb53919330dd ("ARM: 5677/1: ARM support for
TIF_RESTORE_SIGMASK/pselect6/ppoll/epoll_pwait") from the arm tree and
commits d0420c83f39f79afb82010c2d2cafd150eef651b ("KEYS: Extend
TIF_NOTIFY_RESUME to (almost) all architectures [try #6]") and
ee18d64c1f632043a02e6f5ba5e045bb26a5465f ("KEYS: Add a keyctl to install
a process's session keyring on its parent [try #6]") from the
security-testing tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell [email protected]
diff --cc arch/arm/kernel/signal.c
index f7194e4,ea4ad3a..0000000
--- a/arch/arm/kernel/signal.c
+++ b/arch/arm/kernel/signal.c
@@@ -694,5 -706,12 +694,12 @@@ asmlinkage voi
do_notify_resume(struct pt_regs *regs, unsigned int thread_flags, int syscall)
{
if (thread_flags & _TIF_SIGPENDING)
- do_signal(¤t->blocked, regs, syscall);
+ do_signal(regs, syscall);
+
+ if (thread_flags & _TIF_NOTIFY_RESUME) {
+ clear_thread_flag(TIF_NOTIFY_RESUME);
+ tracehook_notify_resume(regs);
+ if (current->replacement_session_keyring)
+ key_replace_session_keyring();
+ }
}
Hi Russell,
On Thu, 3 Sep 2009 15:47:00 +1000 Stephen Rothwell <[email protected]> wrote:
>
> Today's linux-next merge of the security-testing tree got a conflicts in
> arch/arm/kernel/signal.c between commit
> 369842658a36bcea28ecb643ba4bdb53919330dd ("ARM: 5677/1: ARM support for
> TIF_RESTORE_SIGMASK/pselect6/ppoll/epoll_pwait") from the arm tree and
> commits d0420c83f39f79afb82010c2d2cafd150eef651b ("KEYS: Extend
> TIF_NOTIFY_RESUME to (almost) all architectures [try #6]") and
> ee18d64c1f632043a02e6f5ba5e045bb26a5465f ("KEYS: Add a keyctl to install
> a process's session keyring on its parent [try #6]") from the
> security-testing tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.
This is now a conflict between the arm tree and Linus' tree (as the
security-testing tree has been merged).
> diff --cc arch/arm/kernel/signal.c
> index f7194e4,ea4ad3a..0000000
> --- a/arch/arm/kernel/signal.c
> +++ b/arch/arm/kernel/signal.c
> @@@ -694,5 -706,12 +694,12 @@@ asmlinkage voi
> do_notify_resume(struct pt_regs *regs, unsigned int thread_flags, int syscall)
> {
> if (thread_flags & _TIF_SIGPENDING)
> - do_signal(¤t->blocked, regs, syscall);
> + do_signal(regs, syscall);
> +
> + if (thread_flags & _TIF_NOTIFY_RESUME) {
> + clear_thread_flag(TIF_NOTIFY_RESUME);
> + tracehook_notify_resume(regs);
> + if (current->replacement_session_keyring)
> + key_replace_session_keyring();
> + }
> }
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Mon, Sep 14, 2009 at 01:03:55PM +1000, Stephen Rothwell wrote:
> This is now a conflict between the arm tree and Linus' tree (as the
> security-testing tree has been merged).
That's going to be a problem then - I've sent Linus a pull request last
Saturday, and so my tree is now frozen pending a response from Linus.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Mon, 14 Sep 2009 09:12:21 +0100 Russell King <[email protected]> wrote:
>
> On Mon, Sep 14, 2009 at 01:03:55PM +1000, Stephen Rothwell wrote:
> > This is now a conflict between the arm tree and Linus' tree (as the
> > security-testing tree has been merged).
>
> That's going to be a problem then - I've sent Linus a pull request last
> Saturday, and so my tree is now frozen pending a response from Linus.
You could, of course, send an email to Linus saying something like
"linux-next has shown that you will get a conflict in
arch/arm/kernel/signal.c when you merge the arm tree. You could fix it
like this: ... or I could merge your tree and fix it locally and let you
know when it is done."
Actually Linus is probably clever enough to fix the conflict himself -
after all, I did :-)
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Mon, Sep 14, 2009 at 06:55:00PM +1000, Stephen Rothwell wrote:
> Actually Linus is probably clever enough to fix the conflict himself -
> after all, I did :-)
In my experience, sending follow-up emails to Linus on issues to do with
pull requests doesn't work - the pull happens long before Linus reads the
follow-up email. It's entirely possible that Linus has already pulled
my tree, but hasn't published it yet - I've seen that happen several
times when I submit pull requests over a weekend.
If there's a problem, Linus will reply, possibly with a "check my
conflict resolution" or "I've not pulled, please fix it up your tree".
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: