[PATCH] crypto/caam/jr.c: include linux/of_address.h

2013-11-25 Thread shh.xie
From: Shaohui Xie to avoid a compile error: drivers/crypto/caam/jr.c: In function 'caam_jr_probe': drivers/crypto/caam/jr.c:468:2: error: implicit declaration of function 'of_iomap' [-Werror=implicit-function-declaration] drivers/crypto/caam/jr.c:468:7: warning: assignment makes pointer from int

Re: [PATCH] update consumers of MSG_MORE to recognize MSG_SENDPAGE_NOTLAST

2013-11-25 Thread Shawn Landden
On Mon, Nov 25, 2013 at 7:36 AM, Shawn Landden wrote: > Commit 35f9c09fe (tcp: tcp_sendpages() should call tcp_push() once) > added an internal flag MSG_SENDPAGE_NOTLAST, similar to > MSG_MORE. > > algif_hash, algif_skcipher, and udp used MSG_MORE from tcp_sendpages() > and need to see the new fla

Re: [PATCH] pipe_to_sendpage: Ensure that MSG_MORE is set if we set MSG_SENDPAGE_NOTLAST

2013-11-25 Thread Eric Dumazet
On Mon, 2013-11-25 at 08:42 +0100, Richard Weinberger wrote: > In the commit message of your patch you wrote "For all sendpage() providers, > its a transparent change.". Why does AF_ALG need special handling? > If users have to care about MSG_SENDPAGE_NOTLAST it is no longer really an > internal

[PATCH v3] crypto: more robust crypto_memneq

2013-11-25 Thread Cesar Eduardo Barros
Disabling compiler optimizations can be fragile, since a new optimization could be added to -O0 or -Os that breaks the assumptions the code is making. Instead of disabling compiler optimizations, use a dummy inline assembly (based on RELOC_HIDE) to block the problematic kinds of optimization, whil

Re: [PATCH v2] crypto: more robust crypto_memneq

