Re: [PATCH net] net: mana: Cleanup "mana" debugfs dir after cleanup of all children

2025-01-10 Thread patchwork-bot+netdevbpf
Hello: This patch was applied to netdev/net.git (main) by Jakub Kicinski : On Wed, 8 Jan 2025 21:03:11 -0800 you wrote: > In mana_driver_exit(), mana_debugfs_root gets cleanup before any of it's > children (which happens later in the pci_unregister_driver()). > Due to this, when mana driver is c

[PATCH v2 2/2] drivers/hv: add CPU offlining support

2025-01-10 Thread Hamza Mahfooz
Currently, it is effectively impossible to offline CPUs. Since, most CPUs will have vmbus channels attached to them. So, as made mention of in commit d570aec0f2154 ("Drivers: hv: vmbus: Synchronize init_vp_index() vs. CPU hotplug"), rebind channels associated with CPUs that a user is trying to offl

[PATCH v2 1/2] drivers/hv: introduce vmbus_channel_set_cpu()

2025-01-10 Thread Hamza Mahfooz
I would like to reuse target_cpu_store() within the driver. So, move most of it's body into vmbus_channel_set_cpu(). Cc: Boqun Feng Cc: Wei Liu Signed-off-by: Hamza Mahfooz --- v2: separate vmbus_channel_set_cpu() changes from cpu offlining changes. --- drivers/hv/vmbus_drv.c | 52

Re: [PATCH] scsi: storvsc: Ratelimit warning logs to prevent VM denial of service

2025-01-10 Thread Martin K. Petersen
Easwar, > If there's a persistent error in the hypervisor, the scsi warning for > failed IO can flood the kernel log and max out CPU utilization, > preventing troubleshooting from the VM side. Ratelimit the warning so > it doesn't DOS the VM. Applied to 6.14/scsi-staging, thanks! -- Martin K.

Re: [PATCH] drivers/hv: add CPU offlining support

2025-01-10 Thread Boqun Feng
Hi Hamza, Thanks for the patch, a few comments below: On Fri, Jan 10, 2025 at 03:05:06PM -0500, Hamza Mahfooz wrote: > Currently, it is effectively impossible to offline CPUs. Since, most > CPUs will have vmbus channels attached to them. So, as made mention of > in commit d570aec0f2154 ("Drivers:

[PATCH] drivers/hv: add CPU offlining support

2025-01-10 Thread Hamza Mahfooz
Currently, it is effectively impossible to offline CPUs. Since, most CPUs will have vmbus channels attached to them. So, as made mention of in commit d570aec0f2154 ("Drivers: hv: vmbus: Synchronize init_vp_index() vs. CPU hotplug"), rebind channels associated with CPUs that a user is trying to offl

Re: [PATCH v2] treewide: const qualify ctl_tables where applicable

2025-01-10 Thread Anna Schumaker
On 1/10/25 9:16 AM, Joel Granados wrote: > Add the const qualifier to all the ctl_tables in the tree except for > watchdog_hardlockup_sysctl, memory_allocation_profiling_sysctls, > loadpin_sysctl_table and the ones calling register_net_sysctl (./net, > drivers/inifiniband dirs). These are specia

RE: [v2 PATCH] rhashtable: Fix rhashtable_try_insert test

2025-01-10 Thread Michael Kelley
From: Herbert Xu Sent: Friday, January 10, 2025 9:24 AM > > On Fri, Jan 10, 2025 at 04:59:28PM +, Michael Kelley wrote: > > > > This patch fixes the problem I saw with VMs in the Azure cloud. Thanks! > > Sorry, but the test on data is needed after all (it was just > buggy). Otherwise we w

[v2 PATCH] rhashtable: Fix rhashtable_try_insert test

2025-01-10 Thread Herbert Xu
On Fri, Jan 10, 2025 at 04:59:28PM +, Michael Kelley wrote: > > This patch fixes the problem I saw with VMs in the Azure cloud. Thanks! Sorry, but the test on data is needed after all (it was just buggy). Otherwise we will break rhlist. So please test this patch instead. ---8<--- The test

Re: [PATCH] treewide: const qualify ctl_tables where applicable

2025-01-10 Thread Dixit, Ashutosh
On Thu, 09 Jan 2025 05:16:39 -0800, Joel Granados wrote: > > diff --git a/drivers/gpu/drm/i915/i915_perf.c > b/drivers/gpu/drm/i915/i915_perf.c > index 2406cda75b7b..5384d1bb4923 100644 > --- a/drivers/gpu/drm/i915/i915_perf.c > +++ b/drivers/gpu/drm/i915/i915_perf.c > @@ -4802,7 +4802,7 @@ int i9

RE: [PATCH] rhashtable: Fix potential deadlock by moving schedule_work outside lock

2025-01-10 Thread Michael Kelley
From: Herbert Xu Sent: Friday, January 10, 2025 1:28 AM > > On Thu, Jan 09, 2025 at 02:15:17AM -0800, Breno Leitao wrote: > > > > I would suggest we revert this patch until we investigate further. I'll > > prepare and send a revert patch shortly. > > Sorry, I think it was my addition that broke

Re: [PATCH] rhashtable: Fix potential deadlock by moving schedule_work outside lock

2025-01-10 Thread Zaslonko Mikhail
Herbert and Breno, On 10.01.2025 10:27, Herbert Xu wrote: > On Thu, Jan 09, 2025 at 02:15:17AM -0800, Breno Leitao wrote: > > Reported-by: Michael Kelley > Fixes: e1d3422c95f0 ("rhashtable: Fix potential deadlock by moving > schedule_work outside lock") > Signed-off-by: Herbert Xu > > diff --

[PATCH v2] treewide: const qualify ctl_tables where applicable

2025-01-10 Thread Joel Granados
Add the const qualifier to all the ctl_tables in the tree except for watchdog_hardlockup_sysctl, memory_allocation_profiling_sysctls, loadpin_sysctl_table and the ones calling register_net_sysctl (./net, drivers/inifiniband dirs). These are special cases as they use a registration function with a n

Re: [PATCH] rhashtable: Fix potential deadlock by moving schedule_work outside lock

2025-01-10 Thread Herbert Xu
On Fri, Jan 10, 2025 at 01:49:44AM -0800, Breno Leitao wrote: > > That is what I though originally as well, but I was not convinced. While > reading the code, I understood that, if new_tbl is not NULL, then > PTR_ERR(data) will be -ENOENT. > > In which case `net_tbl` will not be NULL, and PTR_ERR(

Re: [PATCH] rhashtable: Fix potential deadlock by moving schedule_work outside lock

2025-01-10 Thread Breno Leitao
Hello Herbet, On Fri, Jan 10, 2025 at 05:27:49PM +0800, Herbert Xu wrote: > Sorry, I think it was my addition that broke things. The condition > for checking whether an entry is inserted is incorrect, thus resulting > in an underflow of the number of entries after entry removal. That is what I

Re: [PATCH] rhashtable: Fix potential deadlock by moving schedule_work outside lock

2025-01-10 Thread Herbert Xu
On Thu, Jan 09, 2025 at 02:15:17AM -0800, Breno Leitao wrote: > > I would suggest we revert this patch until we investigate further. I'll > prepare and send a revert patch shortly. Sorry, I think it was my addition that broke things. The condition for checking whether an entry is inserted is inco