Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: 226853ac3ebe ("crypto: caam/qi2 - add skcipher algorithms").
The bot has tested the following trees: v5.8.1, v5.7.15, v5.4.58.
v5.8.1: Failed to apply! Possible dependencies:
528f776df67c ("crypto: qat - allow xts requests not multiple of block")
a85211f36f3d ("crypto: qat - fallback for xts with 192 bit keys")
b185a68710e0 ("crypto: qat - validate xts key")
b8aa7dc5c753 ("crypto: drivers - set the flag CRYPTO_ALG_ALLOCATES_MEMORY")
da6a66853a38 ("crypto: caam - silence .setkey in case of bad key length")
v5.7.15: Failed to apply! Possible dependencies:
528f776df67c ("crypto: qat - allow xts requests not multiple of block")
a85211f36f3d ("crypto: qat - fallback for xts with 192 bit keys")
b185a68710e0 ("crypto: qat - validate xts key")
b8aa7dc5c753 ("crypto: drivers - set the flag CRYPTO_ALG_ALLOCATES_MEMORY")
da6a66853a38 ("crypto: caam - silence .setkey in case of bad key length")
v5.4.58: Failed to apply! Possible dependencies:
64db5e7439fb ("crypto: sparc/aes - convert to skcipher API")
66d7fb94e4ff ("crypto: blake2s - generic C library implementation and selftest")
674f368a952c ("crypto: remove CRYPTO_TFM_RES_BAD_KEY_LEN")
746b2e024c67 ("crypto: lib - tidy up lib/crypto Kconfig and Makefile")
7988fb2c03c8 ("crypto: s390/aes - convert to skcipher API")
7f725f41f627 ("crypto: powerpc - convert SPE AES algorithms to skcipher API")
7f9b0880925f ("crypto: blake2s - implement generic shash driver")
91d689337fe8 ("crypto: blake2b - add blake2b generic implementation")
b4d0c0aad57a ("crypto: arm - use Kconfig based compiler checks for crypto opcodes")
b95bba5d0114 ("crypto: skcipher - rename the crypto_blkcipher module and kconfig option")
d00c06398154 ("crypto: s390/paes - convert to skcipher API")
da6a66853a38 ("crypto: caam - silence .setkey in case of bad key length")
ed0356eda153 ("crypto: blake2s - x86_64 SIMD implementation")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: b189817cf789 ("crypto: caam/qi - add ablkcipher and authenc algorithms").
The bot has tested the following trees: v5.8.1, v5.7.15, v5.4.58, v4.19.139, v4.14.193.
v5.8.1: Failed to apply! Possible dependencies:
528f776df67c ("crypto: qat - allow xts requests not multiple of block")
a85211f36f3d ("crypto: qat - fallback for xts with 192 bit keys")
b185a68710e0 ("crypto: qat - validate xts key")
b8aa7dc5c753 ("crypto: drivers - set the flag CRYPTO_ALG_ALLOCATES_MEMORY")
da6a66853a38 ("crypto: caam - silence .setkey in case of bad key length")
v5.7.15: Failed to apply! Possible dependencies:
528f776df67c ("crypto: qat - allow xts requests not multiple of block")
a85211f36f3d ("crypto: qat - fallback for xts with 192 bit keys")
b185a68710e0 ("crypto: qat - validate xts key")
b8aa7dc5c753 ("crypto: drivers - set the flag CRYPTO_ALG_ALLOCATES_MEMORY")
da6a66853a38 ("crypto: caam - silence .setkey in case of bad key length")
v5.4.58: Failed to apply! Possible dependencies:
64db5e7439fb ("crypto: sparc/aes - convert to skcipher API")
66d7fb94e4ff ("crypto: blake2s - generic C library implementation and selftest")
674f368a952c ("crypto: remove CRYPTO_TFM_RES_BAD_KEY_LEN")
746b2e024c67 ("crypto: lib - tidy up lib/crypto Kconfig and Makefile")
7988fb2c03c8 ("crypto: s390/aes - convert to skcipher API")
7f725f41f627 ("crypto: powerpc - convert SPE AES algorithms to skcipher API")
7f9b0880925f ("crypto: blake2s - implement generic shash driver")
91d689337fe8 ("crypto: blake2b - add blake2b generic implementation")
b4d0c0aad57a ("crypto: arm - use Kconfig based compiler checks for crypto opcodes")
b95bba5d0114 ("crypto: skcipher - rename the crypto_blkcipher module and kconfig option")
d00c06398154 ("crypto: s390/paes - convert to skcipher API")
da6a66853a38 ("crypto: caam - silence .setkey in case of bad key length")
ed0356eda153 ("crypto: blake2s - x86_64 SIMD implementation")
v4.19.139: Failed to apply! Possible dependencies:
0a5dff9882e5 ("crypto: arm/ghash - provide a synchronous version")
1ca1b917940c ("crypto: chacha20-generic - refactor to allow varying number of rounds")
5ca7badb1f62 ("crypto: caam/jr - ablkcipher -> skcipher conversion")
674f368a952c ("crypto: remove CRYPTO_TFM_RES_BAD_KEY_LEN")
8a5a79d5556b ("crypto: x86/chacha20 - Add a 4-block AVX2 variant")
99680c5e9182 ("crypto: arm - convert to use crypto_simd_usable()")
9b17608f15b9 ("crypto: x86/chacha20 - Use larger block functions more aggressively")
9dbe3072c6b1 ("crypto: caam/qi - ablkcipher -> skcipher conversion")
a5dd97f86211 ("crypto: x86/chacha20 - Add a 2-block AVX2 variant")
aec48adce85d ("crypto: caam/qi - remove ablkcipher IV generation")
c3b734dd325d ("crypto: x86/chacha20 - Support partial lengths in 8-block AVX2 variant")
cf5448b5c3d8 ("crypto: caam/jr - remove ablkcipher IV generation")
da6a66853a38 ("crypto: caam - silence .setkey in case of bad key length")
db8e15a24957 ("crypto: x86/chacha20 - Support partial lengths in 4-block SSSE3 variant")
e4e72063d3c0 ("crypto: x86/chacha20 - Support partial lengths in 1-block SSSE3 variant")
v4.14.193: Failed to apply! Possible dependencies:
5ca7badb1f62 ("crypto: caam/jr - ablkcipher -> skcipher conversion")
662f70ede597 ("crypto: caam - remove needless ablkcipher key copy")
7e0880b9fbbe ("crypto: caam - add Derived Key Protocol (DKP) support")
87ec3a0b1c2d ("crypto: caam - prepare for gcm(aes) support over QI interface")
9dbe3072c6b1 ("crypto: caam/qi - ablkcipher -> skcipher conversion")
cf5448b5c3d8 ("crypto: caam/jr - remove ablkcipher IV generation")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
Checks for partial overlaps on insertion assume that end elements
are always descendant nodes of their corresponding start, because
they are inserted later. However, this is not the case if a
previous delete operation caused a tree rotation as part of
rebalancing.
Taking the issue reported by Andreas Fischer as an example, if we
omit delete operations, the existing procedure works because,
equivalently, we are inserting a start item with value 40 in the
this region of the red-black tree with single-sized intervals:
overlap flag
10 (start)
/ \ false
20 (start)
/ \ false
30 (start)
/ \ false
60 (start)
/ \ false
50 (end)
/ \ false
20 (end)
/ \ false
40 (start)
if we now delete interval 30 - 30, the tree can be rearranged in
a way similar to this (note the rotation involving 50 - 50):
overlap flag
10 (start)
/ \ false
20 (start)
/ \ false
25 (start)
/ \ false
70 (start)
/ \ false
50 (end)
/ \ true (from rule a1.)
50 (start)
/ \ true
40 (start)
and we traverse interval 50 - 50 from the opposite direction
compared to what was expected.
To deal with those cases, add a start-before-start rule, b4.,
that covers traversal of existing intervals from the right.
We now need to restrict start-after-end rule b3. to cases
where there are no occurring nodes between existing start and
end elements, because addition of rule b4. isn't sufficient to
ensure that the pre-existing end element we encounter while
descending the tree corresponds to a start element of an
interval that we already traversed entirely.
Different types of overlap detection on trees with rotations
resulting from re-balancing will be covered by nft test case
sets/0044interval_overlap_1.
Reported-by: Andreas Fischer <netfilter(a)d9c.eu>
Bugzilla: https://bugzilla.netfilter.org/show_bug.cgi?id=1449
Cc: <stable(a)vger.kernel.org> # 5.6.x
Fixes: 7c84d41416d8 ("netfilter: nft_set_rbtree: Detect partial overlaps on insertion")
Signed-off-by: Stefano Brivio <sbrivio(a)redhat.com>
---
net/netfilter/nft_set_rbtree.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/net/netfilter/nft_set_rbtree.c b/net/netfilter/nft_set_rbtree.c
index 4b2834fd17b2..27668f4e44ea 100644
--- a/net/netfilter/nft_set_rbtree.c
+++ b/net/netfilter/nft_set_rbtree.c
@@ -238,21 +238,27 @@ static int __nft_rbtree_insert(const struct net *net, const struct nft_set *set,
*
* b1. _ _ __>| !_ _ __| (insert end before existing start)
* b2. _ _ ___| !_ _ _>| (insert end after existing start)
- * b3. _ _ ___! >|_ _ __| (insert start after existing end)
+ * b3. _ _ ___! >|_ _ __| (insert start after existing end, as a leaf)
+ * '--' no nodes falling in this range
+ * b4. >|_ _ ! (insert start before existing start)
*
* Case a3. resolves to b3.:
* - if the inserted start element is the leftmost, because the '0'
* element in the tree serves as end element
- * - otherwise, if an existing end is found. Note that end elements are
- * always inserted after corresponding start elements.
+ * - otherwise, if an existing end is found immediately to the left. If
+ * there are existing nodes in between, we need to further descend the
+ * tree before we can conclude the new start isn't causing an overlap
+ *
+ * or to b4., which, preceded by a3., means we already traversed one or
+ * more existing intervals entirely, from the right.
*
* For a new, rightmost pair of elements, we'll hit cases b3. and b2.,
* in that order.
*
* The flag is also cleared in two special cases:
*
- * b4. |__ _ _!|<_ _ _ (insert start right before existing end)
- * b5. |__ _ >|!__ _ _ (insert end right after existing start)
+ * b5. |__ _ _!|<_ _ _ (insert start right before existing end)
+ * b6. |__ _ >|!__ _ _ (insert end right after existing start)
*
* which always happen as last step and imply that no further
* overlapping is possible.
@@ -272,7 +278,7 @@ static int __nft_rbtree_insert(const struct net *net, const struct nft_set *set,
if (nft_rbtree_interval_start(new)) {
if (nft_rbtree_interval_end(rbe) &&
nft_set_elem_active(&rbe->ext, genmask) &&
- !nft_set_elem_expired(&rbe->ext))
+ !nft_set_elem_expired(&rbe->ext) && !*p)
overlap = false;
} else {
overlap = nft_rbtree_interval_end(rbe) &&
@@ -288,10 +294,9 @@ static int __nft_rbtree_insert(const struct net *net, const struct nft_set *set,
nft_set_elem_active(&rbe->ext,
genmask) &&
!nft_set_elem_expired(&rbe->ext);
- } else if (nft_rbtree_interval_end(rbe) &&
- nft_set_elem_active(&rbe->ext, genmask) &&
+ } else if (nft_set_elem_active(&rbe->ext, genmask) &&
!nft_set_elem_expired(&rbe->ext)) {
- overlap = true;
+ overlap = nft_rbtree_interval_end(rbe);
}
} else {
if (nft_rbtree_interval_end(rbe) &&
--
2.28.0
The patch titled
Subject: mm, THP, swap: fix allocating cluster for swapfile by mistake
has been added to the -mm tree. Its filename is
mm-thp-swap-fix-allocating-cluster-for-swapfile-by-mistake.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/mm-thp-swap-fix-allocating-cluste…
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/mm-thp-swap-fix-allocating-cluste…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Gao Xiang <hsiangkao(a)redhat.com>
Subject: mm, THP, swap: fix allocating cluster for swapfile by mistake
SWP_FS doesn't mean the device is file-backed swap device, which just
means each writeback request should go through fs by DIO. Or it'll just
use extents added by .swap_activate(), but it also works as file-backed
swap device.
So in order to achieve the goal of the original patch, SWP_BLKDEV should
be used instead.
FS corruption can be observed with SSD device + XFS + fragmented swapfile
due to CONFIG_THP_SWAP=y.
I reproduced the issue with the following details:
Environment:
QEMU + upstream kernel + buildroot + NVMe (2 GB)
Kernel config:
CONFIG_BLK_DEV_NVME=y
CONFIG_THP_SWAP=y
Some reproducable steps:
mkfs.xfs -f /dev/nvme0n1
mkdir /tmp/mnt
mount /dev/nvme0n1 /tmp/mnt
bs="32k"
sz="1024m" # doesn't matter too much, I also tried 16m
xfs_io -f -c "pwrite -R -b $bs 0 $sz" -c "fdatasync" /tmp/mnt/sw
xfs_io -f -c "pwrite -R -b $bs 0 $sz" -c "fdatasync" /tmp/mnt/sw
xfs_io -f -c "pwrite -R -b $bs 0 $sz" -c "fdatasync" /tmp/mnt/sw
xfs_io -f -c "pwrite -F -S 0 -b $bs 0 $sz" -c "fdatasync" /tmp/mnt/sw
xfs_io -f -c "pwrite -R -b $bs 0 $sz" -c "fsync" /tmp/mnt/sw
mkswap /tmp/mnt/sw
swapon /tmp/mnt/sw
stress --vm 2 --vm-bytes 600M # doesn't matter too much as well
Symptoms:
- FS corruption (e.g. checksum failure)
- memory corruption at: 0xd2808010
- segfault
Link: https://lkml.kernel.org/r/20200819195613.24269-1-hsiangkao@redhat.com
Fixes: f0eea189e8e9 ("mm, THP, swap: Don't allocate huge cluster for file backed swap device")
Fixes: 38d8b4e6bdc8 ("mm, THP, swap: delay splitting THP during swap out")
Signed-off-by: Gao Xiang <hsiangkao(a)redhat.com>
Cc: "Huang, Ying" <ying.huang(a)intel.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/swapfile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/swapfile.c~mm-thp-swap-fix-allocating-cluster-for-swapfile-by-mistake
+++ a/mm/swapfile.c
@@ -1078,7 +1078,7 @@ start_over:
goto nextsi;
}
if (size == SWAPFILE_CLUSTER) {
- if (!(si->flags & SWP_FS))
+ if (si->flags & SWP_BLKDEV)
n_ret = swap_alloc_cluster(si, swp_entries);
} else
n_ret = scan_swap_map_slots(si, SWAP_HAS_CACHE,
_
Patches currently in -mm which might be from hsiangkao(a)redhat.com are
mm-thp-swap-fix-allocating-cluster-for-swapfile-by-mistake.patch
Adjust the calls to `user_regset_copyout' and `user_regset_copyin' in
`riscv_fpr_get' and `riscv_fpr_set' respectively so as to use @start_pos
and @end_pos according to API documentation in <linux/regset.h>, that is
to point at the beginning and the end respectively of the data chunk to
be copied. Update @data accordingly, also for the first call, to make
it clear which structure member is accessed.
We currently have @start_pos fixed at 0 across all calls, which works as
a result of the implementation, in particular because we have no padding
between the FP general registers and the FP control and status register,
but appears not to have been the intent of the API and is not what other
ports do, requiring one to study the copy handlers to understand what is
going on here.
Signed-off-by: Maciej W. Rozycki <macro(a)wdc.com>
Fixes: b8c8a9590e4f ("RISC-V: Add FP register ptrace support for gdb.")
Cc: stable(a)vger.kernel.org # 4.20+
---
arch/riscv/kernel/ptrace.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
linux-riscv-ptrace-fcsr.diff
Index: linux-hv/arch/riscv/kernel/ptrace.c
===================================================================
--- linux-hv.orig/arch/riscv/kernel/ptrace.c
+++ linux-hv/arch/riscv/kernel/ptrace.c
@@ -61,10 +61,13 @@ static int riscv_fpr_get(struct task_str
int ret;
struct __riscv_d_ext_state *fstate = &target->thread.fstate;
- ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf, fstate, 0,
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf, &fstate->f, 0,
offsetof(struct __riscv_d_ext_state, fcsr));
if (!ret) {
- ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf, fstate, 0,
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &fstate->fcsr,
+ offsetof(struct __riscv_d_ext_state,
+ fcsr),
offsetof(struct __riscv_d_ext_state, fcsr) +
sizeof(fstate->fcsr));
}
@@ -80,10 +83,13 @@ static int riscv_fpr_set(struct task_str
int ret;
struct __riscv_d_ext_state *fstate = &target->thread.fstate;
- ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, fstate, 0,
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &fstate->f, 0,
offsetof(struct __riscv_d_ext_state, fcsr));
if (!ret) {
- ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, fstate, 0,
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &fstate->fcsr,
+ offsetof(struct __riscv_d_ext_state,
+ fcsr),
offsetof(struct __riscv_d_ext_state, fcsr) +
sizeof(fstate->fcsr));
}