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

[PATCH v3 1/3] acpi: introduce acpi_arch_get_root_pointer() for getting rsdp address

by Juergen Gross

Add an architecture specific function to get the address of the RSDP table. Per default it will just return 0 indicating falling back to the current mechanism. Cc: <stable(a)vger.kernel.org> # 4.11 Signed-off-by: Juergen Gross <jgross(a)suse.com> --- drivers/acpi/osl.c | 5 ++++- include/linux/acpi.h | 7 +++++++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c index 3bb46cb24a99..ff812243bac3 100644 --- a/drivers/acpi/osl.c +++ b/drivers/acpi/osl.c @@ -189,12 +189,15 @@ early_param("acpi_rsdp", setup_acpi_rsdp); acpi_physical_address __init acpi_os_get_root_pointer(void) { - acpi_physical_address pa = 0; + acpi_physical_address pa; #ifdef CONFIG_KEXEC if (acpi_rsdp) return acpi_rsdp; #endif + pa = acpi_arch_get_root_pointer(); + if (pa) + return pa; if (efi_enabled(EFI_CONFIG_TABLES)) { if (efi.acpi20 != EFI_INVALID_TABLE_ADDR) diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 968173ec2726..15bfb15c2fa5 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -623,6 +623,13 @@ bool acpi_gtdt_c3stop(int type); int acpi_arch_timer_mem_init(struct arch_timer_mem *timer_mem, int *timer_count); #endif +#ifndef ACPI_HAVE_ARCH_GET_ROOT_POINTER +static inline u64 acpi_arch_get_root_pointer(void) +{ + return 0; +} +#endif + #else /* !CONFIG_ACPI */ #define acpi_disabled 1 -- 2.13.6

7 years, 4 months

1
0
0 0

Re: [PATCH] x86/mm/kaiser: avoid 32-bit/PAE build warning

by Arnd Bergmann

On Wed, Dec 6, 2017 at 4:08 PM, Dave Hansen <dave.hansen(a)linux.intel.com> wrote: > On 12/06/2017 07:03 AM, Arnd Bergmann wrote: >> On Wed, Dec 6, 2017 at 3:15 PM, Arnd Bergmann <arnd(a)arndb.de> wrote: >> >>> This changes the type to u64 in the architecture-independent dummy, >>> and to pteval_t in the x86 specific portion that is used when KAISER >>> is enabled, ensuring that the flags can always fit. Unfortunately, >>> pteval_t is not provided by most other architectures, so we are >>> a little bit inconsistent here. >> >> I ran into a new regression with my patch applied, after doing more randconfig >> builds: >> >> In file included from /git/arm-soc/include/linux/kaiser.h:5, >> from /git/arm-soc/arch/x86/events/intel/ds.c:4: >> arch/x86/include/asm/kaiser.h:34:10: error: unknown type name >> 'pteval_t'; did you mean 'dev_t'? >> >> Maybe it's better to just to the last one-line change in include/linux/kaiser.h. > > Hi Arnd, > > Are you hitting this in -next? > > The newest version of this code has a single kpti_init() function that > shouldn't have any of these problems. Coming back to an old thread... I did some randconfig testing on 4.9.80, and now I see the same problem there, since that version uses the KAISER patches rather than PTI: /git/arm-soc/arch/x86/kernel/ldt.c: In function 'alloc_ldt_struct': /git/arm-soc/arch/x86/include/asm/pgtable_types.h:208:24: error: large integer implicitly truncated to unsigned type [-Werror=overflow] #define __PAGE_KERNEL (__PAGE_KERNEL_EXEC | _PAGE_NX) ^ /git/arm-soc/arch/x86/kernel/ldt.c:81:6: note: in expansion of macro '__PAGE_KERNEL' __PAGE_KERNEL); ^~~~~~~~~~~~~ I also saw another warning: /git/arm-soc/arch/x86/mm/kaiser.c: In function 'kaiser_init': /git/arm-soc/arch/x86/mm/kaiser.c:347:8: error: 'vsyscall_pgprot' undeclared (first use in this function); did you mean 'massage_pgprot'? I can send this as proper patches for inclusion in 4.9-stable, unless someone has a better idea or finds a problem Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> diff --git a/include/linux/kaiser.h b/include/linux/kaiser.h index 58c55b1589d0..b56c19010480 100644 --- a/include/linux/kaiser.h +++ b/include/linux/kaiser.h @@ -32,7 +32,7 @@ static inline void kaiser_init(void) { } static inline int kaiser_add_mapping(unsigned long addr, - unsigned long size, unsigned long flags) + unsigned long size, u64 flags) { return 0; } --- a/arch/x86/include/asm/vsyscall.h +++ b/arch/x86/include/asm/vsyscall.h @@ -13,7 +13,6 @@ extern void map_vsyscall(void); */ extern bool emulate_vsyscall(struct pt_regs *regs, unsigned long address); extern bool vsyscall_enabled(void); -extern unsigned long vsyscall_pgprot; #else static inline void map_vsyscall(void) {} static inline bool emulate_vsyscall(struct pt_regs *regs, unsigned long address) @@ -23,4 +22,6 @@ static inline bool emulate_vsyscall(struct pt_regs *regs, unsigned long address) static inline bool vsyscall_enabled(void) { return false; } #endif +extern unsigned long vsyscall_pgprot; + #endif /* _ASM_X86_VSYSCALL_H */ Arnd

