Re: (subset) [PATCH 000/141] Fix fall-through warnings for Clang

eak/goto/return/fallthrough statements instead of just > letting the code fall through to the next case. > > [...] Applied to 5.11/scsi-queue, thanks! [054/141] target: Fix fall-through warnings for Clang https://git.kernel.org/mkp/scsi/c/492096ecfa39 -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH 000/141] Fix fall-through warnings for Clang

Gustavo, > This series aims to fix almost all remaining fall-through warnings in > order to enable -Wimplicit-fallthrough for Clang. Applied 20-22,54,120-124 to 5.11/scsi-staging, thanks. -- Martin K. Petersen Oracle Linux Engineering

Re: [v2 PATCH] crc-t10dif: Fix potential crypto notify dead-lock

atch fixes this by postponing the work into a work queue and > taking the same lock in the module init function. No particular objections to this approach from me. Reviewed-by: Martin K. Petersen -- Martin K. Petersen Oracle Linux Engineering

[PATCH v2 1/3] crypto: Introduce notifier for new crypto algorithms

to the existing crypto notification chain, and the register/unregister functions are exported so they can be called by subsystems outside of crypto. Signed-off-by: Martin K. Petersen Suggested-by: Herbert Xu --- crypto/algapi.c | 2 ++ crypto/algboss.c| 2 ++ crypto/internal.h

[PATCH v2 3/3] crc-t10dif: Allow current transform to be inspected in sysfs

Add a way to print the currently active CRC algorithm in: /sys/module/crc_t10dif/parameters/transform Signed-off-by: Martin K. Petersen --- lib/crc-t10dif.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/lib/crc-t10dif.c b/lib/crc-t10dif.c index 52f577a3868d

[PATCH v2 2/3] crc-t10dif: Pick better transform if one becomes available

available after the initial hash has been registered. Use RCU to protect the original transform while the new one is being set up. Suggested-by: Ard Biesheuvel Signed-off-by: Martin K. Petersen --- include/linux/crc-t10dif.h | 1 + lib/crc-t10dif.c | 46

Re: [PATCH 1/4] crypto: Introduce notifier for new crypto algorithms

Herbert, Sorry about the delay. Been on the road with surprisingly spotty internet. I addressed your two comments in the patch series that will follow. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH 4/4] block: Integrity profile init function to trigger module loads

Ard, > That is odd. On my Ubuntu system, both crct10dif_pclmul and > crc32_pclmul get loaded automatically. Just checked my Fedora box and they are loaded there too. Peculiar. I'll keep digging... (crc32c-intel is brought in by dracut on RHEL/OL/Fedora, fwiw) -- Martin

Re: [PATCH 4/4] block: Integrity profile init function to trigger module loads

ic 16384 0 crc32_pclmul 16384 0 crc32c_intel 24576 0 crc_ccitt 16384 1 ipv6 -- Martin K. Petersen Oracle Linux Engineering

[PATCH 3/4] crc-t10dif: Allow current transform to be inspected in sysfs

Add a way to print the currently active CRC algorithm in: /sys/module/crc_t10dif/parameters/transform Signed-off-by: Martin K. Petersen --- lib/crc-t10dif.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/lib/crc-t10dif.c b/lib/crc-t10dif.c index 72076a902df5

[PATCH 4/4] block: Integrity profile init function to trigger module loads

_fn in the integrity profile that can be called to trigger a load of modules providing the T10 CRC calculation capability. This function will ony get called when a new integrity profile is registered during device discovery. Signed-off-by: Martin K. Petersen --- block/blk-integrity.c | 5 +

[PATCH 2/4] crc-t10dif: Pick better transform if one becomes available

available after the initial hash has been registered. Use RCU to protect the original transform while the new one is being set up. Suggested-by: Ard Biesheuvel Signed-off-by: Martin K. Petersen --- include/linux/crc-t10dif.h | 1 + lib/crc-t10dif.c | 46

[PATCH 1/4] crypto: Introduce notifier for new crypto algorithms

to the existing crypto notification chain, and the register/unregister functions are exported so they can be called by subsystems outside of crypto. Signed-off-by: Martin K. Petersen Suggested-by: Herbert Xu --- crypto/algapi.c | 7 +++ crypto/algboss.c| 2 ++ crypto

Re: [PATCH] Performance Improvement in CRC16 Calculations.

a small race there. Patch series coming... -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] Performance Improvement in CRC16 Calculations.

_debug). I'll do some more testing over the weekend... -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] Performance Improvement in CRC16 Calculations.

Ard, > I'd prefer to handle this without help from userland. > > It shouldn't be too difficult to register a module notifier that only > sets a flag (or the static key, even?), and to free and re-allocate > the crc_t10dif transform if the flag is set. Something like this proof of concept? diff

Re: [PATCH] Performance Improvement in CRC16 Calculations.

Jeffrey, > So it seems the CONFIG_CRYPTO_CRCT10DIF_PCLMUL=y provides the best > performance. Thanks for confirming! > Are there any negative side effect to this config option? Other than kernel image size, not really. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] Performance Improvement in CRC16 Calculations.

tionally load crct10dif-pclmul (and your ARM equivalent). Looks like there are already hacks in place in dracut to preload crc32c for btrfs and XFS. Anyway. Just seems like the kernel is violating the principle of least surprise here. The kernel should always pick the best available tool for t

Re: [PATCH] Performance Improvement in CRC16 Calculations.

he first place). Instead they are registering their own transformation at a later time where any accelerator modules are more likely to be loaded. Anyway. Just a heads up to people that wonder why the table algorithm is being exercised despite their hardware supporting CRC acceleration. -- Mart

Re: [PATCH] Performance Improvement in CRC16 Calculations.

on performance perspective. With the caveat that our measurements were done about 10 years ago and I'm sure we've come a long way with processors and caches since then. So the results should be interesting... -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] Performance Improvement in CRC16 Calculations.

han one-dimensional. Latency and cache side effects are often more important than throughput. At least on the initiator side. Also, I'd like to keep the original slice-by-one implementation for reference purposes. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH v3 2/5] lib: introduce crc_t10dif_update()

gt; into a local inline function that crc_t10dif_update and crc_t10dif Tim> invoke to get rid of all the duplication. I'm OK with that approach. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a mess

Re: [PATCH v3 0/5] target: Fix several problems related to T10-PI support

ble to handle it. The target will also pass Sagi> this single block with PI to it's backend. The backend is Sagi> responsible to update PI for all the sectors that are written. Sagi> Sounds right? Yes, I agree. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from

Re: [PATCH v3 0/5] target: Fix several problems related to T10-PI support

rld you'd just keep overriding the ref tag in the received PI tuple. But for performance reasons you'll obviously want to do I/O in units bigger than a single block. Blindly preallocating PI to fit the entire I/O is also be problematic, however, since a block count of 0 unfortunately means

Re: [PATCH v3 2/5] lib: introduce crc_t10dif_update()

>>>>> "Akinobu" == Akinobu Mita writes: Akinobu> This introduces crc_t10dif_update() which enables to calculate Akinobu> CRC for a block which straddles multiple SG elements by calling Akinobu> multiple times. Looks good. We need this for the initiator side