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
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
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 +++--
"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
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
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
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(-)
&
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/
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
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
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,
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
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
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
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
> > +++
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
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
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/
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
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
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
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 +
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
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/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
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
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:
> > &
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
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
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
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.
> >
&
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
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/
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
-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
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
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:
> > >
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
> >&
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:
> > >
> &
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
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
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
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,
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
-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
: 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
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
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
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
.
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
: 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
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
-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
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
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
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
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
.
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
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
@@ -
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
73 matches
Mail list logo
