Hi Xose,
Thanks for your reviews
The up-to-date patch will be sent later.
Regards!
-Yang
On 2017/7/18 7:00, Xose Vazquez Perez wrote:
> On 07/17/2017 04:23 AM, Yang Feng wrote:
>
>> I think there is a mistake:
>> 1. In fact, the tur checker feature has never been removed. The tur checker
>> ha
There are quite a number of occurrences in the kernel of the pattern
if (dst != src)
memcpy(dst, src, walk.total % AES_BLOCK_SIZE);
crypto_xor(dst, final, walk.total % AES_BLOCK_SIZE);
or
crypto_xor(keystream, src, nbytes);
memcpy(dst, keystream, nbytes);
where crypto_xor() is p
>From 2/2:
"""
There are quite a number of occurrences in the kernel of the pattern
if (dst != src)
memcpy(dst, src, walk.total % AES_BLOCK_SIZE);
crypto_xor(dst, final, walk.total % AES_BLOCK_SIZE);
or
crypto_xor(keystream, src, nbytes);
memcpy(dst, keystream, nbyte
In preparation of introducing crypto_xor_cpy(), which will use separate
operands for input and output, modify the __crypto_xor() implementation,
which it will share with the existing crypto_xor(), which provides the
actual functionality when not using the inline version.
Signed-off-by: Ard Biesheu
On 18 July 2017 at 09:39, Herbert Xu wrote:
> On Mon, Jul 10, 2017 at 02:45:48PM +0100, Ard Biesheuvel wrote:
>> There are quite a number of occurrences in the kernel of the pattern
>>
>> if (dst != src)
>> memcpy(dst, src, walk.total % AES_BLOCK_SIZE);
>> crypto_xor(dst, final
On Mon, Jul 10, 2017 at 02:45:48PM +0100, Ard Biesheuvel wrote:
> There are quite a number of occurrences in the kernel of the pattern
>
> if (dst != src)
> memcpy(dst, src, walk.total % AES_BLOCK_SIZE);
> crypto_xor(dst, final, walk.total % AES_BLOCK_SIZE);
>
> or
>
> cr
We are only interested in disks anyway. This saves us checking
for devtype in the uevent processing queue, and is more powerful
than the previous test in the dropped function
uevent_can_discard_by_devpath().
Signed-off-by: Martin Wilck
Reviewed-by: Hannes Reinecke
Acked-by: Benjamin Marzinski
R
This function is broken. Not all devices that matter for multipathd
follow the block/$DEVICE/$PARTITION convention (example: NVME)
Signed-off-by: Martin Wilck
Reviewed-by: Hannes Reinecke
Acked-by: Benjamin Marzinski
Reviewed-by: "Schremmer, Steven"
Reviewed-by: Guan Junxiong
---
libmultipat
If the first WWID_LEN bytes of the uuid_attribute do not contain
a 0 byte, pp->wwid may end up not properly terminated. Fix it by
using strlcpy() rather than strncpy().
Signed-off-by: Martin Wilck
Acked-by: Benjamin Marzinski
---
libmultipath/discovery.c | 6 ++
1 file changed, 2 insertion
Current code fails to set up multipath maps for NVME devices in a
Linux target/Linux host combination. This series enables at least
basic operation.
Patch 1/4 fixes a crash that happens if over-long WWIDs are encountered, and
is not specific to NVME as such. Patch 2/4 drops
the broken test uevent_
Fix for NVME wwids looking like this (line continuations inserted here
for readability):
nvme.-3163653363666438366239656630386200-\
4c696e757800-\
0002
which are encountered in some combinations of Linux NVME host and tar
11 matches
Mail list logo
