From 98f5e34ae5aead5bb5dca7bc60b9e7ef4669b9f8 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Fri, 24 Nov 2023 13:16:09 +0000 Subject: [PATCH] 5.4-stable patches added patches: i2c-i801-fix-potential-race-in-i801_block_transaction_byte_by_byte.patch media-lirc-drop-trailing-space-from-scancode-transmit.patch media-sharp-fix-sharp-encoding.patch media-venus-hfi-add-checks-to-handle-capabilities-from-firmware.patch media-venus-hfi-fix-the-check-to-handle-session-buffer-requirement.patch media-venus-hfi_parser-add-check-to-keep-the-number-of-codecs-within-range.patch net-dsa-lan9303-consequently-nested-lock-physical-mdio.patch nfsd-fix-file-memleak-on-client_opens_release.patch revert-ncsi-propagate-carrier-gain-loss-events-to-the-ncsi-controller.patch --- ...-i801_block_transaction_byte_by_byte.patch | 66 +++++++ ...railing-space-from-scancode-transmit.patch | 37 ++++ .../media-sharp-fix-sharp-encoding.patch | 48 +++++ ...to-handle-capabilities-from-firmware.patch | 69 +++++++ ...to-handle-session-buffer-requirement.patch | 36 ++++ ...ep-the-number-of-codecs-within-range.patch | 39 ++++ ...nsequently-nested-lock-physical-mdio.patch | 171 ++++++++++++++++++ ...file-memleak-on-client_opens_release.patch | 34 ++++ ...n-loss-events-to-the-ncsi-controller.patch | 46 +++++ queue-5.4/series | 9 + 10 files changed, 555 insertions(+) create mode 100644 queue-5.4/i2c-i801-fix-potential-race-in-i801_block_transaction_byte_by_byte.patch create mode 100644 queue-5.4/media-lirc-drop-trailing-space-from-scancode-transmit.patch create mode 100644 queue-5.4/media-sharp-fix-sharp-encoding.patch create mode 100644 queue-5.4/media-venus-hfi-add-checks-to-handle-capabilities-from-firmware.patch create mode 100644 queue-5.4/media-venus-hfi-fix-the-check-to-handle-session-buffer-requirement.patch create mode 100644 queue-5.4/media-venus-hfi_parser-add-check-to-keep-the-number-of-codecs-within-range.patch create mode 100644 queue-5.4/net-dsa-lan9303-consequently-nested-lock-physical-mdio.patch create mode 100644 queue-5.4/nfsd-fix-file-memleak-on-client_opens_release.patch create mode 100644 queue-5.4/revert-ncsi-propagate-carrier-gain-loss-events-to-the-ncsi-controller.patch diff --git a/queue-5.4/i2c-i801-fix-potential-race-in-i801_block_transaction_byte_by_byte.patch b/queue-5.4/i2c-i801-fix-potential-race-in-i801_block_transaction_byte_by_byte.patch new file mode 100644 index 00000000000..5f12a9692bd --- /dev/null +++ b/queue-5.4/i2c-i801-fix-potential-race-in-i801_block_transaction_byte_by_byte.patch @@ -0,0 +1,66 @@ +From f78ca48a8ba9cdec96e8839351e49eec3233b177 Mon Sep 17 00:00:00 2001 +From: Heiner Kallweit +Date: Sat, 9 Sep 2023 22:25:06 +0200 +Subject: i2c: i801: fix potential race in i801_block_transaction_byte_by_byte + +From: Heiner Kallweit + +commit f78ca48a8ba9cdec96e8839351e49eec3233b177 upstream. + +Currently we set SMBHSTCNT_LAST_BYTE only after the host has started +receiving the last byte. If we get e.g. preempted before setting +SMBHSTCNT_LAST_BYTE, the host may be finished with receiving the byte +before SMBHSTCNT_LAST_BYTE is set. +Therefore change the code to set SMBHSTCNT_LAST_BYTE before writing +SMBHSTSTS_BYTE_DONE for the byte before the last byte. Now the code +is also consistent with what we do in i801_isr_byte_done(). + +Reported-by: Jean Delvare +Closes: https://lore.kernel.org/linux-i2c/20230828152747.09444625@endymion.delvare/ +Cc: stable@vger.kernel.org +Acked-by: Andi Shyti +Signed-off-by: Heiner Kallweit +Reviewed-by: Jean Delvare +Signed-off-by: Wolfram Sang +Signed-off-by: Greg Kroah-Hartman +--- + drivers/i2c/busses/i2c-i801.c | 19 +++++++++---------- + 1 file changed, 9 insertions(+), 10 deletions(-) + +--- a/drivers/i2c/busses/i2c-i801.c ++++ b/drivers/i2c/busses/i2c-i801.c +@@ -723,15 +723,11 @@ static int i801_block_transaction_byte_b + return i801_check_post(priv, status); + } + +- for (i = 1; i <= len; i++) { +- if (i == len && read_write == I2C_SMBUS_READ) +- smbcmd |= SMBHSTCNT_LAST_BYTE; +- outb_p(smbcmd, SMBHSTCNT(priv)); +- +- if (i == 1) +- outb_p(inb(SMBHSTCNT(priv)) | SMBHSTCNT_START, +- SMBHSTCNT(priv)); ++ if (len == 1 && read_write == I2C_SMBUS_READ) ++ smbcmd |= SMBHSTCNT_LAST_BYTE; ++ outb_p(smbcmd | SMBHSTCNT_START, SMBHSTCNT(priv)); + ++ for (i = 1; i <= len; i++) { + status = i801_wait_byte_done(priv); + if (status) + goto exit; +@@ -754,9 +750,12 @@ static int i801_block_transaction_byte_b + data->block[0] = len; + } + +- /* Retrieve/store value in SMBBLKDAT */ +- if (read_write == I2C_SMBUS_READ) ++ if (read_write == I2C_SMBUS_READ) { + data->block[i] = inb_p(SMBBLKDAT(priv)); ++ if (i == len - 1) ++ outb_p(smbcmd | SMBHSTCNT_LAST_BYTE, SMBHSTCNT(priv)); ++ } ++ + if (read_write == I2C_SMBUS_WRITE && i+1 <= len) + outb_p(data->block[i+1], SMBBLKDAT(priv)); + diff --git a/queue-5.4/media-lirc-drop-trailing-space-from-scancode-transmit.patch b/queue-5.4/media-lirc-drop-trailing-space-from-scancode-transmit.patch new file mode 100644 index 00000000000..558da9a73b5 --- /dev/null +++ b/queue-5.4/media-lirc-drop-trailing-space-from-scancode-transmit.patch @@ -0,0 +1,37 @@ +From c8a489f820179fb12251e262b50303c29de991ac Mon Sep 17 00:00:00 2001 +From: Sean Young +Date: Fri, 6 Oct 2023 22:31:52 +0100 +Subject: media: lirc: drop trailing space from scancode transmit + +From: Sean Young + +commit c8a489f820179fb12251e262b50303c29de991ac upstream. + +When transmitting, infrared drivers expect an odd number of samples; iow +without a trailing space. No problems have been observed so far, so +this is just belt and braces. + +Fixes: 9b6192589be7 ("media: lirc: implement scancode sending") +Cc: stable@vger.kernel.org +Signed-off-by: Sean Young +Signed-off-by: Hans Verkuil +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/rc/lirc_dev.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/drivers/media/rc/lirc_dev.c ++++ b/drivers/media/rc/lirc_dev.c +@@ -292,7 +292,11 @@ static ssize_t ir_lirc_transmit_ir(struc + if (ret < 0) + goto out_kfree_raw; + +- count = ret; ++ /* drop trailing space */ ++ if (!(ret % 2)) ++ count = ret - 1; ++ else ++ count = ret; + + txbuf = kmalloc_array(count, sizeof(unsigned int), GFP_KERNEL); + if (!txbuf) { diff --git a/queue-5.4/media-sharp-fix-sharp-encoding.patch b/queue-5.4/media-sharp-fix-sharp-encoding.patch new file mode 100644 index 00000000000..7dcd7cc36ee --- /dev/null +++ b/queue-5.4/media-sharp-fix-sharp-encoding.patch @@ -0,0 +1,48 @@ +From 4f7efc71891462ab7606da7039f480d7c1584a13 Mon Sep 17 00:00:00 2001 +From: Sean Young +Date: Fri, 6 Oct 2023 12:54:25 +0100 +Subject: media: sharp: fix sharp encoding + +From: Sean Young + +commit 4f7efc71891462ab7606da7039f480d7c1584a13 upstream. + +The Sharp protocol[1] encoding has incorrect timings for bit space. + +[1] https://www.sbprojects.net/knowledge/ir/sharp.php + +Fixes: d35afc5fe097 ("[media] rc: ir-sharp-decoder: Add encode capability") +Cc: stable@vger.kernel.org +Reported-by: Joe Ferner +Closes: https://sourceforge.net/p/lirc/mailman/message/38604507/ +Signed-off-by: Sean Young +Signed-off-by: Hans Verkuil +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/rc/ir-sharp-decoder.c | 8 +++++--- + 1 file changed, 5 insertions(+), 3 deletions(-) + +--- a/drivers/media/rc/ir-sharp-decoder.c ++++ b/drivers/media/rc/ir-sharp-decoder.c +@@ -15,7 +15,9 @@ + #define SHARP_UNIT 40000 /* ns */ + #define SHARP_BIT_PULSE (8 * SHARP_UNIT) /* 320us */ + #define SHARP_BIT_0_PERIOD (25 * SHARP_UNIT) /* 1ms (680us space) */ +-#define SHARP_BIT_1_PERIOD (50 * SHARP_UNIT) /* 2ms (1680ms space) */ ++#define SHARP_BIT_1_PERIOD (50 * SHARP_UNIT) /* 2ms (1680us space) */ ++#define SHARP_BIT_0_SPACE (17 * SHARP_UNIT) /* 680us space */ ++#define SHARP_BIT_1_SPACE (42 * SHARP_UNIT) /* 1680us space */ + #define SHARP_ECHO_SPACE (1000 * SHARP_UNIT) /* 40 ms */ + #define SHARP_TRAILER_SPACE (125 * SHARP_UNIT) /* 5 ms (even longer) */ + +@@ -168,8 +170,8 @@ static const struct ir_raw_timings_pd ir + .header_pulse = 0, + .header_space = 0, + .bit_pulse = SHARP_BIT_PULSE, +- .bit_space[0] = SHARP_BIT_0_PERIOD, +- .bit_space[1] = SHARP_BIT_1_PERIOD, ++ .bit_space[0] = SHARP_BIT_0_SPACE, ++ .bit_space[1] = SHARP_BIT_1_SPACE, + .trailer_pulse = SHARP_BIT_PULSE, + .trailer_space = SHARP_ECHO_SPACE, + .msb_first = 1, diff --git a/queue-5.4/media-venus-hfi-add-checks-to-handle-capabilities-from-firmware.patch b/queue-5.4/media-venus-hfi-add-checks-to-handle-capabilities-from-firmware.patch new file mode 100644 index 00000000000..e459223c640 --- /dev/null +++ b/queue-5.4/media-venus-hfi-add-checks-to-handle-capabilities-from-firmware.patch @@ -0,0 +1,69 @@ +From 8d0b89398b7ebc52103e055bf36b60b045f5258f Mon Sep 17 00:00:00 2001 +From: Vikash Garodia +Date: Thu, 10 Aug 2023 07:55:03 +0530 +Subject: media: venus: hfi: add checks to handle capabilities from firmware + +From: Vikash Garodia + +commit 8d0b89398b7ebc52103e055bf36b60b045f5258f upstream. + +The hfi parser, parses the capabilities received from venus firmware and +copies them to core capabilities. Consider below api, for example, +fill_caps - In this api, caps in core structure gets updated with the +number of capabilities received in firmware data payload. If the same api +is called multiple times, there is a possibility of copying beyond the max +allocated size in core caps. +Similar possibilities in fill_raw_fmts and fill_profile_level functions. + +Cc: stable@vger.kernel.org +Fixes: 1a73374a04e5 ("media: venus: hfi_parser: add common capability parser") +Signed-off-by: Vikash Garodia +Signed-off-by: Stanimir Varbanov +Signed-off-by: Hans Verkuil +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/platform/qcom/venus/hfi_parser.c | 12 ++++++++++++ + 1 file changed, 12 insertions(+) + +--- a/drivers/media/platform/qcom/venus/hfi_parser.c ++++ b/drivers/media/platform/qcom/venus/hfi_parser.c +@@ -89,6 +89,9 @@ static void fill_profile_level(struct ve + { + const struct hfi_profile_level *pl = data; + ++ if (cap->num_pl + num >= HFI_MAX_PROFILE_COUNT) ++ return; ++ + memcpy(&cap->pl[cap->num_pl], pl, num * sizeof(*pl)); + cap->num_pl += num; + } +@@ -114,6 +117,9 @@ fill_caps(struct venus_caps *cap, const + { + const struct hfi_capability *caps = data; + ++ if (cap->num_caps + num >= MAX_CAP_ENTRIES) ++ return; ++ + memcpy(&cap->caps[cap->num_caps], caps, num * sizeof(*caps)); + cap->num_caps += num; + } +@@ -140,6 +146,9 @@ static void fill_raw_fmts(struct venus_c + { + const struct raw_formats *formats = fmts; + ++ if (cap->num_fmts + num_fmts >= MAX_FMT_ENTRIES) ++ return; ++ + memcpy(&cap->fmts[cap->num_fmts], formats, num_fmts * sizeof(*formats)); + cap->num_fmts += num_fmts; + } +@@ -162,6 +171,9 @@ parse_raw_formats(struct venus_core *cor + rawfmts[i].buftype = fmt->buffer_type; + i++; + ++ if (i >= MAX_FMT_ENTRIES) ++ return; ++ + if (pinfo->num_planes > MAX_PLANES) + break; + diff --git a/queue-5.4/media-venus-hfi-fix-the-check-to-handle-session-buffer-requirement.patch b/queue-5.4/media-venus-hfi-fix-the-check-to-handle-session-buffer-requirement.patch new file mode 100644 index 00000000000..cc8666f107b --- /dev/null +++ b/queue-5.4/media-venus-hfi-fix-the-check-to-handle-session-buffer-requirement.patch @@ -0,0 +1,36 @@ +From b18e36dfd6c935da60a971310374f3dfec3c82e1 Mon Sep 17 00:00:00 2001 +From: Vikash Garodia +Date: Thu, 10 Aug 2023 07:55:02 +0530 +Subject: media: venus: hfi: fix the check to handle session buffer requirement + +From: Vikash Garodia + +commit b18e36dfd6c935da60a971310374f3dfec3c82e1 upstream. + +Buffer requirement, for different buffer type, comes from video firmware. +While copying these requirements, there is an OOB possibility when the +payload from firmware is more than expected size. Fix the check to avoid +the OOB possibility. + +Cc: stable@vger.kernel.org +Fixes: 09c2845e8fe4 ("[media] media: venus: hfi: add Host Firmware Interface (HFI)") +Reviewed-by: Nathan Hebert +Signed-off-by: Vikash Garodia +Signed-off-by: Stanimir Varbanov +Signed-off-by: Hans Verkuil +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/platform/qcom/venus/hfi_msgs.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/media/platform/qcom/venus/hfi_msgs.c ++++ b/drivers/media/platform/qcom/venus/hfi_msgs.c +@@ -350,7 +350,7 @@ session_get_prop_buf_req(struct hfi_msg_ + memcpy(&bufreq[idx], buf_req, sizeof(*bufreq)); + idx++; + +- if (idx > HFI_BUFFER_TYPE_MAX) ++ if (idx >= HFI_BUFFER_TYPE_MAX) + return HFI_ERR_SESSION_INVALID_PARAMETER; + + req_bytes -= sizeof(struct hfi_buffer_requirements); diff --git a/queue-5.4/media-venus-hfi_parser-add-check-to-keep-the-number-of-codecs-within-range.patch b/queue-5.4/media-venus-hfi_parser-add-check-to-keep-the-number-of-codecs-within-range.patch new file mode 100644 index 00000000000..3bb0f74f693 --- /dev/null +++ b/queue-5.4/media-venus-hfi_parser-add-check-to-keep-the-number-of-codecs-within-range.patch @@ -0,0 +1,39 @@ +From 0768a9dd809ef52440b5df7dce5a1c1c7e97abbd Mon Sep 17 00:00:00 2001 +From: Vikash Garodia +Date: Thu, 10 Aug 2023 07:55:04 +0530 +Subject: media: venus: hfi_parser: Add check to keep the number of codecs within range + +From: Vikash Garodia + +commit 0768a9dd809ef52440b5df7dce5a1c1c7e97abbd upstream. + +Supported codec bitmask is populated from the payload from venus firmware. +There is a possible case when all the bits in the codec bitmask is set. In +such case, core cap for decoder is filled and MAX_CODEC_NUM is utilized. +Now while filling the caps for encoder, it can lead to access the caps +array beyong 32 index. Hence leading to OOB write. +The fix counts the supported encoder and decoder. If the count is more than +max, then it skips accessing the caps. + +Cc: stable@vger.kernel.org +Fixes: 1a73374a04e5 ("media: venus: hfi_parser: add common capability parser") +Signed-off-by: Vikash Garodia +Signed-off-by: Stanimir Varbanov +Signed-off-by: Hans Verkuil +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/platform/qcom/venus/hfi_parser.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/media/platform/qcom/venus/hfi_parser.c ++++ b/drivers/media/platform/qcom/venus/hfi_parser.c +@@ -19,6 +19,9 @@ static void init_codecs(struct venus_cor + struct venus_caps *caps = core->caps, *cap; + unsigned long bit; + ++ if (hweight_long(core->dec_codecs) + hweight_long(core->enc_codecs) > MAX_CODEC_NUM) ++ return; ++ + for_each_set_bit(bit, &core->dec_codecs, MAX_CODEC_NUM) { + cap = &caps[core->codecs_count++]; + cap->codec = BIT(bit); diff --git a/queue-5.4/net-dsa-lan9303-consequently-nested-lock-physical-mdio.patch b/queue-5.4/net-dsa-lan9303-consequently-nested-lock-physical-mdio.patch new file mode 100644 index 00000000000..7d47d3dedd3 --- /dev/null +++ b/queue-5.4/net-dsa-lan9303-consequently-nested-lock-physical-mdio.patch @@ -0,0 +1,171 @@ +From 5a22fbcc10f3f7d94c5d88afbbffa240a3677057 Mon Sep 17 00:00:00 2001 +From: Alexander Sverdlin +Date: Fri, 27 Oct 2023 08:57:38 +0200 +Subject: net: dsa: lan9303: consequently nested-lock physical MDIO + +From: Alexander Sverdlin + +commit 5a22fbcc10f3f7d94c5d88afbbffa240a3677057 upstream. + +When LAN9303 is MDIO-connected two callchains exist into +mdio->bus->write(): + +1. switch ports 1&2 ("physical" PHYs): + +virtual (switch-internal) MDIO bus (lan9303_switch_ops->phy_{read|write})-> + lan9303_mdio_phy_{read|write} -> mdiobus_{read|write}_nested + +2. LAN9303 virtual PHY: + +virtual MDIO bus (lan9303_phy_{read|write}) -> + lan9303_virt_phy_reg_{read|write} -> regmap -> lan9303_mdio_{read|write} + +If the latter functions just take +mutex_lock(&sw_dev->device->bus->mdio_lock) it triggers a LOCKDEP +false-positive splat. It's false-positive because the first +mdio_lock in the second callchain above belongs to virtual MDIO bus, the +second mdio_lock belongs to physical MDIO bus. + +Consequent annotation in lan9303_mdio_{read|write} as nested lock +(similar to lan9303_mdio_phy_{read|write}, it's the same physical MDIO bus) +prevents the following splat: + +WARNING: possible circular locking dependency detected +5.15.71 #1 Not tainted +------------------------------------------------------ +kworker/u4:3/609 is trying to acquire lock: +ffff000011531c68 (lan9303_mdio:131:(&lan9303_mdio_regmap_config)->lock){+.+.}-{3:3}, at: regmap_lock_mutex +but task is already holding lock: +ffff0000114c44d8 (&bus->mdio_lock){+.+.}-{3:3}, at: mdiobus_read +which lock already depends on the new lock. +the existing dependency chain (in reverse order) is: +-> #1 (&bus->mdio_lock){+.+.}-{3:3}: + lock_acquire + __mutex_lock + mutex_lock_nested + lan9303_mdio_read + _regmap_read + regmap_read + lan9303_probe + lan9303_mdio_probe + mdio_probe + really_probe + __driver_probe_device + driver_probe_device + __device_attach_driver + bus_for_each_drv + __device_attach + device_initial_probe + bus_probe_device + deferred_probe_work_func + process_one_work + worker_thread + kthread + ret_from_fork +-> #0 (lan9303_mdio:131:(&lan9303_mdio_regmap_config)->lock){+.+.}-{3:3}: + __lock_acquire + lock_acquire.part.0 + lock_acquire + __mutex_lock + mutex_lock_nested + regmap_lock_mutex + regmap_read + lan9303_phy_read + dsa_slave_phy_read + __mdiobus_read + mdiobus_read + get_phy_device + mdiobus_scan + __mdiobus_register + dsa_register_switch + lan9303_probe + lan9303_mdio_probe + mdio_probe + really_probe + __driver_probe_device + driver_probe_device + __device_attach_driver + bus_for_each_drv + __device_attach + device_initial_probe + bus_probe_device + deferred_probe_work_func + process_one_work + worker_thread + kthread + ret_from_fork +other info that might help us debug this: + Possible unsafe locking scenario: + CPU0 CPU1 + ---- ---- + lock(&bus->mdio_lock); + lock(lan9303_mdio:131:(&lan9303_mdio_regmap_config)->lock); + lock(&bus->mdio_lock); + lock(lan9303_mdio:131:(&lan9303_mdio_regmap_config)->lock); +*** DEADLOCK *** +5 locks held by kworker/u4:3/609: + #0: ffff000002842938 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work + #1: ffff80000bacbd60 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work + #2: ffff000007645178 (&dev->mutex){....}-{3:3}, at: __device_attach + #3: ffff8000096e6e78 (dsa2_mutex){+.+.}-{3:3}, at: dsa_register_switch + #4: ffff0000114c44d8 (&bus->mdio_lock){+.+.}-{3:3}, at: mdiobus_read +stack backtrace: +CPU: 1 PID: 609 Comm: kworker/u4:3 Not tainted 5.15.71 #1 +Workqueue: events_unbound deferred_probe_work_func +Call trace: + dump_backtrace + show_stack + dump_stack_lvl + dump_stack + print_circular_bug + check_noncircular + __lock_acquire + lock_acquire.part.0 + lock_acquire + __mutex_lock + mutex_lock_nested + regmap_lock_mutex + regmap_read + lan9303_phy_read + dsa_slave_phy_read + __mdiobus_read + mdiobus_read + get_phy_device + mdiobus_scan + __mdiobus_register + dsa_register_switch + lan9303_probe + lan9303_mdio_probe +... + +Cc: stable@vger.kernel.org +Fixes: dc7005831523 ("net: dsa: LAN9303: add MDIO managed mode support") +Signed-off-by: Alexander Sverdlin +Reviewed-by: Andrew Lunn +Link: https://lore.kernel.org/r/20231027065741.534971-1-alexander.sverdlin@siemens.com +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/dsa/lan9303_mdio.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/net/dsa/lan9303_mdio.c ++++ b/drivers/net/dsa/lan9303_mdio.c +@@ -32,7 +32,7 @@ static int lan9303_mdio_write(void *ctx, + struct lan9303_mdio *sw_dev = (struct lan9303_mdio *)ctx; + + reg <<= 2; /* reg num to offset */ +- mutex_lock(&sw_dev->device->bus->mdio_lock); ++ mutex_lock_nested(&sw_dev->device->bus->mdio_lock, MDIO_MUTEX_NESTED); + lan9303_mdio_real_write(sw_dev->device, reg, val & 0xffff); + lan9303_mdio_real_write(sw_dev->device, reg + 2, (val >> 16) & 0xffff); + mutex_unlock(&sw_dev->device->bus->mdio_lock); +@@ -50,7 +50,7 @@ static int lan9303_mdio_read(void *ctx, + struct lan9303_mdio *sw_dev = (struct lan9303_mdio *)ctx; + + reg <<= 2; /* reg num to offset */ +- mutex_lock(&sw_dev->device->bus->mdio_lock); ++ mutex_lock_nested(&sw_dev->device->bus->mdio_lock, MDIO_MUTEX_NESTED); + *val = lan9303_mdio_real_read(sw_dev->device, reg); + *val |= (lan9303_mdio_real_read(sw_dev->device, reg + 2) << 16); + mutex_unlock(&sw_dev->device->bus->mdio_lock); diff --git a/queue-5.4/nfsd-fix-file-memleak-on-client_opens_release.patch b/queue-5.4/nfsd-fix-file-memleak-on-client_opens_release.patch new file mode 100644 index 00000000000..3cf7dc3dae1 --- /dev/null +++ b/queue-5.4/nfsd-fix-file-memleak-on-client_opens_release.patch @@ -0,0 +1,34 @@ +From bc1b5acb40201a0746d68a7d7cfc141899937f4f Mon Sep 17 00:00:00 2001 +From: Mahmoud Adam +Date: Fri, 10 Nov 2023 19:21:04 +0100 +Subject: nfsd: fix file memleak on client_opens_release + +From: Mahmoud Adam + +commit bc1b5acb40201a0746d68a7d7cfc141899937f4f upstream. + +seq_release should be called to free the allocated seq_file + +Cc: stable@vger.kernel.org # v5.3+ +Signed-off-by: Mahmoud Adam +Reviewed-by: Jeff Layton +Fixes: 78599c42ae3c ("nfsd4: add file to display list of client's opens") +Reviewed-by: NeilBrown +Tested-by: Jeff Layton +Signed-off-by: Chuck Lever +Signed-off-by: Greg Kroah-Hartman +--- + fs/nfsd/nfs4state.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/nfsd/nfs4state.c ++++ b/fs/nfsd/nfs4state.c +@@ -2571,7 +2571,7 @@ static int client_opens_release(struct i + + /* XXX: alternatively, we could get/drop in seq start/stop */ + drop_client(clp); +- return 0; ++ return seq_release(inode, file); + } + + static const struct file_operations client_states_fops = { diff --git a/queue-5.4/revert-ncsi-propagate-carrier-gain-loss-events-to-the-ncsi-controller.patch b/queue-5.4/revert-ncsi-propagate-carrier-gain-loss-events-to-the-ncsi-controller.patch new file mode 100644 index 00000000000..204dff24b78 --- /dev/null +++ b/queue-5.4/revert-ncsi-propagate-carrier-gain-loss-events-to-the-ncsi-controller.patch @@ -0,0 +1,46 @@ +From 9e2e7efbbbff69d8340abb56d375dd79d1f5770f Mon Sep 17 00:00:00 2001 +From: Johnathan Mantey +Date: Mon, 13 Nov 2023 08:30:29 -0800 +Subject: Revert ncsi: Propagate carrier gain/loss events to the NCSI controller + +From: Johnathan Mantey + +commit 9e2e7efbbbff69d8340abb56d375dd79d1f5770f upstream. + +This reverts commit 3780bb29311eccb7a1c9641032a112eed237f7e3. + +The cited commit introduced unwanted behavior. + +The intent for the commit was to be able to detect carrier loss/gain +for just the NIC connected to the BMC. The unwanted effect is a +carrier loss for auxiliary paths also causes the BMC to lose +carrier. The BMC never regains carrier despite the secondary NIC +regaining a link. + +This change, when merged, needs to be backported to stable kernels. +5.4-stable, 5.10-stable, 5.15-stable, 6.1-stable, 6.5-stable + +Fixes: 3780bb29311e ("ncsi: Propagate carrier gain/loss events to the NCSI controller") +CC: stable@vger.kernel.org +Signed-off-by: Johnathan Mantey +Reviewed-by: Simon Horman +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/ncsi/ncsi-aen.c | 5 ----- + 1 file changed, 5 deletions(-) + +--- a/net/ncsi/ncsi-aen.c ++++ b/net/ncsi/ncsi-aen.c +@@ -89,11 +89,6 @@ static int ncsi_aen_handler_lsc(struct n + if ((had_link == has_link) || chained) + return 0; + +- if (had_link) +- netif_carrier_off(ndp->ndev.dev); +- else +- netif_carrier_on(ndp->ndev.dev); +- + if (!ndp->multi_package && !nc->package->multi_channel) { + if (had_link) { + ndp->flags |= NCSI_DEV_RESHUFFLE; diff --git a/queue-5.4/series b/queue-5.4/series index aefd1681e4a..7c7ce2b997d 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -114,3 +114,12 @@ bluetooth-add-device-0bda-887b-to-device-tables.patch bluetooth-add-device-13d3-3571-to-device-tables.patch bluetooth-btusb-add-rtw8852be-device-13d3-3570-to-de.patch bluetooth-btusb-add-0bda-b85b-for-fn-link-rtl8852be.patch +revert-ncsi-propagate-carrier-gain-loss-events-to-the-ncsi-controller.patch +net-dsa-lan9303-consequently-nested-lock-physical-mdio.patch +i2c-i801-fix-potential-race-in-i801_block_transaction_byte_by_byte.patch +media-lirc-drop-trailing-space-from-scancode-transmit.patch +media-sharp-fix-sharp-encoding.patch +media-venus-hfi_parser-add-check-to-keep-the-number-of-codecs-within-range.patch +media-venus-hfi-fix-the-check-to-handle-session-buffer-requirement.patch +media-venus-hfi-add-checks-to-handle-capabilities-from-firmware.patch +nfsd-fix-file-memleak-on-client_opens_release.patch -- 2.47.3