November 2023 - Linux-stable-mirror

[PATCH 1/1] driver core: Avoid using fwnode in __fwnode_link_del()

by Herve Codina

A refcount issue can appeared in __fwnode_link_del() due to the pr_debug() call: WARNING: CPU: 0 PID: 901 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110 Call Trace: <TASK> ? refcount_warn_saturate+0xe5/0x110 ? __warn+0x81/0x130 ? refcount_warn_saturate+0xe5/0x110 ? report_bug+0x191/0x1c0 ? srso_alias_return_thunk+0x5/0x7f ? prb_read_valid+0x1b/0x30 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? refcount_warn_saturate+0xe5/0x110 kobject_get+0x68/0x70 of_node_get+0x1e/0x30 of_fwnode_get+0x28/0x40 fwnode_full_name_string+0x34/0x90 fwnode_string+0xdb/0x140 vsnprintf+0x17b/0x630 va_format.isra.0+0x71/0x130 vsnprintf+0x17b/0x630 vprintk_store+0x162/0x4d0 ? srso_alias_return_thunk+0x5/0x7f ? srso_alias_return_thunk+0x5/0x7f ? srso_alias_return_thunk+0x5/0x7f ? try_to_wake_up+0x9c/0x620 ? rwsem_mark_wake+0x1b2/0x310 vprintk_emit+0xe4/0x2b0 _printk+0x5c/0x80 __dynamic_pr_debug+0x131/0x160 ? srso_alias_return_thunk+0x5/0x7f __fwnode_link_del+0x25/0xa0 fwnode_links_purge+0x39/0xb0 of_node_release+0xd9/0x180 kobject_put+0x7b/0x190 ... Indeed, an of_node is destroyed and so, of_node_release() is called because the of_node refcount reached 0. of_node_release() calls fwnode_links_purge() to purge the links and ended with __fwnode_link_del() calls. __fwnode_link_del calls pr_debug() to print the fwnodes (of_nodes) involved in the link and so this call is done while one of them is no more available (ie the one related to the of_node_release() call) Remove the pr_debug() call to avoid the use of the links fwnode while destroying the fwnode itself. Fixes: ebd6823af378 ("driver core: Add debug logs when fwnode links are added/deleted") Cc: stable(a)vger.kernel.org Signed-off-by: Herve Codina <herve.codina(a)bootlin.com> --- drivers/base/core.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/base/core.c b/drivers/base/core.c index f4b09691998e..62088c663014 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -109,8 +109,6 @@ int fwnode_link_add(struct fwnode_handle *con, struct fwnode_handle *sup) */ static void __fwnode_link_del(struct fwnode_link *link) { - pr_debug("%pfwf Dropping the fwnode link to %pfwf\n", - link->consumer, link->supplier); list_del(&link->s_hook); list_del(&link->c_hook); kfree(link); -- 2.41.0

1 year, 1 month

2
2
0 0

+ parisc-fix-mmap_base-calculation-when-stack-grows-upwards.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: parisc: fix mmap_base calculation when stack grows upwards has been added to the -mm mm-hotfixes-unstable branch. Its filename is parisc-fix-mmap_base-calculation-when-stack-grows-upwards.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm 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 via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Helge Deller <deller(a)gmx.de> Subject: parisc: fix mmap_base calculation when stack grows upwards Date: Mon, 13 Nov 2023 11:12:57 +0100 Matoro reported various userspace crashes on the parisc platform with kernel 6.6 and bisected it to commit 3033cd430768 ("parisc: Use generic mmap top-down layout and brk randomization"). That commit switched parisc to use the common infrastructure to calculate mmap_base, but missed that the mmap_base() function takes care for architectures where the stack grows downwards only. Fix the mmap_base() calculation to include the stack-grows-upwards case and thus fix the userspace crashes on parisc. Link: https://lkml.kernel.org/r/ZVH2qeS1bG7/1J/l@p100 Fixes: 3033cd430768 ("parisc: Use generic mmap top-down layout and brk randomization") Signed-off-by: Helge Deller <deller(a)gmx.de> Reported-by: matoro <matoro_mailinglist_kernel(a)matoro.tk> Tested-by: matoro <matoro_mailinglist_kernel(a)matoro.tk> Cc: <stable(a)vger.kernel.org> [6.6+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/parisc/Kconfig | 6 +++--- arch/parisc/include/asm/elf.h | 10 +--------- arch/parisc/include/asm/processor.h | 2 ++ arch/parisc/kernel/sys_parisc.c | 2 +- mm/util.c | 10 ++++++++++ 5 files changed, 17 insertions(+), 13 deletions(-) --- a/arch/parisc/include/asm/elf.h~parisc-fix-mmap_base-calculation-when-stack-grows-upwards +++ a/arch/parisc/include/asm/elf.h @@ -349,15 +349,7 @@ struct pt_regs; /* forward declaration.. #define ELF_HWCAP 0 -/* Masks for stack and mmap randomization */ -#define BRK_RND_MASK (is_32bit_task() ? 0x07ffUL : 0x3ffffUL) -#define MMAP_RND_MASK (is_32bit_task() ? 0x1fffUL : 0x3ffffUL) -#define STACK_RND_MASK MMAP_RND_MASK - -struct mm_struct; -extern unsigned long arch_randomize_brk(struct mm_struct *); -#define arch_randomize_brk arch_randomize_brk - +#define STACK_RND_MASK 0x7ff /* 8MB of VA */ #define ARCH_HAS_SETUP_ADDITIONAL_PAGES 1 struct linux_binprm; --- a/arch/parisc/include/asm/processor.h~parisc-fix-mmap_base-calculation-when-stack-grows-upwards +++ a/arch/parisc/include/asm/processor.h @@ -47,6 +47,8 @@ #ifndef __ASSEMBLY__ +struct rlimit; +unsigned long mmap_upper_limit(struct rlimit *rlim_stack); unsigned long calc_max_stack_size(unsigned long stack_max); /* --- a/arch/parisc/Kconfig~parisc-fix-mmap_base-calculation-when-stack-grows-upwards +++ a/arch/parisc/Kconfig @@ -140,11 +140,11 @@ config ARCH_MMAP_RND_COMPAT_BITS_MIN default 8 config ARCH_MMAP_RND_BITS_MAX - default 24 if 64BIT - default 17 + default 18 if 64BIT + default 13 config ARCH_MMAP_RND_COMPAT_BITS_MAX - default 17 + default 13 # unless you want to implement ACPI on PA-RISC ... ;-) config PM --- a/arch/parisc/kernel/sys_parisc.c~parisc-fix-mmap_base-calculation-when-stack-grows-upwards +++ a/arch/parisc/kernel/sys_parisc.c @@ -77,7 +77,7 @@ unsigned long calc_max_stack_size(unsign * indicating that "current" should be used instead of a passed-in * value from the exec bprm as done with arch_pick_mmap_layout(). */ -static unsigned long mmap_upper_limit(struct rlimit *rlim_stack) +unsigned long mmap_upper_limit(struct rlimit *rlim_stack) { unsigned long stack_base; --- a/mm/util.c~parisc-fix-mmap_base-calculation-when-stack-grows-upwards +++ a/mm/util.c @@ -414,6 +414,15 @@ static int mmap_is_legacy(struct rlimit static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack) { +#ifdef CONFIG_STACK_GROWSUP + /* + * For an upwards growing stack the calculation is much simpler. + * Memory for the maximum stack size is reserved at the top of the + * task. mmap_base starts directly below the stack and grows + * downwards. + */ + return PAGE_ALIGN_DOWN(mmap_upper_limit(rlim_stack) - rnd); +#else unsigned long gap = rlim_stack->rlim_cur; unsigned long pad = stack_guard_gap; @@ -431,6 +440,7 @@ static unsigned long mmap_base(unsigned gap = MAX_GAP; return PAGE_ALIGN(STACK_TOP - gap - rnd); +#endif } void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack) _ Patches currently in -mm which might be from deller(a)gmx.de are parisc-fix-mmap_base-calculation-when-stack-grows-upwards.patch

1 year, 1 month

1
0
0 0

[PATCH v2] mtd: rawnand: Increment IFC_TIMEOUT_MSECS for nand controller response

by Ronald Monthero

Under heavy load it is likely that the controller is done with its own task but the thread unlocking the wait is not scheduled in time. Increasing IFC_TIMEOUT_MSECS allows the controller to respond within allowable timeslice of 1 sec fsl,ifc-nand 7e800000.nand: Controller is not responding main/smp_fsm.c:1884 <inrcu: rcu_preempt detected stalls on CPUs/tasks: rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P116/2:b..l (detected by 1, t=2102 jiffies, g=7729, q=754) task:irq/31-arm-irq1 state:D stack: 0 pid: 116 ppid: 2 flags:0x00000000 [<8064b97f>] (__schedule) from [<8064bb01>] (schedule+0x8d/0xc2) [<8064bb01>] (schedule) from [<8064dacd>] [<8064dacd>] (rt_mutex_slowlock_block.constprop.0) from [<8064db57>] [<8064db57>] (__rt_mutex_slowlock.constprop.0) from [<8064dbf7>] [<8064dbf7>] (rt_mutex_slowlock.constprop.0) from [<804b2047>] [<804b2047>] (nand_get_device) from [<804b5335>] (nand_write_oob+0x1b/0x4a) [<804b5335>] (nand_write_oob) from [<804a3585>] (mtd_write+0x41/0x5c) [<804a3585>] (mtd_write) from [<804c1d47>] (ubi_io_write+0x17f/0x22c) [<804c1d47>] (ubi_io_write) from [<804c047b>] (ubi_eba_write_leb+0x5b/0x1d0) Cc: stable(a)vger.kernel.org Signed-off-by: Ronald Monthero <debug.penguin32(a)gmail.com> --- drivers/mtd/nand/raw/fsl_ifc_nand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/fsl_ifc_nand.c b/drivers/mtd/nand/raw/fsl_ifc_nand.c index 20bb1e0cb5eb..42f8ea46b6a8 100644 --- a/drivers/mtd/nand/raw/fsl_ifc_nand.c +++ b/drivers/mtd/nand/raw/fsl_ifc_nand.c @@ -21,7 +21,7 @@ #define ERR_BYTE 0xFF /* Value returned for read bytes when read failed */ -#define IFC_TIMEOUT_MSECS 500 /* Maximum number of mSecs to wait +#define IFC_TIMEOUT_MSECS 1000 /* Maximum number of mSecs to wait for IFC NAND Machine */ struct fsl_ifc_ctrl; -- 2.34.1

1 year, 1 month

2
2
0 0

[PATCH net,v4, 2/3] hv_netvsc: Fix race of register_netdevice_notifier and VF register

by Haiyang Zhang

If VF NIC is registered earlier, NETDEV_REGISTER event is replayed, but NETDEV_POST_INIT is not. Move register_netdevice_notifier() earlier, so the call back function is set before probing. Cc: stable(a)vger.kernel.org Fixes: e04e7a7bbd4b ("hv_netvsc: Fix a deadlock by getting rtnl lock earlier in netvsc_probe()") Reported-by: Dexuan Cui <decui(a)microsoft.com> Signed-off-by: Haiyang Zhang <haiyangz(a)microsoft.com> Reviewed-by: Wojciech Drewek <wojciech.drewek(a)intel.com> --- v3: Divide it into two patches, suggested by Jakub Kicinski. v2: Fix rtnl_unlock() in error handling as found by Wojciech Drewek. --- drivers/net/hyperv/netvsc_drv.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c index 5e528a76f5f5..1d1491da303b 100644 --- a/drivers/net/hyperv/netvsc_drv.c +++ b/drivers/net/hyperv/netvsc_drv.c @@ -2793,11 +2793,14 @@ static int __init netvsc_drv_init(void) } netvsc_ring_bytes = ring_size * PAGE_SIZE; + register_netdevice_notifier(&netvsc_netdev_notifier); + ret = vmbus_driver_register(&netvsc_drv); - if (ret) + if (ret) { + unregister_netdevice_notifier(&netvsc_netdev_notifier); return ret; + } - register_netdevice_notifier(&netvsc_netdev_notifier); return 0; } -- 2.25.1