7 years, 4 months

2
5
0 0

[PATCH v4] extcon: int3496: process id-pin first so that we start with the right status

by Hans de Goede

Some other drivers may be waiting for our extcon to show-up, exiting their probe methods with -EPROBE_DEFER until we show up. These drivers will typically get the cable state directly after getting the extcon, this commit changes the int3496 code to wait for the initial processing of the id-pin to complete before exiting probe() with 0, which will cause devices waiting on the defered probe to get reprobed. This fixes a race where the initial work might still be running while other drivers were already calling extcon_get_state(). Fixes: 2f556bdb9f2e ("extcon: int3496: Add Intel INT3496 ACPI ... driver") Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- Changes in v2: -Add Fixes tag Changes in v3: -Fix oops on probe by scheduling the work too early Changes in v4: -Ugh sorry about this, but we cannot call extcon_set_state() before extcon_dev_register() at all because before registration the cable array is not yet allocated. Instead wait for the initial processing of the id-pin to complete before exiting probe(). --- drivers/extcon/extcon-intel-int3496.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/extcon/extcon-intel-int3496.c b/drivers/extcon/extcon-intel-int3496.c index c8691b5a9cb0..191e99f06a9a 100644 --- a/drivers/extcon/extcon-intel-int3496.c +++ b/drivers/extcon/extcon-intel-int3496.c @@ -153,8 +153,9 @@ static int int3496_probe(struct platform_device *pdev) return ret; } - /* queue initial processing of id-pin */ + /* process id-pin so that we start with the right status */ queue_delayed_work(system_wq, &data->work, 0); + flush_delayed_work(&data->work); platform_set_drvdata(pdev, data); -- 2.14.3

7 years, 4 months

2
1
0 0

Patch "RDMA/rxe: Fix a race condition related to the QP error state" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDMA/rxe: Fix a race condition related to the QP error state to the 4.9-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: rdma-rxe-fix-a-race-condition-related-to-the-qp-error-state.patch and it can be found in the queue-4.9 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. >From 6f301e06de4cf9ab7303f5acd43e64fcd4aa04be Mon Sep 17 00:00:00 2001 From: Bart Van Assche <bart.vanassche(a)wdc.com> Date: Tue, 9 Jan 2018 11:23:40 -0800 Subject: RDMA/rxe: Fix a race condition related to the QP error state From: Bart Van Assche <bart.vanassche(a)wdc.com> commit 6f301e06de4cf9ab7303f5acd43e64fcd4aa04be upstream. The following sequence: * Change queue pair state into IB_QPS_ERR. * Post a work request on the queue pair. Triggers the following race condition in the rdma_rxe driver: * rxe_qp_error() triggers an asynchronous call of rxe_completer(), the function that examines the QP send queue. * rxe_post_send() posts a work request on the QP send queue. If rxe_completer() runs prior to rxe_post_send(), it will drain the send queue and the driver will assume no further action is necessary. However, once we post the send to the send queue, because the queue is in error, no send completion will ever happen and the send will get stuck. In order to process the send, we need to make sure that rxe_completer() gets run after a send is posted to a queue pair in an error state. This patch ensures that happens. Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Moni Shoua <monis(a)mellanox.com> Cc: <stable(a)vger.kernel.org> # v4.8 Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/sw/rxe/rxe_verbs.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/infiniband/sw/rxe/rxe_verbs.c +++ b/drivers/infiniband/sw/rxe/rxe_verbs.c @@ -848,6 +848,8 @@ static int rxe_post_send_kernel(struct r (queue_count(qp->sq.queue) > 1); rxe_run_task(&qp->req.task, must_sched); + if (unlikely(qp->req.state == QP_STATE_ERROR)) + rxe_run_task(&qp->comp.task, 1); return err; } Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are queue-4.9/rdma-rxe-fix-a-race-condition-related-to-the-qp-error-state.patch

7 years, 4 months

1
0
0 0

Patch "kselftest: fix OOM in memory compaction test" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled kselftest: fix OOM in memory compaction test to the 4.9-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: kselftest-fix-oom-in-memory-compaction-test.patch and it can be found in the queue-4.9 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. >From 4c1baad223906943b595a887305f2e8124821dad Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Tue, 9 Jan 2018 17:26:24 +0100 Subject: kselftest: fix OOM in memory compaction test From: Arnd Bergmann <arnd(a)arndb.de> commit 4c1baad223906943b595a887305f2e8124821dad upstream. Running the compaction_test sometimes results in out-of-memory failures. When I debugged this, it turned out that the code to reset the number of hugepages to the initial value is simply broken since we write into an open sysctl file descriptor multiple times without seeking back to the start. Adding the lseek here fixes the problem. Cc: stable(a)vger.kernel.org Reported-by: Naresh Kamboju <naresh.kamboju(a)linaro.org> Link: https://bugs.linaro.org/show_bug.cgi?id=3145 Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/vm/compaction_test.c | 2 ++ 1 file changed, 2 insertions(+) --- a/tools/testing/selftests/vm/compaction_test.c +++ b/tools/testing/selftests/vm/compaction_test.c @@ -136,6 +136,8 @@ int check_compaction(unsigned long mem_f printf("No of huge pages allocated = %d\n", (atoi(nr_hugepages))); + lseek(fd, 0, SEEK_SET); + if (write(fd, initial_nr_hugepages, strlen(initial_nr_hugepages)) != strlen(initial_nr_hugepages)) { perror("Failed to write value to /proc/sys/vm/nr_hugepages\n"); Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.9/kselftest-fix-oom-in-memory-compaction-test.patch

7 years, 4 months

1
0
0 0

Patch "IB/qib: Fix comparison error with qperf compare/swap test" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/qib: Fix comparison error with qperf compare/swap test to the 4.9-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: ib-qib-fix-comparison-error-with-qperf-compare-swap-test.patch and it can be found in the queue-4.9 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. >From 87b3524cb5058fdc7c2afdb92bdb2e079661ddc4 Mon Sep 17 00:00:00 2001 From: Mike Marciniszyn <mike.marciniszyn(a)intel.com> Date: Tue, 14 Nov 2017 04:34:52 -0800 Subject: IB/qib: Fix comparison error with qperf compare/swap test From: Mike Marciniszyn <mike.marciniszyn(a)intel.com> commit 87b3524cb5058fdc7c2afdb92bdb2e079661ddc4 upstream. This failure exists with qib: ver_rc_compare_swap: mismatch, sequence 2, expected 123456789abcdef, got 0 The request builder was using the incorrect inlines to build the request header resulting in incorrect data in the atomic header. Fix by using the appropriate inlines to create the request. Fixes: 261a4351844b ("IB/qib,IB/hfi: Use core common header file") Reviewed-by: Michael J. Ruhl <michael.j.ruhl(a)intel.com> Signed-off-by: Mike Marciniszyn <mike.marciniszyn(a)intel.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/qib/qib_rc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/infiniband/hw/qib/qib_rc.c +++ b/drivers/infiniband/hw/qib/qib_rc.c @@ -443,13 +443,13 @@ no_flow_control: qp->s_state = OP(COMPARE_SWAP); put_ib_ateth_swap(wqe->atomic_wr.swap, &ohdr->u.atomic_eth); - put_ib_ateth_swap(wqe->atomic_wr.compare_add, - &ohdr->u.atomic_eth); + put_ib_ateth_compare(wqe->atomic_wr.compare_add, + &ohdr->u.atomic_eth); } else { qp->s_state = OP(FETCH_ADD); put_ib_ateth_swap(wqe->atomic_wr.compare_add, &ohdr->u.atomic_eth); - put_ib_ateth_swap(0, &ohdr->u.atomic_eth); + put_ib_ateth_compare(0, &ohdr->u.atomic_eth); } put_ib_ateth_vaddr(wqe->atomic_wr.remote_addr, &ohdr->u.atomic_eth); Patches currently in stable-queue which might be from mike.marciniszyn(a)intel.com are queue-4.9/ib-qib-fix-comparison-error-with-qperf-compare-swap-test.patch

