On 13 September 2016 at 07:43, Herbert Xu wrote:
> On Mon, Sep 12, 2016 at 06:40:15PM +0100, Ard Biesheuvel wrote:
>>
>> So to me, it seems like we should be taking the blkcipher_next_slow()
>> path, which does a kmalloc() and bails with -ENOMEM if that fails.
>
>
On 13 September 2016 at 07:43, Herbert Xu wrote:
> On Mon, Sep 12, 2016 at 06:40:15PM +0100, Ard Biesheuvel wrote:
>>
>> So to me, it seems like we should be taking the blkcipher_next_slow()
>> path, which does a kmalloc() and bails with -ENOMEM if that fails.
>
> Indeed. This was broken a long
On Mon, Sep 12, 2016 at 06:40:15PM +0100, Ard Biesheuvel wrote:
>
> So to me, it seems like we should be taking the blkcipher_next_slow()
> path, which does a kmalloc() and bails with -ENOMEM if that fails.
Indeed. This was broken a long time ago. It does seem to be
fixed in the new
On Mon, Sep 12, 2016 at 06:40:15PM +0100, Ard Biesheuvel wrote:
>
> So to me, it seems like we should be taking the blkcipher_next_slow()
> path, which does a kmalloc() and bails with -ENOMEM if that fails.
Indeed. This was broken a long time ago. It does seem to be
fixed in the new
On 12 September 2016 at 03:16, liushuoran wrote:
Hi Ard,
Thanks for the prompt reply. With the patch, there is no panic anymore. But it
seems that the encryption/decryption is not successful anyway.
As Herbert points out, "If the page allocation fails in
On 12 September 2016 at 03:16, liushuoran wrote:
Hi Ard,
Thanks for the prompt reply. With the patch, there is no panic anymore. But it
seems that the encryption/decryption is not successful anyway.
As Herbert points out, "If the page allocation fails in blkcipher_walk_next it'll
simply
On 12 September 2016 at 03:16, liushuoran wrote:
> Hi Ard,
>
> Thanks for the prompt reply. With the patch, there is no panic anymore. But
> it seems that the encryption/decryption is not successful anyway.
>
> As Herbert points out, "If the page allocation fails in
On 12 September 2016 at 03:16, liushuoran wrote:
> Hi Ard,
>
> Thanks for the prompt reply. With the patch, there is no panic anymore. But
> it seems that the encryption/decryption is not successful anyway.
>
> As Herbert points out, "If the page allocation fails in blkcipher_walk_next
> it'll
September 09, 2016 6:57 PM
> To: Xiakaixu
> Cc: Herbert Xu; David S. Miller; Theodore Ts'o; Jaegeuk Kim;
> nhor...@tuxdriver.com; m...@iki.fi; linux-cry...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Wangbintian; liushuoran; Huxinwei; zhangzhibin
> (C)
> Subject: Re: Kernel
September 09, 2016 6:57 PM
> To: Xiakaixu
> Cc: Herbert Xu; David S. Miller; Theodore Ts'o; Jaegeuk Kim;
> nhor...@tuxdriver.com; m...@iki.fi; linux-cry...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Wangbintian; liushuoran; Huxinwei; zhangzhibin
> (C)
> Subject: Re: Kernel
On 9 September 2016 at 11:31, Ard Biesheuvel wrote:
> On 9 September 2016 at 11:19, xiakaixu wrote:
>> Hi,
>>
>> After a deeply research about this crash, seems it is a specific
>> bug that only exists in armv8 board. And it occurs in this function
On 9 September 2016 at 11:31, Ard Biesheuvel wrote:
> On 9 September 2016 at 11:19, xiakaixu wrote:
>> Hi,
>>
>> After a deeply research about this crash, seems it is a specific
>> bug that only exists in armv8 board. And it occurs in this function
>> in arch/arm64/crypto/aes-glue.c.
>>
>>
On 9 September 2016 at 11:19, xiakaixu wrote:
> Hi,
>
> After a deeply research about this crash, seems it is a specific
> bug that only exists in armv8 board. And it occurs in this function
> in arch/arm64/crypto/aes-glue.c.
>
> static int ctr_encrypt(struct blkcipher_desc
On 9 September 2016 at 11:19, xiakaixu wrote:
> Hi,
>
> After a deeply research about this crash, seems it is a specific
> bug that only exists in armv8 board. And it occurs in this function
> in arch/arm64/crypto/aes-glue.c.
>
> static int ctr_encrypt(struct blkcipher_desc *desc, struct
Hi,
After a deeply research about this crash, seems it is a specific
bug that only exists in armv8 board. And it occurs in this function
in arch/arm64/crypto/aes-glue.c.
static int ctr_encrypt(struct blkcipher_desc *desc, struct scatterlist *dst,
struct scatterlist *src,
Hi,
After a deeply research about this crash, seems it is a specific
bug that only exists in armv8 board. And it occurs in this function
in arch/arm64/crypto/aes-glue.c.
static int ctr_encrypt(struct blkcipher_desc *desc, struct scatterlist *dst,
struct scatterlist *src,
Sorry for resend this email, just add the linux-cry...@vger.kernel.org
and linux-kernel@vger.kernel.org.
Hi,
Firstly, thanks for your reply!
To reproduce this kernel panic, I test the encryption/decryption feature
on arm64 board with more memory. Just add the following
change:
diff
Sorry for resend this email, just add the linux-cry...@vger.kernel.org
and linux-kernel@vger.kernel.org.
Hi,
Firstly, thanks for your reply!
To reproduce this kernel panic, I test the encryption/decryption feature
on arm64 board with more memory. Just add the following
change:
diff
On Thu, Sep 08, 2016 at 08:38:43PM +0800, xiakaixu wrote:
> Hi,
>
> I am using the encryption/decryption feature on arm64 board and a kernel
> panic occurs just when open a file. As the memory size of the board
> is limited
> and there are some page allocation failures before the panic.
>
>
On Thu, Sep 08, 2016 at 08:38:43PM +0800, xiakaixu wrote:
> Hi,
>
> I am using the encryption/decryption feature on arm64 board and a kernel
> panic occurs just when open a file. As the memory size of the board
> is limited
> and there are some page allocation failures before the panic.
>
>
20 matches
Mail list logo