1 year, 1 month

3
3
0 0

Re: Patch "fbdev: omapfb: Drop unused remove function" has been added to the 6.6-stable tree

by Uwe Kleine-König

On Sun, Nov 12, 2023 at 11:36:02PM -0500, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > fbdev: omapfb: Drop unused remove function > > to the 6.6-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > fbdev-omapfb-drop-unused-remove-function.patch > and it can be found in the queue-6.6 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > > commit a772de6bea2f5a9b5dad8afe0d9145fd8ee62564 > Author: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> > Date: Fri Nov 3 18:35:58 2023 +0100 > > fbdev: omapfb: Drop unused remove function > > [ Upstream commit fc6699d62f5f4facc3e934efd25892fc36050b70 ] > > OMAP2_VRFB is a bool, so the vrfb driver can never be compiled as a > module. With that __exit_p(vrfb_remove) always evaluates to NULL and > vrfb_remove() is unused. > > If the driver was compilable as a module, it would fail to build because > the type of vrfb_remove() isn't compatible with struct > platform_driver::remove(). (The former returns void, the latter int.) > > Fixes: aa1e49a3752f ("OMAPDSS: VRFB: add omap_vrfb_supported()") > Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> > Signed-off-by: Helge Deller <deller(a)gmx.de> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> While it doesn't hurt to backport this patch, I guess it also doesn't give any benefit (apart from increasing my patch count in stable :-). This commit just removes code that was thrown away by the compiler before. So I'd not backport it. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |

1 year, 1 month

2
1
0 0

[git:media_stage/master] media: subdev: Don't report V4L2_SUBDEV_CAP_STREAMS when the streams API is disabled

by Hans Verkuil

This is an automatic generated email to let you know that the following patch were queued: Subject: media: subdev: Don't report V4L2_SUBDEV_CAP_STREAMS when the streams API is disabled Author: Hans de Goede <hdegoede(a)redhat.com> Date: Tue Oct 10 12:24:58 2023 +0200 Since the stream API is still experimental it is currently locked away behind the internal, default disabled, v4l2_subdev_enable_streams_api flag. Advertising V4L2_SUBDEV_CAP_STREAMS when the streams API is disabled confuses userspace. E.g. it causes the following libcamera error: ERROR SimplePipeline simple.cpp:1497 Failed to reset routes for /dev/v4l-subdev1: Inappropriate ioctl for device Don't report V4L2_SUBDEV_CAP_STREAMS when the streams API is disabled to avoid problems like this. Reported-by: Dennis Bonke <admin(a)dennisbonke.com> Fixes: 9a6b5bf4c1bb ("media: add V4L2_SUBDEV_CAP_STREAMS") Cc: stable(a)vger.kernel.org # for >= 6.3 Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Acked-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> drivers/media/v4l2-core/v4l2-subdev.c | 7 +++++++ 1 file changed, 7 insertions(+) --- diff --git a/drivers/media/v4l2-core/v4l2-subdev.c b/drivers/media/v4l2-core/v4l2-subdev.c index b92348ad61f6..31752c06d1f0 100644 --- a/drivers/media/v4l2-core/v4l2-subdev.c +++ b/drivers/media/v4l2-core/v4l2-subdev.c @@ -502,6 +502,13 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg, V4L2_SUBDEV_CLIENT_CAP_STREAMS; int rval; + /* + * If the streams API is not enabled, remove V4L2_SUBDEV_CAP_STREAMS. + * Remove this when the API is no longer experimental. + */ + if (!v4l2_subdev_enable_streams_api) + streams_subdev = false; + switch (cmd) { case VIDIOC_SUBDEV_QUERYCAP: { struct v4l2_subdev_capability *cap = arg;

1 year, 1 month

1
0
0 0

[PATCH net] ppp: limit MRU to 64K

by Willem de Bruijn

From: Willem de Bruijn <willemb(a)google.com> ppp_sync_ioctl allows setting device MRU, but does not sanity check this input. Limit to a sane upper bound of 64KB. No implementation I could find generates larger than 64KB frames. RFC 2823 mentions an upper bound of PPP over SDL of 64KB based on the 16-bit length field. Other protocols will be smaller, such as PPPoE (9KB jumbo frame) and PPPoA (18190 maximum CPCS-SDU size, RFC 2364). PPTP and L2TP encapsulate in IP. Syzbot managed to trigger alloc warning in __alloc_pages: if (WARN_ON_ONCE_GFP(order > MAX_ORDER, gfp)) WARNING: CPU: 1 PID: 37 at mm/page_alloc.c:4544 __alloc_pages+0x3ab/0x4a0 mm/page_alloc.c:4544 __alloc_skb+0x12b/0x330 net/core/skbuff.c:651 __netdev_alloc_skb+0x72/0x3f0 net/core/skbuff.c:715 netdev_alloc_skb include/linux/skbuff.h:3225 [inline] dev_alloc_skb include/linux/skbuff.h:3238 [inline] ppp_sync_input drivers/net/ppp/ppp_synctty.c:669 [inline] ppp_sync_receive+0xff/0x680 drivers/net/ppp/ppp_synctty.c:334 tty_ldisc_receive_buf+0x14c/0x180 drivers/tty/tty_buffer.c:390 tty_port_default_receive_buf+0x70/0xb0 drivers/tty/tty_port.c:37 receive_buf drivers/tty/tty_buffer.c:444 [inline] flush_to_ldisc+0x261/0x780 drivers/tty/tty_buffer.c:494 process_one_work+0x884/0x15c0 kernel/workqueue.c:2630 With call ioctl$PPPIOCSMRU1(r1, 0x40047452, &(0x7f0000000100)=0x5e6417a8) Similar code exists in other drivers that implement ppp_channel_ops ioctl PPPIOCSMRU. Those might also be in scope. Notably excluded from this are pppol2tp_ioctl and pppoe_ioctl. This code goes back to the start of git history. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+6177e1f90d92583bcc58(a)syzkaller.appspotmail.com Signed-off-by: Willem de Bruijn <willemb(a)google.com> --- drivers/net/ppp/ppp_synctty.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/ppp/ppp_synctty.c b/drivers/net/ppp/ppp_synctty.c index ea261a628786..52d05ce4a281 100644 --- a/drivers/net/ppp/ppp_synctty.c +++ b/drivers/net/ppp/ppp_synctty.c @@ -453,6 +453,10 @@ ppp_sync_ioctl(struct ppp_channel *chan, unsigned int cmd, unsigned long arg) case PPPIOCSMRU: if (get_user(val, (int __user *) argp)) break; + if (val > U16_MAX) { + err = -EINVAL; + break; + } if (val < PPP_MRU) val = PPP_MRU; ap->mru = val; -- 2.43.0.rc0.421.g78406f8d94-goog