7 years, 4 months

1
0
0 0

Patch "IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports to the 4.9-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: ib-mlx4-fix-incorrectly-releasing-steerable-ud-qps-when-have-only-eth-ports.patch and it can be found in the queue-4.9 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. >From 852f6927594d0d3e8632c889b2ab38cbc46476ad Mon Sep 17 00:00:00 2001 From: Jack Morgenstein <jackm(a)dev.mellanox.co.il> Date: Fri, 12 Jan 2018 07:58:40 +0200 Subject: IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports From: Jack Morgenstein <jackm(a)dev.mellanox.co.il> commit 852f6927594d0d3e8632c889b2ab38cbc46476ad upstream. Allocating steerable UD QPs depends on having at least one IB port, while releasing those QPs does not. As a result, when there are only ETH ports, the IB (RoCE) driver requests releasing a qp range whose base qp is zero, with qp count zero. When SR-IOV is enabled, and the VF driver is running on a VM over a hypervisor which treats such qp release calls as errors (rather than NOPs), we see lines in the VM message log like: mlx4_core 0002:00:02.0: Failed to release qp range base:0 cnt:0 Fix this by adding a check for a zero count in mlx4_release_qp_range() (which thus treats releasing 0 qps as a nop), and eliminating the check for device managed flow steering when releasing steerable UD QPs. (Freeing ib_uc_qpns_bitmap unconditionally is also OK, since it remains NULL when steerable UD QPs are not allocated). Fixes: 4196670be786 ("IB/mlx4: Don't allocate range of steerable UD QPs for Ethernet-only device") Signed-off-by: Jack Morgenstein <jackm(a)dev.mellanox.co.il> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/mlx4/main.c | 13 +++++-------- drivers/net/ethernet/mellanox/mlx4/qp.c | 3 +++ 2 files changed, 8 insertions(+), 8 deletions(-) --- a/drivers/infiniband/hw/mlx4/main.c +++ b/drivers/infiniband/hw/mlx4/main.c @@ -2928,9 +2928,8 @@ err_steer_free_bitmap: kfree(ibdev->ib_uc_qpns_bitmap); err_steer_qp_release: - if (ibdev->steering_support == MLX4_STEERING_MODE_DEVICE_MANAGED) - mlx4_qp_release_range(dev, ibdev->steer_qpn_base, - ibdev->steer_qpn_count); + mlx4_qp_release_range(dev, ibdev->steer_qpn_base, + ibdev->steer_qpn_count); err_counter: for (i = 0; i < ibdev->num_ports; ++i) mlx4_ib_delete_counters_table(ibdev, &ibdev->counters_table[i]); @@ -3035,11 +3034,9 @@ static void mlx4_ib_remove(struct mlx4_d ibdev->iboe.nb.notifier_call = NULL; } - if (ibdev->steering_support == MLX4_STEERING_MODE_DEVICE_MANAGED) { - mlx4_qp_release_range(dev, ibdev->steer_qpn_base, - ibdev->steer_qpn_count); - kfree(ibdev->ib_uc_qpns_bitmap); - } + mlx4_qp_release_range(dev, ibdev->steer_qpn_base, + ibdev->steer_qpn_count); + kfree(ibdev->ib_uc_qpns_bitmap); iounmap(ibdev->uar_map); for (p = 0; p < ibdev->num_ports; ++p) --- a/drivers/net/ethernet/mellanox/mlx4/qp.c +++ b/drivers/net/ethernet/mellanox/mlx4/qp.c @@ -286,6 +286,9 @@ void mlx4_qp_release_range(struct mlx4_d u64 in_param = 0; int err; + if (!cnt) + return; + if (mlx4_is_mfunc(dev)) { set_param_l(&in_param, base_qpn); set_param_h(&in_param, cnt); Patches currently in stable-queue which might be from jackm(a)dev.mellanox.co.il are queue-4.9/ib-mlx4-fix-incorrectly-releasing-steerable-ud-qps-when-have-only-eth-ports.patch

7 years, 4 months

1
0
0 0

Patch "IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports to the 4.4-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: ib-mlx4-fix-incorrectly-releasing-steerable-ud-qps-when-have-only-eth-ports.patch and it can be found in the queue-4.4 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. >From 852f6927594d0d3e8632c889b2ab38cbc46476ad Mon Sep 17 00:00:00 2001 From: Jack Morgenstein <jackm(a)dev.mellanox.co.il> Date: Fri, 12 Jan 2018 07:58:40 +0200 Subject: IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports From: Jack Morgenstein <jackm(a)dev.mellanox.co.il> commit 852f6927594d0d3e8632c889b2ab38cbc46476ad upstream. Allocating steerable UD QPs depends on having at least one IB port, while releasing those QPs does not. As a result, when there are only ETH ports, the IB (RoCE) driver requests releasing a qp range whose base qp is zero, with qp count zero. When SR-IOV is enabled, and the VF driver is running on a VM over a hypervisor which treats such qp release calls as errors (rather than NOPs), we see lines in the VM message log like: mlx4_core 0002:00:02.0: Failed to release qp range base:0 cnt:0 Fix this by adding a check for a zero count in mlx4_release_qp_range() (which thus treats releasing 0 qps as a nop), and eliminating the check for device managed flow steering when releasing steerable UD QPs. (Freeing ib_uc_qpns_bitmap unconditionally is also OK, since it remains NULL when steerable UD QPs are not allocated). Fixes: 4196670be786 ("IB/mlx4: Don't allocate range of steerable UD QPs for Ethernet-only device") Signed-off-by: Jack Morgenstein <jackm(a)dev.mellanox.co.il> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/mlx4/main.c | 13 +++++-------- drivers/net/ethernet/mellanox/mlx4/qp.c | 3 +++ 2 files changed, 8 insertions(+), 8 deletions(-) --- a/drivers/infiniband/hw/mlx4/main.c +++ b/drivers/infiniband/hw/mlx4/main.c @@ -2483,9 +2483,8 @@ err_steer_free_bitmap: kfree(ibdev->ib_uc_qpns_bitmap); err_steer_qp_release: - if (ibdev->steering_support == MLX4_STEERING_MODE_DEVICE_MANAGED) - mlx4_qp_release_range(dev, ibdev->steer_qpn_base, - ibdev->steer_qpn_count); + mlx4_qp_release_range(dev, ibdev->steer_qpn_base, + ibdev->steer_qpn_count); err_counter: for (i = 0; i < ibdev->num_ports; ++i) mlx4_ib_delete_counters_table(ibdev, &ibdev->counters_table[i]); @@ -2586,11 +2585,9 @@ static void mlx4_ib_remove(struct mlx4_d ibdev->iboe.nb.notifier_call = NULL; } - if (ibdev->steering_support == MLX4_STEERING_MODE_DEVICE_MANAGED) { - mlx4_qp_release_range(dev, ibdev->steer_qpn_base, - ibdev->steer_qpn_count); - kfree(ibdev->ib_uc_qpns_bitmap); - } + mlx4_qp_release_range(dev, ibdev->steer_qpn_base, + ibdev->steer_qpn_count); + kfree(ibdev->ib_uc_qpns_bitmap); iounmap(ibdev->uar_map); for (p = 0; p < ibdev->num_ports; ++p) --- a/drivers/net/ethernet/mellanox/mlx4/qp.c +++ b/drivers/net/ethernet/mellanox/mlx4/qp.c @@ -280,6 +280,9 @@ void mlx4_qp_release_range(struct mlx4_d u64 in_param = 0; int err; + if (!cnt) + return; + if (mlx4_is_mfunc(dev)) { set_param_l(&in_param, base_qpn); set_param_h(&in_param, cnt); Patches currently in stable-queue which might be from jackm(a)dev.mellanox.co.il are queue-4.4/ib-mlx4-fix-incorrectly-releasing-steerable-ud-qps-when-have-only-eth-ports.patch