2013-11-25 Thread Daniel Borkmann
On 11/25/2013 11:35 PM, Cesar Eduardo Barros wrote: Disabling compiler optimizations can be fragile, since a new optimization could be added to -O0 or -Os that breaks the assumptions the code is making. Instead of disabling compiler optimizations, use a dummy inline assembly (based on RELOC_HIDE

Re: [PATCH] update consumers of MSG_MORE to recognize MSG_SENDPAGE_NOTLAST

2013-11-25 Thread Richard Weinberger
On Mon, Nov 25, 2013 at 7:36 AM, Shawn Landden wrote: > Commit 35f9c09fe (tcp: tcp_sendpages() should call tcp_push() once) > added an internal flag MSG_SENDPAGE_NOTLAST, similar to > MSG_MORE. > > algif_hash, algif_skcipher, and udp used MSG_MORE from tcp_sendpages() > and need to see the new fla

[PATCH v2] crypto: more robust crypto_memneq

2013-11-25 Thread Cesar Eduardo Barros
Disabling compiler optimizations can be fragile, since a new optimization could be added to -O0 or -Os that breaks the assumptions the code is making. Instead of disabling compiler optimizations, use a dummy inline assembly (based on RELOC_HIDE) to block the problematic kinds of optimization, whil

Re: [PATCH] crypto: more robust crypto_memneq

2013-11-25 Thread Cesar Eduardo Barros
Em 25-11-2013 14:26, Daniel Borkmann escreveu: On 11/25/2013 04:59 PM, James Yonan wrote: This approach using __asm__ ("" : "=r" (var) : "0" (var)) to try to prevent compiler optimizations of var is interesting. I like the fact that it's finer-grained than -Os and doesn't preclude inlining. A

Re: [PATCH] crypto: more robust crypto_memneq

2013-11-25 Thread Cesar Eduardo Barros
Em 25-11-2013 13:59, James Yonan escreveu: On 24/11/2013 14:12, Cesar Eduardo Barros wrote: Disabling compiler optimizations can be fragile, since a new optimization could be added to -O0 or -Os that breaks the assumptions the code is making. Instead of disabling compiler optimizations, use a d

Re: [PATCH] crypto: more robust crypto_memneq

2013-11-25 Thread Daniel Borkmann
On 11/25/2013 04:59 PM, James Yonan wrote: On 24/11/2013 14:12, Cesar Eduardo Barros wrote: Disabling compiler optimizations can be fragile, since a new optimization could be added to -O0 or -Os that breaks the assumptions the code is making. Instead of disabling compiler optimizations, use a d

Re: [PATCH] crypto: more robust crypto_memneq

2013-11-25 Thread James Yonan
On 24/11/2013 14:12, Cesar Eduardo Barros wrote: Disabling compiler optimizations can be fragile, since a new optimization could be added to -O0 or -Os that breaks the assumptions the code is making. Instead of disabling compiler optimizations, use a dummy inline assembly (based on RELOC_HIDE) t

Re: WARNING: CPU: 0 PID: 1 at init/main.c:711 do_one_initcall()

2013-11-25 Thread Richard Weinberger
Am Montag, 25. November 2013, 16:32:19 schrieb Boaz Harrosh: > On 11/25/2013 04:15 PM, Richard Weinberger wrote: > > On Fri, Nov 22, 2013 at 7:02 AM, Yuanhan Liu > > > > wrote: > >> Greetings, > >> > >> I got the below dmesg and the first bad commit is > >> > >> commit 20545536cd8ea949c61527b63

Re: WARNING: CPU: 0 PID: 1 at init/main.c:711 do_one_initcall()

2013-11-25 Thread Boaz Harrosh
On 11/25/2013 04:15 PM, Richard Weinberger wrote: > On Fri, Nov 22, 2013 at 7:02 AM, Yuanhan Liu > wrote: >> Greetings, >> >> I got the below dmesg and the first bad commit is >> >> commit 20545536cd8ea949c61527b6395ec8c0d2c237b1 >> Author: Boaz Harrosh >> Date: Thu Jul 19 15:22:37 2012 +0300 >

Re: WARNING: CPU: 0 PID: 1 at init/main.c:711 do_one_initcall()

2013-11-25 Thread Richard Weinberger
On Fri, Nov 22, 2013 at 7:02 AM, Yuanhan Liu wrote: > Greetings, > > I got the below dmesg and the first bad commit is > > commit 20545536cd8ea949c61527b6395ec8c0d2c237b1 > Author: Boaz Harrosh > Date: Thu Jul 19 15:22:37 2012 +0300 > > RFC: do_xor_speed Broken on UML do to jiffies > >

Re: WARNING: CPU: 0 PID: 1 at init/main.c:711 do_one_initcall()

2013-11-25 Thread Boaz Harrosh
On 11/25/2013 03:25 PM, Yuanhan Liu wrote: > > Hi Boaz, > > We are running an 0day kernel testing system. We will test all developers' > tree we tracked in our system automatically. And obviously, linux-open-osd > is in that list. > > This system can't tell whether a branch is experimental unles

Re: WARNING: CPU: 0 PID: 1 at init/main.c:711 do_one_initcall()

2013-11-25 Thread Yuanhan Liu
On Mon, Nov 25, 2013 at 12:43:42PM +0200, Boaz Harrosh wrote: > On 11/22/2013 08:02 AM, Yuanhan Liu wrote: > > Greetings, > > > > I got the below dmesg and the first bad commit is > > > > commit 20545536cd8ea949c61527b6395ec8c0d2c237b1 > > Author: Boaz Harrosh > > Date: Thu Jul 19 15:22:37 201

Re: WARNING: CPU: 0 PID: 1 at init/main.c:711 do_one_initcall()

2013-11-25 Thread Boaz Harrosh
On 11/22/2013 08:02 AM, Yuanhan Liu wrote: > Greetings, > > I got the below dmesg and the first bad commit is > > commit 20545536cd8ea949c61527b6395ec8c0d2c237b1 > Author: Boaz Harrosh > Date: Thu Jul 19 15:22:37 2012 +0300 > > RFC: do_xor_speed Broken on UML do to jiffies > Hi Sir