similar to: [CRASH] crypto: virtio: crash when modprobing tcrypt on 5.5-rc7 / next-20200122

On Thu, Jan 23, 2020 at 11:10:00AM +0100, LABBE Corentin wrote: > Hello > > When modprobing tcrypt on qemu 4.1.0 I get a kernel panic on 5.5-rc7 and next-20200122 > qemu is started by: > /usr/bin/qemu-system-x86_64 -cpu host -enable-kvm -nographic -net nic,model=e1000,macaddr=52:54:00:12:34:58 -net tap -m 512 -monitor none -object cryptodev-backend-builtin,id=cryptodev0 -device

On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote: > diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c > index eea0f453cfb6..8aac5bc60f4c 100644 > --- a/crypto/tcrypt.c > +++ b/crypto/tcrypt.c > @@ -2464,7 +2464,7 @@ static int do_test(const char *alg, u32 type, u32 mask, int m, u32 num_mb) > test_hash_speed("streebog512", sec, >

On Mon, Dec 12, 2016 at 06:54:07PM +0800, Herbert Xu wrote: > On Mon, Dec 12, 2016 at 06:25:12AM +0000, Gonglei (Arei) wrote: > > Hi, Michael & Herbert > > > > Because the virtio-crypto device emulation had been in QEMU 2.8, > > would you please merge the virtio-crypto driver for 4.10 if no other > > comments? If so, Miachel pls ack and/or review the patch,

On Mon, Dec 12, 2016 at 06:54:07PM +0800, Herbert Xu wrote: > On Mon, Dec 12, 2016 at 06:25:12AM +0000, Gonglei (Arei) wrote: > > Hi, Michael & Herbert > > > > Because the virtio-crypto device emulation had been in QEMU 2.8, > > would you please merge the virtio-crypto driver for 4.10 if no other > > comments? If so, Miachel pls ack and/or review the patch,

On 12/12/2016 11:05 PM, Michael S. Tsirkin wrote: > On Mon, Dec 12, 2016 at 06:54:07PM +0800, Herbert Xu wrote: >> On Mon, Dec 12, 2016 at 06:25:12AM +0000, Gonglei (Arei) wrote: >>> Hi, Michael & Herbert >>> >>> Because the virtio-crypto device emulation had been in QEMU 2.8, >>> would you please merge the virtio-crypto driver for 4.10 if no other

fallthrough to a separate case/default label break; isn't very readable. Convert pseudo-keyword fallthrough; statements to a simple break; when the next label is case or default and the only statement in the next label block is break; Found using: $ grep-2.5.4 -rP --include=*.[ch] -n "fallthrough;(\s*(case\s+\w+|default)\s*:\s*){1,7}break;" * Miscellanea: o Move or coalesce a

Hello When modprobing tcrypt on a qemu virtual machine, I get the following trace in dmesg: skcipher: Test 1 failed (invalid result) on encryption for cts(virtio_crypto_aes_cbc) Regards Corentin Labbe

On 2020/5/25 ??8:56, Longpeng(Mike) wrote: > The system will crash when we insmod crypto/tcrypt.ko whit mode=38. > > Usually the next entry of one sg will be @sg@ + 1, but if this sg element > is part of a chained scatterlist, it could jump to the start of a new > scatterlist array. Let's fix it by sg_next() on calculation of src/dst > scatterlist. > > BTW I add a check

From: Longpeng(Mike) <longpeng2 at huawei.com> commit b02989f37fc5e865ceeee9070907e4493b3a21e2 upstream. The system will crash when the users insmod crypto/tcrypt.ko with mode=38 ( testing "cts(cbc(aes))" ). Usually the next entry of one sg will be @sg@ + 1, but if this sg element is part of a chained scatterlist, it could jump to the start of a new scatterlist array. Fix it by

From: Longpeng(Mike) <longpeng2 at huawei.com> commit b02989f37fc5e865ceeee9070907e4493b3a21e2 upstream. The system will crash when the users insmod crypto/tcrypt.ko with mode=38 ( testing "cts(cbc(aes))" ). Usually the next entry of one sg will be @sg@ + 1, but if this sg element is part of a chained scatterlist, it could jump to the start of a new scatterlist array. Fix it by

From: Longpeng(Mike) <longpeng2 at huawei.com> [ Upstream commit b02989f37fc5e865ceeee9070907e4493b3a21e2 ] The system will crash when the users insmod crypto/tcrypt.ko with mode=38 ( testing "cts(cbc(aes))" ). Usually the next entry of one sg will be @sg@ + 1, but if this sg element is part of a chained scatterlist, it could jump to the start of a new scatterlist array. Fix it

From: Longpeng(Mike) <longpeng2 at huawei.com> [ Upstream commit b02989f37fc5e865ceeee9070907e4493b3a21e2 ] The system will crash when the users insmod crypto/tcrypt.ko with mode=38 ( testing "cts(cbc(aes))" ). Usually the next entry of one sg will be @sg@ + 1, but if this sg element is part of a chained scatterlist, it could jump to the start of a new scatterlist array. Fix it

From: Longpeng(Mike) <longpeng2 at huawei.com> [ Upstream commit b02989f37fc5e865ceeee9070907e4493b3a21e2 ] The system will crash when the users insmod crypto/tcrypt.ko with mode=38 ( testing "cts(cbc(aes))" ). Usually the next entry of one sg will be @sg@ + 1, but if this sg element is part of a chained scatterlist, it could jump to the start of a new scatterlist array. Fix it

This is a note to let you know that I've just added the patch titled crypto: virtio: Fix src/dst scatterlist calculation in __virtio_crypto_skcipher_do_req() to the 5.7-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is:

This is a note to let you know that I've just added the patch titled crypto: virtio: Fix src/dst scatterlist calculation in __virtio_crypto_skcipher_do_req() to the 5.6-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is:

I will be out of the office starting 02/06/2006 and will not return until 02/13/2006. I will respond to your message when I return.

Hello Sean and Tobias, Sean, Thank you. Could you describe Nick's ideas in few words or give me links to your discussion, so I could adapt my ideas to it. Tobias, Your patch fails on several modules in my benchmark (73 of ~1800 tests). I have sent one as attachment. See statistics files for more details, all the .ll files you could simply find in test-suite object directory (after

Hi Stepan, Sorry for the delay. It's great that you are working on MergeFunctions as well and I agree, we should definitely try to combine our efforts to improve MergeFunctions. Just to give you some context, the pass (with the similar function merging patch) is already being used in a production setting. From my point of view, it would be better if we focus on improving its capability

There is a new fallthrough pseudo-keyword macro that can be used to replace the various /* fallthrough */ style comments that are used to indicate a case label code block is intended to fallthrough to the next case label block. See commit 294f69e662d1 ("compiler_attributes.h: Add 'fallthrough' pseudo keyword for switch/case use") These patches are intended to allow clang to

There is a new fallthrough pseudo-keyword macro that can be used to replace the various /* fallthrough */ style comments that are used to indicate a case label code block is intended to fallthrough to the next case label block. See commit 294f69e662d1 ("compiler_attributes.h: Add 'fallthrough' pseudo keyword for switch/case use") These patches are intended to allow clang to