[PATCH net-next v3 9/9] Revert "net: do not leave a dangling sk pointer, when socket creation fails"

ations. So this code is now redundant. Suggested-by: Kuniyuki Iwashima Signed-off-by: Ignat Korchagin --- net/core/sock.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/net/core/sock.c b/net/core/sock.c index 083d438d8b6f..a9391cb796a2 100644 --- a/net/core/sock.c +++ b/net/core/sock.c @@ -

[PATCH net-next v3 8/9] net: warn, if pf->create does not clear sock->sk on error

All pf->create implementations have been fixed now to clear sock->sk on error, when they deallocate the allocated sk object. Put a warning in place to make sure we don't break this promise in the future. Suggested-by: Kuniyuki Iwashima Signed-off-by: Ignat Korchagin --- net/s

[PATCH net-next v3 7/9] net: inet6: do not leave a dangling sk pointer in inet6_create()

sock_init_data() attaches the allocated sk pointer to the provided sock object. If inet6_create() fails later, the sk object is released, but the sock object retains the dangling sk pointer, which may cause use-after-free later. Clear the sock sk pointer on error. Signed-off-by: Ignat Korchagin

[PATCH net-next v3 6/9] net: inet: do not leave a dangling sk pointer in inet_create()

sock_init_data() attaches the allocated sk object to the provided sock object. If inet_create() fails later, the sk object is freed, but the sock object retains the dangling pointer, which may create use-after-free later. Clear the sk pointer in the sock object on error. Signed-off-by: Ignat

[PATCH net-next v3 5/9] net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()

. Signed-off-by: Ignat Korchagin Reviewed-by: Miquel Raynal --- net/ieee802154/socket.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/net/ieee802154/socket.c b/net/ieee802154/socket.c index 990a83455dcf..18d267921bb5 100644 --- a/net/ieee802154/socket.c +++ b/net

[PATCH net-next v3 4/9] net: af_can: do not leave a dangling sk pointer in can_create()

On error can_create() frees the allocated sk object, but sock_init_data() has already attached it to the provided sock object. This will leave a dangling sk pointer in the sock object and may cause use-after-free later. Signed-off-by: Ignat Korchagin Reviewed-by: Vincent Mailhol --- net/can

[PATCH net-next v3 3/9] Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc()

: Ignat Korchagin --- net/bluetooth/rfcomm/sock.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c index f48250e3f2e1..355e1a1698f5 100644 --- a/net/bluetooth/rfcomm/sock.c +++ b/net/bluetooth/rfcomm/sock.c

[PATCH net-next v3 2/9] Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()

bt_sock_alloc() allocates the sk object and attaches it to the provided sock object. On error l2cap_sock_alloc() frees the sk object, but the dangling pointer is still attached to the sock object, which may create use-after-free in other code. Signed-off-by: Ignat Korchagin --- net/bluetooth

[PATCH net-next v3 1/9] af_packet: avoid erroring out after sock_init_data() in packet_create()

-off-by: Ignat Korchagin --- net/packet/af_packet.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c index f8942062f776..99ae27d1e4dc 100644 --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -3421,17

[PATCH net-next v3 0/9] do not leave dangling sk pointers in pf->create functions

dangling sk pointer, when socket creation fails") * added optional commits to all pf->create implementaions to clear the sk pointer on error after sock_init_data() Ignat Korchagin (9): af_packet: avoid erroring out after sock_init_data() in packet_create() Bluetooth: L2CAP: do not

Re: [PATCH v2 5/8] net: af_can: do not leave a dangling sk pointer in can_create()

On Tue, Oct 8, 2024 at 3:38 AM Vincent MAILHOL wrote: > > Hi Ignat, > > Thanks for the patch. > > On Tue. 8 Oct. 2024 at 06:37, Ignat Korchagin wrote: > > On error can_create() frees the allocated sk object, but sock_init_data() > > has already attached it to the p

[PATCH v2 8/8] inet6: do not leave a dangling sk pointer in inet6_create()

sock_init_data() attaches the allocated sk pointer to the provided sock object. If inet6_create() fails later, the sk object is released, but the sock object retains the dangling sk pointer, which may cause use-after-free later. Clear the sock sk pointer on error. Signed-off-by: Ignat Korchagin