1 year, 1 month

4
3
0 0

[PATCH 1/1] driver core: Keep the supplier fwnode consistent with the device

by Herve Codina

The commit 3a2dbc510c43 ("driver core: fw_devlink: Don't purge child fwnode's consumer links") introduces the possibility to use the supplier's parent device instead of the supplier itself. In that case the supplier fwnode used is not updated and is no more consistent with the supplier device used. Update the fwnode used to be consistent with the supplier device used. Fixes: 3a2dbc510c43 ("driver core: fw_devlink: Don't purge child fwnode's consumer links") Cc: stable(a)vger.kernel.org Signed-off-by: Herve Codina <herve.codina(a)bootlin.com> --- drivers/base/core.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/base/core.c b/drivers/base/core.c index 4d8b315c48a1..17f2568e0a79 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -2076,6 +2076,18 @@ static int fw_devlink_create_devlink(struct device *con, sup_dev = get_dev_from_fwnode(sup_handle); if (sup_dev) { + /* + * The supplier device may have changed and so, the supplier + * fwnode maybe inconsistent. + * Update the supplier fwnode + */ + sup_handle = sup_dev->fwnode; + if (!sup_handle) { + dev_dbg(con, "Not linking %s - fwnode NULL\n", + dev_name(sup_dev)); + goto out; + } + /* * If it's one of those drivers that don't actually bind to * their device using driver core, then don't wait on this -- 2.41.0

1 year, 1 month

2
2
0 0

[PATCH v2] iio: cros_ec: fix an use-after-free in cros_ec_sensors_push_data()

by Tzung-Bi Shih

cros_ec_sensors_push_data() reads `indio_dev->active_scan_mask` and calls iio_push_to_buffers_with_timestamp() without making sure the `indio_dev` stays in buffer mode. There is a race if `indio_dev` exits buffer mode right before cros_ec_sensors_push_data() accesses them. An use-after-free on `indio_dev->active_scan_mask` was observed. The call trace: [...] _find_next_bit cros_ec_sensors_push_data cros_ec_sensorhub_event blocking_notifier_call_chain cros_ec_irq_thread It was caused by a race condition: one thread just freed `active_scan_mask` at [1]; while another thread tried to access the memory at [2]. Fix it by calling iio_device_claim_buffer_mode() to ensure the `indio_dev` can't exit buffer mode during cros_ec_sensors_push_data(). [1]: https://elixir.bootlin.com/linux/v6.5/source/drivers/iio/industrialio-buffe… [2]: https://elixir.bootlin.com/linux/v6.5/source/drivers/iio/common/cros_ec_sen… Cc: stable(a)vger.kernel.org Fixes: aa984f1ba4a4 ("iio: cros_ec: Register to cros_ec_sensorhub when EC supports FIFO") Signed-off-by: Tzung-Bi Shih <tzungbi(a)kernel.org> --- Changes from v1(https://patchwork.kernel.org/project/linux-iio/patch/20230828094339.1248…: - Use iio_device_{claim|release}_buffer_mode() instead of accessing `mlock`. drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c index b72d39fc2434..6bfe5d6847e7 100644 --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c @@ -190,8 +190,11 @@ int cros_ec_sensors_push_data(struct iio_dev *indio_dev, /* * Ignore samples if the buffer is not set: it is needed if the ODR is * set but the buffer is not enabled yet. + * + * Note: iio_device_claim_buffer_mode() returns -EBUSY if the buffer + * is not enabled. */ - if (!iio_buffer_enabled(indio_dev)) + if (iio_device_claim_buffer_mode(indio_dev) < 0) return 0; out = (s16 *)st->samples; @@ -210,6 +213,7 @@ int cros_ec_sensors_push_data(struct iio_dev *indio_dev, iio_push_to_buffers_with_timestamp(indio_dev, st->samples, timestamp + delta); + iio_device_release_buffer_mode(indio_dev); return 0; } EXPORT_SYMBOL_GPL(cros_ec_sensors_push_data); -- 2.42.0.rc2.253.gd59a3bf2b4-goog

1 year, 1 month

5
5
0 0

[PATCH net,v4, 1/3] hv_netvsc: fix race of netvsc and VF register_netdevice

by Haiyang Zhang

The rtnl lock also needs to be held before rndis_filter_device_add() which advertises nvsp_2_vsc_capability / sriov bit, and triggers VF NIC offering and registering. If VF NIC finished register_netdev() earlier it may cause name based config failure. To fix this issue, move the call to rtnl_lock() before rndis_filter_device_add(), so VF will be registered later than netvsc / synthetic NIC, and gets a name numbered (ethX) after netvsc. Cc: stable(a)vger.kernel.org Fixes: e04e7a7bbd4b ("hv_netvsc: Fix a deadlock by getting rtnl lock earlier in netvsc_probe()") Reported-by: Dexuan Cui <decui(a)microsoft.com> Signed-off-by: Haiyang Zhang <haiyangz(a)microsoft.com> Reviewed-by: Wojciech Drewek <wojciech.drewek(a)intel.com> --- v3: Divide it into two patches, suggested by Jakub Kicinski. v2: Fix rtnl_unlock() in error handling as found by Wojciech Drewek. --- drivers/net/hyperv/netvsc_drv.c | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c index 3ba3c8fb28a5..5e528a76f5f5 100644 --- a/drivers/net/hyperv/netvsc_drv.c +++ b/drivers/net/hyperv/netvsc_drv.c @@ -2531,15 +2531,6 @@ static int netvsc_probe(struct hv_device *dev, goto devinfo_failed; } - nvdev = rndis_filter_device_add(dev, device_info); - if (IS_ERR(nvdev)) { - ret = PTR_ERR(nvdev); - netdev_err(net, "unable to add netvsc device (ret %d)\n", ret); - goto rndis_failed; - } - - eth_hw_addr_set(net, device_info->mac_adr); - /* We must get rtnl lock before scheduling nvdev->subchan_work, * otherwise netvsc_subchan_work() can get rtnl lock first and wait * all subchannels to show up, but that may not happen because @@ -2547,9 +2538,23 @@ static int netvsc_probe(struct hv_device *dev, * -> ... -> device_add() -> ... -> __device_attach() can't get * the device lock, so all the subchannels can't be processed -- * finally netvsc_subchan_work() hangs forever. + * + * The rtnl lock also needs to be held before rndis_filter_device_add() + * which advertises nvsp_2_vsc_capability / sriov bit, and triggers + * VF NIC offering and registering. If VF NIC finished register_netdev() + * earlier it may cause name based config failure. */ rtnl_lock(); + nvdev = rndis_filter_device_add(dev, device_info); + if (IS_ERR(nvdev)) { + ret = PTR_ERR(nvdev); + netdev_err(net, "unable to add netvsc device (ret %d)\n", ret); + goto rndis_failed; + } + + eth_hw_addr_set(net, device_info->mac_adr); + if (nvdev->num_chn > 1) schedule_work(&nvdev->subchan_work); @@ -2586,9 +2591,9 @@ static int netvsc_probe(struct hv_device *dev, return 0; register_failed: - rtnl_unlock(); rndis_filter_device_remove(dev, nvdev); rndis_failed: + rtnl_unlock(); netvsc_devinfo_put(device_info); devinfo_failed: free_percpu(net_device_ctx->vf_stats); -- 2.25.1

1 year, 1 month

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2023