- Linux-stable-mirror - lists.linaro.org

by Greg Kurz

The only users of free_spa() are alloc_link() and free_link(), and in both cases: - link->spa != NULL - free_spa(link) is immediatly followed by kfree(link) The check isn't needed, and it doesn't bring much to clear the link->spa pointer. Drop both. Signed-off-by: Greg Kurz <groug(a)kaod.org> --- drivers/misc/ocxl/link.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c index 31695a078485..eed92055184d 100644 --- a/drivers/misc/ocxl/link.c +++ b/drivers/misc/ocxl/link.c @@ -352,11 +352,8 @@ static void free_spa(struct link *link) pr_debug("Freeing SPA for %x:%x:%x\n", link->domain, link->bus, link->dev); - if (spa && spa->spa_mem) { - free_pages((unsigned long) spa->spa_mem, spa->spa_order); - kfree(spa); - link->spa = NULL; - } + free_pages((unsigned long) spa->spa_mem, spa->spa_order); + kfree(spa); } static int alloc_link(struct pci_dev *dev, int PE_mask, struct link **out_link)

6 years, 8 months

3
5
0 0

+ panic-avoid-the-extra-noise-dmesg.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: panic: Avoid the extra noise dmesg has been added to the -mm tree. Its filename is panic-avoid-the-extra-noise-dmesg.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/panic-avoid-the-extra-noise-dmesg.… and later at http://ozlabs.org/~akpm/mmotm/broken-out/panic-avoid-the-extra-noise-dmesg.… 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 and is updated there every 3-4 working days ------------------------------------------------------ From: Feng Tang <feng.tang(a)intel.com> Subject: panic: Avoid the extra noise dmesg When kernel panic happens, it will first print the panic call stack, then the ending msg like: [ 35.743249] ---[ end Kernel panic - not syncing: Fatal exception [ 35.749975] ------------[ cut here ]------------ The above message are very useful for debugging. But if system is configured to not reboot on panic, say the "panic_timeout" parameter equals 0, it will likely print out many noisy message like WARN() call stack for each and every CPU except the panic one, messages like below: WARNING: CPU: 1 PID: 280 at kernel/sched/core.c:1198 set_task_cpu+0x183/0x190 Call Trace: <IRQ> try_to_wake_up default_wake_function autoremove_wake_function __wake_up_common __wake_up_common_lock __wake_up wake_up_klogd_work_func irq_work_run_list irq_work_tick update_process_times tick_sched_timer __hrtimer_run_queues hrtimer_interrupt smp_apic_timer_interrupt apic_timer_interrupt For people working in console mode, the screen will first show the panic call stack, but immediately overridded by these noisy extra messages, which makes debugging much more difficult, as the original context gets lost on screen. Also these noisy messages will confuse some users, as I have seen many bug reporters posted the noisy message into bugzilla, instead of the real panic call stack and context. Removing the "local_irq_enable" will avoid the noisy message. The justification for the removing is: when code runs to this point, it means user has chosed to not reboot, or do any special handling by using the panic notifier method, no much point in re-enabling the interrupt. Link: http://lkml.kernel.org/r/1543902228-23834-1-git-send-email-feng.tang@intel.… Signed-off-by: Feng Tang <feng.tang(a)intel.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Kees Cook <keescook(a)chromium.org> Cc: Borislav Petkov <bp(a)suse.de> Cc: Petr Mladek <pmladek(a)suse.com> Cc: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- --- a/kernel/panic.c~panic-avoid-the-extra-noise-dmesg +++ a/kernel/panic.c @@ -322,7 +322,6 @@ void panic(const char *fmt, ...) } #endif pr_emerg("---[ end Kernel panic - not syncing: %s ]---\n", buf); - local_irq_enable(); for (i = 0; ; i += PANIC_TIMER_STEP) { touch_softlockup_watchdog(); if (i >= i_next) { _ Patches currently in -mm which might be from feng.tang(a)intel.com are panic-add-options-to-print-system-info-when-panic-happens.patch kernel-sysctl-add-panic_print-into-sysctl.patch panic-avoid-the-extra-noise-dmesg.patch

6 years, 8 months

4
24
0 0

[PATCH] ocxl: Fix endiannes bug in read_afu_name()

by Greg Kurz

The double word returned by read_afu_info(OCXL_DVSEC_TEMPL_NAME) contains four characters of the AFU name, read from the PCI config space, hence with a little-endian ordering. When composing the string, a big-endian system must swap the bytes so that the characters appear in the right order. Do this with le32_to_cpu(). Signed-off-by: Greg Kurz <groug(a)kaod.org> --- drivers/misc/ocxl/config.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/ocxl/config.c b/drivers/misc/ocxl/config.c index 57a6bb1fd3c9..b76198ba8630 100644 --- a/drivers/misc/ocxl/config.c +++ b/drivers/misc/ocxl/config.c @@ -318,7 +318,7 @@ static int read_afu_name(struct pci_dev *dev, struct ocxl_fn_config *fn, if (rc) return rc; ptr = (u32 *) &afu->name[i]; - *ptr = val; + *ptr = le32_to_cpu(val); } afu->name[OCXL_AFU_NAME_SZ - 1] = '\0'; /* play safe */ return 0;

6 years, 8 months

3
4
0 0

[PATCH] VSOCK: bind to random port for VMADDR_PORT_ANY

by Lepton Wu

The old code always starts from fixed port for VMADDR_PORT_ANY. Sometimes when VMM crashed, there is still orphaned vsock which is waiting for close timer, then it could cause connection time out for new started VM if they are trying to connect to same port with same guest cid since the new packets could hit that orphaned vsock. We could also fix this by doing more in vhost_vsock_reset_orphans, but any way, it should be better to start from a random local port instead of a fixed one. Signed-off-by: Lepton Wu <ytht.net(a)gmail.com> --- net/vmw_vsock/af_vsock.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c index ab27a2872935..73817e846a1f 100644 --- a/net/vmw_vsock/af_vsock.c +++ b/net/vmw_vsock/af_vsock.c @@ -107,6 +107,7 @@ #include <linux/mutex.h> #include <linux/net.h> #include <linux/poll.h> +#include <linux/random.h> #include <linux/skbuff.h> #include <linux/smp.h> #include <linux/socket.h> @@ -504,9 +505,12 @@ static void vsock_pending_work(struct work_struct *work) static int __vsock_bind_stream(struct vsock_sock *vsk, struct sockaddr_vm *addr) { - static u32 port = LAST_RESERVED_PORT + 1; + static u32 port = 0; struct sockaddr_vm new_addr; + if (!port) + port = prandom_u32(); + vsock_addr_init(&new_addr, addr->svm_cid, addr->svm_port); if (addr->svm_port == VMADDR_PORT_ANY) { -- 2.20.0.rc2.403.gdbc3b29805-goog

6 years, 8 months

2
1
0 0

[PATCH] mtd: atmel-quadspi: disallow building on ebsa110

by Arnd Bergmann

I ran into a link-time error with the atmel-quadspi driver on the EBSA110 platform: drivers/mtd/built-in.o: In function `atmel_qspi_run_command': :(.text+0x1ee3c): undefined reference to `_memcpy_toio' :(.text+0x1ee48): undefined reference to `_memcpy_fromio' The problem is that _memcpy_toio/_memcpy_fromio are not available on that platform, and we have to prevent building the driver there. In case we want to backport this to older kernels: between linux-4.8 and linux-4.20, the Kconfig entry was in drivers/mtd/spi-nor/Kconfig but had the same problem. Link: https://lore.kernel.org/patchwork/patch/812860/ Fixes: 161aaab8a067 ("mtd: atmel-quadspi: add driver for Atmel QSPI controller") Cc: stable(a)vger.kernel.org Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- drivers/spi/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 55d5ffb50750..9f89cb134549 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -93,7 +93,7 @@ config SPI_AT91_USART config SPI_ATMEL_QUADSPI tristate "Atmel Quad SPI Controller" - depends on ARCH_AT91 || (ARM && COMPILE_TEST) + depends on ARCH_AT91 || (ARM && COMPILE_TEST && !ARCH_EBSA110) depends on OF && HAS_IOMEM help This enables support for the Quad SPI controller in master mode. -- 2.18.0

6 years, 8 months

3
2
0 0

Re: [PATCH v6 1/3] mm: Add support for kmem caches in DMA32 zone

by Nicolas Boichat

Hi Sasha, On Tue, Dec 11, 2018 at 2:42 AM Sasha Levin <sashal(a)kernel.org> wrote: > > Hi, > > [This is an automated email] > > This commit has been processed because it contains a -stable tag. > The stable tag indicates that it's relevant for the following trees: all > > The bot has tested the following trees: v4.19.8, v4.14.87, v4.9.144, v4.4.166, v3.18.128, > > v4.19.8: Build OK! > v4.14.87: Failed to apply! Possible dependencies: > 4fd0b46e8987 ("slab, slub, slob: convert slab_flags_t to 32-bit") > a3ba07444782 ("mm/slab.c: only set __GFP_RECLAIMABLE once") > d50112edde1d ("slab, slub, slob: add slab_flags_t") > > v4.9.144: Failed to apply! Possible dependencies: > 04d348ae3f0a ("drm/i915/gvt: vGPU display virtualization") > 12d14cc43b34 ("drm/i915/gvt: Introduce a framework for tracking HW registers.") > 1b36595ffb35 ("drm/i915: Show RING registers through debugfs") > 28a60dee2ce6 ("drm/i915/gvt: vGPU HW resource management") > 3f728236c516 ("drm/i915/gvt: trace stub") > 4fd0b46e8987 ("slab, slub, slob: convert slab_flags_t to 32-bit") > 579cea5f30f2 ("drm/i915/gvt: golden virtual HW state management") > 5f0d5a3ae7cf ("mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU") > 73cb97010d4f ("drm/i915: Combine seqno + tracking into a global timeline struct") > 82d375d1b568 ("drm/i915/gvt: Introduce basic vGPU life cycle management") > 8453d674ae7e ("drm/i915/gvt: vGPU execlist virtualization") > a933568eb61d ("drm/i915: Tidy slab cache allocations") > c8fe6a6811a7 ("drm/i915/gvt: vGPU interrupt virtualization.") > d50112edde1d ("slab, slub, slob: add slab_flags_t") > e39c5add3221 ("drm/i915/gvt: vGPU MMIO virtualization") > e473405783c0 ("drm/i915/gvt: vGPU workload scheduler") > e95433c73a11 ("drm/i915: Rearrange i915_wait_request() accounting with callers") > > v4.4.166: Failed to apply! Possible dependencies: > 10b2e9e8e808 ("mm/slab: factor out debugging initialization in cache_init_objs()") > 40b44137971c ("mm/slab: clean up DEBUG_PAGEALLOC processing code") > 4fd0b46e8987 ("slab, slub, slob: convert slab_flags_t to 32-bit") > 505f5dcb1c41 ("mm, kasan: add GFP flags to KASAN API") > 55834c59098d ("mm: kasan: initial memory quarantine implementation") > 5d097056c9a0 ("kmemcg: account certain kmem allocations to memcg") > 7ed2f9e66385 ("mm, kasan: SLAB support") > 832a15d209cd ("mm/slab: align cache size first before determination of OFF_SLAB candidate") > a307ebd468e0 ("mm/slab: activate debug_pagealloc in SLAB when it is actually enabled") > d50112edde1d ("slab, slub, slob: add slab_flags_t") > > v3.18.128: Failed to apply! Possible dependencies: > 081fa9dffcde ("staging/lustre/llite: remove llite proc root on init failure") > 12cf89b550d1 ("livepatch: rename config to CONFIG_LIVEPATCH") > 13d1cf7e7025 ("livepatch: samples: add sample live patching module") > 31e7213ab21e ("drivers: staging: lustre: Fix "spaces required around that '='" errors") > 32b7eb877165 ("livepatch: change ARCH_HAVE_LIVE_PATCHING to HAVE_LIVE_PATCHING") > 4fd0b46e8987 ("slab, slub, slob: convert slab_flags_t to 32-bit") > 5aaeb5c01c5b ("x86/fpu, sched: Introduce CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT and use it on x86") > 5d097056c9a0 ("kmemcg: account certain kmem allocations to memcg") > 6471b825c41e ("x86/kconfig: Reorganize arch feature Kconfig select's") > 6e0a0ea12962 ("ACPI / sleep: Introduce CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT") > 83ac237a950e ("livepatch: kconfig: use bool instead of boolean") > 957e3facd147 ("gcov: enable GCOV_PROFILE_ALL from ARCH Kconfigs") > b700e7f03df5 ("livepatch: kernel: add support for live patching") > b9dfe0bed999 ("livepatch: handle ancient compilers with more grace") > d50112edde1d ("slab, slub, slob: add slab_flags_t") > > > How should we proceed with this patch? I'm not sure how we need to handle this. 2/3 in this series (https://patchwork.kernel.org/patch/10720495/) is the patch that matters, and has correct Fixes/Cc tag (this only needs to apply >=4.15). I added Cc: stable@ to this patch, as it is a dependency of 2/3. Should I remove Cc: stable from this patch? Or add Fixes: line? Thanks, Nicolas > -- > Thanks, > Sasha

6 years, 8 months

2
2
0 0

x86: e820 regression

by Erick Cafferata

The following commit introduced a regression on my system. 124049decbb121ec32742c94fb5d9d6bed8f24d8 x86/e820: put !E820_TYPE_RAM regions into memblock.reserved and it was backported to stable, stopping the kernel to boot on my system since around 4.17.4. It was reverted on upstream a couple months ago. commit 2a5bda5a624d6471d25e953b9adba5182ab1b51f upstream There are some other modifications to the file after that. However, at the very least, can the revert be backported? I think the original patch tries to fix a previous bug, so probably the latest commits fixed that one correctly and need to be backported as well.

6 years, 8 months

4
11
0 0

+ lib-fix-build-failure-in-config_debug_virtual-test.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: lib/test_debug_virtual.c: fix build failure has been added to the -mm tree. Its filename is lib-fix-build-failure-in-config_debug_virtual-test.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/lib-fix-build-failure-in-config_de… and later at http://ozlabs.org/~akpm/mmotm/broken-out/lib-fix-build-failure-in-config_de… 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 and is updated there every 3-4 working days ------------------------------------------------------ From: Christophe Leroy <christophe.leroy(a)c-s.fr> Subject: lib/test_debug_virtual.c: fix build failure On several arches, virt_to_phys() is in io.h Build fails without it: CC lib/test_debug_virtual.o lib/test_debug_virtual.c: In function 'test_debug_virtual_init': lib/test_debug_virtual.c:26:7: error: implicit declaration of function 'virt_to_phys' [-Werror=implicit-function-declaration] pa = virt_to_phys(va); ^ Link: http://lkml.kernel.org/r/40d63adb6058b1fbb4082ca6f15225cb6e76bd62.154442917… Fixes: e4dace361552 ("lib: add test module for CONFIG_DEBUG_VIRTUAL") Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr> Reviewed-by: Kees Cook <keescook(a)chromium.org> Cc: Colin King <colin.king(a)canonical.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- --- a/lib/test_debug_virtual.c~lib-fix-build-failure-in-config_debug_virtual-test +++ a/lib/test_debug_virtual.c @@ -5,6 +5,7 @@ #include <linux/vmalloc.h> #include <linux/slab.h> #include <linux/sizes.h> +#include <linux/io.h> #include <asm/page.h> #ifdef CONFIG_MIPS _ Patches currently in -mm which might be from christophe.leroy(a)c-s.fr are lib-fix-build-failure-in-config_debug_virtual-test.patch

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] arm64: dts: rockchip: remove vdd_log from rock960 to fix a" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-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>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 13682e524167cbd7e2a26c5e91bec765f0f96273 Mon Sep 17 00:00:00 2001 From: Daniel Lezcano <daniel.lezcano(a)linaro.org> Date: Wed, 17 Oct 2018 11:18:30 +0200 Subject: [PATCH] arm64: dts: rockchip: remove vdd_log from rock960 to fix a stability issues When the performance governor is set as default, the rock960 hangs around one minute after booting, whatever the activity is (idle, key pressed, loaded, ...). Based on the commit log found at https://patchwork.kernel.org/patch/10092377/ "vdd_log has no consumer and therefore will not be set to a specific voltage. Still the PWM output pin gets configured and thence the vdd_log output voltage will changed from it's default. Depending on the idle state of the PWM this will slightly over or undervoltage the logic supply of the RK3399 and cause instability with GbE (undervoltage) and PCIe (overvoltage). Since the default value set by a voltage divider is the correct supply voltage and we don't need to change it during runtime we remove the rail from the devicetree completely so the PWM pin will not be configured." After removing the vdd-log from the rock960's specific DT, the board does no longer hang and shows a stable behavior. Apply the same change for the rock960 by removing the vdd-log from the DT. Fixes: 874846f1fccd ("arm64: dts: rockchip: add 96boards RK3399 Ficus board") Cc: stable(a)vger.kernel.org Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi index 6c8c4ab044aa..56abbb08c133 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi @@ -57,18 +57,6 @@ regulator-always-on; vin-supply = <&vcc_sys>; }; - - vdd_log: vdd-log { - compatible = "pwm-regulator"; - pwms = <&pwm2 0 25000 0>; - regulator-name = "vdd_log"; - regulator-min-microvolt = <800000>; - regulator-max-microvolt = <1400000>; - regulator-always-on; - regulator-boot-on; - vin-supply = <&vcc_sys>; - }; - }; &cpu_l0 {

