subject:"linux\-next\: Tree for Jun 21"

On Wed, Jun 22, 2016 at 04:43:15PM -0400, Chris Metcalf wrote:
> It turns out there were a few places where we were #include'ing Linux
> headers in the gcc build (asm/unistd.h, arch/icache.h, arch/spr_def.h).
> I patched gcc to provide inline copies of what was needed (pretty simple
> stuff and won't ever change) and asked our lead compiler guy to upstream
> it back up to gcc, so using buildall.git should get easier for tilepro/tilegx.

tilegx actually built without issue (although I think it needed
--disable-gdb for binutils).

But thanks! Much appreciated.

I'll try and make a few patches for Segher to update buildall and reduce
the number of hacks/patches I have to carry around on that.

Re: linux-next: Tree for Jun 21

On Wed, Jun 22, 2016 at 04:43:15PM -0400, Chris Metcalf wrote:
> It turns out there were a few places where we were #include'ing Linux
> headers in the gcc build (asm/unistd.h, arch/icache.h, arch/spr_def.h).
> I patched gcc to provide inline copies of what was needed (pretty simple
> stuff and won't ever change) and asked our lead compiler guy to upstream
> it back up to gcc, so using buildall.git should get easier for tilepro/tilegx.

tilegx actually built without issue (although I think it needed
--disable-gdb for binutils).

But thanks! Much appreciated.

I'll try and make a few patches for Segher to update buildall and reduce
the number of hacks/patches I have to carry around on that.

Re: linux-next: Tree for Jun 21


On 6/21/2016 5:14 PM, Arnd Bergmann wrote:

On Tuesday, June 21, 2016 8:50:48 PM CEST Peter Zijlstra wrote:

So what's your build process for the cross tools, by the way?  I'm assuming
you're not doing a total bootstrap cross-tool build since you'd need minimal
kernel headers (linux/errno.h or whatever) in that case.  I assume you're using
the host headers to build the cross tool?

So I'm a little confused how the other kernel headers are working out for you,
e.g.  is referenced when building the tilegx libgcc.

I've no idea; I use this thing:

   git://git.infradead.org/users/segher/buildall.git

Although I've got some local modifications, none are to the actual
toolchain building part (although I suppose I should send segher a
patch).

I have binutils-gdb.git and gcc.bit checkouts and point the buildall
config to that (both are on latest stable branches binutils-2_26-branch
and gcc-6-branch resp.). And I point the kernel path to my current
hacked up tree.

I don't really rebuild the entire toolchains often, mostly only when I
really need a new GCC or its getting really old (like I used 5.3.0 for a
long while).

I think the kernel headers are only needed for building glibc, which
buildall.git doesn't use: it only does the initial stage of creating
a cross-toolchain.


It turns out there were a few places where we were #include'ing Linux
headers in the gcc build (asm/unistd.h, arch/icache.h, arch/spr_def.h).
I patched gcc to provide inline copies of what was needed (pretty simple
stuff and won't ever change) and asked our lead compiler guy to upstream
it back up to gcc, so using buildall.git should get easier for tilepro/tilegx.

--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21


On 6/21/2016 5:14 PM, Arnd Bergmann wrote:

On Tuesday, June 21, 2016 8:50:48 PM CEST Peter Zijlstra wrote:

So what's your build process for the cross tools, by the way?  I'm assuming
you're not doing a total bootstrap cross-tool build since you'd need minimal
kernel headers (linux/errno.h or whatever) in that case.  I assume you're using
the host headers to build the cross tool?

So I'm a little confused how the other kernel headers are working out for you,
e.g.  is referenced when building the tilegx libgcc.

I've no idea; I use this thing:

   git://git.infradead.org/users/segher/buildall.git

Although I've got some local modifications, none are to the actual
toolchain building part (although I suppose I should send segher a
patch).

I have binutils-gdb.git and gcc.bit checkouts and point the buildall
config to that (both are on latest stable branches binutils-2_26-branch
and gcc-6-branch resp.). And I point the kernel path to my current
hacked up tree.

I don't really rebuild the entire toolchains often, mostly only when I
really need a new GCC or its getting really old (like I used 5.3.0 for a
long while).

I think the kernel headers are only needed for building glibc, which
buildall.git doesn't use: it only does the initial stage of creating
a cross-toolchain.


It turns out there were a few places where we were #include'ing Linux
headers in the gcc build (asm/unistd.h, arch/icache.h, arch/spr_def.h).
I patched gcc to provide inline copies of what was needed (pretty simple
stuff and won't ever change) and asked our lead compiler guy to upstream
it back up to gcc, so using buildall.git should get easier for tilepro/tilegx.

--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21


On 6/22/2016 5:16 AM, Peter Zijlstra wrote:

On Tue, Jun 21, 2016 at 02:36:34PM -0400, Chris Metcalf wrote:

>On 6/21/2016 2:28 PM, Peter Zijlstra wrote:

> >On Tue, Jun 21, 2016 at 07:29:18PM +0200, Peter Zijlstra wrote:
> >

> >>>OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I
> >>>can build me a kernel with it.

> >The below, much larger than desired, patch seems to make it go again.
> >
> >I had to s/__atomic_fetch/__atomic32_fetch/ to avoid a namespace clash
> >with the builtin C11 atomic primitives.
> >
> >You want me to rename them all to regain consistent naming?

>
>Yes, it's probably the right thing to do.  All the internal routines with 
"atomic32"
>or "atomic64" I assume you mean?

Something like so then?

---
  arch/tile/include/asm/atomic_32.h |   24 
  arch/tile/include/asm/futex.h |   14 +++---
  arch/tile/lib/atomic_32.c |   16 
  arch/tile/lib/atomic_asm_32.S |   21 +
  4 files changed, 40 insertions(+), 35 deletions(-)


Yes, that looks good.  Thanks!

Acked-by: Chris Metcalf 

--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21


On 6/22/2016 5:16 AM, Peter Zijlstra wrote:

On Tue, Jun 21, 2016 at 02:36:34PM -0400, Chris Metcalf wrote:

>On 6/21/2016 2:28 PM, Peter Zijlstra wrote:

> >On Tue, Jun 21, 2016 at 07:29:18PM +0200, Peter Zijlstra wrote:
> >

> >>>OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I
> >>>can build me a kernel with it.

> >The below, much larger than desired, patch seems to make it go again.
> >
> >I had to s/__atomic_fetch/__atomic32_fetch/ to avoid a namespace clash
> >with the builtin C11 atomic primitives.
> >
> >You want me to rename them all to regain consistent naming?

>
>Yes, it's probably the right thing to do.  All the internal routines with 
"atomic32"
>or "atomic64" I assume you mean?

Something like so then?

---
  arch/tile/include/asm/atomic_32.h |   24 
  arch/tile/include/asm/futex.h |   14 +++---
  arch/tile/lib/atomic_32.c |   16 
  arch/tile/lib/atomic_asm_32.S |   21 +
  4 files changed, 40 insertions(+), 35 deletions(-)


Yes, that looks good.  Thanks!

Acked-by: Chris Metcalf 

--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 02:36:34PM -0400, Chris Metcalf wrote:
> On 6/21/2016 2:28 PM, Peter Zijlstra wrote:
> >On Tue, Jun 21, 2016 at 07:29:18PM +0200, Peter Zijlstra wrote:
> >
> >>>OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I
> >>>can build me a kernel with it.
> >The below, much larger than desired, patch seems to make it go again.
> >
> >I had to s/__atomic_fetch/__atomic32_fetch/ to avoid a namespace clash
> >with the builtin C11 atomic primitives.
> >
> >You want me to rename them all to regain consistent naming?
> 
> Yes, it's probably the right thing to do.  All the internal routines with 
> "atomic32"
> or "atomic64" I assume you mean?

Something like so then?

---
 arch/tile/include/asm/atomic_32.h |   24 
 arch/tile/include/asm/futex.h |   14 +++---
 arch/tile/lib/atomic_32.c |   16 
 arch/tile/lib/atomic_asm_32.S |   21 +
 4 files changed, 40 insertions(+), 35 deletions(-)

diff --git a/arch/tile/include/asm/atomic_32.h 
b/arch/tile/include/asm/atomic_32.h
index da8eb4e..a937742 100644
--- a/arch/tile/include/asm/atomic_32.h
+++ b/arch/tile/include/asm/atomic_32.h
@@ -143,15 +143,15 @@ static inline void atomic64_##op(long long i, atomic64_t 
*v)  \
 {  \
_atomic64_fetch_##op(>counter, i);   \
 }  \
-static inline void atomic64_##op(long long i, atomic64_t *v)   \
+static inline long long atomic64_fetch_##op(long long i, atomic64_t *v)
\
 {  \
smp_mb();   \
return _atomic64_fetch_##op(>counter, i);\
 }
 
-ATOMIC64_OP(and)
-ATOMIC64_OP(or)
-ATOMIC64_OP(xor)
+ATOMIC64_OPS(and)
+ATOMIC64_OPS(or)
+ATOMIC64_OPS(xor)
 
 #undef ATOMIC64_OPS
 
@@ -266,16 +266,16 @@ struct __get_user {
unsigned long val;
int err;
 };
-extern struct __get_user __atomic_cmpxchg(volatile int *p,
+extern struct __get_user __atomic32_cmpxchg(volatile int *p,
  int *lock, int o, int n);
-extern struct __get_user __atomic_xchg(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_xchg_add(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_xchg_add_unless(volatile int *p,
+extern struct __get_user __atomic32_xchg(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_xchg_add(volatile int *p, int *lock, int 
n);
+extern struct __get_user __atomic32_xchg_add_unless(volatile int *p,
  int *lock, int o, int n);
-extern struct __get_user __atomic_fetch_or(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_fetch_and(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_fetch_andn(volatile int *p, int *lock, int 
n);
-extern struct __get_user __atomic_fetch_xor(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_fetch_or(volatile int *p, int *lock, int 
n);
+extern struct __get_user __atomic32_fetch_and(volatile int *p, int *lock, int 
n);
+extern struct __get_user __atomic32_fetch_andn(volatile int *p, int *lock, int 
n);
+extern struct __get_user __atomic32_fetch_xor(volatile int *p, int *lock, int 
n);
 extern long long __atomic64_cmpxchg(volatile long long *p, int *lock,
long long o, long long n);
 extern long long __atomic64_xchg(volatile long long *p, int *lock, long long 
n);
diff --git a/arch/tile/include/asm/futex.h b/arch/tile/include/asm/futex.h
index 1a6ef1b..e64a1b7 100644
--- a/arch/tile/include/asm/futex.h
+++ b/arch/tile/include/asm/futex.h
@@ -80,16 +80,16 @@
ret = gu.err;   \
}
 
-#define __futex_set() __futex_call(__atomic_xchg)
-#define __futex_add() __futex_call(__atomic_xchg_add)
-#define __futex_or() __futex_call(__atomic_or)
-#define __futex_andn() __futex_call(__atomic_andn)
-#define __futex_xor() __futex_call(__atomic_xor)
+#define __futex_set() __futex_call(__atomic32_xchg)
+#define __futex_add() __futex_call(__atomic32_xchg_add)
+#define __futex_or() __futex_call(__atomic32_fetch_or)
+#define __futex_andn() __futex_call(__atomic32_fetch_andn)
+#define __futex_xor() __futex_call(__atomic32_fetch_xor)
 
 #define __futex_cmpxchg()  \
{   \
-   struct __get_user gu = __atomic_cmpxchg((u32 __force *)uaddr, \
-   lock, oldval, oparg); \
+   struct __get_user gu = __atomic32_cmpxchg((u32 __force *)uaddr, 
\
+ lock, oldval, oparg); 
\
val = gu.val;

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 02:36:34PM -0400, Chris Metcalf wrote:
> On 6/21/2016 2:28 PM, Peter Zijlstra wrote:
> >On Tue, Jun 21, 2016 at 07:29:18PM +0200, Peter Zijlstra wrote:
> >
> >>>OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I
> >>>can build me a kernel with it.
> >The below, much larger than desired, patch seems to make it go again.
> >
> >I had to s/__atomic_fetch/__atomic32_fetch/ to avoid a namespace clash
> >with the builtin C11 atomic primitives.
> >
> >You want me to rename them all to regain consistent naming?
> 
> Yes, it's probably the right thing to do.  All the internal routines with 
> "atomic32"
> or "atomic64" I assume you mean?

Something like so then?

---
 arch/tile/include/asm/atomic_32.h |   24 
 arch/tile/include/asm/futex.h |   14 +++---
 arch/tile/lib/atomic_32.c |   16 
 arch/tile/lib/atomic_asm_32.S |   21 +
 4 files changed, 40 insertions(+), 35 deletions(-)

diff --git a/arch/tile/include/asm/atomic_32.h 
b/arch/tile/include/asm/atomic_32.h
index da8eb4e..a937742 100644
--- a/arch/tile/include/asm/atomic_32.h
+++ b/arch/tile/include/asm/atomic_32.h
@@ -143,15 +143,15 @@ static inline void atomic64_##op(long long i, atomic64_t 
*v)  \
 {  \
_atomic64_fetch_##op(>counter, i);   \
 }  \
-static inline void atomic64_##op(long long i, atomic64_t *v)   \
+static inline long long atomic64_fetch_##op(long long i, atomic64_t *v)
\
 {  \
smp_mb();   \
return _atomic64_fetch_##op(>counter, i);\
 }
 
-ATOMIC64_OP(and)
-ATOMIC64_OP(or)
-ATOMIC64_OP(xor)
+ATOMIC64_OPS(and)
+ATOMIC64_OPS(or)
+ATOMIC64_OPS(xor)
 
 #undef ATOMIC64_OPS
 
@@ -266,16 +266,16 @@ struct __get_user {
unsigned long val;
int err;
 };
-extern struct __get_user __atomic_cmpxchg(volatile int *p,
+extern struct __get_user __atomic32_cmpxchg(volatile int *p,
  int *lock, int o, int n);
-extern struct __get_user __atomic_xchg(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_xchg_add(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_xchg_add_unless(volatile int *p,
+extern struct __get_user __atomic32_xchg(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_xchg_add(volatile int *p, int *lock, int 
n);
+extern struct __get_user __atomic32_xchg_add_unless(volatile int *p,
  int *lock, int o, int n);
-extern struct __get_user __atomic_fetch_or(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_fetch_and(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_fetch_andn(volatile int *p, int *lock, int 
n);
-extern struct __get_user __atomic_fetch_xor(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_fetch_or(volatile int *p, int *lock, int 
n);
+extern struct __get_user __atomic32_fetch_and(volatile int *p, int *lock, int 
n);
+extern struct __get_user __atomic32_fetch_andn(volatile int *p, int *lock, int 
n);
+extern struct __get_user __atomic32_fetch_xor(volatile int *p, int *lock, int 
n);
 extern long long __atomic64_cmpxchg(volatile long long *p, int *lock,
long long o, long long n);
 extern long long __atomic64_xchg(volatile long long *p, int *lock, long long 
n);
diff --git a/arch/tile/include/asm/futex.h b/arch/tile/include/asm/futex.h
index 1a6ef1b..e64a1b7 100644
--- a/arch/tile/include/asm/futex.h
+++ b/arch/tile/include/asm/futex.h
@@ -80,16 +80,16 @@
ret = gu.err;   \
}
 
-#define __futex_set() __futex_call(__atomic_xchg)
-#define __futex_add() __futex_call(__atomic_xchg_add)
-#define __futex_or() __futex_call(__atomic_or)
-#define __futex_andn() __futex_call(__atomic_andn)
-#define __futex_xor() __futex_call(__atomic_xor)
+#define __futex_set() __futex_call(__atomic32_xchg)
+#define __futex_add() __futex_call(__atomic32_xchg_add)
+#define __futex_or() __futex_call(__atomic32_fetch_or)
+#define __futex_andn() __futex_call(__atomic32_fetch_andn)
+#define __futex_xor() __futex_call(__atomic32_fetch_xor)
 
 #define __futex_cmpxchg()  \
{   \
-   struct __get_user gu = __atomic_cmpxchg((u32 __force *)uaddr, \
-   lock, oldval, oparg); \
+   struct __get_user gu = __atomic32_cmpxchg((u32 __force *)uaddr, 
\
+ lock, oldval, oparg); 
\
val = gu.val;

Re: linux-next: Tree for Jun 21

2016-06-21 Thread Arnd Bergmann

On Tuesday, June 21, 2016 8:50:48 PM CEST Peter Zijlstra wrote:
> 
> > So what's your build process for the cross tools, by the way?  I'm assuming
> > you're not doing a total bootstrap cross-tool build since you'd need minimal
> > kernel headers (linux/errno.h or whatever) in that case.  I assume you're 
> > using
> > the host headers to build the cross tool?
> > 
> > So I'm a little confused how the other kernel headers are working out for 
> > you,
> > e.g.  is referenced when building the tilegx libgcc.
> 
> I've no idea; I use this thing:
> 
>   git://git.infradead.org/users/segher/buildall.git
> 
> Although I've got some local modifications, none are to the actual
> toolchain building part (although I suppose I should send segher a
> patch).
> 
> I have binutils-gdb.git and gcc.bit checkouts and point the buildall
> config to that (both are on latest stable branches binutils-2_26-branch
> and gcc-6-branch resp.). And I point the kernel path to my current
> hacked up tree.
> 
> I don't really rebuild the entire toolchains often, mostly only when I
> really need a new GCC or its getting really old (like I used 5.3.0 for a
> long while).

I think the kernel headers are only needed for building glibc, which
buildall.git doesn't use: it only does the initial stage of creating
a cross-toolchain.

Arnd

Re: linux-next: Tree for Jun 21

2016-06-21 Thread Arnd Bergmann

On Tuesday, June 21, 2016 8:50:48 PM CEST Peter Zijlstra wrote:
> 
> > So what's your build process for the cross tools, by the way?  I'm assuming
> > you're not doing a total bootstrap cross-tool build since you'd need minimal
> > kernel headers (linux/errno.h or whatever) in that case.  I assume you're 
> > using
> > the host headers to build the cross tool?
> > 
> > So I'm a little confused how the other kernel headers are working out for 
> > you,
> > e.g.  is referenced when building the tilegx libgcc.
> 
> I've no idea; I use this thing:
> 
>   git://git.infradead.org/users/segher/buildall.git
> 
> Although I've got some local modifications, none are to the actual
> toolchain building part (although I suppose I should send segher a
> patch).
> 
> I have binutils-gdb.git and gcc.bit checkouts and point the buildall
> config to that (both are on latest stable branches binutils-2_26-branch
> and gcc-6-branch resp.). And I point the kernel path to my current
> hacked up tree.
> 
> I don't really rebuild the entire toolchains often, mostly only when I
> really need a new GCC or its getting really old (like I used 5.3.0 for a
> long while).

I think the kernel headers are only needed for building glibc, which
buildall.git doesn't use: it only does the initial stage of creating
a cross-toolchain.

Arnd

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 02:36:34PM -0400, Chris Metcalf wrote:
> On 6/21/2016 2:28 PM, Peter Zijlstra wrote:

> >I had to s/__atomic_fetch/__atomic32_fetch/ to avoid a namespace clash
> >with the builtin C11 atomic primitives.
> >
> >You want me to rename them all to regain consistent naming?
> 
> Yes, it's probably the right thing to do.  All the internal routines with 
> "atomic32"
> or "atomic64" I assume you mean?

Yep, after this patch we have a few __atomic_ and a few __atomic32_,
which is rather unbecoming. Lemme go convert them all to __atomic32_.

> So what's your build process for the cross tools, by the way?  I'm assuming
> you're not doing a total bootstrap cross-tool build since you'd need minimal
> kernel headers (linux/errno.h or whatever) in that case.  I assume you're 
> using
> the host headers to build the cross tool?
> 
> So I'm a little confused how the other kernel headers are working out for you,
> e.g.  is referenced when building the tilegx libgcc.

I've no idea; I use this thing:

  git://git.infradead.org/users/segher/buildall.git

Although I've got some local modifications, none are to the actual
toolchain building part (although I suppose I should send segher a
patch).

I have binutils-gdb.git and gcc.bit checkouts and point the buildall
config to that (both are on latest stable branches binutils-2_26-branch
and gcc-6-branch resp.). And I point the kernel path to my current
hacked up tree.

I don't really rebuild the entire toolchains often, mostly only when I
really need a new GCC or its getting really old (like I used 5.3.0 for a
long while).

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 02:36:34PM -0400, Chris Metcalf wrote:
> On 6/21/2016 2:28 PM, Peter Zijlstra wrote:

> >I had to s/__atomic_fetch/__atomic32_fetch/ to avoid a namespace clash
> >with the builtin C11 atomic primitives.
> >
> >You want me to rename them all to regain consistent naming?
> 
> Yes, it's probably the right thing to do.  All the internal routines with 
> "atomic32"
> or "atomic64" I assume you mean?

Yep, after this patch we have a few __atomic_ and a few __atomic32_,
which is rather unbecoming. Lemme go convert them all to __atomic32_.

> So what's your build process for the cross tools, by the way?  I'm assuming
> you're not doing a total bootstrap cross-tool build since you'd need minimal
> kernel headers (linux/errno.h or whatever) in that case.  I assume you're 
> using
> the host headers to build the cross tool?
> 
> So I'm a little confused how the other kernel headers are working out for you,
> e.g.  is referenced when building the tilegx libgcc.

I've no idea; I use this thing:

  git://git.infradead.org/users/segher/buildall.git

Although I've got some local modifications, none are to the actual
toolchain building part (although I suppose I should send segher a
patch).

I have binutils-gdb.git and gcc.bit checkouts and point the buildall
config to that (both are on latest stable branches binutils-2_26-branch
and gcc-6-branch resp.). And I point the kernel path to my current
hacked up tree.

I don't really rebuild the entire toolchains often, mostly only when I
really need a new GCC or its getting really old (like I used 5.3.0 for a
long while).

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 08:50:48PM +0200, Peter Zijlstra wrote:
> I've no idea; I use this thing:
> 
>   git://git.infradead.org/users/segher/buildall.git
> 
> Although I've got some local modifications, none are to the actual
> toolchain building part (although I suppose I should send segher a
> patch).

Oops, I do have..

sjlj-exceptions is causing aarch64 to fail, so I killed it, its not like
the kernel needs that.


diff --git a/build-gcc b/build-gcc
index a93c624..183f445 100755
--- a/build-gcc
+++ b/build-gcc
@@ -22,7 +22,7 @@ $ECHO -ne "   gcc:" && \
$GCC_SRC/configure \
--target=$TARGET --enable-targets=all --prefix=$PREFIX \
--enable-languages=c --without-headers --disable-bootstrap \
-   --enable-sjlj-exceptions --with-system-libunwind \
+   --disable-sjlj-exceptions --with-system-libunwind \
--disable-nls --disable-threads --disable-shared \
--disable-libmudflap --disable-libssp --disable-libgomp \
--disable-decimal-float --disable-libquadmath \

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 08:50:48PM +0200, Peter Zijlstra wrote:
> I've no idea; I use this thing:
> 
>   git://git.infradead.org/users/segher/buildall.git
> 
> Although I've got some local modifications, none are to the actual
> toolchain building part (although I suppose I should send segher a
> patch).

Oops, I do have..

sjlj-exceptions is causing aarch64 to fail, so I killed it, its not like
the kernel needs that.


diff --git a/build-gcc b/build-gcc
index a93c624..183f445 100755
--- a/build-gcc
+++ b/build-gcc
@@ -22,7 +22,7 @@ $ECHO -ne "   gcc:" && \
$GCC_SRC/configure \
--target=$TARGET --enable-targets=all --prefix=$PREFIX \
--enable-languages=c --without-headers --disable-bootstrap \
-   --enable-sjlj-exceptions --with-system-libunwind \
+   --disable-sjlj-exceptions --with-system-libunwind \
--disable-nls --disable-threads --disable-shared \
--disable-libmudflap --disable-libssp --disable-libgomp \
--disable-decimal-float --disable-libquadmath \

Re: linux-next: Tree for Jun 21

On 6/21/2016 2:28 PM, Peter Zijlstra wrote:

On Tue, Jun 21, 2016 at 07:29:18PM +0200, Peter Zijlstra wrote:

>OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I
>can build me a kernel with it.

The below, much larger than desired, patch seems to make it go again.

I had to s/__atomic_fetch/__atomic32_fetch/ to avoid a namespace clash
with the builtin C11 atomic primitives.

You want me to rename them all to regain consistent naming?

Yes, it's probably the right thing to do.  All the internal routines with 
"atomic32"
or "atomic64" I assume you mean?

So what's your build process for the cross tools, by the way?  I'm assuming
you're not doing a total bootstrap cross-tool build since you'd need minimal
kernel headers (linux/errno.h or whatever) in that case.  I assume you're using
the host headers to build the cross tool?

So I'm a little confused how the other kernel headers are working out for you,
e.g.  is referenced when building the tilegx libgcc.

--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21

On 6/21/2016 2:28 PM, Peter Zijlstra wrote:

On Tue, Jun 21, 2016 at 07:29:18PM +0200, Peter Zijlstra wrote:

>OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I
>can build me a kernel with it.

The below, much larger than desired, patch seems to make it go again.

I had to s/__atomic_fetch/__atomic32_fetch/ to avoid a namespace clash
with the builtin C11 atomic primitives.

You want me to rename them all to regain consistent naming?

Yes, it's probably the right thing to do.  All the internal routines with 
"atomic32"
or "atomic64" I assume you mean?

So what's your build process for the cross tools, by the way?  I'm assuming
you're not doing a total bootstrap cross-tool build since you'd need minimal
kernel headers (linux/errno.h or whatever) in that case.  I assume you're using
the host headers to build the cross tool?

So I'm a little confused how the other kernel headers are working out for you,
e.g.  is referenced when building the tilegx libgcc.

--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 07:29:18PM +0200, Peter Zijlstra wrote:

> OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I
> can build me a kernel with it.

The below, much larger than desired, patch seems to make it go again.

I had to s/__atomic_fetch/__atomic32_fetch/ to avoid a namespace clash
with the builtin C11 atomic primitives.

You want me to rename them all to regain consistent naming?

---
 arch/tile/include/asm/atomic_32.h |   16 
 arch/tile/include/asm/futex.h |6 +++---
 arch/tile/lib/atomic_32.c |8 
 arch/tile/lib/atomic_asm_32.S |8 
 4 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/arch/tile/include/asm/atomic_32.h 
b/arch/tile/include/asm/atomic_32.h
index da8eb4e..e063825 100644
--- a/arch/tile/include/asm/atomic_32.h
+++ b/arch/tile/include/asm/atomic_32.h
@@ -143,15 +143,15 @@ static inline void atomic64_##op(long long i, atomic64_t 
*v)  \
 {  \
_atomic64_fetch_##op(>counter, i);   \
 }  \
-static inline void atomic64_##op(long long i, atomic64_t *v)   \
+static inline long long atomic64_fetch_##op(long long i, atomic64_t *v)
\
 {  \
smp_mb();   \
return _atomic64_fetch_##op(>counter, i);\
 }
 
-ATOMIC64_OP(and)
-ATOMIC64_OP(or)
-ATOMIC64_OP(xor)
+ATOMIC64_OPS(and)
+ATOMIC64_OPS(or)
+ATOMIC64_OPS(xor)
 
 #undef ATOMIC64_OPS
 
@@ -272,10 +272,10 @@ extern struct __get_user __atomic_xchg(volatile int *p, 
int *lock, int n);
 extern struct __get_user __atomic_xchg_add(volatile int *p, int *lock, int n);
 extern struct __get_user __atomic_xchg_add_unless(volatile int *p,
  int *lock, int o, int n);
-extern struct __get_user __atomic_fetch_or(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_fetch_and(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_fetch_andn(volatile int *p, int *lock, int 
n);
-extern struct __get_user __atomic_fetch_xor(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_fetch_or(volatile int *p, int *lock, int 
n);
+extern struct __get_user __atomic32_fetch_and(volatile int *p, int *lock, int 
n);
+extern struct __get_user __atomic32_fetch_andn(volatile int *p, int *lock, int 
n);
+extern struct __get_user __atomic32_fetch_xor(volatile int *p, int *lock, int 
n);
 extern long long __atomic64_cmpxchg(volatile long long *p, int *lock,
long long o, long long n);
 extern long long __atomic64_xchg(volatile long long *p, int *lock, long long 
n);
diff --git a/arch/tile/include/asm/futex.h b/arch/tile/include/asm/futex.h
index 1a6ef1b..479b28b 100644
--- a/arch/tile/include/asm/futex.h
+++ b/arch/tile/include/asm/futex.h
@@ -82,9 +82,9 @@
 
 #define __futex_set() __futex_call(__atomic_xchg)
 #define __futex_add() __futex_call(__atomic_xchg_add)
-#define __futex_or() __futex_call(__atomic_or)
-#define __futex_andn() __futex_call(__atomic_andn)
-#define __futex_xor() __futex_call(__atomic_xor)
+#define __futex_or() __futex_call(__atomic32_fetch_or)
+#define __futex_andn() __futex_call(__atomic32_fetch_andn)
+#define __futex_xor() __futex_call(__atomic32_fetch_xor)
 
 #define __futex_cmpxchg()  \
{   \
diff --git a/arch/tile/lib/atomic_32.c b/arch/tile/lib/atomic_32.c
index 5b6bd93..64d12fa 100644
--- a/arch/tile/lib/atomic_32.c
+++ b/arch/tile/lib/atomic_32.c
@@ -90,25 +90,25 @@ EXPORT_SYMBOL(_atomic_cmpxchg);
 
 unsigned long _atomic_fetch_or(volatile unsigned long *p, unsigned long mask)
 {
-   return __atomic_fetch_or((int *)p, __atomic_setup(p), mask).val;
+   return __atomic32_fetch_or((int *)p, __atomic_setup(p), mask).val;
 }
 EXPORT_SYMBOL(_atomic_fetch_or);
 
 unsigned long _atomic_fetch_and(volatile unsigned long *p, unsigned long mask)
 {
-   return __atomic_fetch_and((int *)p, __atomic_setup(p), mask).val;
+   return __atomic32_fetch_and((int *)p, __atomic_setup(p), mask).val;
 }
 EXPORT_SYMBOL(_atomic_fetch_and);
 
 unsigned long _atomic_fetch_andn(volatile unsigned long *p, unsigned long mask)
 {
-   return __atomic_fetch_andn((int *)p, __atomic_setup(p), mask).val;
+   return __atomic32_fetch_andn((int *)p, __atomic_setup(p), mask).val;
 }
 EXPORT_SYMBOL(_atomic_fetch_andn);
 
 unsigned long _atomic_fetch_xor(volatile unsigned long *p, unsigned long mask)
 {
-   return __atomic_fetch_xor((int *)p, __atomic_setup(p), mask).val;
+   return __atomic32_fetch_xor((int *)p, __atomic_setup(p), mask).val;
 }
 EXPORT_SYMBOL(_atomic_fetch_xor);
 
diff --git a/arch/tile/lib/atomic_asm_32.S

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 07:29:18PM +0200, Peter Zijlstra wrote:

> OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I
> can build me a kernel with it.

The below, much larger than desired, patch seems to make it go again.

I had to s/__atomic_fetch/__atomic32_fetch/ to avoid a namespace clash
with the builtin C11 atomic primitives.

You want me to rename them all to regain consistent naming?

---
 arch/tile/include/asm/atomic_32.h |   16 
 arch/tile/include/asm/futex.h |6 +++---
 arch/tile/lib/atomic_32.c |8 
 arch/tile/lib/atomic_asm_32.S |8 
 4 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/arch/tile/include/asm/atomic_32.h 
b/arch/tile/include/asm/atomic_32.h
index da8eb4e..e063825 100644
--- a/arch/tile/include/asm/atomic_32.h
+++ b/arch/tile/include/asm/atomic_32.h
@@ -143,15 +143,15 @@ static inline void atomic64_##op(long long i, atomic64_t 
*v)  \
 {  \
_atomic64_fetch_##op(>counter, i);   \
 }  \
-static inline void atomic64_##op(long long i, atomic64_t *v)   \
+static inline long long atomic64_fetch_##op(long long i, atomic64_t *v)
\
 {  \
smp_mb();   \
return _atomic64_fetch_##op(>counter, i);\
 }
 
-ATOMIC64_OP(and)
-ATOMIC64_OP(or)
-ATOMIC64_OP(xor)
+ATOMIC64_OPS(and)
+ATOMIC64_OPS(or)
+ATOMIC64_OPS(xor)
 
 #undef ATOMIC64_OPS
 
@@ -272,10 +272,10 @@ extern struct __get_user __atomic_xchg(volatile int *p, 
int *lock, int n);
 extern struct __get_user __atomic_xchg_add(volatile int *p, int *lock, int n);
 extern struct __get_user __atomic_xchg_add_unless(volatile int *p,
  int *lock, int o, int n);
-extern struct __get_user __atomic_fetch_or(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_fetch_and(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_fetch_andn(volatile int *p, int *lock, int 
n);
-extern struct __get_user __atomic_fetch_xor(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_fetch_or(volatile int *p, int *lock, int 
n);
+extern struct __get_user __atomic32_fetch_and(volatile int *p, int *lock, int 
n);
+extern struct __get_user __atomic32_fetch_andn(volatile int *p, int *lock, int 
n);
+extern struct __get_user __atomic32_fetch_xor(volatile int *p, int *lock, int 
n);
 extern long long __atomic64_cmpxchg(volatile long long *p, int *lock,
long long o, long long n);
 extern long long __atomic64_xchg(volatile long long *p, int *lock, long long 
n);
diff --git a/arch/tile/include/asm/futex.h b/arch/tile/include/asm/futex.h
index 1a6ef1b..479b28b 100644
--- a/arch/tile/include/asm/futex.h
+++ b/arch/tile/include/asm/futex.h
@@ -82,9 +82,9 @@
 
 #define __futex_set() __futex_call(__atomic_xchg)
 #define __futex_add() __futex_call(__atomic_xchg_add)
-#define __futex_or() __futex_call(__atomic_or)
-#define __futex_andn() __futex_call(__atomic_andn)
-#define __futex_xor() __futex_call(__atomic_xor)
+#define __futex_or() __futex_call(__atomic32_fetch_or)
+#define __futex_andn() __futex_call(__atomic32_fetch_andn)
+#define __futex_xor() __futex_call(__atomic32_fetch_xor)
 
 #define __futex_cmpxchg()  \
{   \
diff --git a/arch/tile/lib/atomic_32.c b/arch/tile/lib/atomic_32.c
index 5b6bd93..64d12fa 100644
--- a/arch/tile/lib/atomic_32.c
+++ b/arch/tile/lib/atomic_32.c
@@ -90,25 +90,25 @@ EXPORT_SYMBOL(_atomic_cmpxchg);
 
 unsigned long _atomic_fetch_or(volatile unsigned long *p, unsigned long mask)
 {
-   return __atomic_fetch_or((int *)p, __atomic_setup(p), mask).val;
+   return __atomic32_fetch_or((int *)p, __atomic_setup(p), mask).val;
 }
 EXPORT_SYMBOL(_atomic_fetch_or);
 
 unsigned long _atomic_fetch_and(volatile unsigned long *p, unsigned long mask)
 {
-   return __atomic_fetch_and((int *)p, __atomic_setup(p), mask).val;
+   return __atomic32_fetch_and((int *)p, __atomic_setup(p), mask).val;
 }
 EXPORT_SYMBOL(_atomic_fetch_and);
 
 unsigned long _atomic_fetch_andn(volatile unsigned long *p, unsigned long mask)
 {
-   return __atomic_fetch_andn((int *)p, __atomic_setup(p), mask).val;
+   return __atomic32_fetch_andn((int *)p, __atomic_setup(p), mask).val;
 }
 EXPORT_SYMBOL(_atomic_fetch_andn);
 
 unsigned long _atomic_fetch_xor(volatile unsigned long *p, unsigned long mask)
 {
-   return __atomic_fetch_xor((int *)p, __atomic_setup(p), mask).val;
+   return __atomic32_fetch_xor((int *)p, __atomic_setup(p), mask).val;
 }
 EXPORT_SYMBOL(_atomic_fetch_xor);
 
diff --git a/arch/tile/lib/atomic_asm_32.S

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 07:06:07PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 11:26:19AM -0400, Chris Metcalf wrote:
> > This has been true since gcc 4.x when tilepro support was first added.
> > 
> > In any case if you replace the #include  with
> > 
> > #define __NR_FAST_cmpxchg-1
> > #define __NR_FAST_atomic_update-2
> > #define __NR_FAST_cmpxchg64-3
> > 
> > that should also probably fix it, though I haven't tested it.  It probably
> > wouldn't be crazy to just put those #defines directly in tilepro's atomic.h,
> > since it's not like those fast system call numbers will ever change.

OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I
can build me a kernel with it.

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 07:06:07PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 11:26:19AM -0400, Chris Metcalf wrote:
> > This has been true since gcc 4.x when tilepro support was first added.
> > 
> > In any case if you replace the #include  with
> > 
> > #define __NR_FAST_cmpxchg-1
> > #define __NR_FAST_atomic_update-2
> > #define __NR_FAST_cmpxchg64-3
> > 
> > that should also probably fix it, though I haven't tested it.  It probably
> > wouldn't be crazy to just put those #defines directly in tilepro's atomic.h,
> > since it's not like those fast system call numbers will ever change.

OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I
can build me a kernel with it.

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 11:26:19AM -0400, Chris Metcalf wrote:
> On 6/21/2016 10:14 AM, Peter Zijlstra wrote:
> >On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
> >>>I'm not sure who builds the toolchains, but tilepro is in upstream 
> >>>gcc/binutils/etc
> >>>so should be easy enough to include.  There's also a cross-toolchain for 
> >>>x64 I put
> >>>up a while ago [1] that you could grab if you wanted to try it.
> >>I usually build my own set -- and just did. But tilepro was not
> >>included. Lemme go do so.
> >binutils-2_26-branch builds for tilepro-linux
> >gcc-6-branch does _not_ build for tilepro-linux
> 
> I figured I would take a stab at diagnosing this myself, and it looks like the
> toolchain build assumes that the kernel headers have already been installed
> and therefore we have  available.  This actually seems like
> a reasonable prerequisite for building the toolchain.  I'm guessing you
> don't?  Should you?  Or perhaps the compiler shouldn't make that assumption?

I can build:

ls -la /opt/cross/bin/*-gcc | wc -l
27

compilers without installing kernel headers.

> This has been true since gcc 4.x when tilepro support was first added.
> 
> In any case if you replace the #include  with
> 
> #define __NR_FAST_cmpxchg-1
> #define __NR_FAST_atomic_update-2
> #define __NR_FAST_cmpxchg64-3
> 
> that should also probably fix it, though I haven't tested it.  It probably
> wouldn't be crazy to just put those #defines directly in tilepro's atomic.h,
> since it's not like those fast system call numbers will ever change.

OK, I'll go test that right after I've got the kid in bed .. I'll let
you know.

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 11:26:19AM -0400, Chris Metcalf wrote:
> On 6/21/2016 10:14 AM, Peter Zijlstra wrote:
> >On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
> >>>I'm not sure who builds the toolchains, but tilepro is in upstream 
> >>>gcc/binutils/etc
> >>>so should be easy enough to include.  There's also a cross-toolchain for 
> >>>x64 I put
> >>>up a while ago [1] that you could grab if you wanted to try it.
> >>I usually build my own set -- and just did. But tilepro was not
> >>included. Lemme go do so.
> >binutils-2_26-branch builds for tilepro-linux
> >gcc-6-branch does _not_ build for tilepro-linux
> 
> I figured I would take a stab at diagnosing this myself, and it looks like the
> toolchain build assumes that the kernel headers have already been installed
> and therefore we have  available.  This actually seems like
> a reasonable prerequisite for building the toolchain.  I'm guessing you
> don't?  Should you?  Or perhaps the compiler shouldn't make that assumption?

I can build:

ls -la /opt/cross/bin/*-gcc | wc -l
27

compilers without installing kernel headers.

> This has been true since gcc 4.x when tilepro support was first added.
> 
> In any case if you replace the #include  with
> 
> #define __NR_FAST_cmpxchg-1
> #define __NR_FAST_atomic_update-2
> #define __NR_FAST_cmpxchg64-3
> 
> that should also probably fix it, though I haven't tested it.  It probably
> wouldn't be crazy to just put those #defines directly in tilepro's atomic.h,
> since it's not like those fast system call numbers will ever change.

OK, I'll go test that right after I've got the kid in bed .. I'll let
you know.

Re: linux-next: Tree for Jun 21


On 6/21/2016 10:14 AM, Peter Zijlstra wrote:

On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:

I'm not sure who builds the toolchains, but tilepro is in upstream 
gcc/binutils/etc
so should be easy enough to include.  There's also a cross-toolchain for x64 I 
put
up a while ago [1] that you could grab if you wanted to try it.

I usually build my own set -- and just did. But tilepro was not
included. Lemme go do so.

binutils-2_26-branch builds for tilepro-linux
gcc-6-branch does _not_ build for tilepro-linux


I figured I would take a stab at diagnosing this myself, and it looks like the
toolchain build assumes that the kernel headers have already been installed
and therefore we have  available.  This actually seems like
a reasonable prerequisite for building the toolchain.  I'm guessing you
don't?  Should you?  Or perhaps the compiler shouldn't make that assumption?
This has been true since gcc 4.x when tilepro support was first added.

In any case if you replace the #include  with

#define __NR_FAST_cmpxchg-1
#define __NR_FAST_atomic_update-2
#define __NR_FAST_cmpxchg64-3

that should also probably fix it, though I haven't tested it.  It probably
wouldn't be crazy to just put those #defines directly in tilepro's atomic.h,
since it's not like those fast system call numbers will ever change.

--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21


On 6/21/2016 10:14 AM, Peter Zijlstra wrote:

On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:

I'm not sure who builds the toolchains, but tilepro is in upstream 
gcc/binutils/etc
so should be easy enough to include.  There's also a cross-toolchain for x64 I 
put
up a while ago [1] that you could grab if you wanted to try it.

I usually build my own set -- and just did. But tilepro was not
included. Lemme go do so.

binutils-2_26-branch builds for tilepro-linux
gcc-6-branch does _not_ build for tilepro-linux


I figured I would take a stab at diagnosing this myself, and it looks like the
toolchain build assumes that the kernel headers have already been installed
and therefore we have  available.  This actually seems like
a reasonable prerequisite for building the toolchain.  I'm guessing you
don't?  Should you?  Or perhaps the compiler shouldn't make that assumption?
This has been true since gcc 4.x when tilepro support was first added.

In any case if you replace the #include  with

#define __NR_FAST_cmpxchg-1
#define __NR_FAST_atomic_update-2
#define __NR_FAST_cmpxchg64-3

that should also probably fix it, though I haven't tested it.  It probably
wouldn't be crazy to just put those #defines directly in tilepro's atomic.h,
since it's not like those fast system call numbers will ever change.

--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21


On 6/21/2016 10:14 AM, Peter Zijlstra wrote:

On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:

I'm not sure who builds the toolchains, but tilepro is in upstream 
gcc/binutils/etc
so should be easy enough to include.  There's also a cross-toolchain for x64 I 
put
up a while ago [1] that you could grab if you wanted to try it.

I usually build my own set -- and just did. But tilepro was not
included. Lemme go do so.

binutils-2_26-branch builds for tilepro-linux
gcc-6-branch does _not_ build for tilepro-linux


That's unexpected.  I'll pass this over to our compiler folks. Thanks!

--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21


On 6/21/2016 10:14 AM, Peter Zijlstra wrote:

On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:

I'm not sure who builds the toolchains, but tilepro is in upstream 
gcc/binutils/etc
so should be easy enough to include.  There's also a cross-toolchain for x64 I 
put
up a while ago [1] that you could grab if you wanted to try it.

I usually build my own set -- and just did. But tilepro was not
included. Lemme go do so.

binutils-2_26-branch builds for tilepro-linux
gcc-6-branch does _not_ build for tilepro-linux


That's unexpected.  I'll pass this over to our compiler folks. Thanks!

--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 04:14:35PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
> > > I'm not sure who builds the toolchains, but tilepro is in upstream 
> > > gcc/binutils/etc
> > > so should be easy enough to include.  There's also a cross-toolchain for 
> > > x64 I put
> > > up a while ago [1] that you could grab if you wanted to try it.
> > 
> > I usually build my own set -- and just did. But tilepro was not
> > included. Lemme go do so.
> 
> binutils-2_26-branch builds for tilepro-linux
> gcc-6-branch does _not_ build for tilepro-linux

I have not tried with binutils-2_26. But if you want my compiler, its at
http://chat.vectorindia.net/crosstool/x86_64/5.3.0/tilepro-linux-gnu.tar.xz

regards
sudip

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 04:14:35PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
> > > I'm not sure who builds the toolchains, but tilepro is in upstream 
> > > gcc/binutils/etc
> > > so should be easy enough to include.  There's also a cross-toolchain for 
> > > x64 I put
> > > up a while ago [1] that you could grab if you wanted to try it.
> > 
> > I usually build my own set -- and just did. But tilepro was not
> > included. Lemme go do so.
> 
> binutils-2_26-branch builds for tilepro-linux
> gcc-6-branch does _not_ build for tilepro-linux

I have not tried with binutils-2_26. But if you want my compiler, its at
http://chat.vectorindia.net/crosstool/x86_64/5.3.0/tilepro-linux-gnu.tar.xz

regards
sudip

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 09:47:00AM -0400, Chris Metcalf wrote:
> On 6/21/2016 8:42 AM, Peter Zijlstra wrote:
> >On Tue, Jun 21, 2016 at 08:08:29AM -0400, Chris Metcalf wrote:
> >>You need to have a tilepro toolchain (not tilegx)
> >Ah, should I go use TARGET=tilepro-linux ?
> 
> Yes.

> I'm not sure who builds the toolchains, but tilepro is in upstream 
> gcc/binutils/etc
> so should be easy enough to include.  There's also a cross-toolchain for x64 
> I put
> up a while ago [1] that you could grab if you wanted to try it.

I usually build my own set -- and just did. But tilepro was not
included. Lemme go do so.

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 09:47:00AM -0400, Chris Metcalf wrote:
> On 6/21/2016 8:42 AM, Peter Zijlstra wrote:
> >On Tue, Jun 21, 2016 at 08:08:29AM -0400, Chris Metcalf wrote:
> >>You need to have a tilepro toolchain (not tilegx)
> >Ah, should I go use TARGET=tilepro-linux ?
> 
> Yes.

> I'm not sure who builds the toolchains, but tilepro is in upstream 
> gcc/binutils/etc
> so should be easy enough to include.  There's also a cross-toolchain for x64 
> I put
> up a while ago [1] that you could grab if you wanted to try it.

I usually build my own set -- and just did. But tilepro was not
included. Lemme go do so.

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 10:20:39AM -0400, Chris Metcalf wrote:
> On 6/21/2016 10:14 AM, Peter Zijlstra wrote:
> >On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
> >>>I'm not sure who builds the toolchains, but tilepro is in upstream 
> >>>gcc/binutils/etc
> >>>so should be easy enough to include.  There's also a cross-toolchain for 
> >>>x64 I put
> >>>up a while ago [1] that you could grab if you wanted to try it.
> >>I usually build my own set -- and just did. But tilepro was not
> >>included. Lemme go do so.
> >binutils-2_26-branch builds for tilepro-linux
> >gcc-6-branch does _not_ build for tilepro-linux
> 
> That's unexpected.  I'll pass this over to our compiler folks. Thanks!

If you need more info like gcc-configure, gcc-build logs or exact
gcc-6-branch commitid, please let me know.

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 10:20:39AM -0400, Chris Metcalf wrote:
> On 6/21/2016 10:14 AM, Peter Zijlstra wrote:
> >On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
> >>>I'm not sure who builds the toolchains, but tilepro is in upstream 
> >>>gcc/binutils/etc
> >>>so should be easy enough to include.  There's also a cross-toolchain for 
> >>>x64 I put
> >>>up a while ago [1] that you could grab if you wanted to try it.
> >>I usually build my own set -- and just did. But tilepro was not
> >>included. Lemme go do so.
> >binutils-2_26-branch builds for tilepro-linux
> >gcc-6-branch does _not_ build for tilepro-linux
> 
> That's unexpected.  I'll pass this over to our compiler folks. Thanks!

If you need more info like gcc-configure, gcc-build logs or exact
gcc-6-branch commitid, please let me know.

Re: linux-next: Tree for Jun 21


On 6/21/2016 8:42 AM, Peter Zijlstra wrote:

On Tue, Jun 21, 2016 at 08:08:29AM -0400, Chris Metcalf wrote:

You need to have a tilepro toolchain (not tilegx)

Ah, should I go use TARGET=tilepro-linux ?


Yes.


and build with ARCH=tilepro.

 tilepro)
 ARCH=tile
 CROSS_COMPILE=tilegx-linux-
 if [ "$CONFIG" == "defconfig" ] ; then
 CONFIG=tilepro_defconfig
 fi
 ;;

So I suppose that too is wrong.


Yup.  That's actually just building exactly what "tilegx" would build by 
default.

I'm not sure who builds the toolchains, but tilepro is in upstream 
gcc/binutils/etc
so should be easy enough to include.  There's also a cross-toolchain for x64 I 
put
up a while ago [1] that you could grab if you wanted to try it.

[1] http://www.mellanox.com/repository/solutions/tile-scm/tilepro-x86_64.tar.bz2

--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21


On 6/21/2016 8:42 AM, Peter Zijlstra wrote:

On Tue, Jun 21, 2016 at 08:08:29AM -0400, Chris Metcalf wrote:

You need to have a tilepro toolchain (not tilegx)

Ah, should I go use TARGET=tilepro-linux ?


Yes.


and build with ARCH=tilepro.

 tilepro)
 ARCH=tile
 CROSS_COMPILE=tilegx-linux-
 if [ "$CONFIG" == "defconfig" ] ; then
 CONFIG=tilepro_defconfig
 fi
 ;;

So I suppose that too is wrong.


Yup.  That's actually just building exactly what "tilegx" would build by 
default.

I'm not sure who builds the toolchains, but tilepro is in upstream 
gcc/binutils/etc
so should be easy enough to include.  There's also a cross-toolchain for x64 I 
put
up a while ago [1] that you could grab if you wanted to try it.

[1] http://www.mellanox.com/repository/solutions/tile-scm/tilepro-x86_64.tar.bz2

--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
> > I'm not sure who builds the toolchains, but tilepro is in upstream 
> > gcc/binutils/etc
> > so should be easy enough to include.  There's also a cross-toolchain for 
> > x64 I put
> > up a while ago [1] that you could grab if you wanted to try it.
> 
> I usually build my own set -- and just did. But tilepro was not
> included. Lemme go do so.

binutils-2_26-branch builds for tilepro-linux
gcc-6-branch does _not_ build for tilepro-linux


---

/usr/local/src/buildall/tilepro/gcc/./gcc/xgcc 
-B/usr/local/src/buildall/tilepro/gcc/./gcc/ -B/opt/cross/tilepro-linux/bin/ 
-B/opt/cross/tilepro-linux/lib/ -isystem /opt/cross/tilepro-linux/include 
-isystem /opt/cross/tilepro-linux/sys-include-g -O2 -O2  -g -O2 -DIN_GCC  
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  
-isystem ./include   -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc 
-fno-stack-protector -Dinhibit_libc  -fPIC -I. -I. -I../.././gcc 
-I/usr/local/src/gcc/libgcc -I/usr/local/src/gcc/libgcc/. 
-I/usr/local/src/gcc/libgcc/../gcc -I/usr/local/src/gcc/libgcc/../include  
-DHAVE_CC_TLS  -o unwind-sjlj.o -MT unwind-sjlj.o -MD -MP -MF unwind-sjlj.dep 
-fexceptions -c /usr/local/src/gcc/libgcc/unwind-sjlj.c -fvisibility=hidden 
-DHIDE_EXPORTS
In file included from /usr/local/src/gcc/libgcc/config/tilepro/atomic.c:26:0:
/usr/local/src/gcc/libgcc/config/tilepro/atomic.h:98:24: fatal error: 
asm/unistd.h: No such file or directory
 #include 
^
compilation terminated.
mv -f softmpy.visT softmpy.vis
make[2]: *** [atomic.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory 
`/usr/local/src/buildall/tilepro/gcc/tilepro-linux/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/usr/local/src/buildall/tilepro/gcc'
make: *** [all] Error 2

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
> > I'm not sure who builds the toolchains, but tilepro is in upstream 
> > gcc/binutils/etc
> > so should be easy enough to include.  There's also a cross-toolchain for 
> > x64 I put
> > up a while ago [1] that you could grab if you wanted to try it.
> 
> I usually build my own set -- and just did. But tilepro was not
> included. Lemme go do so.

binutils-2_26-branch builds for tilepro-linux
gcc-6-branch does _not_ build for tilepro-linux


---

/usr/local/src/buildall/tilepro/gcc/./gcc/xgcc 
-B/usr/local/src/buildall/tilepro/gcc/./gcc/ -B/opt/cross/tilepro-linux/bin/ 
-B/opt/cross/tilepro-linux/lib/ -isystem /opt/cross/tilepro-linux/include 
-isystem /opt/cross/tilepro-linux/sys-include-g -O2 -O2  -g -O2 -DIN_GCC  
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  
-isystem ./include   -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc 
-fno-stack-protector -Dinhibit_libc  -fPIC -I. -I. -I../.././gcc 
-I/usr/local/src/gcc/libgcc -I/usr/local/src/gcc/libgcc/. 
-I/usr/local/src/gcc/libgcc/../gcc -I/usr/local/src/gcc/libgcc/../include  
-DHAVE_CC_TLS  -o unwind-sjlj.o -MT unwind-sjlj.o -MD -MP -MF unwind-sjlj.dep 
-fexceptions -c /usr/local/src/gcc/libgcc/unwind-sjlj.c -fvisibility=hidden 
-DHIDE_EXPORTS
In file included from /usr/local/src/gcc/libgcc/config/tilepro/atomic.c:26:0:
/usr/local/src/gcc/libgcc/config/tilepro/atomic.h:98:24: fatal error: 
asm/unistd.h: No such file or directory
 #include 
^
compilation terminated.
mv -f softmpy.visT softmpy.vis
make[2]: *** [atomic.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory 
`/usr/local/src/buildall/tilepro/gcc/tilepro-linux/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/usr/local/src/buildall/tilepro/gcc'
make: *** [all] Error 2

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 08:08:29AM -0400, Chris Metcalf wrote:
> 
> On inspection, I note that the arch/tile/include/atomic_32.h header has
> 
> ATOMIC64_OP(and)
> ATOMIC64_OP(or)
> ATOMIC64_OP(xor)
> 
> but these should be ATOMIC64_OPS, plural.

Bugger, I'll go fix. Clearly nobody has tilepro toolchains :/

> Peter, what toolchain were you using for tilepro build testing? 

tilegx-linux-

> You need to have a tilepro toolchain (not tilegx) 

Ah, should I go use TARGET=tilepro-linux ?

> and build with ARCH=tilepro.

tilepro)
ARCH=tile
CROSS_COMPILE=tilegx-linux-
if [ "$CONFIG" == "defconfig" ] ; then
CONFIG=tilepro_defconfig
fi
;;

So I suppose that too is wrong.

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 08:08:29AM -0400, Chris Metcalf wrote:
> 
> On inspection, I note that the arch/tile/include/atomic_32.h header has
> 
> ATOMIC64_OP(and)
> ATOMIC64_OP(or)
> ATOMIC64_OP(xor)
> 
> but these should be ATOMIC64_OPS, plural.

Bugger, I'll go fix. Clearly nobody has tilepro toolchains :/

> Peter, what toolchain were you using for tilepro build testing? 

tilegx-linux-

> You need to have a tilepro toolchain (not tilegx) 

Ah, should I go use TARGET=tilepro-linux ?

> and build with ARCH=tilepro.

tilepro)
ARCH=tile
CROSS_COMPILE=tilegx-linux-
if [ "$CONFIG" == "defconfig" ] ; then
CONFIG=tilepro_defconfig
fi
;;

So I suppose that too is wrong.

Re: linux-next: Tree for Jun 21


On 6/21/2016 3:01 AM, Sudip Mukherjee wrote:

On Tuesday 21 June 2016 06:46 AM, Stephen Rothwell wrote:

Hi all,

Changes since 20160620:


tilepro defconfig is failing while doing "make prepare" and bisect shows the 
first bad commit as:

1af5de9af138 ("locking/atomic, arch/tile: Implement 
atomic{,64}_fetch_{add,sub,and,or,xor}()")

You can find today's build log at:
https://travis-ci.org/sudipm-mukherjee/parport/jobs/139112570


On inspection, I note that the arch/tile/include/atomic_32.h header has

ATOMIC64_OP(and)
ATOMIC64_OP(or)
ATOMIC64_OP(xor)

but these should be ATOMIC64_OPS, plural.

Peter, what toolchain were you using for tilepro build testing?  You need to 
have a tilepro toolchain (not tilegx) and build with ARCH=tilepro.

--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21


On 6/21/2016 3:01 AM, Sudip Mukherjee wrote:

On Tuesday 21 June 2016 06:46 AM, Stephen Rothwell wrote:

Hi all,

Changes since 20160620:


tilepro defconfig is failing while doing "make prepare" and bisect shows the 
first bad commit as:

1af5de9af138 ("locking/atomic, arch/tile: Implement 
atomic{,64}_fetch_{add,sub,and,or,xor}()")

You can find today's build log at:
https://travis-ci.org/sudipm-mukherjee/parport/jobs/139112570


On inspection, I note that the arch/tile/include/atomic_32.h header has

ATOMIC64_OP(and)
ATOMIC64_OP(or)
ATOMIC64_OP(xor)

but these should be ATOMIC64_OPS, plural.

Peter, what toolchain were you using for tilepro build testing?  You need to 
have a tilepro toolchain (not tilegx) and build with ARCH=tilepro.

--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 09:58:28AM +0200, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 08:01:36AM +0100, Sudip Mukherjee wrote:
> 
> > tilepro defconfig is failing while doing "make prepare" and bisect shows the
> > first bad commit as:
> > 
> > 1af5de9af138 ("locking/atomic, arch/tile: Implement
> > atomic{,64}_fetch_{add,sub,and,or,xor}()")
> > 
> > You can find today's build log at:
> > https://travis-ci.org/sudipm-mukherjee/parport/jobs/139112570
> > 
> > Please do let me know if i can help in any way to debug/solve this.
> 
> I cannot reproduce, I tried both tip/master (which carries the patch you
> fingered) and next/master.

Thats strange.
The log I gave is for next-20160621.
BTW, I am using gcc-5.3.0

regards
sudip

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 09:58:28AM +0200, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 08:01:36AM +0100, Sudip Mukherjee wrote:
> 
> > tilepro defconfig is failing while doing "make prepare" and bisect shows the
> > first bad commit as:
> > 
> > 1af5de9af138 ("locking/atomic, arch/tile: Implement
> > atomic{,64}_fetch_{add,sub,and,or,xor}()")
> > 
> > You can find today's build log at:
> > https://travis-ci.org/sudipm-mukherjee/parport/jobs/139112570
> > 
> > Please do let me know if i can help in any way to debug/solve this.
> 
> I cannot reproduce, I tried both tip/master (which carries the patch you
> fingered) and next/master.

Thats strange.
The log I gave is for next-20160621.
BTW, I am using gcc-5.3.0

regards
sudip

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 08:01:36AM +0100, Sudip Mukherjee wrote:

> tilepro defconfig is failing while doing "make prepare" and bisect shows the
> first bad commit as:
> 
> 1af5de9af138 ("locking/atomic, arch/tile: Implement
> atomic{,64}_fetch_{add,sub,and,or,xor}()")
> 
> You can find today's build log at:
> https://travis-ci.org/sudipm-mukherjee/parport/jobs/139112570
> 
> Please do let me know if i can help in any way to debug/solve this.

I cannot reproduce, I tried both tip/master (which carries the patch you
fingered) and next/master.

My tilepro build ends in a vmlinux with just a single warning.


root@ivb-ep:/usr/src/linux-2.6# rm -rf tile-defconfig/ tile-tilepro_defconfig/
root@ivb-ep:/usr/src/linux-2.6# ./build-arch-defconfig.sh tilepro
make[1]: Entering directory `/usr/src/linux-2.6/tile-tilepro_defconfig'
  HOSTCC  scripts/basic/fixdep
  GEN ./Makefile
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
#
# configuration written to .config
#
make[1]: Leaving directory `/usr/src/linux-2.6/tile-tilepro_defconfig'
../arch/tile/lib/cacheflush.c: In function 'finv_buffer_remote':
../arch/tile/lib/cacheflush.c:146:0: warning: ignoring #pragma unroll  
[-Wunknown-pragmas]
 #pragma unroll 8
 
root@ivb-ep:/usr/src/linux-2.6# ls -la tile-tilepro_defconfig/vmlinux
vmlinuxvmlinux.o

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 08:01:36AM +0100, Sudip Mukherjee wrote:

> tilepro defconfig is failing while doing "make prepare" and bisect shows the
> first bad commit as:
> 
> 1af5de9af138 ("locking/atomic, arch/tile: Implement
> atomic{,64}_fetch_{add,sub,and,or,xor}()")
> 
> You can find today's build log at:
> https://travis-ci.org/sudipm-mukherjee/parport/jobs/139112570
> 
> Please do let me know if i can help in any way to debug/solve this.

I cannot reproduce, I tried both tip/master (which carries the patch you
fingered) and next/master.

My tilepro build ends in a vmlinux with just a single warning.


root@ivb-ep:/usr/src/linux-2.6# rm -rf tile-defconfig/ tile-tilepro_defconfig/
root@ivb-ep:/usr/src/linux-2.6# ./build-arch-defconfig.sh tilepro
make[1]: Entering directory `/usr/src/linux-2.6/tile-tilepro_defconfig'
  HOSTCC  scripts/basic/fixdep
  GEN ./Makefile
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
#
# configuration written to .config
#
make[1]: Leaving directory `/usr/src/linux-2.6/tile-tilepro_defconfig'
../arch/tile/lib/cacheflush.c: In function 'finv_buffer_remote':
../arch/tile/lib/cacheflush.c:146:0: warning: ignoring #pragma unroll  
[-Wunknown-pragmas]
 #pragma unroll 8
 
root@ivb-ep:/usr/src/linux-2.6# ls -la tile-tilepro_defconfig/vmlinux
vmlinuxvmlinux.o

Re: linux-next: Tree for Jun 21


On Tuesday 21 June 2016 06:46 AM, Stephen Rothwell wrote:

Hi all,

Changes since 20160620:


tilepro defconfig is failing while doing "make prepare" and bisect shows 
the first bad commit as:


1af5de9af138 ("locking/atomic, arch/tile: Implement 
atomic{,64}_fetch_{add,sub,and,or,xor}()")


You can find today's build log at:
https://travis-ci.org/sudipm-mukherjee/parport/jobs/139112570

Please do let me know if i can help in any way to debug/solve this.

regards
sudip

Re: linux-next: Tree for Jun 21


On Tuesday 21 June 2016 06:46 AM, Stephen Rothwell wrote:

Hi all,

Changes since 20160620:


tilepro defconfig is failing while doing "make prepare" and bisect shows 
the first bad commit as:


1af5de9af138 ("locking/atomic, arch/tile: Implement 
atomic{,64}_fetch_{add,sub,and,or,xor}()")


You can find today's build log at:
https://travis-ci.org/sudipm-mukherjee/parport/jobs/139112570

Please do let me know if i can help in any way to debug/solve this.

regards
sudip

linux-next: Tree for Jun 21

2016-06-20 Thread Stephen Rothwell

Hi all,

Changes since 20160620:

The net-next tree gained conflicts against the arm-doc tree.

The akpm-current tree gained a conflict against the arm-soc tree.

Non-merge commits (relative to Linus' tree): 4462
 4490 files changed, 203456 insertions(+), 78511 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 234 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (67016f6cdfd0 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging fixes/master (5edb56491d48 Linux 4.7-rc3)
Merging kbuild-current/rc-fixes (b36fad65d61f kbuild: Initialize exported 
variables)
Merging arc-current/for-curr (5edb56491d48 Linux 4.7-rc3)
Merging arm-current/fixes (56530f5d2ddc ARM: 8579/1: mm: Fix definition of 
pmd_mknotpresent)
Merging m68k-current/for-linus (9a6462763b17 m68k/mvme16x: Include generic 
)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (8550e2fa34f0 powerpc/mm/hash: Use the correct PPP 
mask when updating HPTE)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (6b15d6650c53 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging net/master (ab522fd68bc7 Merge branch 'qed-fixes')
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (50219538ffc0 vmxnet3: segCnt can be 1 for LRO packets)
Merging wireless-drivers/master (034fdd4a17ff Merge ath-current from ath.git)
Merging mac80211/master (3d5fdff46c4b wext: Fix 32 bit iwpriv compatibility 
issue with 64 bit Kernel)
Merging sound-current/for-linus (8198868f0a28 ALSA: hdac_regmap - fix the 
register access for runtime PM)
Merging pci-current/for-linus (ef0dab4aae14 PCI: Fix unaligned accesses in VC 
code)
Merging driver-core.current/driver-core-linus (e80dac114c63 Merge tag 
'usb-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb)
Merging tty.current/tty-linus (33688abb2802 Linux 4.7-rc4)
Merging usb.current/usb-linus (33688abb2802 Linux 4.7-rc4)
Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit 
on Clear Stall EP command)
Merging usb-serial-fixes/usb-linus (33688abb2802 Linux 4.7-rc4)
Merging usb-chipidea-fixes/ci-for-usb-stable (ea1d39a31d3b usb: common: 
otg-fsm: add license to usb-otg-fsm)
Merging staging.current/staging-linus (33688abb2802 Linux 4.7-rc4)
Merging char-misc.current/char-misc-linus (e80dac114c63 Merge tag 'usb-4.7-rc4' 
of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb)
Merging input-current/for-linus (30172936eefb MAINTAINERS: add Pali Rohár as 
reviewer of ALPS PS/2 touchpad driver)
Merging crypto-current/master (19ced623db2f crypto: ux500 - memmove the right 
size)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (ce7585f3c4d7 vfio/pci: Allow VPD short read)
Merging kselftest-fixes/fixes (f80eb4289491 selftests/exec: Makefile is a 
run-time dependency, add it to the install list)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: 
Handle EPROBE_DEFER while requesting the PWM)
Merging ftrace-fixes/for-next-urgent (6224beb12e19 tracing: Have

linux-next: Tree for Jun 21

2016-06-20 Thread Stephen Rothwell

Hi all,

Changes since 20160620:

The net-next tree gained conflicts against the arm-doc tree.

The akpm-current tree gained a conflict against the arm-soc tree.

Non-merge commits (relative to Linus' tree): 4462
 4490 files changed, 203456 insertions(+), 78511 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 234 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (67016f6cdfd0 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging fixes/master (5edb56491d48 Linux 4.7-rc3)
Merging kbuild-current/rc-fixes (b36fad65d61f kbuild: Initialize exported 
variables)
Merging arc-current/for-curr (5edb56491d48 Linux 4.7-rc3)
Merging arm-current/fixes (56530f5d2ddc ARM: 8579/1: mm: Fix definition of 
pmd_mknotpresent)
Merging m68k-current/for-linus (9a6462763b17 m68k/mvme16x: Include generic 
)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (8550e2fa34f0 powerpc/mm/hash: Use the correct PPP 
mask when updating HPTE)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (6b15d6650c53 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging net/master (ab522fd68bc7 Merge branch 'qed-fixes')
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (50219538ffc0 vmxnet3: segCnt can be 1 for LRO packets)
Merging wireless-drivers/master (034fdd4a17ff Merge ath-current from ath.git)
Merging mac80211/master (3d5fdff46c4b wext: Fix 32 bit iwpriv compatibility 
issue with 64 bit Kernel)
Merging sound-current/for-linus (8198868f0a28 ALSA: hdac_regmap - fix the 
register access for runtime PM)
Merging pci-current/for-linus (ef0dab4aae14 PCI: Fix unaligned accesses in VC 
code)
Merging driver-core.current/driver-core-linus (e80dac114c63 Merge tag 
'usb-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb)
Merging tty.current/tty-linus (33688abb2802 Linux 4.7-rc4)
Merging usb.current/usb-linus (33688abb2802 Linux 4.7-rc4)
Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit 
on Clear Stall EP command)
Merging usb-serial-fixes/usb-linus (33688abb2802 Linux 4.7-rc4)
Merging usb-chipidea-fixes/ci-for-usb-stable (ea1d39a31d3b usb: common: 
otg-fsm: add license to usb-otg-fsm)
Merging staging.current/staging-linus (33688abb2802 Linux 4.7-rc4)
Merging char-misc.current/char-misc-linus (e80dac114c63 Merge tag 'usb-4.7-rc4' 
of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb)
Merging input-current/for-linus (30172936eefb MAINTAINERS: add Pali Rohár as 
reviewer of ALPS PS/2 touchpad driver)
Merging crypto-current/master (19ced623db2f crypto: ux500 - memmove the right 
size)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (ce7585f3c4d7 vfio/pci: Allow VPD short read)
Merging kselftest-fixes/fixes (f80eb4289491 selftests/exec: Makefile is a 
run-time dependency, add it to the install list)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: 
Handle EPROBE_DEFER while requesting the PWM)
Merging ftrace-fixes/for-next-urgent (6224beb12e19 tracing: Have

linux-next: Tree for Jun 21

2015-06-21 Thread Stephen Rothwell

Hi all,

Changes since 20150620:

The drm tree gained a conflict against Linus' tree.

Non-merge commits (relative to Linus' tree): 11654
 9752 files changed, 1021167 insertions(+), 230410 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 221 trees (counting Linus' and 31 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (8f4ce072bf4b Merge branch 'drm-fixes' of 
git://people.freedesktop.org/~airlied/linux)
Merging fixes/master (b94d525e58dc Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1)
Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify)
Merging arm-current/fixes (0bbe6b5a73c0 ARM: 8388/1: tcm: Don't crash when TCM 
banks are protected by TrustZone)
Merging m68k-current/for-linus (b24f670b7f5b m68k/mac: Fix out-of-bounds array 
index in OSS IRQ source initialization)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-merge-mpe/fixes (c65b99f04684 Linux 4.1-rc6)
Merging powerpc-merge/merge (c517d838eb7d Linux 4.0-rc1)
Merging sparc/master (c46a024ea5eb Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging net/master (2dab80a8b486 bridge: fix br_stp_set_bridge_priority race 
conditions)
Merging ipsec/master (31a418986a58 xen: netback: read hotplug script once at 
start of day.)
Merging sound-current/for-linus (145c0e914d2c ALSA: hda - Fix unused label 
skip_i915)
Merging pci-current/for-linus (552bc94ebeeb PCI: Preserve resource size during 
alignment reordering)
Merging wireless-drivers/master (38fe44e61a89 Merge tag 
'iwlwifi-for-kalle-2015-05-28' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging driver-core.current/driver-core-linus (d4a4f75cd8f2 Linux 4.1-rc7)
Merging tty.current/tty-linus (d4a4f75cd8f2 Linux 4.1-rc7)
Merging usb.current/usb-linus (d4a4f75cd8f2 Linux 4.1-rc7)
Merging usb-gadget-fixes/fixes (c94e289f195e usb: gadget: remove incorrect 
__init/__exit annotations)
Merging usb-serial-fixes/usb-linus (0f57d86787d8 Linux 4.1-rc8)
Merging staging.current/staging-linus (d4a4f75cd8f2 Linux 4.1-rc7)
Merging char-misc.current/char-misc-linus (e26081808eda Linux 4.1-rc4)
Merging input-current/for-linus (469d7d22cea1 Input: pixcir_i2c_ts - fix 
receive error)
Merging crypto-current/master (412c98c1bef6 crypto: caam - fix RNG buffer cache 
alignment)
Merging ide/master (d681f1166919 ide: remove deprecated use of pci api)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (f36963c9d3f6 cpumask_set_cpu_local_first => 
cpumask_local_spread, lament)
Merging vfio-fixes/for-linus (db7d4d7f4021 vfio: Fix runaway interruptible 
timeout)
Merging kselftest-fixes/fixes (ba155e2d21f6 Linux 4.1-rc5)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: 
Handle EPROBE_DEFER while requesting the PWM)
Merging drm-intel-fixes/for-linux-next-fixes (245ec9d85696 Revert "drm/i915: 
Don't skip request retirement if the active list is empty")
Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess_for_upstream' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost into asm-generic)
Merging arc/for-next (5793e273a134 ARC: intc: split into ARCompact ISA 
specific, common bits)
Merging arm/for-next (9ce93bdda7b7 ARM: fix new BSYM()

linux-next: Tree for Jun 21

2015-06-21 Thread Stephen Rothwell

Hi all,

Changes since 20150620:

The drm tree gained a conflict against Linus' tree.

Non-merge commits (relative to Linus' tree): 11654
 9752 files changed, 1021167 insertions(+), 230410 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use git pull
to do so as that will try to merge the new linux-next release with the
old one.  You should use git fetch and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 221 trees (counting Linus' and 31 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (8f4ce072bf4b Merge branch 'drm-fixes' of 
git://people.freedesktop.org/~airlied/linux)
Merging fixes/master (b94d525e58dc Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1)
Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify)
Merging arm-current/fixes (0bbe6b5a73c0 ARM: 8388/1: tcm: Don't crash when TCM 
banks are protected by TrustZone)
Merging m68k-current/for-linus (b24f670b7f5b m68k/mac: Fix out-of-bounds array 
index in OSS IRQ source initialization)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-merge-mpe/fixes (c65b99f04684 Linux 4.1-rc6)
Merging powerpc-merge/merge (c517d838eb7d Linux 4.0-rc1)
Merging sparc/master (c46a024ea5eb Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging net/master (2dab80a8b486 bridge: fix br_stp_set_bridge_priority race 
conditions)
Merging ipsec/master (31a418986a58 xen: netback: read hotplug script once at 
start of day.)
Merging sound-current/for-linus (145c0e914d2c ALSA: hda - Fix unused label 
skip_i915)
Merging pci-current/for-linus (552bc94ebeeb PCI: Preserve resource size during 
alignment reordering)
Merging wireless-drivers/master (38fe44e61a89 Merge tag 
'iwlwifi-for-kalle-2015-05-28' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging driver-core.current/driver-core-linus (d4a4f75cd8f2 Linux 4.1-rc7)
Merging tty.current/tty-linus (d4a4f75cd8f2 Linux 4.1-rc7)
Merging usb.current/usb-linus (d4a4f75cd8f2 Linux 4.1-rc7)
Merging usb-gadget-fixes/fixes (c94e289f195e usb: gadget: remove incorrect 
__init/__exit annotations)
Merging usb-serial-fixes/usb-linus (0f57d86787d8 Linux 4.1-rc8)
Merging staging.current/staging-linus (d4a4f75cd8f2 Linux 4.1-rc7)
Merging char-misc.current/char-misc-linus (e26081808eda Linux 4.1-rc4)
Merging input-current/for-linus (469d7d22cea1 Input: pixcir_i2c_ts - fix 
receive error)
Merging crypto-current/master (412c98c1bef6 crypto: caam - fix RNG buffer cache 
alignment)
Merging ide/master (d681f1166919 ide: remove deprecated use of pci api)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (f36963c9d3f6 cpumask_set_cpu_local_first = 
cpumask_local_spread, lament)
Merging vfio-fixes/for-linus (db7d4d7f4021 vfio: Fix runaway interruptible 
timeout)
Merging kselftest-fixes/fixes (ba155e2d21f6 Linux 4.1-rc5)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: 
Handle EPROBE_DEFER while requesting the PWM)
Merging drm-intel-fixes/for-linux-next-fixes (245ec9d85696 Revert drm/i915: 
Don't skip request retirement if the active list is empty)
Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess_for_upstream' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost into asm-generic)
Merging arc/for-next (5793e273a134 ARC: intc: split into ARCompact ISA 
specific, common bits)
Merging arm/for-next (9ce93bdda7b7 ARM: fix new BSYM() usage

Re: ipc-msg broken again on 3.11-rc7? (was Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ])

2013-08-30 Thread Sedat Dilek

On Fri, Aug 30, 2013 at 10:19 AM, Vineet Gupta  wrote:
> Ping ?
>
> It seems 3.11 is pretty close to releasing but we stil have LTP msgctl08 
> causing a
> hang (atleast on ARC) for both linux-next 20130829 as well as Linus tree.
>
> So far, I haven't seemed to have drawn attention of people involved.
>

Hi Vineet,

I remember fakeroot was an another good test-case for me to test this
IPC breakage.
Attached is my build-script for Linux-next (tested with Debian/Ubuntu).
( Cannot say if you can play with it in your environment. )

Regards,
- Sedat -

> -Vineet
>
> On 08/29/2013 01:22 PM, Sedat Dilek wrote:
>> On Thu, Aug 29, 2013 at 9:21 AM, Vineet Gupta
>>  wrote:
>>> On 08/29/2013 08:34 AM, Sedat Dilek wrote:
 On Wed, Aug 28, 2013 at 1:58 PM, Vineet Gupta
  wrote:
> Hi David,
>
>
> []
>
> LTP msgctl08 hangs on 3.11-rc7 (ARC port) with some of my local changes. I
> bisected it, sigh... didn't look at this thread earlier :-( and landed 
> into this.
>
> ->8
> 3dd1f784ed6603d7ab1043e51e6371235edf2313 is the first bad commit
> commit 3dd1f784ed6603d7ab1043e51e6371235edf2313
> Author: Davidlohr Bueso 
> Date:   Mon Jul 8 16:01:17 2013 -0700
>
> ipc,msg: shorten critical region in msgsnd
>
> do_msgsnd() is another function that does too many things with the ipc
> object lock acquired.  Take it only when needed when actually updating
> msq.
> ->8
>
> If I revert 3dd1f784ed66 and 9ad66ae "ipc: remove unused functions" - the 
> test
> passes. I can confirm that linux-next also has the issue (didn't try the 
> revert
> there though).
>
> 1. arc 3.11-rc7 config attached (UP + PREEMPT)
> 2. dmesg prints "msgmni has been set to 479"
> 3. LTP output (this is slightly dated source, so prints might vary)
>
> ->8
> <<>>
> tag=msgctl08 stime=1377689180
> cmdline="msgctl08"
> contacts=""
> analysis=exit
> initiation_status="ok"
> <<>>
> ->8 hung here --
>
>
> Let me know if you need more data/test help.
>
 Cannot say much to your constellation as I had the issue on x86-64 and
 Linux-next.
 But I have just seen a post-v3.11-rc7 IPC-fix in [1].

 I have here a v3.11-rc7 kernel with drm-intel-nightly on top... did not 
 run LTP.
>>>
>>> Not sure what you mean - I'd posted that Im seeing the issue on ARC Linux 
>>> (an FPGA
>>> board) 3.11-rc7 as well as linux-next of yesterday.
>>>
>>
>> I am not saying there is no issue, but I have no possibility to test
>> for ARC arch.
>>
 Which LTP release do you use?
>>>
>>> The LTP build I generally use is from a 2007 based sources (lazy me). 
>>> However I
>>> knew this would come up so before posting, I'd built the latest from 
>>> buildroot and
>>> ran the msgctl08 from there standalone and it did the same thing.
>>>
>>
>> Try always latest LTP-stable (03-May-2013 is what I tried). AFAICS a
>> new release is planned soon.
>>
 Might be good to attach your kernel-config for followers?
>>>
>>> It was already there in my orig msg - you probably missed it.
>>>
>>
>> I have got that response from you only :-).
>>
 [1] 
 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=368ae537e056acd3f751fa276f48423f06803922
>>>
>>> I tried linux-next of today, same deal - msgctl08 still hangs.
>>>
>>
>> That above fix [1] in Linus-tree is also in next-20130828.
>>
>> Hope Davidlohr and fellows can help you.
>>
>> - Sedat -
>>
>


build_linux-next.sh
Description: Bourne shell script

Re: ipc-msg broken again on 3.11-rc7? (was Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ])

2013-08-30 Thread Vineet Gupta

Ping ?

It seems 3.11 is pretty close to releasing but we stil have LTP msgctl08 
causing a
hang (atleast on ARC) for both linux-next 20130829 as well as Linus tree.

So far, I haven't seemed to have drawn attention of people involved.

-Vineet

On 08/29/2013 01:22 PM, Sedat Dilek wrote:
> On Thu, Aug 29, 2013 at 9:21 AM, Vineet Gupta
>  wrote:
>> On 08/29/2013 08:34 AM, Sedat Dilek wrote:
>>> On Wed, Aug 28, 2013 at 1:58 PM, Vineet Gupta
>>>  wrote:
 Hi David,


[]

 LTP msgctl08 hangs on 3.11-rc7 (ARC port) with some of my local changes. I
 bisected it, sigh... didn't look at this thread earlier :-( and landed 
 into this.

 ->8
 3dd1f784ed6603d7ab1043e51e6371235edf2313 is the first bad commit
 commit 3dd1f784ed6603d7ab1043e51e6371235edf2313
 Author: Davidlohr Bueso 
 Date:   Mon Jul 8 16:01:17 2013 -0700

 ipc,msg: shorten critical region in msgsnd

 do_msgsnd() is another function that does too many things with the ipc
 object lock acquired.  Take it only when needed when actually updating
 msq.
 ->8

 If I revert 3dd1f784ed66 and 9ad66ae "ipc: remove unused functions" - the 
 test
 passes. I can confirm that linux-next also has the issue (didn't try the 
 revert
 there though).

 1. arc 3.11-rc7 config attached (UP + PREEMPT)
 2. dmesg prints "msgmni has been set to 479"
 3. LTP output (this is slightly dated source, so prints might vary)

 ->8
 <<>>
 tag=msgctl08 stime=1377689180
 cmdline="msgctl08"
 contacts=""
 analysis=exit
 initiation_status="ok"
 <<>>
 ->8 hung here --


 Let me know if you need more data/test help.

>>> Cannot say much to your constellation as I had the issue on x86-64 and
>>> Linux-next.
>>> But I have just seen a post-v3.11-rc7 IPC-fix in [1].
>>>
>>> I have here a v3.11-rc7 kernel with drm-intel-nightly on top... did not run 
>>> LTP.
>>
>> Not sure what you mean - I'd posted that Im seeing the issue on ARC Linux 
>> (an FPGA
>> board) 3.11-rc7 as well as linux-next of yesterday.
>>
> 
> I am not saying there is no issue, but I have no possibility to test
> for ARC arch.
> 
>>> Which LTP release do you use?
>>
>> The LTP build I generally use is from a 2007 based sources (lazy me). 
>> However I
>> knew this would come up so before posting, I'd built the latest from 
>> buildroot and
>> ran the msgctl08 from there standalone and it did the same thing.
>>
> 
> Try always latest LTP-stable (03-May-2013 is what I tried). AFAICS a
> new release is planned soon.
> 
>>> Might be good to attach your kernel-config for followers?
>>
>> It was already there in my orig msg - you probably missed it.
>>
> 
> I have got that response from you only :-).
> 
>>> [1] 
>>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=368ae537e056acd3f751fa276f48423f06803922
>>
>> I tried linux-next of today, same deal - msgctl08 still hangs.
>>
> 
> That above fix [1] in Linus-tree is also in next-20130828.
> 
> Hope Davidlohr and fellows can help you.
> 
> - Sedat -
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ipc-msg broken again on 3.11-rc7? (was Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ])

2013-08-30 Thread Vineet Gupta

Ping ?

It seems 3.11 is pretty close to releasing but we stil have LTP msgctl08
causing a
hang (atleast on ARC) for both linux-next 20130829 as well as Linus tree.

So far, I haven't seemed to have drawn attention of people involved.

-Vineet

On 08/29/2013 01:22 PM, Sedat Dilek wrote:
On Thu, Aug 29, 2013 at 9:21 AM, Vineet Gupta
vineet.gup...@synopsys.com wrote:
On 08/29/2013 08:34 AM, Sedat Dilek wrote:
On Wed, Aug 28, 2013 at 1:58 PM, Vineet Gupta
vineet.gup...@synopsys.com wrote:
Hi David,

[]

LTP msgctl08 hangs on 3.11-rc7 (ARC port) with some of my local changes. I
bisected it, sigh... didn't look at this thread earlier :-( and landed
into this.

-8
3dd1f784ed6603d7ab1043e51e6371235edf2313 is the first bad commit
commit 3dd1f784ed6603d7ab1043e51e6371235edf2313
Author: Davidlohr Bueso davidlohr.bu...@hp.com
Date: Mon Jul 8 16:01:17 2013 -0700

ipc,msg: shorten critical region in msgsnd

do_msgsnd() is another function that does too many things with the ipc
object lock acquired. Take it only when needed when actually updating
msq.
-8

If I revert 3dd1f784ed66 and 9ad66ae ipc: remove unused functions - the
test
passes. I can confirm that linux-next also has the issue (didn't try the
revert
there though).

1. arc 3.11-rc7 config attached (UP + PREEMPT)
2. dmesg prints msgmni has been set to 479
3. LTP output (this is slightly dated source, so prints might vary)

-8
test_start
tag=msgctl08 stime=1377689180
cmdline=msgctl08
contacts=
analysis=exit
initiation_status=ok
test_output
-8 hung here --

Let me know if you need more data/test help.

Cannot say much to your constellation as I had the issue on x86-64 and
Linux-next.
But I have just seen a post-v3.11-rc7 IPC-fix in [1].

I have here a v3.11-rc7 kernel with drm-intel-nightly on top... did not run
LTP.

Not sure what you mean - I'd posted that Im seeing the issue on ARC Linux
(an FPGA
board) 3.11-rc7 as well as linux-next of yesterday.

I am not saying there is no issue, but I have no possibility to test
for ARC arch.

Which LTP release do you use?

The LTP build I generally use is from a 2007 based sources (lazy me).
However I
knew this would come up so before posting, I'd built the latest from
buildroot and
ran the msgctl08 from there standalone and it did the same thing.

Try always latest LTP-stable (03-May-2013 is what I tried). AFAICS a
new release is planned soon.

Might be good to attach your kernel-config for followers?

It was already there in my orig msg - you probably missed it.

I have got that response from you only :-).

[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=368ae537e056acd3f751fa276f48423f06803922

I tried linux-next of today, same deal - msgctl08 still hangs.

That above fix [1] in Linus-tree is also in next-20130828.

Hope Davidlohr and fellows can help you.

- Sedat -

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: ipc-msg broken again on 3.11-rc7? (was Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ])

2013-08-30 Thread Sedat Dilek

On Fri, Aug 30, 2013 at 10:19 AM, Vineet Gupta vineet...@gmail.com wrote:
Ping ?

It seems 3.11 is pretty close to releasing but we stil have LTP msgctl08
causing a
hang (atleast on ARC) for both linux-next 20130829 as well as Linus tree.

So far, I haven't seemed to have drawn attention of people involved.

Hi Vineet,

I remember fakeroot was an another good test-case for me to test this
IPC breakage.
Attached is my build-script for Linux-next (tested with Debian/Ubuntu).
( Cannot say if you can play with it in your environment. )

Regards,
- Sedat -

-Vineet

[]

LTP msgctl08 hangs on 3.11-rc7 (ARC port) with some of my local changes. I
bisected it, sigh... didn't look at this thread earlier :-( and landed
into this.

-8
3dd1f784ed6603d7ab1043e51e6371235edf2313 is the first bad commit
commit 3dd1f784ed6603d7ab1043e51e6371235edf2313
Author: Davidlohr Bueso davidlohr.bu...@hp.com
Date: Mon Jul 8 16:01:17 2013 -0700

ipc,msg: shorten critical region in msgsnd

do_msgsnd() is another function that does too many things with the ipc
object lock acquired. Take it only when needed when actually updating
msq.
-8

If I revert 3dd1f784ed66 and 9ad66ae ipc: remove unused functions - the
test
passes. I can confirm that linux-next also has the issue (didn't try the
revert
there though).

1. arc 3.11-rc7 config attached (UP + PREEMPT)
2. dmesg prints msgmni has been set to 479
3. LTP output (this is slightly dated source, so prints might vary)

-8
test_start
tag=msgctl08 stime=1377689180
cmdline=msgctl08
contacts=
analysis=exit
initiation_status=ok
test_output
-8 hung here --

Let me know if you need more data/test help.

Cannot say much to your constellation as I had the issue on x86-64 and
Linux-next.
But I have just seen a post-v3.11-rc7 IPC-fix in [1].

I have here a v3.11-rc7 kernel with drm-intel-nightly on top... did not
run LTP.

Not sure what you mean - I'd posted that Im seeing the issue on ARC Linux
(an FPGA
board) 3.11-rc7 as well as linux-next of yesterday.

I am not saying there is no issue, but I have no possibility to test
for ARC arch.

Which LTP release do you use?

Try always latest LTP-stable (03-May-2013 is what I tried). AFAICS a
new release is planned soon.

Might be good to attach your kernel-config for followers?

It was already there in my orig msg - you probably missed it.

I have got that response from you only :-).

[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=368ae537e056acd3f751fa276f48423f06803922

I tried linux-next of today, same deal - msgctl08 still hangs.

That above fix [1] in Linus-tree is also in next-20130828.

Hope Davidlohr and fellows can help you.

- Sedat -

build_linux-next.sh
Description: Bourne shell script

Re: ipc-msg broken again on 3.11-rc7? (was Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ])

2013-08-29 Thread Sedat Dilek

On Thu, Aug 29, 2013 at 9:21 AM, Vineet Gupta
 wrote:
> On 08/29/2013 08:34 AM, Sedat Dilek wrote:
>> On Wed, Aug 28, 2013 at 1:58 PM, Vineet Gupta
>>  wrote:
>>> Hi David,
>>>
>>> On 06/26/2013 04:59 AM, Davidlohr Bueso wrote:
 On Tue, 2013-06-25 at 23:41 +0200, Sedat Dilek wrote:
> On Tue, Jun 25, 2013 at 10:33 PM, Davidlohr Bueso
>  wrote:
>> On Tue, 2013-06-25 at 18:10 +0200, Sedat Dilek wrote:
>> [...]
>>
>>> I did some more testing with Linux-Testing-Project (release:
>>> ltp-full-20130503) and next-20130624 (Monday) which has still the
>>> issue, here.
>>>
>>> If I revert the mentioned two commits from my local
>>> revert-ipc-next20130624-5089fd1c6a6a-ab9efc2d0db5 GIT repo, everything
>>> is fine.
>>>
>>> I have tested the LTP ***IPC*** and ***SYSCALLS*** testcases.
>>>
>>>root# ./runltp -f ipc
>>>
>>>root# ./runltp -f syscalls
>> These are nice test cases!
>>
>> So I was able to reproduce the issue with LTP and manually running
>> msgctl08. We seemed to be racing at find_msg(), so take to q_perm lock
>> before calling it. The following changes fixes the issue and passes all
>> 'runltp -f syscall' tests, could you give it a try?
>>
> Cool, that fixes the issues here.
>
> Building with fakeroot & make deb-pkg is now OK, again.
>
> The syscalls/msgctl08 test-case ran successfully!
 Andrew, could you pick this one up? I've made the patch on top of
 3.10.0-rc7-next-20130625
>>> LTP msgctl08 hangs on 3.11-rc7 (ARC port) with some of my local changes. I
>>> bisected it, sigh... didn't look at this thread earlier :-( and landed into 
>>> this.
>>>
>>> ->8
>>> 3dd1f784ed6603d7ab1043e51e6371235edf2313 is the first bad commit
>>> commit 3dd1f784ed6603d7ab1043e51e6371235edf2313
>>> Author: Davidlohr Bueso 
>>> Date:   Mon Jul 8 16:01:17 2013 -0700
>>>
>>> ipc,msg: shorten critical region in msgsnd
>>>
>>> do_msgsnd() is another function that does too many things with the ipc
>>> object lock acquired.  Take it only when needed when actually updating
>>> msq.
>>> ->8
>>>
>>> If I revert 3dd1f784ed66 and 9ad66ae "ipc: remove unused functions" - the 
>>> test
>>> passes. I can confirm that linux-next also has the issue (didn't try the 
>>> revert
>>> there though).
>>>
>>> 1. arc 3.11-rc7 config attached (UP + PREEMPT)
>>> 2. dmesg prints "msgmni has been set to 479"
>>> 3. LTP output (this is slightly dated source, so prints might vary)
>>>
>>> ->8
>>> <<>>
>>> tag=msgctl08 stime=1377689180
>>> cmdline="msgctl08"
>>> contacts=""
>>> analysis=exit
>>> initiation_status="ok"
>>> <<>>
>>> ->8 hung here --
>>>
>>>
>>> Let me know if you need more data/test help.
>>>
>> Cannot say much to your constellation as I had the issue on x86-64 and
>> Linux-next.
>> But I have just seen a post-v3.11-rc7 IPC-fix in [1].
>>
>> I have here a v3.11-rc7 kernel with drm-intel-nightly on top... did not run 
>> LTP.
>
> Not sure what you mean - I'd posted that Im seeing the issue on ARC Linux (an 
> FPGA
> board) 3.11-rc7 as well as linux-next of yesterday.
>

I am not saying there is no issue, but I have no possibility to test
for ARC arch.

>> Which LTP release do you use?
>
> The LTP build I generally use is from a 2007 based sources (lazy me). However 
> I
> knew this would come up so before posting, I'd built the latest from 
> buildroot and
> ran the msgctl08 from there standalone and it did the same thing.
>

Try always latest LTP-stable (03-May-2013 is what I tried). AFAICS a
new release is planned soon.

>> Might be good to attach your kernel-config for followers?
>
> It was already there in my orig msg - you probably missed it.
>

I have got that response from you only :-).

>> [1] 
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=368ae537e056acd3f751fa276f48423f06803922
>
> I tried linux-next of today, same deal - msgctl08 still hangs.
>

That above fix [1] in Linus-tree is also in next-20130828.

Hope Davidlohr and fellows can help you.

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ipc-msg broken again on 3.11-rc7? (was Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ])

2013-08-29 Thread Vineet Gupta

On 08/29/2013 08:34 AM, Sedat Dilek wrote:
> On Wed, Aug 28, 2013 at 1:58 PM, Vineet Gupta
>  wrote:
>> Hi David,
>>
>> On 06/26/2013 04:59 AM, Davidlohr Bueso wrote:
>>> On Tue, 2013-06-25 at 23:41 +0200, Sedat Dilek wrote:
 On Tue, Jun 25, 2013 at 10:33 PM, Davidlohr Bueso
  wrote:
> On Tue, 2013-06-25 at 18:10 +0200, Sedat Dilek wrote:
> [...]
>
>> I did some more testing with Linux-Testing-Project (release:
>> ltp-full-20130503) and next-20130624 (Monday) which has still the
>> issue, here.
>>
>> If I revert the mentioned two commits from my local
>> revert-ipc-next20130624-5089fd1c6a6a-ab9efc2d0db5 GIT repo, everything
>> is fine.
>>
>> I have tested the LTP ***IPC*** and ***SYSCALLS*** testcases.
>>
>>root# ./runltp -f ipc
>>
>>root# ./runltp -f syscalls
> These are nice test cases!
>
> So I was able to reproduce the issue with LTP and manually running
> msgctl08. We seemed to be racing at find_msg(), so take to q_perm lock
> before calling it. The following changes fixes the issue and passes all
> 'runltp -f syscall' tests, could you give it a try?
>
 Cool, that fixes the issues here.

 Building with fakeroot & make deb-pkg is now OK, again.

 The syscalls/msgctl08 test-case ran successfully!
>>> Andrew, could you pick this one up? I've made the patch on top of
>>> 3.10.0-rc7-next-20130625
>> LTP msgctl08 hangs on 3.11-rc7 (ARC port) with some of my local changes. I
>> bisected it, sigh... didn't look at this thread earlier :-( and landed into 
>> this.
>>
>> ->8
>> 3dd1f784ed6603d7ab1043e51e6371235edf2313 is the first bad commit
>> commit 3dd1f784ed6603d7ab1043e51e6371235edf2313
>> Author: Davidlohr Bueso 
>> Date:   Mon Jul 8 16:01:17 2013 -0700
>>
>> ipc,msg: shorten critical region in msgsnd
>>
>> do_msgsnd() is another function that does too many things with the ipc
>> object lock acquired.  Take it only when needed when actually updating
>> msq.
>> ->8
>>
>> If I revert 3dd1f784ed66 and 9ad66ae "ipc: remove unused functions" - the 
>> test
>> passes. I can confirm that linux-next also has the issue (didn't try the 
>> revert
>> there though).
>>
>> 1. arc 3.11-rc7 config attached (UP + PREEMPT)
>> 2. dmesg prints "msgmni has been set to 479"
>> 3. LTP output (this is slightly dated source, so prints might vary)
>>
>> ->8
>> <<>>
>> tag=msgctl08 stime=1377689180
>> cmdline="msgctl08"
>> contacts=""
>> analysis=exit
>> initiation_status="ok"
>> <<>>
>> ->8 hung here --
>>
>>
>> Let me know if you need more data/test help.
>>
> Cannot say much to your constellation as I had the issue on x86-64 and
> Linux-next.
> But I have just seen a post-v3.11-rc7 IPC-fix in [1].
>
> I have here a v3.11-rc7 kernel with drm-intel-nightly on top... did not run 
> LTP.

Not sure what you mean - I'd posted that Im seeing the issue on ARC Linux (an 
FPGA
board) 3.11-rc7 as well as linux-next of yesterday.

> Which LTP release do you use?

The LTP build I generally use is from a 2007 based sources (lazy me). However I
knew this would come up so before posting, I'd built the latest from buildroot 
and
ran the msgctl08 from there standalone and it did the same thing.

> Might be good to attach your kernel-config for followers?

It was already there in my orig msg - you probably missed it.

> [1] 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=368ae537e056acd3f751fa276f48423f06803922

I tried linux-next of today, same deal - msgctl08 still hangs.

-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ipc-msg broken again on 3.11-rc7? (was Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ])

2013-08-29 Thread Vineet Gupta

On 08/29/2013 08:34 AM, Sedat Dilek wrote:
On Wed, Aug 28, 2013 at 1:58 PM, Vineet Gupta
vineet.gup...@synopsys.com wrote:
Hi David,

On 06/26/2013 04:59 AM, Davidlohr Bueso wrote:
On Tue, 2013-06-25 at 23:41 +0200, Sedat Dilek wrote:
On Tue, Jun 25, 2013 at 10:33 PM, Davidlohr Bueso
davidlohr.bu...@hp.com wrote:
On Tue, 2013-06-25 at 18:10 +0200, Sedat Dilek wrote:
[...]

I did some more testing with Linux-Testing-Project (release:
ltp-full-20130503) and next-20130624 (Monday) which has still the
issue, here.

If I revert the mentioned two commits from my local
revert-ipc-next20130624-5089fd1c6a6a-ab9efc2d0db5 GIT repo, everything
is fine.

I have tested the LTP ***IPC*** and ***SYSCALLS*** testcases.

root# ./runltp -f ipc

root# ./runltp -f syscalls
These are nice test cases!

So I was able to reproduce the issue with LTP and manually running
msgctl08. We seemed to be racing at find_msg(), so take to q_perm lock
before calling it. The following changes fixes the issue and passes all
'runltp -f syscall' tests, could you give it a try?

Cool, that fixes the issues here.

Building with fakeroot make deb-pkg is now OK, again.

The syscalls/msgctl08 test-case ran successfully!
Andrew, could you pick this one up? I've made the patch on top of
3.10.0-rc7-next-20130625
LTP msgctl08 hangs on 3.11-rc7 (ARC port) with some of my local changes. I
bisected it, sigh... didn't look at this thread earlier :-( and landed into
this.

-8
3dd1f784ed6603d7ab1043e51e6371235edf2313 is the first bad commit
commit 3dd1f784ed6603d7ab1043e51e6371235edf2313
Author: Davidlohr Bueso davidlohr.bu...@hp.com
Date: Mon Jul 8 16:01:17 2013 -0700

ipc,msg: shorten critical region in msgsnd

do_msgsnd() is another function that does too many things with the ipc
object lock acquired. Take it only when needed when actually updating
msq.
-8

If I revert 3dd1f784ed66 and 9ad66ae ipc: remove unused functions - the
test
passes. I can confirm that linux-next also has the issue (didn't try the
revert
there though).

1. arc 3.11-rc7 config attached (UP + PREEMPT)
2. dmesg prints msgmni has been set to 479
3. LTP output (this is slightly dated source, so prints might vary)

-8
test_start
tag=msgctl08 stime=1377689180
cmdline=msgctl08
contacts=
analysis=exit
initiation_status=ok
test_output
-8 hung here --

Let me know if you need more data/test help.

Cannot say much to your constellation as I had the issue on x86-64 and
Linux-next.
But I have just seen a post-v3.11-rc7 IPC-fix in [1].

I have here a v3.11-rc7 kernel with drm-intel-nightly on top... did not run
LTP.

Not sure what you mean - I'd posted that Im seeing the issue on ARC Linux (an
FPGA
board) 3.11-rc7 as well as linux-next of yesterday.

Which LTP release do you use?

The LTP build I generally use is from a 2007 based sources (lazy me). However I
knew this would come up so before posting, I'd built the latest from buildroot
and
ran the msgctl08 from there standalone and it did the same thing.

Might be good to attach your kernel-config for followers?

It was already there in my orig msg - you probably missed it.

[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=368ae537e056acd3f751fa276f48423f06803922

I tried linux-next of today, same deal - msgctl08 still hangs.

-Vineet
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: ipc-msg broken again on 3.11-rc7? (was Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ])

2013-08-29 Thread Sedat Dilek

On Thu, Aug 29, 2013 at 9:21 AM, Vineet Gupta
vineet.gup...@synopsys.com wrote:
On 08/29/2013 08:34 AM, Sedat Dilek wrote:
On Wed, Aug 28, 2013 at 1:58 PM, Vineet Gupta
vineet.gup...@synopsys.com wrote:
Hi David,

I did some more testing with Linux-Testing-Project (release:
ltp-full-20130503) and next-20130624 (Monday) which has still the
issue, here.

If I revert the mentioned two commits from my local
revert-ipc-next20130624-5089fd1c6a6a-ab9efc2d0db5 GIT repo, everything
is fine.

I have tested the LTP ***IPC*** and ***SYSCALLS*** testcases.

root# ./runltp -f ipc

root# ./runltp -f syscalls
These are nice test cases!

Cool, that fixes the issues here.

Building with fakeroot make deb-pkg is now OK, again.

-8
3dd1f784ed6603d7ab1043e51e6371235edf2313 is the first bad commit
commit 3dd1f784ed6603d7ab1043e51e6371235edf2313
Author: Davidlohr Bueso davidlohr.bu...@hp.com
Date: Mon Jul 8 16:01:17 2013 -0700

ipc,msg: shorten critical region in msgsnd

do_msgsnd() is another function that does too many things with the ipc
object lock acquired. Take it only when needed when actually updating
msq.
-8

If I revert 3dd1f784ed66 and 9ad66ae ipc: remove unused functions - the
test
passes. I can confirm that linux-next also has the issue (didn't try the
revert
there though).

1. arc 3.11-rc7 config attached (UP + PREEMPT)
2. dmesg prints msgmni has been set to 479
3. LTP output (this is slightly dated source, so prints might vary)

-8
test_start
tag=msgctl08 stime=1377689180
cmdline=msgctl08
contacts=
analysis=exit
initiation_status=ok
test_output
-8 hung here --

Let me know if you need more data/test help.

Cannot say much to your constellation as I had the issue on x86-64 and
Linux-next.
But I have just seen a post-v3.11-rc7 IPC-fix in [1].

I have here a v3.11-rc7 kernel with drm-intel-nightly on top... did not run
LTP.

Not sure what you mean - I'd posted that Im seeing the issue on ARC Linux (an
FPGA
board) 3.11-rc7 as well as linux-next of yesterday.

I am not saying there is no issue, but I have no possibility to test
for ARC arch.

Which LTP release do you use?

The LTP build I generally use is from a 2007 based sources (lazy me). However
I
knew this would come up so before posting, I'd built the latest from
buildroot and
ran the msgctl08 from there standalone and it did the same thing.

Try always latest LTP-stable (03-May-2013 is what I tried). AFAICS a
new release is planned soon.

Might be good to attach your kernel-config for followers?

It was already there in my orig msg - you probably missed it.

I have got that response from you only :-).

[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=368ae537e056acd3f751fa276f48423f06803922

I tried linux-next of today, same deal - msgctl08 still hangs.

That above fix [1] in Linus-tree is also in next-20130828.

Hope Davidlohr and fellows can help you.

- Sedat -
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: ipc-msg broken again on 3.11-rc7? (was Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ])

2013-08-28 Thread Sedat Dilek

On Wed, Aug 28, 2013 at 1:58 PM, Vineet Gupta
 wrote:
> Hi David,
>
> On 06/26/2013 04:59 AM, Davidlohr Bueso wrote:
>> On Tue, 2013-06-25 at 23:41 +0200, Sedat Dilek wrote:
>>> On Tue, Jun 25, 2013 at 10:33 PM, Davidlohr Bueso
>>>  wrote:
 On Tue, 2013-06-25 at 18:10 +0200, Sedat Dilek wrote:
 [...]

> I did some more testing with Linux-Testing-Project (release:
> ltp-full-20130503) and next-20130624 (Monday) which has still the
> issue, here.
>
> If I revert the mentioned two commits from my local
> revert-ipc-next20130624-5089fd1c6a6a-ab9efc2d0db5 GIT repo, everything
> is fine.
>
> I have tested the LTP ***IPC*** and ***SYSCALLS*** testcases.
>
>root# ./runltp -f ipc
>
>root# ./runltp -f syscalls

 These are nice test cases!

 So I was able to reproduce the issue with LTP and manually running
 msgctl08. We seemed to be racing at find_msg(), so take to q_perm lock
 before calling it. The following changes fixes the issue and passes all
 'runltp -f syscall' tests, could you give it a try?

>>>
>>> Cool, that fixes the issues here.
>>>
>>> Building with fakeroot & make deb-pkg is now OK, again.
>>>
>>> The syscalls/msgctl08 test-case ran successfully!
>>
>> Andrew, could you pick this one up? I've made the patch on top of
>> 3.10.0-rc7-next-20130625
>
> LTP msgctl08 hangs on 3.11-rc7 (ARC port) with some of my local changes. I
> bisected it, sigh... didn't look at this thread earlier :-( and landed into 
> this.
>
> ->8
> 3dd1f784ed6603d7ab1043e51e6371235edf2313 is the first bad commit
> commit 3dd1f784ed6603d7ab1043e51e6371235edf2313
> Author: Davidlohr Bueso 
> Date:   Mon Jul 8 16:01:17 2013 -0700
>
> ipc,msg: shorten critical region in msgsnd
>
> do_msgsnd() is another function that does too many things with the ipc
> object lock acquired.  Take it only when needed when actually updating
> msq.
> ->8
>
> If I revert 3dd1f784ed66 and 9ad66ae "ipc: remove unused functions" - the test
> passes. I can confirm that linux-next also has the issue (didn't try the 
> revert
> there though).
>
> 1. arc 3.11-rc7 config attached (UP + PREEMPT)
> 2. dmesg prints "msgmni has been set to 479"
> 3. LTP output (this is slightly dated source, so prints might vary)
>
> ->8
> <<>>
> tag=msgctl08 stime=1377689180
> cmdline="msgctl08"
> contacts=""
> analysis=exit
> initiation_status="ok"
> <<>>
> ->8 hung here --
>
>
> Let me know if you need more data/test help.
>

Cannot say much to your constellation as I had the issue on x86-64 and
Linux-next.
But I have just seen a post-v3.11-rc7 IPC-fix in [1].

I have here a v3.11-rc7 kernel with drm-intel-nightly on top... did not run LTP.

Which LTP release do you use?
Might be good to attach your kernel-config for followers?

- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=368ae537e056acd3f751fa276f48423f06803922
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ipc-msg broken again on 3.11-rc7? (was Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ])

2013-08-28 Thread Vineet Gupta

Hi David,

On 06/26/2013 04:59 AM, Davidlohr Bueso wrote:
> On Tue, 2013-06-25 at 23:41 +0200, Sedat Dilek wrote:
>> On Tue, Jun 25, 2013 at 10:33 PM, Davidlohr Bueso
>>  wrote:
>>> On Tue, 2013-06-25 at 18:10 +0200, Sedat Dilek wrote:
>>> [...]
>>>
 I did some more testing with Linux-Testing-Project (release:
 ltp-full-20130503) and next-20130624 (Monday) which has still the
 issue, here.

 If I revert the mentioned two commits from my local
 revert-ipc-next20130624-5089fd1c6a6a-ab9efc2d0db5 GIT repo, everything
 is fine.

 I have tested the LTP ***IPC*** and ***SYSCALLS*** testcases.

root# ./runltp -f ipc

root# ./runltp -f syscalls
>>>
>>> These are nice test cases!
>>>
>>> So I was able to reproduce the issue with LTP and manually running
>>> msgctl08. We seemed to be racing at find_msg(), so take to q_perm lock
>>> before calling it. The following changes fixes the issue and passes all
>>> 'runltp -f syscall' tests, could you give it a try?
>>>
>>
>> Cool, that fixes the issues here.
>>
>> Building with fakeroot & make deb-pkg is now OK, again.
>>
>> The syscalls/msgctl08 test-case ran successfully!
> 
> Andrew, could you pick this one up? I've made the patch on top of
> 3.10.0-rc7-next-20130625

LTP msgctl08 hangs on 3.11-rc7 (ARC port) with some of my local changes. I
bisected it, sigh... didn't look at this thread earlier :-( and landed into 
this.

->8
3dd1f784ed6603d7ab1043e51e6371235edf2313 is the first bad commit
commit 3dd1f784ed6603d7ab1043e51e6371235edf2313
Author: Davidlohr Bueso 
Date:   Mon Jul 8 16:01:17 2013 -0700

ipc,msg: shorten critical region in msgsnd

do_msgsnd() is another function that does too many things with the ipc
object lock acquired.  Take it only when needed when actually updating
msq.
->8

If I revert 3dd1f784ed66 and 9ad66ae "ipc: remove unused functions" - the test
passes. I can confirm that linux-next also has the issue (didn't try the revert
there though).

1. arc 3.11-rc7 config attached (UP + PREEMPT)
2. dmesg prints "msgmni has been set to 479"
3. LTP output (this is slightly dated source, so prints might vary)

->8
<<>>
tag=msgctl08 stime=1377689180
cmdline="msgctl08"
contacts=""
analysis=exit
initiation_status="ok"
<<>>
->8 hung here --


Let me know if you need more data/test help.

-Vineet
#
# Automatically generated file; DO NOT EDIT.
# Linux/arc 3.11.0-rc7 Kernel Configuration
#
CONFIG_ARC=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_GENERIC_CSUM=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_MMU=y
CONFIG_NO_IOPORT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
# CONFIG_NO_DMA is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE="arc-linux-uclibc-"
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_DEFAULT_HOSTNAME="ARCLinux"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_FHANDLE is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_IRQ_DOMAIN=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_BOOST is not set
# CONFIG_RCU_NOCB_CPU is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
CONFIG_IPC_NS=y
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
CONFIG_NET_NS=y
CONFIG_UIDGID_CONVERTED=y
# CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="../arc_initramfs/"
CONFIG_INITRAMFS_ROOT_UID=0
CONFIG_INITRAMFS_ROOT_GID=0
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
CONFIG_INITRAMFS_COMPRESSION_NONE=y
# CONFIG_INITRAMFS_COMPRESSION_GZIP is not set
#

ipc-msg broken again on 3.11-rc7? (was Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ])

2013-08-28 Thread Vineet Gupta

Hi David,

On 06/26/2013 04:59 AM, Davidlohr Bueso wrote:
 On Tue, 2013-06-25 at 23:41 +0200, Sedat Dilek wrote:
 On Tue, Jun 25, 2013 at 10:33 PM, Davidlohr Bueso
 davidlohr.bu...@hp.com wrote:
 On Tue, 2013-06-25 at 18:10 +0200, Sedat Dilek wrote:
 [...]

 I did some more testing with Linux-Testing-Project (release:
 ltp-full-20130503) and next-20130624 (Monday) which has still the
 issue, here.

 If I revert the mentioned two commits from my local
 revert-ipc-next20130624-5089fd1c6a6a-ab9efc2d0db5 GIT repo, everything
 is fine.

 I have tested the LTP ***IPC*** and ***SYSCALLS*** testcases.

root# ./runltp -f ipc

root# ./runltp -f syscalls

 These are nice test cases!

 So I was able to reproduce the issue with LTP and manually running
 msgctl08. We seemed to be racing at find_msg(), so take to q_perm lock
 before calling it. The following changes fixes the issue and passes all
 'runltp -f syscall' tests, could you give it a try?


 Cool, that fixes the issues here.

 Building with fakeroot  make deb-pkg is now OK, again.

 The syscalls/msgctl08 test-case ran successfully!
 
 Andrew, could you pick this one up? I've made the patch on top of
 3.10.0-rc7-next-20130625

LTP msgctl08 hangs on 3.11-rc7 (ARC port) with some of my local changes. I
bisected it, sigh... didn't look at this thread earlier :-( and landed into 
this.

-8
3dd1f784ed6603d7ab1043e51e6371235edf2313 is the first bad commit
commit 3dd1f784ed6603d7ab1043e51e6371235edf2313
Author: Davidlohr Bueso davidlohr.bu...@hp.com
Date:   Mon Jul 8 16:01:17 2013 -0700

ipc,msg: shorten critical region in msgsnd

do_msgsnd() is another function that does too many things with the ipc
object lock acquired.  Take it only when needed when actually updating
msq.
-8

If I revert 3dd1f784ed66 and 9ad66ae ipc: remove unused functions - the test
passes. I can confirm that linux-next also has the issue (didn't try the revert
there though).

1. arc 3.11-rc7 config attached (UP + PREEMPT)
2. dmesg prints msgmni has been set to 479
3. LTP output (this is slightly dated source, so prints might vary)

-8
test_start
tag=msgctl08 stime=1377689180
cmdline=msgctl08
contacts=
analysis=exit
initiation_status=ok
test_output
-8 hung here --


Let me know if you need more data/test help.

-Vineet
#
# Automatically generated file; DO NOT EDIT.
# Linux/arc 3.11.0-rc7 Kernel Configuration
#
CONFIG_ARC=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_GENERIC_CSUM=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_MMU=y
CONFIG_NO_IOPORT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
# CONFIG_NO_DMA is not set
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
CONFIG_IRQ_WORK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=arc-linux-uclibc-
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_DEFAULT_HOSTNAME=ARCLinux
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_FHANDLE is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_IRQ_DOMAIN=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_BOOST is not set
# CONFIG_RCU_NOCB_CPU is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
CONFIG_IPC_NS=y
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
CONFIG_NET_NS=y
CONFIG_UIDGID_CONVERTED=y
# CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=../arc_initramfs/
CONFIG_INITRAMFS_ROOT_UID=0
CONFIG_INITRAMFS_ROOT_GID=0
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
CONFIG_INITRAMFS_COMPRESSION_NONE=y
# CONFIG_INITRAMFS_COMPRESSION_GZIP is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_EXPERT=y

Re: ipc-msg broken again on 3.11-rc7? (was Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ])

2013-08-28 Thread Sedat Dilek

On Wed, Aug 28, 2013 at 1:58 PM, Vineet Gupta
vineet.gup...@synopsys.com wrote:
Hi David,

I did some more testing with Linux-Testing-Project (release:
ltp-full-20130503) and next-20130624 (Monday) which has still the
issue, here.

If I revert the mentioned two commits from my local
revert-ipc-next20130624-5089fd1c6a6a-ab9efc2d0db5 GIT repo, everything
is fine.

I have tested the LTP ***IPC*** and ***SYSCALLS*** testcases.

root# ./runltp -f ipc

root# ./runltp -f syscalls

These are nice test cases!

Cool, that fixes the issues here.

Building with fakeroot make deb-pkg is now OK, again.

The syscalls/msgctl08 test-case ran successfully!

Andrew, could you pick this one up? I've made the patch on top of
3.10.0-rc7-next-20130625

LTP msgctl08 hangs on 3.11-rc7 (ARC port) with some of my local changes. I
bisected it, sigh... didn't look at this thread earlier :-( and landed into
this.

-8
3dd1f784ed6603d7ab1043e51e6371235edf2313 is the first bad commit
commit 3dd1f784ed6603d7ab1043e51e6371235edf2313
Author: Davidlohr Bueso davidlohr.bu...@hp.com
Date: Mon Jul 8 16:01:17 2013 -0700

ipc,msg: shorten critical region in msgsnd

do_msgsnd() is another function that does too many things with the ipc
object lock acquired. Take it only when needed when actually updating
msq.
-8

If I revert 3dd1f784ed66 and 9ad66ae ipc: remove unused functions - the test
passes. I can confirm that linux-next also has the issue (didn't try the
revert
there though).

1. arc 3.11-rc7 config attached (UP + PREEMPT)
2. dmesg prints msgmni has been set to 479
3. LTP output (this is slightly dated source, so prints might vary)

-8
test_start
tag=msgctl08 stime=1377689180
cmdline=msgctl08
contacts=
analysis=exit
initiation_status=ok
test_output
-8 hung here --

Let me know if you need more data/test help.

Cannot say much to your constellation as I had the issue on x86-64 and
Linux-next.
But I have just seen a post-v3.11-rc7 IPC-fix in [1].

I have here a v3.11-rc7 kernel with drm-intel-nightly on top... did not run LTP.

Which LTP release do you use?
Might be good to attach your kernel-config for followers?

- Sedat -

[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=368ae537e056acd3f751fa276f48423f06803922
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ]

On Tue, 2013-06-25 at 23:41 +0200, Sedat Dilek wrote:
> On Tue, Jun 25, 2013 at 10:33 PM, Davidlohr Bueso
>  wrote:
> > On Tue, 2013-06-25 at 18:10 +0200, Sedat Dilek wrote:
> > [...]
> >
> >> I did some more testing with Linux-Testing-Project (release:
> >> ltp-full-20130503) and next-20130624 (Monday) which has still the
> >> issue, here.
> >>
> >> If I revert the mentioned two commits from my local
> >> revert-ipc-next20130624-5089fd1c6a6a-ab9efc2d0db5 GIT repo, everything
> >> is fine.
> >>
> >> I have tested the LTP ***IPC*** and ***SYSCALLS*** testcases.
> >>
> >>root# ./runltp -f ipc
> >>
> >>root# ./runltp -f syscalls
> >
> > These are nice test cases!
> >
> > So I was able to reproduce the issue with LTP and manually running
> > msgctl08. We seemed to be racing at find_msg(), so take to q_perm lock
> > before calling it. The following changes fixes the issue and passes all
> > 'runltp -f syscall' tests, could you give it a try?
> >
> 
> Cool, that fixes the issues here.
> 
> Building with fakeroot & make deb-pkg is now OK, again.
> 
> The syscalls/msgctl08 test-case ran successfully!

Andrew, could you pick this one up? I've made the patch on top of
3.10.0-rc7-next-20130625

Thanks.
Davidlohr

8<-

From: Davidlohr Bueso 
Subject: [PATCH] ipc,msq: fix race in msgrcv(2)

Sedat reported the following issue when building the latest linux-next:

Building via 'make deb-pkg' with fakeroot fails here like this:

make: *** [deb-pkg] Terminated
/usr/bin/fakeroot: line 181:  2386 Terminated
FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB"
"$@"
semop(1): encountered an error: Identifier removed
semop(2): encountered an error: Invalid argument
semop(1): encountered an error: Identifier removed
semop(1): encountered an error: Identifier removed
semop(1): encountered an error: Invalid argument
semop(1): encountered an error: Invalid argument
semop(1): encountered an error: Invalid argument

The issue was caused by a race in find_msg(), so acquire the q_perm.lock
before calling the function. This also broke some LTP test cases:

<<>>
tag=msgctl08 stime=1372174954
cmdline="msgctl08"
contacts=""
analysis=exit
<<>>
msgctl080  TWARN  :  Verify error in child 0, *buf = 28, val = 27, size = 8
msgctl081  TFAIL  :  in child 0 read # = 73,key =  127
msgctl080  TWARN  :  Verify error in child 3, *buf = ff8a, val
= ff89, size = 52
msgctl081  TFAIL  :  in child 3 read # = 157,key =  189
msgctl080  TWARN  :  Verify error in child 2, *buf = ff87, val
= ff86, size = 71
msgctl081  TFAIL  :  in child 2 read # = 15954,key =  3e86
msgctl080  TWARN  :  Verify error in child 12, *buf = ffa9,
val = ffa8, size = 22
msgctl081  TFAIL  :  in child 12 read # = 12904,key =  32a8
msgctl080  TWARN  :  Verify error in child 13, *buf = 36, val =
35, size = 27
...

Also update a comment referring to ipc_lock_by_ptr(), which has already been 
deleted
and no longer applies to this context.

Reported-and-tested-by: Sedat Dilek 
Signed-off-by: Davidlohr Bueso 
---
 ipc/msg.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/ipc/msg.c b/ipc/msg.c
index a1cf70e..bd60d7e 100644
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -895,6 +895,7 @@ long do_msgrcv(int msqid, void __user *buf, size_t bufsz, 
long msgtyp, int msgfl
if (ipcperms(ns, >q_perm, S_IRUGO))
goto out_unlock1;
 
+   ipc_lock_object(>q_perm);
msg = find_msg(msq, , mode);
if (!IS_ERR(msg)) {
/*
@@ -903,7 +904,7 @@ long do_msgrcv(int msqid, void __user *buf, size_t bufsz, 
long msgtyp, int msgfl
 */
if ((bufsz < msg->m_ts) && !(msgflg & MSG_NOERROR)) {
msg = ERR_PTR(-E2BIG);
-   goto out_unlock1;
+   goto out_unlock0;
}
/*
 * If we are copying, then do not unlink message and do
@@ -911,10 +912,9 @@ long do_msgrcv(int msqid, void __user *buf, size_t bufsz, 
long msgtyp, int msgfl
 */
if (msgflg & MSG_COPY) {
msg = copy_msg(msg, copy);
-   goto out_unlock1;
+   goto out_unlock0;
}
 
-   ipc_lock_object(>q_perm);
list_del(>m_list);
msq->q_qnum--;
msq->q_rtime = get_seconds();
@@ -930,10 +930,9 @@ long do_msgrcv(int msqid, void __user *buf, size_t bufsz, 
long msgtyp, int msgfl
/* No message waiting. Wait for a message */
if (msgflg & IPC_NOWAIT) {
msg = ERR_PTR(-ENOMSG);
-   goto out_unlock1;
+   goto

Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ]

On Tue, 2013-06-25 at 18:10 +0200, Sedat Dilek wrote:
[...]

> I did some more testing with Linux-Testing-Project (release:
> ltp-full-20130503) and next-20130624 (Monday) which has still the
> issue, here.
> 
> If I revert the mentioned two commits from my local
> revert-ipc-next20130624-5089fd1c6a6a-ab9efc2d0db5 GIT repo, everything
> is fine.
> 
> I have tested the LTP ***IPC*** and ***SYSCALLS*** testcases.
> 
>root# ./runltp -f ipc
> 
>root# ./runltp -f syscalls

These are nice test cases!

So I was able to reproduce the issue with LTP and manually running
msgctl08. We seemed to be racing at find_msg(), so take to q_perm lock
before calling it. The following changes fixes the issue and passes all
'runltp -f syscall' tests, could you give it a try?

Thanks,
Davidlohr

diff --git a/ipc/msg.c b/ipc/msg.c
index a1cf70e..a1f7d84 100644
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -895,6 +895,7 @@ long do_msgrcv(int msqid, void __user *buf, size_t bufsz, 
long msgtyp, int msgfl
if (ipcperms(ns, >q_perm, S_IRUGO))
goto out_unlock1;
 
+   ipc_lock_object(>q_perm);
msg = find_msg(msq, , mode);
if (!IS_ERR(msg)) {
/*
@@ -903,7 +904,7 @@ long do_msgrcv(int msqid, void __user *buf, size_t bufsz, 
long msgtyp, int msgfl
 */
if ((bufsz < msg->m_ts) && !(msgflg & MSG_NOERROR)) {
msg = ERR_PTR(-E2BIG);
-   goto out_unlock1;
+   goto out_unlock0;
}
/*
 * If we are copying, then do not unlink message and do
@@ -911,10 +912,9 @@ long do_msgrcv(int msqid, void __user *buf, size_t bufsz, 
long msgtyp, int msgfl
 */
if (msgflg & MSG_COPY) {
msg = copy_msg(msg, copy);
-   goto out_unlock1;
+   goto out_unlock0;
}
 
-   ipc_lock_object(>q_perm);
list_del(>m_list);
msq->q_qnum--;
msq->q_rtime = get_seconds();
@@ -930,10 +930,9 @@ long do_msgrcv(int msqid, void __user *buf, size_t bufsz, 
long msgtyp, int msgfl
/* No message waiting. Wait for a message */
if (msgflg & IPC_NOWAIT) {
msg = ERR_PTR(-ENOMSG);
-   goto out_unlock1;
+   goto out_unlock0;
}
 
-   ipc_lock_object(>q_perm);
list_add_tail(_d.r_list, >q_receivers);
msr_d.r_tsk = current;
msr_d.r_msgtype = msgtyp;


Thanks,
Davidlohr
> 
> IPC seems to be fine for both -1 (UNPATCHED) and -2 (with attached two
> REVERTED patches) kernel, but -1 hangs in the SYSCALLS/msgctl08 test.
> 
> Previous msgctl07 is OK, but ***msgctl08*** produces this:
> ...
> <<>>
> tag=msgctl07 stime=1372174934
> cmdline="msgctl07"
> contacts=""
> analysis=exit
> <<>>
> msgctl071  TPASS  :  msgctl07 ran successfully!
> <<>>
> initiation_status="ok"
> duration=20 termination_type=exited termination_id=0 corefile=no
> cutime=1995 cstime=3
> <<>>
> <<>>
> tag=msgctl08 stime=1372174954
> cmdline="msgctl08"
> contacts=""
> analysis=exit
> <<>>
> msgctl080  TWARN  :  Verify error in child 0, *buf = 28, val = 27, size = 
> 8
> msgctl081  TFAIL  :  in child 0 read # = 73,key =  127
> msgctl080  TWARN  :  Verify error in child 3, *buf = ff8a, val
> = ff89, size = 52
> msgctl081  TFAIL  :  in child 3 read # = 157,key =  189
> msgctl080  TWARN  :  Verify error in child 2, *buf = ff87, val
> = ff86, size = 71
> msgctl081  TFAIL  :  in child 2 read # = 15954,key =  3e86
> msgctl080  TWARN  :  Verify error in child 12, *buf = ffa9,
> val = ffa8, size = 22
> msgctl081  TFAIL  :  in child 12 read # = 12904,key =  32a8
> msgctl080  TWARN  :  Verify error in child 13, *buf = 36, val =
> 35, size = 27
> msgctl081  TFAIL  :  in child 13 read # = 10442,key =  2935
> msgctl080  TWARN  :  Verify error in child 10, *buf = ff86,
> val = ff85, size = 63
> msgctl081  TFAIL  :  in child 10 read # = 19713,key =  4d85
> msgctl080  TWARN  :  Verify error in child 4, *buf = 4c, val = 4b, size = 
> 83
> msgctl081  TFAIL  :  in child 4 read # = 23082,key =  5a4b
> msgctl080  TWARN  :  Verify error in child 15, *buf = 61, val =
> 60, size = 94
> msgctl081  TFAIL  :  in child 15 read # = 23554,key =  5c60
> msgctl080  TWARN  :  Verify error in child 11, *buf = 3b, val =
> 3a, size = 22
> msgctl081  TFAIL  :  in child 11 read # = 26468,key =  683a
> msgctl080  TWARN  :  Verify error in child 5, *buf = ffb5, val
> = ffb4, size = 41
> msgctl081  TFAIL  :  in child 5 read # = 31867,key =

Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ]

On Tue, 2013-06-25 at 18:10 +0200, Sedat Dilek wrote:
[...]

 I did some more testing with Linux-Testing-Project (release:
 ltp-full-20130503) and next-20130624 (Monday) which has still the
 issue, here.
 
 If I revert the mentioned two commits from my local
 revert-ipc-next20130624-5089fd1c6a6a-ab9efc2d0db5 GIT repo, everything
 is fine.
 
 I have tested the LTP ***IPC*** and ***SYSCALLS*** testcases.
 
root# ./runltp -f ipc
 
root# ./runltp -f syscalls

These are nice test cases!

So I was able to reproduce the issue with LTP and manually running
msgctl08. We seemed to be racing at find_msg(), so take to q_perm lock
before calling it. The following changes fixes the issue and passes all
'runltp -f syscall' tests, could you give it a try?

Thanks,
Davidlohr

diff --git a/ipc/msg.c b/ipc/msg.c
index a1cf70e..a1f7d84 100644
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -895,6 +895,7 @@ long do_msgrcv(int msqid, void __user *buf, size_t bufsz, 
long msgtyp, int msgfl
if (ipcperms(ns, msq-q_perm, S_IRUGO))
goto out_unlock1;
 
+   ipc_lock_object(msq-q_perm);
msg = find_msg(msq, msgtyp, mode);
if (!IS_ERR(msg)) {
/*
@@ -903,7 +904,7 @@ long do_msgrcv(int msqid, void __user *buf, size_t bufsz, 
long msgtyp, int msgfl
 */
if ((bufsz  msg-m_ts)  !(msgflg  MSG_NOERROR)) {
msg = ERR_PTR(-E2BIG);
-   goto out_unlock1;
+   goto out_unlock0;
}
/*
 * If we are copying, then do not unlink message and do
@@ -911,10 +912,9 @@ long do_msgrcv(int msqid, void __user *buf, size_t bufsz, 
long msgtyp, int msgfl
 */
if (msgflg  MSG_COPY) {
msg = copy_msg(msg, copy);
-   goto out_unlock1;
+   goto out_unlock0;
}
 
-   ipc_lock_object(msq-q_perm);
list_del(msg-m_list);
msq-q_qnum--;
msq-q_rtime = get_seconds();
@@ -930,10 +930,9 @@ long do_msgrcv(int msqid, void __user *buf, size_t bufsz, 
long msgtyp, int msgfl
/* No message waiting. Wait for a message */
if (msgflg  IPC_NOWAIT) {
msg = ERR_PTR(-ENOMSG);
-   goto out_unlock1;
+   goto out_unlock0;
}
 
-   ipc_lock_object(msq-q_perm);
list_add_tail(msr_d.r_list, msq-q_receivers);
msr_d.r_tsk = current;
msr_d.r_msgtype = msgtyp;


Thanks,
Davidlohr
 
 IPC seems to be fine for both -1 (UNPATCHED) and -2 (with attached two
 REVERTED patches) kernel, but -1 hangs in the SYSCALLS/msgctl08 test.
 
 Previous msgctl07 is OK, but ***msgctl08*** produces this:
 ...
 test_start
 tag=msgctl07 stime=1372174934
 cmdline=msgctl07
 contacts=
 analysis=exit
 test_output
 msgctl071  TPASS  :  msgctl07 ran successfully!
 execution_status
 initiation_status=ok
 duration=20 termination_type=exited termination_id=0 corefile=no
 cutime=1995 cstime=3
 test_end
 test_start
 tag=msgctl08 stime=1372174954
 cmdline=msgctl08
 contacts=
 analysis=exit
 test_output
 msgctl080  TWARN  :  Verify error in child 0, *buf = 28, val = 27, size = 
 8
 msgctl081  TFAIL  :  in child 0 read # = 73,key =  127
 msgctl080  TWARN  :  Verify error in child 3, *buf = ff8a, val
 = ff89, size = 52
 msgctl081  TFAIL  :  in child 3 read # = 157,key =  189
 msgctl080  TWARN  :  Verify error in child 2, *buf = ff87, val
 = ff86, size = 71
 msgctl081  TFAIL  :  in child 2 read # = 15954,key =  3e86
 msgctl080  TWARN  :  Verify error in child 12, *buf = ffa9,
 val = ffa8, size = 22
 msgctl081  TFAIL  :  in child 12 read # = 12904,key =  32a8
 msgctl080  TWARN  :  Verify error in child 13, *buf = 36, val =
 35, size = 27
 msgctl081  TFAIL  :  in child 13 read # = 10442,key =  2935
 msgctl080  TWARN  :  Verify error in child 10, *buf = ff86,
 val = ff85, size = 63
 msgctl081  TFAIL  :  in child 10 read # = 19713,key =  4d85
 msgctl080  TWARN  :  Verify error in child 4, *buf = 4c, val = 4b, size = 
 83
 msgctl081  TFAIL  :  in child 4 read # = 23082,key =  5a4b
 msgctl080  TWARN  :  Verify error in child 15, *buf = 61, val =
 60, size = 94
 msgctl081  TFAIL  :  in child 15 read # = 23554,key =  5c60
 msgctl080  TWARN  :  Verify error in child 11, *buf = 3b, val =
 3a, size = 22
 msgctl081  TFAIL  :  in child 11 read # = 26468,key =  683a
 msgctl080  TWARN  :  Verify error in child 5, *buf = ffb5, val
 = ffb4, size = 41
 msgctl081  TFAIL  :  in child 5 read # = 31867,key =  7cb4
 msgctl08

Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ]

On Tue, 2013-06-25 at 23:41 +0200, Sedat Dilek wrote:
 On Tue, Jun 25, 2013 at 10:33 PM, Davidlohr Bueso
 davidlohr.bu...@hp.com wrote:
  On Tue, 2013-06-25 at 18:10 +0200, Sedat Dilek wrote:
  [...]
 
  I did some more testing with Linux-Testing-Project (release:
  ltp-full-20130503) and next-20130624 (Monday) which has still the
  issue, here.
 
  If I revert the mentioned two commits from my local
  revert-ipc-next20130624-5089fd1c6a6a-ab9efc2d0db5 GIT repo, everything
  is fine.
 
  I have tested the LTP ***IPC*** and ***SYSCALLS*** testcases.
 
 root# ./runltp -f ipc
 
 root# ./runltp -f syscalls
 
  These are nice test cases!
 
  So I was able to reproduce the issue with LTP and manually running
  msgctl08. We seemed to be racing at find_msg(), so take to q_perm lock
  before calling it. The following changes fixes the issue and passes all
  'runltp -f syscall' tests, could you give it a try?
 
 
 Cool, that fixes the issues here.
 
 Building with fakeroot  make deb-pkg is now OK, again.
 
 The syscalls/msgctl08 test-case ran successfully!

Andrew, could you pick this one up? I've made the patch on top of
3.10.0-rc7-next-20130625

Thanks.
Davidlohr

8-

From: Davidlohr Bueso davidlohr.bu...@hp.com
Subject: [PATCH] ipc,msq: fix race in msgrcv(2)

Sedat reported the following issue when building the latest linux-next:

Building via 'make deb-pkg' with fakeroot fails here like this:

make: *** [deb-pkg] Terminated
/usr/bin/fakeroot: line 181:  2386 Terminated
FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH=$PATHS LD_PRELOAD=$LIB
$@
semop(1): encountered an error: Identifier removed
semop(2): encountered an error: Invalid argument
semop(1): encountered an error: Identifier removed
semop(1): encountered an error: Identifier removed
semop(1): encountered an error: Invalid argument
semop(1): encountered an error: Invalid argument
semop(1): encountered an error: Invalid argument

The issue was caused by a race in find_msg(), so acquire the q_perm.lock
before calling the function. This also broke some LTP test cases:

test_start
tag=msgctl08 stime=1372174954
cmdline=msgctl08
contacts=
analysis=exit
test_output
msgctl080  TWARN  :  Verify error in child 0, *buf = 28, val = 27, size = 8
msgctl081  TFAIL  :  in child 0 read # = 73,key =  127
msgctl080  TWARN  :  Verify error in child 3, *buf = ff8a, val
= ff89, size = 52
msgctl081  TFAIL  :  in child 3 read # = 157,key =  189
msgctl080  TWARN  :  Verify error in child 2, *buf = ff87, val
= ff86, size = 71
msgctl081  TFAIL  :  in child 2 read # = 15954,key =  3e86
msgctl080  TWARN  :  Verify error in child 12, *buf = ffa9,
val = ffa8, size = 22
msgctl081  TFAIL  :  in child 12 read # = 12904,key =  32a8
msgctl080  TWARN  :  Verify error in child 13, *buf = 36, val =
35, size = 27
...

Also update a comment referring to ipc_lock_by_ptr(), which has already been 
deleted
and no longer applies to this context.

Reported-and-tested-by: Sedat Dilek sedat.di...@gmail.com
Signed-off-by: Davidlohr Bueso davidlohr.bu...@hp.com
---
 ipc/msg.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/ipc/msg.c b/ipc/msg.c
index a1cf70e..bd60d7e 100644
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -895,6 +895,7 @@ long do_msgrcv(int msqid, void __user *buf, size_t bufsz, 
long msgtyp, int msgfl
if (ipcperms(ns, msq-q_perm, S_IRUGO))
goto out_unlock1;
 
+   ipc_lock_object(msq-q_perm);
msg = find_msg(msq, msgtyp, mode);
if (!IS_ERR(msg)) {
/*
@@ -903,7 +904,7 @@ long do_msgrcv(int msqid, void __user *buf, size_t bufsz, 
long msgtyp, int msgfl
 */
if ((bufsz  msg-m_ts)  !(msgflg  MSG_NOERROR)) {
msg = ERR_PTR(-E2BIG);
-   goto out_unlock1;
+   goto out_unlock0;
}
/*
 * If we are copying, then do not unlink message and do
@@ -911,10 +912,9 @@ long do_msgrcv(int msqid, void __user *buf, size_t bufsz, 
long msgtyp, int msgfl
 */
if (msgflg  MSG_COPY) {
msg = copy_msg(msg, copy);
-   goto out_unlock1;
+   goto out_unlock0;
}
 
-   ipc_lock_object(msq-q_perm);
list_del(msg-m_list);
msq-q_qnum--;
msq-q_rtime = get_seconds();
@@ -930,10 +930,9 @@ long do_msgrcv(int msqid, void __user *buf, size_t bufsz, 
long msgtyp, int msgfl
/* No message waiting. Wait for a message */
if (msgflg  IPC_NOWAIT) {
msg = ERR_PTR(-ENOMSG);
-   goto out_unlock1;
+

Re: linux-next: Tree for Jun 21 (netdev: openvswitch)

2013-06-21 Thread Jesse Gross

On Fri, Jun 21, 2013 at 8:22 AM, Randy Dunlap  wrote:
> On 06/21/13 01:17, Stephen Rothwell wrote:
>> Hi all,
>>
>> Happy solstice!
>>
>> Changes since 20130620:
>>
>
> when CONFIG_INET is not enabled:
>
>   CC  net/openvswitch/flow.o
> In file included from net/openvswitch/flow.c:43:0:
> include/net/ip_tunnels.h: In function 'tunnel_ip_select_ident':
> include/net/ip_tunnels.h:155:3: error: implicit declaration of function 
> '__ip_select_ident' [-Werror=implicit-function-declaration]

Thanks, I just sent out a couple of patches to fix config issues with
the recent tunneling series.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ]

On Sat, Jun 22, 2013 at 12:54 AM, Sedat Dilek  wrote:
> On Sat, Jun 22, 2013 at 12:07 AM, Davidlohr Bueso
>  wrote:
>> On Fri, 2013-06-21 at 21:34 +0200, Sedat Dilek wrote:
>>> On Fri, Jun 21, 2013 at 10:17 AM, Stephen Rothwell  
>>> wrote:
>>> > Hi all,
>>> >
>>> > Happy solstice!
>>> >
>>> > Changes since 20130620:
>>> >
>>> > Dropped tree: mailbox (really bad merge conflicts with the arm-soc tree)
>>> >
>>> > The net-next tree gained a conflict against the net tree.
>>> >
>>> > The leds tree still had its build failure, so I used the version from
>>> > next-20130607.
>>> >
>>> > The arm-soc tree gained conflicts against the tip, net-next, mfd and
>>> > mailbox trees.
>>> >
>>> > The staging tree still had its build failure for which I disabled some
>>> > code.
>>> >
>>> > The akpm tree lost a few patches that turned up elsewhere and gained
>>> > conflicts against the ftrace and arm-soc trees.
>>> >
>>> > 
>>> >
>>>
>>> [ CC IPC folks ]
>>>
>>> Building via 'make deb-pkg' with fakeroot fails here like this:
>>>
>>> make: *** [deb-pkg] Terminated
>>> /usr/bin/fakeroot: line 181:  2386 Terminated
>>> FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB"
>>> "$@"
>>> semop(1): encountered an error: Identifier removed
>>> semop(2): encountered an error: Invalid argument
>>> semop(1): encountered an error: Identifier removed
>>> semop(1): encountered an error: Identifier removed
>>> semop(1): encountered an error: Invalid argument
>>> semop(1): encountered an error: Invalid argument
>>> semop(1): encountered an error: Invalid argument
>>>
>>
>> Hmmm those really shouldn't be related to the message queue changes. Are
>> you sure you got the right bisect?
>>
>> Manfred has a few ipc/sem.c patches in linux-next, starting at commit
>> c50df1b4 (ipc/sem.c: cacheline align the semaphore structures), does
>> reverting any of those instead of "ipc,msg: shorten critical region in
>> msgrcv" help at all? Also, anything reported in dmesg?
>>
>
> First, I reverted all IPC patches from akpm-tree within -next.
> Then, I isolated the culprit by git-bisecting.
> As I checked my logs I did not see anything helpful.
>
>>> The issue is present since next-20130606!
>>>
>>> LAST KNOWN GOOD: next-20130605
>>> FIRST KNOWN BAD: next-20130606
>>>
>>> KNOWN GOOD: next-20130604
>>> KNOWN BAD:  next-20130607 || next-20130619 || next-20130620 || next-20130621
>>>
>>> git-bisect says CULPRIT commit is...
>>>
>>>  "ipc,msg: shorten critical region in msgrcv"
>>
>> This I get. I went through the code again and it looks correct and
>> functionally equivalent to the old msgrcv.
>>
>
> Hmm, I guess a rcu_read_unlock() is missing?
>
> [ next-20130605 ]
> ...
> /* Lockless receive, part 3:
>  * Acquire the queue spinlock.
>  */
> ipc_lock_by_ptr(>q_perm);
> rcu_read_unlock();
> ...
> [ next-20130621 ]
> ...
> /* Lockless receive, part 3:
>  * Acquire the queue spinlock.
>  */
> ipc_lock_object(>q_perm);
> ...
>
> Whereas ipc_lock_by_ptr() is equivalent to:
> rcu_read_lock();
> ipc_lock_object();
>
>>>
>>> NOTE: msg_lock_(check_) routines have to be restored (one more revert 
>>> needed)!
>>
>> This I don't get. Restoring msg_lock_[check] is already equivalent to
>> reverting "ipc,msg: shorten critical region in msgrcv" and several other
>> of the msq patches. What other patch needs reverted?
>>
>
> No, you have to revert both patches as the other removed
> msg_lock_[check] afterwards.
>
>> Anyway, I'll see if I can reproduce the issue, maybe I'm missing
>> something.
>>
>
> Yupp, I try with adding rcu_read_unlock()... and report.
>
> - Sedat -
>
>> Thanks,
>> Davidlohr
>>
>>>
>>> Reverting both (below) commits makes fakeroot build via 'make dep-pkg" 
>>> again.
>>>
>>> I have tested the revert-patches with next-20130606 and next-20130621
>>> (see file-attachments).
>>>
>>> My build-script is attached!
>>>
>>> Can someone of the IPC folks look at that?
>>> Thanks!
>>>
>>> - Sedat -
>>>
>>>
>>> P.S.: Commit-IDs listed below.
>>>
>>> [ next-20130606 ]
>>>
>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20130606
>>>
>>> "ipc: remove unused functions"
>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=8793fdfb0d0a6ed5916767e29a15d3eb56e04e79
>>>
>>> "ipc,msg: shorten critical region in msgrcv"
>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=c0ff93322847a54f74a5450032c4df64c17fdaed
>>>
>>> [ next-20130621 ]
>>>
>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20130621
>>>
>>> "ipc: remove unused functions"
>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=941ce57c81dcceadf55265616ee1e8bef18b0ad3
>>>
>>> "ipc,msg: shorten critical region in msgrcv"
>>>

Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ]

On Sat, Jun 22, 2013 at 1:11 AM, Davidlohr Bueso  wrote:
> On Sat, 2013-06-22 at 00:54 +0200, Sedat Dilek wrote:
>> On Sat, Jun 22, 2013 at 12:07 AM, Davidlohr Bueso
>>  wrote:
>> > On Fri, 2013-06-21 at 21:34 +0200, Sedat Dilek wrote:
>> >> On Fri, Jun 21, 2013 at 10:17 AM, Stephen Rothwell 
>> >>  wrote:
>> >> > Hi all,
>> >> >
>> >> > Happy solstice!
>> >> >
>> >> > Changes since 20130620:
>> >> >
>> >> > Dropped tree: mailbox (really bad merge conflicts with the arm-soc tree)
>> >> >
>> >> > The net-next tree gained a conflict against the net tree.
>> >> >
>> >> > The leds tree still had its build failure, so I used the version from
>> >> > next-20130607.
>> >> >
>> >> > The arm-soc tree gained conflicts against the tip, net-next, mfd and
>> >> > mailbox trees.
>> >> >
>> >> > The staging tree still had its build failure for which I disabled some
>> >> > code.
>> >> >
>> >> > The akpm tree lost a few patches that turned up elsewhere and gained
>> >> > conflicts against the ftrace and arm-soc trees.
>> >> >
>> >> > 
>> >> >
>> >>
>> >> [ CC IPC folks ]
>> >>
>> >> Building via 'make deb-pkg' with fakeroot fails here like this:
>> >>
>> >> make: *** [deb-pkg] Terminated
>> >> /usr/bin/fakeroot: line 181:  2386 Terminated
>> >> FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB"
>> >> "$@"
>> >> semop(1): encountered an error: Identifier removed
>> >> semop(2): encountered an error: Invalid argument
>> >> semop(1): encountered an error: Identifier removed
>> >> semop(1): encountered an error: Identifier removed
>> >> semop(1): encountered an error: Invalid argument
>> >> semop(1): encountered an error: Invalid argument
>> >> semop(1): encountered an error: Invalid argument
>> >>
>> >
>> > Hmmm those really shouldn't be related to the message queue changes. Are
>> > you sure you got the right bisect?
>> >
>> > Manfred has a few ipc/sem.c patches in linux-next, starting at commit
>> > c50df1b4 (ipc/sem.c: cacheline align the semaphore structures), does
>> > reverting any of those instead of "ipc,msg: shorten critical region in
>> > msgrcv" help at all? Also, anything reported in dmesg?
>> >
>>
>> First, I reverted all IPC patches from akpm-tree within -next.
>> Then, I isolated the culprit by git-bisecting.
>> As I checked my logs I did not see anything helpful.
>>
>> >> The issue is present since next-20130606!
>> >>
>> >> LAST KNOWN GOOD: next-20130605
>> >> FIRST KNOWN BAD: next-20130606
>> >>
>> >> KNOWN GOOD: next-20130604
>> >> KNOWN BAD:  next-20130607 || next-20130619 || next-20130620 || 
>> >> next-20130621
>> >>
>> >> git-bisect says CULPRIT commit is...
>> >>
>> >>  "ipc,msg: shorten critical region in msgrcv"
>> >
>> > This I get. I went through the code again and it looks correct and
>> > functionally equivalent to the old msgrcv.
>> >
>>
>> Hmm, I guess a rcu_read_unlock() is missing?
>>
>> [ next-20130605 ]
>> ...
>>   /* Lockless receive, part 3:
>>* Acquire the queue spinlock.
>>*/
>>   ipc_lock_by_ptr(>q_perm);
>>   rcu_read_unlock();
>> ...
>> [ next-20130621 ]
>> ...
>>   /* Lockless receive, part 3:
>>* Acquire the queue spinlock.
>>*/
>>   ipc_lock_object(>q_perm);
>> ...
>>
>> Whereas ipc_lock_by_ptr() is equivalent to:
>> rcu_read_lock();
>> ipc_lock_object();
>
> Yeah, I noticed that, but it's not an error. In the older code we have
>
> rcu_read_lock (Lockless receive, part 1)
> [...]
> /* Lockless receive, part 3:
>  * Acquire the queue spinlock.
>  */
> ipc_lock_by_ptr(>q_perm);
> rcu_read_unlock();
>
>
> Which translates to:
> rcu_read_lock (Lockless receive, part 1)
> [...]
> /* Lockless receive, part 3:
>  * Acquire the queue spinlock.
>  */
> rcu_read_lock();
> ipc_lock_object();
> rcu_read_unlock();
>
> And thus, after that last rcu_read_unlock we are left with
> rcu_read_lock()
> ipc_lock_object();
>
> If you notice, that's exactly what is done in the new code, only much
> more readable: We do rcu_read_lock in the part 1, then in part 3, we
> acquire the spinlock via ipc_lock_object(>q_perm)
>

OK.

AFAICS some comments has to be refreshed.

/* Lockless receive, part 1:
 * Disable preemption.  We don't hold a reference to the queue
 * and getting a reference would defeat the idea of a lockless
 * operation, thus the code relies on rcu to guarantee the
 * existence of msq:
 * Prior to destruction, expunge_all(-EIRDM) changes r_msg.
 * Thus if r_msg is -EAGAIN, then the queue not yet destroyed.
 * rcu_read_lock() prevents preemption between reading r_msg
 * and the spin_lock() inside ipc_lock_by_ptr().

...as there is no usage of ipc_lock_by_ptr().

NO success with that:

--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -983,6

Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ]

On Sat, 2013-06-22 at 00:54 +0200, Sedat Dilek wrote:
> On Sat, Jun 22, 2013 at 12:07 AM, Davidlohr Bueso
>  wrote:
> > On Fri, 2013-06-21 at 21:34 +0200, Sedat Dilek wrote:
> >> On Fri, Jun 21, 2013 at 10:17 AM, Stephen Rothwell  
> >> wrote:
> >> > Hi all,
> >> >
> >> > Happy solstice!
> >> >
> >> > Changes since 20130620:
> >> >
> >> > Dropped tree: mailbox (really bad merge conflicts with the arm-soc tree)
> >> >
> >> > The net-next tree gained a conflict against the net tree.
> >> >
> >> > The leds tree still had its build failure, so I used the version from
> >> > next-20130607.
> >> >
> >> > The arm-soc tree gained conflicts against the tip, net-next, mfd and
> >> > mailbox trees.
> >> >
> >> > The staging tree still had its build failure for which I disabled some
> >> > code.
> >> >
> >> > The akpm tree lost a few patches that turned up elsewhere and gained
> >> > conflicts against the ftrace and arm-soc trees.
> >> >
> >> > 
> >> >
> >>
> >> [ CC IPC folks ]
> >>
> >> Building via 'make deb-pkg' with fakeroot fails here like this:
> >>
> >> make: *** [deb-pkg] Terminated
> >> /usr/bin/fakeroot: line 181:  2386 Terminated
> >> FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB"
> >> "$@"
> >> semop(1): encountered an error: Identifier removed
> >> semop(2): encountered an error: Invalid argument
> >> semop(1): encountered an error: Identifier removed
> >> semop(1): encountered an error: Identifier removed
> >> semop(1): encountered an error: Invalid argument
> >> semop(1): encountered an error: Invalid argument
> >> semop(1): encountered an error: Invalid argument
> >>
> >
> > Hmmm those really shouldn't be related to the message queue changes. Are
> > you sure you got the right bisect?
> >
> > Manfred has a few ipc/sem.c patches in linux-next, starting at commit
> > c50df1b4 (ipc/sem.c: cacheline align the semaphore structures), does
> > reverting any of those instead of "ipc,msg: shorten critical region in
> > msgrcv" help at all? Also, anything reported in dmesg?
> >
> 
> First, I reverted all IPC patches from akpm-tree within -next.
> Then, I isolated the culprit by git-bisecting.
> As I checked my logs I did not see anything helpful.
> 
> >> The issue is present since next-20130606!
> >>
> >> LAST KNOWN GOOD: next-20130605
> >> FIRST KNOWN BAD: next-20130606
> >>
> >> KNOWN GOOD: next-20130604
> >> KNOWN BAD:  next-20130607 || next-20130619 || next-20130620 || 
> >> next-20130621
> >>
> >> git-bisect says CULPRIT commit is...
> >>
> >>  "ipc,msg: shorten critical region in msgrcv"
> >
> > This I get. I went through the code again and it looks correct and
> > functionally equivalent to the old msgrcv.
> >
> 
> Hmm, I guess a rcu_read_unlock() is missing?
> 
> [ next-20130605 ]
> ...
>   /* Lockless receive, part 3:
>* Acquire the queue spinlock.
>*/
>   ipc_lock_by_ptr(>q_perm);
>   rcu_read_unlock();
> ...
> [ next-20130621 ]
> ...
>   /* Lockless receive, part 3:
>* Acquire the queue spinlock.
>*/
>   ipc_lock_object(>q_perm);
> ...
> 
> Whereas ipc_lock_by_ptr() is equivalent to:
> rcu_read_lock();
> ipc_lock_object();

Yeah, I noticed that, but it's not an error. In the older code we have

rcu_read_lock (Lockless receive, part 1)
[...]
/* Lockless receive, part 3:
 * Acquire the queue spinlock.
 */
ipc_lock_by_ptr(>q_perm);
rcu_read_unlock();


Which translates to:
rcu_read_lock (Lockless receive, part 1)
[...]
/* Lockless receive, part 3:
 * Acquire the queue spinlock.
 */
rcu_read_lock();
ipc_lock_object();
rcu_read_unlock();

And thus, after that last rcu_read_unlock we are left with
rcu_read_lock()
ipc_lock_object();

If you notice, that's exactly what is done in the new code, only much
more readable: We do rcu_read_lock in the part 1, then in part 3, we
acquire the spinlock via ipc_lock_object(>q_perm)


> >>
> >> NOTE: msg_lock_(check_) routines have to be restored (one more revert 
> >> needed)!
> >
> > This I don't get. Restoring msg_lock_[check] is already equivalent to
> > reverting "ipc,msg: shorten critical region in msgrcv" and several other
> > of the msq patches. What other patch needs reverted?
> >
> 
> No, you have to revert both patches as the other removed
> msg_lock_[check] afterwards.
> 
> > Anyway, I'll see if I can reproduce the issue, maybe I'm missing
> > something.
> >
> 
> Yupp, I try with adding rcu_read_unlock()... and report.
> 
> - Sedat -
> 
> > Thanks,
> > Davidlohr
> >
> >>
> >> Reverting both (below) commits makes fakeroot build via 'make dep-pkg" 
> >> again.
> >>
> >> I have tested the revert-patches with next-20130606 and next-20130621
> >> (see file-attachments).
> >>
> >> My build-script is attached!
> >>
> >> Can someone of the IPC folks look at that?
> >> Thanks!
> >>
> >> - Sedat -
> >>
> >>
> >> P.S.: Commit-IDs listed below.
> >>

Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ]

On Sat, Jun 22, 2013 at 12:07 AM, Davidlohr Bueso
 wrote:
> On Fri, 2013-06-21 at 21:34 +0200, Sedat Dilek wrote:
>> On Fri, Jun 21, 2013 at 10:17 AM, Stephen Rothwell  
>> wrote:
>> > Hi all,
>> >
>> > Happy solstice!
>> >
>> > Changes since 20130620:
>> >
>> > Dropped tree: mailbox (really bad merge conflicts with the arm-soc tree)
>> >
>> > The net-next tree gained a conflict against the net tree.
>> >
>> > The leds tree still had its build failure, so I used the version from
>> > next-20130607.
>> >
>> > The arm-soc tree gained conflicts against the tip, net-next, mfd and
>> > mailbox trees.
>> >
>> > The staging tree still had its build failure for which I disabled some
>> > code.
>> >
>> > The akpm tree lost a few patches that turned up elsewhere and gained
>> > conflicts against the ftrace and arm-soc trees.
>> >
>> > 
>> >
>>
>> [ CC IPC folks ]
>>
>> Building via 'make deb-pkg' with fakeroot fails here like this:
>>
>> make: *** [deb-pkg] Terminated
>> /usr/bin/fakeroot: line 181:  2386 Terminated
>> FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB"
>> "$@"
>> semop(1): encountered an error: Identifier removed
>> semop(2): encountered an error: Invalid argument
>> semop(1): encountered an error: Identifier removed
>> semop(1): encountered an error: Identifier removed
>> semop(1): encountered an error: Invalid argument
>> semop(1): encountered an error: Invalid argument
>> semop(1): encountered an error: Invalid argument
>>
>
> Hmmm those really shouldn't be related to the message queue changes. Are
> you sure you got the right bisect?
>
> Manfred has a few ipc/sem.c patches in linux-next, starting at commit
> c50df1b4 (ipc/sem.c: cacheline align the semaphore structures), does
> reverting any of those instead of "ipc,msg: shorten critical region in
> msgrcv" help at all? Also, anything reported in dmesg?
>

First, I reverted all IPC patches from akpm-tree within -next.
Then, I isolated the culprit by git-bisecting.
As I checked my logs I did not see anything helpful.

>> The issue is present since next-20130606!
>>
>> LAST KNOWN GOOD: next-20130605
>> FIRST KNOWN BAD: next-20130606
>>
>> KNOWN GOOD: next-20130604
>> KNOWN BAD:  next-20130607 || next-20130619 || next-20130620 || next-20130621
>>
>> git-bisect says CULPRIT commit is...
>>
>>  "ipc,msg: shorten critical region in msgrcv"
>
> This I get. I went through the code again and it looks correct and
> functionally equivalent to the old msgrcv.
>

Hmm, I guess a rcu_read_unlock() is missing?

[ next-20130605 ]
...
/* Lockless receive, part 3:
 * Acquire the queue spinlock.
 */
ipc_lock_by_ptr(>q_perm);
rcu_read_unlock();
...
[ next-20130621 ]
...
/* Lockless receive, part 3:
 * Acquire the queue spinlock.
 */
ipc_lock_object(>q_perm);
...

Whereas ipc_lock_by_ptr() is equivalent to:
rcu_read_lock();
ipc_lock_object();

>>
>> NOTE: msg_lock_(check_) routines have to be restored (one more revert 
>> needed)!
>
> This I don't get. Restoring msg_lock_[check] is already equivalent to
> reverting "ipc,msg: shorten critical region in msgrcv" and several other
> of the msq patches. What other patch needs reverted?
>

No, you have to revert both patches as the other removed
msg_lock_[check] afterwards.

> Anyway, I'll see if I can reproduce the issue, maybe I'm missing
> something.
>

Yupp, I try with adding rcu_read_unlock()... and report.

- Sedat -

> Thanks,
> Davidlohr
>
>>
>> Reverting both (below) commits makes fakeroot build via 'make dep-pkg" again.
>>
>> I have tested the revert-patches with next-20130606 and next-20130621
>> (see file-attachments).
>>
>> My build-script is attached!
>>
>> Can someone of the IPC folks look at that?
>> Thanks!
>>
>> - Sedat -
>>
>>
>> P.S.: Commit-IDs listed below.
>>
>> [ next-20130606 ]
>>
>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20130606
>>
>> "ipc: remove unused functions"
>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=8793fdfb0d0a6ed5916767e29a15d3eb56e04e79
>>
>> "ipc,msg: shorten critical region in msgrcv"
>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=c0ff93322847a54f74a5450032c4df64c17fdaed
>>
>> [ next-20130621 ]
>>
>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20130621
>>
>> "ipc: remove unused functions"
>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=941ce57c81dcceadf55265616ee1e8bef18b0ad3
>>
>> "ipc,msg: shorten critical region in msgrcv"
>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=62190df4081ee8504e3611d45edb40450cb408ac
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More

Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ]

On Fri, 2013-06-21 at 21:34 +0200, Sedat Dilek wrote:
> On Fri, Jun 21, 2013 at 10:17 AM, Stephen Rothwell  
> wrote:
> > Hi all,
> >
> > Happy solstice!
> >
> > Changes since 20130620:
> >
> > Dropped tree: mailbox (really bad merge conflicts with the arm-soc tree)
> >
> > The net-next tree gained a conflict against the net tree.
> >
> > The leds tree still had its build failure, so I used the version from
> > next-20130607.
> >
> > The arm-soc tree gained conflicts against the tip, net-next, mfd and
> > mailbox trees.
> >
> > The staging tree still had its build failure for which I disabled some
> > code.
> >
> > The akpm tree lost a few patches that turned up elsewhere and gained
> > conflicts against the ftrace and arm-soc trees.
> >
> > 
> >
> 
> [ CC IPC folks ]
> 
> Building via 'make deb-pkg' with fakeroot fails here like this:
> 
> make: *** [deb-pkg] Terminated
> /usr/bin/fakeroot: line 181:  2386 Terminated
> FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB"
> "$@"
> semop(1): encountered an error: Identifier removed
> semop(2): encountered an error: Invalid argument
> semop(1): encountered an error: Identifier removed
> semop(1): encountered an error: Identifier removed
> semop(1): encountered an error: Invalid argument
> semop(1): encountered an error: Invalid argument
> semop(1): encountered an error: Invalid argument
> 

Hmmm those really shouldn't be related to the message queue changes. Are
you sure you got the right bisect? 

Manfred has a few ipc/sem.c patches in linux-next, starting at commit
c50df1b4 (ipc/sem.c: cacheline align the semaphore structures), does
reverting any of those instead of "ipc,msg: shorten critical region in
msgrcv" help at all? Also, anything reported in dmesg?

> The issue is present since next-20130606!
> 
> LAST KNOWN GOOD: next-20130605
> FIRST KNOWN BAD: next-20130606
> 
> KNOWN GOOD: next-20130604
> KNOWN BAD:  next-20130607 || next-20130619 || next-20130620 || next-20130621
> 
> git-bisect says CULPRIT commit is...
> 
>  "ipc,msg: shorten critical region in msgrcv"

This I get. I went through the code again and it looks correct and
functionally equivalent to the old msgrcv.

> 
> NOTE: msg_lock_(check_) routines have to be restored (one more revert needed)!

This I don't get. Restoring msg_lock_[check] is already equivalent to
reverting "ipc,msg: shorten critical region in msgrcv" and several other
of the msq patches. What other patch needs reverted?

Anyway, I'll see if I can reproduce the issue, maybe I'm missing
something.

Thanks,
Davidlohr

> 
> Reverting both (below) commits makes fakeroot build via 'make dep-pkg" again.
> 
> I have tested the revert-patches with next-20130606 and next-20130621
> (see file-attachments).
> 
> My build-script is attached!
> 
> Can someone of the IPC folks look at that?
> Thanks!
> 
> - Sedat -
> 
> 
> P.S.: Commit-IDs listed below.
> 
> [ next-20130606 ]
> 
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20130606
> 
> "ipc: remove unused functions"
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=8793fdfb0d0a6ed5916767e29a15d3eb56e04e79
> 
> "ipc,msg: shorten critical region in msgrcv"
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=c0ff93322847a54f74a5450032c4df64c17fdaed
> 
> [ next-20130621 ]
> 
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20130621
> 
> "ipc: remove unused functions"
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=941ce57c81dcceadf55265616ee1e8bef18b0ad3
> 
> "ipc,msg: shorten critical region in msgrcv"
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=62190df4081ee8504e3611d45edb40450cb408ac


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ]

On Fri, Jun 21, 2013 at 10:17 AM, Stephen Rothwell  
wrote:
> Hi all,
>
> Happy solstice!
>
> Changes since 20130620:
>
> Dropped tree: mailbox (really bad merge conflicts with the arm-soc tree)
>
> The net-next tree gained a conflict against the net tree.
>
> The leds tree still had its build failure, so I used the version from
> next-20130607.
>
> The arm-soc tree gained conflicts against the tip, net-next, mfd and
> mailbox trees.
>
> The staging tree still had its build failure for which I disabled some
> code.
>
> The akpm tree lost a few patches that turned up elsewhere and gained
> conflicts against the ftrace and arm-soc trees.
>
> 
>

[ CC IPC folks ]

Building via 'make deb-pkg' with fakeroot fails here like this:

make: *** [deb-pkg] Terminated
/usr/bin/fakeroot: line 181:  2386 Terminated
FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB"
"$@"
semop(1): encountered an error: Identifier removed
semop(2): encountered an error: Invalid argument
semop(1): encountered an error: Identifier removed
semop(1): encountered an error: Identifier removed
semop(1): encountered an error: Invalid argument
semop(1): encountered an error: Invalid argument
semop(1): encountered an error: Invalid argument

The issue is present since next-20130606!

LAST KNOWN GOOD: next-20130605
FIRST KNOWN BAD: next-20130606

KNOWN GOOD: next-20130604
KNOWN BAD:  next-20130607 || next-20130619 || next-20130620 || next-20130621

git-bisect says CULPRIT commit is...

 "ipc,msg: shorten critical region in msgrcv"

NOTE: msg_lock_(check_) routines have to be restored (one more revert needed)!

Reverting both (below) commits makes fakeroot build via 'make dep-pkg" again.

I have tested the revert-patches with next-20130606 and next-20130621
(see file-attachments).

My build-script is attached!

Can someone of the IPC folks look at that?
Thanks!

- Sedat -


P.S.: Commit-IDs listed below.

[ next-20130606 ]

http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20130606

"ipc: remove unused functions"
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=8793fdfb0d0a6ed5916767e29a15d3eb56e04e79

"ipc,msg: shorten critical region in msgrcv"
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=c0ff93322847a54f74a5450032c4df64c17fdaed

[ next-20130621 ]

http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20130621

"ipc: remove unused functions"
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=941ce57c81dcceadf55265616ee1e8bef18b0ad3

"ipc,msg: shorten critical region in msgrcv"
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=62190df4081ee8504e3611d45edb40450cb408ac


build_linux-next.sh
Description: Bourne shell script


3.10.0-rc4-next20130606-3-iniza-small.patch
Description: Binary data


3.10.0-rc6-next20130621-2-iniza-small.patch
Description: Binary data

RE: linux-next: Tree for Jun 21 (infiniband: qib)

2013-06-21 Thread Marciniszyn, Mike

I just submitted  a fix for this.

> -Original Message-
> From: Randy Dunlap [mailto:rdun...@infradead.org]
> Sent: Friday, June 21, 2013 11:30 AM
> To: Stephen Rothwell
> Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; infinipath; 
> linux-
> r...@vger.kernel.org
> Subject: Re: linux-next: Tree for Jun 21 (infiniband: qib)
> 
> On 06/21/13 01:17, Stephen Rothwell wrote:
> > Hi all,
> >
> > Happy solstice!
> >
> > Changes since 20130620:
> >
> 
> 
> on x86_64:
> 
> when CONFIG_SMP is not enabled:
> 
> (from qib.h:)
> 
> #ifdef CONFIG_INFINIBAND_QIB_DCA
> struct qib_irq_notify {
>   int rcv;
>   void *arg;
>   struct irq_affinity_notify notify;
> };
> #endif
> 
> struct irq_affinity_notify is only defined for CONFIG_SMP or
> GENERIC_HARDIRQS.
> Build error happens when one of those is not enabled.
> 
> 
> In file included from drivers/infiniband/hw/qib/qib_cq.c:41:0:
> drivers/infiniband/hw/qib/qib.h:447:29: error: field 'notify' has incomplete 
> type
> make[4]: *** [drivers/infiniband/hw/qib/qib_cq.o] Error 1
> 
> 
> 
> 
> --
> ~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Jun 21 (infiniband: qib)

On 06/21/13 01:17, Stephen Rothwell wrote:
> Hi all,
> 
> Happy solstice!
> 
> Changes since 20130620:
> 


on x86_64:

when CONFIG_SMP is not enabled:

(from qib.h:)

#ifdef CONFIG_INFINIBAND_QIB_DCA
struct qib_irq_notify {
int rcv;
void *arg;
struct irq_affinity_notify notify;
};
#endif

struct irq_affinity_notify is only defined for CONFIG_SMP or GENERIC_HARDIRQS.
Build error happens when one of those is not enabled.


In file included from drivers/infiniband/hw/qib/qib_cq.c:41:0:
drivers/infiniband/hw/qib/qib.h:447:29: error: field 'notify' has incomplete 
type
make[4]: *** [drivers/infiniband/hw/qib/qib_cq.o] Error 1




-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Jun 21 (netdev: openvswitch)

On 06/21/13 01:17, Stephen Rothwell wrote:
> Hi all,
> 
> Happy solstice!
> 
> Changes since 20130620:
> 

when CONFIG_INET is not enabled:

  CC  net/openvswitch/flow.o
In file included from net/openvswitch/flow.c:43:0:
include/net/ip_tunnels.h: In function 'tunnel_ip_select_ident':
include/net/ip_tunnels.h:155:3: error: implicit declaration of function 
'__ip_select_ident' [-Werror=implicit-function-declaration]



-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Jun 21 (netdev: openvswitch)

On 06/21/13 01:17, Stephen Rothwell wrote:
 Hi all,
 
 Happy solstice!
 
 Changes since 20130620:
 

when CONFIG_INET is not enabled:

  CC  net/openvswitch/flow.o
In file included from net/openvswitch/flow.c:43:0:
include/net/ip_tunnels.h: In function 'tunnel_ip_select_ident':
include/net/ip_tunnels.h:155:3: error: implicit declaration of function 
'__ip_select_ident' [-Werror=implicit-function-declaration]



-- 
~Randy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: linux-next: Tree for Jun 21 (infiniband: qib)

2013-06-21 Thread Marciniszyn, Mike

I just submitted  a fix for this.

 -Original Message-
 From: Randy Dunlap [mailto:rdun...@infradead.org]
 Sent: Friday, June 21, 2013 11:30 AM
 To: Stephen Rothwell
 Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; infinipath; 
 linux-
 r...@vger.kernel.org
 Subject: Re: linux-next: Tree for Jun 21 (infiniband: qib)
 
 On 06/21/13 01:17, Stephen Rothwell wrote:
  Hi all,
 
  Happy solstice!
 
  Changes since 20130620:
 
 
 
 on x86_64:
 
 when CONFIG_SMP is not enabled:
 
 (from qib.h:)
 
 #ifdef CONFIG_INFINIBAND_QIB_DCA
 struct qib_irq_notify {
   int rcv;
   void *arg;
   struct irq_affinity_notify notify;
 };
 #endif
 
 struct irq_affinity_notify is only defined for CONFIG_SMP or
 GENERIC_HARDIRQS.
 Build error happens when one of those is not enabled.
 
 
 In file included from drivers/infiniband/hw/qib/qib_cq.c:41:0:
 drivers/infiniband/hw/qib/qib.h:447:29: error: field 'notify' has incomplete 
 type
 make[4]: *** [drivers/infiniband/hw/qib/qib_cq.o] Error 1
 
 
 
 
 --
 ~Randy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Jun 21 (infiniband: qib)

On 06/21/13 01:17, Stephen Rothwell wrote:
 Hi all,
 
 Happy solstice!
 
 Changes since 20130620:
 


on x86_64:

when CONFIG_SMP is not enabled:

(from qib.h:)

#ifdef CONFIG_INFINIBAND_QIB_DCA
struct qib_irq_notify {
int rcv;
void *arg;
struct irq_affinity_notify notify;
};
#endif

struct irq_affinity_notify is only defined for CONFIG_SMP or GENERIC_HARDIRQS.
Build error happens when one of those is not enabled.


In file included from drivers/infiniband/hw/qib/qib_cq.c:41:0:
drivers/infiniband/hw/qib/qib.h:447:29: error: field 'notify' has incomplete 
type
make[4]: *** [drivers/infiniband/hw/qib/qib_cq.o] Error 1




-- 
~Randy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ]

On Fri, Jun 21, 2013 at 10:17 AM, Stephen Rothwell s...@canb.auug.org.au 
wrote:
 Hi all,

 Happy solstice!

 Changes since 20130620:

 Dropped tree: mailbox (really bad merge conflicts with the arm-soc tree)

 The net-next tree gained a conflict against the net tree.

 The leds tree still had its build failure, so I used the version from
 next-20130607.

 The arm-soc tree gained conflicts against the tip, net-next, mfd and
 mailbox trees.

 The staging tree still had its build failure for which I disabled some
 code.

 The akpm tree lost a few patches that turned up elsewhere and gained
 conflicts against the ftrace and arm-soc trees.

 


[ CC IPC folks ]

Building via 'make deb-pkg' with fakeroot fails here like this:

make: *** [deb-pkg] Terminated
/usr/bin/fakeroot: line 181:  2386 Terminated
FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH=$PATHS LD_PRELOAD=$LIB
$@
semop(1): encountered an error: Identifier removed
semop(2): encountered an error: Invalid argument
semop(1): encountered an error: Identifier removed
semop(1): encountered an error: Identifier removed
semop(1): encountered an error: Invalid argument
semop(1): encountered an error: Invalid argument
semop(1): encountered an error: Invalid argument

The issue is present since next-20130606!

LAST KNOWN GOOD: next-20130605
FIRST KNOWN BAD: next-20130606

KNOWN GOOD: next-20130604
KNOWN BAD:  next-20130607 || next-20130619 || next-20130620 || next-20130621

git-bisect says CULPRIT commit is...

 ipc,msg: shorten critical region in msgrcv

NOTE: msg_lock_(check_) routines have to be restored (one more revert needed)!

Reverting both (below) commits makes fakeroot build via 'make dep-pkg again.

I have tested the revert-patches with next-20130606 and next-20130621
(see file-attachments).

My build-script is attached!

Can someone of the IPC folks look at that?
Thanks!

- Sedat -


P.S.: Commit-IDs listed below.

[ next-20130606 ]

http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20130606

ipc: remove unused functions
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=8793fdfb0d0a6ed5916767e29a15d3eb56e04e79

ipc,msg: shorten critical region in msgrcv
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=c0ff93322847a54f74a5450032c4df64c17fdaed

[ next-20130621 ]

http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20130621

ipc: remove unused functions
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=941ce57c81dcceadf55265616ee1e8bef18b0ad3

ipc,msg: shorten critical region in msgrcv
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=62190df4081ee8504e3611d45edb40450cb408ac


build_linux-next.sh
Description: Bourne shell script


3.10.0-rc4-next20130606-3-iniza-small.patch
Description: Binary data


3.10.0-rc6-next20130621-2-iniza-small.patch
Description: Binary data

Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ]

On Fri, 2013-06-21 at 21:34 +0200, Sedat Dilek wrote:
 On Fri, Jun 21, 2013 at 10:17 AM, Stephen Rothwell s...@canb.auug.org.au 
 wrote:
  Hi all,
 
  Happy solstice!
 
  Changes since 20130620:
 
  Dropped tree: mailbox (really bad merge conflicts with the arm-soc tree)
 
  The net-next tree gained a conflict against the net tree.
 
  The leds tree still had its build failure, so I used the version from
  next-20130607.
 
  The arm-soc tree gained conflicts against the tip, net-next, mfd and
  mailbox trees.
 
  The staging tree still had its build failure for which I disabled some
  code.
 
  The akpm tree lost a few patches that turned up elsewhere and gained
  conflicts against the ftrace and arm-soc trees.
 
  
 
 
 [ CC IPC folks ]
 
 Building via 'make deb-pkg' with fakeroot fails here like this:
 
 make: *** [deb-pkg] Terminated
 /usr/bin/fakeroot: line 181:  2386 Terminated
 FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH=$PATHS LD_PRELOAD=$LIB
 $@
 semop(1): encountered an error: Identifier removed
 semop(2): encountered an error: Invalid argument
 semop(1): encountered an error: Identifier removed
 semop(1): encountered an error: Identifier removed
 semop(1): encountered an error: Invalid argument
 semop(1): encountered an error: Invalid argument
 semop(1): encountered an error: Invalid argument
 

Hmmm those really shouldn't be related to the message queue changes. Are
you sure you got the right bisect? 

Manfred has a few ipc/sem.c patches in linux-next, starting at commit
c50df1b4 (ipc/sem.c: cacheline align the semaphore structures), does
reverting any of those instead of ipc,msg: shorten critical region in
msgrcv help at all? Also, anything reported in dmesg?

 The issue is present since next-20130606!
 
 LAST KNOWN GOOD: next-20130605
 FIRST KNOWN BAD: next-20130606
 
 KNOWN GOOD: next-20130604
 KNOWN BAD:  next-20130607 || next-20130619 || next-20130620 || next-20130621
 
 git-bisect says CULPRIT commit is...
 
  ipc,msg: shorten critical region in msgrcv

This I get. I went through the code again and it looks correct and
functionally equivalent to the old msgrcv.

 
 NOTE: msg_lock_(check_) routines have to be restored (one more revert needed)!

This I don't get. Restoring msg_lock_[check] is already equivalent to
reverting ipc,msg: shorten critical region in msgrcv and several other
of the msq patches. What other patch needs reverted?

Anyway, I'll see if I can reproduce the issue, maybe I'm missing
something.

Thanks,
Davidlohr

 
 Reverting both (below) commits makes fakeroot build via 'make dep-pkg again.
 
 I have tested the revert-patches with next-20130606 and next-20130621
 (see file-attachments).
 
 My build-script is attached!
 
 Can someone of the IPC folks look at that?
 Thanks!
 
 - Sedat -
 
 
 P.S.: Commit-IDs listed below.
 
 [ next-20130606 ]
 
 http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20130606
 
 ipc: remove unused functions
 http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=8793fdfb0d0a6ed5916767e29a15d3eb56e04e79
 
 ipc,msg: shorten critical region in msgrcv
 http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=c0ff93322847a54f74a5450032c4df64c17fdaed
 
 [ next-20130621 ]
 
 http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20130621
 
 ipc: remove unused functions
 http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=941ce57c81dcceadf55265616ee1e8bef18b0ad3
 
 ipc,msg: shorten critical region in msgrcv
 http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=62190df4081ee8504e3611d45edb40450cb408ac


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ]

On Sat, Jun 22, 2013 at 12:07 AM, Davidlohr Bueso
davidlohr.bu...@hp.com wrote:
 On Fri, 2013-06-21 at 21:34 +0200, Sedat Dilek wrote:
 On Fri, Jun 21, 2013 at 10:17 AM, Stephen Rothwell s...@canb.auug.org.au 
 wrote:
  Hi all,
 
  Happy solstice!
 
  Changes since 20130620:
 
  Dropped tree: mailbox (really bad merge conflicts with the arm-soc tree)
 
  The net-next tree gained a conflict against the net tree.
 
  The leds tree still had its build failure, so I used the version from
  next-20130607.
 
  The arm-soc tree gained conflicts against the tip, net-next, mfd and
  mailbox trees.
 
  The staging tree still had its build failure for which I disabled some
  code.
 
  The akpm tree lost a few patches that turned up elsewhere and gained
  conflicts against the ftrace and arm-soc trees.
 
  
 

 [ CC IPC folks ]

 Building via 'make deb-pkg' with fakeroot fails here like this:

 make: *** [deb-pkg] Terminated
 /usr/bin/fakeroot: line 181:  2386 Terminated
 FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH=$PATHS LD_PRELOAD=$LIB
 $@
 semop(1): encountered an error: Identifier removed
 semop(2): encountered an error: Invalid argument
 semop(1): encountered an error: Identifier removed
 semop(1): encountered an error: Identifier removed
 semop(1): encountered an error: Invalid argument
 semop(1): encountered an error: Invalid argument
 semop(1): encountered an error: Invalid argument


 Hmmm those really shouldn't be related to the message queue changes. Are
 you sure you got the right bisect?

 Manfred has a few ipc/sem.c patches in linux-next, starting at commit
 c50df1b4 (ipc/sem.c: cacheline align the semaphore structures), does
 reverting any of those instead of ipc,msg: shorten critical region in
 msgrcv help at all? Also, anything reported in dmesg?


First, I reverted all IPC patches from akpm-tree within -next.
Then, I isolated the culprit by git-bisecting.
As I checked my logs I did not see anything helpful.

 The issue is present since next-20130606!

 LAST KNOWN GOOD: next-20130605
 FIRST KNOWN BAD: next-20130606

 KNOWN GOOD: next-20130604
 KNOWN BAD:  next-20130607 || next-20130619 || next-20130620 || next-20130621

 git-bisect says CULPRIT commit is...

  ipc,msg: shorten critical region in msgrcv

 This I get. I went through the code again and it looks correct and
 functionally equivalent to the old msgrcv.


Hmm, I guess a rcu_read_unlock() is missing?

[ next-20130605 ]
...
/* Lockless receive, part 3:
 * Acquire the queue spinlock.
 */
ipc_lock_by_ptr(msq-q_perm);
rcu_read_unlock();
...
[ next-20130621 ]
...
/* Lockless receive, part 3:
 * Acquire the queue spinlock.
 */
ipc_lock_object(msq-q_perm);
...

Whereas ipc_lock_by_ptr() is equivalent to:
rcu_read_lock();
ipc_lock_object();


 NOTE: msg_lock_(check_) routines have to be restored (one more revert 
 needed)!

 This I don't get. Restoring msg_lock_[check] is already equivalent to
 reverting ipc,msg: shorten critical region in msgrcv and several other
 of the msq patches. What other patch needs reverted?


No, you have to revert both patches as the other removed
msg_lock_[check] afterwards.

 Anyway, I'll see if I can reproduce the issue, maybe I'm missing
 something.


Yupp, I try with adding rcu_read_unlock()... and report.

- Sedat -

 Thanks,
 Davidlohr


 Reverting both (below) commits makes fakeroot build via 'make dep-pkg again.

 I have tested the revert-patches with next-20130606 and next-20130621
 (see file-attachments).

 My build-script is attached!

 Can someone of the IPC folks look at that?
 Thanks!

 - Sedat -


 P.S.: Commit-IDs listed below.

 [ next-20130606 ]

 http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20130606

 ipc: remove unused functions
 http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=8793fdfb0d0a6ed5916767e29a15d3eb56e04e79

 ipc,msg: shorten critical region in msgrcv
 http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=c0ff93322847a54f74a5450032c4df64c17fdaed

 [ next-20130621 ]

 http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20130621

 ipc: remove unused functions
 http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=941ce57c81dcceadf55265616ee1e8bef18b0ad3

 ipc,msg: shorten critical region in msgrcv
 http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=62190df4081ee8504e3611d45edb40450cb408ac


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ]

On Sat, 2013-06-22 at 00:54 +0200, Sedat Dilek wrote:
 On Sat, Jun 22, 2013 at 12:07 AM, Davidlohr Bueso
 davidlohr.bu...@hp.com wrote:
  On Fri, 2013-06-21 at 21:34 +0200, Sedat Dilek wrote:
  On Fri, Jun 21, 2013 at 10:17 AM, Stephen Rothwell s...@canb.auug.org.au 
  wrote:
   Hi all,
  
   Happy solstice!
  
   Changes since 20130620:
  
   Dropped tree: mailbox (really bad merge conflicts with the arm-soc tree)
  
   The net-next tree gained a conflict against the net tree.
  
   The leds tree still had its build failure, so I used the version from
   next-20130607.
  
   The arm-soc tree gained conflicts against the tip, net-next, mfd and
   mailbox trees.
  
   The staging tree still had its build failure for which I disabled some
   code.
  
   The akpm tree lost a few patches that turned up elsewhere and gained
   conflicts against the ftrace and arm-soc trees.
  
   
  
 
  [ CC IPC folks ]
 
  Building via 'make deb-pkg' with fakeroot fails here like this:
 
  make: *** [deb-pkg] Terminated
  /usr/bin/fakeroot: line 181:  2386 Terminated
  FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH=$PATHS LD_PRELOAD=$LIB
  $@
  semop(1): encountered an error: Identifier removed
  semop(2): encountered an error: Invalid argument
  semop(1): encountered an error: Identifier removed
  semop(1): encountered an error: Identifier removed
  semop(1): encountered an error: Invalid argument
  semop(1): encountered an error: Invalid argument
  semop(1): encountered an error: Invalid argument
 
 
  Hmmm those really shouldn't be related to the message queue changes. Are
  you sure you got the right bisect?
 
  Manfred has a few ipc/sem.c patches in linux-next, starting at commit
  c50df1b4 (ipc/sem.c: cacheline align the semaphore structures), does
  reverting any of those instead of ipc,msg: shorten critical region in
  msgrcv help at all? Also, anything reported in dmesg?
 
 
 First, I reverted all IPC patches from akpm-tree within -next.
 Then, I isolated the culprit by git-bisecting.
 As I checked my logs I did not see anything helpful.
 
  The issue is present since next-20130606!
 
  LAST KNOWN GOOD: next-20130605
  FIRST KNOWN BAD: next-20130606
 
  KNOWN GOOD: next-20130604
  KNOWN BAD:  next-20130607 || next-20130619 || next-20130620 || 
  next-20130621
 
  git-bisect says CULPRIT commit is...
 
   ipc,msg: shorten critical region in msgrcv
 
  This I get. I went through the code again and it looks correct and
  functionally equivalent to the old msgrcv.
 
 
 Hmm, I guess a rcu_read_unlock() is missing?
 
 [ next-20130605 ]
 ...
   /* Lockless receive, part 3:
* Acquire the queue spinlock.
*/
   ipc_lock_by_ptr(msq-q_perm);
   rcu_read_unlock();
 ...
 [ next-20130621 ]
 ...
   /* Lockless receive, part 3:
* Acquire the queue spinlock.
*/
   ipc_lock_object(msq-q_perm);
 ...
 
 Whereas ipc_lock_by_ptr() is equivalent to:
 rcu_read_lock();
 ipc_lock_object();

Yeah, I noticed that, but it's not an error. In the older code we have

rcu_read_lock (Lockless receive, part 1)
[...]
/* Lockless receive, part 3:
 * Acquire the queue spinlock.
 */
ipc_lock_by_ptr(msq-q_perm);
rcu_read_unlock();


Which translates to:
rcu_read_lock (Lockless receive, part 1)
[...]
/* Lockless receive, part 3:
 * Acquire the queue spinlock.
 */
rcu_read_lock();
ipc_lock_object();
rcu_read_unlock();

And thus, after that last rcu_read_unlock we are left with
rcu_read_lock()
ipc_lock_object();

If you notice, that's exactly what is done in the new code, only much
more readable: We do rcu_read_lock in the part 1, then in part 3, we
acquire the spinlock via ipc_lock_object(msq-q_perm)


 
  NOTE: msg_lock_(check_) routines have to be restored (one more revert 
  needed)!
 
  This I don't get. Restoring msg_lock_[check] is already equivalent to
  reverting ipc,msg: shorten critical region in msgrcv and several other
  of the msq patches. What other patch needs reverted?
 
 
 No, you have to revert both patches as the other removed
 msg_lock_[check] afterwards.
 
  Anyway, I'll see if I can reproduce the issue, maybe I'm missing
  something.
 
 
 Yupp, I try with adding rcu_read_unlock()... and report.
 
 - Sedat -
 
  Thanks,
  Davidlohr
 
 
  Reverting both (below) commits makes fakeroot build via 'make dep-pkg 
  again.
 
  I have tested the revert-patches with next-20130606 and next-20130621
  (see file-attachments).
 
  My build-script is attached!
 
  Can someone of the IPC folks look at that?
  Thanks!
 
  - Sedat -
 
 
  P.S.: Commit-IDs listed below.
 
  [ next-20130606 ]
 
  http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20130606
 
  ipc: remove unused functions
  http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=8793fdfb0d0a6ed5916767e29a15d3eb56e04e79
 
  ipc,msg: shorten critical

Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ]

On Sat, Jun 22, 2013 at 1:11 AM, Davidlohr Bueso davidlohr.bu...@hp.com wrote:
 On Sat, 2013-06-22 at 00:54 +0200, Sedat Dilek wrote:
 On Sat, Jun 22, 2013 at 12:07 AM, Davidlohr Bueso
 davidlohr.bu...@hp.com wrote:
  On Fri, 2013-06-21 at 21:34 +0200, Sedat Dilek wrote:
  On Fri, Jun 21, 2013 at 10:17 AM, Stephen Rothwell 
  s...@canb.auug.org.au wrote:
   Hi all,
  
   Happy solstice!
  
   Changes since 20130620:
  
   Dropped tree: mailbox (really bad merge conflicts with the arm-soc tree)
  
   The net-next tree gained a conflict against the net tree.
  
   The leds tree still had its build failure, so I used the version from
   next-20130607.
  
   The arm-soc tree gained conflicts against the tip, net-next, mfd and
   mailbox trees.
  
   The staging tree still had its build failure for which I disabled some
   code.
  
   The akpm tree lost a few patches that turned up elsewhere and gained
   conflicts against the ftrace and arm-soc trees.
  
   
  
 
  [ CC IPC folks ]
 
  Building via 'make deb-pkg' with fakeroot fails here like this:
 
  make: *** [deb-pkg] Terminated
  /usr/bin/fakeroot: line 181:  2386 Terminated
  FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH=$PATHS LD_PRELOAD=$LIB
  $@
  semop(1): encountered an error: Identifier removed
  semop(2): encountered an error: Invalid argument
  semop(1): encountered an error: Identifier removed
  semop(1): encountered an error: Identifier removed
  semop(1): encountered an error: Invalid argument
  semop(1): encountered an error: Invalid argument
  semop(1): encountered an error: Invalid argument
 
 
  Hmmm those really shouldn't be related to the message queue changes. Are
  you sure you got the right bisect?
 
  Manfred has a few ipc/sem.c patches in linux-next, starting at commit
  c50df1b4 (ipc/sem.c: cacheline align the semaphore structures), does
  reverting any of those instead of ipc,msg: shorten critical region in
  msgrcv help at all? Also, anything reported in dmesg?
 

 First, I reverted all IPC patches from akpm-tree within -next.
 Then, I isolated the culprit by git-bisecting.
 As I checked my logs I did not see anything helpful.

  The issue is present since next-20130606!
 
  LAST KNOWN GOOD: next-20130605
  FIRST KNOWN BAD: next-20130606
 
  KNOWN GOOD: next-20130604
  KNOWN BAD:  next-20130607 || next-20130619 || next-20130620 || 
  next-20130621
 
  git-bisect says CULPRIT commit is...
 
   ipc,msg: shorten critical region in msgrcv
 
  This I get. I went through the code again and it looks correct and
  functionally equivalent to the old msgrcv.
 

 Hmm, I guess a rcu_read_unlock() is missing?

 [ next-20130605 ]
 ...
   /* Lockless receive, part 3:
* Acquire the queue spinlock.
*/
   ipc_lock_by_ptr(msq-q_perm);
   rcu_read_unlock();
 ...
 [ next-20130621 ]
 ...
   /* Lockless receive, part 3:
* Acquire the queue spinlock.
*/
   ipc_lock_object(msq-q_perm);
 ...

 Whereas ipc_lock_by_ptr() is equivalent to:
 rcu_read_lock();
 ipc_lock_object();

 Yeah, I noticed that, but it's not an error. In the older code we have

 rcu_read_lock (Lockless receive, part 1)
 [...]
 /* Lockless receive, part 3:
  * Acquire the queue spinlock.
  */
 ipc_lock_by_ptr(msq-q_perm);
 rcu_read_unlock();


 Which translates to:
 rcu_read_lock (Lockless receive, part 1)
 [...]
 /* Lockless receive, part 3:
  * Acquire the queue spinlock.
  */
 rcu_read_lock();
 ipc_lock_object();
 rcu_read_unlock();

 And thus, after that last rcu_read_unlock we are left with
 rcu_read_lock()
 ipc_lock_object();

 If you notice, that's exactly what is done in the new code, only much
 more readable: We do rcu_read_lock in the part 1, then in part 3, we
 acquire the spinlock via ipc_lock_object(msq-q_perm)


OK.

AFAICS some comments has to be refreshed.

/* Lockless receive, part 1:
 * Disable preemption.  We don't hold a reference to the queue
 * and getting a reference would defeat the idea of a lockless
 * operation, thus the code relies on rcu to guarantee the
 * existence of msq:
 * Prior to destruction, expunge_all(-EIRDM) changes r_msg.
 * Thus if r_msg is -EAGAIN, then the queue not yet destroyed.
 * rcu_read_lock() prevents preemption between reading r_msg
 * and the spin_lock() inside ipc_lock_by_ptr().

...as there is no usage of ipc_lock_by_ptr().

NO success with that:

--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -983,6 +983,7 @@ long do_msgrcv(int msqid, void __user *buf, size_t
bufsz, long msgtyp, int msgfl
 * Acquire the queue spinlock.
 */
ipc_lock_object(msq-q_perm);
+   rcu_read_unlock();

/* Lockless receive, part 4:
 * Repeat

Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ]