January 2024 - Linux-stable-mirror

Re: [REGRESSION 6.1.70] system calls with CIFS mounts failing with "Resource temporarily unavailable"

by Mohamed Abuelfotoh, Hazem

It looks like both 5.15.146 and 5.10.206 are impacted by this regression as they both have the bad commit 33eae65c6f (smb: client: fix OOB in SMB2_query_info_init()). We tried to apply the proposed fix eb3e28c1e89b ("smb3: Replace smb2pdu 1-element arrays with flex-arrays”) but there are a lot of dependencies required to do the backport. Is it possible to consider the simple fix that Paulo proposed as a solution for 5.10 and 5.15. We were lucky with 5.4 as it doesn’t have the bad commit because of merge conflict reported in https://lore.kernel.org/all/2023122857-doubling-crazed-27f4@gregkh/T/#m3aa0… diff --git a/fs/smb/client/smb2pdu.c b/fs/smb/client/smb2pdu.c index 05ff8a457a3d..aed5067661de 100644 --- a/fs/smb/client/smb2pdu.c +++ b/fs/smb/client/smb2pdu.c @@ -3556,7 +3556,7 @@ SMB2_query_info_init(struct cifs_tcon *tcon, struct TCP_Server_Info *server, iov[0].iov_base = (char *)req; /* 1 for Buffer */ - iov[0].iov_len = len; + iov[0].iov_len = len - 1; return 0; } Hazem

2 months, 1 week

9
19
0 0

FAILED: patch "[PATCH] erofs: fix lz4 inplace decompression" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 3c12466b6b7bf1e56f9b32c366a3d83d87afb4de # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024012650-altitude-gush-572f@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 3c12466b6b7b ("erofs: fix lz4 inplace decompression") 123ec246ebe3 ("erofs: get rid of the remaining kmap_atomic()") ab749badf9f4 ("erofs: support unaligned data decompression") 10e5f6e482e1 ("erofs: introduce z_erofs_fixup_insize") d67aee76d418 ("erofs: tidy up z_erofs_lz4_decompress") 7e508f2ca8bb ("erofs: rename lz4_0pading to zero_padding") eaa9172ad988 ("erofs: get rid of ->lru usage") 622ceaddb764 ("erofs: lzma compression support") 966edfb0a3dc ("erofs: rename some generic methods in decompressor") 386292919c25 ("erofs: introduce readmore decompression strategy") 8f89926290c4 ("erofs: get compression algorithms directly on mapping") dfeab2e95a75 ("erofs: add multiple device support") e62424651f43 ("erofs: decouple basic mount options from fs_context") 5b6e7e120e71 ("erofs: remove the fast path of per-CPU buffer decompression") 2e5fd489a4e5 ("Merge tag 'libnvdimm-for-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 3c12466b6b7bf1e56f9b32c366a3d83d87afb4de Mon Sep 17 00:00:00 2001 From: Gao Xiang <xiang(a)kernel.org> Date: Wed, 6 Dec 2023 12:55:34 +0800 Subject: [PATCH] erofs: fix lz4 inplace decompression Currently EROFS can map another compressed buffer for inplace decompression, that was used to handle the cases that some pages of compressed data are actually not in-place I/O. However, like most simple LZ77 algorithms, LZ4 expects the compressed data is arranged at the end of the decompressed buffer and it explicitly uses memmove() to handle overlapping: __________________________________________________________ |_ direction of decompression --> ____ |_ compressed data _| Although EROFS arranges compressed data like this, it typically maps two individual virtual buffers so the relative order is uncertain. Previously, it was hardly observed since LZ4 only uses memmove() for short overlapped literals and x86/arm64 memmove implementations seem to completely cover it up and they don't have this issue. Juhyung reported that EROFS data corruption can be found on a new Intel x86 processor. After some analysis, it seems that recent x86 processors with the new FSRM feature expose this issue with "rep movsb". Let's strictly use the decompressed buffer for lz4 inplace decompression for now. Later, as an useful improvement, we could try to tie up these two buffers together in the correct order. Reported-and-tested-by: Juhyung Park <qkrwngud825(a)gmail.com> Closes: https://lore.kernel.org/r/CAD14+f2AVKf8Fa2OO1aAUdDNTDsVzzR6ctU_oJSmTyd6zSYR… Fixes: 0ffd71bcc3a0 ("staging: erofs: introduce LZ4 decompression inplace") Fixes: 598162d05080 ("erofs: support decompress big pcluster for lz4 backend") Cc: stable <stable(a)vger.kernel.org> # 5.4+ Tested-by: Yifan Zhao <zhaoyifan(a)sjtu.edu.cn> Signed-off-by: Gao Xiang <hsiangkao(a)linux.alibaba.com> Link: https://lore.kernel.org/r/20231206045534.3920847-1-hsiangkao@linux.alibaba.… diff --git a/fs/erofs/decompressor.c b/fs/erofs/decompressor.c index 021be5feb1bc..e0d609c3958f 100644 --- a/fs/erofs/decompressor.c +++ b/fs/erofs/decompressor.c @@ -121,11 +121,11 @@ static int z_erofs_lz4_prepare_dstpages(struct z_erofs_lz4_decompress_ctx *ctx, } static void *z_erofs_lz4_handle_overlap(struct z_erofs_lz4_decompress_ctx *ctx, - void *inpage, unsigned int *inputmargin, int *maptype, - bool may_inplace) + void *inpage, void *out, unsigned int *inputmargin, + int *maptype, bool may_inplace) { struct z_erofs_decompress_req *rq = ctx->rq; - unsigned int omargin, total, i, j; + unsigned int omargin, total, i; struct page **in; void *src, *tmp; @@ -135,12 +135,13 @@ static void *z_erofs_lz4_handle_overlap(struct z_erofs_lz4_decompress_ctx *ctx, omargin < LZ4_DECOMPRESS_INPLACE_MARGIN(rq->inputsize)) goto docopy; - for (i = 0; i < ctx->inpages; ++i) { - DBG_BUGON(rq->in[i] == NULL); - for (j = 0; j < ctx->outpages - ctx->inpages + i; ++j) - if (rq->out[j] == rq->in[i]) - goto docopy; - } + for (i = 0; i < ctx->inpages; ++i) + if (rq->out[ctx->outpages - ctx->inpages + i] != + rq->in[i]) + goto docopy; + kunmap_local(inpage); + *maptype = 3; + return out + ((ctx->outpages - ctx->inpages) << PAGE_SHIFT); } if (ctx->inpages <= 1) { @@ -148,7 +149,6 @@ static void *z_erofs_lz4_handle_overlap(struct z_erofs_lz4_decompress_ctx *ctx, return inpage; } kunmap_local(inpage); - might_sleep(); src = erofs_vm_map_ram(rq->in, ctx->inpages); if (!src) return ERR_PTR(-ENOMEM); @@ -204,12 +204,12 @@ int z_erofs_fixup_insize(struct z_erofs_decompress_req *rq, const char *padbuf, } static int z_erofs_lz4_decompress_mem(struct z_erofs_lz4_decompress_ctx *ctx, - u8 *out) + u8 *dst) { struct z_erofs_decompress_req *rq = ctx->rq; bool support_0padding = false, may_inplace = false; unsigned int inputmargin; - u8 *headpage, *src; + u8 *out, *headpage, *src; int ret, maptype; DBG_BUGON(*rq->in == NULL); @@ -230,11 +230,12 @@ static int z_erofs_lz4_decompress_mem(struct z_erofs_lz4_decompress_ctx *ctx, } inputmargin = rq->pageofs_in; - src = z_erofs_lz4_handle_overlap(ctx, headpage, &inputmargin, + src = z_erofs_lz4_handle_overlap(ctx, headpage, dst, &inputmargin, &maptype, may_inplace); if (IS_ERR(src)) return PTR_ERR(src); + out = dst + rq->pageofs_out; /* legacy format could compress extra data in a pcluster. */ if (rq->partial_decoding || !support_0padding) ret = LZ4_decompress_safe_partial(src + inputmargin, out, @@ -265,7 +266,7 @@ static int z_erofs_lz4_decompress_mem(struct z_erofs_lz4_decompress_ctx *ctx, vm_unmap_ram(src, ctx->inpages); } else if (maptype == 2) { erofs_put_pcpubuf(src); - } else { + } else if (maptype != 3) { DBG_BUGON(1); return -EFAULT; } @@ -308,7 +309,7 @@ static int z_erofs_lz4_decompress(struct z_erofs_decompress_req *rq, } dstmap_out: - ret = z_erofs_lz4_decompress_mem(&ctx, dst + rq->pageofs_out); + ret = z_erofs_lz4_decompress_mem(&ctx, dst); if (!dst_maptype) kunmap_local(dst); else if (dst_maptype == 2)

2 months, 1 week

3
2
0 0

[PATCH v2] kbuild: tools: drop overridden CFLAGS from MAKEOVERRIDES

by Max Filippov

Some Makefiles under tools/ use the 'override CFLAGS += ...' construct to add a few required options to CFLAGS passed by the user. Unfortunately that only works when user passes CFLAGS as an environment variable, i.e. CFLAGS=... make ... and not in case when CFLAGS are passed as make command line arguments: make ... CFLAGS=... It happens because in the latter case CFLAGS=... is recorded in the make variable MAKEOVERRIDES and this variable is passed in its original form to all $(MAKE) subcommands, taking precedence over modified CFLAGS value passed in the environment variable. E.g. this causes build failure for gpio and iio tools when the build is run with user CFLAGS because of missing _GNU_SOURCE definition needed for the asprintf(). One way to fix it is by removing overridden variables from the MAKEOVERRIDES. Add macro 'drop-var-from-overrides' that removes a definition of a variable passed to it from the MAKEOVERRIDES and use it to fix CFLAGS passing for tools/gpio and tools/iio. This implementation tries to be precise in string processing and handle variables with embedded spaces and backslashes correctly. To achieve that it replaces every '\\' sequence with '\-' to make sure that every '\' in the resulting string is an escape character. It then replaces every '\ ' sequence with '\_' to turn string values with embedded spaces into single words. After filtering the overridden variable definition out of the resulting string these two transformations are reversed. Cc: stable(a)vger.kernel.org Fixes: 4ccc98a48958 ("tools gpio: Allow overriding CFLAGS") Fixes: 572974610273 ("tools iio: Override CFLAGS assignments") Signed-off-by: Max Filippov <jcmvbkbc(a)gmail.com> --- Changes v1->v2: - make drop-var-from-overrides-code work correctly with arbitrary variables, including thoses ending with '\'. tools/gpio/Makefile | 1 + tools/iio/Makefile | 1 + tools/scripts/Makefile.include | 9 +++++++++ 3 files changed, 11 insertions(+) diff --git a/tools/gpio/Makefile b/tools/gpio/Makefile index d29c9c49e251..46fc38d51639 100644 --- a/tools/gpio/Makefile +++ b/tools/gpio/Makefile @@ -24,6 +24,7 @@ ALL_PROGRAMS := $(patsubst %,$(OUTPUT)%,$(ALL_TARGETS)) all: $(ALL_PROGRAMS) export srctree OUTPUT CC LD CFLAGS +$(call drop-var-from-overrides,CFLAGS) include $(srctree)/tools/build/Makefile.include # diff --git a/tools/iio/Makefile b/tools/iio/Makefile index fa720f062229..04307588dd3f 100644 --- a/tools/iio/Makefile +++ b/tools/iio/Makefile @@ -20,6 +20,7 @@ ALL_PROGRAMS := $(patsubst %,$(OUTPUT)%,$(ALL_TARGETS)) all: $(ALL_PROGRAMS) export srctree OUTPUT CC LD CFLAGS +$(call drop-var-from-overrides,CFLAGS) include $(srctree)/tools/build/Makefile.include # diff --git a/tools/scripts/Makefile.include b/tools/scripts/Makefile.include index 6fba29f3222d..0f68b95cf55c 100644 --- a/tools/scripts/Makefile.include +++ b/tools/scripts/Makefile.include @@ -51,6 +51,15 @@ define allow-override $(eval $(1) = $(2))) endef +# When a Makefile overrides a variable and exports it for the nested $(MAKE) +# invocations to use its modified value, it must remove that variable definition +# from the MAKEOVERRIDES variable, otherwise the original definition from the +# MAKEOVERRIDES takes precedence over the exported value. +drop-var-from-overrides = $(eval $(drop-var-from-overrides-code)) +define drop-var-from-overrides-code +MAKEOVERRIDES := $(subst \-,\\,$(subst \_,\ ,$(filter-out $(1)=%,$(subst \ ,\_,$(subst \\,\-,$(MAKEOVERRIDES)))))) +endef + ifneq ($(LLVM),) ifneq ($(filter %/,$(LLVM)),) LLVM_PREFIX := $(LLVM) -- 2.39.2

2 months, 1 week

2
2
0 0

FAILED: patch "[PATCH] erofs: fix lz4 inplace decompression" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 3c12466b6b7bf1e56f9b32c366a3d83d87afb4de # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024012648-backwater-colt-7290@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 3c12466b6b7b ("erofs: fix lz4 inplace decompression") 123ec246ebe3 ("erofs: get rid of the remaining kmap_atomic()") ab749badf9f4 ("erofs: support unaligned data decompression") 10e5f6e482e1 ("erofs: introduce z_erofs_fixup_insize") d67aee76d418 ("erofs: tidy up z_erofs_lz4_decompress") 7e508f2ca8bb ("erofs: rename lz4_0pading to zero_padding") eaa9172ad988 ("erofs: get rid of ->lru usage") 622ceaddb764 ("erofs: lzma compression support") 966edfb0a3dc ("erofs: rename some generic methods in decompressor") 386292919c25 ("erofs: introduce readmore decompression strategy") 8f89926290c4 ("erofs: get compression algorithms directly on mapping") dfeab2e95a75 ("erofs: add multiple device support") e62424651f43 ("erofs: decouple basic mount options from fs_context") 5b6e7e120e71 ("erofs: remove the fast path of per-CPU buffer decompression") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 3c12466b6b7bf1e56f9b32c366a3d83d87afb4de Mon Sep 17 00:00:00 2001 From: Gao Xiang <xiang(a)kernel.org> Date: Wed, 6 Dec 2023 12:55:34 +0800 Subject: [PATCH] erofs: fix lz4 inplace decompression Currently EROFS can map another compressed buffer for inplace decompression, that was used to handle the cases that some pages of compressed data are actually not in-place I/O. However, like most simple LZ77 algorithms, LZ4 expects the compressed data is arranged at the end of the decompressed buffer and it explicitly uses memmove() to handle overlapping: __________________________________________________________ |_ direction of decompression --> ____ |_ compressed data _| Although EROFS arranges compressed data like this, it typically maps two individual virtual buffers so the relative order is uncertain. Previously, it was hardly observed since LZ4 only uses memmove() for short overlapped literals and x86/arm64 memmove implementations seem to completely cover it up and they don't have this issue. Juhyung reported that EROFS data corruption can be found on a new Intel x86 processor. After some analysis, it seems that recent x86 processors with the new FSRM feature expose this issue with "rep movsb". Let's strictly use the decompressed buffer for lz4 inplace decompression for now. Later, as an useful improvement, we could try to tie up these two buffers together in the correct order. Reported-and-tested-by: Juhyung Park <qkrwngud825(a)gmail.com> Closes: https://lore.kernel.org/r/CAD14+f2AVKf8Fa2OO1aAUdDNTDsVzzR6ctU_oJSmTyd6zSYR… Fixes: 0ffd71bcc3a0 ("staging: erofs: introduce LZ4 decompression inplace") Fixes: 598162d05080 ("erofs: support decompress big pcluster for lz4 backend") Cc: stable <stable(a)vger.kernel.org> # 5.4+ Tested-by: Yifan Zhao <zhaoyifan(a)sjtu.edu.cn> Signed-off-by: Gao Xiang <hsiangkao(a)linux.alibaba.com> Link: https://lore.kernel.org/r/20231206045534.3920847-1-hsiangkao@linux.alibaba.… diff --git a/fs/erofs/decompressor.c b/fs/erofs/decompressor.c index 021be5feb1bc..e0d609c3958f 100644 --- a/fs/erofs/decompressor.c +++ b/fs/erofs/decompressor.c @@ -121,11 +121,11 @@ static int z_erofs_lz4_prepare_dstpages(struct z_erofs_lz4_decompress_ctx *ctx, } static void *z_erofs_lz4_handle_overlap(struct z_erofs_lz4_decompress_ctx *ctx, - void *inpage, unsigned int *inputmargin, int *maptype, - bool may_inplace) + void *inpage, void *out, unsigned int *inputmargin, + int *maptype, bool may_inplace) { struct z_erofs_decompress_req *rq = ctx->rq; - unsigned int omargin, total, i, j; + unsigned int omargin, total, i; struct page **in; void *src, *tmp; @@ -135,12 +135,13 @@ static void *z_erofs_lz4_handle_overlap(struct z_erofs_lz4_decompress_ctx *ctx, omargin < LZ4_DECOMPRESS_INPLACE_MARGIN(rq->inputsize)) goto docopy; - for (i = 0; i < ctx->inpages; ++i) { - DBG_BUGON(rq->in[i] == NULL); - for (j = 0; j < ctx->outpages - ctx->inpages + i; ++j) - if (rq->out[j] == rq->in[i]) - goto docopy; - } + for (i = 0; i < ctx->inpages; ++i) + if (rq->out[ctx->outpages - ctx->inpages + i] != + rq->in[i]) + goto docopy; + kunmap_local(inpage); + *maptype = 3; + return out + ((ctx->outpages - ctx->inpages) << PAGE_SHIFT); } if (ctx->inpages <= 1) { @@ -148,7 +149,6 @@ static void *z_erofs_lz4_handle_overlap(struct z_erofs_lz4_decompress_ctx *ctx, return inpage; } kunmap_local(inpage); - might_sleep(); src = erofs_vm_map_ram(rq->in, ctx->inpages); if (!src) return ERR_PTR(-ENOMEM); @@ -204,12 +204,12 @@ int z_erofs_fixup_insize(struct z_erofs_decompress_req *rq, const char *padbuf, } static int z_erofs_lz4_decompress_mem(struct z_erofs_lz4_decompress_ctx *ctx, - u8 *out) + u8 *dst) { struct z_erofs_decompress_req *rq = ctx->rq; bool support_0padding = false, may_inplace = false; unsigned int inputmargin; - u8 *headpage, *src; + u8 *out, *headpage, *src; int ret, maptype; DBG_BUGON(*rq->in == NULL); @@ -230,11 +230,12 @@ static int z_erofs_lz4_decompress_mem(struct z_erofs_lz4_decompress_ctx *ctx, } inputmargin = rq->pageofs_in; - src = z_erofs_lz4_handle_overlap(ctx, headpage, &inputmargin, + src = z_erofs_lz4_handle_overlap(ctx, headpage, dst, &inputmargin, &maptype, may_inplace); if (IS_ERR(src)) return PTR_ERR(src); + out = dst + rq->pageofs_out; /* legacy format could compress extra data in a pcluster. */ if (rq->partial_decoding || !support_0padding) ret = LZ4_decompress_safe_partial(src + inputmargin, out, @@ -265,7 +266,7 @@ static int z_erofs_lz4_decompress_mem(struct z_erofs_lz4_decompress_ctx *ctx, vm_unmap_ram(src, ctx->inpages); } else if (maptype == 2) { erofs_put_pcpubuf(src); - } else { + } else if (maptype != 3) { DBG_BUGON(1); return -EFAULT; } @@ -308,7 +309,7 @@ static int z_erofs_lz4_decompress(struct z_erofs_decompress_req *rq, } dstmap_out: - ret = z_erofs_lz4_decompress_mem(&ctx, dst + rq->pageofs_out); + ret = z_erofs_lz4_decompress_mem(&ctx, dst); if (!dst_maptype) kunmap_local(dst); else if (dst_maptype == 2)

2 months, 2 weeks

2
2
0 0

[PATCH 4/7] ext4: add positive int attr pointer to avoid sysfs variables overflow

by Baokun Li

We can easily trigger a BUG_ON by using the following commands: mount /dev/$disk /tmp/test echo 2147483650 > /sys/fs/ext4/$disk/mb_group_prealloc echo test > /tmp/test/file && sync ================================================================== kernel BUG at fs/ext4/mballoc.c:2029! invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 3 PID: 320 Comm: kworker/u36:1 Not tainted 6.8.0-rc1 #462 RIP: 0010:mb_mark_used+0x358/0x370 [...] Call Trace: ext4_mb_use_best_found+0x56/0x140 ext4_mb_complex_scan_group+0x196/0x2f0 ext4_mb_regular_allocator+0xa92/0xf00 ext4_mb_new_blocks+0x302/0xbc0 ext4_ext_map_blocks+0x95a/0xef0 ext4_map_blocks+0x2b1/0x680 ext4_do_writepages+0x733/0xbd0 [...] ================================================================== In ext4_mb_normalize_group_request(): ac->ac_g_ex.fe_len = EXT4_SB(sb)->s_mb_group_prealloc; Here fe_len is of type int, but s_mb_group_prealloc is of type unsigned int, so setting s_mb_group_prealloc to 2147483650 overflows fe_len to a negative number, which ultimately triggers a BUG_ON() in mb_mark_used(). Therefore, we add attr_pointer_pi (aka positive int attr pointer) with a value range of 0-INT_MAX to avoid the above problem. In addition to the mb_group_prealloc sysfs interface, the following interfaces also have uint to int conversions that result in overflows, and are also fixed. err_ratelimit_burst msg_ratelimit_burst warning_ratelimit_burst err_ratelimit_interval_ms msg_ratelimit_interval_ms warning_ratelimit_interval_ms mb_best_avail_max_trim_order CC: stable(a)vger.kernel.org Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/ext4/sysfs.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/fs/ext4/sysfs.c b/fs/ext4/sysfs.c index a5d657fa05cb..6f9f96e00f2f 100644 --- a/fs/ext4/sysfs.c +++ b/fs/ext4/sysfs.c @@ -30,6 +30,7 @@ typedef enum { attr_first_error_time, attr_last_error_time, attr_feature, + attr_pointer_pi, attr_pointer_ui, attr_pointer_ul, attr_pointer_u64, @@ -178,6 +179,9 @@ static struct ext4_attr ext4_attr_##_name = { \ #define EXT4_RO_ATTR_ES_STRING(_name,_elname,_size) \ EXT4_ATTR_STRING(_name, 0444, _size, ext4_super_block, _elname) +#define EXT4_RW_ATTR_SBI_PI(_name,_elname) \ + EXT4_ATTR_OFFSET(_name, 0644, pointer_pi, ext4_sb_info, _elname) + #define EXT4_RW_ATTR_SBI_UI(_name,_elname) \ EXT4_ATTR_OFFSET(_name, 0644, pointer_ui, ext4_sb_info, _elname) @@ -213,17 +217,17 @@ EXT4_RW_ATTR_SBI_UI(mb_max_to_scan, s_mb_max_to_scan); EXT4_RW_ATTR_SBI_UI(mb_min_to_scan, s_mb_min_to_scan); EXT4_RW_ATTR_SBI_UI(mb_order2_req, s_mb_order2_reqs); EXT4_RW_ATTR_SBI_UI(mb_stream_req, s_mb_stream_request); -EXT4_RW_ATTR_SBI_UI(mb_group_prealloc, s_mb_group_prealloc); +EXT4_RW_ATTR_SBI_PI(mb_group_prealloc, s_mb_group_prealloc); EXT4_RW_ATTR_SBI_UI(mb_max_linear_groups, s_mb_max_linear_groups); EXT4_RW_ATTR_SBI_UI(extent_max_zeroout_kb, s_extent_max_zeroout_kb); EXT4_ATTR(trigger_fs_error, 0200, trigger_test_error); -EXT4_RW_ATTR_SBI_UI(err_ratelimit_interval_ms, s_err_ratelimit_state.interval); -EXT4_RW_ATTR_SBI_UI(err_ratelimit_burst, s_err_ratelimit_state.burst); -EXT4_RW_ATTR_SBI_UI(warning_ratelimit_interval_ms, s_warning_ratelimit_state.interval); -EXT4_RW_ATTR_SBI_UI(warning_ratelimit_burst, s_warning_ratelimit_state.burst); -EXT4_RW_ATTR_SBI_UI(msg_ratelimit_interval_ms, s_msg_ratelimit_state.interval); -EXT4_RW_ATTR_SBI_UI(msg_ratelimit_burst, s_msg_ratelimit_state.burst); -EXT4_RW_ATTR_SBI_UI(mb_best_avail_max_trim_order, s_mb_best_avail_max_trim_order); +EXT4_RW_ATTR_SBI_PI(err_ratelimit_interval_ms, s_err_ratelimit_state.interval); +EXT4_RW_ATTR_SBI_PI(err_ratelimit_burst, s_err_ratelimit_state.burst); +EXT4_RW_ATTR_SBI_PI(warning_ratelimit_interval_ms, s_warning_ratelimit_state.interval); +EXT4_RW_ATTR_SBI_PI(warning_ratelimit_burst, s_warning_ratelimit_state.burst); +EXT4_RW_ATTR_SBI_PI(msg_ratelimit_interval_ms, s_msg_ratelimit_state.interval); +EXT4_RW_ATTR_SBI_PI(msg_ratelimit_burst, s_msg_ratelimit_state.burst); +EXT4_RW_ATTR_SBI_PI(mb_best_avail_max_trim_order, s_mb_best_avail_max_trim_order); #ifdef CONFIG_EXT4_DEBUG EXT4_RW_ATTR_SBI_UL(simulate_fail, s_simulate_fail); #endif @@ -376,6 +380,7 @@ static ssize_t ext4_generic_attr_show(struct ext4_attr *a, switch (a->attr_id) { case attr_inode_readahead: + case attr_pointer_pi: case attr_pointer_ui: if (a->attr_ptr == ptr_ext4_super_block_offset) return sysfs_emit(buf, "%u\n", le32_to_cpup(ptr)); @@ -448,6 +453,10 @@ static ssize_t ext4_generic_attr_store(struct ext4_attr *a, return ret; switch (a->attr_id) { + case attr_pointer_pi: + if ((int)t < 0) + return -EINVAL; + fallthrough; case attr_pointer_ui: if (t != (unsigned int)t) return -EINVAL; -- 2.31.1

2 months, 2 weeks

3
5
0 0

fs/bcachefs/

by Kent Overstreet

Hi stable team - please don't take patches for fs/bcachefs/ except from myself; I'll be doing backports and sending pull requests after stuff has been tested by my CI. Thanks, and let me know if there's any other workflow things I should know about -Kent

2 months, 2 weeks

6
30
0 0

[REGRESSION 6.1.70] system calls with CIFS mounts failing with "Resource temporarily unavailable"

by Leonardo Brondani Schenkel

I'm new here, first time reporting a regression, apologies in advance if I'm doing something wrong of if this was already reported (I found some CIFS issues but not exactly this one). I'm using x86-64 Arch Linux and LTS kernel (6.1.71 as I write this) and I noticed a regression that I could reproduce in other boxes with other architectures as well (aarch64 with 6.1.70). # mount.cifs //server/share /mnt # mount //server/share on /mnt type cifs (rw,relatime,vers=3.1.1...) # cd /mnt # df . df: .: Resource temporarily unavailable # ls -al ls: .: Resource temporarily unavailable ls: file1: Resource temporarily unavailable ls: file2: Resource temporarily unavailable [...then ls shows the listing...] If I use strace with df, the problem is: statfs(".", 0x.....) = -1 EAGAIN (Resource temporarily unavailable) And with ls: listxattr(".", 0x..., 152): -1 EAGAIN (Resource temporarily unavailable) listxattr("file1", ..., 152): -1 EAGAIN (same as above) ... Initially I thought the problem was with the Samba server and/or the client mount flags, but I've spent a day trying a *lot* of different combinations and nothing worked. This happens with any share that I try, and I've tried mounting shares from multiple Linux boxes running different Samba and kernel versions. Then I tried changing kernel versions at my client box. I booted latest 6.6.9 and the problem simply disappeared. My Debian server with 6.5.11 also doesn't have it. I then started a VM and tried a "bisection" of 6.1.x versions, leading to kernel 6.1.70 when this started to happen. 6.1.69 and older look fine. I hope that this is enough information to reproduce this issue. I will be glad to provide more info if necessary. // Leonardo.

2 months, 2 weeks

6
14
0 0

[PATCH AUTOSEL 6.1 01/27] PCI: Only override AMD USB controller if required

by Sasha Levin

From: "Guilherme G. Piccoli" <gpiccoli(a)igalia.com> [ Upstream commit e585a37e5061f6d5060517aed1ca4ccb2e56a34c ] By running a Van Gogh device (Steam Deck), the following message was noticed in the kernel log: pci 0000:04:00.3: PCI class overridden (0x0c03fe -> 0x0c03fe) so dwc3 driver can claim this instead of xhci Effectively this means the quirk executed but changed nothing, since the class of this device was already the proper one (likely adjusted by newer firmware versions). Check and perform the override only if necessary. Link: https://lore.kernel.org/r/20231120160531.361552-1-gpiccoli@igalia.com Signed-off-by: Guilherme G. Piccoli <gpiccoli(a)igalia.com> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Cc: Huang Rui <ray.huang(a)amd.com> Cc: Vicki Pfau <vi(a)endrift.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/pci/quirks.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 8765544bac35..75b297c15cf5 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -607,10 +607,13 @@ static void quirk_amd_dwc_class(struct pci_dev *pdev) { u32 class = pdev->class; - /* Use "USB Device (not host controller)" class */ - pdev->class = PCI_CLASS_SERIAL_USB_DEVICE; - pci_info(pdev, "PCI class overridden (%#08x -> %#08x) so dwc3 driver can claim this instead of xhci\n", - class, pdev->class); + if (class != PCI_CLASS_SERIAL_USB_DEVICE) { + /* Use "USB Device (not host controller)" class */ + pdev->class = PCI_CLASS_SERIAL_USB_DEVICE; + pci_info(pdev, + "PCI class overridden (%#08x -> %#08x) so dwc3 driver can claim this instead of xhci\n", + class, pdev->class); + } } DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_NL_USB, quirk_amd_dwc_class); -- 2.43.0

2 months, 2 weeks

2
28
0 0

[PATCH 0/2] RISC-V: Fix CONFIG_AS_HAS_OPTION_ARCH with tip of tree LLVM

by Nathan Chancellor

Hi all, Eric reported that builds of LLVM with [1] (close to tip of tree) have CONFIG_AS_HAS_OPTION_ARCH=n because the test for expected failure on invalid input has started succeeding. This Kconfig test was added because '.option arch' only causes an assembler warning when it is unsupported, rather than a hard error, which is what users of as-instr expect when something is unsupported. This can be resolved by turning assembler warnings into errors with '-Wa,--fatal-warnings' like we do with the compiler with '-Werror', which is what the first patch does. The second patch removes the invalid test, as the valid test is good enough with fatal warnings. I have diffed several configurations for the different architectures that use as-instr and I have found no issues. I think this could go in through either the kbuild or RISC-V tree with sufficient acks but I will let them fight over who takes it :) [1]: https://github.com/llvm/llvm-project/commit/3ac9fe69f70a2b3541266daedbaaa7d… --- Nathan Chancellor (2): kbuild: Add -Wa,--fatal-warnings to as-instr invocation RISC-V: Drop invalid test from CONFIG_AS_HAS_OPTION_ARCH arch/riscv/Kconfig | 1 - scripts/Kconfig.include | 2 +- scripts/Makefile.compiler | 2 +- 3 files changed, 2 insertions(+), 3 deletions(-) --- base-commit: 6613476e225e090cc9aad49be7fa504e290dd33d change-id: 20240124-fix-riscv-option-arch-llvm-18-3cbe7b09a216 Best regards, -- Nathan Chancellor <nathan(a)kernel.org>

2 months, 2 weeks

6
7
0 0

[PATCH 4/4] mtd: rawnand: Clarify conditions to enable continuous reads

by Miquel Raynal

The current logic is probably fine but is a bit convoluted. Plus, we don't want partial pages to be part of the sequential operation just in case the core would optimize the page read with a subpage read (which would break the sequence). This may happen on the first and last page only, so if the start offset or the end offset is not aligned with a page boundary, better avoid them to prevent any risk. Cc: stable(a)vger.kernel.org Fixes: 003fe4b9545b ("mtd: rawnand: Support for sequential cache reads") Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> --- drivers/mtd/nand/raw/nand_base.c | 26 +++++++++++++++++--------- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c index 139fdf3e58c0..bbdcfbe643f3 100644 --- a/drivers/mtd/nand/raw/nand_base.c +++ b/drivers/mtd/nand/raw/nand_base.c @@ -3460,21 +3460,29 @@ static void rawnand_enable_cont_reads(struct nand_chip *chip, unsigned int page, u32 readlen, int col) { struct mtd_info *mtd = nand_to_mtd(chip); + unsigned int end_page, end_col; + + chip->cont_read.ongoing = false; if (!chip->controller->supported_op.cont_read) return; - if ((col && col + readlen < (3 * mtd->writesize)) || - (!col && readlen < (2 * mtd->writesize))) { - chip->cont_read.ongoing = false; - return; - } + end_page = DIV_ROUND_UP(col + readlen, mtd->writesize); + end_col = (col + readlen) % mtd->writesize; - chip->cont_read.ongoing = true; - chip->cont_read.first_page = page; if (col) - chip->cont_read.first_page++; - chip->cont_read.last_page = page + ((readlen >> chip->page_shift) & chip->pagemask); + page++; + + if (end_col && end_page) + end_page--; + + if (page + 1 > end_page) + return; + + chip->cont_read.first_page = page; + chip->cont_read.last_page = end_page; + chip->cont_read.ongoing = true; + rawnand_cap_cont_reads(chip); } -- 2.34.1

2 months, 2 weeks

2
6
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2024