[PATCH v2 7/8] net: inet: do not leave a dangling sk pointer in inet_create()

sock_init_data() attaches the allocated sk object to the provided sock object. If inet_create() fails later, the sk object is freed, but the sock object retains the dangling pointer, which may create use-after-free later. Clear the sk pointer in the sock object on error. Signed-off-by: Ignat

[PATCH v2 5/8] net: af_can: do not leave a dangling sk pointer in can_create()

On error can_create() frees the allocated sk object, but sock_init_data() has already attached it to the provided sock object. This will leave a dangling sk pointer in the sock object and may cause use-after-free later. Signed-off-by: Ignat Korchagin --- net/can/af_can.c | 1 + 1 file changed

[PATCH v2 6/8] net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()

. Signed-off-by: Ignat Korchagin --- net/ieee802154/socket.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/net/ieee802154/socket.c b/net/ieee802154/socket.c index 990a83455dcf..18d267921bb5 100644 --- a/net/ieee802154/socket.c +++ b/net/ieee802154/socket.c @@ -1043,19

[PATCH v2 4/8] Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc()

: Ignat Korchagin --- net/bluetooth/rfcomm/sock.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c index 37d63d768afb..0d0c4311da57 100644 --- a/net/bluetooth/rfcomm/sock.c +++ b/net/bluetooth/rfcomm/sock.c

[PATCH v2 3/8] Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()

bt_sock_alloc() allocates the sk object and attaches it to the provided sock object. On error l2cap_sock_alloc() frees the sk object, but the dangling pointer is still attached to the sock object, which may create use-after-free in other code. Signed-off-by: Ignat Korchagin --- net/bluetooth

[PATCH v2 2/8] af_packet: avoid erroring out after sock_init_data() in packet_create()

-off-by: Ignat Korchagin --- net/packet/af_packet.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c index a705ec214254..97774bd4b6cb 100644 --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -3421,17

[PATCH v2 1/8] net: explicitly clear the sk pointer, when pf->create fails

r, so if the pointer is not NULL, it is definitely dangling. Fixes: 6cd4a78d962b ("net: do not leave a dangling sk pointer, when socket creation fails") Signed-off-by: Ignat Korchagin Cc: sta...@vger.kernel.org --- net/core/sock.c | 3 --- net/socket.c| 7 ++- 2 files changed,

[PATCH v2 0/8] do not leave dangling sk pointers in pf->create functions

to clear the sk pointer on error after sock_init_data() Ignat Korchagin (8): net: explicitly clear the sk pointer, when pf->create fails af_packet: avoid erroring out after sock_init_data() in packet_create() Bluetooth: L2CAP: do not leave dangling sk pointer on error in l

[PATCH] dm crypt: fix invalid copy paste in crypt_alloc_req_aead

AD request pointer are part of a union, but may confuse code reviewers. Fixes: d68b295 ("dm crypt: use GFP_ATOMIC when allocating crypto requests from softirq") Cc: sta...@vger.kernel.org # v5.9+ Reported-by: Pavel Machek Signed-off-by: Ignat Korchagin --- drivers/md/dm-crypt.c | 6 +++--

Re: [PATCH 5.10 045/152] dm crypt: use GFP_ATOMIC when allocating crypto requests from softirq