7 years, 4 months

1
0
0 0

Patch "selftests: seccomp: fix compile error seccomp_bpf" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selftests: seccomp: fix compile error seccomp_bpf to the 4.15-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: selftests-seccomp-fix-compile-error-seccomp_bpf.patch and it can be found in the queue-4.15 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. >From 912ec316686df352028afb6efec59e47a958a24d Mon Sep 17 00:00:00 2001 From: Anders Roxell <anders.roxell(a)linaro.org> Date: Fri, 5 Jan 2018 17:31:18 +0100 Subject: selftests: seccomp: fix compile error seccomp_bpf From: Anders Roxell <anders.roxell(a)linaro.org> commit 912ec316686df352028afb6efec59e47a958a24d upstream. aarch64-linux-gnu-gcc -Wl,-no-as-needed -Wall -lpthread seccomp_bpf.c -o seccomp_bpf seccomp_bpf.c: In function 'tracer_ptrace': seccomp_bpf.c:1720:12: error: '__NR_open' undeclared (first use in this function) if (nr == __NR_open) ^~~~~~~~~ seccomp_bpf.c:1720:12: note: each undeclared identifier is reported only once for each function it appears in In file included from seccomp_bpf.c:48:0: seccomp_bpf.c: In function 'TRACE_syscall_ptrace_syscall_dropped': seccomp_bpf.c:1795:39: error: '__NR_open' undeclared (first use in this function) EXPECT_SYSCALL_RETURN(EPERM, syscall(__NR_open)); ^ open(2) is a legacy syscall, replaced with openat(2) since 2.6.16. Thus new architectures in the kernel, such as arm64, don't implement these legacy syscalls. Fixes: a33b2d0359a0 ("selftests/seccomp: Add tests for basic ptrace actions") Signed-off-by: Anders Roxell <anders.roxell(a)linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju(a)linaro.org> Cc: stable(a)vger.kernel.org Acked-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/seccomp/seccomp_bpf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/tools/testing/selftests/seccomp/seccomp_bpf.c +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c @@ -1717,7 +1717,7 @@ void tracer_ptrace(struct __test_metadat if (nr == __NR_getpid) change_syscall(_metadata, tracee, __NR_getppid); - if (nr == __NR_open) + if (nr == __NR_openat) change_syscall(_metadata, tracee, -1); } @@ -1792,7 +1792,7 @@ TEST_F(TRACE_syscall, ptrace_syscall_dro true); /* Tracer should skip the open syscall, resulting in EPERM. */ - EXPECT_SYSCALL_RETURN(EPERM, syscall(__NR_open)); + EXPECT_SYSCALL_RETURN(EPERM, syscall(__NR_openat)); } TEST_F(TRACE_syscall, syscall_allowed) Patches currently in stable-queue which might be from anders.roxell(a)linaro.org are queue-4.15/selftests-seccomp-fix-compile-error-seccomp_bpf.patch

7 years, 4 months

1
0
0 0

