On 03/30/2018 01:53 AM, Salvatore Mesoraca wrote:
All ciphers implemented in Linux have a block size less than or
equal to 16 bytes and the most demanding hw require 16 bytes
alignment for the block buffer.
We avoid 2 VLAs[1] by always allocating 16 bytes with 16 bytes
alignment, unless the
Hi Sergey,
>You shrink a 2 bytes offset down to a 1 byte offset, thus you enforce that
2 Byte offset is not shrinked to 1 byte, Its only 1 bit is reserved out of
16 bits of offset. So only 15 Bits can be used to store offset value.
>'page should be less than 32KB', which I'm sure will be
On (04/02/18 11:21), Maninder Singh wrote:
[..]
> >> static const char * const backends[] = {
> >> "lzo",
> >> #if IS_ENABLED(CONFIG_CRYPTO_LZ4)
> >> "lz4",
> >> +#if (PAGE_SIZE < (32 * KB))
> >> +"lz4_dyn",
> >> +#endif
> >
> >This is not the list of supported
On 03/31/2018 07:30 PM, Gilad Ben-Yossef wrote:
...
>> Are there other crypto drivers doing this?
>
> I thought the exact same thing until I ran into a presentation about the s390
> secure keys implementation. I basically imitated their use (or abuse?)
> of the Crypto API
> assuming it is the way
On Sat, Mar 31, 2018 at 08:30:46PM +0300, Gilad Ben-Yossef wrote:
>
> However, as it uses the exact same mechanism of the regular xts-aes-ccree
> but takes the key from another source, I've marked it with a test of
> alg_test_null() on the premise that if the xts-aes-ccree works, so must this.
On Tue, Apr 03, 2018 at 09:01:02AM +0300, Tudor Ambarus wrote:
>
> I set the err inside the if branch so that the compiler will
> warn me in case of undefined value for err. Like here:
>
> https://rusty.ozlabs.org/?p=232
Yes but then sometimes the compiler will get it wrong and we will
then have
On 03/30/2018 08:27 PM, Herbert Xu wrote:
On Mon, Mar 26, 2018 at 02:59:06PM +0300, Tudor Ambarus wrote:
Remove useless assignment of ret to -ENOMEM in rsa_verify.
Remove useless initialization of ret to zero at declaration in
rsa_enc/dec/sign/verify.
Benefit of the power of undefined values
Hello,
>> (Added cover letter to avoid much text in patch description)
>>
>> LZ4 specification defines 2 byte offset length for 64 KB data.
>> But in case of ZRAM we compress data per page and in most of
>> architecture PAGE_SIZE is 4KB. So we can decide offset length based
>> on actual offset
Hi,
>> diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
>> index 4ed0a78..5bc5aab 100644
>> --- a/drivers/block/zram/zcomp.c
>> +++ b/drivers/block/zram/zcomp.c
>> @@ -17,11 +17,15 @@
>> #include
>>
>> #include "zcomp.h"
>> +#define KB(1 << 10)
>>
>> static
On 3/31/2018 7:11 PM, Atul Gupta wrote:
Facility to register Inline TLS drivers to net/tls. Setup
TLS_HW_RECORD prot to listen on offload device.
Cases handled
- Inline TLS device exists, setup prot for TLS_HW_RECORD
- Atleast one Inline TLS exists, sets TLS_HW_RECORD.
- If non-inline device
Hi,
On 4/1/2018 6:37 AM, David Miller wrote:
From: Atul Gupta
Date: Sat, 31 Mar 2018 21:41:51 +0530
Series for Chelsio Inline TLS driver (chtls)
Series applied, thank you.
Sorry for being late to the party, could you please help answer a few
questions to help me
From: Atul Gupta
Date: Sat, 31 Mar 2018 21:41:51 +0530
> Series for Chelsio Inline TLS driver (chtls)
Series applied, thank you.
On Fri, Mar 30, 2018 at 8:26 PM, Herbert Xu wrote:
> On Mon, Mar 26, 2018 at 08:32:19AM +0100, Gilad Ben-Yossef wrote:
>> Enable CryptoCell support for hardware keys.
>>
>> Hardware keys are regular AES keys loaded into CryptoCell internal memory
>> via firmware,
On Sat, 31 Mar 2018, Varsha Rao wrote:
> On Sat, Mar 31, 2018 at 11:48 AM, Julia Lawall wrote:
> > On Thu, 29 Mar 2018, Varsha Rao wrote:
> >
> >> On Wed, Mar 28, 2018 at 11:41 PM, Joe Perches wrote:
> >> >
> >> > On Wed, 2018-03-28 at 23:27, Varsha Rao wrote:
> >> > > This patch fixes the
On Sat, Mar 31, 2018 at 11:48 AM, Julia Lawall wrote:
> On Thu, 29 Mar 2018, Varsha Rao wrote:
>
>> On Wed, Mar 28, 2018 at 11:41 PM, Joe Perches wrote:
>> >
>> > On Wed, 2018-03-28 at 23:27, Varsha Rao wrote:
>> > > This patch fixes the clang warning of extraneous parentheses, with the
>> > >
On Thu, 29 Mar 2018, Varsha Rao wrote:
> On Wed, Mar 28, 2018 at 11:41 PM, Joe Perches wrote:
> >
> > On Wed, 2018-03-28 at 23:27, Varsha Rao wrote:
> > > This patch fixes the clang warning of extraneous parentheses, with the
> > > following coccinelle script.
> > >
> > > @@
> > > identifier i;
On Fri, 30 Mar 2018, Joe Perches wrote:
> On Thu, 2018-03-29 at 21:03 +0530, Varsha Rao wrote:
> > On Wed, Mar 28, 2018 at 11:41 PM, Joe Perches wrote:
> > >
> > > On Wed, 2018-03-28 at 23:27, Varsha Rao wrote:
> > > > This patch fixes the clang warning of extraneous parentheses, with the
> > >
On Thu, 2018-03-29 at 21:03 +0530, Varsha Rao wrote:
> On Wed, Mar 28, 2018 at 11:41 PM, Joe Perches wrote:
> >
> > On Wed, 2018-03-28 at 23:27, Varsha Rao wrote:
> > > This patch fixes the clang warning of extraneous parentheses, with the
> > > following coccinelle script.
> > >
> > > @@
> > >
> On Mar 30, 2018, at 10:14 AM, Herbert Xu wrote:
>
> On Thu, Mar 22, 2018 at 01:32:30PM +0900, Sergey Senozhatsky wrote:
>> On (03/21/18 15:49), Nick Terrell wrote:
>>> depends on CONFIG_CRYPTO_ZSTD, which isn't defined until this patch is in
>>
>> Yikes! How come
On Mon, Mar 26, 2018 at 08:32:18AM +0100, Gilad Ben-Yossef wrote:
> Remove enums definitions unused in the driver code.
>
> Signed-off-by: Gilad Ben-Yossef
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page:
On Sat, Mar 24, 2018 at 12:02:42PM +0100, Stefan Agner wrote:
> In the AES cases enum spu_cipher_type and enum hash_type have
> the same values, so the assignment is fine. Explicitly cast
> the enum type conversion.
>
> This fixes two warnings when building with clang:
>
On Fri, Mar 23, 2018 at 12:42:15PM +0200, Tudor Ambarus wrote:
> There are few places in crypto where we save pointers to the
> authenc keys to a local variable of type struct crypto_authenc_keys
> and we don't zeroize it after use. Fix all those cases and don't
> leak pointers to the authenc
On Wed, Mar 21, 2018 at 07:01:40PM +0200, Andy Shevchenko wrote:
> Deduplicate le32_to_cpu_array() and cpu_to_le32_array() by moving them
> to the generic header.
>
> No functional change implied.
>
> Signed-off-by: Andy Shevchenko
Patch applied. Thanks.
--
On Thu, Mar 22, 2018 at 10:57:01AM +0100, Christophe Leroy wrote:
> For SEC 2.x+, cipher in length must contain only the ciphertext length.
> In case of using hardware ICV checking, the ICV length is provided via
> the "extent" field of the descriptor pointer.
>
> Cc: #
On Tue, Mar 20, 2018 at 09:56:12AM +0200, Horia Geantă wrote:
> Add a note that it is perfectly legal to "abandon" a request object:
> - call .init() and then (as many times) .update()
> - _not_ call any of .final(), .finup() or .export() at any point in
> future
>
> Link:
On Mon, Mar 19, 2018 at 09:21:12AM +0100, Antoine Tenart wrote:
> Hi Herbert,
>
> This series brings hmac(sha256) and hmac(sha224) support to the Inside
> Secure cryptographic engine driver.
>
> The first 7 patches are fixes and reworks needed for the hmac(sha256)
> and hmac(224) support to land
On Mon, Mar 19, 2018 at 07:06:22PM +0530, Harsh Jain wrote:
> It fixes compilation warning introduced in commit
>
> Introduced by commit
>
> 5110e65536f3 ("crypto: chelsio -Split Hash requests for large scatter
> gather list")
>
> Reported-by: Stephen Rothwell
>
On Mon, Mar 26, 2018 at 02:59:06PM +0300, Tudor Ambarus wrote:
> Remove useless assignment of ret to -ENOMEM in rsa_verify.
> Remove useless initialization of ret to zero at declaration in
> rsa_enc/dec/sign/verify.
>
> Benefit of the power of undefined values and set ret in branches in
>
On Mon, Mar 26, 2018 at 08:32:19AM +0100, Gilad Ben-Yossef wrote:
> Enable CryptoCell support for hardware keys.
>
> Hardware keys are regular AES keys loaded into CryptoCell internal memory
> via firmware, often from secure boot ROM or hardware fuses at boot time.
>
> As such, they can be used
On Fri, Mar 23, 2018 at 12:42:16PM +0200, Tudor Ambarus wrote:
> In crypto_authenc_setkey we save pointers to the authenc keys in
> a local variable of type struct crypto_authenc_keys and we don't
> zeroize it after use. Fix this and don't leak pointers to the
> authenc keys.
>
> Signed-off-by:
Francis Le Bourse wrote:
> Hi Tero,
>
>> I have a couple of additional comments, but can't add them as the patch
>> content is an attachment (like, I would not add the WARN_ON.) Overall,
>> the issue you have found is a legitimate problem, and should be fixed.
>
> I
On Thu, Mar 22, 2018 at 01:32:30PM +0900, Sergey Senozhatsky wrote:
> On (03/21/18 15:49), Nick Terrell wrote:
> > depends on CONFIG_CRYPTO_ZSTD, which isn't defined until this patch is in
>
> Yikes! How come I missed that... :)
>
> > [0]
> >
On Friday, March 03/30/18, 2018 at 00:38:06 +0530, Atul Gupta wrote:
>
>
> On 3/29/2018 9:56 PM, Sabrina Dubroca wrote:
> > 2018-03-29, 21:27:50 +0530, Atul Gupta wrote:
> > ...
> >> +static void chtls_pass_accept_request(struct sock *sk,
> >> +struct sk_buff
On (03/29/18 15:56), Maninder Singh wrote:
> Hello Nick/Sergey,
>
> Any suggestion or comments, so that we can change code and resend the patch?
Well... there were no replies to
https://marc.info/?l=linux-kernel=152161450026771=2
and
https://marc.info/?l=linux-kernel=152161860627974=2
On 3/29/2018 9:56 PM, Sabrina Dubroca wrote:
> 2018-03-29, 21:27:51 +0530, Atul Gupta wrote:
>> TLS handler for record transmit.
>> Create Inline TLS work request and post to FW.
>> Create Inline TLS record CPLs for hardware
>>
>> Signed-off-by: Atul Gupta
>>
On 3/29/2018 9:56 PM, Sabrina Dubroca wrote:
> 2018-03-29, 21:27:50 +0530, Atul Gupta wrote:
> ...
>> +static void chtls_pass_accept_request(struct sock *sk,
>> + struct sk_buff *skb)
>> +{
> ...
>> +if (chtls_get_module(newsk))
>> +goto reject;
2018-03-29, 21:27:51 +0530, Atul Gupta wrote:
> TLS handler for record transmit.
> Create Inline TLS work request and post to FW.
> Create Inline TLS record CPLs for hardware
>
> Signed-off-by: Atul Gupta
> Signed-off-by: Michael Werner
> ---
...
>
2018-03-29, 21:27:50 +0530, Atul Gupta wrote:
...
> +static void chtls_pass_accept_request(struct sock *sk,
> + struct sk_buff *skb)
> +{
...
> + if (chtls_get_module(newsk))
> + goto reject;
> + inet_csk_reqsk_queue_added(sk);
> +
On Wed, Mar 28, 2018 at 11:41 PM, Joe Perches wrote:
>
> On Wed, 2018-03-28 at 23:27, Varsha Rao wrote:
> > This patch fixes the clang warning of extraneous parentheses, with the
> > following coccinelle script.
> >
> > @@
> > identifier i;
> > constant c;
> > @@
> > (
> > -((i == c))
> > +i == c
Hello Nick/Sergey,
Any suggestion or comments, so that we can change code and resend the patch?
> Hi Nick / Sergey,
>
>
> We have compared LZ4 Dyn with Original LZ4 using some samples of realtime
>application data(4Kb)
> compressed/decompressed by ZRAM. For comparison we have used lzbench
Hi,
Fix for that is already submitted in below patch.
https://patchwork.kernel.org/patch/10292333/
Thanks
On 28-03-2018 19:35, Arnd Bergmann wrote:
> static function declarations don't belong in a header file, as shown
> by this compiler warning:
>
> In file included from
Applying, thanks!--b.
On Wed, Mar 28, 2018 at 10:57:22AM -0700, Eric Biggers wrote:
> make_checksum_hmac_md5() is allocating an HMAC transform and doing
> crypto API calls in the following order:
>
> crypto_ahash_init()
> crypto_ahash_setkey()
> crypto_ahash_digest()
>
> This is
On Wed, 2018-03-28 at 23:27 +0530, Varsha Rao wrote:
> This patch fixes the clang warning of extraneous parentheses, with the
> following coccinelle script.
>
> @@
> identifier i;
> constant c;
> @@
> (
> -((i == c))
> +i == c
> >
>
> -((i <= c))
> +i <= c
Why just the "==" and "<=" cases?
Why
On Wed, Mar 28, 2018 at 05:41:30PM +0200, Stefan Agner wrote:
>
> Herbert, given that Raveendra agrees to the change, do you want me to
> send a non-RFC version or can you merge the patch as is?
There is no need to resend it.
Thanks,
--
Email: Herbert Xu
Home Page:
On 28.03.2018 08:38, Raveendra Padasalagi wrote:
> Hi Stefan,
>
> The change looks to be fine. From the IP point of view its using the
> same values in case of AES cipher and hash types so explicit casting
> should be ok.
Can I take that as an Ack?
Herbert, given that Raveendra agrees to the
Hi Stefan,
The change looks to be fine. From the IP point of view its using the
same values in case of AES cipher and hash types so explicit casting
should be ok.
-Raveendra
On Sat, Mar 24, 2018 at 4:32 PM, Stefan Agner wrote:
> In the AES cases enum spu_cipher_type and enum
On 3/27/2018 11:53 PM, Stefano Brivio wrote:
> On Tue, 27 Mar 2018 23:06:30 +0530
> Atul Gupta wrote:
>
>> +static struct tls_context *create_ctx(struct sock *sk)
>> +{
>> +struct inet_connection_sock *icsk = inet_csk(sk);
>> +struct tls_context *ctx;
>> +
>> +
On 3/27/2018 11:12 PM, Stefano Brivio wrote:
> On Tue, 27 Mar 2018 23:06:37 +0530
> Atul Gupta wrote:
>
>> Exchange messages with hardware to program the TLS session
>> CPL handlers for messages received from chip.
>>
>> Signed-off-by: Atul Gupta
On 3/28/2018 2:14 AM, Sabrina Dubroca wrote:
> 2018-03-27, 23:06:31 +0530, Atul Gupta wrote:
>> Ethtool option enables TLS record offload on HW, user
>> configures the feature for netdev capable of Inline TLS.
>> This allows user to define custom sk_prot for Inline TLS sock
>>
>> Signed-off-by:
2018-03-27, 23:06:31 +0530, Atul Gupta wrote:
> Ethtool option enables TLS record offload on HW, user
> configures the feature for netdev capable of Inline TLS.
> This allows user to define custom sk_prot for Inline TLS sock
>
> Signed-off-by: Atul Gupta
> Reviewed-by:
On Tue, 27 Mar 2018 23:06:30 +0530
Atul Gupta wrote:
> +static struct tls_context *create_ctx(struct sock *sk)
> +{
> + struct inet_connection_sock *icsk = inet_csk(sk);
> + struct tls_context *ctx;
> +
> + /* allocate tls context */
> + ctx =
On Tue, 27 Mar 2018 23:06:36 +0530
Atul Gupta wrote:
> +static void __set_tcb_field(struct sock *sk, struct sk_buff *skb, u16 word,
> + u64 mask, u64 val, u8 cookie, int no_reply)
> +{
> + struct chtls_sock *csk =
On Tue, 27 Mar 2018 23:06:38 +0530
Atul Gupta wrote:
> +static u8 tcp_state_to_flowc_state(u8 state)
> +{
> + u8 ret = FW_FLOWC_MNEM_TCPSTATE_ESTABLISHED;
> +
> + switch (state) {
> + case TCP_ESTABLISHED:
> + ret =
On Tue, 27 Mar 2018 23:06:37 +0530
Atul Gupta wrote:
> Exchange messages with hardware to program the TLS session
> CPL handlers for messages received from chip.
>
> Signed-off-by: Atul Gupta
> Signed-off-by: Michael Werner
>
On Tue, 27 Mar 2018 23:06:38 +0530
Atul Gupta wrote:
> TLS handler for record transmit.
> Create Inline TLS work request and post to FW.
> Create Inline TLS record CPLs for hardware
>
> Signed-off-by: Atul Gupta
> Signed-off-by: Michael Werner
On Tue, 27 Mar 2018 23:06:36 +0530
Atul Gupta wrote:
> Initialize the space reserved for storing the TLS keys,
> get and free the location where key is stored for the TLS
> connection.
> Program the Tx and Rx key as received from user in
> struct
Hi Tero,
> Also, I think this patch should be split up in two, as there are two
> issues you are fixing; the bad pointer issue (which I think you only
> fixed partially, also the in->sgl has similar problem), and the missing
> output IVI. Why is this needed btw, I have never faced the requirement
Hi Tero,
> I have a couple of additional comments, but can't add them as the patch
> content is an attachment (like, I would not add the WARN_ON.) Overall,
> the issue you have found is a legitimate problem, and should be fixed.
I have used WARN_ON() to have some very visible output, I agree it
On Fri, Mar 23, 2018 at 02:09:46PM -0500, Gustavo A. R. Silva wrote:
>
> Hi Herbert,
>
> There is an ongoing effort to remove all VLAs from the code base [1] and
> while working on that I came across the following macro at
> include/crypto/hash.h:154:
>
> #define SHASH_DESC_ON_STACK(shash, ctx)
Yael Chemla <yael.che...@foss.arm.com>;
Mike Snitzer <snit...@redhat.com>
Cc: Alasdair Kergon <a...@redhat.com>; dm-de...@redhat.com;
linux-ker...@vger.kernel.org; ofir.dr...@gmail.com; Yael Chemla
<yael.che...@arm.com>; linux-crypto@vger.kernel.org; gi...@benyossef.com
Su
;yael.che...@foss.arm.com>
Cc: Alasdair Kergon <a...@redhat.com>; Mike Snitzer <snit...@redhat.com>;
dm-de...@redhat.com; linux-ker...@vger.kernel.org; ofir.dr...@gmail.com; Yael
Chemla <yael.che...@arm.com>; linux-crypto@vger.kernel.org; gi...@benyossef.com
Subject: Re: [dm-devel] [P
Mike and others,
did anyone even try to run veritysetup tests?
We have verity-compat-test in our testsuite, is has even basic FEC tests
included.
We just added userspace verification of FEC RS codes to compare if kernel
behaves the same.
I tried to apply three last dm-verity patches from
[+Cc linux-crypto]
Hi Yael,
On Sun, Mar 25, 2018 at 07:41:30PM +0100, Yael Chemla wrote:
> Allow parallel processing of bio blocks by moving to async. completion
> handling. This allows for better resource utilization of both HW and
> software based hash tfm and therefore better performance
+CC linux-crypto@vger.kernel.org
No functional change, though.
2018-03-23 22:04 GMT+09:00 Masahiro Yamada :
> Clean up these patterns from the top Makefile to omit 'clean-files'
> in each Makefile.
>
> Signed-off-by: Masahiro Yamada
+CC linux-crypto@vger.kernel.org
No functional change, though.
(I fixed up the subject.)
2018-03-23 22:04 GMT+09:00 Masahiro Yamada :
> Our convention is to distinguish file types by suffixes with a period
> as a separator.
>
> *-asn1.[ch] is a different pattern
+CC linux-crypto@vger.kernel.org
No functional change, though.
2018-03-23 22:04 GMT+09:00 Masahiro Yamada :
> These are common patterns where source files are parsed by the
> asn1_compiler.
>
> Signed-off-by: Masahiro Yamada
> ---
>
On Fri, Mar 16, 2018 at 8:56 AM, Herbert Xu wrote:
> On Thu, Mar 08, 2018 at 01:57:02PM -0800, Kees Cook wrote:
>> On the quest to remove all VLAs from the kernel[1], this switches to
>> a pair of kmalloc regions instead of using the stack. This also moves
>> the
On 26/03/18 01:50 PM, Arnd Bergmann wrote:
> I wouldn't expect it to matter: the byte swap is almost always much
> cheaper compared to the actual bus access for the MMIO, and I
> would also guess that modern compilers can eliminate the double
> byte swap on architectures where writel() is an
On Mon, Mar 26, 2018 at 6:21 PM, Logan Gunthorpe wrote:
>
>
> On 26/03/18 04:53 AM, Arnd Bergmann wrote:
>> On most architectures, this is not important:
>> - For x86, the stores are aways atomic and no additional barriers
>> are needed, so the two are the same
>> - For ARM
On 26/03/18 04:53 AM, Arnd Bergmann wrote:
> On most architectures, this is not important:
> - For x86, the stores are aways atomic and no additional barriers
> are needed, so the two are the same
> - For ARM (both 32 and 64-bit), powerpc and many others, we don't
> use the generic iowrite()
On 03/12/2018 07:07 PM, Tudor Ambarus wrote:
Would you consider using ECDSA in the kernel module signing facility?
Any feedback is good. I can invest some time to make this happen, if
needed.
When compared with RSA, ECDSA has shorter keys, the key generation
process is faster, the sign
On Fri, 2018-03-16 at 17:38 -0300, Thiago Jung Bauermann wrote:
> With the introduction of another IMA signature type (modsig), some places
> will need to check for both of them. It is cleaner to do that if there's a
> helper function to tell whether an xattr_value represents an IMA
> signature.
On Fri, 2018-03-16 at 17:38 -0300, Thiago Jung Bauermann wrote:
> This patch actually implements the appraise_type=imasig|modsig option,
> allowing IMA to read and verify modsig signatures.
>
> In case both are present in the same file, IMA will first check whether the
> key used by the xattr
On Fri, 2018-03-16 at 17:38 -0300, Thiago Jung Bauermann wrote:
> Define new "d-sig" template field which holds the digest that is expected
> to match the one contained in the modsig.
>
> Also add modsig support to the "sig" template field, allowing the the
> contents of the modsig to be included
On Wed, Mar 21, 2018 at 5:37 PM, Logan Gunthorpe wrote:
> The semantics of the iowriteXXbe() functions are to write a
> value in CPU endianess to an IO register that is known by the
> caller to be in Big Endian. The mmio_writeXXbe() macro, which
> is called by iowriteXXbe(),
On 3/23/2018 12:42 PM, Tudor Ambarus wrote:
> In caam's aead_setkey we save pointers to the authenc keys in a
> local variable of type struct crypto_authenc_keys and we don't
> zeroize it after use. Fix this and don't leak pointers to the
> authenc keys.
>
> Signed-off-by: Tudor Ambarus
On 3/23/2018 12:42 PM, Tudor Ambarus wrote:
> In caam/qi's aead_setkey we save pointers to the authenc keys in
> a local variable of type struct crypto_authenc_keys and we don't
> zeroize it after use. Fix this and don't leak pointers to the
> authenc keys.
>
> Signed-off-by: Tudor Ambarus
Hi Benjamin,
Thanks for the nice present and good testing!
I hope to grab a chance to test this shiny new algorithm but is busy this week.
Hopefully, I will get that soon and feedback to you asap.
Thanks.
On Mon, Mar 26, 2018 at 10:31:40AM +0200, Benjamin Warnke wrote:
> This patch series adds
2018-03-23 16:36 GMT+01:00 Herbert Xu :
> On Thu, Mar 15, 2018 at 12:18:58PM +0100, Salvatore Mesoraca wrote:
>>
>> +#define MAX_BLOCKSIZE 16
>> +
>> +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
>> +#define MAX_ALIGNMASK 15
>> +#else
>> +#define MAX_ALIGNMASK 0
>>
Hi Herbert,
On sam., mars 24 2018, Herbert Xu wrote:
> On Tue, Mar 13, 2018 at 05:48:39PM +0100, Gregory CLEMENT wrote:
>> Hi,
>>
>> This short series fixes the way the clocks are used for the SafeXcel
>> EIP-197 controller embedded in the Marvell Armada 7K/8K
From: Dave Watson
Date: Thu, 22 Mar 2018 10:09:44 -0700
> TLS tcp socket RX implementation, to match existing TX code.
Looks great Dave. Applied, and once my build tests finish I'll push
this out to net-next.
In some of the new functions, reverse christmas tree ordering of
On Sun, Mar 18, 2018 at 10:50:38PM +0800, Jia-Ju Bai wrote:
> cpt_device_init() is never called in atomic context.
>
> The call chain ending up at cpt_device_init() is:
> [1] cpt_device_init() <- cpt_probe()
> cpt_probe() is only set as ".probe" in pci_driver structure
> "cpt_pci_driver".
>
>
Leonard Crestez wrote:
> The decision to rebuild .S_shipped is made based on the relative
> timestamps of .S_shipped and .pl files but git makes this essentially
> random. This means that the perl script might run anyway (usually at
> most once per checkout), defeating
On Wed, Mar 14, 2018 at 05:15:52PM -0500, Gary R Hook wrote:
> Add missing comments for union members ablkcipher, blkcipher,
> cipher, and compress. This silences complaints when building
> the htmldocs.
>
> Fixes: 0d7f488f0305a (crypto: doc - cipher data structures)
> Signed-off-by: Gary R Hook
On Wed, Mar 14, 2018 at 04:35:32PM +0100, Arnd Bergmann wrote:
> The blackfin architecture is getting removed, so this
> driver won't be used any more.
>
> Signed-off-by: Arnd Bergmann
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page:
On Tue, Mar 13, 2018 at 01:33:29PM -0400, Vitaly Andrianov wrote:
> Keyston2 Security Accelerator has a hardware random generator sub-module.
> This series adds the driver for the sub-module.
>
> Changes in v2:
> - Changed subject prefix in 1/2 patch
> - renamed dts node
>
> Vitaly Andrianov
On Tue, Mar 13, 2018 at 05:48:39PM +0100, Gregory CLEMENT wrote:
> Hi,
>
> This short series fixes the way the clocks are used for the SafeXcel
> EIP-197 controller embedded in the Marvell Armada 7K/8K SoCs. On these
> SoCs a second one is needed in order to clock the registers. It was
> not
On Tue, Mar 13, 2018 at 02:54:03PM +, Wei Yongjun wrote:
> Add the missing unlock before return from function
> safexcel_ahash_send_req() in the error handling case.
>
> Fixes: cff9a17545a3 ("crypto: inside-secure - move cache result dma mapping
> to request")
> Signed-off-by: Wei Yongjun
On Mon, Mar 12, 2018 at 02:32:58PM +0100, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Mon, 12 Mar 2018 14:18:23 +0100
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle
On Thu, Mar 15, 2018 at 12:18:58PM +0100, Salvatore Mesoraca wrote:
>
> +#define MAX_BLOCKSIZE 16
> +
> +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> +#define MAX_ALIGNMASK 15
> +#else
> +#define MAX_ALIGNMASK 0
> +#endif
> +
Hmm, this won't work. Just because you have efficient unaligned
On 07.03.2018 18:56, Maciej S. Szmigiero wrote:
> On 07.03.2018 16:44, David Howells wrote:
>> Maciej S. Szmigiero wrote:
>>
>>> + if (!strcmp(ctx->cert->sig->pkey_algo, "rsa")) {
>>
>> I'm going to change this to '== 0' rather than '!'.
>
> No problem.
I cannot
Hi Nick / Sergey,
We have compared LZ4 Dyn with Original LZ4 using some samples of realtime
application data(4Kb)
compressed/decompressed by ZRAM. For comparison we have used lzbench
(https://github.com/inikep/lzbench)
we have implemented dedicated LZ4 Dyn API & kept last literal length as 6
Hi Francis,
This has similar checkpatch issues + being split into multipart message
as your other patch.
Also, I think this patch should be split up in two, as there are two
issues you are fixing; the bad pointer issue (which I think you only
fixed partially, also the in->sgl has similar
On 23/03/18 15:50, Tero Kristo wrote:
Hi Francis,
Your email program is still messing up things, the patch was sent as a
multipart message. Use git-send-email tool or something similar if
possible.
Also, there are at least two checkpatch issues (run
scripts/checkpatch.pl -strict ), in
Hi Francis,
Your email program is still messing up things, the patch was sent as a
multipart message. Use git-send-email tool or something similar if possible.
Also, there are at least two checkpatch issues (run
scripts/checkpatch.pl -strict ), in addition to the UTF-8
formatted message
Hi Nick,
Thanks for your comments, Please check my reply to few of your comments.
I will be sharing benchmarking figures separately.
>
>> +if (curr_offset > 127) {
>> +curr_offset = (curr_offset << 1) | DYN_BIT;
>> +
Hi Benjamin,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.16-rc6]
[cannot apply to next-20180322]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
On 3/22/2018 12:04 PM, Christophe LEROY wrote:
> Le 16/03/2018 à 15:07, Horia Geantă a écrit :
>> On 3/16/2018 2:42 PM, Christophe LEROY wrote:
>>> Le 16/03/2018 à 09:48, Horia Geantă a écrit :
For SEC 2.x+, cipher in length must contain only the ciphertext length.
In case of using
On Sat, Mar 10, 2018 at 03:22:31PM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> If the pcrypt template is used multiple times in an algorithm, then a
> deadlock occurs because all pcrypt instances share the same
> padata_instance, which completes requests in the order
Hi Maninder,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc6]
[cannot apply to next-20180322]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
701 - 800 of 16295 matches
Mail list logo