[PATCH cryptodev] crypto: memneq: fix for archs without efficient unaligned access

2013-12-05 Thread Daniel Borkmann
Commit fe8c8a126806 introduced a possible build error for archs that do not have CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS set. :/ Fix this up by bringing else braces outside of the ifdef. Reported-by: Fengguang Wu Fixes: fe8c8a126806 ("crypto: more robust crypto_memneq") Cc: Cesar Eduardo Barros S

[PATCH v4] crypto: more robust crypto_memneq

2013-12-05 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

[PATCH] crypto: scatterwalk - Use sg_chain_ptr on chain entries

2013-12-05 Thread Tom Lendacky
Now that scatterwalk_sg_chain sets the chain pointer bit the sg_page call in scatterwalk_sg_next hits a BUG_ON when CONFIG_DEBUG_SG is enabled. Use sg_chain_ptr instead of sg_page on a chain entry. Signed-off-by: Tom Lendacky --- include/crypto/scatterwalk.h |2 +- 1 file changed, 1 insertio

Re: scatterlist.h backtrace from crypto ccm module

2013-12-05 Thread Tom Lendacky
On Thursday, December 05, 2013 09:03:02 AM Josh Boyer wrote: > Hi All, > > We've had a report [1] of the backtrace below on the latest rawhide > kernel, which is essentially Linus' tree as of yesterday. We aren't > carrying any patches to crypto at the moment. It's basically hitting > the secon

Re: [PATCH] crypto: omap-aes: add error check for pm_runtime_get_sync

2013-12-05 Thread Herbert Xu
On Tue, Dec 03, 2013 at 07:43:13PM -0600, Nishanth Menon wrote: > The AES driver currently assumes that pm_runtime_get_sync will always > succeed, which may not always be true, so add error handling for the > same. > > This scenario was reported in the following bug: > place. https://bugzilla.ker

Re: [PATCH v3] crypto: more robust crypto_memneq

2013-12-05 Thread Herbert Xu
On Wed, Nov 27, 2013 at 01:54:15PM +0100, Daniel Borkmann wrote: > On 11/26/2013 10:44 PM, Cesar Eduardo Barros wrote: > >Em 26-11-2013 17:27, Daniel Borkmann escreveu: > >>On 11/26/2013 01:00 AM, Cesar Eduardo Barros wrote: > >>>Compile-tested on x86_64. > >> > >>Actually with yet another version,

Re: [PATCH 0/2] pcrypt/padata rcu fixes

2013-12-05 Thread Herbert Xu
On Mon, Dec 02, 2013 at 01:12:33PM +0100, Steffen Klassert wrote: > On Thu, Nov 28, 2013 at 07:20:03PM +0100, Mathias Krause wrote: > > Two small RCU related fixes, lockdep complained about. > > > > Please apply! > > > > > > Mathias Krause (2): > > crypto: pcrypt - Fix wrong usage of rcu_deref

Re: [PATCH] crypto: omap-sham - Only release DMA channel if successfully requested

2013-12-05 Thread Herbert Xu
On Tue, Nov 12, 2013 at 01:12:27PM -0700, Mark A. Greer wrote: > In omap_sham_probe() and omap_sham_remove(), 'dd->dma_lch' > is released without checking to see if it was successfully > requested or not. This is a bug and was identified and > reported by Dan Carpenter here: > > http://www.

Re: [PATCH] crypto: talitos - fix locating offending descriptor in error path

2013-12-05 Thread Herbert Xu
On Wed, Nov 13, 2013 at 12:20:37PM +0200, Horia Geanta wrote: > Commit 3e721aeb3df3816e283ab18e327cd4652972e213 > ("crypto: talitos - handle descriptor not found in error path") > tried to address the fact that CDPR (Current Descriptor Pointer Register) > is unreliable. > > As it turns out, there

Re: [PATCH 00/10] AMD Cryptographic Coprocessor support

2013-12-05 Thread Herbert Xu
On Tue, Nov 12, 2013 at 11:45:59AM -0600, Tom Lendacky wrote: > Resending because of typo in mailing list address... > > The following series implements support for the AMD Cryptographic > Coprocessor (CCP). The AMD CCP provides hardware encryption, hashing > and other related operations. > > Th

scatterlist.h backtrace from crypto ccm module

2013-12-05 Thread Josh Boyer
Hi All, We've had a report [1] of the backtrace below on the latest rawhide kernel, which is essentially Linus' tree as of yesterday. We aren't carrying any patches to crypto at the moment. It's basically hitting the second BUG_ON in the sg_page function: static inline struct page *sg_page(stru

RE: [PATCH] crypto: remove unnecessary includes

2013-12-05 Thread Cristian Stoica
> If you can't work out why authenc.c needs slab.h I don't think > you should be submitting patches removing unnecessary header > files. [] You left out "kernel.h". I really hoped this would not be your answer. Yes, I'm an ignorant and yes, I ask questions. But if all you got is this type of a

Re: [PATCH] crypto: remove unnecessary includes

2013-12-05 Thread Herbert Xu
On Thu, Dec 05, 2013 at 08:14:55AM +, Cristian Stoica wrote: > Hi Herbert, > > Your original response was terse and left me more puzzled. Do you have a > sensible explanation why some includes should be kept in the source even they > serve no purpose during the build? If you can't work out

RE: [PATCH] crypto: remove unnecessary includes

2013-12-05 Thread Cristian Stoica
Hi Herbert, Your original response was terse and left me more puzzled. Do you have a sensible explanation why some includes should be kept in the source even they serve no purpose during the build? Thanks, Cristian S. > > Just because it compiles it doesn't meant that the files you > > remo