Patch "RDMA/rxe: Fix rxe_qp_cleanup()" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDMA/rxe: Fix rxe_qp_cleanup() to the 4.15-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: rdma-rxe-fix-rxe_qp_cleanup.patch and it can be found in the queue-4.15 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. >From bb3ffb7ad48a21e98a5c64eb21103a74fd9f03f6 Mon Sep 17 00:00:00 2001 From: Bart Van Assche <bart.vanassche(a)wdc.com> Date: Fri, 12 Jan 2018 15:11:59 -0800 Subject: RDMA/rxe: Fix rxe_qp_cleanup() From: Bart Van Assche <bart.vanassche(a)wdc.com> commit bb3ffb7ad48a21e98a5c64eb21103a74fd9f03f6 upstream. rxe_qp_cleanup() can sleep so it must be run in thread context and not in atomic context. This patch avoids that the following bug is triggered: Kernel BUG at 00000000560033f3 [verbose debug info unavailable] BUG: sleeping function called from invalid context at net/core/sock.c:2761 in_atomic(): 1, irqs_disabled(): 0, pid: 7, name: ksoftirqd/0 INFO: lockdep is turned off. Preemption disabled at: [<00000000b6e69628>] __do_softirq+0x4e/0x540 CPU: 0 PID: 7 Comm: ksoftirqd/0 Not tainted 4.15.0-rc7-dbg+ #4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 Call Trace: dump_stack+0x85/0xbf ___might_sleep+0x177/0x260 lock_sock_nested+0x1d/0x90 inet_shutdown+0x2e/0xd0 rxe_qp_cleanup+0x107/0x140 [rdma_rxe] rxe_elem_release+0x18/0x80 [rdma_rxe] rxe_requester+0x1cf/0x11b0 [rdma_rxe] rxe_do_task+0x78/0xf0 [rdma_rxe] tasklet_action+0x99/0x270 __do_softirq+0xc0/0x540 run_ksoftirqd+0x1c/0x70 smpboot_thread_fn+0x1be/0x270 kthread+0x117/0x130 ret_from_fork+0x24/0x30 Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Moni Shoua <monis(a)mellanox.com> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/sw/rxe/rxe_qp.c | 12 ++++++++++-- drivers/infiniband/sw/rxe/rxe_verbs.h | 3 +++ 2 files changed, 13 insertions(+), 2 deletions(-) --- a/drivers/infiniband/sw/rxe/rxe_qp.c +++ b/drivers/infiniband/sw/rxe/rxe_qp.c @@ -824,9 +824,9 @@ void rxe_qp_destroy(struct rxe_qp *qp) } /* called when the last reference to the qp is dropped */ -void rxe_qp_cleanup(struct rxe_pool_entry *arg) +static void rxe_qp_do_cleanup(struct work_struct *work) { - struct rxe_qp *qp = container_of(arg, typeof(*qp), pelem); + struct rxe_qp *qp = container_of(work, typeof(*qp), cleanup_work.work); rxe_drop_all_mcast_groups(qp); @@ -859,3 +859,11 @@ void rxe_qp_cleanup(struct rxe_pool_entr kernel_sock_shutdown(qp->sk, SHUT_RDWR); sock_release(qp->sk); } + +/* called when the last reference to the qp is dropped */ +void rxe_qp_cleanup(struct rxe_pool_entry *arg) +{ + struct rxe_qp *qp = container_of(arg, typeof(*qp), pelem); + + execute_in_process_context(rxe_qp_do_cleanup, &qp->cleanup_work); +} --- a/drivers/infiniband/sw/rxe/rxe_verbs.h +++ b/drivers/infiniband/sw/rxe/rxe_verbs.h @@ -35,6 +35,7 @@ #define RXE_VERBS_H #include <linux/interrupt.h> +#include <linux/workqueue.h> #include <rdma/rdma_user_rxe.h> #include "rxe_pool.h" #include "rxe_task.h" @@ -281,6 +282,8 @@ struct rxe_qp { struct timer_list rnr_nak_timer; spinlock_t state_lock; /* guard requester and completer */ + + struct execute_work cleanup_work; }; enum rxe_mem_state { Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are queue-4.15/ib-core-fix-two-kernel-warnings-triggered-by-rxe-registration.patch queue-4.15/rdma-rxe-fix-a-race-condition-in-rxe_requester.patch queue-4.15/rdma-rxe-fix-rxe_qp_cleanup.patch queue-4.15/rdma-rxe-fix-a-race-condition-related-to-the-qp-error-state.patch

7 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror