2014-11-25 19:43:37

by Kees Cook

Subject: [PULL] seccomp update (next)

Hi,

Please pull these seccomp changes for next.

Thanks!

-Kees

The following changes since commit 5d01410fe4d92081f349b013a2e7a95429e4f2c9:

Linux 3.18-rc6 (2014-11-23 15:25:20 -0800)

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next

for you to fetch changes up to cb24de187b9a0717246f05afc0f2be070e075d80:

seccomp: Replace smp_read_barrier_depends() with lockless_dereference() (2014-11-25 11:40:24 -0800)

----------------------------------------------------------------
Improves SMP dereferencing with new macro.

----------------------------------------------------------------
Pranith Kumar (1):
seccomp: Replace smp_read_barrier_depends() with lockless_dereference()

kernel/seccomp.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)

--
Kees Cook
Chrome OS Security

2014-11-26 13:23:17

by James Morris

Subject: Re: [PULL] seccomp update (next)

On Tue, 25 Nov 2014, Kees Cook wrote:

> Hi,
>
> Please pull these seccomp changes for next.
>
> Thanks!
>
> -Kees
>
> The following changes since commit 5d01410fe4d92081f349b013a2e7a95429e4f2c9:
>
> Linux 3.18-rc6 (2014-11-23 15:25:20 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next
>
> for you to fetch changes up to cb24de187b9a0717246f05afc0f2be070e075d80:
>
> seccomp: Replace smp_read_barrier_depends() with lockless_dereference() (2014-11-25 11:40:24 -0800)
>
> ----------------------------------------------------------------
> Improves SMP dereferencing with new macro.
>
> ----------------------------------------------------------------
> Pranith Kumar (1):
> seccomp: Replace smp_read_barrier_depends() with lockless_dereference()
>
> kernel/seccomp.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>

This is what I get when pulling to my next branch:

9128 files changed, 468773 insertions(+), 340317 deletions(-)


--
James Morris
<[email protected]>

2014-11-26 21:46:24

by Stephen Rothwell

Subject: Re: [PULL] seccomp update (next)

Hi James,

On Thu, 27 Nov 2014 00:23:06 +1100 (AEDT) James Morris <[email protected]> wrote:
>
> On Tue, 25 Nov 2014, Kees Cook wrote:
>
> > Please pull these seccomp changes for next.
> >
> > Thanks!
> >
> > -Kees
> >
> > The following changes since commit 5d01410fe4d92081f349b013a2e7a95429e4f2c9:
> >
> > Linux 3.18-rc6 (2014-11-23 15:25:20 -0800)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next
> >
> > for you to fetch changes up to cb24de187b9a0717246f05afc0f2be070e075d80:
> >
> > seccomp: Replace smp_read_barrier_depends() with lockless_dereference() (2014-11-25 11:40:24 -0800)
> >
> > ----------------------------------------------------------------
> > Improves SMP dereferencing with new macro.
> >
> > ----------------------------------------------------------------
> > Pranith Kumar (1):
> > seccomp: Replace smp_read_barrier_depends() with lockless_dereference()
> >
> > kernel/seccomp.c | 7 +++----
> > 1 file changed, 3 insertions(+), 4 deletions(-)
> >
>
> This is what I get when pulling to my next branch:
>
> 9128 files changed, 468773 insertions(+), 340317 deletions(-)

That would be because your tree is based on v3.17 and Kees' is based on
v3.18-rc6 ...

--
Cheers,
Stephen Rothwell [email protected]

Attachments:

2014-11-26 21:59:14

by Kees Cook

Subject: Re: [PULL] seccomp update (next)

On Wed, Nov 26, 2014 at 1:46 PM, Stephen Rothwell <[email protected]> wrote:
> Hi James,
>
> On Thu, 27 Nov 2014 00:23:06 +1100 (AEDT) James Morris <[email protected]> wrote:
>>
>> On Tue, 25 Nov 2014, Kees Cook wrote:
>>
>> > Please pull these seccomp changes for next.
>> >
>> > Thanks!
>> >
>> > -Kees
>> >
>> > The following changes since commit 5d01410fe4d92081f349b013a2e7a95429e4f2c9:
>> >
>> > Linux 3.18-rc6 (2014-11-23 15:25:20 -0800)
>> >
>> > are available in the git repository at:
>> >
>> > git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next
>> >
>> > for you to fetch changes up to cb24de187b9a0717246f05afc0f2be070e075d80:
>> >
>> > seccomp: Replace smp_read_barrier_depends() with lockless_dereference() (2014-11-25 11:40:24 -0800)
>> >
>> > ----------------------------------------------------------------
>> > Improves SMP dereferencing with new macro.
>> >
>> > ----------------------------------------------------------------
>> > Pranith Kumar (1):
>> > seccomp: Replace smp_read_barrier_depends() with lockless_dereference()
>> >
>> > kernel/seccomp.c | 7 +++----
>> > 1 file changed, 3 insertions(+), 4 deletions(-)
>> >
>>
>> This is what I get when pulling to my next branch:
>>
>> 9128 files changed, 468773 insertions(+), 340317 deletions(-)
>
> That would be because your tree is based on v3.17 and Kees' is based on
> v3.18-rc6 ...

James, I can base on whatever you like. I can do v3.17, or even
against your security-next. It seems everyone uses something
different. :)

Thanks!

-Kees

--
Kees Cook
Chrome OS Security

2014-11-27 23:38:16

by James Morris

Subject: Re: [PULL] seccomp update (next)

On Wed, 26 Nov 2014, Kees Cook wrote:

> > That would be because your tree is based on v3.17 and Kees' is based on
> > v3.18-rc6 ...
>
> James, I can base on whatever you like. I can do v3.17, or even
> against your security-next. It seems everyone uses something
> different. :)

It's best to track my next branch as your upstream.


--
James Morris
<[email protected]>

2014-12-01 20:34:50

by Kees Cook

Subject: Re: [PULL] seccomp update (next)

On Thu, Nov 27, 2014 at 3:37 PM, James Morris <[email protected]> wrote:
> On Wed, 26 Nov 2014, Kees Cook wrote:
>
>> > That would be because your tree is based on v3.17 and Kees' is based on
>> > v3.18-rc6 ...
>>
>> James, I can base on whatever you like. I can do v3.17, or even
>> against your security-next. It seems everyone uses something
>> different. :)
>
> It's best to track my next branch as your upstream.

It'll trigger collisions with what's the x86 -next from luto's
changes. Should I just let Stephen sort that out?

-Kees

--
Kees Cook
Chrome OS Security

2014-12-01 22:56:22

by James Morris

Subject: Re: [PULL] seccomp update (next)

On Mon, 1 Dec 2014, Kees Cook wrote:

> On Thu, Nov 27, 2014 at 3:37 PM, James Morris <[email protected]> wrote:
> > On Wed, 26 Nov 2014, Kees Cook wrote:
> >
> >> > That would be because your tree is based on v3.17 and Kees' is based on
> >> > v3.18-rc6 ...
> >>
> >> James, I can base on whatever you like. I can do v3.17, or even
> >> against your security-next. It seems everyone uses something
> >> different. :)
> >
> > It's best to track my next branch as your upstream.
>
> It'll trigger collisions with what's the x86 -next from luto's
> changes. Should I just let Stephen sort that out?

Yep.

--
James Morris
<[email protected]>

2014-12-01 23:06:52

by Kees Cook

Subject: Re: [PULL] seccomp update (next)

On Mon, Dec 1, 2014 at 2:56 PM, James Morris <[email protected]> wrote:
> On Mon, 1 Dec 2014, Kees Cook wrote:
>
>> On Thu, Nov 27, 2014 at 3:37 PM, James Morris <[email protected]> wrote:
>> > On Wed, 26 Nov 2014, Kees Cook wrote:
>> >
>> >> > That would be because your tree is based on v3.17 and Kees' is based on
>> >> > v3.18-rc6 ...
>> >>
>> >> James, I can base on whatever you like. I can do v3.17, or even
>> >> against your security-next. It seems everyone uses something
>> >> different. :)
>> >
>> > It's best to track my next branch as your upstream.
>>
>> It'll trigger collisions with what's the x86 -next from luto's
>> changes. Should I just let Stephen sort that out?
>
> Yep.

Hm, it depends on 54ef6df3f3f1353d99c80c437259d317b2cd1cbd, so basing
against security-next would make the tree unbuildable. Perhaps I
should just wait for -rc1 to land first?

-Kees

--
Kees Cook
Chrome OS Security

2014-12-02 07:56:32

by James Morris

Subject: Re: [PULL] seccomp update (next)

On Mon, 1 Dec 2014, Kees Cook wrote:

> On Mon, Dec 1, 2014 at 2:56 PM, James Morris <[email protected]> wrote:
> > On Mon, 1 Dec 2014, Kees Cook wrote:
> >
> >> On Thu, Nov 27, 2014 at 3:37 PM, James Morris <[email protected]> wrote:
> >> > On Wed, 26 Nov 2014, Kees Cook wrote:
> >> >
> >> >> > That would be because your tree is based on v3.17 and Kees' is based on
> >> >> > v3.18-rc6 ...
> >> >>
> >> >> James, I can base on whatever you like. I can do v3.17, or even
> >> >> against your security-next. It seems everyone uses something
> >> >> different. :)
> >> >
> >> > It's best to track my next branch as your upstream.
> >>
> >> It'll trigger collisions with what's the x86 -next from luto's
> >> changes. Should I just let Stephen sort that out?
> >
> > Yep.
>
> Hm, it depends on 54ef6df3f3f1353d99c80c437259d317b2cd1cbd, so basing
> against security-next would make the tree unbuildable. Perhaps I
> should just wait for -rc1 to land first?

Yep, that will work.


--
James Morris
<[email protected]>