September 2024 - Linux-stable-mirror

[PATCH 0/3] Backport statx(..., NULL, AT_EMPTY_PATH, ...)

by Miao Wang via B4 Relay

Commit 0ef625bba6fb ("vfs: support statx(..., NULL, AT_EMPTY_PATH, ...)") added support for passing in NULL when AT_EMPTY_PATH is given, improving performance when statx is used for fetching stat informantion from a given fd, which is especially important for 32-bit platforms. This commit also improved the performance when an empty string is given by short-circuiting the handling of such paths. This series is based on the commits in the Linus’ tree. Sligth modifications are applied to the context of the patches for cleanly applying. Tested-by: Xi Ruoyao <xry111(a)xry111.site> Signed-off-by: Miao Wang <shankerwangmiao(a)gmail.com> --- Christian Brauner (2): fs: new helper vfs_empty_path() stat: use vfs_empty_path() helper Mateusz Guzik (1): vfs: support statx(..., NULL, AT_EMPTY_PATH, ...) fs/internal.h | 14 ++++++ fs/namespace.c | 13 ------ fs/stat.c | 123 ++++++++++++++++++++++++++++++++++++----------------- include/linux/fs.h | 17 ++++++++ 4 files changed, 116 insertions(+), 51 deletions(-) --- base-commit: 049be94099ea5ba8338526c5a4f4f404b9dcaf54 change-id: 20240918-statx-stable-linux-6-10-y-17c3ec7497c8 Best regards, -- Miao Wang <shankerwangmiao(a)gmail.com>

16 minutes

4
7
0 0

[PATCH v4 2/2] ufs: core: requeue aborted request

by peter.wang＠mediatek.com

From: Peter Wang <peter.wang(a)mediatek.com> ufshcd_abort_all froce abort all on-going command and the host will automatically fill in the OCS field of the corresponding response with OCS_ABORTED based on different working modes. MCQ mode: aborts a command using SQ cleanup, The host controller will post a Completion Queue entry with OCS = ABORTED. SDB mode: aborts a command using UTRLCLR. Task Management response which means a Transfer Request was aborted. For these two cases, set a flag to notify SCSI to requeue the command after receiving response with OCS_ABORTED. Fixes: ab248643d3d6 ("scsi: ufs: core: Add error handling for MCQ mode") Cc: stable(a)vger.kernel.org Signed-off-by: Peter Wang <peter.wang(a)mediatek.com> --- drivers/ufs/core/ufshcd.c | 34 +++++++++++++++++++--------------- include/ufs/ufshcd.h | 3 +++ 2 files changed, 22 insertions(+), 15 deletions(-) diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c index a6f818cdef0e..615da47c1727 100644 --- a/drivers/ufs/core/ufshcd.c +++ b/drivers/ufs/core/ufshcd.c @@ -3006,6 +3006,7 @@ static int ufshcd_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *cmd) ufshcd_prepare_lrbp_crypto(scsi_cmd_to_rq(cmd), lrbp); lrbp->req_abort_skip = false; + lrbp->abort_initiated_by_err = false; ufshcd_comp_scsi_upiu(hba, lrbp); @@ -5404,7 +5405,10 @@ ufshcd_transfer_rsp_status(struct ufs_hba *hba, struct ufshcd_lrb *lrbp, } break; case OCS_ABORTED: - result |= DID_ABORT << 16; + if (lrbp->abort_initiated_by_err) + result |= DID_REQUEUE << 16; + else + result |= DID_ABORT << 16; break; case OCS_INVALID_COMMAND_STATUS: result |= DID_REQUEUE << 16; @@ -6471,26 +6475,12 @@ static bool ufshcd_abort_one(struct request *rq, void *priv) struct scsi_device *sdev = cmd->device; struct Scsi_Host *shost = sdev->host; struct ufs_hba *hba = shost_priv(shost); - struct ufshcd_lrb *lrbp = &hba->lrb[tag]; - struct ufs_hw_queue *hwq; - unsigned long flags; *ret = ufshcd_try_to_abort_task(hba, tag); dev_err(hba->dev, "Aborting tag %d / CDB %#02x %s\n", tag, hba->lrb[tag].cmd ? hba->lrb[tag].cmd->cmnd[0] : -1, *ret ? "failed" : "succeeded"); - /* Release cmd in MCQ mode if abort succeeds */ - if (hba->mcq_enabled && (*ret == 0)) { - hwq = ufshcd_mcq_req_to_hwq(hba, scsi_cmd_to_rq(lrbp->cmd)); - if (!hwq) - return 0; - spin_lock_irqsave(&hwq->cq_lock, flags); - if (ufshcd_cmd_inflight(lrbp->cmd)) - ufshcd_release_scsi_cmd(hba, lrbp); - spin_unlock_irqrestore(&hwq->cq_lock, flags); - } - return *ret == 0; } @@ -7561,6 +7551,20 @@ int ufshcd_try_to_abort_task(struct ufs_hba *hba, int tag) goto out; } + /* + * When the host software receives a "FUNCTION COMPLETE", set flag + * to requeue command after receive response with OCS_ABORTED + * SDB mode: UTRLCLR Task Management response which means a Transfer + * Request was aborted. + * MCQ mode: Host will post to CQ with OCS_ABORTED after SQ cleanup + * This flag is set because ufshcd_abort_all forcibly aborts all + * commands, and the host will automatically fill in the OCS field + * of the corresponding response with OCS_ABORTED. + * Therefore, upon receiving this response, it needs to be requeued. + */ + if (!err) + lrbp->abort_initiated_by_err = true; + err = ufshcd_clear_cmd(hba, tag); if (err) dev_err(hba->dev, "%s: Failed clearing cmd at tag %d, err %d\n", diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h index 0fd2aebac728..15b357672ca5 100644 --- a/include/ufs/ufshcd.h +++ b/include/ufs/ufshcd.h @@ -173,6 +173,8 @@ struct ufs_pm_lvl_states { * @crypto_key_slot: the key slot to use for inline crypto (-1 if none) * @data_unit_num: the data unit number for the first block for inline crypto * @req_abort_skip: skip request abort task flag + * @abort_initiated_by_err: The flag is specifically used to handle aborts + * caused by errors due to host/device communication */ struct ufshcd_lrb { struct utp_transfer_req_desc *utr_descriptor_ptr; @@ -202,6 +204,7 @@ struct ufshcd_lrb { #endif bool req_abort_skip; + bool abort_initiated_by_err; }; /** -- 2.45.2

17 minutes

3
12
0 0

[PATCH v3] crypto: Removing CRYPTO_AES_GCM_P10.

by Danny Tsen

Data mismatch found when testing ipsec tunnel with AES/GCM crypto. Disabling CRYPTO_AES_GCM_P10 in Kconfig for this feature. Fixes: fd0e9b3e2ee6 ("crypto: p10-aes-gcm - An accelerated AES/GCM stitched implementation") Fixes: cdcecfd9991f ("crypto: p10-aes-gcm - Glue code for AES/GCM stitched implementation") Fixes: 45a4672b9a6e2 ("crypto: p10-aes-gcm - Update Kconfig and Makefile") Signed-off-by: Danny Tsen <dtsen(a)linux.ibm.com> --- arch/powerpc/crypto/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/crypto/Kconfig b/arch/powerpc/crypto/Kconfig index 09ebcbdfb34f..46a4c85e85e2 100644 --- a/arch/powerpc/crypto/Kconfig +++ b/arch/powerpc/crypto/Kconfig @@ -107,6 +107,7 @@ config CRYPTO_AES_PPC_SPE config CRYPTO_AES_GCM_P10 tristate "Stitched AES/GCM acceleration support on P10 or later CPU (PPC)" + depends on BROKEN depends on PPC64 && CPU_LITTLE_ENDIAN && VSX select CRYPTO_LIB_AES select CRYPTO_ALGAPI -- 2.43.0

47 minutes

2
1
0 0

[STABLE REGRESSION] Possible missing backport of x86_match_cpu() change in v6.1.96

by Thomas Lindroth

I upgraded from kernel 6.1.94 to 6.1.99 on one of my machines and noticed that the dmesg line "Incomplete global flushes, disabling PCID" had disappeared from the log. That message comes from commit c26b9e193172f48cd0ccc64285337106fb8aa804, which disables PCID support on some broken hardware in arch/x86/mm/init.c: #define INTEL_MATCH(_model) { .vendor = X86_VENDOR_INTEL, \ .family = 6, \ .model = _model, \ } /* * INVLPG may not properly flush Global entries * on these CPUs when PCIDs are enabled. */ static const struct x86_cpu_id invlpg_miss_ids[] = { INTEL_MATCH(INTEL_FAM6_ALDERLAKE ), INTEL_MATCH(INTEL_FAM6_ALDERLAKE_L ), INTEL_MATCH(INTEL_FAM6_ALDERLAKE_N ), INTEL_MATCH(INTEL_FAM6_RAPTORLAKE ), INTEL_MATCH(INTEL_FAM6_RAPTORLAKE_P), INTEL_MATCH(INTEL_FAM6_RAPTORLAKE_S), {} ... if (x86_match_cpu(invlpg_miss_ids)) { pr_info("Incomplete global flushes, disabling PCID"); setup_clear_cpu_cap(X86_FEATURE_PCID); return; } arch/x86/mm/init.c, which has that code, hasn't changed in 6.1.94 -> 6.1.99. However I found a commit changing how x86_match_cpu() behaves in 6.1.96: commit 8ab1361b2eae44077fef4adea16228d44ffb860c Author: Tony Luck <tony.luck(a)intel.com> Date: Mon May 20 15:45:33 2024 -0700 x86/cpu: Fix x86_match_cpu() to match just X86_VENDOR_INTEL I suspect this broke the PCID disabling code in arch/x86/mm/init.c. The commit message says: "Add a new flags field to struct x86_cpu_id that has a bit set to indicate that this entry in the array is valid. Update X86_MATCH*() macros to set that bit. Change the end-marker check in x86_match_cpu() to just check the flags field for this bit." But the PCID disabling code in 6.1.99 does not make use of the X86_MATCH*() macros; instead, it defines a new INTEL_MATCH() macro without the X86_CPU_ID_FLAG_ENTRY_VALID flag. I looked in upstream git and found an existing fix: commit 2eda374e883ad297bd9fe575a16c1dc850346075 Author: Tony Luck <tony.luck(a)intel.com> Date: Wed Apr 24 11:15:18 2024 -0700 x86/mm: Switch to new Intel CPU model defines New CPU #defines encode vendor and family as well as model. [ dhansen: vertically align 0's in invlpg_miss_ids[] ] Signed-off-by: Tony Luck <tony.luck(a)intel.com> Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Link: https://lore.kernel.org/all/20240424181518.41946-1-tony.luck%40intel.com diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c index 679893ea5e68..6b43b6480354 100644 --- a/arch/x86/mm/init.c +++ b/arch/x86/mm/init.c @@ -261,21 +261,17 @@ static void __init probe_page_size_mask(void) } } -#define INTEL_MATCH(_model) { .vendor = X86_VENDOR_INTEL, \ - .family = 6, \ - .model = _model, \ - } /* * INVLPG may not properly flush Global entries * on these CPUs when PCIDs are enabled. */ static const struct x86_cpu_id invlpg_miss_ids[] = { - INTEL_MATCH(INTEL_FAM6_ALDERLAKE ), - INTEL_MATCH(INTEL_FAM6_ALDERLAKE_L ), - INTEL_MATCH(INTEL_FAM6_ATOM_GRACEMONT ), - INTEL_MATCH(INTEL_FAM6_RAPTORLAKE ), - INTEL_MATCH(INTEL_FAM6_RAPTORLAKE_P), - INTEL_MATCH(INTEL_FAM6_RAPTORLAKE_S), + X86_MATCH_VFM(INTEL_ALDERLAKE, 0), + X86_MATCH_VFM(INTEL_ALDERLAKE_L, 0), + X86_MATCH_VFM(INTEL_ATOM_GRACEMONT, 0), + X86_MATCH_VFM(INTEL_RAPTORLAKE, 0), + X86_MATCH_VFM(INTEL_RAPTORLAKE_P, 0), + X86_MATCH_VFM(INTEL_RAPTORLAKE_S, 0), {} }; The fix removed the custom INTEL_MATCH macro and uses the X86_MATCH*() macros with X86_CPU_ID_FLAG_ENTRY_VALID. This fixed commit was never backported to 6.1, so it looks like a stable series regression due to a missing backport. If I apply the fix patch on 6.1.99, the PCID disabling code activates again. I had to change all the INTEL_* definitions to the old definitions to make it build: static const struct x86_cpu_id invlpg_miss_ids[] = { - INTEL_MATCH(INTEL_FAM6_ALDERLAKE ), - INTEL_MATCH(INTEL_FAM6_ALDERLAKE_L ), - INTEL_MATCH(INTEL_FAM6_ALDERLAKE_N ), - INTEL_MATCH(INTEL_FAM6_RAPTORLAKE ), - INTEL_MATCH(INTEL_FAM6_RAPTORLAKE_P), - INTEL_MATCH(INTEL_FAM6_RAPTORLAKE_S), + X86_MATCH_VFM(INTEL_FAM6_ALDERLAKE, 0), + X86_MATCH_VFM(INTEL_FAM6_ALDERLAKE_L, 0), + X86_MATCH_VFM(INTEL_FAM6_ALDERLAKE_N, 0), + X86_MATCH_VFM(INTEL_FAM6_RAPTORLAKE, 0), + X86_MATCH_VFM(INTEL_FAM6_RAPTORLAKE_P, 0), + X86_MATCH_VFM(INTEL_FAM6_RAPTORLAKE_S, 0), {} }; I only looked at the code in arch/x86/mm/init.c, so there may be other uses of x86_match_cpu() in the kernel that are also broken in 6.1.99. This email is meant as a bug report, not a pull request. Someone else should confirm the problem and submit the appropriate fix.

1 hour, 14 minutes

5
4
0 0

Re: [PATCH net 3/3] net: enetc: reset xdp_tx_in_flight when updating bpf program

by Subbaraya Sundeep

On 2024-09-19 at 14:11:04, Wei Fang (wei.fang(a)nxp.com) wrote: > When running "xdp-bench tx eno0" to test the XDP_TX feature of ENETC > on LS1028A, it was found that if the command was re-run multiple times, > Rx could not receive the frames, and the result of xdo-bench showed > that the rx rate was 0. > > root@ls1028ardb:~# ./xdp-bench tx eno0 > Hairpinning (XDP_TX) packets on eno0 (ifindex 3; driver fsl_enetc) > Summary 2046 rx/s 0 err,drop/s > Summary 0 rx/s 0 err,drop/s > Summary 0 rx/s 0 err,drop/s > Summary 0 rx/s 0 err,drop/s > > By observing the Rx PIR and CIR registers, we found that CIR is always > equal to 0x7FF and PIR is always 0x7FE, which means that the Rx ring > is full and can no longer accommodate other Rx frames. Therefore, it > is obvious that the RX BD ring has not been cleaned up. > > Further analysis of the code revealed that the Rx BD ring will only > be cleaned if the "cleaned_cnt > xdp_tx_in_flight" condition is met. > Therefore, some debug logs were added to the driver and the current > values of cleaned_cnt and xdp_tx_in_flight were printed when the Rx > BD ring was full. The logs are as follows. > > [ 178.762419] [XDP TX] >> cleaned_cnt:1728, xdp_tx_in_flight:2140 > [ 178.771387] [XDP TX] >> cleaned_cnt:1941, xdp_tx_in_flight:2110 > [ 178.776058] [XDP TX] >> cleaned_cnt:1792, xdp_tx_in_flight:2110 > > From the results, we can see that the maximum value of xdp_tx_in_flight > has reached 2140. However, the size of the Rx BD ring is only 2048. This > is incredible, so checked the code again and found that the driver did > not reset xdp_tx_in_flight when installing or uninstalling bpf program, > resulting in xdp_tx_in_flight still retaining the value after the last > command was run. > > Fixes: c33bfaf91c4c ("net: enetc: set up XDP program under enetc_reconfigure()") > Cc: stable(a)vger.kernel.org > Signed-off-by: Wei Fang <wei.fang(a)nxp.com> Reviewed-by: Subbaraya Sundeep <sbhatta(a)marvell.com> Thanks, Sundeep

1 hour, 21 minutes

1
0
0 0

[PATCH v2] usb: using mutex lock and supporting O_NONBLOCK flag in iowarrior_read()

by Jeongjun Park

iowarrior_read() uses the iowarrior dev structure, but does not use any lock on the structure. This can cause various bugs including data-races, so it is more appropriate to use a mutex lock to safely protect the iowarrior dev structure. When using a mutex lock, you should split the branch to prevent blocking when the O_NONBLOCK flag is set. In addition, it is unnecessary to check for NULL on the iowarrior dev structure obtained by reading file->private_data. Therefore, it is better to remove the check. Cc: stable(a)vger.kernel.org Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.") Signed-off-by: Jeongjun Park <aha310510(a)gmail.com> --- v1 -> v2: Added cc tag and change log drivers/usb/misc/iowarrior.c | 46 ++++++++++++++++++++++++++++-------- 1 file changed, 36 insertions(+), 10 deletions(-) diff --git a/drivers/usb/misc/iowarrior.c b/drivers/usb/misc/iowarrior.c index 6d28467ce352..a513766b4985 100644 --- a/drivers/usb/misc/iowarrior.c +++ b/drivers/usb/misc/iowarrior.c @@ -277,28 +277,45 @@ static ssize_t iowarrior_read(struct file *file, char __user *buffer, struct iowarrior *dev; int read_idx; int offset; + int retval; dev = file->private_data; + if (file->f_flags & O_NONBLOCK) { + retval = mutex_trylock(&dev->mutex); + if (!retval) + return -EAGAIN; + } else { + retval = mutex_lock_interruptible(&dev->mutex); + if (retval) + return -ERESTARTSYS; + } + /* verify that the device wasn't unplugged */ - if (!dev || !dev->present) - return -ENODEV; + if (!dev->present) { + retval = -ENODEV; + goto exit; + } dev_dbg(&dev->interface->dev, "minor %d, count = %zd\n", dev->minor, count); /* read count must be packet size (+ time stamp) */ if ((count != dev->report_size) - && (count != (dev->report_size + 1))) - return -EINVAL; + && (count != (dev->report_size + 1))) { + retval = -EINVAL; + goto exit; + } /* repeat until no buffer overrun in callback handler occur */ do { atomic_set(&dev->overflow_flag, 0); if ((read_idx = read_index(dev)) == -1) { /* queue empty */ - if (file->f_flags & O_NONBLOCK) - return -EAGAIN; + if (file->f_flags & O_NONBLOCK) { + retval = -EAGAIN; + goto exit; + } else { //next line will return when there is either new data, or the device is unplugged int r = wait_event_interruptible(dev->read_wait, @@ -309,28 +326,37 @@ static ssize_t iowarrior_read(struct file *file, char __user *buffer, -1)); if (r) { //we were interrupted by a signal - return -ERESTART; + retval = -ERESTART; + goto exit; } if (!dev->present) { //The device was unplugged - return -ENODEV; + retval = -ENODEV; + goto exit; } if (read_idx == -1) { // Can this happen ??? - return 0; + retval = 0; + goto exit; } } } offset = read_idx * (dev->report_size + 1); if (copy_to_user(buffer, dev->read_queue + offset, count)) { - return -EFAULT; + retval = -EFAULT; + goto exit; } } while (atomic_read(&dev->overflow_flag)); read_idx = ++read_idx == MAX_INTERRUPT_BUFFER ? 0 : read_idx; atomic_set(&dev->read_idx, read_idx); + mutex_unlock(&dev->mutex); return count; + +exit: + mutex_unlock(&dev->mutex); + return retval; } /* --

2 hours

1
0
0 0

[PATCH v1] usb: typec: Fix arg check for usb_power_delivery_unregister_capabilities

by Amit Sunil Dhamne

usb_power_delivery_register_capabilities() returns ERR_PTR in case of failure. usb_power_delivery_unregister_capabilities() we only check argument ("cap") for NULL. A more robust check would be checking for ERR_PTR as well. Cc: stable(a)vger.kernel.org Fixes: 662a60102c12 ("usb: typec: Separate USB Power Delivery from USB Type-C") Signed-off-by: Amit Sunil Dhamne <amitsd(a)google.com> Reviewed-by: Badhri Jagan Sridharan <badhri(a)google.com> --- drivers/usb/typec/pd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/typec/pd.c b/drivers/usb/typec/pd.c index d78c04a421bc..761fe4dddf1b 100644 --- a/drivers/usb/typec/pd.c +++ b/drivers/usb/typec/pd.c @@ -519,7 +519,7 @@ EXPORT_SYMBOL_GPL(usb_power_delivery_register_capabilities); */ void usb_power_delivery_unregister_capabilities(struct usb_power_delivery_capabilities *cap) { - if (!cap) + if (IS_ERR_OR_NULL(cap)) return; device_for_each_child(&cap->dev, NULL, remove_pdo); base-commit: 68d4209158f43a558c5553ea95ab0c8975eab18c -- 2.46.0.792.g87dc391469-goog

2 hours, 30 minutes

3
3
0 0

5.10.225 stable kernel cgroup_mutex not held assertion failure

by Greg Thelen

Linux stable v5.10.226 suffers a lockdep warning when accessing /proc/PID/cpuset. cset_cgroup_from_root() is called without cgroup_mutex is held, which causes assertion failure. Bisect blames 5.10.225 commit 688325078a8b ("cgroup/cpuset: Prevent UAF in proc_cpuset_show()"). I've have not easily reproduced the problem that this change fixes, so I'm not sure if it's best to revert the fix or adapt it to meet the 5.10 locking expectations. The lockdep complaint: $ cat /proc/1/cpuset $ dmesg [ 198.744891] ------------[ cut here ]------------ [ 198.744918] WARNING: CPU: 4 PID: 9301 at kernel/cgroup/cgroup.c:1395 cset_cgroup_from_root+0xb2/0xd0 [ 198.744957] RIP: 0010:cset_cgroup_from_root+0xb2/0xd0 [ 198.744960] Code: 02 00 00 74 11 48 8b 09 48 39 cb 75 eb eb 19 49 83 c6 10 4c 89 f0 48 85 c0 74 0d 5b 41 5e c3 48 8b 43 60 48 85 c0 75 f3 0f 0b <0f> 0b 83 3d 69 01 ee 01 00 0f 85 78 ff ff ff eb 8b 0f 0b eb 87 66 [ 198.744962] RSP: 0018:ffffb492608a7ce8 EFLAGS: 00010046 [ 198.744977] RAX: 0000000000000000 RBX: ffffffff8f4171b8 RCX: cc949de848c33e00 [ 198.744979] RDX: 0000000000001000 RSI: ffffffff8f415450 RDI: ffff92e5417c4dc0 [ 198.744981] RBP: ffff9303467e3f00 R08: 0000000000000008 R09: ffffffff9122d568 [ 198.744983] R10: ffff92e5417c4380 R11: 0000000000000000 R12: ffff92e3d9506000 [ 198.744984] R13: 0000000000000000 R14: ffff92e443a96000 R15: ffff92e3d9506000 [ 198.744987] FS: 00007f15d94ed740(0000) GS:ffff9302bf500000(0000) knlGS:0000000000000000 [ 198.744988] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 198.744990] CR2: 00007f15d94ca000 CR3: 00000002816ca003 CR4: 00000000001706e0 [ 198.744992] Call Trace: [ 198.744996] ? __warn+0xcd/0x1c0 [ 198.745000] ? cset_cgroup_from_root+0xb2/0xd0 [ 198.745008] ? report_bug+0x87/0xf0 [ 198.745015] ? handle_bug+0x42/0x80 [ 198.745017] ? exc_invalid_op+0x16/0x70 [ 198.745021] ? asm_exc_invalid_op+0x12/0x20 [ 198.745030] ? cset_cgroup_from_root+0xb2/0xd0 [ 198.745034] ? cset_cgroup_from_root+0x28/0xd0 [ 198.745038] cgroup_path_ns_locked+0x23/0x50 [ 198.745044] proc_cpuset_show+0x115/0x210 [ 198.745049] proc_single_show+0x4a/0xa0 [ 198.745056] seq_read_iter+0x14d/0x400 [ 198.745063] seq_read+0x103/0x130 [ 198.745074] vfs_read+0xea/0x320 [ 198.745078] ? do_user_addr_fault+0x25b/0x390 [ 198.745085] ? do_user_addr_fault+0x25b/0x390 [ 198.745090] ksys_read+0x70/0xe0 [ 198.745096] do_syscall_64+0x2d/0x40 [ 198.745099] entry_SYSCALL_64_after_hwframe+0x61/0xcb

3 hours, 7 minutes

3
4
0 0

[PATCH 6.1.y] udf: Fold udf_getblk() into udf_bread()

by Sergey Shtylyov

From: Jan Kara <jack(a)suse.cz> udf_getblk() has a single call site. Fold it there. [Sergey: moved back to using udf_get_block() and buffer_{mapped|new}().] Signed-off-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Sergey Shtylyov <s.shtylyov(a)omp.ru> --- This patch prevents NULL pointer dereference in case sb_getblk() fails... fs/udf/inode.c | 45 +++++++++++++++++++-------------------------- 1 file changed, 19 insertions(+), 26 deletions(-) Index: linux-stable/fs/udf/inode.c =================================================================== --- linux-stable.orig/fs/udf/inode.c +++ linux-stable/fs/udf/inode.c @@ -459,30 +459,6 @@ abort: return err; } -static struct buffer_head *udf_getblk(struct inode *inode, udf_pblk_t block, - int create, int *err) -{ - struct buffer_head *bh; - struct buffer_head dummy; - - dummy.b_state = 0; - dummy.b_blocknr = -1000; - *err = udf_get_block(inode, block, &dummy, create); - if (!*err && buffer_mapped(&dummy)) { - bh = sb_getblk(inode->i_sb, dummy.b_blocknr); - if (buffer_new(&dummy)) { - lock_buffer(bh); - memset(bh->b_data, 0x00, inode->i_sb->s_blocksize); - set_buffer_uptodate(bh); - unlock_buffer(bh); - mark_buffer_dirty_inode(bh, inode); - } - return bh; - } - - return NULL; -} - /* Extend the file with new blocks totaling 'new_block_bytes', * return the number of extents added */ @@ -1198,10 +1174,27 @@ struct buffer_head *udf_bread(struct ino int create, int *err) { struct buffer_head *bh = NULL; + struct buffer_head dummy; + + dummy.b_state = 0; + dummy.b_blocknr = -1000; + *err = udf_get_block(inode, block, &dummy, create); + if (*err || !buffer_mapped(&dummy)) + return NULL; - bh = udf_getblk(inode, block, create, err); - if (!bh) + bh = sb_getblk(inode->i_sb, dummy.b_blocknr); + if (!bh) { + *err = -ENOMEM; return NULL; + } + if (buffer_new(&dummy)) { + lock_buffer(bh); + memset(bh->b_data, 0x00, inode->i_sb->s_blocksize); + set_buffer_uptodate(bh); + unlock_buffer(bh); + mark_buffer_dirty_inode(bh, inode); + return bh; + } if (bh_read(bh, 0) >= 0) return bh;

3 hours, 27 minutes

1
1
0 0

Request to apply patches to v6.6 to fix thunderbolt issue

by Wan, Qin (Thin Client RnD)

Hello, There is an issue found on v6.6.16: Plug in thunderbolt G4 dock with monitor connected after system boots up. The monitor shows nothing when wake up from S3 sometimes. The failure rate is above 50%. The kernel reports “UBSAN: shift-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:4416:36”. The call stack is shown at the bottom of this email. This failure is fixed in v6.9-rc1. We request to merge below commit to v6.6. 6b8ac54f31f985d3abb0b4212187838dd8ea4227 thunderbolt: Fix debug log when DisplayPort adapter not available for pairing fe8a0293c922ee8bc1ff0cf9048075afb264004a thunderbolt: Use tb_tunnel_dbg() where possible to make logging more consistent d27bd2c37d4666bce25ec4d9ac8c6b169992f0f0 thunderbolt: Expose tb_tunnel_xxx() log macros to the rest of the driver 8648c6465c025c488e2855c209c0dea1a1a15184 thunderbolt: Create multiple DisplayPort tunnels if there are more DP IN/OUT pairs f73edddfa2a64a185c65a33f100778169c92fc25 thunderbolt: Use constants for path weight and priority 4d24db0c801461adeefd7e0bdc98c79c60ccefb0 thunderbolt: Use weight constants in tb_usb3_consumed_bandwidth() aa673d606078da36ebc379f041c794228ac08cb5 thunderbolt: Make is_gen4_link() available to the rest of the driver 582e70b0d3a412d15389a3c9c07a44791b311715 thunderbolt: Change bandwidth reservations to comply USB4 v2 2bfeca73e94567c1a117ca45d2e8a25d63e5bd2c 　thunderbolt: Introduce tb_port_path_direction_downstream() 　　956c3abe72fb6a651b8cf77c28462f7e5b6a48b1 　thunderbolt: Introduce tb_for_each_upstream_port_on_path() 　　c4ff14436952c3d0dd05769d76cf48e73a253b48 　thunderbolt: Introduce tb_switch_depth() 　　81af2952e60603d12415e1a6fd200f8073a2ad8b 　thunderbolt: Add support for asymmetric link 　　3e36528c1127b20492ffaea53930bcc3df46a718 　thunderbolt: Configure asymmetric link if needed and bandwidth allows 　　b4734507ac55cc7ea1380e20e83f60fcd7031955 　thunderbolt: Improve DisplayPort tunnel setup process to be more robust 　When failure happened, the kernel log reports Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.414673] UBSAN: shift-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:4416:36 Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.414674] shift exponent -1 is negative Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.414675] CPU: 0 PID: 145 Comm: kworker/0:2 Tainted: G U 6.6.16 #108 Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.414677] Hardware name: HP HP Elite t660 Thin Client/8D05, BIOS W44 Ver. 00.14.00 07/19/2024 Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.414678] Workqueue: events output_poll_execute [drm_kms_helper] Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.414695] Call Trace: Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.414697] <TASK> Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.414698] dump_stack_lvl+0x48/0x70 Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.414703] dump_stack+0x10/0x20 Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.414705] __ubsan_handle_shift_out_of_bounds+0x156/0x310 Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.414708] ? krealloc+0x98/0x100 Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.414711] ? drm_atomic_get_private_obj_state+0x167/0x1a0 [drm] Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.414733] drm_dp_atomic_release_time_slots.cold+0x17/0x3d [drm_display_helper] Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.414743] intel_dp_mst_atomic_check+0x9a/0x170 [i915] Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.414831] drm_atomic_helper_check_modeset+0x4bb/0xe20 [drm_kms_helper] Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.414842] ? __kmem_cache_alloc_node+0x1b3/0x320 Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.414845] ? __ww_mutex_lock.constprop.0+0x39/0xa00 Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.414848] intel_atomic_check+0x113/0x2b50 [i915] Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.414936] drm_atomic_check_only+0x692/0xb80 [drm] Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.414956] drm_atomic_commit+0x57/0xd0 [drm] Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.414972] ? _pfx__drm_printfn_info+0x10/0x10 [drm] Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.414999] drm_client_modeset_commit_atomic+0x1f1/0x230 [drm] Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.415019] drm_client_modeset_commit_locked+0x5b/0x170 [drm] Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.415038] ? mutex_lock+0x13/0x50 Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.415040] drm_client_modeset_commit+0x27/0x50 [drm] Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.415058] __drm_fb_helper_restore_fbdev_mode_unlocked+0xd2/0x100 [drm_kms_helper] Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.415068] drm_fb_helper_hotplug_event+0x11a/0x140 [drm_kms_helper] Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.415077] intel_fbdev_output_poll_changed+0x6f/0xb0 [i915] Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.415156] output_poll_execute+0x23e/0x290 [drm_kms_helper] Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.415166] ? intelfb_dirty+0x41/0x80 [i915] Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.415236] process_one_work+0x178/0x360 Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.415238] ? __pfx_worker_thread+0x10/0x10 Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.415240] worker_thread+0x307/0x430 Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.415241] ? __pfx_worker_thread+0x10/0x10 Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.415242] kthread+0xf4/0x130 Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.415245] ? __pfx_kthread+0x10/0x10 Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.415247] ret_from_fork+0x43/0x70 Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.415249] ? __pfx_kthread+0x10/0x10 Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.415250] ret_from_fork_asm+0x1b/0x30 Sep 6 08:10:29 HP7c5758fc4d4f kernel: [ 89.415252] </TASK> Thanks, Wanqin 　

3 hours, 29 minutes

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2024