On Mon, Jan 18, 2021 at 10:44 PM Pavel Machek wrote: > > > > Fix this by allocating crypto requests with GFP_ATOMIC mask in > > interrupt context. > ... > > This one is wrong. > > > > +++ b/drivers/md/dm-crypt.c > > @@ -1454,13 +1454,16 @@ static int crypt_convert_block_skcipher( > > - if (!ct

[PATCH] dm crypt: defer the decryption to a tasklet, when being called with interrupts disabled

t defer it to a tasklet as with requests from hard irqs. Fixes: 39d42fa96ba1 ("dm crypt: add flags to optionally bypass kcryptd workqueues") Cc: # v5.9+ Signed-off-by: Ignat Korchagin --- drivers/md/dm-crypt.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/d

[PATCH] dm crypt: do not call bio_endio() from the dm-crypt tasklet

"dm crypt: add flags to optionally bypass kcryptd workqueues") Cc: # v5.9+ Signed-off-by: Ignat Korchagin --- drivers/md/dm-crypt.c | 24 +++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c index 5379113

[PATCH v3 2/2] dm crypt: use GFP_ATOMIC when allocating crypto requests from softirq

dd flags to optionally bypass kcryptd workqueues") Reported-by: Maciej S. Szmigiero Cc: # v5.9+ Signed-off-by: Ignat Korchagin --- drivers/md/dm-crypt.c | 35 +-- 1 file changed, 25 insertions(+), 10 deletions(-) diff --git a/drivers/md/dm-crypt.c b/drivers/md/

[PATCH v3 1/2] dm crypt: do not wait for backlogged crypto request completion in softirq

function reentrant from the point of a single bio and make dm-crypt defer further bio processing to a workqueue, if Crypto API backlogs a request in interrupt context. Fixes: 39d42fa96ba1 ("dm crypt: add flags to optionally bypass kcryptd workq ueues") Cc: # v5.9+ Signed-off-by: Ignat

[PATCH v3 0/2] dm crypt: some fixes to support dm-crypt running in softirq context

Changes from v1: * 0001: handle memory allocation failure for GFP_ATOMIC Changes from v2: * reordered patches * 0002: crypt_convert will be retried from a workqueue, when a crypto request allocation fails with GFP_ATOMIC instead of just returning an IO error to the user Ignat

Re: [PATCH v2 1/2] dm crypt: use GFP_ATOMIC when allocating crypto requests from softirq

On Fri, Jan 1, 2021 at 10:00 AM Mikulas Patocka wrote: > > > > On Wed, 30 Dec 2020, Ignat Korchagin wrote: > > > diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c > > index 53791138d78b..e4fd690c70e1 100644 > > --- a/drivers/md/dm-crypt.c > > +++

Re: [PATCH 1/2] dm crypt: use GFP_ATOMIC when allocating crypto requests from softirq

Yes, good call! Reposted with allocation failure handling. Thanks, Ignat On Wed, Dec 30, 2020 at 6:11 PM Mikulas Patocka wrote: > > Hi > > This patch doesn't handle allocation failure gracefully. > > Mikulas > > > > On Tue, 29 Dec 2020,

[PATCH v2 2/2] dm crypt: do not wait for backlogged crypto request completion in softirq

function reentrant from the point of a single bio and make dm-crypt defer further bio processing to a workqueue, if Crypto API backlogs a request in interrupt context. Fixes: 39d42fa96ba1 ("dm crypt: add flags to optionally bypass kcryptd workq ueues") Cc: # v5.9+ Signed-off-by: Ignat

[PATCH v2 0/2] dm crypt: some fixes to support dm-crypt running in softirq context

Changes from v1: 0001: Handle memory allocation failure for GFP_ATOMIC Ignat Korchagin (2): dm crypt: use GFP_ATOMIC when allocating crypto requests from softirq dm crypt: do not wait for backlogged crypto request completion in softirq drivers/md/dm-crypt.c | 135

[PATCH v2 1/2] dm crypt: use GFP_ATOMIC when allocating crypto requests from softirq

dd flags to optionally bypass kcryptd workqueues") Reported-by: Maciej S. Szmigiero Cc: # v5.9+ Signed-off-by: Ignat Korchagin --- drivers/md/dm-crypt.c | 33 +++-- 1 file changed, 23 insertions(+), 10 deletions(-) diff --git a/drivers/md/dm-crypt.c b/drivers/md/

Re: [PATCH 1/2] dm crypt: use GFP_ATOMIC when allocating crypto requests from softirq

les if we are to avoid in_*irq() marcos in the code. > is correct. > > > Reported-by: Maciej S. Szmigiero > > Cc: # v5.9+ > > Signed-off-by: Ignat Korchagin > > --- > > drivers/md/dm-crypt.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) &

[PATCH 2/2] dm crypt: do not wait for backlogged crypto request completion in softirq

function reentrant from the point of a single bio and make dm-crypt defer further bio processing to a workqueue, if Crypto API backlogs a request in interrupt context. Fixes: 39d42fa96ba1 ("dm crypt: add flags to optionally bypass kcryptd workq ueues") Cc: # v5.9+ Signed-off-by: Ignat

[PATCH 1/2] dm crypt: use GFP_ATOMIC when allocating crypto requests from softirq

dd flags to optionally bypass kcryptd workqueues") Reported-by: Maciej S. Szmigiero Cc: # v5.9+ Signed-off-by: Ignat Korchagin --- drivers/md/dm-crypt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c index 5f9f9b3a226d..777

Re: dm-crypt with no_read_workqueue and no_write_workqueue + btrfs scrub = BUG()

On Wed, Dec 23, 2020 at 8:57 PM Herbert Xu wrote: > > On Wed, Dec 23, 2020 at 04:37:34PM +0100, Maciej S. Szmigiero wrote: > > > > It looks like to me that the skcipher API might not be safe to > > call from a softirq context, after all. > > skcipher is safe to use in a softirq. The problem is on

Re: dm-crypt with no_read_workqueue and no_write_workqueue + btrfs scrub = BUG()

On Wed, Dec 23, 2020 at 9:20 PM Maciej S. Szmigiero wrote: > > On 23.12.2020 22:09, Ignat Korchagin wrote: > (..) > > I've been looking into this for the last couple of days because of > > other reports [1]. > > Just finished testing a possible solution. Will sub

Re: dm-crypt with no_read_workqueue and no_write_workqueue + btrfs scrub = BUG()

On Wed, Dec 23, 2020 at 3:37 PM Maciej S. Szmigiero wrote: > > On 14.12.2020 19:11, Maciej S. Szmigiero wrote: > > Hi, > > > > I hit a reproducible BUG() when scrubbing a btrfs fs on top of > > a dm-crypt device with no_read_workqueue and no_write_workqueue > > flags enabled. > > Still happens on

Re: [PATCH v3 3/3] um: allow static linking for non-glibc implementations

On Thu, Jul 16, 2020 at 10:10 AM Johannes Berg wrote: > > On Wed, 2020-07-15 at 21:11 +0100, Ignat Korchagin wrote: > > It is possible to produce a statically linked UML binary with > > UML_NET_VECTOR, > > UML_NET_VDE and UML_NET_PCAP options enabled using alternative

[PATCH v4 3/3] um: allow static linking for non-glibc implementations

It is possible to produce a statically linked UML binary with UML_NET_VECTOR, UML_NET_VDE and UML_NET_PCAP options enabled using alternative libc implementations, which do not rely on NSS, such as musl. Allow static linking in this case. Signed-off-by: Ignat Korchagin Reviewed-by: Brendan

[PATCH v4 1/3] um/kconfig: introduce CC_CAN_LINK_STATIC_NO_RUNTIME_DEPS

encies. Signed-off-by: Ignat Korchagin Reviewed-by: Brendan Higgins Tested-by: Brendan Higgins --- init/Kconfig | 6 ++ scripts/cc-can-link.sh | 5 +++-- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index 0498af567f70..0a1ec56c9f33 10

[PATCH v4 0/3] um: allow static linking for non-glibc libc implementations

being dynamically linked) segfault on start. This is probably of some incompatible config option/module being included and not related to musl/glibc. [1]: https://patchwork.ozlabs.org/project/linux-um/patch/20200624212319.403689-1-ig...@cloudflare.com/ Ignat Korchagin (3): um/kconfig: intr

[PATCH v4 2/3] um: some fixes to build UML with musl

musl toolchain and headers are a bit more strict. These fixes enable building UML with musl as well as seem not to break on glibc. Signed-off-by: Ignat Korchagin Tested-by: Brendan Higgins --- arch/um/drivers/daemon_user.c | 1 + arch/um/drivers/pcap_user.c | 12 ++-- arch/um

[PATCH v3 3/3] um: allow static linking for non-glibc implementations

It is possible to produce a statically linked UML binary with UML_NET_VECTOR, UML_NET_VDE and UML_NET_PCAP options enabled using alternative libc implementations, which do not rely on NSS, such as musl. Allow static linking in this case. Signed-off-by: Ignat Korchagin Reviewed-by: Brendan

[PATCH v3 1/3] um/kconfig: introduce CC_CAN_LINK_STATIC_NO_RUNTIME_DEPS

encies. Signed-off-by: Ignat Korchagin Reviewed-by: Brendan Higgins Tested-by: Brendan Higgins --- init/Kconfig | 6 ++ scripts/cc-can-link.sh | 5 +++-- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index 0498af567f70..0a1ec56c9f33 10

[PATCH v3 0/3] um: allow static linking for non-glibc libc implementations

03689-1-ig...@cloudflare.com/ Ignat Korchagin (3): um/kconfig: introduce CC_CAN_LINK_STATIC_NO_RUNTIME_DEPS um: some fixes to build UML with musl um: allow static linking for non-glibc implementations arch/um/Kconfig | 5 + arch/um/drivers/Kconfig | 3 --- arch/

[PATCH v3 2/3] um: some fixes to build UML with musl

musl toolchain and headers are a bit more strict. These fixes enable building UML with musl as well as seem not to break on glibc. Signed-off-by: Ignat Korchagin Tested-by: Brendan Higgins --- arch/um/drivers/daemon_user.c | 1 + arch/um/drivers/pcap_user.c | 12 ++-- arch/um

Re: [PATCH v2 3/3] um: allow static linking for non-glibc implementations

On Wed, Jul 15, 2020 at 9:44 AM Brendan Higgins wrote: > > On Sat, Jul 4, 2020 at 1:52 AM Ignat Korchagin wrote: > > > > It is possible to produce a statically linked UML binary with > > UML_NET_VECTOR, > > UML_NET_VDE and UML_NET_PCAP options enabled using altern

Re: [PATCH v2 2/3] um: some fixes to build UML with musl

On Tue, Jul 14, 2020 at 9:40 AM Anton Ivanov wrote: > > > On 04/07/2020 09:52, Ignat Korchagin wrote: > > musl toolchain and headers are a bit more strict. These fixes enable > > building > > UML with musl as well as seem not to break on glibc. > > &

Re: [dm-devel] [PATCH v2] dm crypt: add flags to optionally bypass dm-crypt workqueues

On Mon, Jul 6, 2020 at 3:28 PM Bob Liu wrote: > > Hi Ignat, > > On 6/27/20 5:03 AM, Ignat Korchagin wrote: > > This is a follow up from [1]. Consider the following script: > > > > sudo modprobe brd rd_nr=1 rd_size=4194304 > > > > Did you test null_blk dev

[PATCH v3] dm crypt: add flags to optionally bypass dm-crypt workqueues

d encryption into their own workqueues, which are independent of the dm-crypt and its configuration. However upon enabling no_(read|write)_workqueue flags dm-crypt will instruct Crypto API not to backlog crypto requests. [1]: https://www.spinics.net/lists/dm-crypt/msg07516.html [2]: https://blog.c

[PATCH v2 1/3] um/kconfig: introduce CC_CAN_LINK_STATIC_NO_RUNTIME_DEPS

encies. Signed-off-by: Ignat Korchagin --- init/Kconfig | 6 ++ scripts/cc-can-link.sh | 5 +++-- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index a46aa8f3174d..717a3ada765e 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -57,6 +

[PATCH v2 3/3] um: allow static linking for non-glibc implementations

It is possible to produce a statically linked UML binary with UML_NET_VECTOR, UML_NET_VDE and UML_NET_PCAP options enabled using alternative libc implementations, which do not rely on NSS, such as musl. Allow static linking in this case. Signed-off-by: Ignat Korchagin --- arch/um/Kconfig

[PATCH v2 2/3] um: some fixes to build UML with musl

musl toolchain and headers are a bit more strict. These fixes enable building UML with musl as well as seem not to break on glibc. Signed-off-by: Ignat Korchagin --- arch/um/drivers/daemon_user.c | 1 + arch/um/drivers/pcap_user.c | 12 ++-- arch/um/drivers/slip_user.c | 2

[PATCH v2 0/3] um: allow static linking for non-glibc libc implementations

/patch/20200624212319.403689-1-ig...@cloudflare.com/ Ignat Korchagin (3): um/kconfig: introduce CC_CAN_LINK_STATIC_NO_RUNTIME_DEPS um: some fixes to build UML with musl um: allow static linking for non-glibc implementations arch/um/Kconfig | 2 +- arch/um/drivers/Kconfig

Re: [RFC PATCH] Revert "um: Make CONFIG_STATIC_LINK actually static"

On Tue, Jun 30, 2020 at 11:47 PM Brendan Higgins wrote: > > On Wed, Jun 24, 2020 at 2:23 PM Ignat Korchagin wrote: > > > > This reverts commit 3363179385629c1804ea846f4e72608c2201a81e. > > > > This change is too restrictive. I've been running UML stat

Re: [PATCH v2] dm crypt: add flags to optionally bypass dm-crypt workqueues

On Tue, Jun 30, 2020 at 3:51 AM Damien Le Moal wrote: > > On 2020/06/27 6:03, Ignat Korchagin wrote: > > This is a follow up from [1]. Consider the following script: > > > > sudo modprobe brd rd_nr=1 rd_size=4194304 > > > > echo '0 8388608 crypt capi:ecb(c

[PATCH v2] dm crypt: add flags to optionally bypass dm-crypt workqueues

log crypto requests. [1]: https://www.spinics.net/lists/dm-crypt/msg07516.html [2]: https://blog.cloudflare.com/speeding-up-linux-disk-encryption/ Signed-off-by: Ignat Korchagin --- drivers/md/dm-crypt.c | 68 +-- 1 file changed, 52 insertions(+), 16 deletions(-) diff --g

[RFC PATCH] Revert "um: Make CONFIG_STATIC_LINK actually static"

sible to use another libc (like musl, bionic etc) for static linking. I was able with some hacks to compile UML against musl, although the executable segfaults for now. But this option prevents even the research to be done. Signed-off-by: Ignat Korchagin --- arch/um/Kconfig | 8 +--- ar

Re: [dm-crypt] [RFC PATCH 1/1] Add DM_CRYPT_FORCE_INLINE flag to dm-crypt target

On Wed, Jun 24, 2020 at 5:24 PM Eric Biggers wrote: > > On Wed, Jun 24, 2020 at 09:24:07AM +0100, Ignat Korchagin wrote: > > On Wed, Jun 24, 2020 at 6:04 AM Eric Biggers wrote: > > > > > > On Fri, Jun 19, 2020 at 05:41:32PM +0100, Ignat Korchagin wrote: > > &

Re: [dm-crypt] [RFC PATCH 1/1] Add DM_CRYPT_FORCE_INLINE flag to dm-crypt target

On Wed, Jun 24, 2020 at 6:04 AM Eric Biggers wrote: > > On Fri, Jun 19, 2020 at 05:41:32PM +0100, Ignat Korchagin wrote: > > Sometimes extra thread offloading imposed by dm-crypt hurts IO latency. > > This is > > especially visible on busy systems with many processes/thre

Re: [RFC PATCH 0/1] dm-crypt excessive overhead

On Wed, Jun 24, 2020 at 6:22 AM Mike Snitzer wrote: > > On Wed, Jun 24 2020 at 12:54am -0400, > Damien Le Moal wrote: > > > On 2020/06/24 0:23, Mike Snitzer wrote: > > > On Tue, Jun 23 2020 at 11:07am -0400, > > > Ignat Korchagin wrote: > > > > &

Re: [RFC PATCH 0/1] dm-crypt excessive overhead

On Tue, Jun 23, 2020 at 4:34 PM Mike Snitzer wrote: > > On Fri, Jun 19 2020 at 9:23pm -0400, > Herbert Xu wrote: > > > On Fri, Jun 19, 2020 at 02:39:39PM -0400, Mikulas Patocka wrote: > > > > > > I'm looking at this and I'd like to know why does the crypto API fail in > > > hard-irq context and

Re: [RFC PATCH 0/1] dm-crypt excessive overhead

Damien Le Moal wrote: > > > On 2020/06/20 1:56, Mike Snitzer wrote: > > > On Fri, Jun 19 2020 at 12:41pm -0400, > > > Ignat Korchagin wrote: > > > > > >> This is a follow up from the long-forgotten [1], but with some more > > >> convincing

Re: [dm-devel] [RFC PATCH 0/1] dm-crypt excessive overhead

On Mon, Jun 22, 2020 at 1:45 AM Damien Le Moal wrote: > > On 2020/06/20 1:56, Mike Snitzer wrote: > > On Fri, Jun 19 2020 at 12:41pm -0400, > > Ignat Korchagin wrote: > > > >> This is a follow up from the long-forgotten [1], but with some more > >&

Re: [RFC PATCH 0/1] dm-crypt excessive overhead

Yes, it should. I got one when I was testing the first iteration (without the tasklet) of the patch on an NVME? disk. On Sat, Jun 20, 2020 at 8:36 PM Mikulas Patocka wrote: > > > > On Sat, 20 Jun 2020, Herbert Xu wrote: > > > On Fri, Jun 19, 2020 at 02:39:39PM -0400, Mikulas Patocka wrote: > > >

Re: [RFC PATCH 0/1] dm-crypt excessive overhead

On Fri, Jun 19, 2020 at 7:39 PM Mikulas Patocka wrote: > > > > On Fri, 19 Jun 2020, Mike Snitzer wrote: > > > On Fri, Jun 19 2020 at 12:41pm -0400, > > Ignat Korchagin wrote: > > > > > This is a follow up from the long-forgotten [1], but with some more

[RFC PATCH 1/1] Add DM_CRYPT_FORCE_INLINE flag to dm-crypt target

-by: Ignat Korchagin --- drivers/md/dm-crypt.c | 55 +-- 1 file changed, 43 insertions(+), 12 deletions(-) diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c index 000ddfab5ba0..5a9bac4fdffb 100644 --- a/drivers/md/dm-crypt.c +++ b/drivers/md/dm

[RFC PATCH 0/1] dm-crypt excessive overhead

0 datacentres on both SATA SSDs and NVME SSDs and so far were very happy with the performance benefits. [1]: https://www.spinics.net/lists/dm-crypt/msg07516.html [2]: https://blog.cloudflare.com/speeding-up-linux-disk-encryption/ Ignat Korchagin (1): Add DM_CRYPT_FORCE_INLINE flag to dm-c

Re: Linux 4.19 and GCC 9

Hi Greg, > > For us it seems applying the following 4 mainline patches makes 4.19.x > > branch perf compile with GCC-9: > > > > 4d0f16d059ddb91424480d88473f7392f24aebdc: perf ui helpline: Use > > strlcpy() as a shorter form of strncpy() + explicit set nul > > b6313899f4ed2e76b8375cf8069556f5b94fbf

Re: Linux 4.19 and GCC 9

On Mon, Jun 10, 2019 at 3:49 PM Greg KH wrote: > > > > > I typically compile a bare-bones GCC for those things, it is quite quick. > > Pointers to how to do that is appreciated. It's been years since I had > to build gcc "from scratch". This is how we do it, but we use it for some other projects

Re: Linux 4.19 and GCC 9

Hi Greg, For us it seems applying the following 4 mainline patches makes 4.19.x branch perf compile with GCC-9: 4d0f16d059ddb91424480d88473f7392f24aebdc: perf ui helpline: Use strlcpy() as a shorter form of strncpy() + explicit set nul b6313899f4ed2e76b8375cf8069556f5b94fbff0: perf help: Remove n

Re: ipmi_msghandler crashes in 4.19

We're rolling out 4.19.18 across the fleet. Hopefully, we'll not see it anymore, but if we do, we'll let you know. Regards, Ignat On Tue, Jan 29, 2019 at 10:29 AM Greg KH wrote: > > On Tue, Jan 15, 2019 at 10:36:42AM -0800, Ivan Babrou wrote: > > Hey, > > > > We've upgraded some machines from 4.