6 years, 8 months

2
1
0 0

FAILED: patch "[PATCH] vhost/vsock: fix use-after-free in network stack callers" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-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>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 834e772c8db0c6a275d75315d90aba4ebbb1e249 Mon Sep 17 00:00:00 2001 From: Stefan Hajnoczi <stefanha(a)redhat.com> Date: Mon, 5 Nov 2018 10:35:47 +0000 Subject: [PATCH] vhost/vsock: fix use-after-free in network stack callers If the network stack calls .send_pkt()/.cancel_pkt() during .release(), a struct vhost_vsock use-after-free is possible. This occurs because .release() does not wait for other CPUs to stop using struct vhost_vsock. Switch to an RCU-enabled hashtable (indexed by guest CID) so that .release() can wait for other CPUs by calling synchronize_rcu(). This also eliminates vhost_vsock_lock acquisition in the data path so it could have a positive effect on performance. This is CVE-2018-14625 "kernel: use-after-free Read in vhost_transport_send_pkt". Cc: stable(a)vger.kernel.org Reported-and-tested-by: syzbot+bd391451452fb0b93039(a)syzkaller.appspotmail.com Reported-by: syzbot+e3e074963495f92a89ed(a)syzkaller.appspotmail.com Reported-by: syzbot+d5a0a170c5069658b141(a)syzkaller.appspotmail.com Signed-off-by: Stefan Hajnoczi <stefanha(a)redhat.com> Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Acked-by: Jason Wang <jasowang(a)redhat.com> diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c index 731e2ea2aeca..98ed5be132c6 100644 --- a/drivers/vhost/vsock.c +++ b/drivers/vhost/vsock.c @@ -15,6 +15,7 @@ #include <net/sock.h> #include <linux/virtio_vsock.h> #include <linux/vhost.h> +#include <linux/hashtable.h> #include <net/af_vsock.h> #include "vhost.h" @@ -27,14 +28,14 @@ enum { /* Used to track all the vhost_vsock instances on the system. */ static DEFINE_SPINLOCK(vhost_vsock_lock); -static LIST_HEAD(vhost_vsock_list); +static DEFINE_READ_MOSTLY_HASHTABLE(vhost_vsock_hash, 8); struct vhost_vsock { struct vhost_dev dev; struct vhost_virtqueue vqs[2]; - /* Link to global vhost_vsock_list, protected by vhost_vsock_lock */ - struct list_head list; + /* Link to global vhost_vsock_hash, writes use vhost_vsock_lock */ + struct hlist_node hash; struct vhost_work send_pkt_work; spinlock_t send_pkt_list_lock; @@ -50,11 +51,14 @@ static u32 vhost_transport_get_local_cid(void) return VHOST_VSOCK_DEFAULT_HOST_CID; } -static struct vhost_vsock *__vhost_vsock_get(u32 guest_cid) +/* Callers that dereference the return value must hold vhost_vsock_lock or the + * RCU read lock. + */ +static struct vhost_vsock *vhost_vsock_get(u32 guest_cid) { struct vhost_vsock *vsock; - list_for_each_entry(vsock, &vhost_vsock_list, list) { + hash_for_each_possible_rcu(vhost_vsock_hash, vsock, hash, guest_cid) { u32 other_cid = vsock->guest_cid; /* Skip instances that have no CID yet */ @@ -69,17 +73,6 @@ static struct vhost_vsock *__vhost_vsock_get(u32 guest_cid) return NULL; } -static struct vhost_vsock *vhost_vsock_get(u32 guest_cid) -{ - struct vhost_vsock *vsock; - - spin_lock_bh(&vhost_vsock_lock); - vsock = __vhost_vsock_get(guest_cid); - spin_unlock_bh(&vhost_vsock_lock); - - return vsock; -} - static void vhost_transport_do_send_pkt(struct vhost_vsock *vsock, struct vhost_virtqueue *vq) @@ -210,9 +203,12 @@ vhost_transport_send_pkt(struct virtio_vsock_pkt *pkt) struct vhost_vsock *vsock; int len = pkt->len; + rcu_read_lock(); + /* Find the vhost_vsock according to guest context id */ vsock = vhost_vsock_get(le64_to_cpu(pkt->hdr.dst_cid)); if (!vsock) { + rcu_read_unlock(); virtio_transport_free_pkt(pkt); return -ENODEV; } @@ -225,6 +221,8 @@ vhost_transport_send_pkt(struct virtio_vsock_pkt *pkt) spin_unlock_bh(&vsock->send_pkt_list_lock); vhost_work_queue(&vsock->dev, &vsock->send_pkt_work); + + rcu_read_unlock(); return len; } @@ -234,12 +232,15 @@ vhost_transport_cancel_pkt(struct vsock_sock *vsk) struct vhost_vsock *vsock; struct virtio_vsock_pkt *pkt, *n; int cnt = 0; + int ret = -ENODEV; LIST_HEAD(freeme); + rcu_read_lock(); + /* Find the vhost_vsock according to guest context id */ vsock = vhost_vsock_get(vsk->remote_addr.svm_cid); if (!vsock) - return -ENODEV; + goto out; spin_lock_bh(&vsock->send_pkt_list_lock); list_for_each_entry_safe(pkt, n, &vsock->send_pkt_list, list) { @@ -265,7 +266,10 @@ vhost_transport_cancel_pkt(struct vsock_sock *vsk) vhost_poll_queue(&tx_vq->poll); } - return 0; + ret = 0; +out: + rcu_read_unlock(); + return ret; } static struct virtio_vsock_pkt * @@ -533,10 +537,6 @@ static int vhost_vsock_dev_open(struct inode *inode, struct file *file) spin_lock_init(&vsock->send_pkt_list_lock); INIT_LIST_HEAD(&vsock->send_pkt_list); vhost_work_init(&vsock->send_pkt_work, vhost_transport_send_pkt_work); - - spin_lock_bh(&vhost_vsock_lock); - list_add_tail(&vsock->list, &vhost_vsock_list); - spin_unlock_bh(&vhost_vsock_lock); return 0; out: @@ -585,9 +585,13 @@ static int vhost_vsock_dev_release(struct inode *inode, struct file *file) struct vhost_vsock *vsock = file->private_data; spin_lock_bh(&vhost_vsock_lock); - list_del(&vsock->list); + if (vsock->guest_cid) + hash_del_rcu(&vsock->hash); spin_unlock_bh(&vhost_vsock_lock); + /* Wait for other CPUs to finish using vsock */ + synchronize_rcu(); + /* Iterating over all connections for all CIDs to find orphans is * inefficient. Room for improvement here. */ vsock_for_each_connected_socket(vhost_vsock_reset_orphans); @@ -628,12 +632,17 @@ static int vhost_vsock_set_cid(struct vhost_vsock *vsock, u64 guest_cid) /* Refuse if CID is already in use */ spin_lock_bh(&vhost_vsock_lock); - other = __vhost_vsock_get(guest_cid); + other = vhost_vsock_get(guest_cid); if (other && other != vsock) { spin_unlock_bh(&vhost_vsock_lock); return -EADDRINUSE; } + + if (vsock->guest_cid) + hash_del_rcu(&vsock->hash); + vsock->guest_cid = guest_cid; + hash_add_rcu(vhost_vsock_hash, &vsock->hash, guest_cid); spin_unlock_bh(&vhost_vsock_lock); return 0;

6 years, 8 months

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror