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

Patch "ACPICA: OSL: Add support to exclude stdarg.h" 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 ACPICA: OSL: Add support to exclude stdarg.h 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: acpica-osl-add-support-to-exclude-stdarg.h.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 foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Lv Zheng <lv.zheng(a)intel.com> Date: Mon, 5 Jun 2017 16:39:56 +0800 Subject: ACPICA: OSL: Add support to exclude stdarg.h From: Lv Zheng <lv.zheng(a)intel.com> [ Upstream commit 84676b87b27d8aefafb9f712a5b444938f284513 ] ACPICA commit e2df7455a9a4301b03668e4c9c02c7a564cc841c Some hosts may choose not to include stdarg.h, implementing a configurability in acgcc.h, allowing OSen like Solaris to exclude stdarg.h. This patch also fixes acintel.h accordingly without providing builtin support as Intel compiler is similar as GCC. Reported by Dana Myers, fixed by Lv Zheng. Link: https://github.com/acpica/acpica/commit/e2df7455 Reported-by: Dana Myers <dana.myers(a)oracle.com> Signed-off-by: Lv Zheng <lv.zheng(a)intel.com> Signed-off-by: Bob Moore <robert.moore(a)intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/acpi/platform/acgcc.h | 10 ++++++++++ include/acpi/platform/acintel.h | 2 ++ 2 files changed, 12 insertions(+) --- a/include/acpi/platform/acgcc.h +++ b/include/acpi/platform/acgcc.h @@ -48,7 +48,17 @@ * Use compiler specific <stdarg.h> is a good practice for even when * -nostdinc is specified (i.e., ACPI_USE_STANDARD_HEADERS undefined. */ +#ifndef va_arg +#ifdef ACPI_USE_BUILTIN_STDARG +typedef __builtin_va_list va_list; +#define va_start(v, l) __builtin_va_start(v, l) +#define va_end(v) __builtin_va_end(v) +#define va_arg(v, l) __builtin_va_arg(v, l) +#define va_copy(d, s) __builtin_va_copy(d, s) +#else #include <stdarg.h> +#endif +#endif #define ACPI_INLINE __inline__ --- a/include/acpi/platform/acintel.h +++ b/include/acpi/platform/acintel.h @@ -48,7 +48,9 @@ * Use compiler specific <stdarg.h> is a good practice for even when * -nostdinc is specified (i.e., ACPI_USE_STANDARD_HEADERS undefined. */ +#ifndef va_arg #include <stdarg.h> +#endif /* Configuration specific to Intel 64-bit C compiler */ Patches currently in stable-queue which might be from lv.zheng(a)intel.com are queue-4.9/acpica-disassembler-abort-on-an-invalid-unknown-aml-opcode.patch queue-4.9/acpica-events-add-runtime-stub-support-for-event-apis.patch queue-4.9/acpica-osl-add-support-to-exclude-stdarg.h.patch

7 years, 2 months

1
0
0 0

Patch "ACPICA: Disassembler: Abort on an invalid/unknown AML opcode" 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 ACPICA: Disassembler: Abort on an invalid/unknown AML opcode 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: acpica-disassembler-abort-on-an-invalid-unknown-aml-opcode.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 foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Bob Moore <robert.moore(a)intel.com> Date: Mon, 5 Jun 2017 16:40:34 +0800 Subject: ACPICA: Disassembler: Abort on an invalid/unknown AML opcode From: Bob Moore <robert.moore(a)intel.com> [ Upstream commit 6f0527b77d9e0129dd8e50945b0d610ed943d6b2 ] ACPICA commit ed0389cb11a61e63c568ac1f67948fc6a7bd1aeb An invalid opcode indicates something seriously wrong with the input AML file. The AML parser is immediately confused and lost, causing the resulting parse tree to be ill-formed. The actual disassembly can then cause numerous unrelated errors and faults. This change aborts the disassembly upon discovery of such an opcode during the AML parse phase. Link: https://github.com/acpica/acpica/commit/ed0389cb Signed-off-by: Bob Moore <robert.moore(a)intel.com> Signed-off-by: Lv Zheng <lv.zheng(a)intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/acpi/acpica/psobject.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) --- a/drivers/acpi/acpica/psobject.c +++ b/drivers/acpi/acpica/psobject.c @@ -121,6 +121,9 @@ static acpi_status acpi_ps_get_aml_opcod (u32)(aml_offset + sizeof(struct acpi_table_header))); + ACPI_ERROR((AE_INFO, + "Aborting disassembly, AML byte code is corrupt")); + /* Dump the context surrounding the invalid opcode */ acpi_ut_dump_buffer(((u8 *)walk_state->parser_state. @@ -129,6 +132,14 @@ static acpi_status acpi_ps_get_aml_opcod sizeof(struct acpi_table_header) - 16)); acpi_os_printf(" */\n"); + + /* + * Just abort the disassembly, cannot continue because the + * parser is essentially lost. The disassembler can then + * randomly fail because an ill-constructed parse tree + * can result. + */ + return_ACPI_STATUS(AE_AML_BAD_OPCODE); #endif } @@ -293,6 +304,9 @@ acpi_ps_create_op(struct acpi_walk_state if (status == AE_CTRL_PARSE_CONTINUE) { return_ACPI_STATUS(AE_CTRL_PARSE_CONTINUE); } + if (ACPI_FAILURE(status)) { + return_ACPI_STATUS(status); + } /* Create Op structure and append to parent's argument list */ Patches currently in stable-queue which might be from robert.moore(a)intel.com are queue-4.9/acpica-disassembler-abort-on-an-invalid-unknown-aml-opcode.patch queue-4.9/acpica-events-add-runtime-stub-support-for-event-apis.patch queue-4.9/acpica-osl-add-support-to-exclude-stdarg.h.patch

7 years, 2 months

1
0
0 0

Patch "ACPI / video: Default lcd_only to true on Win8-ready and newer machines" 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 ACPI / video: Default lcd_only to true on Win8-ready and newer machines 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: acpi-video-default-lcd_only-to-true-on-win8-ready-and-newer-machines.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 foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Hans de Goede <hdegoede(a)redhat.com> Date: Sat, 23 Dec 2017 19:41:47 +0100 Subject: ACPI / video: Default lcd_only to true on Win8-ready and newer machines From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit 5928c281524fe451114e04f1dfa11246a37e859f ] We're seeing a lot of bogus backlight interfaces on newer machines without a LCD such as desktops, servers and HDMI sticks. This causes userspace to show a non-functional brightness slider in e.g. the GNOME3 system menu, which is undesirable. And, in general, we should simply just not register a non functional backlight interface. Checking the LCD flag causes the bogus acpi_video backlight interfaces to go away (on the machines this was tested on). This change sets the lcd_only option by default on any machines which are Win8-ready, to fix this. This is not entirely without a risk of regressions, but video_detect.c already prefers native-backlight interfaces over the acpi_video one on Win8-ready machines, calling acpi_video_unregister_backlight() as soon as a native interface shows up. This is done because the ACPI backlight interface often is broken on Win8-ready machines, because win8 does not seem to actually use it. So in practice we already end up not registering the ACPI backlight interface on (most) Win8-ready machines with a LCD panel, thus this change does not change anything for (most) machines with a LCD panel and on machines without a LCD panel we actually don't want to register any backlight interfaces. This has been tested on the following machines and fixes a bogus backlight interface showing up there: - Desktop with an Asrock B150M Pro4S/D3 m.b. using i5-6500 builtin gfx - Intel Compute Stick STK1AW32SC - Meegopad T08 HDMI stick Bogus backlight interfaces have also been reported on: - Desktop with Asus H87I-Plus m.b. - Desktop with ASRock B75M-ITX m.b. - Desktop with Gigabyte Z87-D3HP m.b. - Dell PowerEdge T20 desktop Link: https://bugzilla.redhat.com/show_bug.cgi?id=1097436 Link: https://bugzilla.redhat.com/show_bug.cgi?id=1133327 Link: https://bugzilla.redhat.com/show_bug.cgi?id=1133329 Link: https://bugzilla.redhat.com/show_bug.cgi?id=1133646 Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/acpi/acpi_video.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) --- a/drivers/acpi/acpi_video.c +++ b/drivers/acpi/acpi_video.c @@ -87,8 +87,8 @@ MODULE_PARM_DESC(report_key_events, static bool device_id_scheme = false; module_param(device_id_scheme, bool, 0444); -static bool only_lcd = false; -module_param(only_lcd, bool, 0444); +static int only_lcd = -1; +module_param(only_lcd, int, 0444); static int register_count; static DEFINE_MUTEX(register_count_mutex); @@ -2082,6 +2082,16 @@ int acpi_video_register(void) goto leave; } + /* + * We're seeing a lot of bogus backlight interfaces on newer machines + * without a LCD such as desktops, servers and HDMI sticks. Checking + * the lcd flag fixes this, so enable this on any machines which are + * win8 ready (where we also prefer the native backlight driver, so + * normally the acpi_video code should not register there anyways). + */ + if (only_lcd == -1) + only_lcd = acpi_osi_is_win8(); + dmi_check_system(video_dmi_table); ret = acpi_bus_register_driver(&acpi_video_bus); Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.9/gpio-crystalcove-do-not-write-regular-gpio-registers-for-virtual-gpios.patch queue-4.9/acpi-video-default-lcd_only-to-true-on-win8-ready-and-newer-machines.patch queue-4.9/hid-i2c-call-acpi_device_fix_up_power-for-acpi-enumerated-devices.patch queue-4.9/ata-libahci-properly-propagate-return-value-of-platform_get_irq.patch queue-4.9/input-goodix-disable-irqs-while-suspended.patch queue-4.9/asoc-intel-cht_bsw_rt5645-analog-mic-support.patch queue-4.9/pinctrl-baytrail-enable-glitch-filter-for-gpios-used-as-interrupts.patch

7 years, 2 months

1
0
0 0

Patch "ACPI: EC: Fix debugfs_create_*() usage" 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 ACPI: EC: Fix debugfs_create_*() usage 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: acpi-ec-fix-debugfs_create_-usage.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 foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Geert Uytterhoeven <geert+renesas(a)glider.be> Date: Tue, 2 Jan 2018 16:26:31 +0100 Subject: ACPI: EC: Fix debugfs_create_*() usage From: Geert Uytterhoeven <geert+renesas(a)glider.be> [ Upstream commit 3522f867c13b63cf62acdf1b8ca5664c549a716a ] acpi_ec.gpe is "unsigned long", hence treating it as "u32" would expose the wrong half on big-endian 64-bit systems. Fix this by changing its type to "u32" and removing the cast, as all other code already uses u32 or sometimes even only u8. Fixes: 1195a098168fcacf (ACPI: Provide /sys/kernel/debug/ec/...) Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/acpi/ec.c | 2 +- drivers/acpi/ec_sys.c | 2 +- drivers/acpi/internal.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) --- a/drivers/acpi/ec.c +++ b/drivers/acpi/ec.c @@ -1518,7 +1518,7 @@ static int acpi_ec_setup(struct acpi_ec } acpi_handle_info(ec->handle, - "GPE=0x%lx, EC_CMD/EC_SC=0x%lx, EC_DATA=0x%lx\n", + "GPE=0x%x, EC_CMD/EC_SC=0x%lx, EC_DATA=0x%lx\n", ec->gpe, ec->command_addr, ec->data_addr); return ret; } --- a/drivers/acpi/ec_sys.c +++ b/drivers/acpi/ec_sys.c @@ -128,7 +128,7 @@ static int acpi_ec_add_debugfs(struct ac return -ENOMEM; } - if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)&first_ec->gpe)) + if (!debugfs_create_x32("gpe", 0444, dev_dir, &first_ec->gpe)) goto error; if (!debugfs_create_bool("use_global_lock", 0444, dev_dir, &first_ec->global_lock)) --- a/drivers/acpi/internal.h +++ b/drivers/acpi/internal.h @@ -158,7 +158,7 @@ static inline void acpi_early_processor_ -------------------------------------------------------------------------- */ struct acpi_ec { acpi_handle handle; - unsigned long gpe; + u32 gpe; unsigned long command_addr; unsigned long data_addr; bool global_lock; Patches currently in stable-queue which might be from geert+renesas(a)glider.be are queue-4.9/acpi-ec-fix-debugfs_create_-usage.patch queue-4.9/serial-sh-sci-fix-race-condition-causing-garbage-during-shutdown.patch queue-4.9/clk-renesas-rcar-gen2-fix-pll0-on-r-car-v2h-and-e2.patch queue-4.9/sh_eth-use-platform-device-for-printing-before-register_netdev.patch queue-4.9/arm-dts-armadillo800eva-split-lcd-mux-and-gpio.patch

7 years, 2 months

1
0
0 0

[PATCH] drm/vc4: Fix memory leak during BO teardown

by Daniel J Blueman

During BO teardown, an indirect list 'uniform_addr_offsets' wasn't being freed leading to leaking many 128B allocations. Fix the memory leak by releasing it at teardown time. To: linux-kernel(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: Eric Anholt <eric(a)anholt.net> Cc: Dave Airlie <airlied(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: Daniel J Blueman <daniel(a)quora.org> --- drivers/gpu/drm/vc4/vc4_bo.c | 2 ++ drivers/gpu/drm/vc4/vc4_validate_shaders.c | 1 + 2 files changed, 3 insertions(+) diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c index 2decc8e2c79f..add9cc97a3b6 100644 --- a/drivers/gpu/drm/vc4/vc4_bo.c +++ b/drivers/gpu/drm/vc4/vc4_bo.c @@ -195,6 +195,7 @@ static void vc4_bo_destroy(struct vc4_bo *bo) vc4_bo_set_label(obj, -1); if (bo->validated_shader) { + kfree(bo->validated_shader->uniform_addr_offsets); kfree(bo->validated_shader->texture_samples); kfree(bo->validated_shader); bo->validated_shader = NULL; @@ -591,6 +592,7 @@ void vc4_free_object(struct drm_gem_object *gem_bo) } if (bo->validated_shader) { + kfree(bo->validated_shader->uniform_addr_offsets); kfree(bo->validated_shader->texture_samples); kfree(bo->validated_shader); bo->validated_shader = NULL; diff --git a/drivers/gpu/drm/vc4/vc4_validate_shaders.c b/drivers/gpu/drm/vc4/vc4_validate_shaders.c index d3f15bf60900..7cf82b071de2 100644 --- a/drivers/gpu/drm/vc4/vc4_validate_shaders.c +++ b/drivers/gpu/drm/vc4/vc4_validate_shaders.c @@ -942,6 +942,7 @@ vc4_validate_shader(struct drm_gem_cma_object *shader_obj) fail: kfree(validation_state.branch_targets); if (validated_shader) { + kfree(validated_shader->uniform_addr_offsets); kfree(validated_shader->texture_samples); kfree(validated_shader); } -- 2.11.0

7 years, 2 months

3
2
0 0

Re: [PATCH 2/2] HID: i2c-hid: Silently fail probe for CHPN0001 touchscreen

by Sasha Levin

Hi, [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 20.8863) The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92, v4.4.126. v4.16: Build OK! v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Failed to apply! Possible dependencies: 94116f8126de ("ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()") v4.4.126: Failed to apply! Possible dependencies: 94116f8126de ("ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()") Please let us know if you'd like to have this patch included in a stable tree. -- Thanks, Sasha

7 years, 2 months

2
2
0 0

[PATCH v2 2/5] crypto: thunderx_zip: Limit result reading attempts

by Jan Glauber

After issuing a request an endless loop was used to read the completion state from memory which is asynchronously updated by the ZIP coprocessor. Add an upper bound to the retry attempts to prevent a CPU getting stuck forever in case of an error. Additionally, add a read memory barrier and a small delay between the reading attempts. Signed-off-by: Jan Glauber <jglauber(a)cavium.com> Reviewed-by: Robert Richter <rrichter(a)cavium.com> Cc: stable <stable(a)vger.kernel.org> # 4.14 --- drivers/crypto/cavium/zip/common.h | 21 +++++++++++++++++++++ drivers/crypto/cavium/zip/zip_deflate.c | 4 ++-- drivers/crypto/cavium/zip/zip_inflate.c | 4 ++-- 3 files changed, 25 insertions(+), 4 deletions(-) diff --git a/drivers/crypto/cavium/zip/common.h b/drivers/crypto/cavium/zip/common.h index dc451e0a43c5..58fb3ed6e644 100644 --- a/drivers/crypto/cavium/zip/common.h +++ b/drivers/crypto/cavium/zip/common.h @@ -46,8 +46,10 @@ #ifndef __COMMON_H__ #define __COMMON_H__ +#include <linux/delay.h> #include <linux/init.h> #include <linux/interrupt.h> +#include <linux/io.h> #include <linux/kernel.h> #include <linux/module.h> #include <linux/pci.h> @@ -149,6 +151,25 @@ struct zip_operation { u32 sizeofzops; }; +static inline int zip_poll_result(union zip_zres_s *result) +{ + int retries = 1000; + + while (!result->s.compcode) { + if (!--retries) { + pr_err("ZIP ERR: request timed out"); + return -ETIMEDOUT; + } + udelay(10); + /* + * Force re-reading of compcode which is updated + * by the ZIP coprocessor. + */ + rmb(); + } + return 0; +} + /* error messages */ #define zip_err(fmt, args...) pr_err("ZIP ERR:%s():%d: " \ fmt "\n", __func__, __LINE__, ## args) diff --git a/drivers/crypto/cavium/zip/zip_deflate.c b/drivers/crypto/cavium/zip/zip_deflate.c index 9a944b8c1e29..d7133f857d67 100644 --- a/drivers/crypto/cavium/zip/zip_deflate.c +++ b/drivers/crypto/cavium/zip/zip_deflate.c @@ -129,8 +129,8 @@ int zip_deflate(struct zip_operation *zip_ops, struct zip_state *s, /* Stats update for compression requests submitted */ atomic64_inc(&zip_dev->stats.comp_req_submit); - while (!result_ptr->s.compcode) - continue; + /* Wait for completion or error */ + zip_poll_result(result_ptr); /* Stats update for compression requests completed */ atomic64_inc(&zip_dev->stats.comp_req_complete); diff --git a/drivers/crypto/cavium/zip/zip_inflate.c b/drivers/crypto/cavium/zip/zip_inflate.c index 50cbdd83dbf2..7e0d73e2f89e 100644 --- a/drivers/crypto/cavium/zip/zip_inflate.c +++ b/drivers/crypto/cavium/zip/zip_inflate.c @@ -143,8 +143,8 @@ int zip_inflate(struct zip_operation *zip_ops, struct zip_state *s, /* Decompression requests submitted stats update */ atomic64_inc(&zip_dev->stats.decomp_req_submit); - while (!result_ptr->s.compcode) - continue; + /* Wait for completion or error */ + zip_poll_result(result_ptr); /* Decompression requests completed stats update */ atomic64_inc(&zip_dev->stats.decomp_req_complete); -- 2.16.2

7 years, 2 months

1
0
0 0

[PATCH v2 1/5] crypto: thunderx_zip: Fix fallout from CONFIG_VMAP_STACK

by Jan Glauber

Enabling virtual mapped kernel stacks breaks the thunderx_zip driver. On compression or decompression the executing CPU hangs in an endless loop. The reason for this is the usage of __pa by the driver which does no longer work for an address that is not part of the 1:1 mapping. The zip driver allocates a result struct on the stack and needs to tell the hardware the physical address within this struct that is used to signal the completion of the request. As the hardware gets the wrong address after the broken __pa conversion it writes to an arbitrary address. The zip driver then waits forever for the completion byte to contain a non-zero value. Allocating the result struct from 1:1 mapped memory resolves this bug. Signed-off-by: Jan Glauber <jglauber(a)cavium.com> Reviewed-by: Robert Richter <rrichter(a)cavium.com> Cc: stable <stable(a)vger.kernel.org> # 4.14 --- drivers/crypto/cavium/zip/zip_crypto.c | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/drivers/crypto/cavium/zip/zip_crypto.c b/drivers/crypto/cavium/zip/zip_crypto.c index 8df4d26cf9d4..b92b6e7e100f 100644 --- a/drivers/crypto/cavium/zip/zip_crypto.c +++ b/drivers/crypto/cavium/zip/zip_crypto.c @@ -124,7 +124,7 @@ int zip_compress(const u8 *src, unsigned int slen, struct zip_kernel_ctx *zip_ctx) { struct zip_operation *zip_ops = NULL; - struct zip_state zip_state; + struct zip_state *zip_state; struct zip_device *zip = NULL; int ret; @@ -135,20 +135,23 @@ int zip_compress(const u8 *src, unsigned int slen, if (!zip) return -ENODEV; - memset(&zip_state, 0, sizeof(struct zip_state)); + zip_state = kzalloc(sizeof(*zip_state), GFP_ATOMIC); + if (!zip_state) + return -ENOMEM; + zip_ops = &zip_ctx->zip_comp; zip_ops->input_len = slen; zip_ops->output_len = *dlen; memcpy(zip_ops->input, src, slen); - ret = zip_deflate(zip_ops, &zip_state, zip); + ret = zip_deflate(zip_ops, zip_state, zip); if (!ret) { *dlen = zip_ops->output_len; memcpy(dst, zip_ops->output, *dlen); } - + kfree(zip_state); return ret; } @@ -157,7 +160,7 @@ int zip_decompress(const u8 *src, unsigned int slen, struct zip_kernel_ctx *zip_ctx) { struct zip_operation *zip_ops = NULL; - struct zip_state zip_state; + struct zip_state *zip_state; struct zip_device *zip = NULL; int ret; @@ -168,7 +171,10 @@ int zip_decompress(const u8 *src, unsigned int slen, if (!zip) return -ENODEV; - memset(&zip_state, 0, sizeof(struct zip_state)); + zip_state = kzalloc(sizeof(*zip_state), GFP_ATOMIC); + if (!zip_state) + return -ENOMEM; + zip_ops = &zip_ctx->zip_decomp; memcpy(zip_ops->input, src, slen); @@ -179,13 +185,13 @@ int zip_decompress(const u8 *src, unsigned int slen, zip_ops->input_len = slen; zip_ops->output_len = *dlen; - ret = zip_inflate(zip_ops, &zip_state, zip); + ret = zip_inflate(zip_ops, zip_state, zip); if (!ret) { *dlen = zip_ops->output_len; memcpy(dst, zip_ops->output, *dlen); } - + kfree(zip_state); return ret; } -- 2.16.2

7 years, 2 months

1
0
0 0

Re: [PATCH net] arp: fix arp_filter on l3slave devices

by Sasha Levin

Hi, [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 33.5930) The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92, v4.4.126. v4.16: Build OK! v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Build OK! v4.4.126: Build OK! Please let us know if you'd like to have this patch included in a stable tree. -- Thanks, Sasha

7 years, 2 months

2
1
0 0

Re: [PATCH AUTOSEL for 4.15 142/189] firmware: dmi_scan: Fix handling of empty DMI strings

by Jean Delvare

Hi Parag, On Sun, 8 Apr 2018 21:21:19 -0400, Parag Warudkar wrote: > On Sun, Apr 8, 2018 at 8:18 PM, Sasha Levin <Alexander.Levin(a)microsoft.com> > wrote: > > > From: Jean Delvare <jdelvare(a)suse.de> > > > > [ Upstream commit a7770ae194569e96a93c48aceb304edded9cc648 ] > > > > [snip] > > > > > > * Strings starting with 8 spaces are all considered empty, even if > > non-space characters follow (sounds like a weird thing to do, but > > I have actually seen occurrences of this in DMI tables before.) > > > > Unless I am misreading the patch we will now allocate memory for > len(spaces)+len(string) for this case. Correct. > Have you seen BIOSes with lots of <space>string occurrences? A fair number, yes, but most of them were thankfully not in strings we are saving. Also note that most of them only have 1 or 2 leading spaces, not 8+, so this commit makes no difference for them. > If so what's the point of allocating memory for the leading spaces? Presented like that, it sounds like we are silly. But look at things the other way around: what's the point of storing these leading spaces in the DMI table in the first place? Whenever this happens, the hardware manufacturer is to blame, not us. As much as possible, we should stick to the specification and assume the other party does as well. Stripping the leading spaces would be trivial, but hiding their mistakes does not help hardware manufacturers in the long run anyway. If they can't see that it's wrong, it's harder for them to fix it. > IOW, what happens if we strip leading space before allocating? At boot time, we save a few bytes of memory, on the affected systems only. No code cost, but possibly some confusion as to why we strip leading spaces (which are rare) but not trailing spaces (which in my experience are more frequent.) At run time, the exact matching of the affected DMI strings would be less error-prone (although strings having leading spaces are likely to also have trailing spaces, annihilating the benefits.) Non-exact matching would be marginally faster, again only for the affected systems. As a conclusion, it's doable, but the benefit is very small and limited to a few broken systems, and it has the downside of not discouraging low-quality tables, so my position is that it's not worth it and not desirable. -- Jean Delvare SUSE L3 Support

7 years, 2 months

2
1
0 0

Patch "x86/gart: Exclude GART aperture from vmcore" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/gart: Exclude GART aperture from vmcore to the 4.14-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: x86-gart-exclude-gart-aperture-from-vmcore.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Jiri Bohac <jbohac(a)suse.cz> Date: Sat, 6 Jan 2018 02:00:13 +0100 Subject: x86/gart: Exclude GART aperture from vmcore From: Jiri Bohac <jbohac(a)suse.cz> [ Upstream commit 2a3e83c6f96c513f43ce5a8c9034608ea584a255 ] On machines where the GART aperture is mapped over physical RAM /proc/vmcore contains the remapped range and reading it may cause hangs or reboots. In the past, the GART region was added into the resource map, implemented by commit 56dd669a138c ("[PATCH] Insert GART region into resource map") However, inserting the iomem_resource from the early GART code caused resource conflicts with some AGP drivers (bko#72201), which got avoided by reverting the patch in commit 707d4eefbdb3 ("Revert [PATCH] Insert GART region into resource map"). This revert introduced the /proc/vmcore bug. The vmcore ELF header is either prepared by the kernel (when using the kexec_file_load syscall) or by the kexec userspace (when using the kexec_load syscall). Since we no longer have the GART iomem resource, the userspace kexec has no way of knowing which region to exclude from the ELF header. Changes from v1 of this patch: Instead of excluding the aperture from the ELF header, this patch makes /proc/vmcore return zeroes in the second kernel when attempting to read the aperture region. This is done by reusing the gart_oldmem_pfn_is_ram infrastructure originally intended to exclude XEN balooned memory. This works for both, the kexec_file_load and kexec_load syscalls. [Note that the GART region is the same in the first and second kernels: regardless whether the first kernel fixed up the northbridge/bios setting and mapped the aperture over physical memory, the second kernel finds the northbridge properly configured by the first kernel and the aperture never overlaps with e820 memory because the second kernel has a fake e820 map created from the crashkernel memory regions. Thus, the second kernel keeps the aperture address/size as configured by the first kernel.] register_oldmem_pfn_is_ram can only register one callback and returns an error if the callback has been registered already. Since XEN used to be the only user of this function, it never checks the return value. Now that we have more than one user, I added a WARN_ON just in case agp, XEN, or any other future user of register_oldmem_pfn_is_ram were to step on each other's toes. Fixes: 707d4eefbdb3 ("Revert [PATCH] Insert GART region into resource map") Signed-off-by: Jiri Bohac <jbohac(a)suse.cz> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Baoquan He <bhe(a)redhat.com> Cc: Toshi Kani <toshi.kani(a)hpe.com> Cc: David Airlie <airlied(a)linux.ie> Cc: yinghai(a)kernel.org Cc: joro(a)8bytes.org Cc: kexec(a)lists.infradead.org Cc: Borislav Petkov <bp(a)alien8.de> Cc: Bjorn Helgaas <bhelgaas(a)google.com> Cc: Dave Young <dyoung(a)redhat.com> Cc: Vivek Goyal <vgoyal(a)redhat.com> Link: https://lkml.kernel.org/r/20180106010013.73suskgxm7lox7g6@dwarf.suse.cz Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/aperture_64.c | 46 +++++++++++++++++++++++++++++++++++++++++- arch/x86/xen/mmu_hvm.c | 2 - 2 files changed, 46 insertions(+), 2 deletions(-) --- a/arch/x86/kernel/aperture_64.c +++ b/arch/x86/kernel/aperture_64.c @@ -30,6 +30,7 @@ #include <asm/dma.h> #include <asm/amd_nb.h> #include <asm/x86_init.h> +#include <linux/crash_dump.h> /* * Using 512M as goal, in case kexec will load kernel_big @@ -56,6 +57,33 @@ int fallback_aper_force __initdata; int fix_aperture __initdata = 1; +#ifdef CONFIG_PROC_VMCORE +/* + * If the first kernel maps the aperture over e820 RAM, the kdump kernel will + * use the same range because it will remain configured in the northbridge. + * Trying to dump this area via /proc/vmcore may crash the machine, so exclude + * it from vmcore. + */ +static unsigned long aperture_pfn_start, aperture_page_count; + +static int gart_oldmem_pfn_is_ram(unsigned long pfn) +{ + return likely((pfn < aperture_pfn_start) || + (pfn >= aperture_pfn_start + aperture_page_count)); +} + +static void exclude_from_vmcore(u64 aper_base, u32 aper_order) +{ + aperture_pfn_start = aper_base >> PAGE_SHIFT; + aperture_page_count = (32 * 1024 * 1024) << aper_order >> PAGE_SHIFT; + WARN_ON(register_oldmem_pfn_is_ram(&gart_oldmem_pfn_is_ram)); +} +#else +static void exclude_from_vmcore(u64 aper_base, u32 aper_order) +{ +} +#endif + /* This code runs before the PCI subsystem is initialized, so just access the northbridge directly. */ @@ -435,8 +463,16 @@ int __init gart_iommu_hole_init(void) out: if (!fix && !fallback_aper_force) { - if (last_aper_base) + if (last_aper_base) { + /* + * If this is the kdump kernel, the first kernel + * may have allocated the range over its e820 RAM + * and fixed up the northbridge + */ + exclude_from_vmcore(last_aper_base, last_aper_order); + return 1; + } return 0; } @@ -473,6 +509,14 @@ out: return 0; } + /* + * If this is the kdump kernel _and_ the first kernel did not + * configure the aperture in the northbridge, this range may + * overlap with the first kernel's memory. We can't access the + * range through vmcore even though it should be part of the dump. + */ + exclude_from_vmcore(aper_alloc, aper_order); + /* Fix up the north bridges */ for (i = 0; i < amd_nb_bus_dev_ranges[i].dev_limit; i++) { int bus, dev_base, dev_limit; --- a/arch/x86/xen/mmu_hvm.c +++ b/arch/x86/xen/mmu_hvm.c @@ -75,6 +75,6 @@ void __init xen_hvm_init_mmu_ops(void) if (is_pagetable_dying_supported()) pv_mmu_ops.exit_mmap = xen_hvm_exit_mmap; #ifdef CONFIG_PROC_VMCORE - register_oldmem_pfn_is_ram(&xen_oldmem_pfn_is_ram); + WARN_ON(register_oldmem_pfn_is_ram(&xen_oldmem_pfn_is_ram)); #endif } Patches currently in stable-queue which might be from jbohac(a)suse.cz are queue-4.14/x86-gart-exclude-gart-aperture-from-vmcore.patch

7 years, 2 months

1
0
0 0

Patch "wl1251: check return from call to wl1251_acx_arp_ip_filter" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled wl1251: check return from call to wl1251_acx_arp_ip_filter to the 4.14-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: wl1251-check-return-from-call-to-wl1251_acx_arp_ip_filter.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Colin Ian King <colin.king(a)canonical.com> Date: Tue, 26 Dec 2017 17:33:18 +0000 Subject: wl1251: check return from call to wl1251_acx_arp_ip_filter From: Colin Ian King <colin.king(a)canonical.com> [ Upstream commit ac1181c60822292176ab96912208ec9f9819faf8 ] Currently the less than zero error check on ret is incorrect as it is checking a far earlier ret assignment rather than the return from the call to wl1251_acx_arp_ip_filter. Fix this by adding in the missing assginment. Detected by CoverityScan, CID#1164835 ("Logically dead code") Fixes: 204cc5c44fb6 ("wl1251: implement hardware ARP filtering") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ti/wl1251/main.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/drivers/net/wireless/ti/wl1251/main.c +++ b/drivers/net/wireless/ti/wl1251/main.c @@ -1200,8 +1200,7 @@ static void wl1251_op_bss_info_changed(s WARN_ON(wl->bss_type != BSS_TYPE_STA_BSS); enable = bss_conf->arp_addr_cnt == 1 && bss_conf->assoc; - wl1251_acx_arp_ip_filter(wl, enable, addr); - + ret = wl1251_acx_arp_ip_filter(wl, enable, addr); if (ret < 0) goto out_sleep; } Patches currently in stable-queue which might be from colin.king(a)canonical.com are queue-4.14/wl1251-check-return-from-call-to-wl1251_acx_arp_ip_filter.patch

7 years, 2 months

1
0
0 0

Patch "watchdog: dw_wdt: add stop watchdog operation" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled watchdog: dw_wdt: add stop watchdog operation to the 4.14-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: watchdog-dw_wdt-add-stop-watchdog-operation.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Oleksij Rempel <o.rempel(a)pengutronix.de> Date: Tue, 26 Sep 2017 08:11:22 +0200 Subject: watchdog: dw_wdt: add stop watchdog operation From: Oleksij Rempel <o.rempel(a)pengutronix.de> [ Upstream commit 1bfe8889380890efe4943d125124f5a7b48571b0 ] The only way of stopping the watchdog is by resetting it. Add the watchdog op for stopping the device and reset if a reset line is provided. At same time WDOG_HW_RUNNING should be remove from dw_wdt_start. As commented by Guenter Roeck: dw_wdt sets WDOG_HW_RUNNING in its open function. Result is that the kref_get() in watchdog_open() won't be executed. But then kref_put() in close will be called since the watchdog now does stop. This causes the imbalance. Signed-off-by: Oleksij Rempel <o.rempel(a)pengutronix.de> Cc: Wim Van Sebroeck <wim(a)iguana.be> Cc: Guenter Roeck <linux(a)roeck-us.net> Cc: linux-watchdog(a)vger.kernel.org Reviewed-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim(a)iguana.be> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/watchdog/dw_wdt.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) --- a/drivers/watchdog/dw_wdt.c +++ b/drivers/watchdog/dw_wdt.c @@ -127,14 +127,27 @@ static int dw_wdt_start(struct watchdog_ dw_wdt_set_timeout(wdd, wdd->timeout); - set_bit(WDOG_HW_RUNNING, &wdd->status); - writel(WDOG_CONTROL_REG_WDT_EN_MASK, dw_wdt->regs + WDOG_CONTROL_REG_OFFSET); return 0; } +static int dw_wdt_stop(struct watchdog_device *wdd) +{ + struct dw_wdt *dw_wdt = to_dw_wdt(wdd); + + if (!dw_wdt->rst) { + set_bit(WDOG_HW_RUNNING, &wdd->status); + return 0; + } + + reset_control_assert(dw_wdt->rst); + reset_control_deassert(dw_wdt->rst); + + return 0; +} + static int dw_wdt_restart(struct watchdog_device *wdd, unsigned long action, void *data) { @@ -173,6 +186,7 @@ static const struct watchdog_info dw_wdt static const struct watchdog_ops dw_wdt_ops = { .owner = THIS_MODULE, .start = dw_wdt_start, + .stop = dw_wdt_stop, .ping = dw_wdt_ping, .set_timeout = dw_wdt_set_timeout, .get_timeleft = dw_wdt_get_timeleft, Patches currently in stable-queue which might be from o.rempel(a)pengutronix.de are queue-4.14/watchdog-dw_wdt-add-stop-watchdog-operation.patch

7 years, 2 months

1
0
0 0

Patch "VFS: close race between getcwd() and d_move()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled VFS: close race between getcwd() and d_move() to the 4.14-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: vfs-close-race-between-getcwd-and-d_move.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: NeilBrown <neilb(a)suse.com> Date: Fri, 10 Nov 2017 15:45:41 +1100 Subject: VFS: close race between getcwd() and d_move() From: NeilBrown <neilb(a)suse.com> [ Upstream commit 61647823aa920e395afcce4b57c32afb51456cab ] d_move() will call __d_drop() and then __d_rehash() on the dentry being moved. This creates a small window when the dentry appears to be unhashed. Many tests of d_unhashed() are made under ->d_lock and so are safe from racing with this window, but some aren't. In particular, getcwd() calls d_unlinked() (which calls d_unhashed()) without d_lock protection, so it can race. This races has been seen in practice with lustre, which uses d_move() as part of name lookup. See: https://jira.hpdd.intel.com/browse/LU-9735 It could race with a regular rename(), and result in ENOENT instead of either the 'before' or 'after' name. The race can be demonstrated with a simple program which has two threads, one renaming a directory back and forth while another calls getcwd() within that directory: it should never fail, but does. See: https://patchwork.kernel.org/patch/9455345/ We could fix this race by taking d_lock and rechecking when d_unhashed() reports true. Alternately when can remove the window, which is the approach this patch takes. ___d_drop() is introduce which does *not* clear d_hash.pprev so the dentry still appears to be hashed. __d_drop() calls ___d_drop(), then clears d_hash.pprev. __d_move() now uses ___d_drop() and only clears d_hash.pprev when not rehashing. Signed-off-by: NeilBrown <neilb(a)suse.com> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/dcache.c | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) --- a/fs/dcache.c +++ b/fs/dcache.c @@ -468,9 +468,11 @@ static void dentry_lru_add(struct dentry * d_drop() is used mainly for stuff that wants to invalidate a dentry for some * reason (NFS timeouts or autofs deletes). * - * __d_drop requires dentry->d_lock. + * __d_drop requires dentry->d_lock + * ___d_drop doesn't mark dentry as "unhashed" + * (dentry->d_hash.pprev will be LIST_POISON2, not NULL). */ -void __d_drop(struct dentry *dentry) +static void ___d_drop(struct dentry *dentry) { if (!d_unhashed(dentry)) { struct hlist_bl_head *b; @@ -486,12 +488,17 @@ void __d_drop(struct dentry *dentry) hlist_bl_lock(b); __hlist_bl_del(&dentry->d_hash); - dentry->d_hash.pprev = NULL; hlist_bl_unlock(b); /* After this call, in-progress rcu-walk path lookup will fail. */ write_seqcount_invalidate(&dentry->d_seq); } } + +void __d_drop(struct dentry *dentry) +{ + ___d_drop(dentry); + dentry->d_hash.pprev = NULL; +} EXPORT_SYMBOL(__d_drop); void d_drop(struct dentry *dentry) @@ -2386,7 +2393,7 @@ EXPORT_SYMBOL(d_delete); static void __d_rehash(struct dentry *entry) { struct hlist_bl_head *b = d_hash(entry->d_name.hash); - BUG_ON(!d_unhashed(entry)); + hlist_bl_lock(b); hlist_bl_add_head_rcu(&entry->d_hash, b); hlist_bl_unlock(b); @@ -2821,9 +2828,9 @@ static void __d_move(struct dentry *dent write_seqcount_begin_nested(&target->d_seq, DENTRY_D_LOCK_NESTED); /* unhash both */ - /* __d_drop does write_seqcount_barrier, but they're OK to nest. */ - __d_drop(dentry); - __d_drop(target); + /* ___d_drop does write_seqcount_barrier, but they're OK to nest. */ + ___d_drop(dentry); + ___d_drop(target); /* Switch the names.. */ if (exchange) @@ -2835,6 +2842,8 @@ static void __d_move(struct dentry *dent __d_rehash(dentry); if (exchange) __d_rehash(target); + else + target->d_hash.pprev = NULL; /* ... and switch them in the tree */ if (IS_ROOT(dentry)) { Patches currently in stable-queue which might be from neilb(a)suse.com are queue-4.14/staging-lustre-disable-preempt-while-sampling-processor-id.patch queue-4.14/vfs-close-race-between-getcwd-and-d_move.patch

7 years, 2 months

1
0
0 0

Patch "vfb: fix video mode and line_length being set when loaded" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled vfb: fix video mode and line_length being set when loaded to the 4.14-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: vfb-fix-video-mode-and-line_length-being-set-when-loaded.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: "Pieter \\\"PoroCYon\\\" Sluys" <pcy(a)national.shitposting.agency> Date: Thu, 4 Jan 2018 16:53:50 +0100 Subject: vfb: fix video mode and line_length being set when loaded From: "Pieter \\\"PoroCYon\\\" Sluys" <pcy(a)national.shitposting.agency> [ Upstream commit 7b9faf5df0ac495a1a3d7cdb64921c179f9008ac ] Currently, when loading the vfb module, the newly created fbdev has a line_length of 0, and its video mode would be PSEUDOCOLOR regardless of color depth. (The former could be worked around by calling the FBIOPUT_VSCREENINFO ioctl with having the FBACTIVIATE_FORCE flag set.) This patch automatically sets the line_length correctly, and the video mode is derived from the bit depth now as well. Thanks to Geert Uytterhoeven for confirming the bug and helping me with the patch. Output of `fbset -i' before the patch: mode "1366x768-60" # D: 72.432 MHz, H: 47.403 kHz, V: 60.004 Hz geometry 1366 768 1366 768 32 timings 13806 120 10 14 3 32 5 rgba 8/0,8/8,8/16,8/24 endmode Frame buffer device information: Name : Virtual FB Address : 0xffffaa1405d85000 Size : 4196352 Type : PACKED PIXELS Visual : PSEUDOCOLOR XPanStep : 1 YPanStep : 1 YWrapStep : 1 LineLength : 0 <-- note this Accelerator : No After: mode "1366x768-60" # D: 72.432 MHz, H: 47.403 kHz, V: 60.004 Hz geometry 1366 768 1366 768 32 timings 13806 120 10 14 3 32 5 rgba 8/0,8/8,8/16,8/24 endmode Frame buffer device information: Name : Virtual FB Address : 0xffffaa1405d85000 Size : 4196352 Type : PACKED PIXELS Visual : TRUECOLOR XPanStep : 1 YPanStep : 1 YWrapStep : 1 LineLength : 5464 Accelerator : No Signed-off-by: "Pieter \"PoroCYon\" Sluys" <pcy(a)national.shitposting.agency> Reviewed-by: Geert Uytterhoeven <geert(a)linux-m68k.org> [b.zolnierkie: minor fixups] Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/fbdev/vfb.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) --- a/drivers/video/fbdev/vfb.c +++ b/drivers/video/fbdev/vfb.c @@ -239,8 +239,23 @@ static int vfb_check_var(struct fb_var_s */ static int vfb_set_par(struct fb_info *info) { + switch (info->var.bits_per_pixel) { + case 1: + info->fix.visual = FB_VISUAL_MONO01; + break; + case 8: + info->fix.visual = FB_VISUAL_PSEUDOCOLOR; + break; + case 16: + case 24: + case 32: + info->fix.visual = FB_VISUAL_TRUECOLOR; + break; + } + info->fix.line_length = get_line_length(info->var.xres_virtual, info->var.bits_per_pixel); + return 0; } @@ -450,6 +465,8 @@ static int vfb_probe(struct platform_dev goto err2; platform_set_drvdata(dev, info); + vfb_set_par(info); + fb_info(info, "Virtual frame buffer device, using %ldK of video memory\n", videomemorysize >> 10); return 0; Patches currently in stable-queue which might be from pcy(a)national.shitposting.agency are queue-4.14/vfb-fix-video-mode-and-line_length-being-set-when-loaded.patch

7 years, 2 months

1
0
0 0

Patch "tty: n_gsm: Allow ADM response in addition to UA for control dlci" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tty: n_gsm: Allow ADM response in addition to UA for control dlci to the 4.14-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: tty-n_gsm-allow-adm-response-in-addition-to-ua-for-control-dlci.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Tony Lindgren <tony(a)atomide.com> Date: Wed, 3 Jan 2018 10:18:03 -0800 Subject: tty: n_gsm: Allow ADM response in addition to UA for control dlci From: Tony Lindgren <tony(a)atomide.com> [ Upstream commit ea3d8465ab9b3e01be329ac5195970a84bef76c5 ] Some devices have the control dlci stay in ADM mode instead of the UA mode. This can seen at least on droid 4 when trying to open the ts 27.010 mux port. Enabling n_gsm debug mode shows the control dlci always respond with DM to SABM instead of UA: # modprobe n_gsm debug=0xff # ldattach -d GSM0710 /dev/ttyS0 & gsmld_output: 00000000: f9 03 3f 01 1c f9 --> 0) C: SABM(P) gsmld_receive: 00000000: f9 03 1f 01 36 f9 <-- 0) C: DM(P) ... $ minicom -D /dev/gsmtty1 minicom: cannot open /dev/gsmtty1: No error information $ strace minicom -D /dev/gsmtty1 ... open("/dev/gsmtty1", O_RDWR|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = -1 EL2HLT Note that this is different issue from other n_gsm -EL2HLT issues such as timeouts when the control dlci does not respond at all. The ADM mode seems to be a quite common according to "RF Wireless World" article "GSM Issue-UE sends SABM and gets a DM response instead of UA response": This issue is most commonly observed in GSM networks where in UE sends SABM and expects network to send UA response but it ends up receiving DM response from the network. SABM stands for Set asynchronous balanced mode, UA stands for Unnumbered Acknowledge and DA stands for Disconnected Mode. An RLP entity can be in one of two modes: - Asynchronous Balanced Mode (ABM) - Asynchronous Disconnected Mode (ADM) Currently Linux kernel closes the control dlci after several retries in gsm_dlci_t1() on DM. This causes n_gsm /dev/gsmtty ports to produce error code -EL2HLT when trying to open them as the closing of control dlci has already set gsm->dead. Let's fix the issue by allowing control dlci stay in ADM mode after the retries so the /dev/gsmtty ports can be opened and used. It seems that it might take several attempts to get any response from the control dlci, so it's best to allow ADM mode only after the SABM retries are done. Note that for droid 4 additional patches are needed to mux the ttyS0 pins and to toggle RTS gpio_149 to wake up the mdm6600 modem are also needed to use n_gsm. And the mdm6600 modem needs to be powered on. Cc: linux-serial(a)vger.kernel.org Cc: Alan Cox <alan(a)llwyncelyn.cymru> Cc: Jiri Prchal <jiri.prchal(a)aksignal.cz> Cc: Jiri Slaby <jslaby(a)suse.cz> Cc: Marcel Partap <mpartap(a)gmx.net> Cc: Michael Scott <michael.scott(a)linaro.org> Cc: Peter Hurley <peter(a)hurleysoftware.com> Cc: Russ Gorby <russ.gorby(a)intel.com> Cc: Sascha Hauer <s.hauer(a)pengutronix.de> Cc: Sebastian Reichel <sre(a)kernel.org> Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/n_gsm.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) --- a/drivers/tty/n_gsm.c +++ b/drivers/tty/n_gsm.c @@ -1463,6 +1463,10 @@ static void gsm_dlci_open(struct gsm_dlc * in which case an opening port goes back to closed and a closing port * is simply put into closed state (any further frames from the other * end will get a DM response) + * + * Some control dlci can stay in ADM mode with other dlci working just + * fine. In that case we can just keep the control dlci open after the + * DLCI_OPENING retries time out. */ static void gsm_dlci_t1(unsigned long data) @@ -1476,8 +1480,15 @@ static void gsm_dlci_t1(unsigned long da if (dlci->retries) { gsm_command(dlci->gsm, dlci->addr, SABM|PF); mod_timer(&dlci->t1, jiffies + gsm->t1 * HZ / 100); - } else + } else if (!dlci->addr && gsm->control == (DM | PF)) { + if (debug & 8) + pr_info("DLCI %d opening in ADM mode.\n", + dlci->addr); + gsm_dlci_open(dlci); + } else { gsm_dlci_close(dlci); + } + break; case DLCI_CLOSING: dlci->retries--; @@ -1495,8 +1506,8 @@ static void gsm_dlci_t1(unsigned long da * @dlci: DLCI to open * * Commence opening a DLCI from the Linux side. We issue SABM messages - * to the modem which should then reply with a UA, at which point we - * will move into open state. Opening is done asynchronously with retry + * to the modem which should then reply with a UA or ADM, at which point + * we will move into open state. Opening is done asynchronously with retry * running off timers and the responses. */ Patches currently in stable-queue which might be from tony(a)atomide.com are queue-4.14/tty-n_gsm-allow-adm-response-in-addition-to-ua-for-control-dlci.patch

7 years, 2 months

1
0
0 0

Patch "uio_hv_generic: check that host supports monitor page" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled uio_hv_generic: check that host supports monitor page to the 4.14-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: uio_hv_generic-check-that-host-supports-monitor-page.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Stephen Hemminger <stephen(a)networkplumber.org> Date: Tue, 9 Jan 2018 12:57:31 -0800 Subject: uio_hv_generic: check that host supports monitor page From: Stephen Hemminger <stephen(a)networkplumber.org> [ Upstream commit 06028d15177a1b406b7b075ea47c6a352732f23a ] In order for userspace application to signal host, it needs the host to support the monitor page property. Check for the flag and fail if this is not supported. Signed-off-by: Stephen Hemminger <sthemmin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/uio/uio_hv_generic.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/drivers/uio/uio_hv_generic.c +++ b/drivers/uio/uio_hv_generic.c @@ -124,6 +124,13 @@ hv_uio_probe(struct hv_device *dev, if (ret) goto fail; + /* Communicating with host has to be via shared memory not hypercall */ + if (!dev->channel->offermsg.monitor_allocated) { + dev_err(&dev->device, "vmbus channel requires hypercall\n"); + ret = -ENOTSUPP; + goto fail_close; + } + dev->channel->inbound.ring_buffer->interrupt_mask = 1; set_channel_read_mode(dev->channel, HV_CALL_DIRECT); Patches currently in stable-queue which might be from stephen(a)networkplumber.org are queue-4.14/uio_hv_generic-check-that-host-supports-monitor-page.patch

7 years, 2 months

1
0
0 0

Patch "tpm: return a TPM_RC_COMMAND_CODE response if command is not implemented" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tpm: return a TPM_RC_COMMAND_CODE response if command is not implemented to the 4.14-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: tpm-return-a-tpm_rc_command_code-response-if-command-is-not-implemented.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Javier Martinez Canillas <javierm(a)redhat.com> Date: Thu, 30 Nov 2017 08:39:07 +0100 Subject: tpm: return a TPM_RC_COMMAND_CODE response if command is not implemented From: Javier Martinez Canillas <javierm(a)redhat.com> [ Upstream commit 095531f891e627e408606f2da4008d3d53e6748a ] According to the TPM Library Specification, a TPM device must do a command header validation before processing and return a TPM_RC_COMMAND_CODE code if the command is not implemented. So user-space will expect to handle that response as an error. But if the in-kernel resource manager is used (/dev/tpmrm?), an -EINVAL errno code is returned instead if the command isn't implemented. This confuses userspace since it doesn't expect that error value. This also isn't consistent with the behavior when not using TPM spaces and accessing the TPM directly (/dev/tpm?). In this case, the command is sent to the TPM even when not implemented and the TPM responds with an error. Instead of returning an -EINVAL errno code when the tpm_validate_command() function fails, synthesize a TPM command response so user-space can get a TPM_RC_COMMAND_CODE as expected when a chip doesn't implement the command. The TPM only sets 12 of the 32 bits in the TPM_RC response, so the TSS and TAB specifications define that higher layers in the stack should use some of the unused 20 bits to specify from which level of the stack the error is coming from. Since the TPM_RC_COMMAND_CODE response code is sent by the kernel resource manager, set the error level to the TAB/RM layer so user-space is aware of this. Suggested-by: Jason Gunthorpe <jgg(a)ziepe.ca> Signed-off-by: Javier Martinez Canillas <javierm(a)redhat.com> Reviewed-by: William Roberts <william.c.roberts(a)intel.com> Reviewed-by: Philip Tricca <philip.b.tricca(a)intel.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Tested-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/char/tpm/tpm-interface.c | 28 ++++++++++++++++++++-------- drivers/char/tpm/tpm.h | 5 +++++ 2 files changed, 25 insertions(+), 8 deletions(-) --- a/drivers/char/tpm/tpm-interface.c +++ b/drivers/char/tpm/tpm-interface.c @@ -328,7 +328,7 @@ unsigned long tpm_calc_ordinal_duration( } EXPORT_SYMBOL_GPL(tpm_calc_ordinal_duration); -static bool tpm_validate_command(struct tpm_chip *chip, +static int tpm_validate_command(struct tpm_chip *chip, struct tpm_space *space, const u8 *cmd, size_t len) @@ -340,10 +340,10 @@ static bool tpm_validate_command(struct unsigned int nr_handles; if (len < TPM_HEADER_SIZE) - return false; + return -EINVAL; if (!space) - return true; + return 0; if (chip->flags & TPM_CHIP_FLAG_TPM2 && chip->nr_commands) { cc = be32_to_cpu(header->ordinal); @@ -352,7 +352,7 @@ static bool tpm_validate_command(struct if (i < 0) { dev_dbg(&chip->dev, "0x%04X is an invalid command\n", cc); - return false; + return -EOPNOTSUPP; } attrs = chip->cc_attrs_tbl[i]; @@ -362,11 +362,11 @@ static bool tpm_validate_command(struct goto err_len; } - return true; + return 0; err_len: dev_dbg(&chip->dev, "%s: insufficient command length %zu", __func__, len); - return false; + return -EINVAL; } /** @@ -391,8 +391,20 @@ ssize_t tpm_transmit(struct tpm_chip *ch unsigned long stop; bool need_locality; - if (!tpm_validate_command(chip, space, buf, bufsiz)) - return -EINVAL; + rc = tpm_validate_command(chip, space, buf, bufsiz); + if (rc == -EINVAL) + return rc; + /* + * If the command is not implemented by the TPM, synthesize a + * response with a TPM2_RC_COMMAND_CODE return for user-space. + */ + if (rc == -EOPNOTSUPP) { + header->length = cpu_to_be32(sizeof(*header)); + header->tag = cpu_to_be16(TPM2_ST_NO_SESSIONS); + header->return_code = cpu_to_be32(TPM2_RC_COMMAND_CODE | + TSS2_RESMGR_TPM_RC_LAYER); + return bufsiz; + } if (bufsiz > TPM_BUFSIZE) bufsiz = TPM_BUFSIZE; --- a/drivers/char/tpm/tpm.h +++ b/drivers/char/tpm/tpm.h @@ -93,12 +93,17 @@ enum tpm2_structures { TPM2_ST_SESSIONS = 0x8002, }; +/* Indicates from what layer of the software stack the error comes from */ +#define TSS2_RC_LAYER_SHIFT 16 +#define TSS2_RESMGR_TPM_RC_LAYER (11 << TSS2_RC_LAYER_SHIFT) + enum tpm2_return_codes { TPM2_RC_SUCCESS = 0x0000, TPM2_RC_HASH = 0x0083, /* RC_FMT1 */ TPM2_RC_HANDLE = 0x008B, TPM2_RC_INITIALIZE = 0x0100, /* RC_VER1 */ TPM2_RC_DISABLED = 0x0120, + TPM2_RC_COMMAND_CODE = 0x0143, TPM2_RC_TESTING = 0x090A, /* RC_WARN */ TPM2_RC_REFERENCE_H0 = 0x0910, }; Patches currently in stable-queue which might be from javierm(a)redhat.com are queue-4.14/tpm-return-a-tpm_rc_command_code-response-if-command-is-not-implemented.patch

7 years, 2 months

1
0
0 0

Patch "thermal: power_allocator: fix one race condition issue for thermal_instances list" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled thermal: power_allocator: fix one race condition issue for thermal_instances list to the 4.14-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: thermal-power_allocator-fix-one-race-condition-issue-for-thermal_instances-list.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Yi Zeng <yizeng(a)asrmicro.com> Date: Tue, 26 Dec 2017 19:22:26 +0800 Subject: thermal: power_allocator: fix one race condition issue for thermal_instances list From: Yi Zeng <yizeng(a)asrmicro.com> [ Upstream commit a5de11d67dcd268b8d0beb73dc374de5e97f0caf ] When invoking allow_maximum_power and traverse tz->thermal_instances, we should grab thermal_zone_device->lock to avoid race condition. For example, during the system reboot, if the mali GPU device implements device shutdown callback and unregister GPU devfreq cooling device, the deleted list head may be accessed to cause panic, as the following log shows: [ 33.551070] c3 25 (kworker/3:0) Unable to handle kernel paging request at virtual address dead000000000070 [ 33.566708] c3 25 (kworker/3:0) pgd = ffffffc0ed290000 [ 33.572071] c3 25 (kworker/3:0) [dead000000000070] *pgd=00000001ed292003, *pud=00000001ed292003, *pmd=0000000000000000 [ 33.581515] c3 25 (kworker/3:0) Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 33.599761] c3 25 (kworker/3:0) CPU: 3 PID: 25 Comm: kworker/3:0 Not tainted 4.4.35+ #912 [ 33.614137] c3 25 (kworker/3:0) Workqueue: events_freezable thermal_zone_device_check [ 33.620245] c3 25 (kworker/3:0) task: ffffffc0f32e4200 ti: ffffffc0f32f0000 task.ti: ffffffc0f32f0000 [ 33.629466] c3 25 (kworker/3:0) PC is at power_allocator_throttle+0x7c8/0x8a4 [ 33.636609] c3 25 (kworker/3:0) LR is at power_allocator_throttle+0x808/0x8a4 [ 33.643742] c3 25 (kworker/3:0) pc : [<ffffff8008683dd0>] lr : [<ffffff8008683e10>] pstate: 20000145 [ 33.652874] c3 25 (kworker/3:0) sp : ffffffc0f32f3bb0 [ 34.468519] c3 25 (kworker/3:0) Process kworker/3:0 (pid: 25, stack limit = 0xffffffc0f32f0020) [ 34.477220] c3 25 (kworker/3:0) Stack: (0xffffffc0f32f3bb0 to 0xffffffc0f32f4000) [ 34.819822] c3 25 (kworker/3:0) Call trace: [ 34.824021] c3 25 (kworker/3:0) Exception stack(0xffffffc0f32f39c0 to 0xffffffc0f32f3af0) [ 34.924993] c3 25 (kworker/3:0) [<ffffff8008683dd0>] power_allocator_throttle+0x7c8/0x8a4 [ 34.933184] c3 25 (kworker/3:0) [<ffffff80086807f4>] handle_thermal_trip.part.25+0x70/0x224 [ 34.941545] c3 25 (kworker/3:0) [<ffffff8008680a68>] thermal_zone_device_update+0xc0/0x20c [ 34.949818] c3 25 (kworker/3:0) [<ffffff8008680bd4>] thermal_zone_device_check+0x20/0x2c [ 34.957924] c3 25 (kworker/3:0) [<ffffff80080b93a4>] process_one_work+0x168/0x458 [ 34.965414] c3 25 (kworker/3:0) [<ffffff80080ba068>] worker_thread+0x13c/0x4b4 [ 34.972650] c3 25 (kworker/3:0) [<ffffff80080c0a4c>] kthread+0xe8/0xfc [ 34.979187] c3 25 (kworker/3:0) [<ffffff8008084e90>] ret_from_fork+0x10/0x40 [ 34.986244] c3 25 (kworker/3:0) Code: f9405e73 eb1302bf d102e273 54ffc460 (b9402a61) [ 34.994339] c3 25 (kworker/3:0) ---[ end trace 32057901e3b7e1db ]--- Signed-off-by: Yi Zeng <yizeng(a)asrmicro.com> Signed-off-by: Zhang Rui <rui.zhang(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/thermal/power_allocator.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/thermal/power_allocator.c +++ b/drivers/thermal/power_allocator.c @@ -523,6 +523,7 @@ static void allow_maximum_power(struct t struct thermal_instance *instance; struct power_allocator_params *params = tz->governor_data; + mutex_lock(&tz->lock); list_for_each_entry(instance, &tz->thermal_instances, tz_node) { if ((instance->trip != params->trip_max_desired_temperature) || (!cdev_is_power_actor(instance->cdev))) @@ -534,6 +535,7 @@ static void allow_maximum_power(struct t mutex_unlock(&instance->cdev->lock); thermal_cdev_update(instance->cdev); } + mutex_unlock(&tz->lock); } /** Patches currently in stable-queue which might be from yizeng(a)asrmicro.com are queue-4.14/thermal-power_allocator-fix-one-race-condition-issue-for-thermal_instances-list.patch

7 years, 2 months

1
0
0 0

Patch "thermal: int3400_thermal: fix error handling in int3400_thermal_probe()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled thermal: int3400_thermal: fix error handling in int3400_thermal_probe() to the 4.14-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: thermal-int3400_thermal-fix-error-handling-in-int3400_thermal_probe.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Alexey Khoroshilov <khoroshilov(a)ispras.ru> Date: Sat, 30 Dec 2017 01:05:21 +0300 Subject: thermal: int3400_thermal: fix error handling in int3400_thermal_probe() From: Alexey Khoroshilov <khoroshilov(a)ispras.ru> [ Upstream commit 0be86969ae385c5c944286bd9f66068525de15ee ] There are resources that are not dealocated on failure path in int3400_thermal_probe(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov <khoroshilov(a)ispras.ru> Signed-off-by: Zhang Rui <rui.zhang(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/thermal/int340x_thermal/int3400_thermal.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) --- a/drivers/thermal/int340x_thermal/int3400_thermal.c +++ b/drivers/thermal/int340x_thermal/int3400_thermal.c @@ -319,17 +319,21 @@ static int int3400_thermal_probe(struct result = sysfs_create_group(&pdev->dev.kobj, &uuid_attribute_group); if (result) - goto free_zone; + goto free_rel_misc; result = acpi_install_notify_handler( priv->adev->handle, ACPI_DEVICE_NOTIFY, int3400_notify, (void *)priv); if (result) - goto free_zone; + goto free_sysfs; return 0; -free_zone: +free_sysfs: + sysfs_remove_group(&pdev->dev.kobj, &uuid_attribute_group); +free_rel_misc: + if (!priv->rel_misc_dev_res) + acpi_thermal_rel_misc_device_remove(priv->adev->handle); thermal_zone_device_unregister(priv->thermal); free_art_trt: kfree(priv->trts); Patches currently in stable-queue which might be from khoroshilov(a)ispras.ru are queue-4.14/thermal-int3400_thermal-fix-error-handling-in-int3400_thermal_probe.patch

7 years, 2 months

1
0
0 0

Patch "tcmu: release blocks for partially setup cmds" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tcmu: release blocks for partially setup cmds to the 4.14-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: tcmu-release-blocks-for-partially-setup-cmds.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Mike Christie <mchristi(a)redhat.com> Date: Tue, 28 Nov 2017 12:40:33 -0600 Subject: tcmu: release blocks for partially setup cmds From: Mike Christie <mchristi(a)redhat.com> [ Upstream commit 810b8153c4243d2012a6ec002ddd3bbc9a9ae8c2 ] If we cannot setup a cmd because we run out of ring space or global pages release the blocks before sleeping. This prevents a deadlock where dev0 has waiting_blocks set and needs N blocks, but dev1 to devX have each allocated N / X blocks and also hit the global block limit so they went to sleep. find_free_blocks is not able to take the sleeping dev's blocks becaause their waiting_blocks is set and even if it was not the block returned by find_last_bit could equal dbi_max. The latter will probably never happen because DATA_BLOCK_BITS is so high but in the next patches DATA_BLOCK_BITS and TCMU_GLOBAL_MAX_BLOCKS will be settable so it might be lower and could happen. Signed-off-by: Mike Christie <mchristi(a)redhat.com> Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/target_core_user.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/drivers/target/target_core_user.c +++ b/drivers/target/target_core_user.c @@ -796,6 +796,13 @@ tcmu_queue_cmd_ring(struct tcmu_cmd *tcm int ret; DEFINE_WAIT(__wait); + /* + * Don't leave commands partially setup because the unmap + * thread might need the blocks to make forward progress. + */ + tcmu_cmd_free_data(tcmu_cmd, tcmu_cmd->dbi_cur); + tcmu_cmd_reset_dbi_cur(tcmu_cmd); + prepare_to_wait(&udev->wait_cmdr, &__wait, TASK_INTERRUPTIBLE); pr_debug("sleeping for ring space\n"); Patches currently in stable-queue which might be from mchristi(a)redhat.com are queue-4.14/tcmu-release-blocks-for-partially-setup-cmds.patch

7 years, 2 months

1
0
0 0

Patch "staging: lustre: disable preempt while sampling processor id." has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: lustre: disable preempt while sampling processor id. to the 4.14-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: staging-lustre-disable-preempt-while-sampling-processor-id.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: NeilBrown <neilb(a)suse.com> Date: Tue, 19 Dec 2017 10:01:47 +1100 Subject: staging: lustre: disable preempt while sampling processor id. From: NeilBrown <neilb(a)suse.com> [ Upstream commit dbeccabf5294e80f7cc9ee566746c42211bed736 ] Calling smp_processor_id() without disabling preemption triggers a warning (if CONFIG_DEBUG_PREEMPT). I think the result of cfs_cpt_current() is only used as a hint for load balancing, rather than as a precise and stable indicator of the current CPU. So it doesn't need to be called with preemption disabled. So disable preemption inside cfs_cpt_current() to silence the warning. Signed-off-by: NeilBrown <neilb(a)suse.com> Reviewed-by: Andreas Dilger <andreas.dilger(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) --- a/drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c +++ b/drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c @@ -528,19 +528,20 @@ EXPORT_SYMBOL(cfs_cpt_spread_node); int cfs_cpt_current(struct cfs_cpt_table *cptab, int remap) { - int cpu = smp_processor_id(); - int cpt = cptab->ctb_cpu2cpt[cpu]; + int cpu; + int cpt; - if (cpt < 0) { - if (!remap) - return cpt; + preempt_disable(); + cpu = smp_processor_id(); + cpt = cptab->ctb_cpu2cpt[cpu]; + if (cpt < 0 && remap) { /* don't return negative value for safety of upper layer, * instead we shadow the unknown cpu to a valid partition ID */ cpt = cpu % cptab->ctb_nparts; } - + preempt_enable(); return cpt; } EXPORT_SYMBOL(cfs_cpt_current); Patches currently in stable-queue which might be from neilb(a)suse.com are queue-4.14/staging-lustre-disable-preempt-while-sampling-processor-id.patch queue-4.14/vfs-close-race-between-getcwd-and-d_move.patch

7 years, 2 months

1
0
0 0

Patch "spi: sh-msiof: Fix timeout failures for TX-only DMA transfers" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled spi: sh-msiof: Fix timeout failures for TX-only DMA transfers to the 4.14-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: spi-sh-msiof-fix-timeout-failures-for-tx-only-dma-transfers.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Geert Uytterhoeven <geert+renesas(a)glider.be> Date: Wed, 3 Jan 2018 18:11:14 +0100 Subject: spi: sh-msiof: Fix timeout failures for TX-only DMA transfers From: Geert Uytterhoeven <geert+renesas(a)glider.be> [ Upstream commit 89434c3c35081439627baa2225622d5bd12242fe ] When using RX (with or without TX), the DMA interrupt triggers completion when the RX FIFO has been emptied, i.e. after the full transfer has finished. However, when using TX without RX, the DMA interrupt triggers completion as soon as the DMA engine has filled the TX FIFO, i.e. before the full transfer has finished. Then sh_msiof_modify_ctr_wait() will spin until the transfer has really finished and the TFSE bit is cleared, for at most 1 ms. For slow speeds and/or large transfers, this may cause timeouts and transfer failures: spi_sh_msiof e6e10000.spi: failed to shut down hardware 74x164 spi2.0: SPI transfer failed: -110 spi_master spi2: failed to transfer one message from queue 74x164 spi2.0: Failed writing: -110 Fix this by waiting explicitly until the TX FIFO has been emptied. Based on a patch in the BSP by Hiromitsu Yamasaki. Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/spi/spi-sh-msiof.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) --- a/drivers/spi/spi-sh-msiof.c +++ b/drivers/spi/spi-sh-msiof.c @@ -797,11 +797,21 @@ static int sh_msiof_dma_once(struct sh_m goto stop_dma; } - /* wait for tx fifo to be emptied / rx fifo to be filled */ + /* wait for tx/rx DMA completion */ ret = sh_msiof_wait_for_completion(p); if (ret) goto stop_reset; + if (!rx) { + reinit_completion(&p->done); + sh_msiof_write(p, IER, IER_TEOFE); + + /* wait for tx fifo to be emptied */ + ret = sh_msiof_wait_for_completion(p); + if (ret) + goto stop_reset; + } + /* clear status bits */ sh_msiof_reset_str(p); Patches currently in stable-queue which might be from geert+renesas(a)glider.be are queue-4.14/acpi-ec-fix-debugfs_create_-usage.patch queue-4.14/spi-sh-msiof-fix-timeout-failures-for-tx-only-dma-transfers.patch

7 years, 2 months

1
0
0 0

Patch "signal/powerpc: Document conflicts with SI_USER and SIGFPE and SIGTRAP" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled signal/powerpc: Document conflicts with SI_USER and SIGFPE and SIGTRAP to the 4.14-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: signal-powerpc-document-conflicts-with-si_user-and-sigfpe-and-sigtrap.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: "Eric W. Biederman" <ebiederm(a)xmission.com> Date: Sat, 19 Aug 2017 15:26:01 -0500 Subject: signal/powerpc: Document conflicts with SI_USER and SIGFPE and SIGTRAP From: "Eric W. Biederman" <ebiederm(a)xmission.com> [ Upstream commit cf4674c46c66e45f238f8f7e81af2a444b970c0a ] Setting si_code to 0 results in a userspace seeing an si_code of 0. This is the same si_code as SI_USER. Posix and common sense requires that SI_USER not be a signal specific si_code. As such this use of 0 for the si_code is a pretty horribly broken ABI. Further use of si_code == 0 guaranteed that copy_siginfo_to_user saw a value of __SI_KILL and now sees a value of SIL_KILL with the result that uid and pid fields are copied and which might copying the si_addr field by accident but certainly not by design. Making this a very flakey implementation. Utilizing FPE_FIXME and TRAP_FIXME, siginfo_layout() will now return SIL_FAULT and the appropriate fields will be reliably copied. Possible ABI fixes includee: - Send the signal without siginfo - Don't generate a signal - Possibly assign and use an appropriate si_code - Don't handle cases which can't happen Cc: Paul Mackerras <paulus(a)samba.org> Cc: Kumar Gala <kumar.gala(a)freescale.com> Cc: Michael Ellerman <mpe(a)ellerman.id.au> Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> Cc: linuxppc-dev(a)lists.ozlabs.org Ref: 9bad068c24d7 ("[PATCH] ppc32: support for e500 and 85xx") Ref: 0ed70f6105ef ("PPC32: Provide proper siginfo information on various exceptions.") History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/include/uapi/asm/siginfo.h | 15 +++++++++++++++ arch/powerpc/kernel/traps.c | 10 +++++----- 2 files changed, 20 insertions(+), 5 deletions(-) --- a/arch/powerpc/include/uapi/asm/siginfo.h +++ b/arch/powerpc/include/uapi/asm/siginfo.h @@ -18,4 +18,19 @@ #undef NSIGTRAP #define NSIGTRAP 4 +/* + * SIGFPE si_codes + */ +#ifdef __KERNEL__ +#define FPE_FIXME 0 /* Broken dup of SI_USER */ +#endif /* __KERNEL__ */ + +/* + * SIGTRAP si_codes + */ +#ifdef __KERNEL__ +#define TRAP_FIXME 0 /* Broken dup of SI_USER */ +#endif /* __KERNEL__ */ + + #endif /* _ASM_POWERPC_SIGINFO_H */ --- a/arch/powerpc/kernel/traps.c +++ b/arch/powerpc/kernel/traps.c @@ -720,7 +720,7 @@ void unknown_exception(struct pt_regs *r printk("Bad trap at PC: %lx, SR: %lx, vector=%lx\n", regs->nip, regs->msr, regs->trap); - _exception(SIGTRAP, regs, 0, 0); + _exception(SIGTRAP, regs, TRAP_FIXME, 0); exception_exit(prev_state); } @@ -742,7 +742,7 @@ bail: void RunModeException(struct pt_regs *regs) { - _exception(SIGTRAP, regs, 0, 0); + _exception(SIGTRAP, regs, TRAP_FIXME, 0); } void single_step_exception(struct pt_regs *regs) @@ -781,7 +781,7 @@ static void emulate_single_step(struct p static inline int __parse_fpscr(unsigned long fpscr) { - int ret = 0; + int ret = FPE_FIXME; /* Invalid operation */ if ((fpscr & FPSCR_VE) && (fpscr & FPSCR_VX)) @@ -1769,7 +1769,7 @@ void SPEFloatingPointException(struct pt extern int do_spe_mathemu(struct pt_regs *regs); unsigned long spefscr; int fpexc_mode; - int code = 0; + int code = FPE_FIXME; int err; flush_spe_to_thread(current); @@ -1838,7 +1838,7 @@ void SPEFloatingPointRoundException(stru printk(KERN_ERR "unrecognized spe instruction " "in %s at %lx\n", current->comm, regs->nip); } else { - _exception(SIGFPE, regs, 0, regs->nip); + _exception(SIGFPE, regs, FPE_FIXME, regs->nip); return; } } Patches currently in stable-queue which might be from ebiederm(a)xmission.com are queue-4.14/signal-metag-document-a-conflict-with-si_user-with-sigfpe.patch queue-4.14/signal-arm-document-conflicts-with-si_user-and-sigfpe.patch queue-4.14/signal-powerpc-document-conflicts-with-si_user-and-sigfpe-and-sigtrap.patch

7 years, 2 months

1
0
0 0

Patch "signal/metag: Document a conflict with SI_USER with SIGFPE" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled signal/metag: Document a conflict with SI_USER with SIGFPE to the 4.14-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: signal-metag-document-a-conflict-with-si_user-with-sigfpe.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: "Eric W. Biederman" <ebiederm(a)xmission.com> Date: Tue, 1 Aug 2017 10:37:40 -0500 Subject: signal/metag: Document a conflict with SI_USER with SIGFPE From: "Eric W. Biederman" <ebiederm(a)xmission.com> [ Upstream commit b80328be53c215346b153769267b38f531d89b4f ] Setting si_code to 0 results in a userspace seeing an si_code of 0. This is the same si_code as SI_USER. Posix and common sense requires that SI_USER not be a signal specific si_code. As such this use of 0 for the si_code is a pretty horribly broken ABI. Further use of si_code == 0 guaranteed that copy_siginfo_to_user saw a value of __SI_KILL and now sees a value of SIL_KILL with the result hat uid and pid fields are copied and which might copying the si_addr field by accident but certainly not by design. Making this a very flakey implementation. Utilizing FPE_FIXME siginfo_layout will now return SIL_FAULT and the appropriate fields will reliably be copied. Possible ABI fixes includee: - Send the signal without siginfo - Don't generate a signal - Possibly assign and use an appropriate si_code - Don't handle cases which can't happen Cc: James Hogan <james.hogan(a)imgtec.com> Cc: linux-metag(a)vger.kernel.org Ref: ac919f0883e5 ("metag: Traps") Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/metag/include/uapi/asm/siginfo.h | 7 +++++++ arch/metag/kernel/traps.c | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) --- a/arch/metag/include/uapi/asm/siginfo.h +++ b/arch/metag/include/uapi/asm/siginfo.h @@ -6,4 +6,11 @@ #include <asm-generic/siginfo.h> +/* + * SIGFPE si_codes + */ +#ifdef __KERNEL__ +#define FPE_FIXME 0 /* Broken dup of SI_USER */ +#endif /* __KERNEL__ */ + #endif --- a/arch/metag/kernel/traps.c +++ b/arch/metag/kernel/traps.c @@ -735,7 +735,7 @@ TBIRES fpe_handler(TBIRES State, int Sig else if (error_state & TXSTAT_FPE_INEXACT_BIT) info.si_code = FPE_FLTRES; else - info.si_code = 0; + info.si_code = FPE_FIXME; info.si_errno = 0; info.si_addr = (__force void __user *)regs->ctx.CurrPC; force_sig_info(SIGFPE, &info, current); Patches currently in stable-queue which might be from ebiederm(a)xmission.com are queue-4.14/signal-metag-document-a-conflict-with-si_user-with-sigfpe.patch queue-4.14/signal-arm-document-conflicts-with-si_user-and-sigfpe.patch queue-4.14/signal-powerpc-document-conflicts-with-si_user-and-sigfpe-and-sigtrap.patch

7 years, 2 months

1
0
0 0

Patch "sdhci: Advertise 2.0v supply on SDIO host controller" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sdhci: Advertise 2.0v supply on SDIO host controller to the 4.14-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: sdhci-advertise-2.0v-supply-on-sdio-host-controller.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Date: Thu, 11 Jan 2018 15:51:58 +0200 Subject: sdhci: Advertise 2.0v supply on SDIO host controller From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> [ Upstream commit 2a609abe71ca59e4bd7139e161eaca2144ae6f2e ] On Intel Edison the Broadcom Wi-Fi card, which is connected to SDIO, requires 2.0v, while the host, according to Intel Merrifield TRM, supports 1.8v supply only. The card announces itself as mmc2: new ultra high speed DDR50 SDIO card at address 0001 Introduce a custom OCR mask for SDIO host controller on Intel Merrifield and add a special case to sdhci_set_power_noreg() to override 2.0v supply by enforcing 1.8v power choice. Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mmc/host/sdhci-pci-core.c | 2 ++ drivers/mmc/host/sdhci.c | 7 +++++++ 2 files changed, 9 insertions(+) --- a/drivers/mmc/host/sdhci-pci-core.c +++ b/drivers/mmc/host/sdhci-pci-core.c @@ -806,6 +806,8 @@ static int intel_mrfld_mmc_probe_slot(st slot->host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V; break; case INTEL_MRFLD_SDIO: + /* Advertise 2.0v for compatibility with the SDIO card's OCR */ + slot->host->ocr_mask = MMC_VDD_20_21 | MMC_VDD_165_195; slot->host->mmc->caps |= MMC_CAP_NONREMOVABLE | MMC_CAP_POWER_OFF_CARD; break; --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -1470,6 +1470,13 @@ void sdhci_set_power_noreg(struct sdhci_ if (mode != MMC_POWER_OFF) { switch (1 << vdd) { case MMC_VDD_165_195: + /* + * Without a regulator, SDHCI does not support 2.0v + * so we only get here if the driver deliberately + * added the 2.0v range to ocr_avail. Map it to 1.8v + * for the purpose of turning on the power. + */ + case MMC_VDD_20_21: pwr = SDHCI_POWER_180; break; case MMC_VDD_29_30: Patches currently in stable-queue which might be from andriy.shevchenko(a)linux.intel.com are queue-4.14/sdhci-advertise-2.0v-supply-on-sdio-host-controller.patch

7 years, 2 months

1
0
0 0

Patch "selftests/net: fix bugs in address and port initialization" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selftests/net: fix bugs in address and port initialization to the 4.14-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-net-fix-bugs-in-address-and-port-initialization.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com> Date: Mon, 25 Dec 2017 14:43:04 -0800 Subject: selftests/net: fix bugs in address and port initialization From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com> [ Upstream commit d36f45e5b46723cf2d4147173e18c52d4143176d ] Address/port initialization should work correctly regardless of the order in which command line arguments are supplied, E.g, cfg_port should be used to connect to the remote host even if it is processed after -D, src/dst address initialization should not require that [-4|-6] be specified before the -S or -D args, receiver should be able to bind to *.<cfg_port> Achieve this by making sure that the address/port structures are initialized after all command line options are parsed. Store cfg_port in host-byte order, and use htons() to set up the sin_port/sin6_port before bind/connect, so that the network system calls get the correct values in network-byte order. Signed-off-by: Sowmini Varadhan <sowmini.varadhan(a)oracle.com> Acked-by: Willem de Bruijn <willemb(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/net/msg_zerocopy.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) --- a/tools/testing/selftests/net/msg_zerocopy.c +++ b/tools/testing/selftests/net/msg_zerocopy.c @@ -259,22 +259,28 @@ static int setup_ip6h(struct ipv6hdr *ip return sizeof(*ip6h); } -static void setup_sockaddr(int domain, const char *str_addr, void *sockaddr) + +static void setup_sockaddr(int domain, const char *str_addr, + struct sockaddr_storage *sockaddr) { struct sockaddr_in6 *addr6 = (void *) sockaddr; struct sockaddr_in *addr4 = (void *) sockaddr; switch (domain) { case PF_INET: + memset(addr4, 0, sizeof(*addr4)); addr4->sin_family = AF_INET; addr4->sin_port = htons(cfg_port); - if (inet_pton(AF_INET, str_addr, &(addr4->sin_addr)) != 1) + if (str_addr && + inet_pton(AF_INET, str_addr, &(addr4->sin_addr)) != 1) error(1, 0, "ipv4 parse error: %s", str_addr); break; case PF_INET6: + memset(addr6, 0, sizeof(*addr6)); addr6->sin6_family = AF_INET6; addr6->sin6_port = htons(cfg_port); - if (inet_pton(AF_INET6, str_addr, &(addr6->sin6_addr)) != 1) + if (str_addr && + inet_pton(AF_INET6, str_addr, &(addr6->sin6_addr)) != 1) error(1, 0, "ipv6 parse error: %s", str_addr); break; default: @@ -603,6 +609,7 @@ static void parse_opts(int argc, char ** sizeof(struct tcphdr) - 40 /* max tcp options */; int c; + char *daddr = NULL, *saddr = NULL; cfg_payload_len = max_payload_len; @@ -627,7 +634,7 @@ static void parse_opts(int argc, char ** cfg_cpu = strtol(optarg, NULL, 0); break; case 'D': - setup_sockaddr(cfg_family, optarg, &cfg_dst_addr); + daddr = optarg; break; case 'i': cfg_ifindex = if_nametoindex(optarg); @@ -638,7 +645,7 @@ static void parse_opts(int argc, char ** cfg_cork_mixed = true; break; case 'p': - cfg_port = htons(strtoul(optarg, NULL, 0)); + cfg_port = strtoul(optarg, NULL, 0); break; case 'r': cfg_rx = true; @@ -647,7 +654,7 @@ static void parse_opts(int argc, char ** cfg_payload_len = strtoul(optarg, NULL, 0); break; case 'S': - setup_sockaddr(cfg_family, optarg, &cfg_src_addr); + saddr = optarg; break; case 't': cfg_runtime_ms = 200 + strtoul(optarg, NULL, 10) * 1000; @@ -660,6 +667,8 @@ static void parse_opts(int argc, char ** break; } } + setup_sockaddr(cfg_family, daddr, &cfg_dst_addr); + setup_sockaddr(cfg_family, saddr, &cfg_src_addr); if (cfg_payload_len > max_payload_len) error(1, 0, "-s: payload exceeds max (%d)", max_payload_len); Patches currently in stable-queue which might be from sowmini.varadhan(a)oracle.com are queue-4.14/selftests-net-fix-bugs-in-address-and-port-initialization.patch queue-4.14/rds-reset-rs-rs_bound_addr-in-rds_add_bound-failure-path.patch

7 years, 2 months

1
0
0 0

Patch "scsi: mpt3sas: Proper handling of set/clear of "ATA command pending" flag." has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: mpt3sas: Proper handling of set/clear of "ATA command pending" flag. to the 4.14-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: scsi-mpt3sas-proper-handling-of-set-clear-of-ata-command-pending-flag.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Chaitra P B <chaitra.basappa(a)broadcom.com> Date: Wed, 27 Dec 2017 23:09:11 -0800 Subject: scsi: mpt3sas: Proper handling of set/clear of "ATA command pending" flag. From: Chaitra P B <chaitra.basappa(a)broadcom.com> [ Upstream commit f49d4aed1315a7b766d855f1367142e682b0cc87 ] 1. In IO path, setting of "ATA command pending" flag early before device removal, invalid device handle etc., checks causes any new commands to be always returned with SAM_STAT_BUSY and when the driver removes the drive the SML issues SYNC Cache command and that command is always returned with SAM_STAT_BUSY and thus making SYNC Cache command to requeued. 2. If the driver gets an ATA PT command for a SATA drive then the driver set "ATA command pending" flag in device specific data structure not to allow any further commands until the ATA PT command is completed. However, after setting the flag if the driver decides to return the command back to upper layers without actually issuing to the firmware (i.e., returns from qcmd failure return paths) then the corresponding flag is not cleared and this prevents the driver from sending any new commands to the drive. This patch fixes above two issues by setting of "ATA command pending" flag after checking for whether device deleted, invalid device handle, device busy with task management. And by setting "ATA command pending" flag to false in all of the qcmd failure return paths after setting the flag. Signed-off-by: Chaitra P B <chaitra.basappa(a)broadcom.com> Signed-off-by: Suganath Prabu S <suganath-prabu.subramani(a)broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/mpt3sas/mpt3sas_scsih.c | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c @@ -4106,19 +4106,6 @@ scsih_qcmd(struct Scsi_Host *shost, stru return 0; } - /* - * Bug work around for firmware SATL handling. The loop - * is based on atomic operations and ensures consistency - * since we're lockless at this point - */ - do { - if (test_bit(0, &sas_device_priv_data->ata_command_pending)) { - scmd->result = SAM_STAT_BUSY; - scmd->scsi_done(scmd); - return 0; - } - } while (_scsih_set_satl_pending(scmd, true)); - sas_target_priv_data = sas_device_priv_data->sas_target; /* invalid device handle */ @@ -4144,6 +4131,19 @@ scsih_qcmd(struct Scsi_Host *shost, stru sas_device_priv_data->block) return SCSI_MLQUEUE_DEVICE_BUSY; + /* + * Bug work around for firmware SATL handling. The loop + * is based on atomic operations and ensures consistency + * since we're lockless at this point + */ + do { + if (test_bit(0, &sas_device_priv_data->ata_command_pending)) { + scmd->result = SAM_STAT_BUSY; + scmd->scsi_done(scmd); + return 0; + } + } while (_scsih_set_satl_pending(scmd, true)); + if (scmd->sc_data_direction == DMA_FROM_DEVICE) mpi_control = MPI2_SCSIIO_CONTROL_READ; else if (scmd->sc_data_direction == DMA_TO_DEVICE) @@ -4170,6 +4170,7 @@ scsih_qcmd(struct Scsi_Host *shost, stru if (!smid) { pr_err(MPT3SAS_FMT "%s: failed obtaining a smid\n", ioc->name, __func__); + _scsih_set_satl_pending(scmd, false); goto out; } mpi_request = mpt3sas_base_get_msg_frame(ioc, smid); @@ -4200,6 +4201,7 @@ scsih_qcmd(struct Scsi_Host *shost, stru if (mpi_request->DataLength) { if (ioc->build_sg_scmd(ioc, scmd, smid)) { mpt3sas_base_free_smid(ioc, smid); + _scsih_set_satl_pending(scmd, false); goto out; } } else Patches currently in stable-queue which might be from chaitra.basappa(a)broadcom.com are queue-4.14/scsi-mpt3sas-proper-handling-of-set-clear-of-ata-command-pending-flag.patch

7 years, 2 months

1
0
0 0

Patch "scsi: megaraid_sas: unload flag should be set after scsi_remove_host is called" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: megaraid_sas: unload flag should be set after scsi_remove_host is called to the 4.14-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: scsi-megaraid_sas-unload-flag-should-be-set-after-scsi_remove_host-is-called.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com> Date: Fri, 5 Jan 2018 05:27:41 -0800 Subject: scsi: megaraid_sas: unload flag should be set after scsi_remove_host is called From: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com> [ Upstream commit f3f7920b3910171b2999c7dc2335eb9f583e44f2 ] Issue - Driver returns DID_NO_CONNECT when unload is in progress, indicated using instance->unload flag. In case of dynamic unload of driver, this flag is set before calling scsi_remove_host(). While doing manual driver unload, user will see lots of prints for Sync Cache command with DID_NO_CONNECT status. Fix - Set the instance->unload flag after scsi_remove_host(). Allow device removal process to be completed and do not block any command before that. SCSI commands (like SYNC_CACHE) are received (as part of scsi_remove_host) by driver during unload will be submitted further down to the drives. Signed-off-by: Sumit Saxena <sumit.saxena(a)broadcom.com> Signed-off-by: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/megaraid/megaraid_sas_base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -6605,7 +6605,6 @@ static void megasas_detach_one(struct pc u32 pd_seq_map_sz; instance = pci_get_drvdata(pdev); - instance->unload = 1; host = instance->host; fusion = instance->ctrl_context; @@ -6616,6 +6615,7 @@ static void megasas_detach_one(struct pc if (instance->fw_crash_state != UNAVAILABLE) megasas_free_host_crash_buffer(instance); scsi_remove_host(instance->host); + instance->unload = 1; if (megasas_wait_for_adapter_operational(instance)) goto skip_firing_dcmds; Patches currently in stable-queue which might be from shivasharan.srikanteshwara(a)broadcom.com are queue-4.14/scsi-megaraid_sas-error-handling-for-invalid-ldcount-provided-by-firmware-in-raid-map.patch queue-4.14/scsi-megaraid_sas-unload-flag-should-be-set-after-scsi_remove_host-is-called.patch

7 years, 2 months

1
0
0 0

Patch "scsi: megaraid_sas: Error handling for invalid ldcount provided by firmware in RAID map" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: megaraid_sas: Error handling for invalid ldcount provided by firmware in RAID map to the 4.14-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: scsi-megaraid_sas-error-handling-for-invalid-ldcount-provided-by-firmware-in-raid-map.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com> Date: Fri, 5 Jan 2018 05:27:40 -0800 Subject: scsi: megaraid_sas: Error handling for invalid ldcount provided by firmware in RAID map From: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com> [ Upstream commit 7ada701d0d5e5c6d357e157a72b841db3e8d03f4 ] Currently driver does not validate ldcount provided by firmware. If the value is invalid, fail RAID map validation accordingly. This issue is rare to hit in field and is fixed as part of code review. Signed-off-by: Sumit Saxena <sumit.saxena(a)broadcom.com> Signed-off-by: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/megaraid/megaraid_sas_fp.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) --- a/drivers/scsi/megaraid/megaraid_sas_fp.c +++ b/drivers/scsi/megaraid/megaraid_sas_fp.c @@ -168,7 +168,7 @@ static struct MR_LD_SPAN *MR_LdSpanPtrGe /* * This function will Populate Driver Map using firmware raid map */ -void MR_PopulateDrvRaidMap(struct megasas_instance *instance) +static int MR_PopulateDrvRaidMap(struct megasas_instance *instance) { struct fusion_context *fusion = instance->ctrl_context; struct MR_FW_RAID_MAP_ALL *fw_map_old = NULL; @@ -259,7 +259,7 @@ void MR_PopulateDrvRaidMap(struct megasa ld_count = (u16)le16_to_cpu(fw_map_ext->ldCount); if (ld_count > MAX_LOGICAL_DRIVES_EXT) { dev_dbg(&instance->pdev->dev, "megaraid_sas: LD count exposed in RAID map in not valid\n"); - return; + return 1; } pDrvRaidMap->ldCount = (__le16)cpu_to_le16(ld_count); @@ -285,6 +285,12 @@ void MR_PopulateDrvRaidMap(struct megasa fusion->ld_map[(instance->map_id & 1)]; pFwRaidMap = &fw_map_old->raidMap; ld_count = (u16)le32_to_cpu(pFwRaidMap->ldCount); + if (ld_count > MAX_LOGICAL_DRIVES) { + dev_dbg(&instance->pdev->dev, + "LD count exposed in RAID map in not valid\n"); + return 1; + } + pDrvRaidMap->totalSize = pFwRaidMap->totalSize; pDrvRaidMap->ldCount = (__le16)cpu_to_le16(ld_count); pDrvRaidMap->fpPdIoTimeoutSec = pFwRaidMap->fpPdIoTimeoutSec; @@ -300,6 +306,8 @@ void MR_PopulateDrvRaidMap(struct megasa sizeof(struct MR_DEV_HANDLE_INFO) * MAX_RAIDMAP_PHYSICAL_DEVICES); } + + return 0; } /* @@ -317,8 +325,8 @@ u8 MR_ValidateMapInfo(struct megasas_ins u16 ld; u32 expected_size; - - MR_PopulateDrvRaidMap(instance); + if (MR_PopulateDrvRaidMap(instance)) + return 0; fusion = instance->ctrl_context; drv_map = fusion->ld_drv_map[(instance->map_id & 1)]; Patches currently in stable-queue which might be from shivasharan.srikanteshwara(a)broadcom.com are queue-4.14/scsi-megaraid_sas-error-handling-for-invalid-ldcount-provided-by-firmware-in-raid-map.patch queue-4.14/scsi-megaraid_sas-unload-flag-should-be-set-after-scsi_remove_host-is-called.patch

7 years, 2 months

1
0
0 0

Patch "scsi: libsas: initialize sas_phy status according to response of DISCOVER" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: libsas: initialize sas_phy status according to response of DISCOVER to the 4.14-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: scsi-libsas-initialize-sas_phy-status-according-to-response-of-discover.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: chenxiang <chenxiang66(a)hisilicon.com> Date: Thu, 4 Jan 2018 21:04:33 +0800 Subject: scsi: libsas: initialize sas_phy status according to response of DISCOVER From: chenxiang <chenxiang66(a)hisilicon.com> [ Upstream commit affc67788fe5dfffad5cda3d461db5cf2b2ff2b0 ] The status of SAS PHY is in sas_phy->enabled. There is an issue that the status of a remote SAS PHY may be initialized incorrectly: if disable remote SAS PHY through sysfs interface (such as echo 0 > /sys/class/sas_phy/phy-1:0:0/enable), then reboot the system, and we will find the status of remote SAS PHY which is disabled before is 1 (cat /sys/class/sas_phy/phy-1:0:0/enable). But actually the status of remote SAS PHY is disabled and the device attached is not found. In SAS protocol, NEGOTIATED LOGICAL LINK RATE field of DISCOVER response is 0x1 when remote SAS PHY is disabled. So initialize sas_phy->enabled according to the value of NEGOTIATED LOGICAL LINK RATE field. Signed-off-by: chenxiang <chenxiang66(a)hisilicon.com> Reviewed-by: John Garry <john.garry(a)huawei.com> Signed-off-by: Jason Yan <yanaijie(a)huawei.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/libsas/sas_expander.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/scsi/libsas/sas_expander.c +++ b/drivers/scsi/libsas/sas_expander.c @@ -293,6 +293,7 @@ static void sas_set_ex_phy(struct domain phy->phy->minimum_linkrate = dr->pmin_linkrate; phy->phy->maximum_linkrate = dr->pmax_linkrate; phy->phy->negotiated_linkrate = phy->linkrate; + phy->phy->enabled = (phy->linkrate != SAS_PHY_DISABLED); skip: if (new_phy) Patches currently in stable-queue which might be from chenxiang66(a)hisilicon.com are queue-4.14/scsi-libsas-initialize-sas_phy-status-according-to-response-of-discover.patch queue-4.14/scsi-libsas-fix-error-when-getting-phy-events.patch queue-4.14/scsi-libsas-fix-memory-leak-in-sas_smp_get_phy_events.patch

7 years, 2 months

1
0
0 0

Patch "scsi: libsas: fix memory leak in sas_smp_get_phy_events()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: libsas: fix memory leak in sas_smp_get_phy_events() to the 4.14-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: scsi-libsas-fix-memory-leak-in-sas_smp_get_phy_events.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Jason Yan <yanaijie(a)huawei.com> Date: Thu, 4 Jan 2018 21:04:31 +0800 Subject: scsi: libsas: fix memory leak in sas_smp_get_phy_events() From: Jason Yan <yanaijie(a)huawei.com> [ Upstream commit 4a491b1ab11ca0556d2fda1ff1301e862a2d44c4 ] We've got a memory leak with the following producer: while true; do cat /sys/class/sas_phy/phy-1:0:12/invalid_dword_count >/dev/null; done The buffer req is allocated and not freed after we return. Fix it. Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver") Signed-off-by: Jason Yan <yanaijie(a)huawei.com> CC: John Garry <john.garry(a)huawei.com> CC: chenqilin <chenqilin2(a)huawei.com> CC: chenxiang <chenxiang66(a)hisilicon.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/libsas/sas_expander.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/scsi/libsas/sas_expander.c +++ b/drivers/scsi/libsas/sas_expander.c @@ -695,6 +695,7 @@ int sas_smp_get_phy_events(struct sas_ph phy->phy_reset_problem_count = scsi_to_u32(&resp[24]); out: + kfree(req); kfree(resp); return res; Patches currently in stable-queue which might be from yanaijie(a)huawei.com are queue-4.14/scsi-libsas-initialize-sas_phy-status-according-to-response-of-discover.patch queue-4.14/scsi-libsas-fix-error-when-getting-phy-events.patch queue-4.14/scsi-libsas-fix-memory-leak-in-sas_smp_get_phy_events.patch

7 years, 2 months

1
0
0 0

Patch "scsi: libiscsi: Allow sd_shutdown on bad transport" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: libiscsi: Allow sd_shutdown on bad transport to the 4.14-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: scsi-libiscsi-allow-sd_shutdown-on-bad-transport.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Rafael David Tinoco <rafael.tinoco(a)canonical.com> Date: Thu, 7 Dec 2017 19:59:13 -0200 Subject: scsi: libiscsi: Allow sd_shutdown on bad transport From: Rafael David Tinoco <rafael.tinoco(a)canonical.com> [ Upstream commit d754941225a7dbc61f6dd2173fa9498049f9a7ee ] If, for any reason, userland shuts down iscsi transport interfaces before proper logouts - like when logging in to LUNs manually, without logging out on server shutdown, or when automated scripts can't umount/logout from logged LUNs - kernel will hang forever on its sd_sync_cache() logic, after issuing the SYNCHRONIZE_CACHE cmd to all still existent paths. PID: 1 TASK: ffff8801a69b8000 CPU: 1 COMMAND: "systemd-shutdow" #0 [ffff8801a69c3a30] __schedule at ffffffff8183e9ee #1 [ffff8801a69c3a80] schedule at ffffffff8183f0d5 #2 [ffff8801a69c3a98] schedule_timeout at ffffffff81842199 #3 [ffff8801a69c3b40] io_schedule_timeout at ffffffff8183e604 #4 [ffff8801a69c3b70] wait_for_completion_io_timeout at ffffffff8183fc6c #5 [ffff8801a69c3bd0] blk_execute_rq at ffffffff813cfe10 #6 [ffff8801a69c3c88] scsi_execute at ffffffff815c3fc7 #7 [ffff8801a69c3cc8] scsi_execute_req_flags at ffffffff815c60fe #8 [ffff8801a69c3d30] sd_sync_cache at ffffffff815d37d7 #9 [ffff8801a69c3da8] sd_shutdown at ffffffff815d3c3c This happens because iscsi_eh_cmd_timed_out(), the transport layer timeout helper, would tell the queue timeout function (scsi_times_out) to reset the request timer over and over, until the session state is back to logged in state. Unfortunately, during server shutdown, this might never happen again. Other option would be "not to handle" the issue in the transport layer. That would trigger the error handler logic, which would also need the session state to be logged in again. Best option, for such case, is to tell upper layers that the command was handled during the transport layer error handler helper, marking it as DID_NO_CONNECT, which will allow completion and inform about the problem. After the session was marked as ISCSI_STATE_FAILED, due to the first timeout during the server shutdown phase, all subsequent cmds will fail to be queued, allowing upper logic to fail faster. Signed-off-by: Rafael David Tinoco <rafael.tinoco(a)canonical.com> Reviewed-by: Lee Duncan <lduncan(a)suse.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/libiscsi.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) --- a/drivers/scsi/libiscsi.c +++ b/drivers/scsi/libiscsi.c @@ -1696,6 +1696,15 @@ int iscsi_queuecommand(struct Scsi_Host */ switch (session->state) { case ISCSI_STATE_FAILED: + /* + * cmds should fail during shutdown, if the session + * state is bad, allowing completion to happen + */ + if (unlikely(system_state != SYSTEM_RUNNING)) { + reason = FAILURE_SESSION_FAILED; + sc->result = DID_NO_CONNECT << 16; + break; + } case ISCSI_STATE_IN_RECOVERY: reason = FAILURE_SESSION_IN_RECOVERY; sc->result = DID_IMM_RETRY << 16; @@ -1981,6 +1990,19 @@ enum blk_eh_timer_return iscsi_eh_cmd_ti if (session->state != ISCSI_STATE_LOGGED_IN) { /* + * During shutdown, if session is prematurely disconnected, + * recovery won't happen and there will be hung cmds. Not + * handling cmds would trigger EH, also bad in this case. + * Instead, handle cmd, allow completion to happen and let + * upper layer to deal with the result. + */ + if (unlikely(system_state != SYSTEM_RUNNING)) { + sc->result = DID_NO_CONNECT << 16; + ISCSI_DBG_EH(session, "sc on shutdown, handled\n"); + rc = BLK_EH_HANDLED; + goto done; + } + /* * We are probably in the middle of iscsi recovery so let * that complete and handle the error. */ @@ -2084,7 +2106,7 @@ done: task->last_timeout = jiffies; spin_unlock(&session->frwd_lock); ISCSI_DBG_EH(session, "return %s\n", rc == BLK_EH_RESET_TIMER ? - "timer reset" : "nh"); + "timer reset" : "shutdown or nh"); return rc; } EXPORT_SYMBOL_GPL(iscsi_eh_cmd_timed_out); Patches currently in stable-queue which might be from rafael.tinoco(a)canonical.com are queue-4.14/scsi-libiscsi-allow-sd_shutdown-on-bad-transport.patch

7 years, 2 months

1
0
0 0

Patch "scsi: libsas: fix error when getting phy events" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: libsas: fix error when getting phy events to the 4.14-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: scsi-libsas-fix-error-when-getting-phy-events.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Jason Yan <yanaijie(a)huawei.com> Date: Thu, 4 Jan 2018 21:04:32 +0800 Subject: scsi: libsas: fix error when getting phy events From: Jason Yan <yanaijie(a)huawei.com> [ Upstream commit 2b23d9509fd7174b362482cf5f3b5f9a2265bc33 ] The intend purpose here was to goto out if smp_execute_task() returned error. Obviously something got screwed up. We will never get these link error statistics below: ~:/sys/class/sas_phy/phy-1:0:12 # cat invalid_dword_count 0 ~:/sys/class/sas_phy/phy-1:0:12 # cat running_disparity_error_count 0 ~:/sys/class/sas_phy/phy-1:0:12 # cat loss_of_dword_sync_count 0 ~:/sys/class/sas_phy/phy-1:0:12 # cat phy_reset_problem_count 0 Obviously we should goto error handler if smp_execute_task() returns non-zero. Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver") Signed-off-by: Jason Yan <yanaijie(a)huawei.com> CC: John Garry <john.garry(a)huawei.com> CC: chenqilin <chenqilin2(a)huawei.com> CC: chenxiang <chenxiang66(a)hisilicon.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/libsas/sas_expander.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/scsi/libsas/sas_expander.c +++ b/drivers/scsi/libsas/sas_expander.c @@ -686,7 +686,7 @@ int sas_smp_get_phy_events(struct sas_ph res = smp_execute_task(dev, req, RPEL_REQ_SIZE, resp, RPEL_RESP_SIZE); - if (!res) + if (res) goto out; phy->invalid_dword_count = scsi_to_u32(&resp[12]); Patches currently in stable-queue which might be from yanaijie(a)huawei.com are queue-4.14/scsi-libsas-initialize-sas_phy-status-according-to-response-of-discover.patch queue-4.14/scsi-libsas-fix-error-when-getting-phy-events.patch queue-4.14/scsi-libsas-fix-memory-leak-in-sas_smp_get_phy_events.patch

7 years, 2 months

1
0
0 0

Patch "rt2x00: do not pause queue unconditionally on error path" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rt2x00: do not pause queue unconditionally on error path to the 4.14-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: rt2x00-do-not-pause-queue-unconditionally-on-error-path.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Stanislaw Gruszka <sgruszka(a)redhat.com> Date: Tue, 19 Dec 2017 12:33:56 +0100 Subject: rt2x00: do not pause queue unconditionally on error path From: Stanislaw Gruszka <sgruszka(a)redhat.com> [ Upstream commit 6dd80efd75ce7c2dbd9f117cf585ee2b33a42ee1 ] Pausing queue without checking threshold is racy with txdone path. Moreover we do not need pause queue on any error, but only if queue is full - in case when we send RTS frame ( other cases of almost full queue are already handled in rt2x00queue_write_tx_frame() ). Patch fixes of theoretically possible problem of pausing empty queue. Signed-off-by: Stanislaw Gruszka <sgruszka(a)redhat.com> Tested-by: Enrico Mioso <mrkiko.rs(a)gmail.com> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ralink/rt2x00/rt2x00mac.c | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) --- a/drivers/net/wireless/ralink/rt2x00/rt2x00mac.c +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00mac.c @@ -142,15 +142,25 @@ void rt2x00mac_tx(struct ieee80211_hw *h if (!rt2x00dev->ops->hw->set_rts_threshold && (tx_info->control.rates[0].flags & (IEEE80211_TX_RC_USE_RTS_CTS | IEEE80211_TX_RC_USE_CTS_PROTECT))) { - if (rt2x00queue_available(queue) <= 1) - goto exit_fail; + if (rt2x00queue_available(queue) <= 1) { + /* + * Recheck for full queue under lock to avoid race + * conditions with rt2x00lib_txdone(). + */ + spin_lock(&queue->tx_lock); + if (rt2x00queue_threshold(queue)) + rt2x00queue_pause_queue(queue); + spin_unlock(&queue->tx_lock); + + goto exit_free_skb; + } if (rt2x00mac_tx_rts_cts(rt2x00dev, queue, skb)) - goto exit_fail; + goto exit_free_skb; } if (unlikely(rt2x00queue_write_tx_frame(queue, skb, control->sta, false))) - goto exit_fail; + goto exit_free_skb; /* * Pausing queue has to be serialized with rt2x00lib_txdone(). Note @@ -164,10 +174,6 @@ void rt2x00mac_tx(struct ieee80211_hw *h return; - exit_fail: - spin_lock(&queue->tx_lock); - rt2x00queue_pause_queue(queue); - spin_unlock(&queue->tx_lock); exit_free_skb: ieee80211_free_txskb(hw, skb); } Patches currently in stable-queue which might be from sgruszka(a)redhat.com are queue-4.14/rt2x00-do-not-pause-queue-unconditionally-on-error-path.patch

7 years, 2 months

1
0
0 0

Patch "rds; Reset rs->rs_bound_addr in rds_add_bound() failure path" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rds; Reset rs->rs_bound_addr in rds_add_bound() failure path to the 4.14-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: rds-reset-rs-rs_bound_addr-in-rds_add_bound-failure-path.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com> Date: Fri, 22 Dec 2017 09:38:59 -0800 Subject: rds; Reset rs->rs_bound_addr in rds_add_bound() failure path From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com> [ Upstream commit 7ae0c649c47f1c5d2db8cee6dd75855970af1669 ] If the rds_sock is not added to the bind_hash_table, we must reset rs_bound_addr so that rds_remove_bound will not trip on this rds_sock. rds_add_bound() does a rds_sock_put() in this failure path, so failing to reset rs_bound_addr will result in a socket refcount bug, and will trigger a WARN_ON with the stack shown below when the application subsequently tries to close the PF_RDS socket. WARNING: CPU: 20 PID: 19499 at net/rds/af_rds.c:496 \ rds_sock_destruct+0x15/0x30 [rds] : __sk_destruct+0x21/0x190 rds_remove_bound.part.13+0xb6/0x140 [rds] rds_release+0x71/0x120 [rds] sock_release+0x1a/0x70 sock_close+0xe/0x20 __fput+0xd5/0x210 task_work_run+0x82/0xa0 do_exit+0x2ce/0xb30 ? syscall_trace_enter+0x1cc/0x2b0 do_group_exit+0x39/0xa0 SyS_exit_group+0x10/0x10 do_syscall_64+0x61/0x1a0 Signed-off-by: Sowmini Varadhan <sowmini.varadhan(a)oracle.com> Acked-by: Santosh Shilimkar <santosh.shilimkar(a)oracle.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/rds/bind.c | 1 + 1 file changed, 1 insertion(+) --- a/net/rds/bind.c +++ b/net/rds/bind.c @@ -114,6 +114,7 @@ static int rds_add_bound(struct rds_sock rs, &addr, (int)ntohs(*port)); break; } else { + rs->rs_bound_addr = 0; rds_sock_put(rs); ret = -ENOMEM; break; Patches currently in stable-queue which might be from sowmini.varadhan(a)oracle.com are queue-4.14/selftests-net-fix-bugs-in-address-and-port-initialization.patch queue-4.14/rds-reset-rs-rs_bound_addr-in-rds_add_bound-failure-path.patch

7 years, 2 months

1
0
0 0

Patch "RDMA/cma: Mark end of CMA ID messages" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDMA/cma: Mark end of CMA ID messages to the 4.14-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-cma-mark-end-of-cma-id-messages.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Leon Romanovsky <leonro(a)mellanox.com> Date: Mon, 1 Jan 2018 13:07:17 +0200 Subject: RDMA/cma: Mark end of CMA ID messages From: Leon Romanovsky <leonro(a)mellanox.com> [ Upstream commit e48e5e198fb6ec77c91047a694022f0fefa45292 ] The commit 1a1c116f3dcf ("RDMA/netlink: Simplify the put_msg and put_attr") removes nlmsg_len calculation in ibnl_put_attr causing netlink messages and caused to miss source and destination addresses. Fixes: 1a1c116f3dcf ("RDMA/netlink: Simplify the put_msg and put_attr") Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/core/cma.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/infiniband/core/cma.c +++ b/drivers/infiniband/core/cma.c @@ -4453,6 +4453,7 @@ static int cma_get_id_stats(struct sk_bu id_stats->qp_type = id->qp_type; i_id++; + nlmsg_end(skb, nlh); } cb->args[1] = 0; Patches currently in stable-queue which might be from leonro(a)mellanox.com are queue-4.14/rdma-cma-mark-end-of-cma-id-messages.patch

7 years, 2 months

1
0
0 0

Patch "powernv-cpufreq: Add helper to extract pstate from PMSR" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powernv-cpufreq: Add helper to extract pstate from PMSR to the 4.14-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: powernv-cpufreq-add-helper-to-extract-pstate-from-pmsr.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: "Gautham R. Shenoy" <ego(a)linux.vnet.ibm.com> Date: Wed, 13 Dec 2017 12:27:39 +0530 Subject: powernv-cpufreq: Add helper to extract pstate from PMSR From: "Gautham R. Shenoy" <ego(a)linux.vnet.ibm.com> [ Upstream commit ee1f4a7dafa997816ff3de96155c6f3edc21c1e6 ] On POWERNV platform, the fields for pstates in the Power Management Status Register (PMSR) and the Power Management Control Register (PMCR) are 8-bits wide. On POWER8 the pstates are negatively numbered while on POWER9 they are positively numbered. The device-tree exports pstates as 32-bit entries. The device-tree implementation sign-extends the 8-bit pstate values to obtain the corresponding 32-bit entry. Eg: On POWER8, a pstate value 0x82 [-126] is represented in the device-tree as 0xfffffff82 while on POWER9, the same value 0x82 [130] is represented in the device-tree as 0x00000082. The powernv-cpufreq driver implementation represents pstates using the integer type. In multiple places in the driver, the code interprets the pstates extracted from the PMSR as a signed byte and assigns it to a integer variable to get the sign-extention. On POWER9 platforms which have greater than 128 pstates, this results in the driver performing incorrect sign-extention, and thereby treating a legitimate pstate (say 130) as an invalid pstates (since it is interpreted as -126). This patch fixes the issue by implementing a helper function to extract Pstates from PMSR register, and correctly sign-extend it to be consistent with the values provided by the device-tree. Signed-off-by: Gautham R. Shenoy <ego(a)linux.vnet.ibm.com> Acked-by: Balbir Singh <bsingharora(a)gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/cpufreq/powernv-cpufreq.c | 37 +++++++++++++++++++++++-------------- 1 file changed, 23 insertions(+), 14 deletions(-) --- a/drivers/cpufreq/powernv-cpufreq.c +++ b/drivers/cpufreq/powernv-cpufreq.c @@ -41,11 +41,9 @@ #define POWERNV_MAX_PSTATES 256 #define PMSR_PSAFE_ENABLE (1UL << 30) #define PMSR_SPR_EM_DISABLE (1UL << 31) -#define PMSR_MAX(x) ((x >> 32) & 0xFF) +#define MAX_PSTATE_SHIFT 32 #define LPSTATE_SHIFT 48 #define GPSTATE_SHIFT 56 -#define GET_LPSTATE(x) (((x) >> LPSTATE_SHIFT) & 0xFF) -#define GET_GPSTATE(x) (((x) >> GPSTATE_SHIFT) & 0xFF) #define MAX_RAMP_DOWN_TIME 5120 /* @@ -93,6 +91,7 @@ struct global_pstate_info { }; static struct cpufreq_frequency_table powernv_freqs[POWERNV_MAX_PSTATES+1]; +u32 pstate_sign_prefix; static bool rebooting, throttled, occ_reset; static const char * const throttle_reason[] = { @@ -147,6 +146,20 @@ static struct powernv_pstate_info { bool wof_enabled; } powernv_pstate_info; +static inline int extract_pstate(u64 pmsr_val, unsigned int shift) +{ + int ret = ((pmsr_val >> shift) & 0xFF); + + if (!ret) + return ret; + + return (pstate_sign_prefix | ret); +} + +#define extract_local_pstate(x) extract_pstate(x, LPSTATE_SHIFT) +#define extract_global_pstate(x) extract_pstate(x, GPSTATE_SHIFT) +#define extract_max_pstate(x) extract_pstate(x, MAX_PSTATE_SHIFT) + /* Use following macros for conversions between pstate_id and index */ static inline int idx_to_pstate(unsigned int i) { @@ -277,6 +290,9 @@ next: powernv_pstate_info.nr_pstates = nr_pstates; pr_debug("NR PStates %d\n", nr_pstates); + + pstate_sign_prefix = pstate_min & ~0xFF; + for (i = 0; i < nr_pstates; i++) { u32 id = be32_to_cpu(pstate_ids[i]); u32 freq = be32_to_cpu(pstate_freqs[i]); @@ -437,17 +453,10 @@ struct powernv_smp_call_data { static void powernv_read_cpu_freq(void *arg) { unsigned long pmspr_val; - s8 local_pstate_id; struct powernv_smp_call_data *freq_data = arg; pmspr_val = get_pmspr(SPRN_PMSR); - - /* - * The local pstate id corresponds bits 48..55 in the PMSR. - * Note: Watch out for the sign! - */ - local_pstate_id = (pmspr_val >> 48) & 0xFF; - freq_data->pstate_id = local_pstate_id; + freq_data->pstate_id = extract_local_pstate(pmspr_val); freq_data->freq = pstate_id_to_freq(freq_data->pstate_id); pr_debug("cpu %d pmsr %016lX pstate_id %d frequency %d kHz\n", @@ -521,7 +530,7 @@ static void powernv_cpufreq_throttle_che chip = this_cpu_read(chip_info); /* Check for Pmax Capping */ - pmsr_pmax = (s8)PMSR_MAX(pmsr); + pmsr_pmax = extract_max_pstate(pmsr); pmsr_pmax_idx = pstate_to_idx(pmsr_pmax); if (pmsr_pmax_idx != powernv_pstate_info.max) { if (chip->throttled) @@ -644,8 +653,8 @@ void gpstate_timer_handler(unsigned long * value. Hence, read from PMCR to get correct data. */ val = get_pmspr(SPRN_PMCR); - freq_data.gpstate_id = (s8)GET_GPSTATE(val); - freq_data.pstate_id = (s8)GET_LPSTATE(val); + freq_data.gpstate_id = extract_global_pstate(val); + freq_data.pstate_id = extract_local_pstate(val); if (freq_data.gpstate_id == freq_data.pstate_id) { reset_gpstates(policy); spin_unlock(&gpstates->gpstate_lock); Patches currently in stable-queue which might be from ego(a)linux.vnet.ibm.com are queue-4.14/powernv-cpufreq-add-helper-to-extract-pstate-from-pmsr.patch

7 years, 2 months

1
0
0 0

Patch "RDMA/cma: Fix rdma_cm path querying for RoCE" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDMA/cma: Fix rdma_cm path querying for RoCE to the 4.14-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-cma-fix-rdma_cm-path-querying-for-roce.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Parav Pandit <parav(a)mellanox.com> Date: Mon, 8 Jan 2018 17:04:48 +0200 Subject: RDMA/cma: Fix rdma_cm path querying for RoCE From: Parav Pandit <parav(a)mellanox.com> [ Upstream commit 89838118a515847d3e5c904d2e022779a7173bec ] The 'if' logic in ucma_query_path was broken with OPA was introduced and started to treat RoCE paths as as OPA paths. Invert the logic of the 'if' so only OPA paths are treated as OPA paths. Otherwise the path records returned to rdma_cma users are mangled when in RoCE mode. Fixes: 57520751445b ("IB/SA: Add OPA path record type") Signed-off-by: Parav Pandit <parav(a)mellanox.com> Reviewed-by: Mark Bloch <markb(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/core/ucma.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/drivers/infiniband/core/ucma.c +++ b/drivers/infiniband/core/ucma.c @@ -914,13 +914,14 @@ static ssize_t ucma_query_path(struct uc resp->path_data[i].flags = IB_PATH_GMP | IB_PATH_PRIMARY | IB_PATH_BIDIRECTIONAL; - if (rec->rec_type == SA_PATH_REC_TYPE_IB) { - ib_sa_pack_path(rec, &resp->path_data[i].path_rec); - } else { + if (rec->rec_type == SA_PATH_REC_TYPE_OPA) { struct sa_path_rec ib; sa_convert_path_opa_to_ib(&ib, rec); ib_sa_pack_path(&ib, &resp->path_data[i].path_rec); + + } else { + ib_sa_pack_path(rec, &resp->path_data[i].path_rec); } } Patches currently in stable-queue which might be from parav(a)mellanox.com are queue-4.14/net-mlx5-fix-race-for-multiple-roce-enable.patch queue-4.14/rdma-cma-fix-rdma_cm-path-querying-for-roce.patch

7 years, 2 months

1
0
0 0

Patch "power: supply: axp288_charger: Properly stop work on probe-error / remove" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled power: supply: axp288_charger: Properly stop work on probe-error / remove to the 4.14-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: power-supply-axp288_charger-properly-stop-work-on-probe-error-remove.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Hans de Goede <hdegoede(a)redhat.com> Date: Tue, 26 Dec 2017 13:59:09 +0100 Subject: power: supply: axp288_charger: Properly stop work on probe-error / remove From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit 165c2357744e41391902a2a72dd170beb60c28d5 ] Properly stop any work we may have queued on probe-errors / remove. Rather then adding a remove driver callback for this, and goto style error handling to probe, use a devm_action for this. The devm_action gets registered before we register any of the extcon notifiers which may queue the work, devm does cleanup in reverse order, so this ensures that the notifiers are removed before we cancel the work. Reviewed-by: Chen-Yu Tsai <wens(a)csie.org> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel(a)collabora.co.uk> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/power/supply/axp288_charger.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) --- a/drivers/power/supply/axp288_charger.c +++ b/drivers/power/supply/axp288_charger.c @@ -785,6 +785,14 @@ static int charger_init_hw_regs(struct a return 0; } +static void axp288_charger_cancel_work(void *data) +{ + struct axp288_chrg_info *info = data; + + cancel_work_sync(&info->otg.work); + cancel_work_sync(&info->cable.work); +} + static int axp288_charger_probe(struct platform_device *pdev) { int ret, i, pirq; @@ -836,6 +844,11 @@ static int axp288_charger_probe(struct p return ret; } + /* Cancel our work on cleanup, register this before the notifiers */ + ret = devm_add_action(dev, axp288_charger_cancel_work, info); + if (ret) + return ret; + /* Register for extcon notification */ INIT_WORK(&info->cable.work, axp288_charger_extcon_evt_worker); info->cable.nb[0].notifier_call = axp288_charger_handle_cable0_evt; Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.14/acpi-video-default-lcd_only-to-true-on-win8-ready-and-newer-machines.patch queue-4.14/input-goodix-disable-irqs-while-suspended.patch queue-4.14/asoc-intel-cht_bsw_rt5645-analog-mic-support.patch queue-4.14/power-supply-axp288_charger-properly-stop-work-on-probe-error-remove.patch queue-4.14/pinctrl-baytrail-enable-glitch-filter-for-gpios-used-as-interrupts.patch

7 years, 2 months

1
0
0 0

Patch "PM / devfreq: Fix potential NULL pointer dereference in governor_store" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled PM / devfreq: Fix potential NULL pointer dereference in governor_store to the 4.14-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: pm-devfreq-fix-potential-null-pointer-dereference-in-governor_store.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com> Date: Wed, 6 Dec 2017 14:20:15 -0600 Subject: PM / devfreq: Fix potential NULL pointer dereference in governor_store From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com> [ Upstream commit 63f1e05f7fe9ca509c60154d6a833abf96eecdc9 ] df->governor is being dereferenced before it is null checked, hence there is a potential null pointer dereference. Notice that df->governor is being null checked at line 1004: if (df->governor) {, which implies it might be null. Fix this by null checking df->governor before dereferencing it. Addresses-Coverity-ID: 1401988 ("Dereference before null check") Fixes: bcf23c79c4e4 ("PM / devfreq: Fix available_governor sysfs") Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com> Reviewed-by: Chanwoo Choi <cw00.choi(a)samsung.com> Signed-off-by: MyungJoo Ham <myungjoo.ham(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/devfreq/devfreq.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/devfreq/devfreq.c +++ b/drivers/devfreq/devfreq.c @@ -935,7 +935,8 @@ static ssize_t governor_store(struct dev if (df->governor == governor) { ret = 0; goto out; - } else if (df->governor->immutable || governor->immutable) { + } else if ((df->governor && df->governor->immutable) || + governor->immutable) { ret = -EINVAL; goto out; } Patches currently in stable-queue which might be from garsilva(a)embeddedor.com are queue-4.14/pm-devfreq-fix-potential-null-pointer-dereference-in-governor_store.patch

7 years, 2 months

1
0
0 0

Patch "pinctrl: baytrail: Enable glitch filter for GPIOs used as interrupts" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled pinctrl: baytrail: Enable glitch filter for GPIOs used as interrupts to the 4.14-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: pinctrl-baytrail-enable-glitch-filter-for-gpios-used-as-interrupts.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Hans de Goede <hdegoede(a)redhat.com> Date: Mon, 1 Jan 2018 13:23:57 +0100 Subject: pinctrl: baytrail: Enable glitch filter for GPIOs used as interrupts From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit 9291c65b01d1c67ebd56644cb19317ad665c44b3 ] On some systems, some PCB traces attached to GpioInts are routed in such a way that they pick up enough interference to constantly (many times per second) trigger. Enabling glitch-filtering fixes this. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Acked-by: Mika Westerberg <mika.westerberg(a)linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pinctrl/intel/pinctrl-baytrail.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/pinctrl/intel/pinctrl-baytrail.c +++ b/drivers/pinctrl/intel/pinctrl-baytrail.c @@ -46,6 +46,9 @@ #define BYT_TRIG_POS BIT(25) #define BYT_TRIG_LVL BIT(24) #define BYT_DEBOUNCE_EN BIT(20) +#define BYT_GLITCH_FILTER_EN BIT(19) +#define BYT_GLITCH_F_SLOW_CLK BIT(17) +#define BYT_GLITCH_F_FAST_CLK BIT(16) #define BYT_PULL_STR_SHIFT 9 #define BYT_PULL_STR_MASK (3 << BYT_PULL_STR_SHIFT) #define BYT_PULL_STR_2K (0 << BYT_PULL_STR_SHIFT) @@ -1579,6 +1582,9 @@ static int byt_irq_type(struct irq_data */ value &= ~(BYT_DIRECT_IRQ_EN | BYT_TRIG_POS | BYT_TRIG_NEG | BYT_TRIG_LVL); + /* Enable glitch filtering */ + value |= BYT_GLITCH_FILTER_EN | BYT_GLITCH_F_SLOW_CLK | + BYT_GLITCH_F_FAST_CLK; writel(value, reg); Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.14/acpi-video-default-lcd_only-to-true-on-win8-ready-and-newer-machines.patch queue-4.14/input-goodix-disable-irqs-while-suspended.patch queue-4.14/asoc-intel-cht_bsw_rt5645-analog-mic-support.patch queue-4.14/power-supply-axp288_charger-properly-stop-work-on-probe-error-remove.patch queue-4.14/pinctrl-baytrail-enable-glitch-filter-for-gpios-used-as-interrupts.patch

7 years, 2 months

1
0
0 0

Patch "perf tools: Fix copyfile_offset update of output offset" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf tools: Fix copyfile_offset update of output offset to the 4.14-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: perf-tools-fix-copyfile_offset-update-of-output-offset.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Jiri Olsa <jolsa(a)kernel.org> Date: Tue, 9 Jan 2018 14:39:23 +0100 Subject: perf tools: Fix copyfile_offset update of output offset From: Jiri Olsa <jolsa(a)kernel.org> [ Upstream commit fa1195ccc0af2d121abe0fe266a1caee8c265eea ] We need to increase output offset in each iteration, not decrease it as we currently do. I guess we were lucky to finish in most cases in first iteration, so the bug never showed. However it shows a lot when working with big (~4GB) size data. Signed-off-by: Jiri Olsa <jolsa(a)kernel.org> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Andi Kleen <ak(a)linux.intel.com> Cc: David Ahern <dsahern(a)gmail.com> Cc: Namhyung Kim <namhyung(a)kernel.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Fixes: 9c9f5a2f1944 ("perf tools: Introduce copyfile_offset() function") Link: http://lkml.kernel.org/r/20180109133923.25406-1-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/util/util.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/perf/util/util.c +++ b/tools/perf/util/util.c @@ -196,7 +196,7 @@ int copyfile_offset(int ifd, loff_t off_ size -= ret; off_in += ret; - off_out -= ret; + off_out += ret; } munmap(ptr, off_in + size); Patches currently in stable-queue which might be from jolsa(a)kernel.org are queue-4.14/perf-tools-fix-copyfile_offset-update-of-output-offset.patch queue-4.14/perf-report-fix-a-no-annotate-browser-displayed-issue.patch

7 years, 2 months

1
0
0 0

Patch "perf report: Fix a no annotate browser displayed issue" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf report: Fix a no annotate browser displayed issue to the 4.14-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: perf-report-fix-a-no-annotate-browser-displayed-issue.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Jin Yao <yao.jin(a)linux.intel.com> Date: Tue, 26 Dec 2017 18:42:43 +0800 Subject: perf report: Fix a no annotate browser displayed issue From: Jin Yao <yao.jin(a)linux.intel.com> [ Upstream commit 40c39e3046411f84bab82f66783ff3593e2bcd9b ] When enabling '-b' option in perf record, for example, perf record -b ... perf report and then browsing the annotate browser from perf report (press 'A'), it would fail (annotate browser can't be displayed). It's because the '.add_entry_cb' op of struct report is overwritten by hist_iter__branch_callback() in builtin-report.c. But this function doesn't do something like mapping symbols and sources. So next, do_annotate() will return directly. notes = symbol__annotation(act->ms.sym); if (!notes->src) return 0; This patch adds the lost code to hist_iter__branch_callback (refer to hist_iter__report_callback). v2: Fix a crash bug when perform 'perf report --stdio'. The reason is that we init the symbol annotation only in browser mode, it doesn't allocate/init resources for stdio mode. So now in hist_iter__branch_callback(), it will return directly if it's not in browser mode. Signed-off-by: Jin Yao <yao.jin(a)linux.intel.com> Tested-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Andi Kleen <ak(a)linux.intel.com> Cc: Jiri Olsa <jolsa(a)kernel.org> Cc: Kan Liang <kan.liang(a)intel.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Link: http://lkml.kernel.org/r/1514284963-18587-1-git-send-email-yao.jin@linux.in… Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/builtin-report.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) --- a/tools/perf/builtin-report.c +++ b/tools/perf/builtin-report.c @@ -162,12 +162,28 @@ static int hist_iter__branch_callback(st struct hist_entry *he = iter->he; struct report *rep = arg; struct branch_info *bi; + struct perf_sample *sample = iter->sample; + struct perf_evsel *evsel = iter->evsel; + int err; + + if (!ui__has_annotation()) + return 0; + + hist__account_cycles(sample->branch_stack, al, sample, + rep->nonany_branch_mode); bi = he->branch_info; + err = addr_map_symbol__inc_samples(&bi->from, sample, evsel->idx); + if (err) + goto out; + + err = addr_map_symbol__inc_samples(&bi->to, sample, evsel->idx); + branch_type_count(&rep->brtype_stat, &bi->flags, bi->from.addr, bi->to.addr); - return 0; +out: + return err; } static int process_sample_event(struct perf_tool *tool, Patches currently in stable-queue which might be from yao.jin(a)linux.intel.com are queue-4.14/perf-report-fix-a-no-annotate-browser-displayed-issue.patch

7 years, 2 months

1
0
0 0

Patch "perf probe: Find versioned symbols from map" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf probe: Find versioned symbols from map to the 4.14-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: perf-probe-find-versioned-symbols-from-map.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Masami Hiramatsu <mhiramat(a)kernel.org> Date: Sat, 9 Dec 2017 01:28:12 +0900 Subject: perf probe: Find versioned symbols from map From: Masami Hiramatsu <mhiramat(a)kernel.org> [ Upstream commit 4b3a2716dd785fabb9f6ac80c1d53cb29a88169d ] Commit d80406453ad4 ("perf symbols: Allow user probes on versioned symbols") allows user to find default versioned symbols (with "@@") in map. However, it did not enable normal versioned symbol (with "@") for perf-probe. E.g. ===== # ./perf probe -x /lib64/libc-2.25.so malloc_get_state Failed to find symbol malloc_get_state in /usr/lib64/libc-2.25.so Error: Failed to add events. ===== This solves above issue by improving perf-probe symbol search function, as below. ===== # ./perf probe -x /lib64/libc-2.25.so malloc_get_state Added new event: probe_libc:malloc_get_state (on malloc_get_state in /usr/lib64/libc-2.25.so) You can now use it in all perf tools, such as: perf record -e probe_libc:malloc_get_state -aR sleep 1 # ./perf probe -l probe_libc:malloc_get_state (on malloc_get_state(a)GLIBC_2.2.5 in /usr/lib64/libc-2.25.so) ===== Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org> Reviewed-by: Thomas Richter <tmricht(a)linux.vnet.ibm.com> Acked-by: Ravi Bangoria <ravi.bangoria(a)linux.vnet.ibm.com> Tested-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Cc: Paul Clarke <pc(a)us.ibm.com> Cc: bhargavb <bhargavaramudu(a)gmail.com> Cc: linux-rt-users(a)vger.kernel.org Link: http://lkml.kernel.org/r/151275049269.24652.1639103455496216255.stgit@devbox Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/arch/powerpc/util/sym-handling.c | 8 ++++++++ tools/perf/util/probe-event.c | 20 ++++++++++++++++++-- tools/perf/util/symbol.c | 5 +++++ tools/perf/util/symbol.h | 1 + 4 files changed, 32 insertions(+), 2 deletions(-) --- a/tools/perf/arch/powerpc/util/sym-handling.c +++ b/tools/perf/arch/powerpc/util/sym-handling.c @@ -64,6 +64,14 @@ int arch__compare_symbol_names_n(const c return strncmp(namea, nameb, n); } + +const char *arch__normalize_symbol_name(const char *name) +{ + /* Skip over initial dot */ + if (name && *name == '.') + name++; + return name; +} #endif #if defined(_CALL_ELF) && _CALL_ELF == 2 --- a/tools/perf/util/probe-event.c +++ b/tools/perf/util/probe-event.c @@ -2792,16 +2792,32 @@ static int find_probe_functions(struct m int found = 0; struct symbol *sym; struct rb_node *tmp; + const char *norm, *ver; + char *buf = NULL; if (map__load(map) < 0) return 0; map__for_each_symbol(map, sym, tmp) { - if (strglobmatch(sym->name, name)) { + norm = arch__normalize_symbol_name(sym->name); + if (!norm) + continue; + + /* We don't care about default symbol or not */ + ver = strchr(norm, '@'); + if (ver) { + buf = strndup(norm, ver - norm); + if (!buf) + return -ENOMEM; + norm = buf; + } + if (strglobmatch(norm, name)) { found++; if (syms && found < probe_conf.max_probes) syms[found - 1] = sym; } + if (buf) + zfree(&buf); } return found; @@ -2847,7 +2863,7 @@ static int find_probe_trace_events_from_ * same name but different addresses, this lists all the symbols. */ num_matched_functions = find_probe_functions(map, pp->function, syms); - if (num_matched_functions == 0) { + if (num_matched_functions <= 0) { pr_err("Failed to find symbol %s in %s\n", pp->function, pev->target ? : "kernel"); ret = -ENOENT; --- a/tools/perf/util/symbol.c +++ b/tools/perf/util/symbol.c @@ -93,6 +93,11 @@ static int prefix_underscores_count(cons return tail - str; } +const char * __weak arch__normalize_symbol_name(const char *name) +{ + return name; +} + int __weak arch__compare_symbol_names(const char *namea, const char *nameb) { return strcmp(namea, nameb); --- a/tools/perf/util/symbol.h +++ b/tools/perf/util/symbol.h @@ -347,6 +347,7 @@ bool elf__needs_adjust_symbols(GElf_Ehdr void arch__sym_update(struct symbol *s, GElf_Sym *sym); #endif +const char *arch__normalize_symbol_name(const char *name); #define SYMBOL_A 0 #define SYMBOL_B 1 Patches currently in stable-queue which might be from mhiramat(a)kernel.org are queue-4.14/perf-probe-find-versioned-symbols-from-map.patch queue-4.14/perf-probe-add-warning-message-if-there-is-unexpected-event-name.patch

7 years, 2 months

1
0
0 0

Patch "perf probe: Add warning message if there is unexpected event name" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf probe: Add warning message if there is unexpected event name to the 4.14-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: perf-probe-add-warning-message-if-there-is-unexpected-event-name.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Masami Hiramatsu <mhiramat(a)kernel.org> Date: Sat, 9 Dec 2017 01:26:46 +0900 Subject: perf probe: Add warning message if there is unexpected event name From: Masami Hiramatsu <mhiramat(a)kernel.org> [ Upstream commit 9f5c6d8777a2d962b0eeacb2a16f37da6bea545b ] This improve the error message so that user can know event-name error before writing new events to kprobe-events interface. E.g. ====== #./perf probe -x /lib64/libc-2.25.so malloc_get_state* Internal error: "malloc_get_state@GLIBC_2" is an invalid event name. Error: Failed to add events. ====== Reported-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org> Acked-by: Ravi Bangoria <ravi.bangoria(a)linux.vnet.ibm.com> Reviewed-by: Thomas Richter <tmricht(a)linux.vnet.ibm.com> Tested-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Cc: Paul Clarke <pc(a)us.ibm.com> Cc: bhargavb <bhargavaramudu(a)gmail.com> Cc: linux-rt-users(a)vger.kernel.org Link: http://lkml.kernel.org/r/151275040665.24652.5188568529237584489.stgit@devbox Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/util/probe-event.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/tools/perf/util/probe-event.c +++ b/tools/perf/util/probe-event.c @@ -2625,6 +2625,14 @@ static int get_new_event_name(char *buf, out: free(nbase); + + /* Final validation */ + if (ret >= 0 && !is_c_func_name(buf)) { + pr_warning("Internal error: \"%s\" is an invalid event name.\n", + buf); + ret = -EINVAL; + } + return ret; } Patches currently in stable-queue which might be from mhiramat(a)kernel.org are queue-4.14/perf-probe-find-versioned-symbols-from-map.patch queue-4.14/perf-probe-add-warning-message-if-there-is-unexpected-event-name.patch

7 years, 2 months

1
0
0 0

Patch "perf evsel: Enable ignore_missing_thread for pid option" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf evsel: Enable ignore_missing_thread for pid option to the 4.14-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: perf-evsel-enable-ignore_missing_thread-for-pid-option.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Mengting Zhang <zhangmengting(a)huawei.com> Date: Wed, 13 Dec 2017 15:01:53 +0800 Subject: perf evsel: Enable ignore_missing_thread for pid option From: Mengting Zhang <zhangmengting(a)huawei.com> [ Upstream commit ca8000684ec4e66f965e1f9547a3c6cb834154ca ] While monitoring a multithread process with pid option, perf sometimes may return sys_perf_event_open failure with 3(No such process) if any of the process's threads die before we open the event. However, we want perf continue monitoring the remaining threads and do not exit with error. Here, the patch enables perf_evsel::ignore_missing_thread for -p option to ignore complete failure if any of threads die before we open the event. But it may still return sys_perf_event_open failure with 22(Invalid) if we monitors several event groups. sys_perf_event_open: pid 28960 cpu 40 group_fd 118202 flags 0x8 sys_perf_event_open: pid 28961 cpu 40 group_fd 118203 flags 0x8 WARNING: Ignored open failure for pid 28962 sys_perf_event_open: pid 28962 cpu 40 group_fd [118203] flags 0x8 sys_perf_event_open failed, error -22 That is because when we ignore a missing thread, we change the thread_idx without dealing with its fds, FD(evsel, cpu, thread). Then get_group_fd() may return a wrong group_fd for the next thread and sys_perf_event_open() return with 22. sys_perf_event_open(){ ... if (group_fd != -1) perf_fget_light()//to get corresponding group_leader by group_fd ... if (group_leader) if (group_leader->ctx->task != ctx->task)//should on the same task goto err_context ... } This patch also fixes this bug by introducing perf_evsel__remove_fd() and update_fds to allow removing fds for the missing thread. Changes since v1: - Change group_fd__remove() into a more genetic way without changing code logic - Remove redundant condition Changes since v2: - Use a proper function name and add some comment. - Multiline comment style fixes. Committer testing: Before this patch the recently added 'perf stat --per-thread' for system wide counting would race while enumerating all threads using /proc: [root@jouet ~]# perf stat --per-thread failed to parse CPUs map: No such file or directory Usage: perf stat [<options>] [<command>] -C, --cpu <cpu> list of cpus to monitor in system-wide -a, --all-cpus system-wide collection from all CPUs [root@jouet ~]# perf stat --per-thread failed to parse CPUs map: No such file or directory Usage: perf stat [<options>] [<command>] -C, --cpu <cpu> list of cpus to monitor in system-wide -a, --all-cpus system-wide collection from all CPUs [root@jouet ~]# When, say, the kernel was being built, so lots of shortlived threads, after this patch this doesn't happen. Signed-off-by: Mengting Zhang <zhangmengting(a)huawei.com> Tested-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Acked-by: Jiri Olsa <jolsa(a)redhat.com> Cc: Cheng Jian <cj.chengjian(a)huawei.com> Cc: Li Bin <huawei.libin(a)huawei.com> Cc: Wang Nan <wangnan0(a)huawei.com> Link: http://lkml.kernel.org/r/1513148513-6974-1-git-send-email-zhangmengting@hua… [ Remove one use 'evlist' alias variable ] Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/builtin-record.c | 4 +-- tools/perf/util/evsel.c | 47 ++++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 47 insertions(+), 4 deletions(-) --- a/tools/perf/builtin-record.c +++ b/tools/perf/builtin-record.c @@ -1856,8 +1856,8 @@ int cmd_record(int argc, const char **ar goto out; } - /* Enable ignoring missing threads when -u option is defined. */ - rec->opts.ignore_missing_thread = rec->opts.target.uid != UINT_MAX; + /* Enable ignoring missing threads when -u/-p option is defined. */ + rec->opts.ignore_missing_thread = rec->opts.target.uid != UINT_MAX || rec->opts.target.pid; err = -ENOMEM; if (perf_evlist__create_maps(rec->evlist, &rec->opts.target) < 0) --- a/tools/perf/util/evsel.c +++ b/tools/perf/util/evsel.c @@ -1591,10 +1591,46 @@ static int __open_attr__fprintf(FILE *fp return fprintf(fp, " %-32s %s\n", name, val); } +static void perf_evsel__remove_fd(struct perf_evsel *pos, + int nr_cpus, int nr_threads, + int thread_idx) +{ + for (int cpu = 0; cpu < nr_cpus; cpu++) + for (int thread = thread_idx; thread < nr_threads - 1; thread++) + FD(pos, cpu, thread) = FD(pos, cpu, thread + 1); +} + +static int update_fds(struct perf_evsel *evsel, + int nr_cpus, int cpu_idx, + int nr_threads, int thread_idx) +{ + struct perf_evsel *pos; + + if (cpu_idx >= nr_cpus || thread_idx >= nr_threads) + return -EINVAL; + + evlist__for_each_entry(evsel->evlist, pos) { + nr_cpus = pos != evsel ? nr_cpus : cpu_idx; + + perf_evsel__remove_fd(pos, nr_cpus, nr_threads, thread_idx); + + /* + * Since fds for next evsel has not been created, + * there is no need to iterate whole event list. + */ + if (pos == evsel) + break; + } + return 0; +} + static bool ignore_missing_thread(struct perf_evsel *evsel, + int nr_cpus, int cpu, struct thread_map *threads, int thread, int err) { + pid_t ignore_pid = thread_map__pid(threads, thread); + if (!evsel->ignore_missing_thread) return false; @@ -1610,11 +1646,18 @@ static bool ignore_missing_thread(struct if (threads->nr == 1) return false; + /* + * We should remove fd for missing_thread first + * because thread_map__remove() will decrease threads->nr. + */ + if (update_fds(evsel, nr_cpus, cpu, threads->nr, thread)) + return false; + if (thread_map__remove(threads, thread)) return false; pr_warning("WARNING: Ignored open failure for pid %d\n", - thread_map__pid(threads, thread)); + ignore_pid); return true; } @@ -1719,7 +1762,7 @@ retry_open: if (fd < 0) { err = -errno; - if (ignore_missing_thread(evsel, threads, thread, err)) { + if (ignore_missing_thread(evsel, cpus->nr, cpu, threads, thread, err)) { /* * We just removed 1 thread, so take a step * back on thread index and lower the upper Patches currently in stable-queue which might be from zhangmengting(a)huawei.com are queue-4.14/perf-evsel-enable-ignore_missing_thread-for-pid-option.patch

7 years, 2 months

1
0
0 0

Patch "nvme_fcloop: disassocate local port structs" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nvme_fcloop: disassocate local port structs to the 4.14-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: nvme_fcloop-disassocate-local-port-structs.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: James Smart <jsmart2021(a)gmail.com> Date: Wed, 29 Nov 2017 16:47:31 -0800 Subject: nvme_fcloop: disassocate local port structs From: James Smart <jsmart2021(a)gmail.com> [ Upstream commit 6fda20283e55b9d288cd56822ce39fc8e64f2208 ] The current fcloop driver gets its lport structure from the private area co-allocated with the fc_localport. All is fine except the teardown path, which wants to wait on the completion, which is marked complete by the delete_localport callback performed after unregister_localport. The issue is, the nvme_fc transport frees the localport structure immediately after delete_localport is called, meaning the original routine is trying to wait on a complete that was just freed. Change such that a lport struct is allocated coincident with the addition and registration of a localport. The private area of the localport now contains just a backpointer to the real lport struct. Now, the completion can be waited for, and after completing, the new structure can be kfree'd. Signed-off-by: James Smart <james.smart(a)broadcom.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/nvme/target/fcloop.c | 35 +++++++++++++++++++++++++---------- 1 file changed, 25 insertions(+), 10 deletions(-) --- a/drivers/nvme/target/fcloop.c +++ b/drivers/nvme/target/fcloop.c @@ -204,6 +204,10 @@ struct fcloop_lport { struct completion unreg_done; }; +struct fcloop_lport_priv { + struct fcloop_lport *lport; +}; + struct fcloop_rport { struct nvme_fc_remote_port *remoteport; struct nvmet_fc_target_port *targetport; @@ -657,7 +661,8 @@ fcloop_nport_get(struct fcloop_nport *np static void fcloop_localport_delete(struct nvme_fc_local_port *localport) { - struct fcloop_lport *lport = localport->private; + struct fcloop_lport_priv *lport_priv = localport->private; + struct fcloop_lport *lport = lport_priv->lport; /* release any threads waiting for the unreg to complete */ complete(&lport->unreg_done); @@ -697,7 +702,7 @@ static struct nvme_fc_port_template fcte .max_dif_sgl_segments = FCLOOP_SGL_SEGS, .dma_boundary = FCLOOP_DMABOUND_4G, /* sizes of additional private data for data structures */ - .local_priv_sz = sizeof(struct fcloop_lport), + .local_priv_sz = sizeof(struct fcloop_lport_priv), .remote_priv_sz = sizeof(struct fcloop_rport), .lsrqst_priv_sz = sizeof(struct fcloop_lsreq), .fcprqst_priv_sz = sizeof(struct fcloop_ini_fcpreq), @@ -728,11 +733,17 @@ fcloop_create_local_port(struct device * struct fcloop_ctrl_options *opts; struct nvme_fc_local_port *localport; struct fcloop_lport *lport; - int ret; + struct fcloop_lport_priv *lport_priv; + unsigned long flags; + int ret = -ENOMEM; + + lport = kzalloc(sizeof(*lport), GFP_KERNEL); + if (!lport) + return -ENOMEM; opts = kzalloc(sizeof(*opts), GFP_KERNEL); if (!opts) - return -ENOMEM; + goto out_free_lport; ret = fcloop_parse_options(opts, buf); if (ret) @@ -752,23 +763,25 @@ fcloop_create_local_port(struct device * ret = nvme_fc_register_localport(&pinfo, &fctemplate, NULL, &localport); if (!ret) { - unsigned long flags; - /* success */ - lport = localport->private; + lport_priv = localport->private; + lport_priv->lport = lport; + lport->localport = localport; INIT_LIST_HEAD(&lport->lport_list); spin_lock_irqsave(&fcloop_lock, flags); list_add_tail(&lport->lport_list, &fcloop_lports); spin_unlock_irqrestore(&fcloop_lock, flags); - - /* mark all of the input buffer consumed */ - ret = count; } out_free_opts: kfree(opts); +out_free_lport: + /* free only if we're going to fail */ + if (ret) + kfree(lport); + return ret ? ret : count; } @@ -790,6 +803,8 @@ __wait_localport_unreg(struct fcloop_lpo wait_for_completion(&lport->unreg_done); + kfree(lport); + return ret; } Patches currently in stable-queue which might be from jsmart2021(a)gmail.com are queue-4.14/nvme_fcloop-fix-abort-race-condition.patch queue-4.14/nvme_fcloop-disassocate-local-port-structs.patch

7 years, 2 months

1
0
0 0

Patch "nvme_fcloop: fix abort race condition" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nvme_fcloop: fix abort race condition to the 4.14-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: nvme_fcloop-fix-abort-race-condition.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: James Smart <jsmart2021(a)gmail.com> Date: Wed, 29 Nov 2017 16:47:30 -0800 Subject: nvme_fcloop: fix abort race condition From: James Smart <jsmart2021(a)gmail.com> [ Upstream commit 278e096063f1914fccfc77a617be9fc8dbb31b0e ] A test case revealed a race condition of an i/o completing on a thread parallel to the delete_association generating the aborts for the outstanding ios on the controller. The i/o completion was freeing the target fcloop context, thus the abort task referenced the just-freed memory. Correct by clearing the target/initiator cross pointers in the io completion and abort tasks before calling the callbacks. On aborts that detect already finished io's, ensure the complete context is called. Signed-off-by: James Smart <james.smart(a)broadcom.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/nvme/target/fcloop.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) --- a/drivers/nvme/target/fcloop.c +++ b/drivers/nvme/target/fcloop.c @@ -374,6 +374,7 @@ fcloop_tgt_fcprqst_done_work(struct work spin_lock(&tfcp_req->reqlock); fcpreq = tfcp_req->fcpreq; + tfcp_req->fcpreq = NULL; spin_unlock(&tfcp_req->reqlock); if (tport->remoteport && fcpreq) { @@ -615,11 +616,7 @@ fcloop_fcp_abort(struct nvme_fc_local_po if (!tfcp_req) /* abort has already been called */ - return; - - if (rport->targetport) - nvmet_fc_rcv_fcp_abort(rport->targetport, - &tfcp_req->tgt_fcp_req); + goto finish; /* break initiator/target relationship for io */ spin_lock(&tfcp_req->reqlock); @@ -627,6 +624,11 @@ fcloop_fcp_abort(struct nvme_fc_local_po tfcp_req->fcpreq = NULL; spin_unlock(&tfcp_req->reqlock); + if (rport->targetport) + nvmet_fc_rcv_fcp_abort(rport->targetport, + &tfcp_req->tgt_fcp_req); + +finish: /* post the aborted io completion */ fcpreq->status = -ECANCELED; schedule_work(&inireq->iniwork); Patches currently in stable-queue which might be from jsmart2021(a)gmail.com are queue-4.14/nvme_fcloop-fix-abort-race-condition.patch queue-4.14/nvme_fcloop-disassocate-local-port-structs.patch

7 years, 2 months

1
0
0 0

Patch "net/mlx5: Fix race for multiple RoCE enable" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net/mlx5: Fix race for multiple RoCE enable to the 4.14-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: net-mlx5-fix-race-for-multiple-roce-enable.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Daniel Jurgens <danielj(a)mellanox.com> Date: Thu, 4 Jan 2018 17:25:31 +0200 Subject: net/mlx5: Fix race for multiple RoCE enable From: Daniel Jurgens <danielj(a)mellanox.com> [ Upstream commit 734dc065fc41f6143ff88225aa5d335cb1e0f6aa ] There are two potential problems with the existing implementation. 1. Enable and disable can race after the atomic operations. 2. If a command fails the refcount is left in an inconsistent state. Introduce a lock and perform error checking. Fixes: a6f7d2aff623 ("net/mlx5: Add support for multiple RoCE enable") Signed-off-by: Daniel Jurgens <danielj(a)mellanox.com> Reviewed-by: Parav Pandit <parav(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/mellanox/mlx5/core/vport.c | 33 +++++++++++++++++++----- include/linux/mlx5/driver.h | 2 - 2 files changed, 28 insertions(+), 7 deletions(-) --- a/drivers/net/ethernet/mellanox/mlx5/core/vport.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/vport.c @@ -36,6 +36,9 @@ #include <linux/mlx5/vport.h> #include "mlx5_core.h" +/* Mutex to hold while enabling or disabling RoCE */ +static DEFINE_MUTEX(mlx5_roce_en_lock); + static int _mlx5_query_vport_state(struct mlx5_core_dev *mdev, u8 opmod, u16 vport, u32 *out, int outlen) { @@ -998,17 +1001,35 @@ static int mlx5_nic_vport_update_roce_st int mlx5_nic_vport_enable_roce(struct mlx5_core_dev *mdev) { - if (atomic_inc_return(&mdev->roce.roce_en) != 1) - return 0; - return mlx5_nic_vport_update_roce_state(mdev, MLX5_VPORT_ROCE_ENABLED); + int err = 0; + + mutex_lock(&mlx5_roce_en_lock); + if (!mdev->roce.roce_en) + err = mlx5_nic_vport_update_roce_state(mdev, MLX5_VPORT_ROCE_ENABLED); + + if (!err) + mdev->roce.roce_en++; + mutex_unlock(&mlx5_roce_en_lock); + + return err; } EXPORT_SYMBOL_GPL(mlx5_nic_vport_enable_roce); int mlx5_nic_vport_disable_roce(struct mlx5_core_dev *mdev) { - if (atomic_dec_return(&mdev->roce.roce_en) != 0) - return 0; - return mlx5_nic_vport_update_roce_state(mdev, MLX5_VPORT_ROCE_DISABLED); + int err = 0; + + mutex_lock(&mlx5_roce_en_lock); + if (mdev->roce.roce_en) { + mdev->roce.roce_en--; + if (mdev->roce.roce_en == 0) + err = mlx5_nic_vport_update_roce_state(mdev, MLX5_VPORT_ROCE_DISABLED); + + if (err) + mdev->roce.roce_en++; + } + mutex_unlock(&mlx5_roce_en_lock); + return err; } EXPORT_SYMBOL_GPL(mlx5_nic_vport_disable_roce); --- a/include/linux/mlx5/driver.h +++ b/include/linux/mlx5/driver.h @@ -794,7 +794,7 @@ struct mlx5_core_dev { struct mlx5e_resources mlx5e_res; struct { struct mlx5_rsvd_gids reserved_gids; - atomic_t roce_en; + u32 roce_en; } roce; #ifdef CONFIG_MLX5_FPGA struct mlx5_fpga_device *fpga; Patches currently in stable-queue which might be from danielj(a)mellanox.com are queue-4.14/net-mlx5-fix-race-for-multiple-roce-enable.patch

7 years, 2 months

1
0
0 0

Patch "net/mlx4_en: Change default QoS settings" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net/mlx4_en: Change default QoS settings to the 4.14-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: net-mlx4_en-change-default-qos-settings.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Moni Shoua <monis(a)mellanox.com> Date: Thu, 28 Dec 2017 16:26:11 +0200 Subject: net/mlx4_en: Change default QoS settings From: Moni Shoua <monis(a)mellanox.com> [ Upstream commit a42b63c1ac1986f17f71bc91a6b0aaa14d4dae71 ] Change the default mapping between TC and TCG as follows: Prio | TC/TCG | from to | (set by FW) (set by SW) ---------+----------------------------------- 0 | 0/0 0/7 1 | 1/0 0/6 2 | 2/0 0/5 3 | 3/0 0/4 4 | 4/0 0/3 5 | 5/0 0/2 6 | 6/0 0/1 7 | 7/0 0/0 These new settings cause that a pause frame for any prio stops traffic for all prios. Fixes: 564c274c3df0 ("net/mlx4_en: DCB QoS support") Signed-off-by: Moni Shoua <monis(a)mellanox.com> Signed-off-by: Maor Gottlieb <maorg(a)mellanox.com> Signed-off-by: Tariq Toukan <tariqt(a)mellanox.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c | 5 +++++ drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 7 +++++++ drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 + 3 files changed, 13 insertions(+) --- a/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c +++ b/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c @@ -310,6 +310,7 @@ static int mlx4_en_ets_validate(struct m } switch (ets->tc_tsa[i]) { + case IEEE_8021QAZ_TSA_VENDOR: case IEEE_8021QAZ_TSA_STRICT: break; case IEEE_8021QAZ_TSA_ETS: @@ -347,6 +348,10 @@ static int mlx4_en_config_port_scheduler /* higher TC means higher priority => lower pg */ for (i = IEEE_8021QAZ_MAX_TCS - 1; i >= 0; i--) { switch (ets->tc_tsa[i]) { + case IEEE_8021QAZ_TSA_VENDOR: + pg[i] = MLX4_EN_TC_VENDOR; + tc_tx_bw[i] = MLX4_EN_BW_MAX; + break; case IEEE_8021QAZ_TSA_STRICT: pg[i] = num_strict++; tc_tx_bw[i] = MLX4_EN_BW_MAX; --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c @@ -3335,6 +3335,13 @@ int mlx4_en_init_netdev(struct mlx4_en_d priv->msg_enable = MLX4_EN_MSG_LEVEL; #ifdef CONFIG_MLX4_EN_DCB if (!mlx4_is_slave(priv->mdev->dev)) { + u8 prio; + + for (prio = 0; prio < IEEE_8021QAZ_MAX_TCS; ++prio) { + priv->ets.prio_tc[prio] = prio; + priv->ets.tc_tsa[prio] = IEEE_8021QAZ_TSA_VENDOR; + } + priv->dcbx_cap = DCB_CAP_DCBX_VER_CEE | DCB_CAP_DCBX_HOST | DCB_CAP_DCBX_VER_IEEE; priv->flags |= MLX4_EN_DCB_ENABLED; --- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h +++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h @@ -476,6 +476,7 @@ struct mlx4_en_frag_info { #define MLX4_EN_BW_MIN 1 #define MLX4_EN_BW_MAX 100 /* Utilize 100% of the line */ +#define MLX4_EN_TC_VENDOR 0 #define MLX4_EN_TC_ETS 7 enum dcb_pfc_type { Patches currently in stable-queue which might be from monis(a)mellanox.com are queue-4.14/net-mlx4_en-change-default-qos-settings.patch

7 years, 2 months

1
0
0 0

Patch "net: hns3: fix for getting auto-negotiation state in hclge_get_autoneg" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: hns3: fix for getting auto-negotiation state in hclge_get_autoneg to the 4.14-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: net-hns3-fix-for-getting-auto-negotiation-state-in-hclge_get_autoneg.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Fuyun Liang <liangfuyun1(a)huawei.com> Date: Fri, 22 Dec 2017 12:21:50 +0800 Subject: net: hns3: fix for getting auto-negotiation state in hclge_get_autoneg From: Fuyun Liang <liangfuyun1(a)huawei.com> [ Upstream commit 27b5bf49f0924fd62d2b1ef8467b40773973da34 ] When phy exists, we use the value of phydev.autoneg to represent the auto-negotiation state of hardware. Otherwise, we use the value of mac.autoneg to represent it. This patch fixes for getting a error value of auto-negotiation state in hclge_get_autoneg(). Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by: Fuyun Liang <liangfuyun1(a)huawei.com> Signed-off-by: Peng Li <lipeng321(a)huawei.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c @@ -2092,6 +2092,10 @@ static int hclge_get_autoneg(struct hnae { struct hclge_vport *vport = hclge_get_vport(handle); struct hclge_dev *hdev = vport->back; + struct phy_device *phydev = hdev->hw.mac.phydev; + + if (phydev) + return phydev->autoneg; hclge_query_autoneg_result(hdev); Patches currently in stable-queue which might be from liangfuyun1(a)huawei.com are queue-4.14/net-hns3-fix-for-getting-auto-negotiation-state-in-hclge_get_autoneg.patch queue-4.14/net-hns3-fix-for-changing-mtu.patch

7 years, 2 months

1
0
0 0

Patch "net: hns3: free the ring_data structrue when change tqps" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: hns3: free the ring_data structrue when change tqps to the 4.14-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: net-hns3-free-the-ring_data-structrue-when-change-tqps.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Peng Li <lipeng321(a)huawei.com> Date: Fri, 22 Dec 2017 12:21:43 +0800 Subject: net: hns3: free the ring_data structrue when change tqps From: Peng Li <lipeng321(a)huawei.com> [ Upstream commit 99fdf6b1cadf41bb253408589788f025027274f3 ] This patch fixes a memory leak problems in change tqps process, the function hns3_uninit_all_ring and hns3_init_all_ring may be called many times. Signed-off-by: Peng Li <lipeng321(a)huawei.com> Signed-off-by: Mingguang Qu <qumingguang(a)huawei.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c @@ -2687,8 +2687,12 @@ static int hns3_uninit_all_ring(struct h h->ae_algo->ops->reset_queue(h, i); hns3_fini_ring(priv->ring_data[i].ring); + devm_kfree(priv->dev, priv->ring_data[i].ring); hns3_fini_ring(priv->ring_data[i + h->kinfo.num_tqps].ring); + devm_kfree(priv->dev, + priv->ring_data[i + h->kinfo.num_tqps].ring); } + devm_kfree(priv->dev, priv->ring_data); return 0; } Patches currently in stable-queue which might be from lipeng321(a)huawei.com are queue-4.14/net-hns3-fix-for-getting-auto-negotiation-state-in-hclge_get_autoneg.patch queue-4.14/net-hns3-free-the-ring_data-structrue-when-change-tqps.patch queue-4.14/net-hns3-fix-a-loop-index-error-of-tqp-statistics-query.patch queue-4.14/net-hns3-fix-an-error-macro-definition-of-hns3_tqp_stat.patch queue-4.14/net-hns3-fix-an-error-of-total-drop-packet-statistics.patch queue-4.14/net-hns3-fix-for-changing-mtu.patch

7 years, 2 months

1
0
0 0

Patch "net: hns3: fix for changing MTU" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: hns3: fix for changing MTU to the 4.14-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: net-hns3-fix-for-changing-mtu.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Fuyun Liang <liangfuyun1(a)huawei.com> Date: Fri, 5 Jan 2018 18:18:20 +0800 Subject: net: hns3: fix for changing MTU From: Fuyun Liang <liangfuyun1(a)huawei.com> [ Upstream commit 5bad95a1e55f4d5bb41e130db859d57eaf1b1549 ] when changing MTU, The new MTU must need to be set to netdevice. Fixes: a8e8b7ff3517 ("net: hns3: Add support to change MTU in HNS3 hardware") Signed-off-by: Fuyun Liang <liangfuyun1(a)huawei.com> Signed-off-by: Peng Li <lipeng321(a)huawei.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c @@ -1313,6 +1313,8 @@ static int hns3_nic_change_mtu(struct ne return ret; } + netdev->mtu = new_mtu; + /* if the netdev was running earlier, bring it up again */ if (if_running && hns3_nic_net_open(netdev)) ret = -EINVAL; Patches currently in stable-queue which might be from liangfuyun1(a)huawei.com are queue-4.14/net-hns3-fix-for-getting-auto-negotiation-state-in-hclge_get_autoneg.patch queue-4.14/net-hns3-fix-for-changing-mtu.patch

7 years, 2 months

1
0
0 0

Patch "net: hns3: Fix an error of total drop packet statistics" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: hns3: Fix an error of total drop packet statistics to the 4.14-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: net-hns3-fix-an-error-of-total-drop-packet-statistics.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Jian Shen <shenjian15(a)huawei.com> Date: Fri, 5 Jan 2018 18:18:12 +0800 Subject: net: hns3: Fix an error of total drop packet statistics From: Jian Shen <shenjian15(a)huawei.com> [ Upstream commit d2a5dca8404871be683c6bbc175ebf9c56dd2865 ] The dropped tx/rx packets number of each tqp should also be counted into the total drop tx/rx packets numbers. Fixes: 76ad4f0ee74 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC") Signed-off-by: Jian Shen <shenjian15(a)huawei.com> Signed-off-by: Peng Li <lipeng321(a)huawei.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c @@ -1060,6 +1060,8 @@ hns3_nic_get_stats64(struct net_device * u64 rx_bytes = 0; u64 tx_pkts = 0; u64 rx_pkts = 0; + u64 tx_drop = 0; + u64 rx_drop = 0; for (idx = 0; idx < queue_num; idx++) { /* fetch the tx stats */ @@ -1068,6 +1070,8 @@ hns3_nic_get_stats64(struct net_device * start = u64_stats_fetch_begin_irq(&ring->syncp); tx_bytes += ring->stats.tx_bytes; tx_pkts += ring->stats.tx_pkts; + tx_drop += ring->stats.tx_busy; + tx_drop += ring->stats.sw_err_cnt; } while (u64_stats_fetch_retry_irq(&ring->syncp, start)); /* fetch the rx stats */ @@ -1076,6 +1080,9 @@ hns3_nic_get_stats64(struct net_device * start = u64_stats_fetch_begin_irq(&ring->syncp); rx_bytes += ring->stats.rx_bytes; rx_pkts += ring->stats.rx_pkts; + rx_drop += ring->stats.non_vld_descs; + rx_drop += ring->stats.err_pkt_len; + rx_drop += ring->stats.l2_err; } while (u64_stats_fetch_retry_irq(&ring->syncp, start)); } @@ -1091,8 +1098,8 @@ hns3_nic_get_stats64(struct net_device * stats->rx_missed_errors = netdev->stats.rx_missed_errors; stats->tx_errors = netdev->stats.tx_errors; - stats->rx_dropped = netdev->stats.rx_dropped; - stats->tx_dropped = netdev->stats.tx_dropped; + stats->rx_dropped = rx_drop + netdev->stats.rx_dropped; + stats->tx_dropped = tx_drop + netdev->stats.tx_dropped; stats->collisions = netdev->stats.collisions; stats->rx_over_errors = netdev->stats.rx_over_errors; stats->rx_frame_errors = netdev->stats.rx_frame_errors; Patches currently in stable-queue which might be from shenjian15(a)huawei.com are queue-4.14/net-hns3-fix-a-loop-index-error-of-tqp-statistics-query.patch queue-4.14/net-hns3-fix-an-error-macro-definition-of-hns3_tqp_stat.patch queue-4.14/net-hns3-fix-an-error-of-total-drop-packet-statistics.patch

7 years, 2 months

1
0
0 0

Patch "net: hns3: Fix an error macro definition of HNS3_TQP_STAT" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: hns3: Fix an error macro definition of HNS3_TQP_STAT to the 4.14-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: net-hns3-fix-an-error-macro-definition-of-hns3_tqp_stat.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Jian Shen <shenjian15(a)huawei.com> Date: Fri, 5 Jan 2018 18:18:14 +0800 Subject: net: hns3: Fix an error macro definition of HNS3_TQP_STAT From: Jian Shen <shenjian15(a)huawei.com> [ Upstream commit 57ffee737b36dbb81e8e60a37e01791553157a5e ] The member "stats_offset" was designed to indicate the offset of each member of struct ring_stats in struct hns3_enet_ring, but forgot to add the offset of the member in struct ring_stats. Fixes: 496d03e960a ("net: hns3: Add Ethtool support to HNS3 driver") Signed-off-by: Jian Shen <shenjian15(a)huawei.com> Signed-off-by: Peng Li <lipeng321(a)huawei.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c @@ -22,7 +22,8 @@ struct hns3_stats { #define HNS3_TQP_STAT(_string, _member) { \ .stats_string = _string, \ .stats_size = FIELD_SIZEOF(struct ring_stats, _member), \ - .stats_offset = offsetof(struct hns3_enet_ring, stats), \ + .stats_offset = offsetof(struct hns3_enet_ring, stats) +\ + offsetof(struct ring_stats, _member), \ } \ static const struct hns3_stats hns3_txq_stats[] = { Patches currently in stable-queue which might be from shenjian15(a)huawei.com are queue-4.14/net-hns3-fix-a-loop-index-error-of-tqp-statistics-query.patch queue-4.14/net-hns3-fix-an-error-macro-definition-of-hns3_tqp_stat.patch queue-4.14/net-hns3-fix-an-error-of-total-drop-packet-statistics.patch

7 years, 2 months

1
0
0 0

Patch "net: hns3: Fix a loop index error of tqp statistics query" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: hns3: Fix a loop index error of tqp statistics query to the 4.14-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: net-hns3-fix-a-loop-index-error-of-tqp-statistics-query.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Jian Shen <shenjian15(a)huawei.com> Date: Fri, 5 Jan 2018 18:18:13 +0800 Subject: net: hns3: Fix a loop index error of tqp statistics query From: Jian Shen <shenjian15(a)huawei.com> [ Upstream commit 94bfaafac9d2a3c0bcca00d01e38f7597b741799 ] An error loop index was used while querying statistics data of tqps, which may cause call trace. Fixes: 496d03e960ae ("net: hns3: Add Ethtool support to HNS3 driver") Signed-off-by: Jian Shen <shenjian15(a)huawei.com> Signed-off-by: Peng Li <lipeng321(a)huawei.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c @@ -189,13 +189,13 @@ static u64 *hns3_get_stats_tqps(struct h struct hnae3_knic_private_info *kinfo = &handle->kinfo; struct hns3_enet_ring *ring; u8 *stat; - u32 i; + int i, j; /* get stats for Tx */ for (i = 0; i < kinfo->num_tqps; i++) { ring = nic_priv->ring_data[i].ring; - for (i = 0; i < HNS3_TXQ_STATS_COUNT; i++) { - stat = (u8 *)ring + hns3_txq_stats[i].stats_offset; + for (j = 0; j < HNS3_TXQ_STATS_COUNT; j++) { + stat = (u8 *)ring + hns3_txq_stats[j].stats_offset; *data++ = *(u64 *)stat; } } @@ -203,8 +203,8 @@ static u64 *hns3_get_stats_tqps(struct h /* get stats for Rx */ for (i = 0; i < kinfo->num_tqps; i++) { ring = nic_priv->ring_data[i + kinfo->num_tqps].ring; - for (i = 0; i < HNS3_RXQ_STATS_COUNT; i++) { - stat = (u8 *)ring + hns3_rxq_stats[i].stats_offset; + for (j = 0; j < HNS3_RXQ_STATS_COUNT; j++) { + stat = (u8 *)ring + hns3_rxq_stats[j].stats_offset; *data++ = *(u64 *)stat; } } Patches currently in stable-queue which might be from shenjian15(a)huawei.com are queue-4.14/net-hns3-fix-a-loop-index-error-of-tqp-statistics-query.patch queue-4.14/net-hns3-fix-an-error-macro-definition-of-hns3_tqp_stat.patch queue-4.14/net-hns3-fix-an-error-of-total-drop-packet-statistics.patch

7 years, 2 months

1
0
0 0

Patch "mtd: mtd_oobtest: Handle bitflips during reads" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mtd: mtd_oobtest: Handle bitflips during reads to the 4.14-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: mtd-mtd_oobtest-handle-bitflips-during-reads.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Miquel Raynal <miquel.raynal(a)free-electrons.com> Date: Thu, 11 Jan 2018 21:39:20 +0100 Subject: mtd: mtd_oobtest: Handle bitflips during reads From: Miquel Raynal <miquel.raynal(a)free-electrons.com> [ Upstream commit 12663b442e5ac5aa3d6097cd3f287c71ba46d26e ] Reads from NAND devices usually trigger bitflips, this is an expected behavior. While bitflips are under a given threshold, the MTD core returns 0. However, when the number of corrected bitflips is above this same threshold, -EUCLEAN is returned to inform the upper layer that this block is slightly dying and soon the ECC engine will be overtaken so actions should be taken to move the data out of it. This particular condition should not be treated like an error and the test should continue. Signed-off-by: Miquel Raynal <miquel.raynal(a)free-electrons.com> Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mtd/tests/oobtest.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) --- a/drivers/mtd/tests/oobtest.c +++ b/drivers/mtd/tests/oobtest.c @@ -193,6 +193,9 @@ static int verify_eraseblock(int ebnum) ops.datbuf = NULL; ops.oobbuf = readbuf; err = mtd_read_oob(mtd, addr, &ops); + if (mtd_is_bitflip(err)) + err = 0; + if (err || ops.oobretlen != use_len) { pr_err("error: readoob failed at %#llx\n", (long long)addr); @@ -227,6 +230,9 @@ static int verify_eraseblock(int ebnum) ops.datbuf = NULL; ops.oobbuf = readbuf; err = mtd_read_oob(mtd, addr, &ops); + if (mtd_is_bitflip(err)) + err = 0; + if (err || ops.oobretlen != mtd->oobavail) { pr_err("error: readoob failed at %#llx\n", (long long)addr); @@ -286,6 +292,9 @@ static int verify_eraseblock_in_one_go(i /* read entire block's OOB at one go */ err = mtd_read_oob(mtd, addr, &ops); + if (mtd_is_bitflip(err)) + err = 0; + if (err || ops.oobretlen != len) { pr_err("error: readoob failed at %#llx\n", (long long)addr); @@ -527,6 +536,9 @@ static int __init mtd_oobtest_init(void) pr_info("attempting to start read past end of OOB\n"); pr_info("an error is expected...\n"); err = mtd_read_oob(mtd, addr0, &ops); + if (mtd_is_bitflip(err)) + err = 0; + if (err) { pr_info("error occurred as expected\n"); err = 0; @@ -571,6 +583,9 @@ static int __init mtd_oobtest_init(void) pr_info("attempting to read past end of device\n"); pr_info("an error is expected...\n"); err = mtd_read_oob(mtd, mtd->size - mtd->writesize, &ops); + if (mtd_is_bitflip(err)) + err = 0; + if (err) { pr_info("error occurred as expected\n"); err = 0; @@ -615,6 +630,9 @@ static int __init mtd_oobtest_init(void) pr_info("attempting to read past end of device\n"); pr_info("an error is expected...\n"); err = mtd_read_oob(mtd, mtd->size - mtd->writesize, &ops); + if (mtd_is_bitflip(err)) + err = 0; + if (err) { pr_info("error occurred as expected\n"); err = 0; @@ -684,6 +702,9 @@ static int __init mtd_oobtest_init(void) ops.datbuf = NULL; ops.oobbuf = readbuf; err = mtd_read_oob(mtd, addr, &ops); + if (mtd_is_bitflip(err)) + err = 0; + if (err) goto out; if (memcmpshow(addr, readbuf, writebuf, Patches currently in stable-queue which might be from miquel.raynal(a)free-electrons.com are queue-4.14/mtd-mtd_oobtest-handle-bitflips-during-reads.patch

7 years, 2 months

1
0
0 0

Patch "media: videobuf2-core: don't go out of the buffer range" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: videobuf2-core: don't go out of the buffer range to the 4.14-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: media-videobuf2-core-don-t-go-out-of-the-buffer-range.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Date: Thu, 28 Dec 2017 09:16:47 -0500 Subject: media: videobuf2-core: don't go out of the buffer range From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> [ Upstream commit df93dc61b0d8b19a5c9db545cf3fcc24f88dfde4 ] Currently, there's no check if an invalid buffer range is passed. However, while testing DVB memory mapped apps, I got this: videobuf2_core: VB: num_buffers -2143943680, buffer 33, index -2143943647 unable to handle kernel paging request at ffff888b773c0890 IP: __vb2_queue_alloc+0x134/0x4e0 [videobuf2_core] PGD 4142c7067 P4D 4142c7067 PUD 0 Oops: 0002 [#1] SMP Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables bluetooth rfkill ecdh_generic binfmt_misc rc_dvbsky sp2 ts2020 intel_rapl x86_pkg_temp_thermal dvb_usb_dvbsky intel_powerclamp dvb_usb_v2 coretemp m88ds3103 kvm_intel i2c_mux dvb_core snd_hda_codec_hdmi crct10dif_pclmul crc32_pclmul videobuf2_vmalloc videobuf2_memops snd_hda_intel ghash_clmulni_intel videobuf2_core snd_hda_codec rc_core mei_me intel_cstate snd_hwdep snd_hda_core videodev intel_uncore snd_pcm mei media tpm_tis tpm_tis_core intel_rapl_perf tpm snd_timer lpc_ich snd soundcore kvm irqbypass libcrc32c i915 i2c_algo_bit drm_kms_helper e1000e ptp drm crc32c_intel video pps_core CPU: 3 PID: 1776 Comm: dvbv5-zap Not tainted 4.14.0+ #78 Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0364.2017.0511.0949 05/11/2017 task: ffff88877c73bc80 task.stack: ffffb7c402418000 RIP: 0010:__vb2_queue_alloc+0x134/0x4e0 [videobuf2_core] RSP: 0018:ffffb7c40241bc60 EFLAGS: 00010246 RAX: 0000000080360421 RBX: 0000000000000021 RCX: 000000000000000a RDX: ffffb7c40241bcf4 RSI: ffff888780362c60 RDI: ffff888796d8e130 RBP: ffffb7c40241bcc8 R08: 0000000000000316 R09: 0000000000000004 R10: ffff888780362c00 R11: 0000000000000001 R12: 000000000002f000 R13: ffff8887758be700 R14: 0000000000021000 R15: 0000000000000001 FS: 00007f2849024740(0000) GS:ffff888796d80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff888b773c0890 CR3: 000000043beb2005 CR4: 00000000003606e0 Call Trace: vb2_core_reqbufs+0x226/0x420 [videobuf2_core] dvb_vb2_reqbufs+0x2d/0xc0 [dvb_core] dvb_dvr_do_ioctl+0x98/0x1d0 [dvb_core] dvb_usercopy+0x53/0x1b0 [dvb_core] ? dvb_demux_ioctl+0x20/0x20 [dvb_core] ? tty_ldisc_deref+0x16/0x20 ? tty_write+0x1f9/0x310 ? process_echoes+0x70/0x70 dvb_dvr_ioctl+0x15/0x20 [dvb_core] do_vfs_ioctl+0xa5/0x600 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x1a/0xa5 RIP: 0033:0x7f28486f7ea7 RSP: 002b:00007ffc13b2db18 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000055b10fc06130 RCX: 00007f28486f7ea7 RDX: 00007ffc13b2db48 RSI: 00000000c0086f3c RDI: 0000000000000007 RBP: 0000000000000203 R08: 000055b10df1e02c R09: 000000000000002e R10: 0036b42415108357 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f2849062f60 R14: 00000000000001f1 R15: 00007ffc13b2da54 Code: 74 0a 60 8b 0a 48 83 c0 30 48 83 c2 04 89 48 d0 89 48 d4 48 39 f0 75 eb 41 8b 42 08 83 7d d4 01 41 c7 82 ec 01 00 00 ff ff ff ff <4d> 89 94 c5 88 00 00 00 74 14 83 c3 01 41 39 dc 0f 85 f1 fe ff RIP: __vb2_queue_alloc+0x134/0x4e0 [videobuf2_core] RSP: ffffb7c40241bc60 CR2: ffff888b773c0890 So, add a sanity check in order to prevent going past array. Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Acked-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/v4l2-core/videobuf2-core.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -332,6 +332,10 @@ static int __vb2_queue_alloc(struct vb2_ struct vb2_buffer *vb; int ret; + /* Ensure that q->num_buffers+num_buffers is below VB2_MAX_FRAME */ + num_buffers = min_t(unsigned int, num_buffers, + VB2_MAX_FRAME - q->num_buffers); + for (buffer = 0; buffer < num_buffers; ++buffer) { /* Allocate videobuf buffer structures */ vb = kzalloc(q->buf_struct_size, GFP_KERNEL); Patches currently in stable-queue which might be from mchehab(a)s-opensource.com are queue-4.14/media-videobuf2-core-don-t-go-out-of-the-buffer-range.patch

7 years, 2 months

1
0
0 0

Patch "l2tp: fix missing print session offset info" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled l2tp: fix missing print session offset info to the 4.14-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: l2tp-fix-missing-print-session-offset-info.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Hangbin Liu <liuhangbin(a)gmail.com> Date: Fri, 22 Dec 2017 15:10:17 +0100 Subject: l2tp: fix missing print session offset info From: Hangbin Liu <liuhangbin(a)gmail.com> [ Upstream commit 820da5357572715c6235ba3b3daa2d5b43a1198f ] Report offset parameter in L2TP_CMD_SESSION_GET command if it has been configured by userspace Fixes: 309795f4bec ("l2tp: Add netlink control API for L2TP") Reported-by: Jianlin Shi <jishi(a)redhat.com> Signed-off-by: Hangbin Liu <liuhangbin(a)gmail.com> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi(a)redhat.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/l2tp/l2tp_netlink.c | 2 ++ 1 file changed, 2 insertions(+) --- a/net/l2tp/l2tp_netlink.c +++ b/net/l2tp/l2tp_netlink.c @@ -765,6 +765,8 @@ static int l2tp_nl_session_send(struct s if ((session->ifname[0] && nla_put_string(skb, L2TP_ATTR_IFNAME, session->ifname)) || + (session->offset && + nla_put_u16(skb, L2TP_ATTR_OFFSET, session->offset)) || (session->cookie_len && nla_put(skb, L2TP_ATTR_COOKIE, session->cookie_len, &session->cookie[0])) || Patches currently in stable-queue which might be from liuhangbin(a)gmail.com are queue-4.14/l2tp-fix-missing-print-session-offset-info.patch

7 years, 2 months

1
0
0 0

Patch "mac80211: Fix setting TX power on monitor interfaces" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mac80211: Fix setting TX power on monitor interfaces to the 4.14-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: mac80211-fix-setting-tx-power-on-monitor-interfaces.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: "Peter Große" <pegro(a)friiks.de> Date: Wed, 13 Dec 2017 18:29:46 +0100 Subject: mac80211: Fix setting TX power on monitor interfaces From: "Peter Große" <pegro(a)friiks.de> [ Upstream commit 3a3713ec360138f806c6fc368d1de570f692b347 ] Instead of calling ieee80211_recalc_txpower on monitor interfaces directly, call it using the virtual monitor interface, if one exists. In case of a single monitor interface given, reject setting TX power, if no virtual monitor interface exists. That being checked, don't warn in ieee80211_bss_info_change_notify, after setting TX power on a monitor interface. Fixes warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 2193 at net/mac80211/driver-ops.h:167 ieee80211_bss_info_change_notify+0x111/0x190 Modules linked in: uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core rndis_host cdc_ether usbnet mii tp_smapi(O) thinkpad_ec(O) ohci_hcd vboxpci(O) vboxnetadp(O) vboxnetflt(O) v boxdrv(O) x86_pkg_temp_thermal kvm_intel kvm irqbypass iwldvm iwlwifi ehci_pci ehci_hcd tpm_tis tpm_tis_core tpm CPU: 0 PID: 2193 Comm: iw Tainted: G O 4.12.12-gentoo #2 task: ffff880186fd5cc0 task.stack: ffffc90001b54000 RIP: 0010:ieee80211_bss_info_change_notify+0x111/0x190 RSP: 0018:ffffc90001b57a10 EFLAGS: 00010246 RAX: 0000000000000006 RBX: ffff8801052ce840 RCX: 0000000000000064 RDX: 00000000fffffffc RSI: 0000000000040000 RDI: ffff8801052ce840 RBP: ffffc90001b57a38 R08: 0000000000000062 R09: 0000000000000000 R10: ffff8802144b5000 R11: ffff880049dc4614 R12: 0000000000040000 R13: 0000000000000064 R14: ffff8802105f0760 R15: ffffc90001b57b48 FS: 00007f92644b4580(0000) GS:ffff88021e200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9263c109f0 CR3: 00000001df850000 CR4: 00000000000406f0 Call Trace: ieee80211_recalc_txpower+0x33/0x40 ieee80211_set_tx_power+0x40/0x180 nl80211_set_wiphy+0x32e/0x950 Reported-by: Peter GroÃe <pegro(a)friiks.de> Signed-off-by: Peter GroÃe <pegro(a)friiks.de> Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/mac80211/cfg.c | 28 +++++++++++++++++++++++++++- net/mac80211/driver-ops.h | 3 ++- 2 files changed, 29 insertions(+), 2 deletions(-) --- a/net/mac80211/cfg.c +++ b/net/mac80211/cfg.c @@ -2373,10 +2373,17 @@ static int ieee80211_set_tx_power(struct struct ieee80211_sub_if_data *sdata; enum nl80211_tx_power_setting txp_type = type; bool update_txp_type = false; + bool has_monitor = false; if (wdev) { sdata = IEEE80211_WDEV_TO_SUB_IF(wdev); + if (sdata->vif.type == NL80211_IFTYPE_MONITOR) { + sdata = rtnl_dereference(local->monitor_sdata); + if (!sdata) + return -EOPNOTSUPP; + } + switch (type) { case NL80211_TX_POWER_AUTOMATIC: sdata->user_power_level = IEEE80211_UNSET_POWER_LEVEL; @@ -2415,15 +2422,34 @@ static int ieee80211_set_tx_power(struct mutex_lock(&local->iflist_mtx); list_for_each_entry(sdata, &local->interfaces, list) { + if (sdata->vif.type == NL80211_IFTYPE_MONITOR) { + has_monitor = true; + continue; + } sdata->user_power_level = local->user_power_level; if (txp_type != sdata->vif.bss_conf.txpower_type) update_txp_type = true; sdata->vif.bss_conf.txpower_type = txp_type; } - list_for_each_entry(sdata, &local->interfaces, list) + list_for_each_entry(sdata, &local->interfaces, list) { + if (sdata->vif.type == NL80211_IFTYPE_MONITOR) + continue; ieee80211_recalc_txpower(sdata, update_txp_type); + } mutex_unlock(&local->iflist_mtx); + if (has_monitor) { + sdata = rtnl_dereference(local->monitor_sdata); + if (sdata) { + sdata->user_power_level = local->user_power_level; + if (txp_type != sdata->vif.bss_conf.txpower_type) + update_txp_type = true; + sdata->vif.bss_conf.txpower_type = txp_type; + + ieee80211_recalc_txpower(sdata, update_txp_type); + } + } + return 0; } --- a/net/mac80211/driver-ops.h +++ b/net/mac80211/driver-ops.h @@ -165,7 +165,8 @@ static inline void drv_bss_info_changed( if (WARN_ON_ONCE(sdata->vif.type == NL80211_IFTYPE_P2P_DEVICE || sdata->vif.type == NL80211_IFTYPE_NAN || (sdata->vif.type == NL80211_IFTYPE_MONITOR && - !sdata->vif.mu_mimo_owner))) + !sdata->vif.mu_mimo_owner && + !(changed & BSS_CHANGED_TXPOWER)))) return; if (!check_sdata_in_driver(sdata)) Patches currently in stable-queue which might be from pegro(a)friiks.de are queue-4.14/mac80211-fix-setting-tx-power-on-monitor-interfaces.patch

7 years, 2 months

1
0
0 0

[GIT PULL] commits for Linux 4.14

by Sasha Levin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Greg, Pleae pull commits for Linux 4.14 . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== The following changes since commit 9b1fb9cc922dbf27959287ad75009bb388d115fe: Linux 4.14.27 (2018-03-15 10:54:38 +0100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git tags/for-greg-4.14-04052018 for you to fetch changes up to 9c55e4701c7ae30bd21e7bbbcebd08f81005690b: thermal: int3400_thermal: fix error handling in int3400_thermal_probe() (2018-04-05 00:52:17 -0400) - ---------------------------------------------------------------- for-greg-4.14-04052018 - ---------------------------------------------------------------- Alexey Khoroshilov (1): thermal: int3400_thermal: fix error handling in int3400_thermal_probe() Andy Shevchenko (1): sdhci: Advertise 2.0v supply on SDIO host controller Arjun Vynipadath (1): cxgb4vf: Fix SGE FL buffer initialization logic for 64K pages Arnd Bergmann (1): crypto: aes-generic - build with -Os on gcc-7+ Chaitra P B (1): scsi: mpt3sas: Proper handling of set/clear of "ATA command pending" flag. Christophe JAILLET (2): ASoC: Intel: sst: Fix the return value of 'sst_send_byte_stream_mrfld()' EDAC, mv64x60: Fix an error handling path Colin Ian King (1): wl1251: check return from call to wl1251_acx_arp_ip_filter Daniel Jurgens (1): net/mlx5: Fix race for multiple RoCE enable Eric W. Biederman (3): signal/metag: Document a conflict with SI_USER with SIGFPE signal/powerpc: Document conflicts with SI_USER and SIGFPE and SIGTRAP signal/arm: Document conflicts with SI_USER and SIGFPE Florian Westphal (1): netfilter: core: only allow one nat hook per hook point Fuyun Liang (2): net: hns3: fix for getting auto-negotiation state in hclge_get_autoneg net: hns3: fix for changing MTU Gautham R. Shenoy (1): powernv-cpufreq: Add helper to extract pstate from PMSR Geert Uytterhoeven (2): spi: sh-msiof: Fix timeout failures for TX-only DMA transfers ACPI: EC: Fix debugfs_create_*() usage Gustavo A. R. Silva (1): PM / devfreq: Fix potential NULL pointer dereference in governor_store Hangbin Liu (1): l2tp: fix missing print session offset info Hans de Goede (5): ACPI / video: Default lcd_only to true on Win8-ready and newer machines ASoC: Intel: cht_bsw_rt5645: Analog Mic support pinctrl: baytrail: Enable glitch filter for GPIOs used as interrupts power: supply: axp288_charger: Properly stop work on probe-error / remove Input: goodix - disable IRQs while suspended Icenowy Zheng (1): clk: sunxi-ng: fix the A64/H5 clock description of DE2 CCU Ioan Moldovan (1): Bluetooth: Add a new 04ca:3015 QCA_ROME device Jacob Keller (1): i40evf: don't rely on netif_running() outside rtnl_lock() James Smart (2): nvme_fcloop: disassocate local port structs nvme_fcloop: fix abort race condition Jason Yan (2): scsi: libsas: fix memory leak in sas_smp_get_phy_events() scsi: libsas: fix error when getting phy events Javier Martinez Canillas (1): tpm: return a TPM_RC_COMMAND_CODE response if command is not implemented Jernej Å krabec (1): clk: sunxi-ng: a83t: Add M divider to TCON1 clock Jerome Brunet (1): clk: divider: fix incorrect usage of container_of Jian Shen (3): net: hns3: Fix an error of total drop packet statistics net: hns3: Fix a loop index error of tqp statistics query net: hns3: Fix an error macro definition of HNS3_TQP_STAT Jin Yao (1): perf report: Fix a no annotate browser displayed issue Jiri Bohac (1): x86/gart: Exclude GART aperture from vmcore Jiri Olsa (1): perf tools: Fix copyfile_offset update of output offset Leon Romanovsky (1): RDMA/cma: Mark end of CMA ID messages Linus Walleij (1): gpio: label descriptors using the device name Lorenzo Bianconi (1): iio: imu: st_lsm6dsx: fix endianness in st_lsm6dsx_read_oneshot() Maciej Purski (1): hwmon: (ina2xx) Make calibration register value fixed Martin Blumenstingl (1): clk: meson: mpll: use 64-bit maths in params_from_rate Masami Hiramatsu (2): perf probe: Find versioned symbols from map perf probe: Add warning message if there is unexpected event name Mauro Carvalho Chehab (1): media: videobuf2-core: don't go out of the buffer range Mengting Zhang (1): perf evsel: Enable ignore_missing_thread for pid option Mike Christie (1): tcmu: release blocks for partially setup cmds Mike Marciniszyn (1): IB/rdmavt: Allocate CQ memory on the correct node Ming Lei (3): blk-mq: avoid to map CPU into stale hw queue blk-mq: fix race between updating nr_hw_queues and switching io sched blk-mq: fix kernel oops in blk_mq_tag_idle() Miquel Raynal (1): mtd: mtd_oobtest: Handle bitflips during reads Moni Shoua (1): net/mlx4_en: Change default QoS settings Nathan Fontenot (1): ibmvnic: Don't handle RX interrupts when not up. NeilBrown (2): VFS: close race between getcwd() and d_move() staging: lustre: disable preempt while sampling processor id. Oleksij Rempel (1): watchdog: dw_wdt: add stop watchdog operation Paolo Valente (1): block, bfq: put async queues for root bfq groups too Parav Pandit (1): RDMA/cma: Fix rdma_cm path querying for RoCE Pardha Saradhi K (1): ASoC: Intel: Skylake: Disable clock gating during firmware and library download Peng Li (1): net: hns3: free the ring_data structrue when change tqps Peter GroÃŸe (1): mac80211: Fix setting TX power on monitor interfaces Pieter \"PoroCYon\" Sluys (1): vfb: fix video mode and line_length being set when loaded Quinn Tran (1): scsi: qla2xxx: Fix NULL pointer access for fcport structure Rafael David Tinoco (1): scsi: libiscsi: Allow sd_shutdown on bad transport Rasmus Villemoes (1): ARM: dts: ls1021a: add "fsl,ls1021a-esdhc" compatible string to esdhc node Robert Jarzmik (1): backlight: tdo24m: Fix the SPI CS between transfers Rui Hua (1): bcache: ret IOERR when read meets metadata error Shanker Donthineni (1): irqchip/gic-v3: Fix the driver probe() fail due to disabled GICC entry Shiraz Saleem (2): i40iw: Fix sequence number for the first partial FPDU i40iw: Correct Q1/XF object count equation Shivasharan S (2): scsi: megaraid_sas: Error handling for invalid ldcount provided by firmware in RAID map scsi: megaraid_sas: unload flag should be set after scsi_remove_host is called Sowmini Varadhan (2): rds; Reset rs->rs_bound_addr in rds_add_bound() failure path selftests/net: fix bugs in address and port initialization Stanislaw Gruszka (1): rt2x00: do not pause queue unconditionally on error path Stephen Hemminger (1): uio_hv_generic: check that host supports monitor page Tang Junhui (2): bcache: stop writeback thread after detaching bcache: segregate flash only volume write streams Tatyana Nikolova (1): i40iw: Validate correct IRD/ORD connection parameters Tobias Brunner (1): ipv6: Reinject IPv6 packets if IPsec policy matches after SNAT Tony Lindgren (1): tty: n_gsm: Allow ADM response in addition to UA for control dlci Wei Yongjun (1): gpio: thunderx: fix error return code in thunderx_gpio_probe() Yi Zeng (1): thermal: power_allocator: fix one race condition issue for thermal_instances list chenxiang (1): scsi: libsas: initialize sas_phy status according to response of DISCOVER arch/arm/boot/dts/ls1021a.dtsi | 2 +- arch/arm/include/uapi/asm/siginfo.h | 13 ++++ arch/arm/vfp/vfpmodule.c | 2 +- arch/metag/include/uapi/asm/siginfo.h | 7 ++ arch/metag/kernel/traps.c | 2 +- arch/powerpc/include/uapi/asm/siginfo.h | 15 ++++ arch/powerpc/kernel/traps.c | 10 +-- arch/x86/kernel/aperture_64.c | 46 +++++++++++- arch/x86/xen/mmu_hvm.c | 2 +- block/bfq-cgroup.c | 7 +- block/blk-mq.c | 29 +++++++- crypto/Makefile | 1 + drivers/acpi/acpi_video.c | 14 +++- drivers/acpi/ec.c | 2 +- drivers/acpi/ec_sys.c | 2 +- drivers/acpi/internal.h | 2 +- drivers/bluetooth/btusb.c | 1 + drivers/char/tpm/tpm-interface.c | 28 +++++-- drivers/char/tpm/tpm.h | 5 ++ drivers/clk/clk-divider.c | 7 +- drivers/clk/hisilicon/clkdivider-hi6220.c | 2 +- drivers/clk/meson/clk-mpll.c | 2 +- drivers/clk/nxp/clk-lpc32xx.c | 2 +- drivers/clk/qcom/clk-regmap-divider.c | 2 +- drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 4 +- drivers/clk/sunxi-ng/ccu-sun8i-de2.c | 6 +- drivers/clk/sunxi-ng/ccu_div.c | 2 +- drivers/cpufreq/powernv-cpufreq.c | 37 +++++---- drivers/devfreq/devfreq.c | 3 +- drivers/edac/mv64x60_edac.c | 2 +- drivers/gpio/gpio-thunderx.c | 4 +- drivers/gpio/gpiolib.c | 3 +- drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c | 2 +- drivers/hwmon/ina2xx.c | 87 +++++++++++++--------- drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c | 2 +- drivers/infiniband/core/cma.c | 1 + drivers/infiniband/core/ucma.c | 7 +- drivers/infiniband/hw/i40iw/i40iw_cm.c | 5 +- drivers/infiniband/hw/i40iw/i40iw_ctrl.c | 6 +- drivers/infiniband/hw/i40iw/i40iw_d.h | 1 + drivers/infiniband/hw/i40iw/i40iw_puda.c | 2 +- drivers/infiniband/sw/rdmavt/cq.c | 10 ++- drivers/input/touchscreen/goodix.c | 8 +- drivers/irqchip/irq-gic-v3.c | 11 +++ drivers/md/bcache/alloc.c | 19 +++-- drivers/md/bcache/request.c | 22 ++++++ drivers/md/bcache/super.c | 6 ++ drivers/media/v4l2-core/videobuf2-core.c | 4 + drivers/mmc/host/sdhci-pci-core.c | 2 + drivers/mmc/host/sdhci.c | 7 ++ drivers/mtd/tests/oobtest.c | 21 ++++++ drivers/net/ethernet/chelsio/cxgb4vf/sge.c | 23 ++++-- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 4 + .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 17 ++++- .../ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c | 13 ++-- drivers/net/ethernet/ibm/ibmvnic.c | 6 ++ drivers/net/ethernet/intel/i40evf/i40evf_main.c | 20 ++++- drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c | 5 ++ drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 7 ++ drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 + drivers/net/ethernet/mellanox/mlx5/core/vport.c | 33 ++++++-- drivers/net/wireless/ralink/rt2x00/rt2x00mac.c | 22 ++++-- drivers/net/wireless/ti/wl1251/main.c | 3 +- drivers/nvme/target/fcloop.c | 47 ++++++++---- drivers/pinctrl/intel/pinctrl-baytrail.c | 6 ++ drivers/power/supply/axp288_charger.c | 13 ++++ drivers/rtc/rtc-ac100.c | 6 +- drivers/scsi/libiscsi.c | 24 +++++- drivers/scsi/libsas/sas_expander.c | 4 +- drivers/scsi/megaraid/megaraid_sas_base.c | 2 +- drivers/scsi/megaraid/megaraid_sas_fp.c | 16 +++- drivers/scsi/mpt3sas/mpt3sas_scsih.c | 28 +++---- drivers/scsi/qla2xxx/qla_init.c | 13 +++- drivers/spi/spi-sh-msiof.c | 12 ++- .../staging/lustre/lnet/libcfs/linux/linux-cpu.c | 13 ++-- drivers/target/target_core_user.c | 7 ++ drivers/thermal/int340x_thermal/int3400_thermal.c | 10 ++- drivers/thermal/power_allocator.c | 2 + drivers/tty/n_gsm.c | 17 ++++- drivers/uio/uio_hv_generic.c | 7 ++ drivers/video/backlight/corgi_lcd.c | 2 +- drivers/video/backlight/tdo24m.c | 2 +- drivers/video/backlight/tosa_lcd.c | 2 +- drivers/video/fbdev/vfb.c | 17 +++++ drivers/watchdog/dw_wdt.c | 18 ++++- fs/dcache.c | 23 ++++-- include/linux/clk-provider.h | 2 +- include/linux/mlx5/driver.h | 2 +- include/linux/netfilter.h | 1 + net/ipv4/netfilter/iptable_nat.c | 4 + net/ipv6/ip6_output.c | 8 ++ net/ipv6/netfilter/ip6table_nat.c | 4 + net/l2tp/l2tp_netlink.c | 2 + net/mac80211/cfg.c | 28 ++++++- net/mac80211/driver-ops.h | 3 +- net/netfilter/core.c | 6 ++ net/netfilter/nf_tables_api.c | 2 + net/rds/bind.c | 1 + sound/soc/intel/atom/sst/sst_stream.c | 2 +- sound/soc/intel/boards/cht_bsw_rt5645.c | 7 ++ sound/soc/intel/skylake/skl-messages.c | 4 + sound/soc/intel/skylake/skl-pcm.c | 4 + tools/perf/arch/powerpc/util/sym-handling.c | 8 ++ tools/perf/builtin-record.c | 4 +- tools/perf/builtin-report.c | 18 ++++- tools/perf/util/evsel.c | 47 +++++++++++- tools/perf/util/probe-event.c | 28 ++++++- tools/perf/util/symbol.c | 5 ++ tools/perf/util/symbol.h | 1 + tools/perf/util/util.c | 2 +- tools/testing/selftests/net/msg_zerocopy.c | 21 ++++-- 111 files changed, 913 insertions(+), 235 deletions(-) create mode 100644 arch/arm/include/uapi/asm/siginfo.h -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE4n5dijQDou9mhzu83qZv95d3LNwFAlrFwP4ACgkQ3qZv95d3 LNy4PA/+MH4fZECGWKXQd+KzRkbeAdSAcASVZnjmNFleQKEfY8e45EgOSYgGOXdi qZ2y6PJHSTiv/dPy3+h9tPppb/8AkOw51zwWQVK1WRm+jEzn7Lajcho84LwfWxV7 umO82Xam2SFa7SjaLDxFrh2gAunkh8jdpEdqvqCd9n2FOFuBVLODkqvDfHoUcWrU dl5XZXZ13/H0Lvw9dnlEZyarwiquZY5ayWiMKZsRVea7WJTmuQ22nyjpH+b7KxFQ rmxJcAjNpsWeieMaB80wWhJFvH72rJJ6edcR/+vTIbTqgvJNi4UiSWK5hxO0VrMQ JGHm5c4IFGZcI+05QEzFBWurLVV1b6Oc6zKZuNcqM4XMI3ll4ykYhcM7/1xi3UK6 8QdRPMBGlAu1GzgqaI1qcd4wEqBgGRL7smbuO4htFlgyOdVFB7ivnU0FW5ioDob4 WhMY7fnuJbV1rT32yEpAJnIElqx8cIXOMKB2E8e3RBxylucF3p6kvNhE3irm9B1B HJPPm01osZDM7DwvpYRjiTqnEWld/3MDByaYsx65oEjLYQ87MGINrvH7B7WKO7Se Rkww8M46ZJvBHGL/Dr0FpAo5RtyOKBzZAFf6bEpRxa9yidoCyJbU1QZ8n5fDraXh BJBU7MCN/XIjVVtMP8m6VhbcB1fYpcpLhGAys3Alj2xOZEv0ewc= =tzYe -----END PGP SIGNATURE-----

7 years, 2 months

2
1
0 0

Patch "irqchip/gic-v3: Fix the driver probe() fail due to disabled GICC entry" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled irqchip/gic-v3: Fix the driver probe() fail due to disabled GICC entry to the 4.14-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: irqchip-gic-v3-fix-the-driver-probe-fail-due-to-disabled-gicc-entry.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Shanker Donthineni <shankerd(a)codeaurora.org> Date: Tue, 5 Dec 2017 13:16:21 -0600 Subject: irqchip/gic-v3: Fix the driver probe() fail due to disabled GICC entry From: Shanker Donthineni <shankerd(a)codeaurora.org> [ Upstream commit ebe2f8718007d5a1238bb3cb8141b5bb2b4d5773 ] The ACPI specification says OS shouldn't attempt to use GICC configuration parameters if the flag ACPI_MADT_ENABLED is cleared. The ARM64-SMP code skips the disabled GICC entries but not causing any issue. However the current GICv3 driver probe bails out causing kernel panic() instead of skipping the disabled GICC interfaces. This issue happens on systems where redistributor regions are not in the always-on power domain and one of GICC interface marked with ACPI_MADT_ENABLED=0. This patch does the two things to fix the panic. - Don't return an error in gic_acpi_match_gicc() for disabled GICC entry. - No need to keep GICR region information for disabled GICC entry. Observed kernel crash on QDF2400 platform GICC entry is disabled. Kernel crash traces: Kernel panic - not syncing: No interrupt controller found. CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.13.5 #26 [<ffff000008087770>] dump_backtrace+0x0/0x218 [<ffff0000080879dc>] show_stack+0x14/0x20 [<ffff00000883b078>] dump_stack+0x98/0xb8 [<ffff0000080c5c14>] panic+0x118/0x26c [<ffff000008b62348>] init_IRQ+0x24/0x2c [<ffff000008b609fc>] start_kernel+0x230/0x394 [<ffff000008b601e4>] __primary_switched+0x64/0x6c ---[ end Kernel panic - not syncing: No interrupt controller found. Disabled GICC subtable example: Subtable Type : 0B [Generic Interrupt Controller] Length : 50 Reserved : 0000 CPU Interface Number : 0000003D Processor UID : 0000003D Flags (decoded below) : 00000000 Processor Enabled : 0 Performance Interrupt Trig Mode : 0 Virtual GIC Interrupt Trig Mode : 0 Parking Protocol Version : 00000000 Performance Interrupt : 00000017 Parked Address : 0000000000000000 Base Address : 0000000000000000 Virtual GIC Base Address : 0000000000000000 Hypervisor GIC Base Address : 0000000000000000 Virtual GIC Interrupt : 00000019 Redistributor Base Address : 0000FFFF88F40000 ARM MPIDR : 000000000000000D Efficiency Class : 00 Reserved : 000000 Signed-off-by: Shanker Donthineni <shankerd(a)codeaurora.org> Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/irqchip/irq-gic-v3.c | 11 +++++++++++ 1 file changed, 11 insertions(+) --- a/drivers/irqchip/irq-gic-v3.c +++ b/drivers/irqchip/irq-gic-v3.c @@ -1297,6 +1297,10 @@ gic_acpi_parse_madt_gicc(struct acpi_sub u32 size = reg == GIC_PIDR2_ARCH_GICv4 ? SZ_64K * 4 : SZ_64K * 2; void __iomem *redist_base; + /* GICC entry which has !ACPI_MADT_ENABLED is not unusable so skip */ + if (!(gicc->flags & ACPI_MADT_ENABLED)) + return 0; + redist_base = ioremap(gicc->gicr_base_address, size); if (!redist_base) return -ENOMEM; @@ -1346,6 +1350,13 @@ static int __init gic_acpi_match_gicc(st if ((gicc->flags & ACPI_MADT_ENABLED) && gicc->gicr_base_address) return 0; + /* + * It's perfectly valid firmware can pass disabled GICC entry, driver + * should not treat as errors, skip the entry instead of probe fail. + */ + if (!(gicc->flags & ACPI_MADT_ENABLED)) + return 0; + return -ENODEV; } Patches currently in stable-queue which might be from shankerd(a)codeaurora.org are queue-4.14/irqchip-gic-v3-fix-the-driver-probe-fail-due-to-disabled-gicc-entry.patch

7 years, 2 months

1
0
0 0

Patch "Input: goodix - disable IRQs while suspended" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Input: goodix - disable IRQs while suspended to the 4.14-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: input-goodix-disable-irqs-while-suspended.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Hans de Goede <hdegoede(a)redhat.com> Date: Fri, 12 Jan 2018 00:36:48 -0800 Subject: Input: goodix - disable IRQs while suspended From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit faec44b6838312484d63e82286087cf2d5ebb891 ] We should not try to do any i2c transfers before the controller is resumed (which happens before our resume method gets called). So we need to disable our IRQ while suspended to enforce this. The code paths for devices with GPIOs for the int and reset pins already disable the IRQ the through goodix_free_irq(). This commit also disables the IRQ while suspended for devices without GPIOs for the int and reset pins. This fixes the i2c bus sometimes getting stuck after a suspend/resume causing the touchscreen to sometimes not work after a suspend/resume. This has been tested on a GPD pocked device. BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10 BugLink: https://www.reddit.com/r/GPDPocket/comments/7niut2/fix_for_broken_touch_aft… Tested-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Reviewed-by: Bastien Nocera <hadess(a)hadess.net> Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/input/touchscreen/goodix.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/drivers/input/touchscreen/goodix.c +++ b/drivers/input/touchscreen/goodix.c @@ -808,8 +808,10 @@ static int __maybe_unused goodix_suspend int error; /* We need gpio pins to suspend/resume */ - if (!ts->gpiod_int || !ts->gpiod_rst) + if (!ts->gpiod_int || !ts->gpiod_rst) { + disable_irq(client->irq); return 0; + } wait_for_completion(&ts->firmware_loading_complete); @@ -849,8 +851,10 @@ static int __maybe_unused goodix_resume( struct goodix_ts_data *ts = i2c_get_clientdata(client); int error; - if (!ts->gpiod_int || !ts->gpiod_rst) + if (!ts->gpiod_int || !ts->gpiod_rst) { + enable_irq(client->irq); return 0; + } /* * Exit sleep mode by outputting HIGH level to INT pin Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.14/acpi-video-default-lcd_only-to-true-on-win8-ready-and-newer-machines.patch queue-4.14/input-goodix-disable-irqs-while-suspended.patch queue-4.14/asoc-intel-cht_bsw_rt5645-analog-mic-support.patch queue-4.14/power-supply-axp288_charger-properly-stop-work-on-probe-error-remove.patch queue-4.14/pinctrl-baytrail-enable-glitch-filter-for-gpios-used-as-interrupts.patch

7 years, 2 months

1
0
0 0

Patch "ipv6: Reinject IPv6 packets if IPsec policy matches after SNAT" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ipv6: Reinject IPv6 packets if IPsec policy matches after SNAT to the 4.14-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: ipv6-reinject-ipv6-packets-if-ipsec-policy-matches-after-snat.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Tobias Brunner <tobias(a)strongswan.org> Date: Thu, 21 Dec 2017 17:32:24 +0100 Subject: ipv6: Reinject IPv6 packets if IPsec policy matches after SNAT From: Tobias Brunner <tobias(a)strongswan.org> [ Upstream commit 09ee9dba9611cd382fd360a99ad1c2fa23bfdca8 ] If SNAT modifies the source address the resulting packet might match an IPsec policy, reinject the packet if that's the case. The exact same thing is already done for IPv4. Signed-off-by: Tobias Brunner <tobias(a)strongswan.org> Acked-by: Steffen Klassert <steffen.klassert(a)secunet.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv6/ip6_output.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -138,6 +138,14 @@ static int ip6_finish_output(struct net return ret; } +#if defined(CONFIG_NETFILTER) && defined(CONFIG_XFRM) + /* Policy lookup after SNAT yielded a new policy */ + if (skb_dst(skb)->xfrm) { + IPCB(skb)->flags |= IPSKB_REROUTED; + return dst_output(net, sk, skb); + } +#endif + if ((skb->len > ip6_skb_dst_mtu(skb) && !skb_is_gso(skb)) || dst_allfrag(skb_dst(skb)) || (IP6CB(skb)->frag_max_size && skb->len > IP6CB(skb)->frag_max_size)) Patches currently in stable-queue which might be from tobias(a)strongswan.org are queue-4.14/ipv6-reinject-ipv6-packets-if-ipsec-policy-matches-after-snat.patch

7 years, 2 months

1
0
0 0

Patch "IB/rdmavt: Allocate CQ memory on the correct node" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/rdmavt: Allocate CQ memory on the correct node to the 4.14-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-rdmavt-allocate-cq-memory-on-the-correct-node.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Mike Marciniszyn <mike.marciniszyn(a)intel.com> Date: Mon, 18 Dec 2017 19:57:06 -0800 Subject: IB/rdmavt: Allocate CQ memory on the correct node From: Mike Marciniszyn <mike.marciniszyn(a)intel.com> [ Upstream commit db9a2c6f9b6196b889b98e961cb9a37617b11ccf ] CQ allocation does not ensure that completion queue entries and the completion queue structure are allocated on the correct numa node. Fix by allocating the rvt_cq and kernel CQ entries on the device node, leaving the user CQ entries on the default local node. Also ensure CQ resizes use the correct allocator when extending a CQ. Reviewed-by: Sebastian Sanchez <sebastian.sanchez(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: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/sw/rdmavt/cq.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) --- a/drivers/infiniband/sw/rdmavt/cq.c +++ b/drivers/infiniband/sw/rdmavt/cq.c @@ -198,7 +198,7 @@ struct ib_cq *rvt_create_cq(struct ib_de return ERR_PTR(-EINVAL); /* Allocate the completion queue structure. */ - cq = kzalloc(sizeof(*cq), GFP_KERNEL); + cq = kzalloc_node(sizeof(*cq), GFP_KERNEL, rdi->dparms.node); if (!cq) return ERR_PTR(-ENOMEM); @@ -214,7 +214,9 @@ struct ib_cq *rvt_create_cq(struct ib_de sz += sizeof(struct ib_uverbs_wc) * (entries + 1); else sz += sizeof(struct ib_wc) * (entries + 1); - wc = vmalloc_user(sz); + wc = udata ? + vmalloc_user(sz) : + vzalloc_node(sz, rdi->dparms.node); if (!wc) { ret = ERR_PTR(-ENOMEM); goto bail_cq; @@ -369,7 +371,9 @@ int rvt_resize_cq(struct ib_cq *ibcq, in sz += sizeof(struct ib_uverbs_wc) * (cqe + 1); else sz += sizeof(struct ib_wc) * (cqe + 1); - wc = vmalloc_user(sz); + wc = udata ? + vmalloc_user(sz) : + vzalloc_node(sz, rdi->dparms.node); if (!wc) return -ENOMEM; Patches currently in stable-queue which might be from mike.marciniszyn(a)intel.com are queue-4.14/ib-rdmavt-allocate-cq-memory-on-the-correct-node.patch

7 years, 2 months

1
0
0 0

Patch "ibmvnic: Don't handle RX interrupts when not up." has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ibmvnic: Don't handle RX interrupts when not up. to the 4.14-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: ibmvnic-don-t-handle-rx-interrupts-when-not-up.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Nathan Fontenot <nfont(a)linux.vnet.ibm.com> Date: Wed, 10 Jan 2018 10:40:09 -0600 Subject: ibmvnic: Don't handle RX interrupts when not up. From: Nathan Fontenot <nfont(a)linux.vnet.ibm.com> [ Upstream commit 09fb35ead58cd557aa9b20576d15816bc91a4deb ] Initiating a kdump via the command line can cause a pending interrupt to be handled by the ibmvnic driver when initializing the sub-CRQ irqs during driver initialization. NIP [d000000000ca34f0] ibmvnic_interrupt_rx+0x40/0xd0 [ibmvnic] LR [c000000008132ef0] __handle_irq_event_percpu+0xa0/0x2f0 Call Trace: [c000000047fcfde0] [c000000008132ef0] __handle_irq_event_percpu+0xa0/0x2f0 [c000000047fcfea0] [c00000000813317c] handle_irq_event_percpu+0x3c/0x90 [c000000047fcfee0] [c00000000813323c] handle_irq_event+0x6c/0xd0 [c000000047fcff10] [c0000000081385e0] handle_fasteoi_irq+0xf0/0x250 [c000000047fcff40] [c0000000081320a0] generic_handle_irq+0x50/0x80 [c000000047fcff60] [c000000008014984] __do_irq+0x84/0x1d0 [c000000047fcff90] [c000000008027564] call_do_irq+0x14/0x24 [c00000003c92af00] [c000000008014b70] do_IRQ+0xa0/0x120 [c00000003c92af50] [c000000008002594] hardware_interrupt_common+0x114/0x180 Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/ibm/ibmvnic.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/net/ethernet/ibm/ibmvnic.c +++ b/drivers/net/ethernet/ibm/ibmvnic.c @@ -2209,6 +2209,12 @@ static irqreturn_t ibmvnic_interrupt_rx( struct ibmvnic_sub_crq_queue *scrq = instance; struct ibmvnic_adapter *adapter = scrq->adapter; + /* When booting a kdump kernel we can hit pending interrupts + * prior to completing driver initialization. + */ + if (unlikely(adapter->state != VNIC_OPEN)) + return IRQ_NONE; + adapter->rx_stats_buffers[scrq->scrq_num].interrupts++; if (napi_schedule_prep(&adapter->napi[scrq->scrq_num])) { Patches currently in stable-queue which might be from nfont(a)linux.vnet.ibm.com are queue-4.14/ibmvnic-don-t-handle-rx-interrupts-when-not-up.patch

7 years, 2 months

1
0
0 0

Patch "i40iw: Fix sequence number for the first partial FPDU" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled i40iw: Fix sequence number for the first partial FPDU to the 4.14-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: i40iw-fix-sequence-number-for-the-first-partial-fpdu.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Shiraz Saleem <shiraz.saleem(a)intel.com> Date: Fri, 22 Dec 2017 09:46:59 -0600 Subject: i40iw: Fix sequence number for the first partial FPDU From: Shiraz Saleem <shiraz.saleem(a)intel.com> [ Upstream commit df8b13a1b23356d01dfc4647a5629cdb0f4ce566 ] Partial FPDU processing is broken as the sequence number for the first partial FPDU is wrong due to incorrect Q2 buffer offset. The offset should be 64 rather than 16. Fixes: 786c6adb3a94 ("i40iw: add puda code") Signed-off-by: Shiraz Saleem <shiraz.saleem(a)intel.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/i40iw/i40iw_d.h | 1 + drivers/infiniband/hw/i40iw/i40iw_puda.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) --- a/drivers/infiniband/hw/i40iw/i40iw_d.h +++ b/drivers/infiniband/hw/i40iw/i40iw_d.h @@ -93,6 +93,7 @@ #define RDMA_OPCODE_MASK 0x0f #define RDMA_READ_REQ_OPCODE 1 #define Q2_BAD_FRAME_OFFSET 72 +#define Q2_FPSN_OFFSET 64 #define CQE_MAJOR_DRV 0x8000 #define I40IW_TERM_SENT 0x01 --- a/drivers/infiniband/hw/i40iw/i40iw_puda.c +++ b/drivers/infiniband/hw/i40iw/i40iw_puda.c @@ -1376,7 +1376,7 @@ static void i40iw_ieq_handle_exception(s u32 *hw_host_ctx = (u32 *)qp->hw_host_ctx; u32 rcv_wnd = hw_host_ctx[23]; /* first partial seq # in q2 */ - u32 fps = qp->q2_buf[16]; + u32 fps = *(u32 *)(qp->q2_buf + Q2_FPSN_OFFSET); struct list_head *rxlist = &pfpdu->rxlist; struct list_head *plist; Patches currently in stable-queue which might be from shiraz.saleem(a)intel.com are queue-4.14/i40iw-fix-sequence-number-for-the-first-partial-fpdu.patch queue-4.14/i40iw-correct-q1-xf-object-count-equation.patch queue-4.14/i40iw-validate-correct-ird-ord-connection-parameters.patch

7 years, 2 months

1
0
0 0

Patch "i40iw: Validate correct IRD/ORD connection parameters" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled i40iw: Validate correct IRD/ORD connection parameters to the 4.14-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: i40iw-validate-correct-ird-ord-connection-parameters.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Tatyana Nikolova <tatyana.e.nikolova(a)intel.com> Date: Fri, 22 Dec 2017 09:47:01 -0600 Subject: i40iw: Validate correct IRD/ORD connection parameters From: Tatyana Nikolova <tatyana.e.nikolova(a)intel.com> [ Upstream commit ce9ce74145aa6814a370a9ff4f5a1d719baaced1 ] Casting to u16 before validating IRD/ORD connection parameters could cause recording wrong IRD/ORD values in the cm_node. Validate the IRD/ORD parameters as they are passed by the application before recording them. Fixes: f27b4746f378 ("i40iw: add connection management code") Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova(a)intel.com> Signed-off-by: Shiraz Saleem <shiraz.saleem(a)intel.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/i40iw/i40iw_cm.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/drivers/infiniband/hw/i40iw/i40iw_cm.c +++ b/drivers/infiniband/hw/i40iw/i40iw_cm.c @@ -125,7 +125,8 @@ static u8 i40iw_derive_hw_ird_setting(u1 * @conn_ird: connection IRD * @conn_ord: connection ORD */ -static void i40iw_record_ird_ord(struct i40iw_cm_node *cm_node, u16 conn_ird, u16 conn_ord) +static void i40iw_record_ird_ord(struct i40iw_cm_node *cm_node, u32 conn_ird, + u32 conn_ord) { if (conn_ird > I40IW_MAX_IRD_SIZE) conn_ird = I40IW_MAX_IRD_SIZE; @@ -3841,7 +3842,7 @@ int i40iw_connect(struct iw_cm_id *cm_id } cm_node->apbvt_set = true; - i40iw_record_ird_ord(cm_node, (u16)conn_param->ird, (u16)conn_param->ord); + i40iw_record_ird_ord(cm_node, conn_param->ird, conn_param->ord); if (cm_node->send_rdma0_op == SEND_RDMA_READ_ZERO && !cm_node->ord_size) cm_node->ord_size = 1; Patches currently in stable-queue which might be from tatyana.e.nikolova(a)intel.com are queue-4.14/i40iw-validate-correct-ird-ord-connection-parameters.patch

7 years, 2 months

1
0
0 0

Patch "i40evf: don't rely on netif_running() outside rtnl_lock()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled i40evf: don't rely on netif_running() outside rtnl_lock() to the 4.14-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: i40evf-don-t-rely-on-netif_running-outside-rtnl_lock.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Jacob Keller <jacob.e.keller(a)intel.com> Date: Fri, 27 Oct 2017 11:06:49 -0400 Subject: i40evf: don't rely on netif_running() outside rtnl_lock() From: Jacob Keller <jacob.e.keller(a)intel.com> [ Upstream commit 44b034b406211fc103159f82b9e601e05675c739 ] In i40evf_reset_task we use netif_running() to determine whether or not the device is currently up. This allows us to properly free queue memory and shut down things before we request the hardware reset. It turns out that we cannot be guaranteed of netif_running() returning false until the device is fully up, as the kernel core code sets __LINK_STATE_START prior to calling .ndo_open. Since we're not holding the rtnl_lock(), it's possible that the driver's i40evf_open handler function is currently being called while we're resetting. We can't simply hold the rtnl_lock() while checking netif_running() as this could cause a deadlock with the i40evf_open() function. Additionally, we can't avoid the deadlock by holding the rtnl_lock() over the whole reset path, as this essentially serializes all resets, and can cause massive delays if we have multiple VFs on a system. Instead, lets just check our own internal state __I40EVF_RUNNING state field. This allows us to ensure that the state is correct and is only set after we've finished bringing the device up. Without this change we might free data structures about device queues and other memory before they've been fully allocated. Signed-off-by: Jacob Keller <jacob.e.keller(a)intel.com> Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/i40evf/i40evf_main.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c +++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c @@ -1775,7 +1775,11 @@ static void i40evf_disable_vf(struct i40 adapter->flags |= I40EVF_FLAG_PF_COMMS_FAILED; - if (netif_running(adapter->netdev)) { + /* We don't use netif_running() because it may be true prior to + * ndo_open() returning, so we can't assume it means all our open + * tasks have finished, since we're not holding the rtnl_lock here. + */ + if (adapter->state == __I40EVF_RUNNING) { set_bit(__I40E_VSI_DOWN, adapter->vsi.state); netif_carrier_off(adapter->netdev); netif_tx_disable(adapter->netdev); @@ -1833,6 +1837,7 @@ static void i40evf_reset_task(struct wor struct i40evf_mac_filter *f; u32 reg_val; int i = 0, err; + bool running; while (test_and_set_bit(__I40EVF_IN_CLIENT_TASK, &adapter->crit_section)) @@ -1892,7 +1897,13 @@ static void i40evf_reset_task(struct wor } continue_reset: - if (netif_running(netdev)) { + /* We don't use netif_running() because it may be true prior to + * ndo_open() returning, so we can't assume it means all our open + * tasks have finished, since we're not holding the rtnl_lock here. + */ + running = (adapter->state == __I40EVF_RUNNING); + + if (running) { netif_carrier_off(netdev); netif_tx_stop_all_queues(netdev); adapter->link_up = false; @@ -1936,7 +1947,10 @@ continue_reset: mod_timer(&adapter->watchdog_timer, jiffies + 2); - if (netif_running(adapter->netdev)) { + /* We were running when the reset started, so we need to restore some + * state here. + */ + if (running) { /* allocate transmit descriptors */ err = i40evf_setup_all_tx_resources(adapter); if (err) Patches currently in stable-queue which might be from jacob.e.keller(a)intel.com are queue-4.14/i40evf-don-t-rely-on-netif_running-outside-rtnl_lock.patch

7 years, 2 months

1
0
0 0

Patch "i40iw: Correct Q1/XF object count equation" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled i40iw: Correct Q1/XF object count equation to the 4.14-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: i40iw-correct-q1-xf-object-count-equation.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Shiraz Saleem <shiraz.saleem(a)intel.com> Date: Fri, 22 Dec 2017 09:46:56 -0600 Subject: i40iw: Correct Q1/XF object count equation From: Shiraz Saleem <shiraz.saleem(a)intel.com> [ Upstream commit fe99afd1febd74e0ef1fed7e3283f09effe1f4f0 ] Lower Inbound RDMA Read Queue (Q1) object count by a factor of 2 as it is incorrectly doubled. Also, round up Q1 and Transmit FIFO (XF) object count to power of 2 to satisfy hardware requirement. Fixes: 86dbcd0f12e9 ("i40iw: add file to handle cqp calls") Signed-off-by: Shiraz Saleem <shiraz.saleem(a)intel.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/i40iw/i40iw_ctrl.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/infiniband/hw/i40iw/i40iw_ctrl.c +++ b/drivers/infiniband/hw/i40iw/i40iw_ctrl.c @@ -3875,8 +3875,10 @@ enum i40iw_status_code i40iw_config_fpm_ hmc_info->hmc_obj[I40IW_HMC_IW_APBVT_ENTRY].cnt = 1; hmc_info->hmc_obj[I40IW_HMC_IW_MR].cnt = mrwanted; - hmc_info->hmc_obj[I40IW_HMC_IW_XF].cnt = I40IW_MAX_WQ_ENTRIES * qpwanted; - hmc_info->hmc_obj[I40IW_HMC_IW_Q1].cnt = 4 * I40IW_MAX_IRD_SIZE * qpwanted; + hmc_info->hmc_obj[I40IW_HMC_IW_XF].cnt = + roundup_pow_of_two(I40IW_MAX_WQ_ENTRIES * qpwanted); + hmc_info->hmc_obj[I40IW_HMC_IW_Q1].cnt = + roundup_pow_of_two(2 * I40IW_MAX_IRD_SIZE * qpwanted); hmc_info->hmc_obj[I40IW_HMC_IW_XFFL].cnt = hmc_info->hmc_obj[I40IW_HMC_IW_XF].cnt / hmc_fpm_misc->xf_block_size; hmc_info->hmc_obj[I40IW_HMC_IW_Q1FL].cnt = Patches currently in stable-queue which might be from shiraz.saleem(a)intel.com are queue-4.14/i40iw-fix-sequence-number-for-the-first-partial-fpdu.patch queue-4.14/i40iw-correct-q1-xf-object-count-equation.patch queue-4.14/i40iw-validate-correct-ird-ord-connection-parameters.patch

7 years, 2 months

1
0
0 0

Patch "hwmon: (ina2xx) Make calibration register value fixed" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled hwmon: (ina2xx) Make calibration register value fixed to the 4.14-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: hwmon-ina2xx-make-calibration-register-value-fixed.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Maciej Purski <m.purski(a)samsung.com> Date: Wed, 22 Nov 2017 16:32:15 +0100 Subject: hwmon: (ina2xx) Make calibration register value fixed From: Maciej Purski <m.purski(a)samsung.com> [ Upstream commit 5d389b125186cf254ad5b8015763ac07c151aea4 ] Calibration register is used for calculating current register in hardware according to datasheet: current = shunt_volt * calib_register / 2048 (ina 226) current = shunt_volt * calib_register / 4096 (ina 219) Fix calib_register value to 2048 for ina226 and 4096 for ina 219 in order to avoid truncation error and provide best precision allowed by shunt_voltage measurement. Make current scale value follow changes of shunt_resistor from sysfs as calib_register value is now fixed. Power_lsb value should also follow shunt_resistor changes as stated in datasheet: power_lsb = 25 * current_lsb (ina 226) power_lsb = 20 * current_lsb (ina 219) Signed-off-by: Maciej Purski <m.purski(a)samsung.com> Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hwmon/ina2xx.c | 87 ++++++++++++++++++++++++++++--------------------- 1 file changed, 50 insertions(+), 37 deletions(-) --- a/drivers/hwmon/ina2xx.c +++ b/drivers/hwmon/ina2xx.c @@ -95,18 +95,20 @@ enum ina2xx_ids { ina219, ina226 }; struct ina2xx_config { u16 config_default; - int calibration_factor; + int calibration_value; int registers; int shunt_div; int bus_voltage_shift; int bus_voltage_lsb; /* uV */ - int power_lsb; /* uW */ + int power_lsb_factor; }; struct ina2xx_data { const struct ina2xx_config *config; long rshunt; + long current_lsb_uA; + long power_lsb_uW; struct mutex config_lock; struct regmap *regmap; @@ -116,21 +118,21 @@ struct ina2xx_data { static const struct ina2xx_config ina2xx_config[] = { [ina219] = { .config_default = INA219_CONFIG_DEFAULT, - .calibration_factor = 40960000, + .calibration_value = 4096, .registers = INA219_REGISTERS, .shunt_div = 100, .bus_voltage_shift = 3, .bus_voltage_lsb = 4000, - .power_lsb = 20000, + .power_lsb_factor = 20, }, [ina226] = { .config_default = INA226_CONFIG_DEFAULT, - .calibration_factor = 5120000, + .calibration_value = 2048, .registers = INA226_REGISTERS, .shunt_div = 400, .bus_voltage_shift = 0, .bus_voltage_lsb = 1250, - .power_lsb = 25000, + .power_lsb_factor = 25, }, }; @@ -169,12 +171,16 @@ static u16 ina226_interval_to_reg(int in return INA226_SHIFT_AVG(avg_bits); } +/* + * Calibration register is set to the best value, which eliminates + * truncation errors on calculating current register in hardware. + * According to datasheet (eq. 3) the best values are 2048 for + * ina226 and 4096 for ina219. They are hardcoded as calibration_value. + */ static int ina2xx_calibrate(struct ina2xx_data *data) { - u16 val = DIV_ROUND_CLOSEST(data->config->calibration_factor, - data->rshunt); - - return regmap_write(data->regmap, INA2XX_CALIBRATION, val); + return regmap_write(data->regmap, INA2XX_CALIBRATION, + data->config->calibration_value); } /* @@ -187,10 +193,6 @@ static int ina2xx_init(struct ina2xx_dat if (ret < 0) return ret; - /* - * Set current LSB to 1mA, shunt is in uOhms - * (equation 13 in datasheet). - */ return ina2xx_calibrate(data); } @@ -268,15 +270,15 @@ static int ina2xx_get_value(struct ina2x val = DIV_ROUND_CLOSEST(val, 1000); break; case INA2XX_POWER: - val = regval * data->config->power_lsb; + val = regval * data->power_lsb_uW; break; case INA2XX_CURRENT: - /* signed register, LSB=1mA (selected), in mA */ - val = (s16)regval; + /* signed register, result in mA */ + val = regval * data->current_lsb_uA; + val = DIV_ROUND_CLOSEST(val, 1000); break; case INA2XX_CALIBRATION: - val = DIV_ROUND_CLOSEST(data->config->calibration_factor, - regval); + val = regval; break; default: /* programmer goofed */ @@ -304,9 +306,32 @@ static ssize_t ina2xx_show_value(struct ina2xx_get_value(data, attr->index, regval)); } -static ssize_t ina2xx_set_shunt(struct device *dev, - struct device_attribute *da, - const char *buf, size_t count) +/* + * In order to keep calibration register value fixed, the product + * of current_lsb and shunt_resistor should also be fixed and equal + * to shunt_voltage_lsb = 1 / shunt_div multiplied by 10^9 in order + * to keep the scale. + */ +static int ina2xx_set_shunt(struct ina2xx_data *data, long val) +{ + unsigned int dividend = DIV_ROUND_CLOSEST(1000000000, + data->config->shunt_div); + if (val <= 0 || val > dividend) + return -EINVAL; + + mutex_lock(&data->config_lock); + data->rshunt = val; + data->current_lsb_uA = DIV_ROUND_CLOSEST(dividend, val); + data->power_lsb_uW = data->config->power_lsb_factor * + data->current_lsb_uA; + mutex_unlock(&data->config_lock); + + return 0; +} + +static ssize_t ina2xx_store_shunt(struct device *dev, + struct device_attribute *da, + const char *buf, size_t count) { unsigned long val; int status; @@ -316,18 +341,9 @@ static ssize_t ina2xx_set_shunt(struct d if (status < 0) return status; - if (val == 0 || - /* Values greater than the calibration factor make no sense. */ - val > data->config->calibration_factor) - return -EINVAL; - - mutex_lock(&data->config_lock); - data->rshunt = val; - status = ina2xx_calibrate(data); - mutex_unlock(&data->config_lock); + status = ina2xx_set_shunt(data, val); if (status < 0) return status; - return count; } @@ -387,7 +403,7 @@ static SENSOR_DEVICE_ATTR(power1_input, /* shunt resistance */ static SENSOR_DEVICE_ATTR(shunt_resistor, S_IRUGO | S_IWUSR, - ina2xx_show_value, ina2xx_set_shunt, + ina2xx_show_value, ina2xx_store_shunt, INA2XX_CALIBRATION); /* update interval (ina226 only) */ @@ -448,10 +464,7 @@ static int ina2xx_probe(struct i2c_clien val = INA2XX_RSHUNT_DEFAULT; } - if (val <= 0 || val > data->config->calibration_factor) - return -ENODEV; - - data->rshunt = val; + ina2xx_set_shunt(data, val); ina2xx_regmap_config.max_register = data->config->registers; Patches currently in stable-queue which might be from m.purski(a)samsung.com are queue-4.14/hwmon-ina2xx-make-calibration-register-value-fixed.patch

7 years, 2 months

1
0
0 0

Patch "gpio: thunderx: fix error return code in thunderx_gpio_probe()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled gpio: thunderx: fix error return code in thunderx_gpio_probe() to the 4.14-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: gpio-thunderx-fix-error-return-code-in-thunderx_gpio_probe.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Wei Yongjun <weiyongjun1(a)huawei.com> Date: Wed, 10 Jan 2018 14:37:13 +0000 Subject: gpio: thunderx: fix error return code in thunderx_gpio_probe() From: Wei Yongjun <weiyongjun1(a)huawei.com> [ Upstream commit 76e28f5ffed82b1e81a86c4eb8d0420515765620 ] Fix to return error code -ENOMEM from the error handling case instead of 0, as done elsewhere in this function. Fixes: 5a2a30024d8c ("gpio: Add gpio driver support for ThunderX and OCTEON-TX") Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com> Acked-by: David Daney <david.daney(a)cavium.com> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpio/gpio-thunderx.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/gpio/gpio-thunderx.c +++ b/drivers/gpio/gpio-thunderx.c @@ -566,8 +566,10 @@ static int thunderx_gpio_probe(struct pc txgpio->irqd = irq_domain_create_hierarchy(irq_get_irq_data(txgpio->msix_entries[0].vector)->domain, 0, 0, of_node_to_fwnode(dev->of_node), &thunderx_gpio_irqd_ops, txgpio); - if (!txgpio->irqd) + if (!txgpio->irqd) { + err = -ENOMEM; goto out; + } /* Push on irq_data and the domain for each line. */ for (i = 0; i < ngpio; i++) { Patches currently in stable-queue which might be from weiyongjun1(a)huawei.com are queue-4.14/gpio-thunderx-fix-error-return-code-in-thunderx_gpio_probe.patch

7 years, 2 months

1
0
0 0

Patch "gpio: label descriptors using the device name" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled gpio: label descriptors using the device name to the 4.14-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: gpio-label-descriptors-using-the-device-name.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Linus Walleij <linus.walleij(a)linaro.org> Date: Thu, 4 Jan 2018 22:31:11 +0100 Subject: gpio: label descriptors using the device name From: Linus Walleij <linus.walleij(a)linaro.org> [ Upstream commit 24e78079bf2250874e33da2e7cfbb6db72d3caf4 ] Some GPIO lines appear named "?" in the lsgpio dump due to their requesting drivers not passing a reasonable label. Most typically this happens if a device tree node just defines gpios = <...> and not foo-gpios = <...>, the former gets named "foo" and the latter gets named "?". However the struct device passed in is always valid so let's just label the GPIO with dev_name() on the device if no proper label was passed. Cc: Reported-by: Jason Kridner <jkridner(a)beagleboard.org> Reported-by: Jason Kridner <jkridner(a)beagleboard.org> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpio/gpiolib.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -3340,7 +3340,8 @@ struct gpio_desc *__must_check gpiod_get return desc; } - status = gpiod_request(desc, con_id); + /* If a connection label was passed use that, else use the device name as label */ + status = gpiod_request(desc, con_id ? con_id : dev_name(dev)); if (status < 0) return ERR_PTR(status); Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are queue-4.14/gpio-label-descriptors-using-the-device-name.patch queue-4.14/gpio-thunderx-fix-error-return-code-in-thunderx_gpio_probe.patch queue-4.14/pinctrl-baytrail-enable-glitch-filter-for-gpios-used-as-interrupts.patch

7 years, 2 months

1
0
0 0

Patch "EDAC, mv64x60: Fix an error handling path" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled EDAC, mv64x60: Fix an error handling path to the 4.14-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: edac-mv64x60-fix-an-error-handling-path.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Sun, 7 Jan 2018 21:54:00 +0100 Subject: EDAC, mv64x60: Fix an error handling path From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> [ Upstream commit 68fa24f9121c04ef146b5158f538c8b32f285be5 ] We should not call edac_mc_del_mc() if a corresponding call to edac_mc_add_mc() has not been performed yet. So here, we should go to err instead of err2 to branch at the right place of the error handling path. Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Cc: linux-edac <linux-edac(a)vger.kernel.org> Link: http://lkml.kernel.org/r/20180107205400.14068-1-christophe.jaillet@wanadoo.… Signed-off-by: Borislav Petkov <bp(a)suse.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/edac/mv64x60_edac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/edac/mv64x60_edac.c +++ b/drivers/edac/mv64x60_edac.c @@ -758,7 +758,7 @@ static int mv64x60_mc_err_probe(struct p /* Non-ECC RAM? */ printk(KERN_WARNING "%s: No ECC DIMMs discovered\n", __func__); res = -ENODEV; - goto err2; + goto err; } edac_dbg(3, "init mci\n"); Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-4.14/edac-mv64x60-fix-an-error-handling-path.patch queue-4.14/asoc-intel-sst-fix-the-return-value-of-sst_send_byte_stream_mrfld.patch

7 years, 2 months

1
0
0 0

Patch "cxgb4vf: Fix SGE FL buffer initialization logic for 64K pages" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled cxgb4vf: Fix SGE FL buffer initialization logic for 64K pages to the 4.14-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: cxgb4vf-fix-sge-fl-buffer-initialization-logic-for-64k-pages.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Arjun Vynipadath <arjun(a)chelsio.com> Date: Wed, 10 Jan 2018 12:02:13 +0530 Subject: cxgb4vf: Fix SGE FL buffer initialization logic for 64K pages From: Arjun Vynipadath <arjun(a)chelsio.com> [ Upstream commit ea0a42109aee7b92e631c4eb3f2219fadf58acdd ] We'd come in with SGE_FL_BUFFER_SIZE[0] and [1] both equal to 64KB and the extant logic would flag that as an error. This was already fixed in cxgb4 driver with "92ddcc7 cxgb4: Fix some small bugs in t4_sge_init_soft() when our Page Size is 64KB". Original Work by: Casey Leedom <leedom(a)chelsio.com> Signed-off-by: Arjun Vynipadath <arjun(a)chelsio.com> Signed-off-by: Ganesh Goudar <ganeshgr(a)chelsio.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/chelsio/cxgb4vf/sge.c | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) --- a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c +++ b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c @@ -2619,8 +2619,8 @@ void t4vf_sge_stop(struct adapter *adapt int t4vf_sge_init(struct adapter *adapter) { struct sge_params *sge_params = &adapter->params.sge; - u32 fl0 = sge_params->sge_fl_buffer_size[0]; - u32 fl1 = sge_params->sge_fl_buffer_size[1]; + u32 fl_small_pg = sge_params->sge_fl_buffer_size[0]; + u32 fl_large_pg = sge_params->sge_fl_buffer_size[1]; struct sge *s = &adapter->sge; /* @@ -2628,9 +2628,20 @@ int t4vf_sge_init(struct adapter *adapte * the Physical Function Driver. Ideally we should be able to deal * with _any_ configuration. Practice is different ... */ - if (fl0 != PAGE_SIZE || (fl1 != 0 && fl1 <= fl0)) { + + /* We only bother using the Large Page logic if the Large Page Buffer + * is larger than our Page Size Buffer. + */ + if (fl_large_pg <= fl_small_pg) + fl_large_pg = 0; + + /* The Page Size Buffer must be exactly equal to our Page Size and the + * Large Page Size Buffer should be 0 (per above) or a power of 2. + */ + if (fl_small_pg != PAGE_SIZE || + (fl_large_pg & (fl_large_pg - 1)) != 0) { dev_err(adapter->pdev_dev, "bad SGE FL buffer sizes [%d, %d]\n", - fl0, fl1); + fl_small_pg, fl_large_pg); return -EINVAL; } if ((sge_params->sge_control & RXPKTCPLMODE_F) != @@ -2642,8 +2653,8 @@ int t4vf_sge_init(struct adapter *adapte /* * Now translate the adapter parameters into our internal forms. */ - if (fl1) - s->fl_pg_order = ilog2(fl1) - PAGE_SHIFT; + if (fl_large_pg) + s->fl_pg_order = ilog2(fl_large_pg) - PAGE_SHIFT; s->stat_len = ((sge_params->sge_control & EGRSTATUSPAGESIZE_F) ? 128 : 64); s->pktshift = PKTSHIFT_G(sge_params->sge_control); Patches currently in stable-queue which might be from arjun(a)chelsio.com are queue-4.14/cxgb4vf-fix-sge-fl-buffer-initialization-logic-for-64k-pages.patch

7 years, 2 months

1
0
0 0

Patch "crypto: aes-generic - build with -Os on gcc-7+" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: aes-generic - build with -Os on gcc-7+ to the 4.14-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: crypto-aes-generic-build-with-os-on-gcc-7.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Arnd Bergmann <arnd(a)arndb.de> Date: Wed, 3 Jan 2018 23:39:27 +0100 Subject: crypto: aes-generic - build with -Os on gcc-7+ From: Arnd Bergmann <arnd(a)arndb.de> [ Upstream commit 148b974deea927f5dbb6c468af2707b488bfa2de ] While testing other changes, I discovered that gcc-7.2.1 produces badly optimized code for aes_encrypt/aes_decrypt. This is especially true when CONFIG_UBSAN_SANITIZE_ALL is enabled, where it leads to extremely large stack usage that in turn might cause kernel stack overflows: crypto/aes_generic.c: In function 'aes_encrypt': crypto/aes_generic.c:1371:1: warning: the frame size of 4880 bytes is larger than 2048 bytes [-Wframe-larger-than=] crypto/aes_generic.c: In function 'aes_decrypt': crypto/aes_generic.c:1441:1: warning: the frame size of 4864 bytes is larger than 2048 bytes [-Wframe-larger-than=] I verified that this problem exists on all architectures that are supported by gcc-7.2, though arm64 in particular is less affected than the others. I also found that gcc-7.1 and gcc-8 do not show the extreme stack usage but still produce worse code than earlier versions for this file, apparently because of optimization passes that generally provide a substantial improvement in object code quality but understandably fail to find any shortcuts in the AES algorithm. Possible workarounds include a) disabling -ftree-pre and -ftree-sra optimizations, this was an earlier patch I tried, which reliably fixed the stack usage, but caused a serious performance regression in some versions, as later testing found. b) disabling UBSAN on this file or all ciphers, as suggested by Ard Biesheuvel. This would lead to massively better crypto performance in UBSAN-enabled kernels and avoid the stack usage, but there is a concern over whether we should exclude arbitrary files from UBSAN at all. c) Forcing the optimization level in a different way. Similar to a), but rather than deselecting specific optimization stages, this now uses "gcc -Os" for this file, regardless of the CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE/SIZE option. This is a reliable workaround for the stack consumption on all architecture, and I've retested the performance results now on x86, cycles/byte (lower is better) for cbc(aes-generic) with 256 bit keys: -O2 -Os gcc-6.3.1 14.9 15.1 gcc-7.0.1 14.7 15.3 gcc-7.1.1 15.3 14.7 gcc-7.2.1 16.8 15.9 gcc-8.0.0 15.5 15.6 This implements the option c) by enabling forcing -Os on all compiler versions starting with gcc-7.1. As a workaround for PR83356, it would only be needed for gcc-7.2+ with UBSAN enabled, but since it also shows better performance on gcc-7.1 without UBSAN, it seems appropriate to use the faster version here as well. Side note: during testing, I also played with the AES code in libressl, which had a similar performance regression from gcc-6 to gcc-7.2, but was three times slower overall. It might be interesting to investigate that further and possibly port the Linux implementation into that. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356 Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651 Cc: Richard Biener <rguenther(a)suse.de> Cc: Jakub Jelinek <jakub(a)gcc.gnu.org> Cc: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Acked-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- crypto/Makefile | 1 + 1 file changed, 1 insertion(+) --- a/crypto/Makefile +++ b/crypto/Makefile @@ -98,6 +98,7 @@ obj-$(CONFIG_CRYPTO_TWOFISH_COMMON) += t obj-$(CONFIG_CRYPTO_SERPENT) += serpent_generic.o CFLAGS_serpent_generic.o := $(call cc-option,-fsched-pressure) # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149 obj-$(CONFIG_CRYPTO_AES) += aes_generic.o +CFLAGS_aes_generic.o := $(call cc-ifversion, -ge, 0701, -Os) # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356 obj-$(CONFIG_CRYPTO_AES_TI) += aes_ti.o obj-$(CONFIG_CRYPTO_CAMELLIA) += camellia_generic.o obj-$(CONFIG_CRYPTO_CAST_COMMON) += cast_common.o Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.14/crypto-aes-generic-build-with-os-on-gcc-7.patch

7 years, 2 months

1
0
0 0

Patch "clk: sunxi-ng: a83t: Add M divider to TCON1 clock" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: sunxi-ng: a83t: Add M divider to TCON1 clock to the 4.14-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: clk-sunxi-ng-a83t-add-m-divider-to-tcon1-clock.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: "Jernej Škrabec" <jernej.skrabec(a)siol.net> Date: Sat, 30 Dec 2017 22:01:54 +0100 Subject: clk: sunxi-ng: a83t: Add M divider to TCON1 clock From: "Jernej Škrabec" <jernej.skrabec(a)siol.net> [ Upstream commit 7dbc7f5f4904cfddc199af171ea095490a434f15 ] TCON1 also has M divider, contrary to TCON0. And the mux is only 2 bits wide, instead of 3. Fixes: 05359be1176b ("clk: sunxi-ng: Add driver for A83T CCU") Signed-off-by: Jernej Skrabec <jernej.skrabec(a)siol.net> [wens(a)csie.org: Add description about mux width difference] Signed-off-by: Chen-Yu Tsai <wens(a)csie.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c @@ -493,8 +493,8 @@ static SUNXI_CCU_MUX_WITH_GATE(tcon0_clk 0x118, 24, 3, BIT(31), CLK_SET_RATE_PARENT); static const char * const tcon1_parents[] = { "pll-video1" }; -static SUNXI_CCU_MUX_WITH_GATE(tcon1_clk, "tcon1", tcon1_parents, - 0x11c, 24, 3, BIT(31), CLK_SET_RATE_PARENT); +static SUNXI_CCU_M_WITH_MUX_GATE(tcon1_clk, "tcon1", tcon1_parents, + 0x11c, 0, 4, 24, 2, BIT(31), CLK_SET_RATE_PARENT); static SUNXI_CCU_GATE(csi_misc_clk, "csi-misc", "osc24M", 0x130, BIT(16), 0); Patches currently in stable-queue which might be from jernej.skrabec(a)siol.net are queue-4.14/clk-sunxi-ng-a83t-add-m-divider-to-tcon1-clock.patch

7 years, 2 months

1
0
0 0

Patch "clk: sunxi-ng: fix the A64/H5 clock description of DE2 CCU" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: sunxi-ng: fix the A64/H5 clock description of DE2 CCU to the 4.14-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: clk-sunxi-ng-fix-the-a64-h5-clock-description-of-de2-ccu.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Icenowy Zheng <icenowy(a)aosc.io> Date: Fri, 22 Dec 2017 20:22:35 +0800 Subject: clk: sunxi-ng: fix the A64/H5 clock description of DE2 CCU From: Icenowy Zheng <icenowy(a)aosc.io> [ Upstream commit cf4881c1293516c1975606e8f2af7948789168b8 ] The clocks of A64/H5 SoCs in the DE2 CCU is the same as the clocks in H3 DE2 CCU rather than the A83T DE2 CCU (the parent of them is the DE module clock). Fix this by change the clock descriptions to use the clocks of H3. Fixes: 763c5bd045b1 ("clk: sunxi-ng: add support for DE2 CCU") Signed-off-by: Icenowy Zheng <icenowy(a)aosc.io> Signed-off-by: Chen-Yu Tsai <wens(a)csie.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/sunxi-ng/ccu-sun8i-de2.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/clk/sunxi-ng/ccu-sun8i-de2.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c @@ -129,10 +129,10 @@ static const struct sunxi_ccu_desc sun8i }; static const struct sunxi_ccu_desc sun50i_a64_de2_clk_desc = { - .ccu_clks = sun8i_a83t_de2_clks, - .num_ccu_clks = ARRAY_SIZE(sun8i_a83t_de2_clks), + .ccu_clks = sun8i_h3_de2_clks, + .num_ccu_clks = ARRAY_SIZE(sun8i_h3_de2_clks), - .hw_clks = &sun8i_a83t_de2_hw_clks, + .hw_clks = &sun8i_h3_de2_hw_clks, .resets = sun50i_a64_de2_resets, .num_resets = ARRAY_SIZE(sun50i_a64_de2_resets), Patches currently in stable-queue which might be from icenowy(a)aosc.io are queue-4.14/clk-sunxi-ng-fix-the-a64-h5-clock-description-of-de2-ccu.patch

7 years, 2 months

1
0
0 0

Patch "clk: meson: mpll: use 64-bit maths in params_from_rate" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: meson: mpll: use 64-bit maths in params_from_rate to the 4.14-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: clk-meson-mpll-use-64-bit-maths-in-params_from_rate.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> Date: Sat, 23 Dec 2017 22:38:32 +0100 Subject: clk: meson: mpll: use 64-bit maths in params_from_rate From: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> [ Upstream commit 86aacdca66774051cbc0958110a48074b57a060b ] "rem * SDM_DEN" can easily overflow on the 32-bit Meson8 and Meson8b SoCs if the "remainder" (after the division operation) is greater than 262143Hz. This is likely to happen since the input clock for the MPLLs on Meson8 and Meson8b is "fixed_pll", which is running at a rate of 2550MHz. One example where this was observed to be problematic was the Ethernet clock calculation (which takes MPLL2 as input). When requesting a rate of 125MHz there is a remainder of 2500000Hz. The resulting MPLL2 rate before this patch was 127488329Hz. The resulting MPLL2 rate after this patch is 124999103Hz. Commit b609338b26f5 ("clk: meson: mpll: use 64bit math in rate_from_params") already fixed a similar issue in rate_from_params. Fixes: 007e6e5c5f01d3 ("clk: meson: mpll: add rw operation") Signed-off-by: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/meson/clk-mpll.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/clk/meson/clk-mpll.c +++ b/drivers/clk/meson/clk-mpll.c @@ -98,7 +98,7 @@ static void params_from_rate(unsigned lo *sdm = SDM_DEN - 1; } else { *n2 = div; - *sdm = DIV_ROUND_UP(rem * SDM_DEN, requested_rate); + *sdm = DIV_ROUND_UP_ULL((u64)rem * SDM_DEN, requested_rate); } } Patches currently in stable-queue which might be from martin.blumenstingl(a)googlemail.com are queue-4.14/clk-meson-mpll-use-64-bit-maths-in-params_from_rate.patch

7 years, 2 months

1
0
0 0

Patch "Bluetooth: Add a new 04ca:3015 QCA_ROME device" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Bluetooth: Add a new 04ca:3015 QCA_ROME device to the 4.14-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: bluetooth-add-a-new-04ca-3015-qca_rome-device.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Ioan Moldovan <ioan.moldovan1999(a)gmail.com> Date: Mon, 28 Aug 2017 18:09:39 +0300 Subject: Bluetooth: Add a new 04ca:3015 QCA_ROME device From: Ioan Moldovan <ioan.moldovan1999(a)gmail.com> [ Upstream commit 0a03f98b98c201191e3ba15a0e33f46d8660e1fd ] This patch adds the 04ca:3015 (from a QCA9377 board) Bluetooth device to the btusb blacklist and makes the kernel use the btqca module instead of btusb. The patch is necessary because, without it the 04ca:3015 device defaults to using the btusb driver, which makes the WIFI side of the QCA9377 board unusable (obtains 0 MBps in speedtest, when the 04ca:3015 bluetooth is used with an audio headset). /sys/kernel/debug/usb/devices: T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3015 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Ioan Moldovan <ioan.moldovan1999(a)gmail.com> Signed-off-by: Johan Hedberg <johan.hedberg(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bluetooth/btusb.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -277,6 +277,7 @@ static const struct usb_device_id blackl { USB_DEVICE(0x0489, 0xe09f), .driver_info = BTUSB_QCA_ROME }, { USB_DEVICE(0x0489, 0xe0a2), .driver_info = BTUSB_QCA_ROME }, { USB_DEVICE(0x04ca, 0x3011), .driver_info = BTUSB_QCA_ROME }, + { USB_DEVICE(0x04ca, 0x3015), .driver_info = BTUSB_QCA_ROME }, { USB_DEVICE(0x04ca, 0x3016), .driver_info = BTUSB_QCA_ROME }, /* Broadcom BCM2035 */ Patches currently in stable-queue which might be from ioan.moldovan1999(a)gmail.com are queue-4.14/bluetooth-add-a-new-04ca-3015-qca_rome-device.patch

7 years, 2 months

1
0
0 0

Patch "clk: divider: fix incorrect usage of container_of" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: divider: fix incorrect usage of container_of to the 4.14-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: clk-divider-fix-incorrect-usage-of-container_of.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Jerome Brunet <jbrunet(a)baylibre.com> Date: Thu, 21 Dec 2017 17:30:54 +0100 Subject: clk: divider: fix incorrect usage of container_of From: Jerome Brunet <jbrunet(a)baylibre.com> [ Upstream commit 12a26c298d2a8b1cab498533fa65198e49e3afd3 ] divider_recalc_rate() is an helper function used by clock divider of different types, so the structure containing the 'hw' pointer is not always a 'struct clk_divider' At the following line: > div = _get_div(table, val, flags, divider->width); in several cases, the value of 'divider->width' is garbage as the actual structure behind this memory is not a 'struct clk_divider' Fortunately, this width value is used by _get_val() only when CLK_DIVIDER_MAX_AT_ZERO flag is set. This has never been the case so far when the structure is not a 'struct clk_divider'. This is probably why we did not notice this bug before Fixes: afe76c8fd030 ("clk: allow a clk divider with max divisor when zero") Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com> Acked-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com> Acked-by: Sylvain Lemieux <slemieux.tyco(a)gmail.com> Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/clk-divider.c | 7 +++---- drivers/clk/hisilicon/clkdivider-hi6220.c | 2 +- drivers/clk/nxp/clk-lpc32xx.c | 2 +- drivers/clk/qcom/clk-regmap-divider.c | 2 +- drivers/clk/sunxi-ng/ccu_div.c | 2 +- drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c | 2 +- drivers/rtc/rtc-ac100.c | 6 ++++-- include/linux/clk-provider.h | 2 +- 8 files changed, 13 insertions(+), 12 deletions(-) --- a/drivers/clk/clk-divider.c +++ b/drivers/clk/clk-divider.c @@ -118,12 +118,11 @@ static unsigned int _get_val(const struc unsigned long divider_recalc_rate(struct clk_hw *hw, unsigned long parent_rate, unsigned int val, const struct clk_div_table *table, - unsigned long flags) + unsigned long flags, unsigned long width) { - struct clk_divider *divider = to_clk_divider(hw); unsigned int div; - div = _get_div(table, val, flags, divider->width); + div = _get_div(table, val, flags, width); if (!div) { WARN(!(flags & CLK_DIVIDER_ALLOW_ZERO), "%s: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not set\n", @@ -145,7 +144,7 @@ static unsigned long clk_divider_recalc_ val &= div_mask(divider->width); return divider_recalc_rate(hw, parent_rate, val, divider->table, - divider->flags); + divider->flags, divider->width); } static bool _is_valid_table_div(const struct clk_div_table *table, --- a/drivers/clk/hisilicon/clkdivider-hi6220.c +++ b/drivers/clk/hisilicon/clkdivider-hi6220.c @@ -56,7 +56,7 @@ static unsigned long hi6220_clkdiv_recal val &= div_mask(dclk->width); return divider_recalc_rate(hw, parent_rate, val, dclk->table, - CLK_DIVIDER_ROUND_CLOSEST); + CLK_DIVIDER_ROUND_CLOSEST, dclk->width); } static long hi6220_clkdiv_round_rate(struct clk_hw *hw, unsigned long rate, --- a/drivers/clk/nxp/clk-lpc32xx.c +++ b/drivers/clk/nxp/clk-lpc32xx.c @@ -956,7 +956,7 @@ static unsigned long clk_divider_recalc_ val &= div_mask(divider->width); return divider_recalc_rate(hw, parent_rate, val, divider->table, - divider->flags); + divider->flags, divider->width); } static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate, --- a/drivers/clk/qcom/clk-regmap-divider.c +++ b/drivers/clk/qcom/clk-regmap-divider.c @@ -59,7 +59,7 @@ static unsigned long div_recalc_rate(str div &= BIT(divider->width) - 1; return divider_recalc_rate(hw, parent_rate, div, NULL, - CLK_DIVIDER_ROUND_CLOSEST); + CLK_DIVIDER_ROUND_CLOSEST, divider->width); } const struct clk_ops clk_regmap_div_ops = { --- a/drivers/clk/sunxi-ng/ccu_div.c +++ b/drivers/clk/sunxi-ng/ccu_div.c @@ -71,7 +71,7 @@ static unsigned long ccu_div_recalc_rate parent_rate); val = divider_recalc_rate(hw, parent_rate, val, cd->div.table, - cd->div.flags); + cd->div.flags, cd->div.width); if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV) val /= cd->fixed_post_div; --- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c +++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c @@ -698,7 +698,7 @@ static unsigned long dsi_pll_14nm_postdi val &= div_mask(width); return divider_recalc_rate(hw, parent_rate, val, NULL, - postdiv->flags); + postdiv->flags, width); } static long dsi_pll_14nm_postdiv_round_rate(struct clk_hw *hw, --- a/drivers/rtc/rtc-ac100.c +++ b/drivers/rtc/rtc-ac100.c @@ -137,13 +137,15 @@ static unsigned long ac100_clkout_recalc div = (reg >> AC100_CLKOUT_PRE_DIV_SHIFT) & ((1 << AC100_CLKOUT_PRE_DIV_WIDTH) - 1); prate = divider_recalc_rate(hw, prate, div, - ac100_clkout_prediv, 0); + ac100_clkout_prediv, 0, + AC100_CLKOUT_PRE_DIV_WIDTH); } div = (reg >> AC100_CLKOUT_DIV_SHIFT) & (BIT(AC100_CLKOUT_DIV_WIDTH) - 1); return divider_recalc_rate(hw, prate, div, NULL, - CLK_DIVIDER_POWER_OF_TWO); + CLK_DIVIDER_POWER_OF_TWO, + AC100_CLKOUT_DIV_WIDTH); } static long ac100_clkout_round_rate(struct clk_hw *hw, unsigned long rate, --- a/include/linux/clk-provider.h +++ b/include/linux/clk-provider.h @@ -412,7 +412,7 @@ extern const struct clk_ops clk_divider_ unsigned long divider_recalc_rate(struct clk_hw *hw, unsigned long parent_rate, unsigned int val, const struct clk_div_table *table, - unsigned long flags); + unsigned long flags, unsigned long width); long divider_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent, unsigned long rate, unsigned long *prate, const struct clk_div_table *table, Patches currently in stable-queue which might be from jbrunet(a)baylibre.com are queue-4.14/clk-divider-fix-incorrect-usage-of-container_of.patch queue-4.14/clk-meson-mpll-use-64-bit-maths-in-params_from_rate.patch

7 years, 2 months

1
0
0 0

Patch "block, bfq: put async queues for root bfq groups too" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled block, bfq: put async queues for root bfq groups too to the 4.14-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: block-bfq-put-async-queues-for-root-bfq-groups-too.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Paolo Valente <paolo.valente(a)linaro.org> Date: Tue, 9 Jan 2018 10:27:58 +0100 Subject: block, bfq: put async queues for root bfq groups too From: Paolo Valente <paolo.valente(a)linaro.org> [ Upstream commit 52257ffbfcaf58d247b13fb148e27ed17c33e526 ] For each pair [device for which bfq is selected as I/O scheduler, group in blkio/io], bfq maintains a corresponding bfq group. Each such bfq group contains a set of async queues, with each async queue created on demand, i.e., when some I/O request arrives for it. On creation, an async queue gets an extra reference, to make sure that the queue is not freed as long as its bfq group exists. Accordingly, to allow the queue to be freed after the group exited, this extra reference must released on group exit. The above holds also for a bfq root group, i.e., for the bfq group corresponding to the root blkio/io root for a given device. Yet, by mistake, the references to the existing async queues of a root group are not released when the latter exits. This causes a memory leak when the instance of bfq for a given device exits. In a similar vein, bfqg_stats_xfer_dead is not executed for a root group. This commit fixes bfq_pd_offline so that the latter executes the above missing operations for a root group too. Reported-by: Holger Hoffstätte <holger(a)applied-asynchrony.com> Reported-by: Guoqing Jiang <gqjiang(a)suse.com> Tested-by: Holger Hoffstätte <holger(a)applied-asynchrony.com> Signed-off-by: Davide Ferrari <davideferrari8(a)gmail.com> Signed-off-by: Paolo Valente <paolo.valente(a)linaro.org> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- block/bfq-cgroup.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/block/bfq-cgroup.c +++ b/block/bfq-cgroup.c @@ -749,10 +749,11 @@ static void bfq_pd_offline(struct blkg_p unsigned long flags; int i; + spin_lock_irqsave(&bfqd->lock, flags); + if (!entity) /* root group */ - return; + goto put_async_queues; - spin_lock_irqsave(&bfqd->lock, flags); /* * Empty all service_trees belonging to this group before * deactivating the group itself. @@ -783,6 +784,8 @@ static void bfq_pd_offline(struct blkg_p } __bfq_deactivate_entity(entity, false); + +put_async_queues: bfq_put_async_queues(bfqd, bfqg); spin_unlock_irqrestore(&bfqd->lock, flags); Patches currently in stable-queue which might be from paolo.valente(a)linaro.org are queue-4.14/block-bfq-put-async-queues-for-root-bfq-groups-too.patch

7 years, 2 months

1
0
0 0

Patch "blk-mq: fix kernel oops in blk_mq_tag_idle()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled blk-mq: fix kernel oops in blk_mq_tag_idle() to the 4.14-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: blk-mq-fix-kernel-oops-in-blk_mq_tag_idle.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Ming Lei <ming.lei(a)redhat.com> Date: Tue, 9 Jan 2018 21:28:29 +0800 Subject: blk-mq: fix kernel oops in blk_mq_tag_idle() From: Ming Lei <ming.lei(a)redhat.com> [ Upstream commit 8ab0b7dc73e1b3e2987d42554b2bff503f692772 ] HW queues may be unmapped in some cases, such as blk_mq_update_nr_hw_queues(), then we need to check it before calling blk_mq_tag_idle(), otherwise the following kernel oops can be triggered, so fix it by checking if the hw queue is unmapped since it doesn't make sense to idle the tags any more after hw queues are unmapped. [ 440.771298] Workqueue: nvme-wq nvme_rdma_del_ctrl_work [nvme_rdma] [ 440.779104] task: ffff894bae755ee0 ti: ffff893bf9bc8000 task.ti: ffff893bf9bc8000 [ 440.788359] RIP: 0010:[<ffffffffb730e2b4>] [<ffffffffb730e2b4>] __blk_mq_tag_idle+0x24/0x40 [ 440.798697] RSP: 0018:ffff893bf9bcbd10 EFLAGS: 00010286 [ 440.805538] RAX: 0000000000000000 RBX: ffff895bb131dc00 RCX: 000000000000011f [ 440.814426] RDX: 00000000ffffffff RSI: 0000000000000120 RDI: ffff895bb131dc00 [ 440.823301] RBP: ffff893bf9bcbd10 R08: 000000000001b860 R09: 4a51d361c00c0000 [ 440.832193] R10: b5907f32b4cc7003 R11: ffffd6cabfb57000 R12: ffff894bafd1e008 [ 440.841091] R13: 0000000000000001 R14: ffff895baf770000 R15: 0000000000000080 [ 440.849988] FS: 0000000000000000(0000) GS:ffff894bbdcc0000(0000) knlGS:0000000000000000 [ 440.859955] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 440.867274] CR2: 0000000000000008 CR3: 000000103d098000 CR4: 00000000001407e0 [ 440.876169] Call Trace: [ 440.879818] [<ffffffffb7309d68>] blk_mq_exit_hctx+0xd8/0xe0 [ 440.887051] [<ffffffffb730dc40>] blk_mq_free_queue+0xf0/0x160 [ 440.894465] [<ffffffffb72ff679>] blk_cleanup_queue+0xd9/0x150 [ 440.901881] [<ffffffffc08a802b>] nvme_ns_remove+0x5b/0xb0 [nvme_core] [ 440.910068] [<ffffffffc08a811b>] nvme_remove_namespaces+0x3b/0x60 [nvme_core] [ 440.919026] [<ffffffffc08b817b>] __nvme_rdma_remove_ctrl+0x2b/0xb0 [nvme_rdma] [ 440.928079] [<ffffffffc08b8237>] nvme_rdma_del_ctrl_work+0x17/0x20 [nvme_rdma] [ 440.937126] [<ffffffffb70ab58a>] process_one_work+0x17a/0x440 [ 440.944517] [<ffffffffb70ac3a8>] worker_thread+0x278/0x3c0 [ 440.951607] [<ffffffffb70ac130>] ? manage_workers.isra.24+0x2a0/0x2a0 [ 440.959760] [<ffffffffb70b352f>] kthread+0xcf/0xe0 [ 440.966055] [<ffffffffb70b3460>] ? insert_kthread_work+0x40/0x40 [ 440.973715] [<ffffffffb76d8658>] ret_from_fork+0x58/0x90 [ 440.980586] [<ffffffffb70b3460>] ? insert_kthread_work+0x40/0x40 [ 440.988229] Code: 5b 41 5c 5d c3 66 90 0f 1f 44 00 00 48 8b 87 20 01 00 00 f0 0f ba 77 40 01 19 d2 85 d2 75 08 c3 0f 1f 80 00 00 00 00 55 48 89 e5 <f0> ff 48 08 48 8d 78 10 e8 7f 0f 05 00 5d c3 0f 1f 00 66 2e 0f [ 441.011620] RIP [<ffffffffb730e2b4>] __blk_mq_tag_idle+0x24/0x40 [ 441.019301] RSP <ffff893bf9bcbd10> [ 441.024052] CR2: 0000000000000008 Reported-by: Zhang Yi <yizhan(a)redhat.com> Tested-by: Zhang Yi <yizhan(a)redhat.com> Signed-off-by: Ming Lei <ming.lei(a)redhat.com> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- block/blk-mq.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -1928,7 +1928,8 @@ static void blk_mq_exit_hctx(struct requ { blk_mq_debugfs_unregister_hctx(hctx); - blk_mq_tag_idle(hctx); + if (blk_mq_hw_queue_mapped(hctx)) + blk_mq_tag_idle(hctx); if (set->ops->exit_request) set->ops->exit_request(set, hctx->fq->flush_rq, hctx_idx); Patches currently in stable-queue which might be from ming.lei(a)redhat.com are queue-4.14/blk-mq-avoid-to-map-cpu-into-stale-hw-queue.patch queue-4.14/blk-mq-fix-kernel-oops-in-blk_mq_tag_idle.patch queue-4.14/blk-mq-fix-race-between-updating-nr_hw_queues-and-switching-io-sched.patch

7 years, 2 months

1
0
0 0

Patch "blk-mq: fix race between updating nr_hw_queues and switching io sched" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled blk-mq: fix race between updating nr_hw_queues and switching io sched to the 4.14-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: blk-mq-fix-race-between-updating-nr_hw_queues-and-switching-io-sched.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Ming Lei <ming.lei(a)redhat.com> Date: Sat, 6 Jan 2018 16:27:40 +0800 Subject: blk-mq: fix race between updating nr_hw_queues and switching io sched From: Ming Lei <ming.lei(a)redhat.com> [ Upstream commit fb350e0ad99359768e1e80b4784692031ec340e4 ] In both elevator_switch_mq() and blk_mq_update_nr_hw_queues(), sched tags can be allocated, and q->nr_hw_queue is used, and race is inevitable, for example: blk_mq_init_sched() may trigger use-after-free on hctx, which is freed in blk_mq_realloc_hw_ctxs() when nr_hw_queues is decreased. This patch fixes the race be holding q->sysfs_lock. Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reported-by: Yi Zhang <yi.zhang(a)redhat.com> Tested-by: Yi Zhang <yi.zhang(a)redhat.com> Signed-off-by: Ming Lei <ming.lei(a)redhat.com> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- block/blk-mq.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -2314,6 +2314,9 @@ static void blk_mq_realloc_hw_ctxs(struc struct blk_mq_hw_ctx **hctxs = q->queue_hw_ctx; blk_mq_sysfs_unregister(q); + + /* protect against switching io scheduler */ + mutex_lock(&q->sysfs_lock); for (i = 0; i < set->nr_hw_queues; i++) { int node; @@ -2358,6 +2361,7 @@ static void blk_mq_realloc_hw_ctxs(struc } } q->nr_hw_queues = i; + mutex_unlock(&q->sysfs_lock); blk_mq_sysfs_register(q); } Patches currently in stable-queue which might be from ming.lei(a)redhat.com are queue-4.14/blk-mq-avoid-to-map-cpu-into-stale-hw-queue.patch queue-4.14/blk-mq-fix-kernel-oops-in-blk_mq_tag_idle.patch queue-4.14/blk-mq-fix-race-between-updating-nr_hw_queues-and-switching-io-sched.patch

7 years, 2 months

1
0
0 0

Patch "blk-mq: avoid to map CPU into stale hw queue" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled blk-mq: avoid to map CPU into stale hw queue to the 4.14-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: blk-mq-avoid-to-map-cpu-into-stale-hw-queue.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Ming Lei <ming.lei(a)redhat.com> Date: Sat, 6 Jan 2018 16:27:39 +0800 Subject: blk-mq: avoid to map CPU into stale hw queue From: Ming Lei <ming.lei(a)redhat.com> [ Upstream commit 7d4901a90d02500c8011472a060f9b2e60e6e605 ] blk_mq_pci_map_queues() may not map one CPU into any hw queue, but its previous map isn't cleared yet, and may point to one stale hw queue index. This patch fixes the following issue by clearing the mapping table before setting it up in blk_mq_pci_map_queues(). This patches fixes this following issue reported by Zhang Yi: [ 101.202734] BUG: unable to handle kernel NULL pointer dereference at 0000000094d3013f [ 101.211487] IP: blk_mq_map_swqueue+0xbc/0x200 [ 101.216346] PGD 0 P4D 0 [ 101.219171] Oops: 0000 [#1] SMP [ 101.222674] Modules linked in: sunrpc ipmi_ssif vfat fat intel_rapl sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel intel_cstate intel_uncore mxm_wmi intel_rapl_perf iTCO_wdt ipmi_si ipmi_devintf pcspkr iTCO_vendor_support sg dcdbas ipmi_msghandler wmi mei_me lpc_ich shpchp mei acpi_power_meter dm_multipath ip_tables xfs libcrc32c sd_mod mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm ahci libahci crc32c_intel libata tg3 nvme nvme_core megaraid_sas ptp i2c_core pps_core dm_mirror dm_region_hash dm_log dm_mod [ 101.284881] CPU: 0 PID: 504 Comm: kworker/u25:5 Not tainted 4.15.0-rc2 #1 [ 101.292455] Hardware name: Dell Inc. PowerEdge R730xd/072T6D, BIOS 2.5.5 08/16/2017 [ 101.301001] Workqueue: nvme-wq nvme_reset_work [nvme] [ 101.306636] task: 00000000f2c53190 task.stack: 000000002da874f9 [ 101.313241] RIP: 0010:blk_mq_map_swqueue+0xbc/0x200 [ 101.318681] RSP: 0018:ffffc9000234fd70 EFLAGS: 00010282 [ 101.324511] RAX: ffff88047ffc9480 RBX: ffff88047e130850 RCX: 0000000000000000 [ 101.332471] RDX: ffffe8ffffd40580 RSI: ffff88047e509b40 RDI: ffff88046f37a008 [ 101.340432] RBP: 000000000000000b R08: ffff88046f37a008 R09: 0000000011f94280 [ 101.348392] R10: ffff88047ffd4d00 R11: 0000000000000000 R12: ffff88046f37a008 [ 101.356353] R13: ffff88047e130f38 R14: 000000000000000b R15: ffff88046f37a558 [ 101.364314] FS: 0000000000000000(0000) GS:ffff880277c00000(0000) knlGS:0000000000000000 [ 101.373342] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 101.379753] CR2: 0000000000000098 CR3: 000000047f409004 CR4: 00000000001606f0 [ 101.387714] Call Trace: [ 101.390445] blk_mq_update_nr_hw_queues+0xbf/0x130 [ 101.395791] nvme_reset_work+0x6f4/0xc06 [nvme] [ 101.400848] ? pick_next_task_fair+0x290/0x5f0 [ 101.405807] ? __switch_to+0x1f5/0x430 [ 101.409988] ? put_prev_entity+0x2f/0xd0 [ 101.414365] process_one_work+0x141/0x340 [ 101.418836] worker_thread+0x47/0x3e0 [ 101.422921] kthread+0xf5/0x130 [ 101.426424] ? rescuer_thread+0x380/0x380 [ 101.430896] ? kthread_associate_blkcg+0x90/0x90 [ 101.436048] ret_from_fork+0x1f/0x30 [ 101.440034] Code: 48 83 3c ca 00 0f 84 2b 01 00 00 48 63 cd 48 8b 93 10 01 00 00 8b 0c 88 48 8b 83 20 01 00 00 4a 03 14 f5 60 04 af 81 48 8b 0c c8 <48> 8b 81 98 00 00 00 f0 4c 0f ab 30 8b 81 f8 00 00 00 89 42 44 [ 101.461116] RIP: blk_mq_map_swqueue+0xbc/0x200 RSP: ffffc9000234fd70 [ 101.468205] CR2: 0000000000000098 [ 101.471907] ---[ end trace 5fe710f98228a3ca ]--- [ 101.482489] Kernel panic - not syncing: Fatal exception [ 101.488505] Kernel Offset: disabled [ 101.497752] ---[ end Kernel panic - not syncing: Fatal exception Reviewed-by: Christoph Hellwig <hch(a)lst.de> Suggested-by: Christoph Hellwig <hch(a)lst.de> Reported-by: Yi Zhang <yi.zhang(a)redhat.com> Tested-by: Yi Zhang <yi.zhang(a)redhat.com> Signed-off-by: Ming Lei <ming.lei(a)redhat.com> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- block/blk-mq.c | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -2528,9 +2528,27 @@ static int blk_mq_alloc_rq_maps(struct b static int blk_mq_update_queue_map(struct blk_mq_tag_set *set) { - if (set->ops->map_queues) + if (set->ops->map_queues) { + int cpu; + /* + * transport .map_queues is usually done in the following + * way: + * + * for (queue = 0; queue < set->nr_hw_queues; queue++) { + * mask = get_cpu_mask(queue) + * for_each_cpu(cpu, mask) + * set->mq_map[cpu] = queue; + * } + * + * When we need to remap, the table has to be cleared for + * killing stale mapping since one CPU may not be mapped + * to any hw queue. + */ + for_each_possible_cpu(cpu) + set->mq_map[cpu] = 0; + return set->ops->map_queues(set); - else + } else return blk_mq_map_queues(set); } Patches currently in stable-queue which might be from ming.lei(a)redhat.com are queue-4.14/blk-mq-avoid-to-map-cpu-into-stale-hw-queue.patch queue-4.14/blk-mq-fix-kernel-oops-in-blk_mq_tag_idle.patch queue-4.14/blk-mq-fix-race-between-updating-nr_hw_queues-and-switching-io-sched.patch

7 years, 2 months

1
0
0 0

Patch "bcache: stop writeback thread after detaching" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bcache: stop writeback thread after detaching to the 4.14-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: bcache-stop-writeback-thread-after-detaching.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Tang Junhui <tang.junhui(a)zte.com.cn> Date: Mon, 8 Jan 2018 12:21:19 -0800 Subject: bcache: stop writeback thread after detaching From: Tang Junhui <tang.junhui(a)zte.com.cn> [ Upstream commit 8d29c4426b9f8afaccf28de414fde8a722b35fdf ] Currently, when a cached device detaching from cache, writeback thread is not stopped, and writeback_rate_update work is not canceled. For example, after the following command: echo 1 >/sys/block/sdb/bcache/detach you can still see the writeback thread. Then you attach the device to the cache again, bcache will create another writeback thread, for example, after below command: echo ba0fb5cd-658a-4533-9806-6ce166d883b9 > /sys/block/sdb/bcache/attach then you will see 2 writeback threads. This patch stops writeback thread and cancels writeback_rate_update work when cached device detaching from cache. Compare with patch v1, this v2 patch moves code down into the register lock for safety in case of any future changes as Coly and Mike suggested. [edit by mlyle: commit log spelling/formatting] Signed-off-by: Tang Junhui <tang.junhui(a)zte.com.cn> Reviewed-by: Michael Lyle <mlyle(a)lyle.org> Signed-off-by: Michael Lyle <mlyle(a)lyle.org> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/bcache/super.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/md/bcache/super.c +++ b/drivers/md/bcache/super.c @@ -893,6 +893,12 @@ static void cached_dev_detach_finish(str mutex_lock(&bch_register_lock); + cancel_delayed_work_sync(&dc->writeback_rate_update); + if (!IS_ERR_OR_NULL(dc->writeback_thread)) { + kthread_stop(dc->writeback_thread); + dc->writeback_thread = NULL; + } + memset(&dc->sb.set_uuid, 0, 16); SET_BDEV_STATE(&dc->sb, BDEV_STATE_NONE); Patches currently in stable-queue which might be from tang.junhui(a)zte.com.cn are queue-4.14/bcache-segregate-flash-only-volume-write-streams.patch queue-4.14/bcache-stop-writeback-thread-after-detaching.patch

7 years, 2 months

1
0
0 0

Patch "bcache: segregate flash only volume write streams" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bcache: segregate flash only volume write streams to the 4.14-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: bcache-segregate-flash-only-volume-write-streams.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Tang Junhui <tang.junhui(a)zte.com.cn> Date: Mon, 8 Jan 2018 12:21:21 -0800 Subject: bcache: segregate flash only volume write streams From: Tang Junhui <tang.junhui(a)zte.com.cn> [ Upstream commit 4eca1cb28d8b0574ca4f1f48e9331c5f852d43b9 ] In such scenario that there are some flash only volumes , and some cached devices, when many tasks request these devices in writeback mode, the write IOs may fall to the same bucket as bellow: | cached data | flash data | cached data | cached data| flash data| then after writeback of these cached devices, the bucket would be like bellow bucket: | free | flash data | free | free | flash data | So, there are many free space in this bucket, but since data of flash only volumes still exists, so this bucket cannot be reclaimable, which would cause waste of bucket space. In this patch, we segregate flash only volume write streams from cached devices, so data from flash only volumes and cached devices can store in different buckets. Compare to v1 patch, this patch do not add a additionally open bucket list, and it is try best to segregate flash only volume write streams from cached devices, sectors of flash only volumes may still be mixed with dirty sectors of cached device, but the number is very small. [mlyle: fixed commit log formatting, permissions, line endings] Signed-off-by: Tang Junhui <tang.junhui(a)zte.com.cn> Reviewed-by: Michael Lyle <mlyle(a)lyle.org> Signed-off-by: Michael Lyle <mlyle(a)lyle.org> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/bcache/alloc.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) --- a/drivers/md/bcache/alloc.c +++ b/drivers/md/bcache/alloc.c @@ -515,15 +515,21 @@ struct open_bucket { /* * We keep multiple buckets open for writes, and try to segregate different - * write streams for better cache utilization: first we look for a bucket where - * the last write to it was sequential with the current write, and failing that - * we look for a bucket that was last used by the same task. + * write streams for better cache utilization: first we try to segregate flash + * only volume write streams from cached devices, secondly we look for a bucket + * where the last write to it was sequential with the current write, and + * failing that we look for a bucket that was last used by the same task. * * The ideas is if you've got multiple tasks pulling data into the cache at the * same time, you'll get better cache utilization if you try to segregate their * data and preserve locality. * - * For example, say you've starting Firefox at the same time you're copying a + * For example, dirty sectors of flash only volume is not reclaimable, if their + * dirty sectors mixed with dirty sectors of cached device, such buckets will + * be marked as dirty and won't be reclaimed, though the dirty data of cached + * device have been written back to backend device. + * + * And say you've starting Firefox at the same time you're copying a * bunch of files. Firefox will likely end up being fairly hot and stay in the * cache awhile, but the data you copied might not be; if you wrote all that * data to the same buckets it'd get invalidated at the same time. @@ -540,7 +546,10 @@ static struct open_bucket *pick_data_buc struct open_bucket *ret, *ret_task = NULL; list_for_each_entry_reverse(ret, &c->data_buckets, list) - if (!bkey_cmp(&ret->key, search)) + if (UUID_FLASH_ONLY(&c->uuids[KEY_INODE(&ret->key)]) != + UUID_FLASH_ONLY(&c->uuids[KEY_INODE(search)])) + continue; + else if (!bkey_cmp(&ret->key, search)) goto found; else if (ret->last_write_point == write_point) ret_task = ret; Patches currently in stable-queue which might be from tang.junhui(a)zte.com.cn are queue-4.14/bcache-segregate-flash-only-volume-write-streams.patch queue-4.14/bcache-stop-writeback-thread-after-detaching.patch

7 years, 2 months

1
0
0 0

Patch "bcache: ret IOERR when read meets metadata error" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bcache: ret IOERR when read meets metadata error to the 4.14-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: bcache-ret-ioerr-when-read-meets-metadata-error.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Rui Hua <huarui.dev(a)gmail.com> Date: Mon, 8 Jan 2018 12:21:18 -0800 Subject: bcache: ret IOERR when read meets metadata error From: Rui Hua <huarui.dev(a)gmail.com> [ Upstream commit b221fc130c49c50f4c2250d22e873420765a9fa2 ] The read request might meet error when searching the btree, but the error was not handled in cache_lookup(), and this kind of metadata failure will not go into cached_dev_read_error(), finally, the upper layer will receive bi_status=0. In this patch we judge the metadata error by the return value of bch_btree_map_keys(), there are two potential paths give rise to the error: 1. Because the btree is not totally cached in memery, we maybe get error when read btree node from cache device (see bch_btree_node_get()), the likely errno is -EIO, -ENOMEM 2. When read miss happens, bch_btree_insert_check_key() will be called to insert a "replace_key" to btree(see cached_dev_cache_miss(), just for doing preparatory work before insert the missed data to cache device), a failure can also happen in this situation, the likely errno is -ENOMEM bch_btree_map_keys() will return MAP_DONE in normal scenario, but we will get either -EIO or -ENOMEM in above two cases. if this happened, we should NOT recover data from backing device (when cache device is dirty) because we don't know whether bkeys the read request covered are all clean. And after that happened, s->iop.status is still its initially value(0) before we submit s->bio.bio, we set it to BLK_STS_IOERR, so it can go into cached_dev_read_error(), and finally it can be passed to upper layer, or recovered by reread from backing device. [edit by mlyle: patch formatting, word-wrap, comment spelling, commit log format] Signed-off-by: Hua Rui <huarui.dev(a)gmail.com> Reviewed-by: Michael Lyle <mlyle(a)lyle.org> Signed-off-by: Michael Lyle <mlyle(a)lyle.org> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/bcache/request.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) --- a/drivers/md/bcache/request.c +++ b/drivers/md/bcache/request.c @@ -568,6 +568,7 @@ static void cache_lookup(struct closure { struct search *s = container_of(cl, struct search, iop.cl); struct bio *bio = &s->bio.bio; + struct cached_dev *dc; int ret; bch_btree_op_init(&s->op, -1); @@ -580,6 +581,27 @@ static void cache_lookup(struct closure return; } + /* + * We might meet err when searching the btree, If that happens, we will + * get negative ret, in this scenario we should not recover data from + * backing device (when cache device is dirty) because we don't know + * whether bkeys the read request covered are all clean. + * + * And after that happened, s->iop.status is still its initial value + * before we submit s->bio.bio + */ + if (ret < 0) { + BUG_ON(ret == -EINTR); + if (s->d && s->d->c && + !UUID_FLASH_ONLY(&s->d->c->uuids[s->d->id])) { + dc = container_of(s->d, struct cached_dev, disk); + if (dc && atomic_read(&dc->has_dirty)) + s->recoverable = false; + } + if (!s->iop.status) + s->iop.status = BLK_STS_IOERR; + } + closure_return(cl); } Patches currently in stable-queue which might be from huarui.dev(a)gmail.com are queue-4.14/bcache-ret-ioerr-when-read-meets-metadata-error.patch

7 years, 2 months

1
0
0 0

Patch "backlight: tdo24m: Fix the SPI CS between transfers" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled backlight: tdo24m: Fix the SPI CS between transfers to the 4.14-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: backlight-tdo24m-fix-the-spi-cs-between-transfers.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Robert Jarzmik <robert.jarzmik(a)free.fr> Date: Thu, 28 Dec 2017 09:27:41 +0100 Subject: backlight: tdo24m: Fix the SPI CS between transfers From: Robert Jarzmik <robert.jarzmik(a)free.fr> [ Upstream commit 2023b0524a6310e9ea80daf085f51c71bff9289f ] Currently the LCD display (TD035S) on the cm-x300 platform is broken and remains blank. The TD0245S specification requires that the chipselect is toggled between commands sent to the panel. This was also the purpose of the former patch of commit f64dcac0b124 ("backlight: tdo24m: ensure chip select changes between transfers"). Unfortunately, the "cs_change" field of a SPI transfer is misleading. Its true meaning is that for a SPI message holding multiple transfers, the chip select is toggled between each transfer, but for the last transfer it remains asserted. In this driver, all the SPI messages contain exactly one transfer, which means that each transfer is the last of its message, and as a consequence the chip select is never toggled. Actually, there was a second bug hidding the first one, hence the problem was not seen until v4.6. This problem was fixed by commit a52db659c79c ("spi: pxa2xx: Fix cs_change management") for PXA based boards. This fix makes the TD035S work again on a cm-x300 board. The same applies to other PXA boards, ie. corgi and tosa. Fixes: a52db659c79c ("spi: pxa2xx: Fix cs_change management") Reported-by: Andrea Adami <andrea.adami(a)gmail.com> Signed-off-by: Robert Jarzmik <robert.jarzmik(a)free.fr> Acked-by: Daniel Thompson <daniel.thompson(a)linaro.org> Signed-off-by: Lee Jones <lee.jones(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/backlight/corgi_lcd.c | 2 +- drivers/video/backlight/tdo24m.c | 2 +- drivers/video/backlight/tosa_lcd.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) --- a/drivers/video/backlight/corgi_lcd.c +++ b/drivers/video/backlight/corgi_lcd.c @@ -177,7 +177,7 @@ static int corgi_ssp_lcdtg_send(struct c struct spi_message msg; struct spi_transfer xfer = { .len = 1, - .cs_change = 1, + .cs_change = 0, .tx_buf = lcd->buf, }; --- a/drivers/video/backlight/tdo24m.c +++ b/drivers/video/backlight/tdo24m.c @@ -369,7 +369,7 @@ static int tdo24m_probe(struct spi_devic spi_message_init(m); - x->cs_change = 1; + x->cs_change = 0; x->tx_buf = &lcd->buf[0]; spi_message_add_tail(x, m); --- a/drivers/video/backlight/tosa_lcd.c +++ b/drivers/video/backlight/tosa_lcd.c @@ -49,7 +49,7 @@ static int tosa_tg_send(struct spi_devic struct spi_message msg; struct spi_transfer xfer = { .len = 1, - .cs_change = 1, + .cs_change = 0, .tx_buf = buf, }; Patches currently in stable-queue which might be from robert.jarzmik(a)free.fr are queue-4.14/backlight-tdo24m-fix-the-spi-cs-between-transfers.patch

7 years, 2 months

1
0
0 0

Patch "ASoC: Intel: sst: Fix the return value of 'sst_send_byte_stream_mrfld()'" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ASoC: Intel: sst: Fix the return value of 'sst_send_byte_stream_mrfld()' to the 4.14-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: asoc-intel-sst-fix-the-return-value-of-sst_send_byte_stream_mrfld.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Sat, 6 Jan 2018 21:18:24 +0100 Subject: ASoC: Intel: sst: Fix the return value of 'sst_send_byte_stream_mrfld()' From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> [ Upstream commit eaadb1caa966a91128297b754e90b7c92b350a00 ] In some error handling paths, an error code is assiegned to 'ret'. However, the function always return 0. Fix it and return the error code if such an error paths is taken. Fixes: 3d9ff34622ba ("ASoC: Intel: sst: add stream operations") Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/soc/intel/atom/sst/sst_stream.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/sound/soc/intel/atom/sst/sst_stream.c +++ b/sound/soc/intel/atom/sst/sst_stream.c @@ -221,7 +221,7 @@ int sst_send_byte_stream_mrfld(struct in sst_free_block(sst_drv_ctx, block); out: test_and_clear_bit(pvt_id, &sst_drv_ctx->pvt_id); - return 0; + return ret; } /* Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-4.14/edac-mv64x60-fix-an-error-handling-path.patch queue-4.14/asoc-intel-sst-fix-the-return-value-of-sst_send_byte_stream_mrfld.patch

7 years, 2 months

1
0
0 0

Patch "ASoC: Intel: cht_bsw_rt5645: Analog Mic support" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ASoC: Intel: cht_bsw_rt5645: Analog Mic support to the 4.14-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: asoc-intel-cht_bsw_rt5645-analog-mic-support.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Hans de Goede <hdegoede(a)redhat.com> Date: Tue, 2 Jan 2018 19:53:14 +0100 Subject: ASoC: Intel: cht_bsw_rt5645: Analog Mic support From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit b70b309950418437bbd2a30afd169c4f09dee3e5 ] Various Cherry Trail boards with a rt5645 codec have an analog mic connected to IN2P + IN2N. The mic on this boards also needs micbias to be enabled, on some boards micbias1 is used and on others micbias2, so we enable both. This commit adds a new "Int Analog Mic" DAPM widget for this, so that we do not end up enabling micbias on boards with a digital mic which uses the already present "Int Mic" widget. Some existing UCM files already refer to "Int Mic" for their "Internal Analog Microphones" SectionDevice, but these don't work anyways since they enable the RECMIX BST1 Switch instead of the BST2 switch. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/soc/intel/boards/cht_bsw_rt5645.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/sound/soc/intel/boards/cht_bsw_rt5645.c +++ b/sound/soc/intel/boards/cht_bsw_rt5645.c @@ -133,6 +133,7 @@ static const struct snd_soc_dapm_widget SND_SOC_DAPM_HP("Headphone", NULL), SND_SOC_DAPM_MIC("Headset Mic", NULL), SND_SOC_DAPM_MIC("Int Mic", NULL), + SND_SOC_DAPM_MIC("Int Analog Mic", NULL), SND_SOC_DAPM_SPK("Ext Spk", NULL), SND_SOC_DAPM_SUPPLY("Platform Clock", SND_SOC_NOPM, 0, 0, platform_clock_control, SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD), @@ -143,6 +144,8 @@ static const struct snd_soc_dapm_route c {"IN1N", NULL, "Headset Mic"}, {"DMIC L1", NULL, "Int Mic"}, {"DMIC R1", NULL, "Int Mic"}, + {"IN2P", NULL, "Int Analog Mic"}, + {"IN2N", NULL, "Int Analog Mic"}, {"Headphone", NULL, "HPOL"}, {"Headphone", NULL, "HPOR"}, {"Ext Spk", NULL, "SPOL"}, @@ -150,6 +153,9 @@ static const struct snd_soc_dapm_route c {"Headphone", NULL, "Platform Clock"}, {"Headset Mic", NULL, "Platform Clock"}, {"Int Mic", NULL, "Platform Clock"}, + {"Int Analog Mic", NULL, "Platform Clock"}, + {"Int Analog Mic", NULL, "micbias1"}, + {"Int Analog Mic", NULL, "micbias2"}, {"Ext Spk", NULL, "Platform Clock"}, }; @@ -204,6 +210,7 @@ static const struct snd_kcontrol_new cht SOC_DAPM_PIN_SWITCH("Headphone"), SOC_DAPM_PIN_SWITCH("Headset Mic"), SOC_DAPM_PIN_SWITCH("Int Mic"), + SOC_DAPM_PIN_SWITCH("Int Analog Mic"), SOC_DAPM_PIN_SWITCH("Ext Spk"), }; Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.14/acpi-video-default-lcd_only-to-true-on-win8-ready-and-newer-machines.patch queue-4.14/input-goodix-disable-irqs-while-suspended.patch queue-4.14/asoc-intel-cht_bsw_rt5645-analog-mic-support.patch queue-4.14/power-supply-axp288_charger-properly-stop-work-on-probe-error-remove.patch queue-4.14/pinctrl-baytrail-enable-glitch-filter-for-gpios-used-as-interrupts.patch

7 years, 2 months

1
0
0 0

Patch "ASoC: Intel: Skylake: Disable clock gating during firmware and library download" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ASoC: Intel: Skylake: Disable clock gating during firmware and library download to the 4.14-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: asoc-intel-skylake-disable-clock-gating-during-firmware-and-library-download.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Pardha Saradhi K <pardha.saradhi.kesapragada(a)intel.com> Date: Tue, 2 Jan 2018 14:59:57 +0530 Subject: ASoC: Intel: Skylake: Disable clock gating during firmware and library download From: Pardha Saradhi K <pardha.saradhi.kesapragada(a)intel.com> [ Upstream commit d5cc0a1fcbb5ddbef9fdd4c4a978da3254ddbf37 ] During firmware and library download, sometimes it is observed that firmware and library download is timed-out resulting into probe failure. This patch disables dynamic clock gating while firmware and library download. Signed-off-by: Pardha Saradhi K <pardha.saradhi.kesapragada(a)intel.com> Signed-off-by: Sanyog Kale <sanyog.r.kale(a)intel.com> Signed-off-by: Guneshwor Singh <guneshwor.o.singh(a)intel.com> Acked-By: Vinod Koul <vinod.koul(a)intel.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/soc/intel/skylake/skl-messages.c | 4 ++++ sound/soc/intel/skylake/skl-pcm.c | 4 ++++ 2 files changed, 8 insertions(+) --- a/sound/soc/intel/skylake/skl-messages.c +++ b/sound/soc/intel/skylake/skl-messages.c @@ -404,7 +404,11 @@ int skl_resume_dsp(struct skl *skl) if (skl->skl_sst->is_first_boot == true) return 0; + /* disable dynamic clock gating during fw and lib download */ + ctx->enable_miscbdcge(ctx->dev, false); + ret = skl_dsp_wake(ctx->dsp); + ctx->enable_miscbdcge(ctx->dev, true); if (ret < 0) return ret; --- a/sound/soc/intel/skylake/skl-pcm.c +++ b/sound/soc/intel/skylake/skl-pcm.c @@ -1332,7 +1332,11 @@ static int skl_platform_soc_probe(struct return -EIO; } + /* disable dynamic clock gating during fw and lib download */ + skl->skl_sst->enable_miscbdcge(platform->dev, false); + ret = ops->init_fw(platform->dev, skl->skl_sst); + skl->skl_sst->enable_miscbdcge(platform->dev, true); if (ret < 0) { dev_err(platform->dev, "Failed to boot first fw: %d\n", ret); return ret; Patches currently in stable-queue which might be from pardha.saradhi.kesapragada(a)intel.com are queue-4.14/asoc-intel-skylake-disable-clock-gating-during-firmware-and-library-download.patch

7 years, 2 months

1
0
0 0

Patch "ARM: dts: ls1021a: add "fsl, ls1021a-esdhc" compatible string to esdhc node" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: ls1021a: add "fsl,ls1021a-esdhc" compatible string to esdhc node to the 4.14-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: arm-dts-ls1021a-add-fsl-ls1021a-esdhc-compatible-string-to-esdhc-node.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk> Date: Thu, 16 Nov 2017 13:15:26 +0100 Subject: ARM: dts: ls1021a: add "fsl,ls1021a-esdhc" compatible string to esdhc node From: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk> [ Upstream commit d5c7b4d5ac2237a6da7ced3adfe6b8bf769f8cc6 ] Commit a22950c888e3 (mmc: sdhci-of-esdhc: add quirk SDHCI_QUIRK_BROKEN_TIMEOUT_VAL for ls1021a) added logic to the driver to enable the broken timeout val quirk for ls1021a, but did not add the corresponding compatible string to the device tree, so it didn't really have any effect. Fix that. Signed-off-by: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk> Signed-off-by: Shawn Guo <shawnguo(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/ls1021a.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm/boot/dts/ls1021a.dtsi +++ b/arch/arm/boot/dts/ls1021a.dtsi @@ -155,7 +155,7 @@ }; esdhc: esdhc@1560000 { - compatible = "fsl,esdhc"; + compatible = "fsl,ls1021a-esdhc", "fsl,esdhc"; reg = <0x0 0x1560000 0x0 0x10000>; interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>; clock-frequency = <0>; Patches currently in stable-queue which might be from rasmus.villemoes(a)prevas.dk are queue-4.14/arm-dts-ls1021a-add-fsl-ls1021a-esdhc-compatible-string-to-esdhc-node.patch

7 years, 2 months

1
0
0 0

Patch "ACPI / video: Default lcd_only to true on Win8-ready and newer machines" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ACPI / video: Default lcd_only to true on Win8-ready and newer machines to the 4.14-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: acpi-video-default-lcd_only-to-true-on-win8-ready-and-newer-machines.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Hans de Goede <hdegoede(a)redhat.com> Date: Sat, 23 Dec 2017 19:41:47 +0100 Subject: ACPI / video: Default lcd_only to true on Win8-ready and newer machines From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit 5928c281524fe451114e04f1dfa11246a37e859f ] We're seeing a lot of bogus backlight interfaces on newer machines without a LCD such as desktops, servers and HDMI sticks. This causes userspace to show a non-functional brightness slider in e.g. the GNOME3 system menu, which is undesirable. And, in general, we should simply just not register a non functional backlight interface. Checking the LCD flag causes the bogus acpi_video backlight interfaces to go away (on the machines this was tested on). This change sets the lcd_only option by default on any machines which are Win8-ready, to fix this. This is not entirely without a risk of regressions, but video_detect.c already prefers native-backlight interfaces over the acpi_video one on Win8-ready machines, calling acpi_video_unregister_backlight() as soon as a native interface shows up. This is done because the ACPI backlight interface often is broken on Win8-ready machines, because win8 does not seem to actually use it. So in practice we already end up not registering the ACPI backlight interface on (most) Win8-ready machines with a LCD panel, thus this change does not change anything for (most) machines with a LCD panel and on machines without a LCD panel we actually don't want to register any backlight interfaces. This has been tested on the following machines and fixes a bogus backlight interface showing up there: - Desktop with an Asrock B150M Pro4S/D3 m.b. using i5-6500 builtin gfx - Intel Compute Stick STK1AW32SC - Meegopad T08 HDMI stick Bogus backlight interfaces have also been reported on: - Desktop with Asus H87I-Plus m.b. - Desktop with ASRock B75M-ITX m.b. - Desktop with Gigabyte Z87-D3HP m.b. - Dell PowerEdge T20 desktop Link: https://bugzilla.redhat.com/show_bug.cgi?id=1097436 Link: https://bugzilla.redhat.com/show_bug.cgi?id=1133327 Link: https://bugzilla.redhat.com/show_bug.cgi?id=1133329 Link: https://bugzilla.redhat.com/show_bug.cgi?id=1133646 Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/acpi/acpi_video.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) --- a/drivers/acpi/acpi_video.c +++ b/drivers/acpi/acpi_video.c @@ -80,8 +80,8 @@ MODULE_PARM_DESC(report_key_events, static bool device_id_scheme = false; module_param(device_id_scheme, bool, 0444); -static bool only_lcd = false; -module_param(only_lcd, bool, 0444); +static int only_lcd = -1; +module_param(only_lcd, int, 0444); static int register_count; static DEFINE_MUTEX(register_count_mutex); @@ -2136,6 +2136,16 @@ int acpi_video_register(void) goto leave; } + /* + * We're seeing a lot of bogus backlight interfaces on newer machines + * without a LCD such as desktops, servers and HDMI sticks. Checking + * the lcd flag fixes this, so enable this on any machines which are + * win8 ready (where we also prefer the native backlight driver, so + * normally the acpi_video code should not register there anyways). + */ + if (only_lcd == -1) + only_lcd = acpi_osi_is_win8(); + dmi_check_system(video_dmi_table); ret = acpi_bus_register_driver(&acpi_video_bus); Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.14/acpi-video-default-lcd_only-to-true-on-win8-ready-and-newer-machines.patch queue-4.14/input-goodix-disable-irqs-while-suspended.patch queue-4.14/asoc-intel-cht_bsw_rt5645-analog-mic-support.patch queue-4.14/power-supply-axp288_charger-properly-stop-work-on-probe-error-remove.patch queue-4.14/pinctrl-baytrail-enable-glitch-filter-for-gpios-used-as-interrupts.patch

7 years, 2 months

1
0
0 0

Patch "ACPI: EC: Fix debugfs_create_*() usage" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ACPI: EC: Fix debugfs_create_*() usage to the 4.14-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: acpi-ec-fix-debugfs_create_-usage.patch and it can be found in the queue-4.14 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 foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Geert Uytterhoeven <geert+renesas(a)glider.be> Date: Tue, 2 Jan 2018 16:26:31 +0100 Subject: ACPI: EC: Fix debugfs_create_*() usage From: Geert Uytterhoeven <geert+renesas(a)glider.be> [ Upstream commit 3522f867c13b63cf62acdf1b8ca5664c549a716a ] acpi_ec.gpe is "unsigned long", hence treating it as "u32" would expose the wrong half on big-endian 64-bit systems. Fix this by changing its type to "u32" and removing the cast, as all other code already uses u32 or sometimes even only u8. Fixes: 1195a098168fcacf (ACPI: Provide /sys/kernel/debug/ec/...) Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/acpi/ec.c | 2 +- drivers/acpi/ec_sys.c | 2 +- drivers/acpi/internal.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) --- a/drivers/acpi/ec.c +++ b/drivers/acpi/ec.c @@ -1516,7 +1516,7 @@ static int acpi_ec_setup(struct acpi_ec } acpi_handle_info(ec->handle, - "GPE=0x%lx, EC_CMD/EC_SC=0x%lx, EC_DATA=0x%lx\n", + "GPE=0x%x, EC_CMD/EC_SC=0x%lx, EC_DATA=0x%lx\n", ec->gpe, ec->command_addr, ec->data_addr); return ret; } --- a/drivers/acpi/ec_sys.c +++ b/drivers/acpi/ec_sys.c @@ -128,7 +128,7 @@ static int acpi_ec_add_debugfs(struct ac return -ENOMEM; } - if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)&first_ec->gpe)) + if (!debugfs_create_x32("gpe", 0444, dev_dir, &first_ec->gpe)) goto error; if (!debugfs_create_bool("use_global_lock", 0444, dev_dir, &first_ec->global_lock)) --- a/drivers/acpi/internal.h +++ b/drivers/acpi/internal.h @@ -159,7 +159,7 @@ static inline void acpi_early_processor_ -------------------------------------------------------------------------- */ struct acpi_ec { acpi_handle handle; - unsigned long gpe; + u32 gpe; unsigned long command_addr; unsigned long data_addr; bool global_lock; Patches currently in stable-queue which might be from geert+renesas(a)glider.be are queue-4.14/acpi-ec-fix-debugfs_create_-usage.patch queue-4.14/spi-sh-msiof-fix-timeout-failures-for-tx-only-dma-transfers.patch

7 years, 2 months

1
0
0 0

v4.15 stable backport request

by Jani Nikula

Stable team, please backport commits 6e3322c226f1 ("drm/i915/cnp: Properly handle VBT ddc pin out of bounds.") f24c606c21a8 ("drm/i915/cnp: Ignore VBT request for know invalid DDC pin.") to v4.15. Thanks, Jani. References: https://bugs.freedesktop.org/show_bug.cgi?id=104139 References: http://mid.mail-archive.com/4c930511-ea7d-e91a-b492-8943980549e4@ubuntu.com -- Jani Nikula, Intel Open Source Technology Center

7 years, 2 months

2
1
0 0

Patch "nvme-fabrics: don't check for non-NULL module in nvmf_register_transport" 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 nvme-fabrics: don't check for non-NULL module in nvmf_register_transport 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: nvme-fabrics-don-t-check-for-non-null-module-in-nvmf_register_transport.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 5a1e59533380a3fd04593e4ab2d4633ebf7745c1 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig <hch(a)lst.de> Date: Thu, 22 Feb 2018 07:24:08 -0800 Subject: nvme-fabrics: don't check for non-NULL module in nvmf_register_transport From: Christoph Hellwig <hch(a)lst.de> commit 5a1e59533380a3fd04593e4ab2d4633ebf7745c1 upstream. THIS_MODULE evaluates to NULL when used from code built into the kernel, thus breaking built-in transport modules. Remove the bogus check. Fixes: 0de5cd36 ("nvme-fabrics: protect against module unload during create_ctrl") Signed-off-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Sagi Grimberg <sagi(a)grimberg.me> Reviewed-by: Johannes Thumshirn <jthumshirn(a)suse.de> Signed-off-by: Keith Busch <keith.busch(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/nvme/host/fabrics.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/nvme/host/fabrics.c +++ b/drivers/nvme/host/fabrics.c @@ -493,7 +493,7 @@ EXPORT_SYMBOL_GPL(nvmf_should_reconnect) */ int nvmf_register_transport(struct nvmf_transport_ops *ops) { - if (!ops->create_ctrl || !ops->module) + if (!ops->create_ctrl) return -EINVAL; down_write(&nvmf_transports_rwsem); Patches currently in stable-queue which might be from hch(a)lst.de are queue-4.15/nvme_fcloop-fix-abort-race-condition.patch queue-4.15/blk-mq-avoid-to-map-cpu-into-stale-hw-queue.patch queue-4.15/scsi-libsas-initialize-sas_phy-status-according-to-response-of-discover.patch queue-4.15/nvme-fabrics-protect-against-module-unload-during-create_ctrl.patch queue-4.15/nvme_fcloop-disassocate-local-port-structs.patch queue-4.15/nvme-fabrics-don-t-check-for-non-null-module-in-nvmf_register_transport.patch queue-4.15/scsi-libsas-fix-error-when-getting-phy-events.patch queue-4.15/blk-mq-fix-race-between-updating-nr_hw_queues-and-switching-io-sched.patch queue-4.15/scsi-libsas-fix-memory-leak-in-sas_smp_get_phy_events.patch queue-4.15/scsi-libsas-use-dynamic-alloced-work-to-avoid-sas-event-lost.patch

7 years, 2 months

1
0
0 0

Patch "drm/i915/cnp: Ignore VBT request for know invalid DDC pin." 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 drm/i915/cnp: Ignore VBT request for know invalid DDC pin. 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: drm-i915-cnp-ignore-vbt-request-for-know-invalid-ddc-pin.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 f24c606c21a8cb6f75adc20edcd80b6d851991bf Mon Sep 17 00:00:00 2001 From: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Date: Tue, 23 Jan 2018 09:40:50 -0800 Subject: drm/i915/cnp: Ignore VBT request for know invalid DDC pin. From: Rodrigo Vivi <rodrigo.vivi(a)intel.com> commit f24c606c21a8cb6f75adc20edcd80b6d851991bf upstream. Let's ignore VBT request if the pin is clearly wrong. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104139 Cc: Kai Heng Feng <kai.heng.feng(a)canonical.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180123174050.4261-1-rodrigo… Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada(a)intel.com> (cherry picked from commit a8e6f3888b05c1e7b685800a3371ce050720368f) Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/i915/intel_bios.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -1115,9 +1115,14 @@ static const u8 cnp_ddc_pin_map[] = { static u8 map_ddc_pin(struct drm_i915_private *dev_priv, u8 vbt_pin) { - if (HAS_PCH_CNP(dev_priv) && - vbt_pin > 0 && vbt_pin < ARRAY_SIZE(cnp_ddc_pin_map)) - return cnp_ddc_pin_map[vbt_pin]; + if (HAS_PCH_CNP(dev_priv)) { + if (vbt_pin > 0 && vbt_pin < ARRAY_SIZE(cnp_ddc_pin_map)) + return cnp_ddc_pin_map[vbt_pin]; + if (vbt_pin > GMBUS_PIN_4_CNP) { + DRM_DEBUG_KMS("Ignoring alternate pin: VBT claims DDC pin %d, which is not valid for this platform\n", vbt_pin); + return 0; + } + } return vbt_pin; } Patches currently in stable-queue which might be from rodrigo.vivi(a)intel.com are queue-4.15/drm-i915-cnp-properly-handle-vbt-ddc-pin-out-of-bounds.patch queue-4.15/drm-i915-cnp-ignore-vbt-request-for-know-invalid-ddc-pin.patch

7 years, 2 months

1
0
0 0

Patch "drm/i915/cnp: Properly handle VBT ddc pin out of bounds." 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 drm/i915/cnp: Properly handle VBT ddc pin out of bounds. 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: drm-i915-cnp-properly-handle-vbt-ddc-pin-out-of-bounds.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 6e3322c226f15bc1838007f5a75566f1482b8e40 Mon Sep 17 00:00:00 2001 From: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Date: Thu, 25 Jan 2018 14:25:24 -0800 Subject: drm/i915/cnp: Properly handle VBT ddc pin out of bounds. From: Rodrigo Vivi <rodrigo.vivi(a)intel.com> commit 6e3322c226f15bc1838007f5a75566f1482b8e40 upstream. If the table result is out of bounds on the array map there is something really wrong with VBT pin so we don't return that vbt_pin, but only return 0 instead. This basically reverts commit 'a8e6f3888b05 ("drm/i915/cnp: Ignore VBT request for know invalid DDC pin.")' Also this properly fixes commit 9c3b2689d01f ("drm/i915/cnl: Map VBT DDC Pin to BSpec DDC Pin.") v2: Do in a way that we don't break other platforms. (Jani) v3: Keep debug message (Jani) v4: Don't mess with 0 mapping was noticed by Jani and addressed with a simple solution suggested by Lucas that makes this even simpler. Fixes: a8e6f3888b05 ("drm/i915/cnp: Ignore VBT request for know invalid DDC pin.") Fixes: 9c3b2689d01f ("drm/i915/cnl: Map VBT DDC Pin to BSpec DDC Pin.") Cc: Radhakrishna Sripada <radhakrishna.sripada(a)intel.com> Cc: Jani Nikula <jani.nikula(a)intel.com> Cc: Kai Heng Feng <kai.heng.feng(a)canonical.com> Cc: Lucas De Marchi <lucas.demarchi(a)intel.com> Suggested-by: Lucas De Marchi <lucas.demarchi(a)intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi(a)intel.com> Tested-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180125222524.22059-1-rodrig… (cherry picked from commit 3393ce1ed8fc43dbdb83952facaf04e644ca1d54) Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/i915/intel_bios.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -1107,6 +1107,7 @@ static void sanitize_aux_ch(struct drm_i } static const u8 cnp_ddc_pin_map[] = { + [0] = 0, /* N/A */ [DDC_BUS_DDI_B] = GMBUS_PIN_1_BXT, [DDC_BUS_DDI_C] = GMBUS_PIN_2_BXT, [DDC_BUS_DDI_D] = GMBUS_PIN_4_CNP, /* sic */ @@ -1116,9 +1117,9 @@ static const u8 cnp_ddc_pin_map[] = { static u8 map_ddc_pin(struct drm_i915_private *dev_priv, u8 vbt_pin) { if (HAS_PCH_CNP(dev_priv)) { - if (vbt_pin > 0 && vbt_pin < ARRAY_SIZE(cnp_ddc_pin_map)) + if (vbt_pin < ARRAY_SIZE(cnp_ddc_pin_map)) { return cnp_ddc_pin_map[vbt_pin]; - if (vbt_pin > GMBUS_PIN_4_CNP) { + } else { DRM_DEBUG_KMS("Ignoring alternate pin: VBT claims DDC pin %d, which is not valid for this platform\n", vbt_pin); return 0; } Patches currently in stable-queue which might be from rodrigo.vivi(a)intel.com are queue-4.15/drm-i915-cnp-properly-handle-vbt-ddc-pin-out-of-bounds.patch queue-4.15/drm-i915-cnp-ignore-vbt-request-for-know-invalid-ddc-pin.patch

7 years, 2 months

1
0
0 0

Patch "Bluetooth: hci_bcm: Make shutdown and device wake GPIO optional" 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 Bluetooth: hci_bcm: Make shutdown and device wake GPIO optional 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: bluetooth-hci_bcm-make-shutdown-and-device-wake-gpio-optional.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 ab2f336cb7e629de74d8af06bcaf6b15e4230e19 Mon Sep 17 00:00:00 2001 From: Stefan Wahren <stefan.wahren(a)i2se.com> Date: Sun, 25 Feb 2018 15:10:52 +0100 Subject: Bluetooth: hci_bcm: Make shutdown and device wake GPIO optional From: Stefan Wahren <stefan.wahren(a)i2se.com> commit ab2f336cb7e629de74d8af06bcaf6b15e4230e19 upstream. According to the devicetree binding the shutdown and device wake GPIOs are optional. Since commit 3e81a4ca51a1 ("Bluetooth: hci_bcm: Mandate presence of shutdown and device wake GPIO") this driver won't probe anymore on Raspberry Pi 3 and Zero W (no device wake GPIO connected). So fix this regression by reverting this commit partially. Fixes: 3e81a4ca51a1 ("Bluetooth: hci_bcm: Mandate presence of shutdown and device wake GPIO") Signed-off-by: Stefan Wahren <stefan.wahren(a)i2se.com> Reviewed-by: Lukas Wunner <lukas(a)wunner.de> Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bluetooth/hci_bcm.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/drivers/bluetooth/hci_bcm.c +++ b/drivers/bluetooth/hci_bcm.c @@ -775,12 +775,13 @@ static int bcm_get_resources(struct bcm_ dev->clk = devm_clk_get(dev->dev, NULL); - dev->device_wakeup = devm_gpiod_get(dev->dev, "device-wakeup", - GPIOD_OUT_LOW); + dev->device_wakeup = devm_gpiod_get_optional(dev->dev, "device-wakeup", + GPIOD_OUT_LOW); if (IS_ERR(dev->device_wakeup)) return PTR_ERR(dev->device_wakeup); - dev->shutdown = devm_gpiod_get(dev->dev, "shutdown", GPIOD_OUT_LOW); + dev->shutdown = devm_gpiod_get_optional(dev->dev, "shutdown", + GPIOD_OUT_LOW); if (IS_ERR(dev->shutdown)) return PTR_ERR(dev->shutdown); Patches currently in stable-queue which might be from stefan.wahren(a)i2se.com are queue-4.15/bluetooth-hci_bcm-make-shutdown-and-device-wake-gpio-optional.patch

7 years, 2 months

1
0
0 0

Patch "nvme-fabrics: protect against module unload during create_ctrl" 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 nvme-fabrics: protect against module unload during create_ctrl 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: nvme-fabrics-protect-against-module-unload-during-create_ctrl.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Roy Shterman <roys(a)lightbitslabs.com> Date: Mon, 25 Dec 2017 14:18:30 +0200 Subject: nvme-fabrics: protect against module unload during create_ctrl From: Roy Shterman <roys(a)lightbitslabs.com> [ Upstream commit 0de5cd367c6aa2a31a1c931628f778f79f8ef22e ] NVMe transport driver module unload may (and usually does) trigger iteration over the active controllers and delete them all (sometimes under a mutex). However, a controller can be created concurrently with module unload which can lead to leakage of resources (most important char device node leakage) in case the controller creation occured after the unload delete and drain sequence. To protect against this, we take a module reference to guarantee that the nvme transport driver is not unloaded while creating a controller. Signed-off-by: Roy Shterman <roys(a)lightbitslabs.com> Signed-off-by: Sagi Grimberg <sagi(a)grimberg.me> Reviewed-by: Max Gurtovoy <maxg(a)mellanox.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/nvme/host/fabrics.c | 17 +++++++++++++---- drivers/nvme/host/fabrics.h | 2 ++ drivers/nvme/host/fc.c | 1 + drivers/nvme/host/rdma.c | 1 + drivers/nvme/target/loop.c | 1 + 5 files changed, 18 insertions(+), 4 deletions(-) --- a/drivers/nvme/host/fabrics.c +++ b/drivers/nvme/host/fabrics.c @@ -493,7 +493,7 @@ EXPORT_SYMBOL_GPL(nvmf_should_reconnect) */ int nvmf_register_transport(struct nvmf_transport_ops *ops) { - if (!ops->create_ctrl) + if (!ops->create_ctrl || !ops->module) return -EINVAL; down_write(&nvmf_transports_rwsem); @@ -869,32 +869,41 @@ nvmf_create_ctrl(struct device *dev, con goto out_unlock; } + if (!try_module_get(ops->module)) { + ret = -EBUSY; + goto out_unlock; + } + ret = nvmf_check_required_opts(opts, ops->required_opts); if (ret) - goto out_unlock; + goto out_module_put; ret = nvmf_check_allowed_opts(opts, NVMF_ALLOWED_OPTS | ops->allowed_opts | ops->required_opts); if (ret) - goto out_unlock; + goto out_module_put; ctrl = ops->create_ctrl(dev, opts); if (IS_ERR(ctrl)) { ret = PTR_ERR(ctrl); - goto out_unlock; + goto out_module_put; } if (strcmp(ctrl->subsys->subnqn, opts->subsysnqn)) { dev_warn(ctrl->device, "controller returned incorrect NQN: \"%s\".\n", ctrl->subsys->subnqn); + module_put(ops->module); up_read(&nvmf_transports_rwsem); nvme_delete_ctrl_sync(ctrl); return ERR_PTR(-EINVAL); } + module_put(ops->module); up_read(&nvmf_transports_rwsem); return ctrl; +out_module_put: + module_put(ops->module); out_unlock: up_read(&nvmf_transports_rwsem); out_free_opts: --- a/drivers/nvme/host/fabrics.h +++ b/drivers/nvme/host/fabrics.h @@ -108,6 +108,7 @@ struct nvmf_ctrl_options { * fabric implementation of NVMe fabrics. * @entry: Used by the fabrics library to add the new * registration entry to its linked-list internal tree. + * @module: Transport module reference * @name: Name of the NVMe fabric driver implementation. * @required_opts: sysfs command-line options that must be specified * when adding a new NVMe controller. @@ -126,6 +127,7 @@ struct nvmf_ctrl_options { */ struct nvmf_transport_ops { struct list_head entry; + struct module *module; const char *name; int required_opts; int allowed_opts; --- a/drivers/nvme/host/fc.c +++ b/drivers/nvme/host/fc.c @@ -3380,6 +3380,7 @@ nvme_fc_create_ctrl(struct device *dev, static struct nvmf_transport_ops nvme_fc_transport = { .name = "fc", + .module = THIS_MODULE, .required_opts = NVMF_OPT_TRADDR | NVMF_OPT_HOST_TRADDR, .allowed_opts = NVMF_OPT_RECONNECT_DELAY | NVMF_OPT_CTRL_LOSS_TMO, .create_ctrl = nvme_fc_create_ctrl, --- a/drivers/nvme/host/rdma.c +++ b/drivers/nvme/host/rdma.c @@ -2018,6 +2018,7 @@ out_free_ctrl: static struct nvmf_transport_ops nvme_rdma_transport = { .name = "rdma", + .module = THIS_MODULE, .required_opts = NVMF_OPT_TRADDR, .allowed_opts = NVMF_OPT_TRSVCID | NVMF_OPT_RECONNECT_DELAY | NVMF_OPT_HOST_TRADDR | NVMF_OPT_CTRL_LOSS_TMO, --- a/drivers/nvme/target/loop.c +++ b/drivers/nvme/target/loop.c @@ -686,6 +686,7 @@ static struct nvmet_fabrics_ops nvme_loo static struct nvmf_transport_ops nvme_loop_transport = { .name = "loop", + .module = THIS_MODULE, .create_ctrl = nvme_loop_create_ctrl, }; Patches currently in stable-queue which might be from roys(a)lightbitslabs.com are queue-4.15/nvme-fabrics-protect-against-module-unload-during-create_ctrl.patch

7 years, 2 months

3
2
0 0

Patch "Bluetooth: hci_bcm: Mandate presence of shutdown and device wake GPIO" 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 Bluetooth: hci_bcm: Mandate presence of shutdown and device wake GPIO 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: bluetooth-hci_bcm-mandate-presence-of-shutdown-and-device-wake-gpio.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Lukas Wunner <lukas(a)wunner.de> Date: Wed, 10 Jan 2018 16:32:10 +0100 Subject: Bluetooth: hci_bcm: Mandate presence of shutdown and device wake GPIO From: Lukas Wunner <lukas(a)wunner.de> [ Upstream commit 3e81a4ca51a1172253078ca7abd6a91040b8fcf4 ] Commit 0395ffc1ee05 ("Bluetooth: hci_bcm: Add PM for BCM devices") amended this driver to request a shutdown and device wake GPIO on probe, but mandated that only one of them need to be present: /* Make sure at-least one of the GPIO is defined and that * a name is specified for this instance */ if ((!dev->device_wakeup && !dev->shutdown) || !dev->name) { dev_err(&pdev->dev, "invalid platform data\n"); return -EINVAL; } However the same commit added a call to bcm_gpio_set_power() to the ->probe hook, which unconditionally accesses *both* GPIOs. Luckily, the resulting NULL pointer deref was never reported, suggesting there's no machine where either GPIO is missing. Commit 8a92056837fd ("Bluetooth: hci_bcm: Add (runtime)pm support to the serdev driver") removed the check whether at least one of the GPIOs is present without specifying a reason. Because commit 62aaefa7d038 ("Bluetooth: hci_bcm: improve use of gpios API") refactored the driver to use devm_gpiod_get_optional() instead of devm_gpiod_get(), one is now tempted to believe that the driver doesn't require *any* of the two GPIOs. Which is wrong, the driver still requires both GPIOs to avoid a NULL pointer deref. To this end, establish the status quo ante and request the GPIOs with devm_gpiod_get() again. Bail out of ->probe if either of them is missing. Oddly enough, whereas bcm_gpio_set_power() accesses the device wake pin unconditionally, bcm_suspend_device() and bcm_resume_device() do check for its presence before accessing it. Those checks are superfluous, so remove them. Cc: Frédéric Danis <frederic.danis.oss(a)gmail.com> Cc: Loic Poulain <loic.poulain(a)linaro.org> Cc: Hans de Goede <hdegoede(a)redhat.com> Cc: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Cc: Linus Walleij <linus.walleij(a)linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Lukas Wunner <lukas(a)wunner.de> Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bluetooth/hci_bcm.c | 24 +++++++++--------------- 1 file changed, 9 insertions(+), 15 deletions(-) --- a/drivers/bluetooth/hci_bcm.c +++ b/drivers/bluetooth/hci_bcm.c @@ -577,11 +577,9 @@ static int bcm_suspend_device(struct dev } /* Suspend the device */ - if (bdev->device_wakeup) { - gpiod_set_value(bdev->device_wakeup, false); - bt_dev_dbg(bdev, "suspend, delaying 15 ms"); - mdelay(15); - } + gpiod_set_value(bdev->device_wakeup, false); + bt_dev_dbg(bdev, "suspend, delaying 15 ms"); + mdelay(15); return 0; } @@ -592,11 +590,9 @@ static int bcm_resume_device(struct devi bt_dev_dbg(bdev, ""); - if (bdev->device_wakeup) { - gpiod_set_value(bdev->device_wakeup, true); - bt_dev_dbg(bdev, "resume, delaying 15 ms"); - mdelay(15); - } + gpiod_set_value(bdev->device_wakeup, true); + bt_dev_dbg(bdev, "resume, delaying 15 ms"); + mdelay(15); /* When this executes, the device has woken up already */ if (bdev->is_suspended && bdev->hu) { @@ -779,14 +775,12 @@ static int bcm_get_resources(struct bcm_ dev->clk = devm_clk_get(dev->dev, NULL); - dev->device_wakeup = devm_gpiod_get_optional(dev->dev, - "device-wakeup", - GPIOD_OUT_LOW); + dev->device_wakeup = devm_gpiod_get(dev->dev, "device-wakeup", + GPIOD_OUT_LOW); if (IS_ERR(dev->device_wakeup)) return PTR_ERR(dev->device_wakeup); - dev->shutdown = devm_gpiod_get_optional(dev->dev, "shutdown", - GPIOD_OUT_LOW); + dev->shutdown = devm_gpiod_get(dev->dev, "shutdown", GPIOD_OUT_LOW); if (IS_ERR(dev->shutdown)) return PTR_ERR(dev->shutdown); Patches currently in stable-queue which might be from lukas(a)wunner.de are queue-4.15/bluetooth-hci_bcm-mandate-presence-of-shutdown-and-device-wake-gpio.patch queue-4.15/bluetooth-hci_bcm-validate-irq-before-using-it.patch

7 years, 2 months

3
2
0 0

Patch "netfilter: core: only allow one nat hook per hook point" 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 netfilter: core: only allow one nat hook per hook point 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: netfilter-core-only-allow-one-nat-hook-per-hook-point.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Florian Westphal <fw(a)strlen.de> Date: Fri, 8 Dec 2017 17:01:54 +0100 Subject: netfilter: core: only allow one nat hook per hook point From: Florian Westphal <fw(a)strlen.de> [ Upstream commit f92b40a8b2645af38bd6814651c59c1e690db53d ] The netfilter NAT core cannot deal with more than one NAT hook per hook location (prerouting, input ...), because the NAT hooks install a NAT null binding in case the iptables nat table (iptable_nat hooks) or the corresponding nftables chain (nft nat hooks) doesn't specify a nat transformation. Null bindings are needed to detect port collsisions between NAT-ed and non-NAT-ed connections. This causes nftables NAT rules to not work when iptable_nat module is loaded, and vice versa because nat binding has already been attached when the second nat hook is consulted. The netfilter core is not really the correct location to handle this (hooks are just hooks, the core has no notion of what kinds of side effects a hook implements), but its the only place where we can check for conflicts between both iptables hooks and nftables hooks without adding dependencies. So add nat annotation to hook_ops to describe those hooks that will add NAT bindings and then make core reject if such a hook already exists. The annotation fills a padding hole, in case further restrictions appar we might change this to a 'u8 type' instead of bool. iptables error if nft nat hook active: iptables -t nat -A POSTROUTING -j MASQUERADE iptables v1.4.21: can't initialize iptables table `nat': File exists Perhaps iptables or your kernel needs to be upgraded. nftables error if iptables nat table present: nft -f /etc/nftables/ipv4-nat /usr/etc/nftables/ipv4-nat:3:1-2: Error: Could not process rule: File exists table nat { ^^ Signed-off-by: Florian Westphal <fw(a)strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/netfilter.h | 1 + net/ipv4/netfilter/iptable_nat.c | 4 ++++ net/ipv6/netfilter/ip6table_nat.c | 4 ++++ net/netfilter/core.c | 6 ++++++ net/netfilter/nf_tables_api.c | 2 ++ 5 files changed, 17 insertions(+) --- a/include/linux/netfilter.h +++ b/include/linux/netfilter.h @@ -67,6 +67,7 @@ struct nf_hook_ops { struct net_device *dev; void *priv; u_int8_t pf; + bool nat_hook; unsigned int hooknum; /* Hooks are ordered in ascending priority. */ int priority; --- a/net/ipv4/netfilter/iptable_nat.c +++ b/net/ipv4/netfilter/iptable_nat.c @@ -72,6 +72,7 @@ static const struct nf_hook_ops nf_nat_i { .hook = iptable_nat_ipv4_in, .pf = NFPROTO_IPV4, + .nat_hook = true, .hooknum = NF_INET_PRE_ROUTING, .priority = NF_IP_PRI_NAT_DST, }, @@ -79,6 +80,7 @@ static const struct nf_hook_ops nf_nat_i { .hook = iptable_nat_ipv4_out, .pf = NFPROTO_IPV4, + .nat_hook = true, .hooknum = NF_INET_POST_ROUTING, .priority = NF_IP_PRI_NAT_SRC, }, @@ -86,6 +88,7 @@ static const struct nf_hook_ops nf_nat_i { .hook = iptable_nat_ipv4_local_fn, .pf = NFPROTO_IPV4, + .nat_hook = true, .hooknum = NF_INET_LOCAL_OUT, .priority = NF_IP_PRI_NAT_DST, }, @@ -93,6 +96,7 @@ static const struct nf_hook_ops nf_nat_i { .hook = iptable_nat_ipv4_fn, .pf = NFPROTO_IPV4, + .nat_hook = true, .hooknum = NF_INET_LOCAL_IN, .priority = NF_IP_PRI_NAT_SRC, }, --- a/net/ipv6/netfilter/ip6table_nat.c +++ b/net/ipv6/netfilter/ip6table_nat.c @@ -74,6 +74,7 @@ static const struct nf_hook_ops nf_nat_i { .hook = ip6table_nat_in, .pf = NFPROTO_IPV6, + .nat_hook = true, .hooknum = NF_INET_PRE_ROUTING, .priority = NF_IP6_PRI_NAT_DST, }, @@ -81,6 +82,7 @@ static const struct nf_hook_ops nf_nat_i { .hook = ip6table_nat_out, .pf = NFPROTO_IPV6, + .nat_hook = true, .hooknum = NF_INET_POST_ROUTING, .priority = NF_IP6_PRI_NAT_SRC, }, @@ -88,12 +90,14 @@ static const struct nf_hook_ops nf_nat_i { .hook = ip6table_nat_local_fn, .pf = NFPROTO_IPV6, + .nat_hook = true, .hooknum = NF_INET_LOCAL_OUT, .priority = NF_IP6_PRI_NAT_DST, }, /* After packet filtering, change source */ { .hook = ip6table_nat_fn, + .nat_hook = true, .pf = NFPROTO_IPV6, .hooknum = NF_INET_LOCAL_IN, .priority = NF_IP6_PRI_NAT_SRC, --- a/net/netfilter/core.c +++ b/net/netfilter/core.c @@ -135,6 +135,12 @@ nf_hook_entries_grow(const struct nf_hoo ++i; continue; } + + if (reg->nat_hook && orig_ops[i]->nat_hook) { + kvfree(new); + return ERR_PTR(-EEXIST); + } + if (inserted || reg->priority > orig_ops[i]->priority) { new_ops[nhooks] = (void *)orig_ops[i]; new->hooks[nhooks] = old->hooks[i]; --- a/net/netfilter/nf_tables_api.c +++ b/net/netfilter/nf_tables_api.c @@ -1400,6 +1400,8 @@ static int nf_tables_addchain(struct nft ops->hook = hookfn; if (afi->hook_ops_init) afi->hook_ops_init(ops, i); + if (basechain->type->type == NFT_CHAIN_T_NAT) + ops->nat_hook = true; } chain->flags |= NFT_BASE_CHAIN; Patches currently in stable-queue which might be from fw(a)strlen.de are queue-4.15/netfilter-core-only-allow-one-nat-hook-per-hook-point.patch

7 years, 2 months

3
2
0 0

[PATCH 2/8] blk-mq: don't keep offline CPUs mapped to hctx 0

by Ming Lei

>From commit 4b855ad37194 ("blk-mq: Create hctx for each present CPU), blk-mq doesn't remap queue after CPU topo is changed, that said when some of these offline CPUs become online, they are still mapped to hctx 0, then hctx 0 may become the bottleneck of IO dispatch and completion. This patch sets up the mapping from the beginning, and aligns to queue mapping for PCI device (blk_mq_pci_map_queues()). Fixes: 4b855ad37194 ("blk-mq: Create hctx for each present CPU) Cc: Christian Borntraeger <borntraeger(a)de.ibm.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Stefan Haberland <sth(a)linux.vnet.ibm.com> Cc: Keith Busch <keith.busch(a)intel.com> Cc: stable(a)vger.kernel.org Signed-off-by: Ming Lei <ming.lei(a)redhat.com> --- block/blk-mq-cpumap.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/block/blk-mq-cpumap.c b/block/blk-mq-cpumap.c index 9f8cffc8a701..3eb169f15842 100644 --- a/block/blk-mq-cpumap.c +++ b/block/blk-mq-cpumap.c @@ -16,11 +16,6 @@ static int cpu_to_queue_index(unsigned int nr_queues, const int cpu) { - /* - * Non present CPU will be mapped to queue index 0. - */ - if (!cpu_present(cpu)) - return 0; return cpu % nr_queues; } -- 2.9.5

7 years, 2 months

3
2
0 0

[PATCH 1/8] blk-mq: make sure that correct hctx->next_cpu is set

by Ming Lei

>From commit 20e4d81393196 (blk-mq: simplify queue mapping & schedule with each possisble CPU), one hctx can be mapped from all offline CPUs, then hctx->next_cpu can be set as wrong. This patch fixes this issue by making hctx->next_cpu pointing to the first CPU in hctx->cpumask if all CPUs in hctx->cpumask are offline. Cc: Christian Borntraeger <borntraeger(a)de.ibm.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Stefan Haberland <sth(a)linux.vnet.ibm.com> Fixes: 20e4d81393196 ("blk-mq: simplify queue mapping & schedule with each possisble CPU") Cc: stable(a)vger.kernel.org Signed-off-by: Ming Lei <ming.lei(a)redhat.com> --- block/blk-mq.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/block/blk-mq.c b/block/blk-mq.c index f5c7dbcb954f..9b220dc415ac 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -2432,6 +2432,8 @@ static void blk_mq_map_swqueue(struct request_queue *q) */ hctx->next_cpu = cpumask_first_and(hctx->cpumask, cpu_online_mask); + if (hctx->next_cpu >= nr_cpu_ids) + hctx->next_cpu = cpumask_first(hctx->cpumask); hctx->next_cpu_batch = BLK_MQ_CPU_WORK_BATCH; } } -- 2.9.5

7 years, 2 months

3
2
0 0

dma-mapping: clear harmful GFP_* flags in common code

by Alexey Brodkin

Hello, May we have e89f5b370153 ("dma-mapping: Don't clear GFP_ZERO in dma_alloc_attrs") back-ported to 4.16 kernel as it fixes: 57bf5a8 ("dma-mapping: clear harmful GFP_* flags in common code"). For more info about introduced problem see this thread: http://lists.infradead.org/pipermail/linux-snps-arc/2018-March/003652.html -Alexey

7 years, 2 months

1
0
0 0

Grüße von Frau Jordanka

by noreply＠parador.es

Nachricht des Absenders: /Guten Morgen, Bitte schämen Sie sich nicht, diese Nachricht zu lesen, weil Sie der beabsichtigte Empfänger sind. Ich habe deine E-Mail-Adresse über ein Verzeichnis gesehen und ich habe dich kontaktiert, weil ich dringend deine Hilfe benötigt habe. Mein Name ist Frau Yordanka Velikova Nencheva. Ich bin 69 Jahre alt und bin rechtmäßig mit dem verstorbenen Herrn Peter Nencheva verheiratet. Ich und mein verstorbener Ehemann waren beide Bürger von Bulgarien, aber wir lebten hier in der Elfenbeinküste in Westafrika seit 28 Jahren. Mein verstorbener Ehemann arbeitete viele Jahre lang als Expatriate hier in der Elfenbeinküste, bevor er bei einem tödlichen Autounfall starb, bei dem er und sein Fahrer hier in der Elfenbeinküste ums Leben kamen. Ich und mein verstorbener Mann waren beide verheiratet, ohne ein eigenes leibliches Kind. Ich habe derzeit eine schwere Brustkrebskrankheit und schreibe diese Nachricht mit Hilfe eines Arztes hier im Krankenhaus in der Elfenbeinküste. Als mein verstorbener Ehemann noch am Leben war, hinterlegte er die Summe von einer Million fünfhunderttausend Euro (1,500,000.00 Euro) bei der Westra Wermlands Sparbank http://www.warbarbank.se/ in Schweden, die er mit der Bank eine Vereinbarung unterzeichnete die Mittel werden für wohltätige Zwecke verwendet, wie z. Hilfe für die mutterlosen Babys, Unterstützung der kirchlichen Aktivitäten und Unterstützung der nicht privilegierten Kinder, ihre Ausbildung fortzusetzen. Mein Mann hat diese Entscheidung für diese karitative Arbeit getroffen, weil wir kein Kind haben, das die Gelder in der schwedischen Bank erbt, und er wurde von einem Waisenhaus in Sofia, Bulgarien, erzogen, weil er keine Familie in Bulgarien hat. Ich kontaktierte Sie heute, weil mein Arzt mich gerade darüber informiert hat, dass meine Brustkrebskrankheit am schlimmsten geworden ist und sie nächste Woche eine schwere / tödliche Krebsoperation durchführen werden, die ich vielleicht nicht überleben würde, weil der Tod tief in meinem Körpersystem gefressen hat. Ich fürchte, wenn ich nächste Woche während meiner Operation sterbe, werden die Gelder in der schwedischen Bank vergessen, weil ich keinen anderen Verwandten habe, der behauptet, dass ich keine Familie meines verstorbenen Ehemannes in Bulgarien finden kann. Hinweis: Ich möchte, dass Sie mir helfen, das Geld auf Ihr eigenes Bankkonto zu überweisen und es auf Ihr Bankkonto zu überweisen. Sie werden 30% (450.000,00 Euro) des Gesamtbetrages für sich selbst als Entschädigung einstreichen und die restlichen 70% (1,50, 000,00 Euro) für die Wohltätigkeitsarbeit in Ihrem Land verwenden. Bitte antworten Sie mir dringend, wenn Sie daran interessiert sind, mir bei dieser Transaktion zu helfen, damit ich Ihnen weitere Einzelheiten zusenden kann, da ich möchte, dass die Mittel vor meiner bevorstehenden Operation nächste Woche überwiesen werden. Mit freundlichen Grüßen, Frau Yordanka Nencheva Velikova/ Parador de Alcañiz [1] [1] http://www.parador.es/de/paradores/parador-de-alcaniz

7 years, 2 months

1
0
0 0

Patch "x86/gart: Exclude GART aperture from vmcore" 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 x86/gart: Exclude GART aperture from vmcore 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: x86-gart-exclude-gart-aperture-from-vmcore.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Jiri Bohac <jbohac(a)suse.cz> Date: Sat, 6 Jan 2018 02:00:13 +0100 Subject: x86/gart: Exclude GART aperture from vmcore From: Jiri Bohac <jbohac(a)suse.cz> [ Upstream commit 2a3e83c6f96c513f43ce5a8c9034608ea584a255 ] On machines where the GART aperture is mapped over physical RAM /proc/vmcore contains the remapped range and reading it may cause hangs or reboots. In the past, the GART region was added into the resource map, implemented by commit 56dd669a138c ("[PATCH] Insert GART region into resource map") However, inserting the iomem_resource from the early GART code caused resource conflicts with some AGP drivers (bko#72201), which got avoided by reverting the patch in commit 707d4eefbdb3 ("Revert [PATCH] Insert GART region into resource map"). This revert introduced the /proc/vmcore bug. The vmcore ELF header is either prepared by the kernel (when using the kexec_file_load syscall) or by the kexec userspace (when using the kexec_load syscall). Since we no longer have the GART iomem resource, the userspace kexec has no way of knowing which region to exclude from the ELF header. Changes from v1 of this patch: Instead of excluding the aperture from the ELF header, this patch makes /proc/vmcore return zeroes in the second kernel when attempting to read the aperture region. This is done by reusing the gart_oldmem_pfn_is_ram infrastructure originally intended to exclude XEN balooned memory. This works for both, the kexec_file_load and kexec_load syscalls. [Note that the GART region is the same in the first and second kernels: regardless whether the first kernel fixed up the northbridge/bios setting and mapped the aperture over physical memory, the second kernel finds the northbridge properly configured by the first kernel and the aperture never overlaps with e820 memory because the second kernel has a fake e820 map created from the crashkernel memory regions. Thus, the second kernel keeps the aperture address/size as configured by the first kernel.] register_oldmem_pfn_is_ram can only register one callback and returns an error if the callback has been registered already. Since XEN used to be the only user of this function, it never checks the return value. Now that we have more than one user, I added a WARN_ON just in case agp, XEN, or any other future user of register_oldmem_pfn_is_ram were to step on each other's toes. Fixes: 707d4eefbdb3 ("Revert [PATCH] Insert GART region into resource map") Signed-off-by: Jiri Bohac <jbohac(a)suse.cz> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Baoquan He <bhe(a)redhat.com> Cc: Toshi Kani <toshi.kani(a)hpe.com> Cc: David Airlie <airlied(a)linux.ie> Cc: yinghai(a)kernel.org Cc: joro(a)8bytes.org Cc: kexec(a)lists.infradead.org Cc: Borislav Petkov <bp(a)alien8.de> Cc: Bjorn Helgaas <bhelgaas(a)google.com> Cc: Dave Young <dyoung(a)redhat.com> Cc: Vivek Goyal <vgoyal(a)redhat.com> Link: https://lkml.kernel.org/r/20180106010013.73suskgxm7lox7g6@dwarf.suse.cz Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/aperture_64.c | 46 +++++++++++++++++++++++++++++++++++++++++- arch/x86/xen/mmu_hvm.c | 2 - 2 files changed, 46 insertions(+), 2 deletions(-) --- a/arch/x86/kernel/aperture_64.c +++ b/arch/x86/kernel/aperture_64.c @@ -30,6 +30,7 @@ #include <asm/dma.h> #include <asm/amd_nb.h> #include <asm/x86_init.h> +#include <linux/crash_dump.h> /* * Using 512M as goal, in case kexec will load kernel_big @@ -56,6 +57,33 @@ int fallback_aper_force __initdata; int fix_aperture __initdata = 1; +#ifdef CONFIG_PROC_VMCORE +/* + * If the first kernel maps the aperture over e820 RAM, the kdump kernel will + * use the same range because it will remain configured in the northbridge. + * Trying to dump this area via /proc/vmcore may crash the machine, so exclude + * it from vmcore. + */ +static unsigned long aperture_pfn_start, aperture_page_count; + +static int gart_oldmem_pfn_is_ram(unsigned long pfn) +{ + return likely((pfn < aperture_pfn_start) || + (pfn >= aperture_pfn_start + aperture_page_count)); +} + +static void exclude_from_vmcore(u64 aper_base, u32 aper_order) +{ + aperture_pfn_start = aper_base >> PAGE_SHIFT; + aperture_page_count = (32 * 1024 * 1024) << aper_order >> PAGE_SHIFT; + WARN_ON(register_oldmem_pfn_is_ram(&gart_oldmem_pfn_is_ram)); +} +#else +static void exclude_from_vmcore(u64 aper_base, u32 aper_order) +{ +} +#endif + /* This code runs before the PCI subsystem is initialized, so just access the northbridge directly. */ @@ -435,8 +463,16 @@ int __init gart_iommu_hole_init(void) out: if (!fix && !fallback_aper_force) { - if (last_aper_base) + if (last_aper_base) { + /* + * If this is the kdump kernel, the first kernel + * may have allocated the range over its e820 RAM + * and fixed up the northbridge + */ + exclude_from_vmcore(last_aper_base, last_aper_order); + return 1; + } return 0; } @@ -473,6 +509,14 @@ out: return 0; } + /* + * If this is the kdump kernel _and_ the first kernel did not + * configure the aperture in the northbridge, this range may + * overlap with the first kernel's memory. We can't access the + * range through vmcore even though it should be part of the dump. + */ + exclude_from_vmcore(aper_alloc, aper_order); + /* Fix up the north bridges */ for (i = 0; i < amd_nb_bus_dev_ranges[i].dev_limit; i++) { int bus, dev_base, dev_limit; --- a/arch/x86/xen/mmu_hvm.c +++ b/arch/x86/xen/mmu_hvm.c @@ -75,6 +75,6 @@ void __init xen_hvm_init_mmu_ops(void) if (is_pagetable_dying_supported()) pv_mmu_ops.exit_mmap = xen_hvm_exit_mmap; #ifdef CONFIG_PROC_VMCORE - register_oldmem_pfn_is_ram(&xen_oldmem_pfn_is_ram); + WARN_ON(register_oldmem_pfn_is_ram(&xen_oldmem_pfn_is_ram)); #endif } Patches currently in stable-queue which might be from jbohac(a)suse.cz are queue-4.15/x86-gart-exclude-gart-aperture-from-vmcore.patch

7 years, 2 months

1
0
0 0

Patch "watchdog: dw_wdt: add stop watchdog operation" 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 watchdog: dw_wdt: add stop watchdog operation 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: watchdog-dw_wdt-add-stop-watchdog-operation.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Oleksij Rempel <o.rempel(a)pengutronix.de> Date: Tue, 26 Sep 2017 08:11:22 +0200 Subject: watchdog: dw_wdt: add stop watchdog operation From: Oleksij Rempel <o.rempel(a)pengutronix.de> [ Upstream commit 1bfe8889380890efe4943d125124f5a7b48571b0 ] The only way of stopping the watchdog is by resetting it. Add the watchdog op for stopping the device and reset if a reset line is provided. At same time WDOG_HW_RUNNING should be remove from dw_wdt_start. As commented by Guenter Roeck: dw_wdt sets WDOG_HW_RUNNING in its open function. Result is that the kref_get() in watchdog_open() won't be executed. But then kref_put() in close will be called since the watchdog now does stop. This causes the imbalance. Signed-off-by: Oleksij Rempel <o.rempel(a)pengutronix.de> Cc: Wim Van Sebroeck <wim(a)iguana.be> Cc: Guenter Roeck <linux(a)roeck-us.net> Cc: linux-watchdog(a)vger.kernel.org Reviewed-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim(a)iguana.be> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/watchdog/dw_wdt.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) --- a/drivers/watchdog/dw_wdt.c +++ b/drivers/watchdog/dw_wdt.c @@ -127,14 +127,27 @@ static int dw_wdt_start(struct watchdog_ dw_wdt_set_timeout(wdd, wdd->timeout); - set_bit(WDOG_HW_RUNNING, &wdd->status); - writel(WDOG_CONTROL_REG_WDT_EN_MASK, dw_wdt->regs + WDOG_CONTROL_REG_OFFSET); return 0; } +static int dw_wdt_stop(struct watchdog_device *wdd) +{ + struct dw_wdt *dw_wdt = to_dw_wdt(wdd); + + if (!dw_wdt->rst) { + set_bit(WDOG_HW_RUNNING, &wdd->status); + return 0; + } + + reset_control_assert(dw_wdt->rst); + reset_control_deassert(dw_wdt->rst); + + return 0; +} + static int dw_wdt_restart(struct watchdog_device *wdd, unsigned long action, void *data) { @@ -173,6 +186,7 @@ static const struct watchdog_info dw_wdt static const struct watchdog_ops dw_wdt_ops = { .owner = THIS_MODULE, .start = dw_wdt_start, + .stop = dw_wdt_stop, .ping = dw_wdt_ping, .set_timeout = dw_wdt_set_timeout, .get_timeleft = dw_wdt_get_timeleft, Patches currently in stable-queue which might be from o.rempel(a)pengutronix.de are queue-4.15/watchdog-dw_wdt-add-stop-watchdog-operation.patch

7 years, 2 months

1
0
0 0

Patch "wl1251: check return from call to wl1251_acx_arp_ip_filter" 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 wl1251: check return from call to wl1251_acx_arp_ip_filter 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: wl1251-check-return-from-call-to-wl1251_acx_arp_ip_filter.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Colin Ian King <colin.king(a)canonical.com> Date: Tue, 26 Dec 2017 17:33:18 +0000 Subject: wl1251: check return from call to wl1251_acx_arp_ip_filter From: Colin Ian King <colin.king(a)canonical.com> [ Upstream commit ac1181c60822292176ab96912208ec9f9819faf8 ] Currently the less than zero error check on ret is incorrect as it is checking a far earlier ret assignment rather than the return from the call to wl1251_acx_arp_ip_filter. Fix this by adding in the missing assginment. Detected by CoverityScan, CID#1164835 ("Logically dead code") Fixes: 204cc5c44fb6 ("wl1251: implement hardware ARP filtering") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ti/wl1251/main.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/drivers/net/wireless/ti/wl1251/main.c +++ b/drivers/net/wireless/ti/wl1251/main.c @@ -1200,8 +1200,7 @@ static void wl1251_op_bss_info_changed(s WARN_ON(wl->bss_type != BSS_TYPE_STA_BSS); enable = bss_conf->arp_addr_cnt == 1 && bss_conf->assoc; - wl1251_acx_arp_ip_filter(wl, enable, addr); - + ret = wl1251_acx_arp_ip_filter(wl, enable, addr); if (ret < 0) goto out_sleep; } Patches currently in stable-queue which might be from colin.king(a)canonical.com are queue-4.15/wl1251-check-return-from-call-to-wl1251_acx_arp_ip_filter.patch

7 years, 2 months

1
0
0 0

Patch "VFS: close race between getcwd() and d_move()" 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 VFS: close race between getcwd() and d_move() 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: vfs-close-race-between-getcwd-and-d_move.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: NeilBrown <neilb(a)suse.com> Date: Fri, 10 Nov 2017 15:45:41 +1100 Subject: VFS: close race between getcwd() and d_move() From: NeilBrown <neilb(a)suse.com> [ Upstream commit 61647823aa920e395afcce4b57c32afb51456cab ] d_move() will call __d_drop() and then __d_rehash() on the dentry being moved. This creates a small window when the dentry appears to be unhashed. Many tests of d_unhashed() are made under ->d_lock and so are safe from racing with this window, but some aren't. In particular, getcwd() calls d_unlinked() (which calls d_unhashed()) without d_lock protection, so it can race. This races has been seen in practice with lustre, which uses d_move() as part of name lookup. See: https://jira.hpdd.intel.com/browse/LU-9735 It could race with a regular rename(), and result in ENOENT instead of either the 'before' or 'after' name. The race can be demonstrated with a simple program which has two threads, one renaming a directory back and forth while another calls getcwd() within that directory: it should never fail, but does. See: https://patchwork.kernel.org/patch/9455345/ We could fix this race by taking d_lock and rechecking when d_unhashed() reports true. Alternately when can remove the window, which is the approach this patch takes. ___d_drop() is introduce which does *not* clear d_hash.pprev so the dentry still appears to be hashed. __d_drop() calls ___d_drop(), then clears d_hash.pprev. __d_move() now uses ___d_drop() and only clears d_hash.pprev when not rehashing. Signed-off-by: NeilBrown <neilb(a)suse.com> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/dcache.c | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) --- a/fs/dcache.c +++ b/fs/dcache.c @@ -468,9 +468,11 @@ static void dentry_lru_add(struct dentry * d_drop() is used mainly for stuff that wants to invalidate a dentry for some * reason (NFS timeouts or autofs deletes). * - * __d_drop requires dentry->d_lock. + * __d_drop requires dentry->d_lock + * ___d_drop doesn't mark dentry as "unhashed" + * (dentry->d_hash.pprev will be LIST_POISON2, not NULL). */ -void __d_drop(struct dentry *dentry) +static void ___d_drop(struct dentry *dentry) { if (!d_unhashed(dentry)) { struct hlist_bl_head *b; @@ -486,12 +488,17 @@ void __d_drop(struct dentry *dentry) hlist_bl_lock(b); __hlist_bl_del(&dentry->d_hash); - dentry->d_hash.pprev = NULL; hlist_bl_unlock(b); /* After this call, in-progress rcu-walk path lookup will fail. */ write_seqcount_invalidate(&dentry->d_seq); } } + +void __d_drop(struct dentry *dentry) +{ + ___d_drop(dentry); + dentry->d_hash.pprev = NULL; +} EXPORT_SYMBOL(__d_drop); void d_drop(struct dentry *dentry) @@ -2386,7 +2393,7 @@ EXPORT_SYMBOL(d_delete); static void __d_rehash(struct dentry *entry) { struct hlist_bl_head *b = d_hash(entry->d_name.hash); - BUG_ON(!d_unhashed(entry)); + hlist_bl_lock(b); hlist_bl_add_head_rcu(&entry->d_hash, b); hlist_bl_unlock(b); @@ -2821,9 +2828,9 @@ static void __d_move(struct dentry *dent write_seqcount_begin_nested(&target->d_seq, DENTRY_D_LOCK_NESTED); /* unhash both */ - /* __d_drop does write_seqcount_barrier, but they're OK to nest. */ - __d_drop(dentry); - __d_drop(target); + /* ___d_drop does write_seqcount_barrier, but they're OK to nest. */ + ___d_drop(dentry); + ___d_drop(target); /* Switch the names.. */ if (exchange) @@ -2835,6 +2842,8 @@ static void __d_move(struct dentry *dent __d_rehash(dentry); if (exchange) __d_rehash(target); + else + target->d_hash.pprev = NULL; /* ... and switch them in the tree */ if (IS_ROOT(dentry)) { Patches currently in stable-queue which might be from neilb(a)suse.com are queue-4.15/staging-lustre-disable-preempt-while-sampling-processor-id.patch queue-4.15/vfs-close-race-between-getcwd-and-d_move.patch

7 years, 2 months

1
0
0 0

Patch "vfb: fix video mode and line_length being set when loaded" 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 vfb: fix video mode and line_length being set when loaded 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: vfb-fix-video-mode-and-line_length-being-set-when-loaded.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: "Pieter \\\"PoroCYon\\\" Sluys" <pcy(a)national.shitposting.agency> Date: Thu, 4 Jan 2018 16:53:50 +0100 Subject: vfb: fix video mode and line_length being set when loaded From: "Pieter \\\"PoroCYon\\\" Sluys" <pcy(a)national.shitposting.agency> [ Upstream commit 7b9faf5df0ac495a1a3d7cdb64921c179f9008ac ] Currently, when loading the vfb module, the newly created fbdev has a line_length of 0, and its video mode would be PSEUDOCOLOR regardless of color depth. (The former could be worked around by calling the FBIOPUT_VSCREENINFO ioctl with having the FBACTIVIATE_FORCE flag set.) This patch automatically sets the line_length correctly, and the video mode is derived from the bit depth now as well. Thanks to Geert Uytterhoeven for confirming the bug and helping me with the patch. Output of `fbset -i' before the patch: mode "1366x768-60" # D: 72.432 MHz, H: 47.403 kHz, V: 60.004 Hz geometry 1366 768 1366 768 32 timings 13806 120 10 14 3 32 5 rgba 8/0,8/8,8/16,8/24 endmode Frame buffer device information: Name : Virtual FB Address : 0xffffaa1405d85000 Size : 4196352 Type : PACKED PIXELS Visual : PSEUDOCOLOR XPanStep : 1 YPanStep : 1 YWrapStep : 1 LineLength : 0 <-- note this Accelerator : No After: mode "1366x768-60" # D: 72.432 MHz, H: 47.403 kHz, V: 60.004 Hz geometry 1366 768 1366 768 32 timings 13806 120 10 14 3 32 5 rgba 8/0,8/8,8/16,8/24 endmode Frame buffer device information: Name : Virtual FB Address : 0xffffaa1405d85000 Size : 4196352 Type : PACKED PIXELS Visual : TRUECOLOR XPanStep : 1 YPanStep : 1 YWrapStep : 1 LineLength : 5464 Accelerator : No Signed-off-by: "Pieter \"PoroCYon\" Sluys" <pcy(a)national.shitposting.agency> Reviewed-by: Geert Uytterhoeven <geert(a)linux-m68k.org> [b.zolnierkie: minor fixups] Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/fbdev/vfb.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) --- a/drivers/video/fbdev/vfb.c +++ b/drivers/video/fbdev/vfb.c @@ -239,8 +239,23 @@ static int vfb_check_var(struct fb_var_s */ static int vfb_set_par(struct fb_info *info) { + switch (info->var.bits_per_pixel) { + case 1: + info->fix.visual = FB_VISUAL_MONO01; + break; + case 8: + info->fix.visual = FB_VISUAL_PSEUDOCOLOR; + break; + case 16: + case 24: + case 32: + info->fix.visual = FB_VISUAL_TRUECOLOR; + break; + } + info->fix.line_length = get_line_length(info->var.xres_virtual, info->var.bits_per_pixel); + return 0; } @@ -450,6 +465,8 @@ static int vfb_probe(struct platform_dev goto err2; platform_set_drvdata(dev, info); + vfb_set_par(info); + fb_info(info, "Virtual frame buffer device, using %ldK of video memory\n", videomemorysize >> 10); return 0; Patches currently in stable-queue which might be from pcy(a)national.shitposting.agency are queue-4.15/vfb-fix-video-mode-and-line_length-being-set-when-loaded.patch

7 years, 2 months

1
0
0 0

Patch "tty: n_gsm: Allow ADM response in addition to UA for control dlci" 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 tty: n_gsm: Allow ADM response in addition to UA for control dlci 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: tty-n_gsm-allow-adm-response-in-addition-to-ua-for-control-dlci.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Tony Lindgren <tony(a)atomide.com> Date: Wed, 3 Jan 2018 10:18:03 -0800 Subject: tty: n_gsm: Allow ADM response in addition to UA for control dlci From: Tony Lindgren <tony(a)atomide.com> [ Upstream commit ea3d8465ab9b3e01be329ac5195970a84bef76c5 ] Some devices have the control dlci stay in ADM mode instead of the UA mode. This can seen at least on droid 4 when trying to open the ts 27.010 mux port. Enabling n_gsm debug mode shows the control dlci always respond with DM to SABM instead of UA: # modprobe n_gsm debug=0xff # ldattach -d GSM0710 /dev/ttyS0 & gsmld_output: 00000000: f9 03 3f 01 1c f9 --> 0) C: SABM(P) gsmld_receive: 00000000: f9 03 1f 01 36 f9 <-- 0) C: DM(P) ... $ minicom -D /dev/gsmtty1 minicom: cannot open /dev/gsmtty1: No error information $ strace minicom -D /dev/gsmtty1 ... open("/dev/gsmtty1", O_RDWR|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = -1 EL2HLT Note that this is different issue from other n_gsm -EL2HLT issues such as timeouts when the control dlci does not respond at all. The ADM mode seems to be a quite common according to "RF Wireless World" article "GSM Issue-UE sends SABM and gets a DM response instead of UA response": This issue is most commonly observed in GSM networks where in UE sends SABM and expects network to send UA response but it ends up receiving DM response from the network. SABM stands for Set asynchronous balanced mode, UA stands for Unnumbered Acknowledge and DA stands for Disconnected Mode. An RLP entity can be in one of two modes: - Asynchronous Balanced Mode (ABM) - Asynchronous Disconnected Mode (ADM) Currently Linux kernel closes the control dlci after several retries in gsm_dlci_t1() on DM. This causes n_gsm /dev/gsmtty ports to produce error code -EL2HLT when trying to open them as the closing of control dlci has already set gsm->dead. Let's fix the issue by allowing control dlci stay in ADM mode after the retries so the /dev/gsmtty ports can be opened and used. It seems that it might take several attempts to get any response from the control dlci, so it's best to allow ADM mode only after the SABM retries are done. Note that for droid 4 additional patches are needed to mux the ttyS0 pins and to toggle RTS gpio_149 to wake up the mdm6600 modem are also needed to use n_gsm. And the mdm6600 modem needs to be powered on. Cc: linux-serial(a)vger.kernel.org Cc: Alan Cox <alan(a)llwyncelyn.cymru> Cc: Jiri Prchal <jiri.prchal(a)aksignal.cz> Cc: Jiri Slaby <jslaby(a)suse.cz> Cc: Marcel Partap <mpartap(a)gmx.net> Cc: Michael Scott <michael.scott(a)linaro.org> Cc: Peter Hurley <peter(a)hurleysoftware.com> Cc: Russ Gorby <russ.gorby(a)intel.com> Cc: Sascha Hauer <s.hauer(a)pengutronix.de> Cc: Sebastian Reichel <sre(a)kernel.org> Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/n_gsm.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) --- a/drivers/tty/n_gsm.c +++ b/drivers/tty/n_gsm.c @@ -1451,6 +1451,10 @@ static void gsm_dlci_open(struct gsm_dlc * in which case an opening port goes back to closed and a closing port * is simply put into closed state (any further frames from the other * end will get a DM response) + * + * Some control dlci can stay in ADM mode with other dlci working just + * fine. In that case we can just keep the control dlci open after the + * DLCI_OPENING retries time out. */ static void gsm_dlci_t1(struct timer_list *t) @@ -1464,8 +1468,15 @@ static void gsm_dlci_t1(struct timer_lis if (dlci->retries) { gsm_command(dlci->gsm, dlci->addr, SABM|PF); mod_timer(&dlci->t1, jiffies + gsm->t1 * HZ / 100); - } else + } else if (!dlci->addr && gsm->control == (DM | PF)) { + if (debug & 8) + pr_info("DLCI %d opening in ADM mode.\n", + dlci->addr); + gsm_dlci_open(dlci); + } else { gsm_dlci_close(dlci); + } + break; case DLCI_CLOSING: dlci->retries--; @@ -1483,8 +1494,8 @@ static void gsm_dlci_t1(struct timer_lis * @dlci: DLCI to open * * Commence opening a DLCI from the Linux side. We issue SABM messages - * to the modem which should then reply with a UA, at which point we - * will move into open state. Opening is done asynchronously with retry + * to the modem which should then reply with a UA or ADM, at which point + * we will move into open state. Opening is done asynchronously with retry * running off timers and the responses. */ Patches currently in stable-queue which might be from tony(a)atomide.com are queue-4.15/tty-n_gsm-allow-adm-response-in-addition-to-ua-for-control-dlci.patch

7 years, 2 months

1
0
0 0

Patch "uio_hv_generic: check that host supports monitor page" 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 uio_hv_generic: check that host supports monitor page 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: uio_hv_generic-check-that-host-supports-monitor-page.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Stephen Hemminger <stephen(a)networkplumber.org> Date: Tue, 9 Jan 2018 12:57:31 -0800 Subject: uio_hv_generic: check that host supports monitor page From: Stephen Hemminger <stephen(a)networkplumber.org> [ Upstream commit 06028d15177a1b406b7b075ea47c6a352732f23a ] In order for userspace application to signal host, it needs the host to support the monitor page property. Check for the flag and fail if this is not supported. Signed-off-by: Stephen Hemminger <sthemmin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/uio/uio_hv_generic.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/drivers/uio/uio_hv_generic.c +++ b/drivers/uio/uio_hv_generic.c @@ -124,6 +124,13 @@ hv_uio_probe(struct hv_device *dev, if (ret) goto fail; + /* Communicating with host has to be via shared memory not hypercall */ + if (!dev->channel->offermsg.monitor_allocated) { + dev_err(&dev->device, "vmbus channel requires hypercall\n"); + ret = -ENOTSUPP; + goto fail_close; + } + dev->channel->inbound.ring_buffer->interrupt_mask = 1; set_channel_read_mode(dev->channel, HV_CALL_DIRECT); Patches currently in stable-queue which might be from stephen(a)networkplumber.org are queue-4.15/uio_hv_generic-check-that-host-supports-monitor-page.patch

7 years, 2 months

1
0
0 0

Patch "tpm: return a TPM_RC_COMMAND_CODE response if command is not implemented" 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 tpm: return a TPM_RC_COMMAND_CODE response if command is not implemented 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: tpm-return-a-tpm_rc_command_code-response-if-command-is-not-implemented.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Javier Martinez Canillas <javierm(a)redhat.com> Date: Thu, 30 Nov 2017 08:39:07 +0100 Subject: tpm: return a TPM_RC_COMMAND_CODE response if command is not implemented From: Javier Martinez Canillas <javierm(a)redhat.com> [ Upstream commit 095531f891e627e408606f2da4008d3d53e6748a ] According to the TPM Library Specification, a TPM device must do a command header validation before processing and return a TPM_RC_COMMAND_CODE code if the command is not implemented. So user-space will expect to handle that response as an error. But if the in-kernel resource manager is used (/dev/tpmrm?), an -EINVAL errno code is returned instead if the command isn't implemented. This confuses userspace since it doesn't expect that error value. This also isn't consistent with the behavior when not using TPM spaces and accessing the TPM directly (/dev/tpm?). In this case, the command is sent to the TPM even when not implemented and the TPM responds with an error. Instead of returning an -EINVAL errno code when the tpm_validate_command() function fails, synthesize a TPM command response so user-space can get a TPM_RC_COMMAND_CODE as expected when a chip doesn't implement the command. The TPM only sets 12 of the 32 bits in the TPM_RC response, so the TSS and TAB specifications define that higher layers in the stack should use some of the unused 20 bits to specify from which level of the stack the error is coming from. Since the TPM_RC_COMMAND_CODE response code is sent by the kernel resource manager, set the error level to the TAB/RM layer so user-space is aware of this. Suggested-by: Jason Gunthorpe <jgg(a)ziepe.ca> Signed-off-by: Javier Martinez Canillas <javierm(a)redhat.com> Reviewed-by: William Roberts <william.c.roberts(a)intel.com> Reviewed-by: Philip Tricca <philip.b.tricca(a)intel.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Tested-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/char/tpm/tpm-interface.c | 28 ++++++++++++++++++++-------- drivers/char/tpm/tpm.h | 5 +++++ 2 files changed, 25 insertions(+), 8 deletions(-) --- a/drivers/char/tpm/tpm-interface.c +++ b/drivers/char/tpm/tpm-interface.c @@ -328,7 +328,7 @@ unsigned long tpm_calc_ordinal_duration( } EXPORT_SYMBOL_GPL(tpm_calc_ordinal_duration); -static bool tpm_validate_command(struct tpm_chip *chip, +static int tpm_validate_command(struct tpm_chip *chip, struct tpm_space *space, const u8 *cmd, size_t len) @@ -340,10 +340,10 @@ static bool tpm_validate_command(struct unsigned int nr_handles; if (len < TPM_HEADER_SIZE) - return false; + return -EINVAL; if (!space) - return true; + return 0; if (chip->flags & TPM_CHIP_FLAG_TPM2 && chip->nr_commands) { cc = be32_to_cpu(header->ordinal); @@ -352,7 +352,7 @@ static bool tpm_validate_command(struct if (i < 0) { dev_dbg(&chip->dev, "0x%04X is an invalid command\n", cc); - return false; + return -EOPNOTSUPP; } attrs = chip->cc_attrs_tbl[i]; @@ -362,11 +362,11 @@ static bool tpm_validate_command(struct goto err_len; } - return true; + return 0; err_len: dev_dbg(&chip->dev, "%s: insufficient command length %zu", __func__, len); - return false; + return -EINVAL; } /** @@ -391,8 +391,20 @@ ssize_t tpm_transmit(struct tpm_chip *ch unsigned long stop; bool need_locality; - if (!tpm_validate_command(chip, space, buf, bufsiz)) - return -EINVAL; + rc = tpm_validate_command(chip, space, buf, bufsiz); + if (rc == -EINVAL) + return rc; + /* + * If the command is not implemented by the TPM, synthesize a + * response with a TPM2_RC_COMMAND_CODE return for user-space. + */ + if (rc == -EOPNOTSUPP) { + header->length = cpu_to_be32(sizeof(*header)); + header->tag = cpu_to_be16(TPM2_ST_NO_SESSIONS); + header->return_code = cpu_to_be32(TPM2_RC_COMMAND_CODE | + TSS2_RESMGR_TPM_RC_LAYER); + return bufsiz; + } if (bufsiz > TPM_BUFSIZE) bufsiz = TPM_BUFSIZE; --- a/drivers/char/tpm/tpm.h +++ b/drivers/char/tpm/tpm.h @@ -93,12 +93,17 @@ enum tpm2_structures { TPM2_ST_SESSIONS = 0x8002, }; +/* Indicates from what layer of the software stack the error comes from */ +#define TSS2_RC_LAYER_SHIFT 16 +#define TSS2_RESMGR_TPM_RC_LAYER (11 << TSS2_RC_LAYER_SHIFT) + enum tpm2_return_codes { TPM2_RC_SUCCESS = 0x0000, TPM2_RC_HASH = 0x0083, /* RC_FMT1 */ TPM2_RC_HANDLE = 0x008B, TPM2_RC_INITIALIZE = 0x0100, /* RC_VER1 */ TPM2_RC_DISABLED = 0x0120, + TPM2_RC_COMMAND_CODE = 0x0143, TPM2_RC_TESTING = 0x090A, /* RC_WARN */ TPM2_RC_REFERENCE_H0 = 0x0910, }; Patches currently in stable-queue which might be from javierm(a)redhat.com are queue-4.15/tpm-return-a-tpm_rc_command_code-response-if-command-is-not-implemented.patch

7 years, 2 months

1
0
0 0

Patch "thermal: power_allocator: fix one race condition issue for thermal_instances list" 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 thermal: power_allocator: fix one race condition issue for thermal_instances list 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: thermal-power_allocator-fix-one-race-condition-issue-for-thermal_instances-list.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Yi Zeng <yizeng(a)asrmicro.com> Date: Tue, 26 Dec 2017 19:22:26 +0800 Subject: thermal: power_allocator: fix one race condition issue for thermal_instances list From: Yi Zeng <yizeng(a)asrmicro.com> [ Upstream commit a5de11d67dcd268b8d0beb73dc374de5e97f0caf ] When invoking allow_maximum_power and traverse tz->thermal_instances, we should grab thermal_zone_device->lock to avoid race condition. For example, during the system reboot, if the mali GPU device implements device shutdown callback and unregister GPU devfreq cooling device, the deleted list head may be accessed to cause panic, as the following log shows: [ 33.551070] c3 25 (kworker/3:0) Unable to handle kernel paging request at virtual address dead000000000070 [ 33.566708] c3 25 (kworker/3:0) pgd = ffffffc0ed290000 [ 33.572071] c3 25 (kworker/3:0) [dead000000000070] *pgd=00000001ed292003, *pud=00000001ed292003, *pmd=0000000000000000 [ 33.581515] c3 25 (kworker/3:0) Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 33.599761] c3 25 (kworker/3:0) CPU: 3 PID: 25 Comm: kworker/3:0 Not tainted 4.4.35+ #912 [ 33.614137] c3 25 (kworker/3:0) Workqueue: events_freezable thermal_zone_device_check [ 33.620245] c3 25 (kworker/3:0) task: ffffffc0f32e4200 ti: ffffffc0f32f0000 task.ti: ffffffc0f32f0000 [ 33.629466] c3 25 (kworker/3:0) PC is at power_allocator_throttle+0x7c8/0x8a4 [ 33.636609] c3 25 (kworker/3:0) LR is at power_allocator_throttle+0x808/0x8a4 [ 33.643742] c3 25 (kworker/3:0) pc : [<ffffff8008683dd0>] lr : [<ffffff8008683e10>] pstate: 20000145 [ 33.652874] c3 25 (kworker/3:0) sp : ffffffc0f32f3bb0 [ 34.468519] c3 25 (kworker/3:0) Process kworker/3:0 (pid: 25, stack limit = 0xffffffc0f32f0020) [ 34.477220] c3 25 (kworker/3:0) Stack: (0xffffffc0f32f3bb0 to 0xffffffc0f32f4000) [ 34.819822] c3 25 (kworker/3:0) Call trace: [ 34.824021] c3 25 (kworker/3:0) Exception stack(0xffffffc0f32f39c0 to 0xffffffc0f32f3af0) [ 34.924993] c3 25 (kworker/3:0) [<ffffff8008683dd0>] power_allocator_throttle+0x7c8/0x8a4 [ 34.933184] c3 25 (kworker/3:0) [<ffffff80086807f4>] handle_thermal_trip.part.25+0x70/0x224 [ 34.941545] c3 25 (kworker/3:0) [<ffffff8008680a68>] thermal_zone_device_update+0xc0/0x20c [ 34.949818] c3 25 (kworker/3:0) [<ffffff8008680bd4>] thermal_zone_device_check+0x20/0x2c [ 34.957924] c3 25 (kworker/3:0) [<ffffff80080b93a4>] process_one_work+0x168/0x458 [ 34.965414] c3 25 (kworker/3:0) [<ffffff80080ba068>] worker_thread+0x13c/0x4b4 [ 34.972650] c3 25 (kworker/3:0) [<ffffff80080c0a4c>] kthread+0xe8/0xfc [ 34.979187] c3 25 (kworker/3:0) [<ffffff8008084e90>] ret_from_fork+0x10/0x40 [ 34.986244] c3 25 (kworker/3:0) Code: f9405e73 eb1302bf d102e273 54ffc460 (b9402a61) [ 34.994339] c3 25 (kworker/3:0) ---[ end trace 32057901e3b7e1db ]--- Signed-off-by: Yi Zeng <yizeng(a)asrmicro.com> Signed-off-by: Zhang Rui <rui.zhang(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/thermal/power_allocator.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/thermal/power_allocator.c +++ b/drivers/thermal/power_allocator.c @@ -523,6 +523,7 @@ static void allow_maximum_power(struct t struct thermal_instance *instance; struct power_allocator_params *params = tz->governor_data; + mutex_lock(&tz->lock); list_for_each_entry(instance, &tz->thermal_instances, tz_node) { if ((instance->trip != params->trip_max_desired_temperature) || (!cdev_is_power_actor(instance->cdev))) @@ -534,6 +535,7 @@ static void allow_maximum_power(struct t mutex_unlock(&instance->cdev->lock); thermal_cdev_update(instance->cdev); } + mutex_unlock(&tz->lock); } /** Patches currently in stable-queue which might be from yizeng(a)asrmicro.com are queue-4.15/thermal-power_allocator-fix-one-race-condition-issue-for-thermal_instances-list.patch

7 years, 2 months

1
0
0 0

Patch "thermal: int3400_thermal: fix error handling in int3400_thermal_probe()" 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 thermal: int3400_thermal: fix error handling in int3400_thermal_probe() 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: thermal-int3400_thermal-fix-error-handling-in-int3400_thermal_probe.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Alexey Khoroshilov <khoroshilov(a)ispras.ru> Date: Sat, 30 Dec 2017 01:05:21 +0300 Subject: thermal: int3400_thermal: fix error handling in int3400_thermal_probe() From: Alexey Khoroshilov <khoroshilov(a)ispras.ru> [ Upstream commit 0be86969ae385c5c944286bd9f66068525de15ee ] There are resources that are not dealocated on failure path in int3400_thermal_probe(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov <khoroshilov(a)ispras.ru> Signed-off-by: Zhang Rui <rui.zhang(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/thermal/int340x_thermal/int3400_thermal.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) --- a/drivers/thermal/int340x_thermal/int3400_thermal.c +++ b/drivers/thermal/int340x_thermal/int3400_thermal.c @@ -319,17 +319,21 @@ static int int3400_thermal_probe(struct result = sysfs_create_group(&pdev->dev.kobj, &uuid_attribute_group); if (result) - goto free_zone; + goto free_rel_misc; result = acpi_install_notify_handler( priv->adev->handle, ACPI_DEVICE_NOTIFY, int3400_notify, (void *)priv); if (result) - goto free_zone; + goto free_sysfs; return 0; -free_zone: +free_sysfs: + sysfs_remove_group(&pdev->dev.kobj, &uuid_attribute_group); +free_rel_misc: + if (!priv->rel_misc_dev_res) + acpi_thermal_rel_misc_device_remove(priv->adev->handle); thermal_zone_device_unregister(priv->thermal); free_art_trt: kfree(priv->trts); Patches currently in stable-queue which might be from khoroshilov(a)ispras.ru are queue-4.15/thermal-int3400_thermal-fix-error-handling-in-int3400_thermal_probe.patch

7 years, 2 months

1
0
0 0

Patch "thermal/drivers/hisi: Remove bogus const from function return type" 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 thermal/drivers/hisi: Remove bogus const from function return type 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: thermal-drivers-hisi-remove-bogus-const-from-function-return-type.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Geert Uytterhoeven <geert(a)linux-m68k.org> Date: Sun, 19 Nov 2017 12:04:27 +0100 Subject: thermal/drivers/hisi: Remove bogus const from function return type From: Geert Uytterhoeven <geert(a)linux-m68k.org> [ Upstream commit d0ecbbbe518e1b256fcda1770ec06a5a1a058567 ] With gcc-4.1.2: drivers/thermal/hisi_thermal.c: In function ‘hisi_thermal_probe’: drivers/thermal/hisi_thermal.c:530: warning: type qualifiers ignored on function return type Remove the "const" keyword to fix this. Fixes: a160a465297362c5 ("thermal/drivers/hisi: Prepare to add support for other hisi platforms") Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Signed-off-by: Eduardo Valentin <edubezval(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/thermal/hisi_thermal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/thermal/hisi_thermal.c +++ b/drivers/thermal/hisi_thermal.c @@ -527,7 +527,7 @@ static void hisi_thermal_toggle_sensor(s static int hisi_thermal_probe(struct platform_device *pdev) { struct hisi_thermal_data *data; - int const (*platform_probe)(struct hisi_thermal_data *); + int (*platform_probe)(struct hisi_thermal_data *); struct device *dev = &pdev->dev; int ret; Patches currently in stable-queue which might be from geert(a)linux-m68k.org are queue-4.15/thermal-drivers-hisi-remove-bogus-const-from-function-return-type.patch queue-4.15/vfb-fix-video-mode-and-line_length-being-set-when-loaded.patch

7 years, 2 months

1
0
0 0

Patch "tcmu: release blocks for partially setup cmds" 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 tcmu: release blocks for partially setup cmds 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: tcmu-release-blocks-for-partially-setup-cmds.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Mike Christie <mchristi(a)redhat.com> Date: Tue, 28 Nov 2017 12:40:33 -0600 Subject: tcmu: release blocks for partially setup cmds From: Mike Christie <mchristi(a)redhat.com> [ Upstream commit 810b8153c4243d2012a6ec002ddd3bbc9a9ae8c2 ] If we cannot setup a cmd because we run out of ring space or global pages release the blocks before sleeping. This prevents a deadlock where dev0 has waiting_blocks set and needs N blocks, but dev1 to devX have each allocated N / X blocks and also hit the global block limit so they went to sleep. find_free_blocks is not able to take the sleeping dev's blocks becaause their waiting_blocks is set and even if it was not the block returned by find_last_bit could equal dbi_max. The latter will probably never happen because DATA_BLOCK_BITS is so high but in the next patches DATA_BLOCK_BITS and TCMU_GLOBAL_MAX_BLOCKS will be settable so it might be lower and could happen. Signed-off-by: Mike Christie <mchristi(a)redhat.com> Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/target_core_user.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/drivers/target/target_core_user.c +++ b/drivers/target/target_core_user.c @@ -805,6 +805,13 @@ tcmu_queue_cmd_ring(struct tcmu_cmd *tcm int ret; DEFINE_WAIT(__wait); + /* + * Don't leave commands partially setup because the unmap + * thread might need the blocks to make forward progress. + */ + tcmu_cmd_free_data(tcmu_cmd, tcmu_cmd->dbi_cur); + tcmu_cmd_reset_dbi_cur(tcmu_cmd); + prepare_to_wait(&udev->wait_cmdr, &__wait, TASK_INTERRUPTIBLE); pr_debug("sleeping for ring space\n"); Patches currently in stable-queue which might be from mchristi(a)redhat.com are queue-4.15/tcmu-release-blocks-for-partially-setup-cmds.patch

7 years, 2 months

1
0
0 0

Patch "staging: lustre: disable preempt while sampling processor id." 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 staging: lustre: disable preempt while sampling processor id. 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: staging-lustre-disable-preempt-while-sampling-processor-id.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: NeilBrown <neilb(a)suse.com> Date: Tue, 19 Dec 2017 10:01:47 +1100 Subject: staging: lustre: disable preempt while sampling processor id. From: NeilBrown <neilb(a)suse.com> [ Upstream commit dbeccabf5294e80f7cc9ee566746c42211bed736 ] Calling smp_processor_id() without disabling preemption triggers a warning (if CONFIG_DEBUG_PREEMPT). I think the result of cfs_cpt_current() is only used as a hint for load balancing, rather than as a precise and stable indicator of the current CPU. So it doesn't need to be called with preemption disabled. So disable preemption inside cfs_cpt_current() to silence the warning. Signed-off-by: NeilBrown <neilb(a)suse.com> Reviewed-by: Andreas Dilger <andreas.dilger(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) --- a/drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c +++ b/drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c @@ -529,19 +529,20 @@ EXPORT_SYMBOL(cfs_cpt_spread_node); int cfs_cpt_current(struct cfs_cpt_table *cptab, int remap) { - int cpu = smp_processor_id(); - int cpt = cptab->ctb_cpu2cpt[cpu]; + int cpu; + int cpt; - if (cpt < 0) { - if (!remap) - return cpt; + preempt_disable(); + cpu = smp_processor_id(); + cpt = cptab->ctb_cpu2cpt[cpu]; + if (cpt < 0 && remap) { /* don't return negative value for safety of upper layer, * instead we shadow the unknown cpu to a valid partition ID */ cpt = cpu % cptab->ctb_nparts; } - + preempt_enable(); return cpt; } EXPORT_SYMBOL(cfs_cpt_current); Patches currently in stable-queue which might be from neilb(a)suse.com are queue-4.15/staging-lustre-disable-preempt-while-sampling-processor-id.patch queue-4.15/vfs-close-race-between-getcwd-and-d_move.patch

7 years, 2 months

1
0
0 0

Patch "spi: sh-msiof: Fix timeout failures for TX-only DMA transfers" 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 spi: sh-msiof: Fix timeout failures for TX-only DMA transfers 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: spi-sh-msiof-fix-timeout-failures-for-tx-only-dma-transfers.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Geert Uytterhoeven <geert+renesas(a)glider.be> Date: Wed, 3 Jan 2018 18:11:14 +0100 Subject: spi: sh-msiof: Fix timeout failures for TX-only DMA transfers From: Geert Uytterhoeven <geert+renesas(a)glider.be> [ Upstream commit 89434c3c35081439627baa2225622d5bd12242fe ] When using RX (with or without TX), the DMA interrupt triggers completion when the RX FIFO has been emptied, i.e. after the full transfer has finished. However, when using TX without RX, the DMA interrupt triggers completion as soon as the DMA engine has filled the TX FIFO, i.e. before the full transfer has finished. Then sh_msiof_modify_ctr_wait() will spin until the transfer has really finished and the TFSE bit is cleared, for at most 1 ms. For slow speeds and/or large transfers, this may cause timeouts and transfer failures: spi_sh_msiof e6e10000.spi: failed to shut down hardware 74x164 spi2.0: SPI transfer failed: -110 spi_master spi2: failed to transfer one message from queue 74x164 spi2.0: Failed writing: -110 Fix this by waiting explicitly until the TX FIFO has been emptied. Based on a patch in the BSP by Hiromitsu Yamasaki. Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/spi/spi-sh-msiof.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) --- a/drivers/spi/spi-sh-msiof.c +++ b/drivers/spi/spi-sh-msiof.c @@ -797,11 +797,21 @@ static int sh_msiof_dma_once(struct sh_m goto stop_dma; } - /* wait for tx fifo to be emptied / rx fifo to be filled */ + /* wait for tx/rx DMA completion */ ret = sh_msiof_wait_for_completion(p); if (ret) goto stop_reset; + if (!rx) { + reinit_completion(&p->done); + sh_msiof_write(p, IER, IER_TEOFE); + + /* wait for tx fifo to be emptied */ + ret = sh_msiof_wait_for_completion(p); + if (ret) + goto stop_reset; + } + /* clear status bits */ sh_msiof_reset_str(p); Patches currently in stable-queue which might be from geert+renesas(a)glider.be are queue-4.15/acpi-ec-fix-debugfs_create_-usage.patch queue-4.15/spi-sh-msiof-fix-timeout-failures-for-tx-only-dma-transfers.patch

7 years, 2 months

1
0
0 0

Patch "selftests/net: fix bugs in address and port initialization" 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/net: fix bugs in address and port initialization 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-net-fix-bugs-in-address-and-port-initialization.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com> Date: Mon, 25 Dec 2017 14:43:04 -0800 Subject: selftests/net: fix bugs in address and port initialization From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com> [ Upstream commit d36f45e5b46723cf2d4147173e18c52d4143176d ] Address/port initialization should work correctly regardless of the order in which command line arguments are supplied, E.g, cfg_port should be used to connect to the remote host even if it is processed after -D, src/dst address initialization should not require that [-4|-6] be specified before the -S or -D args, receiver should be able to bind to *.<cfg_port> Achieve this by making sure that the address/port structures are initialized after all command line options are parsed. Store cfg_port in host-byte order, and use htons() to set up the sin_port/sin6_port before bind/connect, so that the network system calls get the correct values in network-byte order. Signed-off-by: Sowmini Varadhan <sowmini.varadhan(a)oracle.com> Acked-by: Willem de Bruijn <willemb(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/net/msg_zerocopy.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) --- a/tools/testing/selftests/net/msg_zerocopy.c +++ b/tools/testing/selftests/net/msg_zerocopy.c @@ -259,22 +259,28 @@ static int setup_ip6h(struct ipv6hdr *ip return sizeof(*ip6h); } -static void setup_sockaddr(int domain, const char *str_addr, void *sockaddr) + +static void setup_sockaddr(int domain, const char *str_addr, + struct sockaddr_storage *sockaddr) { struct sockaddr_in6 *addr6 = (void *) sockaddr; struct sockaddr_in *addr4 = (void *) sockaddr; switch (domain) { case PF_INET: + memset(addr4, 0, sizeof(*addr4)); addr4->sin_family = AF_INET; addr4->sin_port = htons(cfg_port); - if (inet_pton(AF_INET, str_addr, &(addr4->sin_addr)) != 1) + if (str_addr && + inet_pton(AF_INET, str_addr, &(addr4->sin_addr)) != 1) error(1, 0, "ipv4 parse error: %s", str_addr); break; case PF_INET6: + memset(addr6, 0, sizeof(*addr6)); addr6->sin6_family = AF_INET6; addr6->sin6_port = htons(cfg_port); - if (inet_pton(AF_INET6, str_addr, &(addr6->sin6_addr)) != 1) + if (str_addr && + inet_pton(AF_INET6, str_addr, &(addr6->sin6_addr)) != 1) error(1, 0, "ipv6 parse error: %s", str_addr); break; default: @@ -603,6 +609,7 @@ static void parse_opts(int argc, char ** sizeof(struct tcphdr) - 40 /* max tcp options */; int c; + char *daddr = NULL, *saddr = NULL; cfg_payload_len = max_payload_len; @@ -627,7 +634,7 @@ static void parse_opts(int argc, char ** cfg_cpu = strtol(optarg, NULL, 0); break; case 'D': - setup_sockaddr(cfg_family, optarg, &cfg_dst_addr); + daddr = optarg; break; case 'i': cfg_ifindex = if_nametoindex(optarg); @@ -638,7 +645,7 @@ static void parse_opts(int argc, char ** cfg_cork_mixed = true; break; case 'p': - cfg_port = htons(strtoul(optarg, NULL, 0)); + cfg_port = strtoul(optarg, NULL, 0); break; case 'r': cfg_rx = true; @@ -647,7 +654,7 @@ static void parse_opts(int argc, char ** cfg_payload_len = strtoul(optarg, NULL, 0); break; case 'S': - setup_sockaddr(cfg_family, optarg, &cfg_src_addr); + saddr = optarg; break; case 't': cfg_runtime_ms = 200 + strtoul(optarg, NULL, 10) * 1000; @@ -660,6 +667,8 @@ static void parse_opts(int argc, char ** break; } } + setup_sockaddr(cfg_family, daddr, &cfg_dst_addr); + setup_sockaddr(cfg_family, saddr, &cfg_src_addr); if (cfg_payload_len > max_payload_len) error(1, 0, "-s: payload exceeds max (%d)", max_payload_len); Patches currently in stable-queue which might be from sowmini.varadhan(a)oracle.com are queue-4.15/selftests-net-fix-bugs-in-address-and-port-initialization.patch queue-4.15/rds-reset-rs-rs_bound_addr-in-rds_add_bound-failure-path.patch

7 years, 2 months

1
0
0 0

Patch "serdev: Fix serdev_uevent failure on ACPI enumerated serdev-controllers" 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 serdev: Fix serdev_uevent failure on ACPI enumerated serdev-controllers 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: serdev-fix-serdev_uevent-failure-on-acpi-enumerated-serdev-controllers.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Hans de Goede <hdegoede(a)redhat.com> Date: Mon, 25 Dec 2017 21:50:45 +0100 Subject: serdev: Fix serdev_uevent failure on ACPI enumerated serdev-controllers From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit 7d09995dcb0577b4a56aad7f2bb56f28604e8f1a ] ACPI enumerated serdev-controllers do not have an ACPI companion, the ACPI companion belongs to the serdev-device child of the serdev-controller, not to the controller itself. This was causing serdev_uevent to always return -ENODEV when called on a serdev-controller leading to errors like these: kernel: serial serial0: uevent: failed to send synthetic uevent being logged. This commit modifies serdev_uevent to directly return 0 when called on an ACPI enumerated serdev-controller fixing this. Note: I do not think that setting a modalias on a devicetree enumerated serdev-controller makes sense either. So perhaps the !dev->of_node part of the check can be dropped too, but I'm not entirely sure that doing this on devicetree too is correct. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Acked-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serdev/core.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/tty/serdev/core.c +++ b/drivers/tty/serdev/core.c @@ -54,6 +54,11 @@ static int serdev_uevent(struct device * int rc; /* TODO: platform modalias */ + + /* ACPI enumerated controllers do not have a modalias */ + if (!dev->of_node && dev->type == &serdev_ctrl_type) + return 0; + rc = acpi_device_uevent_modalias(dev, env); if (rc != -ENODEV) return rc; Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.15/serdev-fix-serdev_uevent-failure-on-acpi-enumerated-serdev-controllers.patch queue-4.15/acpi-video-default-lcd_only-to-true-on-win8-ready-and-newer-machines.patch queue-4.15/bluetooth-hci_bcm-mandate-presence-of-shutdown-and-device-wake-gpio.patch queue-4.15/input-goodix-disable-irqs-while-suspended.patch queue-4.15/asoc-intel-cht_bsw_rt5645-analog-mic-support.patch queue-4.15/power-supply-axp288_charger-properly-stop-work-on-probe-error-remove.patch queue-4.15/pinctrl-baytrail-enable-glitch-filter-for-gpios-used-as-interrupts.patch

7 years, 2 months

1
0
0 0

Patch "sdhci: Advertise 2.0v supply on SDIO host controller" 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 sdhci: Advertise 2.0v supply on SDIO host controller 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: sdhci-advertise-2.0v-supply-on-sdio-host-controller.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Date: Thu, 11 Jan 2018 15:51:58 +0200 Subject: sdhci: Advertise 2.0v supply on SDIO host controller From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> [ Upstream commit 2a609abe71ca59e4bd7139e161eaca2144ae6f2e ] On Intel Edison the Broadcom Wi-Fi card, which is connected to SDIO, requires 2.0v, while the host, according to Intel Merrifield TRM, supports 1.8v supply only. The card announces itself as mmc2: new ultra high speed DDR50 SDIO card at address 0001 Introduce a custom OCR mask for SDIO host controller on Intel Merrifield and add a special case to sdhci_set_power_noreg() to override 2.0v supply by enforcing 1.8v power choice. Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mmc/host/sdhci-pci-core.c | 2 ++ drivers/mmc/host/sdhci.c | 7 +++++++ 2 files changed, 9 insertions(+) --- a/drivers/mmc/host/sdhci-pci-core.c +++ b/drivers/mmc/host/sdhci-pci-core.c @@ -805,6 +805,8 @@ static int intel_mrfld_mmc_probe_slot(st slot->host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V; break; case INTEL_MRFLD_SDIO: + /* Advertise 2.0v for compatibility with the SDIO card's OCR */ + slot->host->ocr_mask = MMC_VDD_20_21 | MMC_VDD_165_195; slot->host->mmc->caps |= MMC_CAP_NONREMOVABLE | MMC_CAP_POWER_OFF_CARD; break; --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -1470,6 +1470,13 @@ void sdhci_set_power_noreg(struct sdhci_ if (mode != MMC_POWER_OFF) { switch (1 << vdd) { case MMC_VDD_165_195: + /* + * Without a regulator, SDHCI does not support 2.0v + * so we only get here if the driver deliberately + * added the 2.0v range to ocr_avail. Map it to 1.8v + * for the purpose of turning on the power. + */ + case MMC_VDD_20_21: pwr = SDHCI_POWER_180; break; case MMC_VDD_29_30: Patches currently in stable-queue which might be from andriy.shevchenko(a)linux.intel.com are queue-4.15/bluetooth-hci_bcm-mandate-presence-of-shutdown-and-device-wake-gpio.patch queue-4.15/bluetooth-hci_bcm-validate-irq-before-using-it.patch queue-4.15/sdhci-advertise-2.0v-supply-on-sdio-host-controller.patch

7 years, 2 months

1
0
0 0

Patch "scsi: megaraid_sas: unload flag should be set after scsi_remove_host is called" 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 scsi: megaraid_sas: unload flag should be set after scsi_remove_host is called 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: scsi-megaraid_sas-unload-flag-should-be-set-after-scsi_remove_host-is-called.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com> Date: Fri, 5 Jan 2018 05:27:41 -0800 Subject: scsi: megaraid_sas: unload flag should be set after scsi_remove_host is called From: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com> [ Upstream commit f3f7920b3910171b2999c7dc2335eb9f583e44f2 ] Issue - Driver returns DID_NO_CONNECT when unload is in progress, indicated using instance->unload flag. In case of dynamic unload of driver, this flag is set before calling scsi_remove_host(). While doing manual driver unload, user will see lots of prints for Sync Cache command with DID_NO_CONNECT status. Fix - Set the instance->unload flag after scsi_remove_host(). Allow device removal process to be completed and do not block any command before that. SCSI commands (like SYNC_CACHE) are received (as part of scsi_remove_host) by driver during unload will be submitted further down to the drives. Signed-off-by: Sumit Saxena <sumit.saxena(a)broadcom.com> Signed-off-by: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/megaraid/megaraid_sas_base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -6822,7 +6822,6 @@ static void megasas_detach_one(struct pc u32 pd_seq_map_sz; instance = pci_get_drvdata(pdev); - instance->unload = 1; host = instance->host; fusion = instance->ctrl_context; @@ -6833,6 +6832,7 @@ static void megasas_detach_one(struct pc if (instance->fw_crash_state != UNAVAILABLE) megasas_free_host_crash_buffer(instance); scsi_remove_host(instance->host); + instance->unload = 1; if (megasas_wait_for_adapter_operational(instance)) goto skip_firing_dcmds; Patches currently in stable-queue which might be from shivasharan.srikanteshwara(a)broadcom.com are queue-4.15/scsi-megaraid_sas-error-handling-for-invalid-ldcount-provided-by-firmware-in-raid-map.patch queue-4.15/scsi-megaraid_sas-unload-flag-should-be-set-after-scsi_remove_host-is-called.patch

7 years, 2 months

1
0
0 0

Patch "scsi: mpt3sas: Proper handling of set/clear of "ATA command pending" flag." 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 scsi: mpt3sas: Proper handling of set/clear of "ATA command pending" flag. 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: scsi-mpt3sas-proper-handling-of-set-clear-of-ata-command-pending-flag.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Chaitra P B <chaitra.basappa(a)broadcom.com> Date: Wed, 27 Dec 2017 23:09:11 -0800 Subject: scsi: mpt3sas: Proper handling of set/clear of "ATA command pending" flag. From: Chaitra P B <chaitra.basappa(a)broadcom.com> [ Upstream commit f49d4aed1315a7b766d855f1367142e682b0cc87 ] 1. In IO path, setting of "ATA command pending" flag early before device removal, invalid device handle etc., checks causes any new commands to be always returned with SAM_STAT_BUSY and when the driver removes the drive the SML issues SYNC Cache command and that command is always returned with SAM_STAT_BUSY and thus making SYNC Cache command to requeued. 2. If the driver gets an ATA PT command for a SATA drive then the driver set "ATA command pending" flag in device specific data structure not to allow any further commands until the ATA PT command is completed. However, after setting the flag if the driver decides to return the command back to upper layers without actually issuing to the firmware (i.e., returns from qcmd failure return paths) then the corresponding flag is not cleared and this prevents the driver from sending any new commands to the drive. This patch fixes above two issues by setting of "ATA command pending" flag after checking for whether device deleted, invalid device handle, device busy with task management. And by setting "ATA command pending" flag to false in all of the qcmd failure return paths after setting the flag. Signed-off-by: Chaitra P B <chaitra.basappa(a)broadcom.com> Signed-off-by: Suganath Prabu S <suganath-prabu.subramani(a)broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/mpt3sas/mpt3sas_scsih.c | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c @@ -4761,19 +4761,6 @@ scsih_qcmd(struct Scsi_Host *shost, stru return 0; } - /* - * Bug work around for firmware SATL handling. The loop - * is based on atomic operations and ensures consistency - * since we're lockless at this point - */ - do { - if (test_bit(0, &sas_device_priv_data->ata_command_pending)) { - scmd->result = SAM_STAT_BUSY; - scmd->scsi_done(scmd); - return 0; - } - } while (_scsih_set_satl_pending(scmd, true)); - sas_target_priv_data = sas_device_priv_data->sas_target; /* invalid device handle */ @@ -4799,6 +4786,19 @@ scsih_qcmd(struct Scsi_Host *shost, stru sas_device_priv_data->block) return SCSI_MLQUEUE_DEVICE_BUSY; + /* + * Bug work around for firmware SATL handling. The loop + * is based on atomic operations and ensures consistency + * since we're lockless at this point + */ + do { + if (test_bit(0, &sas_device_priv_data->ata_command_pending)) { + scmd->result = SAM_STAT_BUSY; + scmd->scsi_done(scmd); + return 0; + } + } while (_scsih_set_satl_pending(scmd, true)); + if (scmd->sc_data_direction == DMA_FROM_DEVICE) mpi_control = MPI2_SCSIIO_CONTROL_READ; else if (scmd->sc_data_direction == DMA_TO_DEVICE) @@ -4826,6 +4826,7 @@ scsih_qcmd(struct Scsi_Host *shost, stru if (!smid) { pr_err(MPT3SAS_FMT "%s: failed obtaining a smid\n", ioc->name, __func__); + _scsih_set_satl_pending(scmd, false); goto out; } mpi_request = mpt3sas_base_get_msg_frame(ioc, smid); @@ -4857,6 +4858,7 @@ scsih_qcmd(struct Scsi_Host *shost, stru pcie_device = sas_target_priv_data->pcie_dev; if (ioc->build_sg_scmd(ioc, scmd, smid, pcie_device)) { mpt3sas_base_free_smid(ioc, smid); + _scsih_set_satl_pending(scmd, false); goto out; } } else Patches currently in stable-queue which might be from chaitra.basappa(a)broadcom.com are queue-4.15/scsi-mpt3sas-proper-handling-of-set-clear-of-ata-command-pending-flag.patch

7 years, 2 months

1
0
0 0

Patch "scsi: megaraid_sas: Error handling for invalid ldcount provided by firmware in RAID map" 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 scsi: megaraid_sas: Error handling for invalid ldcount provided by firmware in RAID map 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: scsi-megaraid_sas-error-handling-for-invalid-ldcount-provided-by-firmware-in-raid-map.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com> Date: Fri, 5 Jan 2018 05:27:40 -0800 Subject: scsi: megaraid_sas: Error handling for invalid ldcount provided by firmware in RAID map From: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com> [ Upstream commit 7ada701d0d5e5c6d357e157a72b841db3e8d03f4 ] Currently driver does not validate ldcount provided by firmware. If the value is invalid, fail RAID map validation accordingly. This issue is rare to hit in field and is fixed as part of code review. Signed-off-by: Sumit Saxena <sumit.saxena(a)broadcom.com> Signed-off-by: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/megaraid/megaraid_sas_fp.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) --- a/drivers/scsi/megaraid/megaraid_sas_fp.c +++ b/drivers/scsi/megaraid/megaraid_sas_fp.c @@ -168,7 +168,7 @@ static struct MR_LD_SPAN *MR_LdSpanPtrGe /* * This function will Populate Driver Map using firmware raid map */ -void MR_PopulateDrvRaidMap(struct megasas_instance *instance) +static int MR_PopulateDrvRaidMap(struct megasas_instance *instance) { struct fusion_context *fusion = instance->ctrl_context; struct MR_FW_RAID_MAP_ALL *fw_map_old = NULL; @@ -259,7 +259,7 @@ void MR_PopulateDrvRaidMap(struct megasa ld_count = (u16)le16_to_cpu(fw_map_ext->ldCount); if (ld_count > MAX_LOGICAL_DRIVES_EXT) { dev_dbg(&instance->pdev->dev, "megaraid_sas: LD count exposed in RAID map in not valid\n"); - return; + return 1; } pDrvRaidMap->ldCount = (__le16)cpu_to_le16(ld_count); @@ -285,6 +285,12 @@ void MR_PopulateDrvRaidMap(struct megasa fusion->ld_map[(instance->map_id & 1)]; pFwRaidMap = &fw_map_old->raidMap; ld_count = (u16)le32_to_cpu(pFwRaidMap->ldCount); + if (ld_count > MAX_LOGICAL_DRIVES) { + dev_dbg(&instance->pdev->dev, + "LD count exposed in RAID map in not valid\n"); + return 1; + } + pDrvRaidMap->totalSize = pFwRaidMap->totalSize; pDrvRaidMap->ldCount = (__le16)cpu_to_le16(ld_count); pDrvRaidMap->fpPdIoTimeoutSec = pFwRaidMap->fpPdIoTimeoutSec; @@ -300,6 +306,8 @@ void MR_PopulateDrvRaidMap(struct megasa sizeof(struct MR_DEV_HANDLE_INFO) * MAX_RAIDMAP_PHYSICAL_DEVICES); } + + return 0; } /* @@ -317,8 +325,8 @@ u8 MR_ValidateMapInfo(struct megasas_ins u16 ld; u32 expected_size; - - MR_PopulateDrvRaidMap(instance); + if (MR_PopulateDrvRaidMap(instance)) + return 0; fusion = instance->ctrl_context; drv_map = fusion->ld_drv_map[(instance->map_id & 1)]; Patches currently in stable-queue which might be from shivasharan.srikanteshwara(a)broadcom.com are queue-4.15/scsi-megaraid_sas-error-handling-for-invalid-ldcount-provided-by-firmware-in-raid-map.patch queue-4.15/scsi-megaraid_sas-unload-flag-should-be-set-after-scsi_remove_host-is-called.patch

7 years, 2 months

1
0
0 0

Patch "scsi: libsas: Use dynamic alloced work to avoid sas event lost" 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 scsi: libsas: Use dynamic alloced work to avoid sas event lost 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: scsi-libsas-use-dynamic-alloced-work-to-avoid-sas-event-lost.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Jason Yan <yanaijie(a)huawei.com> Date: Fri, 8 Dec 2017 17:42:04 +0800 Subject: scsi: libsas: Use dynamic alloced work to avoid sas event lost From: Jason Yan <yanaijie(a)huawei.com> [ Upstream commit 1c393b970e0f4070e4376d45f89a2d19a5c895d0 ] Now libsas hotplug work is static, every sas event type has its own static work, LLDD driver queues the hotplug work into shost->work_q. If LLDD driver burst posts lots hotplug events to libsas, the hotplug events may pending in the workqueue like shost->work_q new work[PORTE_BYTES_DMAED] --> |[PHYE_LOSS_OF_SIGNAL][PORTE_BYTES_DMAED] -> processing |<-------wait worker to process-------->| In this case, a new PORTE_BYTES_DMAED event coming, libsas try to queue it to shost->work_q, but this work is already pending, so it would be lost. Finally, libsas delete the related sas port and sas devices, but LLDD driver expect libsas add the sas port and devices(last sas event). This patch use dynamic allocated work to avoid this issue. Signed-off-by: Yijing Wang <wangyijing(a)huawei.com> CC: John Garry <john.garry(a)huawei.com> CC: Johannes Thumshirn <jthumshirn(a)suse.de> CC: Ewan Milne <emilne(a)redhat.com> CC: Christoph Hellwig <hch(a)lst.de> CC: Tomas Henzl <thenzl(a)redhat.com> CC: Dan Williams <dan.j.williams(a)intel.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Jason Yan <yanaijie(a)huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/libsas/sas_event.c | 74 ++++++++++++++++++++++++++++--------- drivers/scsi/libsas/sas_init.c | 27 ++++++++++++- drivers/scsi/libsas/sas_internal.h | 6 +++ drivers/scsi/libsas/sas_phy.c | 44 ++++------------------ drivers/scsi/libsas/sas_port.c | 18 ++++----- include/scsi/libsas.h | 17 +++++--- 6 files changed, 115 insertions(+), 71 deletions(-) --- a/drivers/scsi/libsas/sas_event.c +++ b/drivers/scsi/libsas/sas_event.c @@ -29,7 +29,8 @@ int sas_queue_work(struct sas_ha_struct *ha, struct sas_work *sw) { - int rc = 0; + /* it's added to the defer_q when draining so return succeed */ + int rc = 1; if (!test_bit(SAS_HA_REGISTERED, &ha->state)) return 0; @@ -44,19 +45,15 @@ int sas_queue_work(struct sas_ha_struct return rc; } -static int sas_queue_event(int event, unsigned long *pending, - struct sas_work *work, +static int sas_queue_event(int event, struct sas_work *work, struct sas_ha_struct *ha) { - int rc = 0; + unsigned long flags; + int rc; - if (!test_and_set_bit(event, pending)) { - unsigned long flags; - - spin_lock_irqsave(&ha->lock, flags); - rc = sas_queue_work(ha, work); - spin_unlock_irqrestore(&ha->lock, flags); - } + spin_lock_irqsave(&ha->lock, flags); + rc = sas_queue_work(ha, work); + spin_unlock_irqrestore(&ha->lock, flags); return rc; } @@ -66,6 +63,7 @@ void __sas_drain_work(struct sas_ha_stru { struct workqueue_struct *wq = ha->core.shost->work_q; struct sas_work *sw, *_sw; + int ret; set_bit(SAS_HA_DRAINING, &ha->state); /* flush submitters */ @@ -78,7 +76,10 @@ void __sas_drain_work(struct sas_ha_stru clear_bit(SAS_HA_DRAINING, &ha->state); list_for_each_entry_safe(sw, _sw, &ha->defer_q, drain_node) { list_del_init(&sw->drain_node); - sas_queue_work(ha, sw); + ret = sas_queue_work(ha, sw); + if (ret != 1) + sas_free_event(to_asd_sas_event(&sw->work)); + } spin_unlock_irq(&ha->lock); } @@ -119,29 +120,68 @@ void sas_enable_revalidation(struct sas_ if (!test_and_clear_bit(ev, &d->pending)) continue; - sas_queue_event(ev, &d->pending, &d->disc_work[ev].work, ha); + sas_queue_event(ev, &d->disc_work[ev].work, ha); } mutex_unlock(&ha->disco_mutex); } + +static void sas_port_event_worker(struct work_struct *work) +{ + struct asd_sas_event *ev = to_asd_sas_event(work); + + sas_port_event_fns[ev->event](work); + sas_free_event(ev); +} + +static void sas_phy_event_worker(struct work_struct *work) +{ + struct asd_sas_event *ev = to_asd_sas_event(work); + + sas_phy_event_fns[ev->event](work); + sas_free_event(ev); +} + static int sas_notify_port_event(struct asd_sas_phy *phy, enum port_event event) { + struct asd_sas_event *ev; struct sas_ha_struct *ha = phy->ha; + int ret; BUG_ON(event >= PORT_NUM_EVENTS); - return sas_queue_event(event, &phy->port_events_pending, - &phy->port_events[event].work, ha); + ev = sas_alloc_event(phy); + if (!ev) + return -ENOMEM; + + INIT_SAS_EVENT(ev, sas_port_event_worker, phy, event); + + ret = sas_queue_event(event, &ev->work, ha); + if (ret != 1) + sas_free_event(ev); + + return ret; } int sas_notify_phy_event(struct asd_sas_phy *phy, enum phy_event event) { + struct asd_sas_event *ev; struct sas_ha_struct *ha = phy->ha; + int ret; BUG_ON(event >= PHY_NUM_EVENTS); - return sas_queue_event(event, &phy->phy_events_pending, - &phy->phy_events[event].work, ha); + ev = sas_alloc_event(phy); + if (!ev) + return -ENOMEM; + + INIT_SAS_EVENT(ev, sas_phy_event_worker, phy, event); + + ret = sas_queue_event(event, &ev->work, ha); + if (ret != 1) + sas_free_event(ev); + + return ret; } int sas_init_events(struct sas_ha_struct *sas_ha) --- a/drivers/scsi/libsas/sas_init.c +++ b/drivers/scsi/libsas/sas_init.c @@ -39,6 +39,7 @@ #include "../scsi_sas_internal.h" static struct kmem_cache *sas_task_cache; +static struct kmem_cache *sas_event_cache; struct sas_task *sas_alloc_task(gfp_t flags) { @@ -364,8 +365,6 @@ void sas_prep_resume_ha(struct sas_ha_st struct asd_sas_phy *phy = ha->sas_phy[i]; memset(phy->attached_sas_addr, 0, SAS_ADDR_SIZE); - phy->port_events_pending = 0; - phy->phy_events_pending = 0; phy->frame_rcvd_size = 0; } } @@ -555,20 +554,42 @@ sas_domain_attach_transport(struct sas_d } EXPORT_SYMBOL_GPL(sas_domain_attach_transport); + +struct asd_sas_event *sas_alloc_event(struct asd_sas_phy *phy) +{ + gfp_t flags = in_interrupt() ? GFP_ATOMIC : GFP_KERNEL; + + return kmem_cache_zalloc(sas_event_cache, flags); +} + +void sas_free_event(struct asd_sas_event *event) +{ + kmem_cache_free(sas_event_cache, event); +} + /* ---------- SAS Class register/unregister ---------- */ static int __init sas_class_init(void) { sas_task_cache = KMEM_CACHE(sas_task, SLAB_HWCACHE_ALIGN); if (!sas_task_cache) - return -ENOMEM; + goto out; + + sas_event_cache = KMEM_CACHE(asd_sas_event, SLAB_HWCACHE_ALIGN); + if (!sas_event_cache) + goto free_task_kmem; return 0; +free_task_kmem: + kmem_cache_destroy(sas_task_cache); +out: + return -ENOMEM; } static void __exit sas_class_exit(void) { kmem_cache_destroy(sas_task_cache); + kmem_cache_destroy(sas_event_cache); } MODULE_AUTHOR("Luben Tuikov <luben_tuikov(a)adaptec.com>"); --- a/drivers/scsi/libsas/sas_internal.h +++ b/drivers/scsi/libsas/sas_internal.h @@ -61,6 +61,9 @@ int sas_show_oob_mode(enum sas_oob_mode int sas_register_phys(struct sas_ha_struct *sas_ha); void sas_unregister_phys(struct sas_ha_struct *sas_ha); +struct asd_sas_event *sas_alloc_event(struct asd_sas_phy *phy); +void sas_free_event(struct asd_sas_event *event); + int sas_register_ports(struct sas_ha_struct *sas_ha); void sas_unregister_ports(struct sas_ha_struct *sas_ha); @@ -99,6 +102,9 @@ void sas_hae_reset(struct work_struct *w void sas_free_device(struct kref *kref); +extern const work_func_t sas_phy_event_fns[PHY_NUM_EVENTS]; +extern const work_func_t sas_port_event_fns[PORT_NUM_EVENTS]; + #ifdef CONFIG_SCSI_SAS_HOST_SMP extern void sas_smp_host_handler(struct bsg_job *job, struct Scsi_Host *shost); #else --- a/drivers/scsi/libsas/sas_phy.c +++ b/drivers/scsi/libsas/sas_phy.c @@ -35,7 +35,6 @@ static void sas_phye_loss_of_signal(stru struct asd_sas_event *ev = to_asd_sas_event(work); struct asd_sas_phy *phy = ev->phy; - clear_bit(PHYE_LOSS_OF_SIGNAL, &phy->phy_events_pending); phy->error = 0; sas_deform_port(phy, 1); } @@ -45,7 +44,6 @@ static void sas_phye_oob_done(struct wor struct asd_sas_event *ev = to_asd_sas_event(work); struct asd_sas_phy *phy = ev->phy; - clear_bit(PHYE_OOB_DONE, &phy->phy_events_pending); phy->error = 0; } @@ -58,8 +56,6 @@ static void sas_phye_oob_error(struct wo struct sas_internal *i = to_sas_internal(sas_ha->core.shost->transportt); - clear_bit(PHYE_OOB_ERROR, &phy->phy_events_pending); - sas_deform_port(phy, 1); if (!port && phy->enabled && i->dft->lldd_control_phy) { @@ -88,8 +84,6 @@ static void sas_phye_spinup_hold(struct struct sas_internal *i = to_sas_internal(sas_ha->core.shost->transportt); - clear_bit(PHYE_SPINUP_HOLD, &phy->phy_events_pending); - phy->error = 0; i->dft->lldd_control_phy(phy, PHY_FUNC_RELEASE_SPINUP_HOLD, NULL); } @@ -99,8 +93,6 @@ static void sas_phye_resume_timeout(stru struct asd_sas_event *ev = to_asd_sas_event(work); struct asd_sas_phy *phy = ev->phy; - clear_bit(PHYE_RESUME_TIMEOUT, &phy->phy_events_pending); - /* phew, lldd got the phy back in the nick of time */ if (!phy->suspended) { dev_info(&phy->phy->dev, "resume timeout cancelled\n"); @@ -119,39 +111,12 @@ int sas_register_phys(struct sas_ha_stru { int i; - static const work_func_t sas_phy_event_fns[PHY_NUM_EVENTS] = { - [PHYE_LOSS_OF_SIGNAL] = sas_phye_loss_of_signal, - [PHYE_OOB_DONE] = sas_phye_oob_done, - [PHYE_OOB_ERROR] = sas_phye_oob_error, - [PHYE_SPINUP_HOLD] = sas_phye_spinup_hold, - [PHYE_RESUME_TIMEOUT] = sas_phye_resume_timeout, - - }; - - static const work_func_t sas_port_event_fns[PORT_NUM_EVENTS] = { - [PORTE_BYTES_DMAED] = sas_porte_bytes_dmaed, - [PORTE_BROADCAST_RCVD] = sas_porte_broadcast_rcvd, - [PORTE_LINK_RESET_ERR] = sas_porte_link_reset_err, - [PORTE_TIMER_EVENT] = sas_porte_timer_event, - [PORTE_HARD_RESET] = sas_porte_hard_reset, - }; - /* Now register the phys. */ for (i = 0; i < sas_ha->num_phys; i++) { - int k; struct asd_sas_phy *phy = sas_ha->sas_phy[i]; phy->error = 0; INIT_LIST_HEAD(&phy->port_phy_el); - for (k = 0; k < PORT_NUM_EVENTS; k++) { - INIT_SAS_WORK(&phy->port_events[k].work, sas_port_event_fns[k]); - phy->port_events[k].phy = phy; - } - - for (k = 0; k < PHY_NUM_EVENTS; k++) { - INIT_SAS_WORK(&phy->phy_events[k].work, sas_phy_event_fns[k]); - phy->phy_events[k].phy = phy; - } phy->port = NULL; phy->ha = sas_ha; @@ -179,3 +144,12 @@ int sas_register_phys(struct sas_ha_stru return 0; } + +const work_func_t sas_phy_event_fns[PHY_NUM_EVENTS] = { + [PHYE_LOSS_OF_SIGNAL] = sas_phye_loss_of_signal, + [PHYE_OOB_DONE] = sas_phye_oob_done, + [PHYE_OOB_ERROR] = sas_phye_oob_error, + [PHYE_SPINUP_HOLD] = sas_phye_spinup_hold, + [PHYE_RESUME_TIMEOUT] = sas_phye_resume_timeout, + +}; --- a/drivers/scsi/libsas/sas_port.c +++ b/drivers/scsi/libsas/sas_port.c @@ -261,8 +261,6 @@ void sas_porte_bytes_dmaed(struct work_s struct asd_sas_event *ev = to_asd_sas_event(work); struct asd_sas_phy *phy = ev->phy; - clear_bit(PORTE_BYTES_DMAED, &phy->port_events_pending); - sas_form_port(phy); } @@ -273,8 +271,6 @@ void sas_porte_broadcast_rcvd(struct wor unsigned long flags; u32 prim; - clear_bit(PORTE_BROADCAST_RCVD, &phy->port_events_pending); - spin_lock_irqsave(&phy->sas_prim_lock, flags); prim = phy->sas_prim; spin_unlock_irqrestore(&phy->sas_prim_lock, flags); @@ -288,8 +284,6 @@ void sas_porte_link_reset_err(struct wor struct asd_sas_event *ev = to_asd_sas_event(work); struct asd_sas_phy *phy = ev->phy; - clear_bit(PORTE_LINK_RESET_ERR, &phy->port_events_pending); - sas_deform_port(phy, 1); } @@ -298,8 +292,6 @@ void sas_porte_timer_event(struct work_s struct asd_sas_event *ev = to_asd_sas_event(work); struct asd_sas_phy *phy = ev->phy; - clear_bit(PORTE_TIMER_EVENT, &phy->port_events_pending); - sas_deform_port(phy, 1); } @@ -308,8 +300,6 @@ void sas_porte_hard_reset(struct work_st struct asd_sas_event *ev = to_asd_sas_event(work); struct asd_sas_phy *phy = ev->phy; - clear_bit(PORTE_HARD_RESET, &phy->port_events_pending); - sas_deform_port(phy, 1); } @@ -353,3 +343,11 @@ void sas_unregister_ports(struct sas_ha_ sas_deform_port(sas_ha->sas_phy[i], 0); } + +const work_func_t sas_port_event_fns[PORT_NUM_EVENTS] = { + [PORTE_BYTES_DMAED] = sas_porte_bytes_dmaed, + [PORTE_BROADCAST_RCVD] = sas_porte_broadcast_rcvd, + [PORTE_LINK_RESET_ERR] = sas_porte_link_reset_err, + [PORTE_TIMER_EVENT] = sas_porte_timer_event, + [PORTE_HARD_RESET] = sas_porte_hard_reset, +}; --- a/include/scsi/libsas.h +++ b/include/scsi/libsas.h @@ -292,6 +292,7 @@ struct asd_sas_port { struct asd_sas_event { struct sas_work work; struct asd_sas_phy *phy; + int event; }; static inline struct asd_sas_event *to_asd_sas_event(struct work_struct *work) @@ -301,17 +302,21 @@ static inline struct asd_sas_event *to_a return ev; } +static inline void INIT_SAS_EVENT(struct asd_sas_event *ev, + void (*fn)(struct work_struct *), + struct asd_sas_phy *phy, int event) +{ + INIT_SAS_WORK(&ev->work, fn); + ev->phy = phy; + ev->event = event; +} + + /* The phy pretty much is controlled by the LLDD. * The class only reads those fields. */ struct asd_sas_phy { /* private: */ - struct asd_sas_event port_events[PORT_NUM_EVENTS]; - struct asd_sas_event phy_events[PHY_NUM_EVENTS]; - - unsigned long port_events_pending; - unsigned long phy_events_pending; - int error; int suspended; Patches currently in stable-queue which might be from yanaijie(a)huawei.com are queue-4.15/scsi-libsas-initialize-sas_phy-status-according-to-response-of-discover.patch queue-4.15/scsi-libsas-fix-error-when-getting-phy-events.patch queue-4.15/scsi-libsas-fix-memory-leak-in-sas_smp_get_phy_events.patch queue-4.15/scsi-libsas-use-dynamic-alloced-work-to-avoid-sas-event-lost.patch

7 years, 2 months

1
0
0 0

Patch "scsi: libsas: initialize sas_phy status according to response of DISCOVER" 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 scsi: libsas: initialize sas_phy status according to response of DISCOVER 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: scsi-libsas-initialize-sas_phy-status-according-to-response-of-discover.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: chenxiang <chenxiang66(a)hisilicon.com> Date: Thu, 4 Jan 2018 21:04:33 +0800 Subject: scsi: libsas: initialize sas_phy status according to response of DISCOVER From: chenxiang <chenxiang66(a)hisilicon.com> [ Upstream commit affc67788fe5dfffad5cda3d461db5cf2b2ff2b0 ] The status of SAS PHY is in sas_phy->enabled. There is an issue that the status of a remote SAS PHY may be initialized incorrectly: if disable remote SAS PHY through sysfs interface (such as echo 0 > /sys/class/sas_phy/phy-1:0:0/enable), then reboot the system, and we will find the status of remote SAS PHY which is disabled before is 1 (cat /sys/class/sas_phy/phy-1:0:0/enable). But actually the status of remote SAS PHY is disabled and the device attached is not found. In SAS protocol, NEGOTIATED LOGICAL LINK RATE field of DISCOVER response is 0x1 when remote SAS PHY is disabled. So initialize sas_phy->enabled according to the value of NEGOTIATED LOGICAL LINK RATE field. Signed-off-by: chenxiang <chenxiang66(a)hisilicon.com> Reviewed-by: John Garry <john.garry(a)huawei.com> Signed-off-by: Jason Yan <yanaijie(a)huawei.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/libsas/sas_expander.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/scsi/libsas/sas_expander.c +++ b/drivers/scsi/libsas/sas_expander.c @@ -293,6 +293,7 @@ static void sas_set_ex_phy(struct domain phy->phy->minimum_linkrate = dr->pmin_linkrate; phy->phy->maximum_linkrate = dr->pmax_linkrate; phy->phy->negotiated_linkrate = phy->linkrate; + phy->phy->enabled = (phy->linkrate != SAS_PHY_DISABLED); skip: if (new_phy) Patches currently in stable-queue which might be from chenxiang66(a)hisilicon.com are queue-4.15/scsi-libsas-initialize-sas_phy-status-according-to-response-of-discover.patch queue-4.15/scsi-libsas-fix-error-when-getting-phy-events.patch queue-4.15/scsi-libsas-fix-memory-leak-in-sas_smp_get_phy_events.patch

7 years, 2 months

1
0
0 0

Patch "scsi: libsas: fix memory leak in sas_smp_get_phy_events()" 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 scsi: libsas: fix memory leak in sas_smp_get_phy_events() 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: scsi-libsas-fix-memory-leak-in-sas_smp_get_phy_events.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Jason Yan <yanaijie(a)huawei.com> Date: Thu, 4 Jan 2018 21:04:31 +0800 Subject: scsi: libsas: fix memory leak in sas_smp_get_phy_events() From: Jason Yan <yanaijie(a)huawei.com> [ Upstream commit 4a491b1ab11ca0556d2fda1ff1301e862a2d44c4 ] We've got a memory leak with the following producer: while true; do cat /sys/class/sas_phy/phy-1:0:12/invalid_dword_count >/dev/null; done The buffer req is allocated and not freed after we return. Fix it. Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver") Signed-off-by: Jason Yan <yanaijie(a)huawei.com> CC: John Garry <john.garry(a)huawei.com> CC: chenqilin <chenqilin2(a)huawei.com> CC: chenxiang <chenxiang66(a)hisilicon.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/libsas/sas_expander.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/scsi/libsas/sas_expander.c +++ b/drivers/scsi/libsas/sas_expander.c @@ -695,6 +695,7 @@ int sas_smp_get_phy_events(struct sas_ph phy->phy_reset_problem_count = scsi_to_u32(&resp[24]); out: + kfree(req); kfree(resp); return res; Patches currently in stable-queue which might be from yanaijie(a)huawei.com are queue-4.15/scsi-libsas-initialize-sas_phy-status-according-to-response-of-discover.patch queue-4.15/scsi-libsas-fix-error-when-getting-phy-events.patch queue-4.15/scsi-libsas-fix-memory-leak-in-sas_smp_get_phy_events.patch queue-4.15/scsi-libsas-use-dynamic-alloced-work-to-avoid-sas-event-lost.patch

7 years, 2 months

1
0
0 0

Patch "scsi: libsas: fix error when getting phy events" 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 scsi: libsas: fix error when getting phy events 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: scsi-libsas-fix-error-when-getting-phy-events.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Jason Yan <yanaijie(a)huawei.com> Date: Thu, 4 Jan 2018 21:04:32 +0800 Subject: scsi: libsas: fix error when getting phy events From: Jason Yan <yanaijie(a)huawei.com> [ Upstream commit 2b23d9509fd7174b362482cf5f3b5f9a2265bc33 ] The intend purpose here was to goto out if smp_execute_task() returned error. Obviously something got screwed up. We will never get these link error statistics below: ~:/sys/class/sas_phy/phy-1:0:12 # cat invalid_dword_count 0 ~:/sys/class/sas_phy/phy-1:0:12 # cat running_disparity_error_count 0 ~:/sys/class/sas_phy/phy-1:0:12 # cat loss_of_dword_sync_count 0 ~:/sys/class/sas_phy/phy-1:0:12 # cat phy_reset_problem_count 0 Obviously we should goto error handler if smp_execute_task() returns non-zero. Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver") Signed-off-by: Jason Yan <yanaijie(a)huawei.com> CC: John Garry <john.garry(a)huawei.com> CC: chenqilin <chenqilin2(a)huawei.com> CC: chenxiang <chenxiang66(a)hisilicon.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/libsas/sas_expander.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/scsi/libsas/sas_expander.c +++ b/drivers/scsi/libsas/sas_expander.c @@ -686,7 +686,7 @@ int sas_smp_get_phy_events(struct sas_ph res = smp_execute_task(dev, req, RPEL_REQ_SIZE, resp, RPEL_RESP_SIZE); - if (!res) + if (res) goto out; phy->invalid_dword_count = scsi_to_u32(&resp[12]); Patches currently in stable-queue which might be from yanaijie(a)huawei.com are queue-4.15/scsi-libsas-initialize-sas_phy-status-according-to-response-of-discover.patch queue-4.15/scsi-libsas-fix-error-when-getting-phy-events.patch queue-4.15/scsi-libsas-fix-memory-leak-in-sas_smp_get_phy_events.patch queue-4.15/scsi-libsas-use-dynamic-alloced-work-to-avoid-sas-event-lost.patch

7 years, 2 months

1
0
0 0

Patch "scsi: libiscsi: Allow sd_shutdown on bad transport" 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 scsi: libiscsi: Allow sd_shutdown on bad transport 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: scsi-libiscsi-allow-sd_shutdown-on-bad-transport.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Rafael David Tinoco <rafael.tinoco(a)canonical.com> Date: Thu, 7 Dec 2017 19:59:13 -0200 Subject: scsi: libiscsi: Allow sd_shutdown on bad transport From: Rafael David Tinoco <rafael.tinoco(a)canonical.com> [ Upstream commit d754941225a7dbc61f6dd2173fa9498049f9a7ee ] If, for any reason, userland shuts down iscsi transport interfaces before proper logouts - like when logging in to LUNs manually, without logging out on server shutdown, or when automated scripts can't umount/logout from logged LUNs - kernel will hang forever on its sd_sync_cache() logic, after issuing the SYNCHRONIZE_CACHE cmd to all still existent paths. PID: 1 TASK: ffff8801a69b8000 CPU: 1 COMMAND: "systemd-shutdow" #0 [ffff8801a69c3a30] __schedule at ffffffff8183e9ee #1 [ffff8801a69c3a80] schedule at ffffffff8183f0d5 #2 [ffff8801a69c3a98] schedule_timeout at ffffffff81842199 #3 [ffff8801a69c3b40] io_schedule_timeout at ffffffff8183e604 #4 [ffff8801a69c3b70] wait_for_completion_io_timeout at ffffffff8183fc6c #5 [ffff8801a69c3bd0] blk_execute_rq at ffffffff813cfe10 #6 [ffff8801a69c3c88] scsi_execute at ffffffff815c3fc7 #7 [ffff8801a69c3cc8] scsi_execute_req_flags at ffffffff815c60fe #8 [ffff8801a69c3d30] sd_sync_cache at ffffffff815d37d7 #9 [ffff8801a69c3da8] sd_shutdown at ffffffff815d3c3c This happens because iscsi_eh_cmd_timed_out(), the transport layer timeout helper, would tell the queue timeout function (scsi_times_out) to reset the request timer over and over, until the session state is back to logged in state. Unfortunately, during server shutdown, this might never happen again. Other option would be "not to handle" the issue in the transport layer. That would trigger the error handler logic, which would also need the session state to be logged in again. Best option, for such case, is to tell upper layers that the command was handled during the transport layer error handler helper, marking it as DID_NO_CONNECT, which will allow completion and inform about the problem. After the session was marked as ISCSI_STATE_FAILED, due to the first timeout during the server shutdown phase, all subsequent cmds will fail to be queued, allowing upper logic to fail faster. Signed-off-by: Rafael David Tinoco <rafael.tinoco(a)canonical.com> Reviewed-by: Lee Duncan <lduncan(a)suse.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/libiscsi.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) --- a/drivers/scsi/libiscsi.c +++ b/drivers/scsi/libiscsi.c @@ -1696,6 +1696,15 @@ int iscsi_queuecommand(struct Scsi_Host */ switch (session->state) { case ISCSI_STATE_FAILED: + /* + * cmds should fail during shutdown, if the session + * state is bad, allowing completion to happen + */ + if (unlikely(system_state != SYSTEM_RUNNING)) { + reason = FAILURE_SESSION_FAILED; + sc->result = DID_NO_CONNECT << 16; + break; + } case ISCSI_STATE_IN_RECOVERY: reason = FAILURE_SESSION_IN_RECOVERY; sc->result = DID_IMM_RETRY << 16; @@ -1979,6 +1988,19 @@ enum blk_eh_timer_return iscsi_eh_cmd_ti if (session->state != ISCSI_STATE_LOGGED_IN) { /* + * During shutdown, if session is prematurely disconnected, + * recovery won't happen and there will be hung cmds. Not + * handling cmds would trigger EH, also bad in this case. + * Instead, handle cmd, allow completion to happen and let + * upper layer to deal with the result. + */ + if (unlikely(system_state != SYSTEM_RUNNING)) { + sc->result = DID_NO_CONNECT << 16; + ISCSI_DBG_EH(session, "sc on shutdown, handled\n"); + rc = BLK_EH_HANDLED; + goto done; + } + /* * We are probably in the middle of iscsi recovery so let * that complete and handle the error. */ @@ -2082,7 +2104,7 @@ done: task->last_timeout = jiffies; spin_unlock(&session->frwd_lock); ISCSI_DBG_EH(session, "return %s\n", rc == BLK_EH_RESET_TIMER ? - "timer reset" : "nh"); + "timer reset" : "shutdown or nh"); return rc; } EXPORT_SYMBOL_GPL(iscsi_eh_cmd_timed_out); Patches currently in stable-queue which might be from rafael.tinoco(a)canonical.com are queue-4.15/scsi-libiscsi-allow-sd_shutdown-on-bad-transport.patch

7 years, 2 months

1
0
0 0

Patch "rt2x00: do not pause queue unconditionally on error path" 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 rt2x00: do not pause queue unconditionally on error path 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: rt2x00-do-not-pause-queue-unconditionally-on-error-path.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Stanislaw Gruszka <sgruszka(a)redhat.com> Date: Tue, 19 Dec 2017 12:33:56 +0100 Subject: rt2x00: do not pause queue unconditionally on error path From: Stanislaw Gruszka <sgruszka(a)redhat.com> [ Upstream commit 6dd80efd75ce7c2dbd9f117cf585ee2b33a42ee1 ] Pausing queue without checking threshold is racy with txdone path. Moreover we do not need pause queue on any error, but only if queue is full - in case when we send RTS frame ( other cases of almost full queue are already handled in rt2x00queue_write_tx_frame() ). Patch fixes of theoretically possible problem of pausing empty queue. Signed-off-by: Stanislaw Gruszka <sgruszka(a)redhat.com> Tested-by: Enrico Mioso <mrkiko.rs(a)gmail.com> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ralink/rt2x00/rt2x00mac.c | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) --- a/drivers/net/wireless/ralink/rt2x00/rt2x00mac.c +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00mac.c @@ -142,15 +142,25 @@ void rt2x00mac_tx(struct ieee80211_hw *h if (!rt2x00dev->ops->hw->set_rts_threshold && (tx_info->control.rates[0].flags & (IEEE80211_TX_RC_USE_RTS_CTS | IEEE80211_TX_RC_USE_CTS_PROTECT))) { - if (rt2x00queue_available(queue) <= 1) - goto exit_fail; + if (rt2x00queue_available(queue) <= 1) { + /* + * Recheck for full queue under lock to avoid race + * conditions with rt2x00lib_txdone(). + */ + spin_lock(&queue->tx_lock); + if (rt2x00queue_threshold(queue)) + rt2x00queue_pause_queue(queue); + spin_unlock(&queue->tx_lock); + + goto exit_free_skb; + } if (rt2x00mac_tx_rts_cts(rt2x00dev, queue, skb)) - goto exit_fail; + goto exit_free_skb; } if (unlikely(rt2x00queue_write_tx_frame(queue, skb, control->sta, false))) - goto exit_fail; + goto exit_free_skb; /* * Pausing queue has to be serialized with rt2x00lib_txdone(). Note @@ -164,10 +174,6 @@ void rt2x00mac_tx(struct ieee80211_hw *h return; - exit_fail: - spin_lock(&queue->tx_lock); - rt2x00queue_pause_queue(queue); - spin_unlock(&queue->tx_lock); exit_free_skb: ieee80211_free_txskb(hw, skb); } Patches currently in stable-queue which might be from sgruszka(a)redhat.com are queue-4.15/rt2x00-do-not-pause-queue-unconditionally-on-error-path.patch

7 years, 2 months

1
0
0 0

Patch "rds; Reset rs->rs_bound_addr in rds_add_bound() failure path" 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 rds; Reset rs->rs_bound_addr in rds_add_bound() failure path 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: rds-reset-rs-rs_bound_addr-in-rds_add_bound-failure-path.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com> Date: Fri, 22 Dec 2017 09:38:59 -0800 Subject: rds; Reset rs->rs_bound_addr in rds_add_bound() failure path From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com> [ Upstream commit 7ae0c649c47f1c5d2db8cee6dd75855970af1669 ] If the rds_sock is not added to the bind_hash_table, we must reset rs_bound_addr so that rds_remove_bound will not trip on this rds_sock. rds_add_bound() does a rds_sock_put() in this failure path, so failing to reset rs_bound_addr will result in a socket refcount bug, and will trigger a WARN_ON with the stack shown below when the application subsequently tries to close the PF_RDS socket. WARNING: CPU: 20 PID: 19499 at net/rds/af_rds.c:496 \ rds_sock_destruct+0x15/0x30 [rds] : __sk_destruct+0x21/0x190 rds_remove_bound.part.13+0xb6/0x140 [rds] rds_release+0x71/0x120 [rds] sock_release+0x1a/0x70 sock_close+0xe/0x20 __fput+0xd5/0x210 task_work_run+0x82/0xa0 do_exit+0x2ce/0xb30 ? syscall_trace_enter+0x1cc/0x2b0 do_group_exit+0x39/0xa0 SyS_exit_group+0x10/0x10 do_syscall_64+0x61/0x1a0 Signed-off-by: Sowmini Varadhan <sowmini.varadhan(a)oracle.com> Acked-by: Santosh Shilimkar <santosh.shilimkar(a)oracle.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/rds/bind.c | 1 + 1 file changed, 1 insertion(+) --- a/net/rds/bind.c +++ b/net/rds/bind.c @@ -114,6 +114,7 @@ static int rds_add_bound(struct rds_sock rs, &addr, (int)ntohs(*port)); break; } else { + rs->rs_bound_addr = 0; rds_sock_put(rs); ret = -ENOMEM; break; Patches currently in stable-queue which might be from sowmini.varadhan(a)oracle.com are queue-4.15/selftests-net-fix-bugs-in-address-and-port-initialization.patch queue-4.15/rds-reset-rs-rs_bound_addr-in-rds_add_bound-failure-path.patch

7 years, 2 months

1
0
0 0

Patch "RDMA/hns: Update the usage of sr_max and rr_max field" 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/hns: Update the usage of sr_max and rr_max field 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-hns-update-the-usage-of-sr_max-and-rr_max-field.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: oulijun <oulijun(a)huawei.com> Date: Wed, 3 Jan 2018 10:44:04 +0800 Subject: RDMA/hns: Update the usage of sr_max and rr_max field From: oulijun <oulijun(a)huawei.com> [ Upstream commit 4f3f7a704b3bff9e4eb322ab3c989b505f7562eb ] This patch fixes the usage with sr_max filed and rr_max of qp context when modify qp. Its modifications include: 1. Adjust location of filling sr_max filed of qpc 2. Only assign the number of responder resource if IB_QP_MAX_DEST_RD_ATOMIC bit is set 3. Only assign the number of outstanding resource if IB_QP_MAX_QP_RD_ATOMIC 4. Fix the assgin algorithms for the field of sr_max and rr_max of qp context Signed-off-by: Lijun Ou <oulijun(a)huawei.com> Signed-off-by: Yixian Liu <liuyixian(a)huawei.com> Signed-off-by: Wei Hu (Xavier) <xavier.huwei(a)huawei.com> Reviewed-by: Leon Romanovsky <leonro(a)mellanox.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 27 ++++++++++++++++----------- 1 file changed, 16 insertions(+), 11 deletions(-) --- a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c @@ -2463,11 +2463,14 @@ static int modify_qp_init_to_rtr(struct roce_set_bit(qpc_mask->byte_28_at_fl, V2_QPC_BYTE_28_LBI_S, 0); } - roce_set_field(context->byte_140_raq, V2_QPC_BYTE_140_RR_MAX_M, - V2_QPC_BYTE_140_RR_MAX_S, - ilog2((unsigned int)attr->max_dest_rd_atomic)); - roce_set_field(qpc_mask->byte_140_raq, V2_QPC_BYTE_140_RR_MAX_M, - V2_QPC_BYTE_140_RR_MAX_S, 0); + if ((attr_mask & IB_QP_MAX_DEST_RD_ATOMIC) && + attr->max_dest_rd_atomic) { + roce_set_field(context->byte_140_raq, V2_QPC_BYTE_140_RR_MAX_M, + V2_QPC_BYTE_140_RR_MAX_S, + fls(attr->max_dest_rd_atomic - 1)); + roce_set_field(qpc_mask->byte_140_raq, V2_QPC_BYTE_140_RR_MAX_M, + V2_QPC_BYTE_140_RR_MAX_S, 0); + } roce_set_field(context->byte_56_dqpn_err, V2_QPC_BYTE_56_DQPN_M, V2_QPC_BYTE_56_DQPN_S, attr->dest_qp_num); @@ -2557,12 +2560,6 @@ static int modify_qp_init_to_rtr(struct V2_QPC_BYTE_168_LP_SGEN_INI_M, V2_QPC_BYTE_168_LP_SGEN_INI_S, 0); - roce_set_field(context->byte_208_irrl, V2_QPC_BYTE_208_SR_MAX_M, - V2_QPC_BYTE_208_SR_MAX_S, - ilog2((unsigned int)attr->max_rd_atomic)); - roce_set_field(qpc_mask->byte_208_irrl, V2_QPC_BYTE_208_SR_MAX_M, - V2_QPC_BYTE_208_SR_MAX_S, 0); - roce_set_field(context->byte_28_at_fl, V2_QPC_BYTE_28_SL_M, V2_QPC_BYTE_28_SL_S, rdma_ah_get_sl(&attr->ah_attr)); roce_set_field(qpc_mask->byte_28_at_fl, V2_QPC_BYTE_28_SL_M, @@ -2766,6 +2763,14 @@ static int modify_qp_rtr_to_rts(struct i roce_set_field(qpc_mask->byte_196_sq_psn, V2_QPC_BYTE_196_SQ_MAX_PSN_M, V2_QPC_BYTE_196_SQ_MAX_PSN_S, 0); + if ((attr_mask & IB_QP_MAX_QP_RD_ATOMIC) && attr->max_rd_atomic) { + roce_set_field(context->byte_208_irrl, V2_QPC_BYTE_208_SR_MAX_M, + V2_QPC_BYTE_208_SR_MAX_S, + fls(attr->max_rd_atomic - 1)); + roce_set_field(qpc_mask->byte_208_irrl, + V2_QPC_BYTE_208_SR_MAX_M, + V2_QPC_BYTE_208_SR_MAX_S, 0); + } return 0; } Patches currently in stable-queue which might be from oulijun(a)huawei.com are queue-4.15/rdma-hns-update-the-usage-of-sr_max-and-rr_max-field.patch

7 years, 2 months

1
0
0 0

Patch "RDMA/cma: Fix rdma_cm path querying for RoCE" 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/cma: Fix rdma_cm path querying for RoCE 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-cma-fix-rdma_cm-path-querying-for-roce.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Parav Pandit <parav(a)mellanox.com> Date: Mon, 8 Jan 2018 17:04:48 +0200 Subject: RDMA/cma: Fix rdma_cm path querying for RoCE From: Parav Pandit <parav(a)mellanox.com> [ Upstream commit 89838118a515847d3e5c904d2e022779a7173bec ] The 'if' logic in ucma_query_path was broken with OPA was introduced and started to treat RoCE paths as as OPA paths. Invert the logic of the 'if' so only OPA paths are treated as OPA paths. Otherwise the path records returned to rdma_cma users are mangled when in RoCE mode. Fixes: 57520751445b ("IB/SA: Add OPA path record type") Signed-off-by: Parav Pandit <parav(a)mellanox.com> Reviewed-by: Mark Bloch <markb(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/core/ucma.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/drivers/infiniband/core/ucma.c +++ b/drivers/infiniband/core/ucma.c @@ -914,13 +914,14 @@ static ssize_t ucma_query_path(struct uc resp->path_data[i].flags = IB_PATH_GMP | IB_PATH_PRIMARY | IB_PATH_BIDIRECTIONAL; - if (rec->rec_type == SA_PATH_REC_TYPE_IB) { - ib_sa_pack_path(rec, &resp->path_data[i].path_rec); - } else { + if (rec->rec_type == SA_PATH_REC_TYPE_OPA) { struct sa_path_rec ib; sa_convert_path_opa_to_ib(&ib, rec); ib_sa_pack_path(&ib, &resp->path_data[i].path_rec); + + } else { + ib_sa_pack_path(rec, &resp->path_data[i].path_rec); } } Patches currently in stable-queue which might be from parav(a)mellanox.com are queue-4.15/net-mlx5-fix-race-for-multiple-roce-enable.patch queue-4.15/rdma-cma-fix-rdma_cm-path-querying-for-roce.patch

7 years, 2 months

1
0
0 0

Patch "powernv-cpufreq: Add helper to extract pstate from PMSR" 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 powernv-cpufreq: Add helper to extract pstate from PMSR 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: powernv-cpufreq-add-helper-to-extract-pstate-from-pmsr.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: "Gautham R. Shenoy" <ego(a)linux.vnet.ibm.com> Date: Wed, 13 Dec 2017 12:27:39 +0530 Subject: powernv-cpufreq: Add helper to extract pstate from PMSR From: "Gautham R. Shenoy" <ego(a)linux.vnet.ibm.com> [ Upstream commit ee1f4a7dafa997816ff3de96155c6f3edc21c1e6 ] On POWERNV platform, the fields for pstates in the Power Management Status Register (PMSR) and the Power Management Control Register (PMCR) are 8-bits wide. On POWER8 the pstates are negatively numbered while on POWER9 they are positively numbered. The device-tree exports pstates as 32-bit entries. The device-tree implementation sign-extends the 8-bit pstate values to obtain the corresponding 32-bit entry. Eg: On POWER8, a pstate value 0x82 [-126] is represented in the device-tree as 0xfffffff82 while on POWER9, the same value 0x82 [130] is represented in the device-tree as 0x00000082. The powernv-cpufreq driver implementation represents pstates using the integer type. In multiple places in the driver, the code interprets the pstates extracted from the PMSR as a signed byte and assigns it to a integer variable to get the sign-extention. On POWER9 platforms which have greater than 128 pstates, this results in the driver performing incorrect sign-extention, and thereby treating a legitimate pstate (say 130) as an invalid pstates (since it is interpreted as -126). This patch fixes the issue by implementing a helper function to extract Pstates from PMSR register, and correctly sign-extend it to be consistent with the values provided by the device-tree. Signed-off-by: Gautham R. Shenoy <ego(a)linux.vnet.ibm.com> Acked-by: Balbir Singh <bsingharora(a)gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/cpufreq/powernv-cpufreq.c | 37 +++++++++++++++++++++++-------------- 1 file changed, 23 insertions(+), 14 deletions(-) --- a/drivers/cpufreq/powernv-cpufreq.c +++ b/drivers/cpufreq/powernv-cpufreq.c @@ -41,11 +41,9 @@ #define POWERNV_MAX_PSTATES 256 #define PMSR_PSAFE_ENABLE (1UL << 30) #define PMSR_SPR_EM_DISABLE (1UL << 31) -#define PMSR_MAX(x) ((x >> 32) & 0xFF) +#define MAX_PSTATE_SHIFT 32 #define LPSTATE_SHIFT 48 #define GPSTATE_SHIFT 56 -#define GET_LPSTATE(x) (((x) >> LPSTATE_SHIFT) & 0xFF) -#define GET_GPSTATE(x) (((x) >> GPSTATE_SHIFT) & 0xFF) #define MAX_RAMP_DOWN_TIME 5120 /* @@ -94,6 +92,7 @@ struct global_pstate_info { }; static struct cpufreq_frequency_table powernv_freqs[POWERNV_MAX_PSTATES+1]; +u32 pstate_sign_prefix; static bool rebooting, throttled, occ_reset; static const char * const throttle_reason[] = { @@ -148,6 +147,20 @@ static struct powernv_pstate_info { bool wof_enabled; } powernv_pstate_info; +static inline int extract_pstate(u64 pmsr_val, unsigned int shift) +{ + int ret = ((pmsr_val >> shift) & 0xFF); + + if (!ret) + return ret; + + return (pstate_sign_prefix | ret); +} + +#define extract_local_pstate(x) extract_pstate(x, LPSTATE_SHIFT) +#define extract_global_pstate(x) extract_pstate(x, GPSTATE_SHIFT) +#define extract_max_pstate(x) extract_pstate(x, MAX_PSTATE_SHIFT) + /* Use following macros for conversions between pstate_id and index */ static inline int idx_to_pstate(unsigned int i) { @@ -278,6 +291,9 @@ next: powernv_pstate_info.nr_pstates = nr_pstates; pr_debug("NR PStates %d\n", nr_pstates); + + pstate_sign_prefix = pstate_min & ~0xFF; + for (i = 0; i < nr_pstates; i++) { u32 id = be32_to_cpu(pstate_ids[i]); u32 freq = be32_to_cpu(pstate_freqs[i]); @@ -438,17 +454,10 @@ struct powernv_smp_call_data { static void powernv_read_cpu_freq(void *arg) { unsigned long pmspr_val; - s8 local_pstate_id; struct powernv_smp_call_data *freq_data = arg; pmspr_val = get_pmspr(SPRN_PMSR); - - /* - * The local pstate id corresponds bits 48..55 in the PMSR. - * Note: Watch out for the sign! - */ - local_pstate_id = (pmspr_val >> 48) & 0xFF; - freq_data->pstate_id = local_pstate_id; + freq_data->pstate_id = extract_local_pstate(pmspr_val); freq_data->freq = pstate_id_to_freq(freq_data->pstate_id); pr_debug("cpu %d pmsr %016lX pstate_id %d frequency %d kHz\n", @@ -522,7 +531,7 @@ static void powernv_cpufreq_throttle_che chip = this_cpu_read(chip_info); /* Check for Pmax Capping */ - pmsr_pmax = (s8)PMSR_MAX(pmsr); + pmsr_pmax = extract_max_pstate(pmsr); pmsr_pmax_idx = pstate_to_idx(pmsr_pmax); if (pmsr_pmax_idx != powernv_pstate_info.max) { if (chip->throttled) @@ -645,8 +654,8 @@ void gpstate_timer_handler(struct timer_ * value. Hence, read from PMCR to get correct data. */ val = get_pmspr(SPRN_PMCR); - freq_data.gpstate_id = (s8)GET_GPSTATE(val); - freq_data.pstate_id = (s8)GET_LPSTATE(val); + freq_data.gpstate_id = extract_global_pstate(val); + freq_data.pstate_id = extract_local_pstate(val); if (freq_data.gpstate_id == freq_data.pstate_id) { reset_gpstates(policy); spin_unlock(&gpstates->gpstate_lock); Patches currently in stable-queue which might be from ego(a)linux.vnet.ibm.com are queue-4.15/powernv-cpufreq-add-helper-to-extract-pstate-from-pmsr.patch

7 years, 2 months

1
0
0 0

Patch "RDMA/cma: Mark end of CMA ID messages" 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/cma: Mark end of CMA ID messages 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-cma-mark-end-of-cma-id-messages.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Leon Romanovsky <leonro(a)mellanox.com> Date: Mon, 1 Jan 2018 13:07:17 +0200 Subject: RDMA/cma: Mark end of CMA ID messages From: Leon Romanovsky <leonro(a)mellanox.com> [ Upstream commit e48e5e198fb6ec77c91047a694022f0fefa45292 ] The commit 1a1c116f3dcf ("RDMA/netlink: Simplify the put_msg and put_attr") removes nlmsg_len calculation in ibnl_put_attr causing netlink messages and caused to miss source and destination addresses. Fixes: 1a1c116f3dcf ("RDMA/netlink: Simplify the put_msg and put_attr") Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/core/cma.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/infiniband/core/cma.c +++ b/drivers/infiniband/core/cma.c @@ -4449,6 +4449,7 @@ static int cma_get_id_stats(struct sk_bu id_stats->qp_type = id->qp_type; i_id++; + nlmsg_end(skb, nlh); } cb->args[1] = 0; Patches currently in stable-queue which might be from leonro(a)mellanox.com are queue-4.15/rdma-hns-update-the-usage-of-sr_max-and-rr_max-field.patch queue-4.15/rdma-cma-mark-end-of-cma-id-messages.patch

7 years, 2 months

1
0
0 0

Patch "power: supply: axp288_charger: Properly stop work on probe-error / remove" 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 power: supply: axp288_charger: Properly stop work on probe-error / remove 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: power-supply-axp288_charger-properly-stop-work-on-probe-error-remove.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Hans de Goede <hdegoede(a)redhat.com> Date: Tue, 26 Dec 2017 13:59:09 +0100 Subject: power: supply: axp288_charger: Properly stop work on probe-error / remove From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit 165c2357744e41391902a2a72dd170beb60c28d5 ] Properly stop any work we may have queued on probe-errors / remove. Rather then adding a remove driver callback for this, and goto style error handling to probe, use a devm_action for this. The devm_action gets registered before we register any of the extcon notifiers which may queue the work, devm does cleanup in reverse order, so this ensures that the notifiers are removed before we cancel the work. Reviewed-by: Chen-Yu Tsai <wens(a)csie.org> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel(a)collabora.co.uk> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/power/supply/axp288_charger.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) --- a/drivers/power/supply/axp288_charger.c +++ b/drivers/power/supply/axp288_charger.c @@ -785,6 +785,14 @@ static int charger_init_hw_regs(struct a return 0; } +static void axp288_charger_cancel_work(void *data) +{ + struct axp288_chrg_info *info = data; + + cancel_work_sync(&info->otg.work); + cancel_work_sync(&info->cable.work); +} + static int axp288_charger_probe(struct platform_device *pdev) { int ret, i, pirq; @@ -836,6 +844,11 @@ static int axp288_charger_probe(struct p return ret; } + /* Cancel our work on cleanup, register this before the notifiers */ + ret = devm_add_action(dev, axp288_charger_cancel_work, info); + if (ret) + return ret; + /* Register for extcon notification */ INIT_WORK(&info->cable.work, axp288_charger_extcon_evt_worker); info->cable.nb[0].notifier_call = axp288_charger_handle_cable0_evt; Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.15/serdev-fix-serdev_uevent-failure-on-acpi-enumerated-serdev-controllers.patch queue-4.15/acpi-video-default-lcd_only-to-true-on-win8-ready-and-newer-machines.patch queue-4.15/bluetooth-hci_bcm-mandate-presence-of-shutdown-and-device-wake-gpio.patch queue-4.15/input-goodix-disable-irqs-while-suspended.patch queue-4.15/asoc-intel-cht_bsw_rt5645-analog-mic-support.patch queue-4.15/power-supply-axp288_charger-properly-stop-work-on-probe-error-remove.patch queue-4.15/pinctrl-baytrail-enable-glitch-filter-for-gpios-used-as-interrupts.patch

7 years, 2 months

1
0
0 0

Patch "PM / devfreq: Fix potential NULL pointer dereference in governor_store" 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 PM / devfreq: Fix potential NULL pointer dereference in governor_store 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: pm-devfreq-fix-potential-null-pointer-dereference-in-governor_store.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com> Date: Wed, 6 Dec 2017 14:20:15 -0600 Subject: PM / devfreq: Fix potential NULL pointer dereference in governor_store From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com> [ Upstream commit 63f1e05f7fe9ca509c60154d6a833abf96eecdc9 ] df->governor is being dereferenced before it is null checked, hence there is a potential null pointer dereference. Notice that df->governor is being null checked at line 1004: if (df->governor) {, which implies it might be null. Fix this by null checking df->governor before dereferencing it. Addresses-Coverity-ID: 1401988 ("Dereference before null check") Fixes: bcf23c79c4e4 ("PM / devfreq: Fix available_governor sysfs") Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com> Reviewed-by: Chanwoo Choi <cw00.choi(a)samsung.com> Signed-off-by: MyungJoo Ham <myungjoo.ham(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/devfreq/devfreq.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/devfreq/devfreq.c +++ b/drivers/devfreq/devfreq.c @@ -996,7 +996,8 @@ static ssize_t governor_store(struct dev if (df->governor == governor) { ret = 0; goto out; - } else if (df->governor->immutable || governor->immutable) { + } else if ((df->governor && df->governor->immutable) || + governor->immutable) { ret = -EINVAL; goto out; } Patches currently in stable-queue which might be from garsilva(a)embeddedor.com are queue-4.15/pm-devfreq-fix-potential-null-pointer-dereference-in-governor_store.patch

7 years, 2 months

1
0
0 0

Patch "PM / domains: Don't skip driver's ->suspend|resume_noirq() callbacks" 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 PM / domains: Don't skip driver's ->suspend|resume_noirq() callbacks 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: pm-domains-don-t-skip-driver-s-suspend-resume_noirq-callbacks.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Ulf Hansson <ulf.hansson(a)linaro.org> Date: Wed, 10 Jan 2018 21:31:56 +0100 Subject: PM / domains: Don't skip driver's ->suspend|resume_noirq() callbacks From: Ulf Hansson <ulf.hansson(a)linaro.org> [ Upstream commit a935424bb658f9ca37eb5e94119b857998341356 ] Commit 10da65423fdb (PM / Domains: Call driver's noirq callbacks) started to respect driver's noirq callbacks, but while doing that it also introduced a few potential problems. More precisely, in genpd_finish_suspend() and genpd_resume_noirq() the noirq callbacks at the driver level should be invoked, no matter of whether dev->power.wakeup_path is set or not. Additionally, the commit in question also made genpd_resume_noirq() to ignore the return value from pm_runtime_force_resume(). Let's fix both these issues! Fixes: 10da65423fdb (PM / Domains: Call driver's noirq callbacks) Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/base/power/domain.c | 30 +++++++++++++++++------------- 1 file changed, 17 insertions(+), 13 deletions(-) --- a/drivers/base/power/domain.c +++ b/drivers/base/power/domain.c @@ -1032,15 +1032,12 @@ static int genpd_prepare(struct device * static int genpd_finish_suspend(struct device *dev, bool poweroff) { struct generic_pm_domain *genpd; - int ret; + int ret = 0; genpd = dev_to_genpd(dev); if (IS_ERR(genpd)) return -EINVAL; - if (dev->power.wakeup_path && genpd_is_active_wakeup(genpd)) - return 0; - if (poweroff) ret = pm_generic_poweroff_noirq(dev); else @@ -1048,10 +1045,18 @@ static int genpd_finish_suspend(struct d if (ret) return ret; + if (dev->power.wakeup_path && genpd_is_active_wakeup(genpd)) + return 0; + if (genpd->dev_ops.stop && genpd->dev_ops.start) { ret = pm_runtime_force_suspend(dev); - if (ret) + if (ret) { + if (poweroff) + pm_generic_restore_noirq(dev); + else + pm_generic_resume_noirq(dev); return ret; + } } genpd_lock(genpd); @@ -1085,7 +1090,7 @@ static int genpd_suspend_noirq(struct de static int genpd_resume_noirq(struct device *dev) { struct generic_pm_domain *genpd; - int ret = 0; + int ret; dev_dbg(dev, "%s()\n", __func__); @@ -1094,21 +1099,20 @@ static int genpd_resume_noirq(struct dev return -EINVAL; if (dev->power.wakeup_path && genpd_is_active_wakeup(genpd)) - return 0; + return pm_generic_resume_noirq(dev); genpd_lock(genpd); genpd_sync_power_on(genpd, true, 0); genpd->suspended_count--; genpd_unlock(genpd); - if (genpd->dev_ops.stop && genpd->dev_ops.start) + if (genpd->dev_ops.stop && genpd->dev_ops.start) { ret = pm_runtime_force_resume(dev); + if (ret) + return ret; + } - ret = pm_generic_resume_noirq(dev); - if (ret) - return ret; - - return ret; + return pm_generic_resume_noirq(dev); } /** Patches currently in stable-queue which might be from ulf.hansson(a)linaro.org are queue-4.15/pm-domains-don-t-skip-driver-s-suspend-resume_noirq-callbacks.patch queue-4.15/sdhci-advertise-2.0v-supply-on-sdio-host-controller.patch

7 years, 2 months

1
0
0 0

Patch "pinctrl: baytrail: Enable glitch filter for GPIOs used as interrupts" 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 pinctrl: baytrail: Enable glitch filter for GPIOs used as interrupts 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: pinctrl-baytrail-enable-glitch-filter-for-gpios-used-as-interrupts.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Hans de Goede <hdegoede(a)redhat.com> Date: Mon, 1 Jan 2018 13:23:57 +0100 Subject: pinctrl: baytrail: Enable glitch filter for GPIOs used as interrupts From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit 9291c65b01d1c67ebd56644cb19317ad665c44b3 ] On some systems, some PCB traces attached to GpioInts are routed in such a way that they pick up enough interference to constantly (many times per second) trigger. Enabling glitch-filtering fixes this. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Acked-by: Mika Westerberg <mika.westerberg(a)linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pinctrl/intel/pinctrl-baytrail.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/pinctrl/intel/pinctrl-baytrail.c +++ b/drivers/pinctrl/intel/pinctrl-baytrail.c @@ -46,6 +46,9 @@ #define BYT_TRIG_POS BIT(25) #define BYT_TRIG_LVL BIT(24) #define BYT_DEBOUNCE_EN BIT(20) +#define BYT_GLITCH_FILTER_EN BIT(19) +#define BYT_GLITCH_F_SLOW_CLK BIT(17) +#define BYT_GLITCH_F_FAST_CLK BIT(16) #define BYT_PULL_STR_SHIFT 9 #define BYT_PULL_STR_MASK (3 << BYT_PULL_STR_SHIFT) #define BYT_PULL_STR_2K (0 << BYT_PULL_STR_SHIFT) @@ -1579,6 +1582,9 @@ static int byt_irq_type(struct irq_data */ value &= ~(BYT_DIRECT_IRQ_EN | BYT_TRIG_POS | BYT_TRIG_NEG | BYT_TRIG_LVL); + /* Enable glitch filtering */ + value |= BYT_GLITCH_FILTER_EN | BYT_GLITCH_F_SLOW_CLK | + BYT_GLITCH_F_FAST_CLK; writel(value, reg); Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.15/serdev-fix-serdev_uevent-failure-on-acpi-enumerated-serdev-controllers.patch queue-4.15/acpi-video-default-lcd_only-to-true-on-win8-ready-and-newer-machines.patch queue-4.15/bluetooth-hci_bcm-mandate-presence-of-shutdown-and-device-wake-gpio.patch queue-4.15/input-goodix-disable-irqs-while-suspended.patch queue-4.15/asoc-intel-cht_bsw_rt5645-analog-mic-support.patch queue-4.15/power-supply-axp288_charger-properly-stop-work-on-probe-error-remove.patch queue-4.15/pinctrl-baytrail-enable-glitch-filter-for-gpios-used-as-interrupts.patch

7 years, 2 months

1
0
0 0

Patch "perf tools: Fix copyfile_offset update of output offset" 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 perf tools: Fix copyfile_offset update of output offset 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: perf-tools-fix-copyfile_offset-update-of-output-offset.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Jiri Olsa <jolsa(a)kernel.org> Date: Tue, 9 Jan 2018 14:39:23 +0100 Subject: perf tools: Fix copyfile_offset update of output offset From: Jiri Olsa <jolsa(a)kernel.org> [ Upstream commit fa1195ccc0af2d121abe0fe266a1caee8c265eea ] We need to increase output offset in each iteration, not decrease it as we currently do. I guess we were lucky to finish in most cases in first iteration, so the bug never showed. However it shows a lot when working with big (~4GB) size data. Signed-off-by: Jiri Olsa <jolsa(a)kernel.org> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Andi Kleen <ak(a)linux.intel.com> Cc: David Ahern <dsahern(a)gmail.com> Cc: Namhyung Kim <namhyung(a)kernel.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Fixes: 9c9f5a2f1944 ("perf tools: Introduce copyfile_offset() function") Link: http://lkml.kernel.org/r/20180109133923.25406-1-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/util/util.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/perf/util/util.c +++ b/tools/perf/util/util.c @@ -210,7 +210,7 @@ static int copyfile_offset(int ifd, loff size -= ret; off_in += ret; - off_out -= ret; + off_out += ret; } munmap(ptr, off_in + size); Patches currently in stable-queue which might be from jolsa(a)kernel.org are queue-4.15/perf-evsel-fix-swap-for-samples-with-raw-data.patch queue-4.15/perf-tools-fix-copyfile_offset-update-of-output-offset.patch queue-4.15/perf-report-fix-a-no-annotate-browser-displayed-issue.patch

7 years, 2 months

1
0
0 0

Patch "perf report: Fix a no annotate browser displayed issue" 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 perf report: Fix a no annotate browser displayed issue 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: perf-report-fix-a-no-annotate-browser-displayed-issue.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Jin Yao <yao.jin(a)linux.intel.com> Date: Tue, 26 Dec 2017 18:42:43 +0800 Subject: perf report: Fix a no annotate browser displayed issue From: Jin Yao <yao.jin(a)linux.intel.com> [ Upstream commit 40c39e3046411f84bab82f66783ff3593e2bcd9b ] When enabling '-b' option in perf record, for example, perf record -b ... perf report and then browsing the annotate browser from perf report (press 'A'), it would fail (annotate browser can't be displayed). It's because the '.add_entry_cb' op of struct report is overwritten by hist_iter__branch_callback() in builtin-report.c. But this function doesn't do something like mapping symbols and sources. So next, do_annotate() will return directly. notes = symbol__annotation(act->ms.sym); if (!notes->src) return 0; This patch adds the lost code to hist_iter__branch_callback (refer to hist_iter__report_callback). v2: Fix a crash bug when perform 'perf report --stdio'. The reason is that we init the symbol annotation only in browser mode, it doesn't allocate/init resources for stdio mode. So now in hist_iter__branch_callback(), it will return directly if it's not in browser mode. Signed-off-by: Jin Yao <yao.jin(a)linux.intel.com> Tested-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Andi Kleen <ak(a)linux.intel.com> Cc: Jiri Olsa <jolsa(a)kernel.org> Cc: Kan Liang <kan.liang(a)intel.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Link: http://lkml.kernel.org/r/1514284963-18587-1-git-send-email-yao.jin@linux.in… Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/builtin-report.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) --- a/tools/perf/builtin-report.c +++ b/tools/perf/builtin-report.c @@ -162,12 +162,28 @@ static int hist_iter__branch_callback(st struct hist_entry *he = iter->he; struct report *rep = arg; struct branch_info *bi; + struct perf_sample *sample = iter->sample; + struct perf_evsel *evsel = iter->evsel; + int err; + + if (!ui__has_annotation()) + return 0; + + hist__account_cycles(sample->branch_stack, al, sample, + rep->nonany_branch_mode); bi = he->branch_info; + err = addr_map_symbol__inc_samples(&bi->from, sample, evsel->idx); + if (err) + goto out; + + err = addr_map_symbol__inc_samples(&bi->to, sample, evsel->idx); + branch_type_count(&rep->brtype_stat, &bi->flags, bi->from.addr, bi->to.addr); - return 0; +out: + return err; } static int process_sample_event(struct perf_tool *tool, Patches currently in stable-queue which might be from yao.jin(a)linux.intel.com are queue-4.15/perf-report-fix-a-no-annotate-browser-displayed-issue.patch

7 years, 2 months

1
0
0 0

Patch "perf probe: Add warning message if there is unexpected event name" 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 perf probe: Add warning message if there is unexpected event name 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: perf-probe-add-warning-message-if-there-is-unexpected-event-name.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Masami Hiramatsu <mhiramat(a)kernel.org> Date: Sat, 9 Dec 2017 01:26:46 +0900 Subject: perf probe: Add warning message if there is unexpected event name From: Masami Hiramatsu <mhiramat(a)kernel.org> [ Upstream commit 9f5c6d8777a2d962b0eeacb2a16f37da6bea545b ] This improve the error message so that user can know event-name error before writing new events to kprobe-events interface. E.g. ====== #./perf probe -x /lib64/libc-2.25.so malloc_get_state* Internal error: "malloc_get_state@GLIBC_2" is an invalid event name. Error: Failed to add events. ====== Reported-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org> Acked-by: Ravi Bangoria <ravi.bangoria(a)linux.vnet.ibm.com> Reviewed-by: Thomas Richter <tmricht(a)linux.vnet.ibm.com> Tested-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Cc: Paul Clarke <pc(a)us.ibm.com> Cc: bhargavb <bhargavaramudu(a)gmail.com> Cc: linux-rt-users(a)vger.kernel.org Link: http://lkml.kernel.org/r/151275040665.24652.5188568529237584489.stgit@devbox Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/util/probe-event.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/tools/perf/util/probe-event.c +++ b/tools/perf/util/probe-event.c @@ -2625,6 +2625,14 @@ static int get_new_event_name(char *buf, out: free(nbase); + + /* Final validation */ + if (ret >= 0 && !is_c_func_name(buf)) { + pr_warning("Internal error: \"%s\" is an invalid event name.\n", + buf); + ret = -EINVAL; + } + return ret; } Patches currently in stable-queue which might be from mhiramat(a)kernel.org are queue-4.15/perf-probe-find-versioned-symbols-from-map.patch queue-4.15/perf-probe-add-warning-message-if-there-is-unexpected-event-name.patch

7 years, 2 months

1
0
0 0

Patch "perf probe: Find versioned symbols from map" 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 perf probe: Find versioned symbols from map 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: perf-probe-find-versioned-symbols-from-map.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Masami Hiramatsu <mhiramat(a)kernel.org> Date: Sat, 9 Dec 2017 01:28:12 +0900 Subject: perf probe: Find versioned symbols from map From: Masami Hiramatsu <mhiramat(a)kernel.org> [ Upstream commit 4b3a2716dd785fabb9f6ac80c1d53cb29a88169d ] Commit d80406453ad4 ("perf symbols: Allow user probes on versioned symbols") allows user to find default versioned symbols (with "@@") in map. However, it did not enable normal versioned symbol (with "@") for perf-probe. E.g. ===== # ./perf probe -x /lib64/libc-2.25.so malloc_get_state Failed to find symbol malloc_get_state in /usr/lib64/libc-2.25.so Error: Failed to add events. ===== This solves above issue by improving perf-probe symbol search function, as below. ===== # ./perf probe -x /lib64/libc-2.25.so malloc_get_state Added new event: probe_libc:malloc_get_state (on malloc_get_state in /usr/lib64/libc-2.25.so) You can now use it in all perf tools, such as: perf record -e probe_libc:malloc_get_state -aR sleep 1 # ./perf probe -l probe_libc:malloc_get_state (on malloc_get_state(a)GLIBC_2.2.5 in /usr/lib64/libc-2.25.so) ===== Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org> Reviewed-by: Thomas Richter <tmricht(a)linux.vnet.ibm.com> Acked-by: Ravi Bangoria <ravi.bangoria(a)linux.vnet.ibm.com> Tested-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Cc: Paul Clarke <pc(a)us.ibm.com> Cc: bhargavb <bhargavaramudu(a)gmail.com> Cc: linux-rt-users(a)vger.kernel.org Link: http://lkml.kernel.org/r/151275049269.24652.1639103455496216255.stgit@devbox Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/arch/powerpc/util/sym-handling.c | 8 ++++++++ tools/perf/util/probe-event.c | 20 ++++++++++++++++++-- tools/perf/util/symbol.c | 5 +++++ tools/perf/util/symbol.h | 1 + 4 files changed, 32 insertions(+), 2 deletions(-) --- a/tools/perf/arch/powerpc/util/sym-handling.c +++ b/tools/perf/arch/powerpc/util/sym-handling.c @@ -64,6 +64,14 @@ int arch__compare_symbol_names_n(const c return strncmp(namea, nameb, n); } + +const char *arch__normalize_symbol_name(const char *name) +{ + /* Skip over initial dot */ + if (name && *name == '.') + name++; + return name; +} #endif #if defined(_CALL_ELF) && _CALL_ELF == 2 --- a/tools/perf/util/probe-event.c +++ b/tools/perf/util/probe-event.c @@ -2792,16 +2792,32 @@ static int find_probe_functions(struct m int found = 0; struct symbol *sym; struct rb_node *tmp; + const char *norm, *ver; + char *buf = NULL; if (map__load(map) < 0) return 0; map__for_each_symbol(map, sym, tmp) { - if (strglobmatch(sym->name, name)) { + norm = arch__normalize_symbol_name(sym->name); + if (!norm) + continue; + + /* We don't care about default symbol or not */ + ver = strchr(norm, '@'); + if (ver) { + buf = strndup(norm, ver - norm); + if (!buf) + return -ENOMEM; + norm = buf; + } + if (strglobmatch(norm, name)) { found++; if (syms && found < probe_conf.max_probes) syms[found - 1] = sym; } + if (buf) + zfree(&buf); } return found; @@ -2847,7 +2863,7 @@ static int find_probe_trace_events_from_ * same name but different addresses, this lists all the symbols. */ num_matched_functions = find_probe_functions(map, pp->function, syms); - if (num_matched_functions == 0) { + if (num_matched_functions <= 0) { pr_err("Failed to find symbol %s in %s\n", pp->function, pev->target ? : "kernel"); ret = -ENOENT; --- a/tools/perf/util/symbol.c +++ b/tools/perf/util/symbol.c @@ -94,6 +94,11 @@ static int prefix_underscores_count(cons return tail - str; } +const char * __weak arch__normalize_symbol_name(const char *name) +{ + return name; +} + int __weak arch__compare_symbol_names(const char *namea, const char *nameb) { return strcmp(namea, nameb); --- a/tools/perf/util/symbol.h +++ b/tools/perf/util/symbol.h @@ -349,6 +349,7 @@ bool elf__needs_adjust_symbols(GElf_Ehdr void arch__sym_update(struct symbol *s, GElf_Sym *sym); #endif +const char *arch__normalize_symbol_name(const char *name); #define SYMBOL_A 0 #define SYMBOL_B 1 Patches currently in stable-queue which might be from mhiramat(a)kernel.org are queue-4.15/perf-probe-find-versioned-symbols-from-map.patch queue-4.15/perf-probe-add-warning-message-if-there-is-unexpected-event-name.patch

7 years, 2 months

1
0
0 0

Patch "perf evsel: Fix swap for samples with raw data" 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 perf evsel: Fix swap for samples with raw data 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: perf-evsel-fix-swap-for-samples-with-raw-data.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Jiri Olsa <jolsa(a)kernel.org> Date: Wed, 29 Nov 2017 19:43:46 +0100 Subject: perf evsel: Fix swap for samples with raw data From: Jiri Olsa <jolsa(a)kernel.org> [ Upstream commit f9d8adb345d7adbb2d3431eea73beb89c8d6d612 ] When we detect a different endianity we swap event before processing. It's tricky for samples because we have no idea what's inside. We treat it as an array of u64s, swap them and later on we swap back parts which are different. We mangle this way also the tracepoint raw data, which ends up in report showing wrong data: 1.95% comm=Q^B pid=29285 prio=16777216 target_cpu=000 1.67% comm=l^B pid=0 prio=16777216 target_cpu=000 Luckily the traceevent library handles the endianity by itself (thank you Steven!), so we can pass the RAW data directly in the other endianity. 2.51% comm=beah-rhts-task pid=1175 prio=120 target_cpu=002 2.23% comm=kworker/0:0 pid=11566 prio=120 target_cpu=000 The fix is basically to swap back the raw data if different endianity is detected. Signed-off-by: Jiri Olsa <jolsa(a)kernel.org> Cc: David Ahern <dsahern(a)gmail.com> Cc: Namhyung Kim <namhyung(a)kernel.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Steven Rostedt <rostedt(a)goodmis.org> Link: http://lkml.kernel.org/r/20171129184346.3656-1-jolsa@kernel.org [ Add util/memswap.c to python-ext-sources to link missing mem_bswap_64() ] Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/util/evsel.c | 20 +++++++++++++++++--- tools/perf/util/python-ext-sources | 1 + 2 files changed, 18 insertions(+), 3 deletions(-) --- a/tools/perf/util/evsel.c +++ b/tools/perf/util/evsel.c @@ -36,6 +36,7 @@ #include "debug.h" #include "trace-event.h" #include "stat.h" +#include "memswap.h" #include "util/parse-branch-options.h" #include "sane_ctype.h" @@ -2120,14 +2121,27 @@ int perf_evsel__parse_sample(struct perf if (type & PERF_SAMPLE_RAW) { OVERFLOW_CHECK_u64(array); u.val64 = *array; - if (WARN_ONCE(swapped, - "Endianness of raw data not corrected!\n")) { - /* undo swap of u64, then swap on individual u32s */ + + /* + * Undo swap of u64, then swap on individual u32s, + * get the size of the raw area and undo all of the + * swap. The pevent interface handles endianity by + * itself. + */ + if (swapped) { u.val64 = bswap_64(u.val64); u.val32[0] = bswap_32(u.val32[0]); u.val32[1] = bswap_32(u.val32[1]); } data->raw_size = u.val32[0]; + + /* + * The raw data is aligned on 64bits including the + * u32 size, so it's safe to use mem_bswap_64. + */ + if (swapped) + mem_bswap_64((void *) array, data->raw_size); + array = (void *)array + sizeof(u32); OVERFLOW_CHECK(array, data->raw_size, max_size); --- a/tools/perf/util/python-ext-sources +++ b/tools/perf/util/python-ext-sources @@ -10,6 +10,7 @@ util/ctype.c util/evlist.c util/evsel.c util/cpumap.c +util/memswap.c util/mmap.c util/namespaces.c ../lib/bitmap.c Patches currently in stable-queue which might be from jolsa(a)kernel.org are queue-4.15/perf-evsel-fix-swap-for-samples-with-raw-data.patch queue-4.15/perf-tools-fix-copyfile_offset-update-of-output-offset.patch queue-4.15/perf-report-fix-a-no-annotate-browser-displayed-issue.patch

7 years, 2 months

1
0
0 0

Patch "perf evsel: Enable ignore_missing_thread for pid option" 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 perf evsel: Enable ignore_missing_thread for pid option 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: perf-evsel-enable-ignore_missing_thread-for-pid-option.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Mengting Zhang <zhangmengting(a)huawei.com> Date: Wed, 13 Dec 2017 15:01:53 +0800 Subject: perf evsel: Enable ignore_missing_thread for pid option From: Mengting Zhang <zhangmengting(a)huawei.com> [ Upstream commit ca8000684ec4e66f965e1f9547a3c6cb834154ca ] While monitoring a multithread process with pid option, perf sometimes may return sys_perf_event_open failure with 3(No such process) if any of the process's threads die before we open the event. However, we want perf continue monitoring the remaining threads and do not exit with error. Here, the patch enables perf_evsel::ignore_missing_thread for -p option to ignore complete failure if any of threads die before we open the event. But it may still return sys_perf_event_open failure with 22(Invalid) if we monitors several event groups. sys_perf_event_open: pid 28960 cpu 40 group_fd 118202 flags 0x8 sys_perf_event_open: pid 28961 cpu 40 group_fd 118203 flags 0x8 WARNING: Ignored open failure for pid 28962 sys_perf_event_open: pid 28962 cpu 40 group_fd [118203] flags 0x8 sys_perf_event_open failed, error -22 That is because when we ignore a missing thread, we change the thread_idx without dealing with its fds, FD(evsel, cpu, thread). Then get_group_fd() may return a wrong group_fd for the next thread and sys_perf_event_open() return with 22. sys_perf_event_open(){ ... if (group_fd != -1) perf_fget_light()//to get corresponding group_leader by group_fd ... if (group_leader) if (group_leader->ctx->task != ctx->task)//should on the same task goto err_context ... } This patch also fixes this bug by introducing perf_evsel__remove_fd() and update_fds to allow removing fds for the missing thread. Changes since v1: - Change group_fd__remove() into a more genetic way without changing code logic - Remove redundant condition Changes since v2: - Use a proper function name and add some comment. - Multiline comment style fixes. Committer testing: Before this patch the recently added 'perf stat --per-thread' for system wide counting would race while enumerating all threads using /proc: [root@jouet ~]# perf stat --per-thread failed to parse CPUs map: No such file or directory Usage: perf stat [<options>] [<command>] -C, --cpu <cpu> list of cpus to monitor in system-wide -a, --all-cpus system-wide collection from all CPUs [root@jouet ~]# perf stat --per-thread failed to parse CPUs map: No such file or directory Usage: perf stat [<options>] [<command>] -C, --cpu <cpu> list of cpus to monitor in system-wide -a, --all-cpus system-wide collection from all CPUs [root@jouet ~]# When, say, the kernel was being built, so lots of shortlived threads, after this patch this doesn't happen. Signed-off-by: Mengting Zhang <zhangmengting(a)huawei.com> Tested-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Acked-by: Jiri Olsa <jolsa(a)redhat.com> Cc: Cheng Jian <cj.chengjian(a)huawei.com> Cc: Li Bin <huawei.libin(a)huawei.com> Cc: Wang Nan <wangnan0(a)huawei.com> Link: http://lkml.kernel.org/r/1513148513-6974-1-git-send-email-zhangmengting@hua… [ Remove one use 'evlist' alias variable ] Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/builtin-record.c | 4 +-- tools/perf/util/evsel.c | 47 ++++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 47 insertions(+), 4 deletions(-) --- a/tools/perf/builtin-record.c +++ b/tools/perf/builtin-record.c @@ -1781,8 +1781,8 @@ int cmd_record(int argc, const char **ar goto out; } - /* Enable ignoring missing threads when -u option is defined. */ - rec->opts.ignore_missing_thread = rec->opts.target.uid != UINT_MAX; + /* Enable ignoring missing threads when -u/-p option is defined. */ + rec->opts.ignore_missing_thread = rec->opts.target.uid != UINT_MAX || rec->opts.target.pid; err = -ENOMEM; if (perf_evlist__create_maps(rec->evlist, &rec->opts.target) < 0) --- a/tools/perf/util/evsel.c +++ b/tools/perf/util/evsel.c @@ -1597,10 +1597,46 @@ static int __open_attr__fprintf(FILE *fp return fprintf(fp, " %-32s %s\n", name, val); } +static void perf_evsel__remove_fd(struct perf_evsel *pos, + int nr_cpus, int nr_threads, + int thread_idx) +{ + for (int cpu = 0; cpu < nr_cpus; cpu++) + for (int thread = thread_idx; thread < nr_threads - 1; thread++) + FD(pos, cpu, thread) = FD(pos, cpu, thread + 1); +} + +static int update_fds(struct perf_evsel *evsel, + int nr_cpus, int cpu_idx, + int nr_threads, int thread_idx) +{ + struct perf_evsel *pos; + + if (cpu_idx >= nr_cpus || thread_idx >= nr_threads) + return -EINVAL; + + evlist__for_each_entry(evsel->evlist, pos) { + nr_cpus = pos != evsel ? nr_cpus : cpu_idx; + + perf_evsel__remove_fd(pos, nr_cpus, nr_threads, thread_idx); + + /* + * Since fds for next evsel has not been created, + * there is no need to iterate whole event list. + */ + if (pos == evsel) + break; + } + return 0; +} + static bool ignore_missing_thread(struct perf_evsel *evsel, + int nr_cpus, int cpu, struct thread_map *threads, int thread, int err) { + pid_t ignore_pid = thread_map__pid(threads, thread); + if (!evsel->ignore_missing_thread) return false; @@ -1616,11 +1652,18 @@ static bool ignore_missing_thread(struct if (threads->nr == 1) return false; + /* + * We should remove fd for missing_thread first + * because thread_map__remove() will decrease threads->nr. + */ + if (update_fds(evsel, nr_cpus, cpu, threads->nr, thread)) + return false; + if (thread_map__remove(threads, thread)) return false; pr_warning("WARNING: Ignored open failure for pid %d\n", - thread_map__pid(threads, thread)); + ignore_pid); return true; } @@ -1725,7 +1768,7 @@ retry_open: if (fd < 0) { err = -errno; - if (ignore_missing_thread(evsel, threads, thread, err)) { + if (ignore_missing_thread(evsel, cpus->nr, cpu, threads, thread, err)) { /* * We just removed 1 thread, so take a step * back on thread index and lower the upper Patches currently in stable-queue which might be from zhangmengting(a)huawei.com are queue-4.15/perf-evsel-enable-ignore_missing_thread-for-pid-option.patch

7 years, 2 months

1
0
0 0

Patch "nvme_fcloop: fix abort race condition" 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 nvme_fcloop: fix abort race condition 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: nvme_fcloop-fix-abort-race-condition.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: James Smart <jsmart2021(a)gmail.com> Date: Wed, 29 Nov 2017 16:47:30 -0800 Subject: nvme_fcloop: fix abort race condition From: James Smart <jsmart2021(a)gmail.com> [ Upstream commit 278e096063f1914fccfc77a617be9fc8dbb31b0e ] A test case revealed a race condition of an i/o completing on a thread parallel to the delete_association generating the aborts for the outstanding ios on the controller. The i/o completion was freeing the target fcloop context, thus the abort task referenced the just-freed memory. Correct by clearing the target/initiator cross pointers in the io completion and abort tasks before calling the callbacks. On aborts that detect already finished io's, ensure the complete context is called. Signed-off-by: James Smart <james.smart(a)broadcom.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/nvme/target/fcloop.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) --- a/drivers/nvme/target/fcloop.c +++ b/drivers/nvme/target/fcloop.c @@ -374,6 +374,7 @@ fcloop_tgt_fcprqst_done_work(struct work spin_lock(&tfcp_req->reqlock); fcpreq = tfcp_req->fcpreq; + tfcp_req->fcpreq = NULL; spin_unlock(&tfcp_req->reqlock); if (tport->remoteport && fcpreq) { @@ -615,11 +616,7 @@ fcloop_fcp_abort(struct nvme_fc_local_po if (!tfcp_req) /* abort has already been called */ - return; - - if (rport->targetport) - nvmet_fc_rcv_fcp_abort(rport->targetport, - &tfcp_req->tgt_fcp_req); + goto finish; /* break initiator/target relationship for io */ spin_lock(&tfcp_req->reqlock); @@ -627,6 +624,11 @@ fcloop_fcp_abort(struct nvme_fc_local_po tfcp_req->fcpreq = NULL; spin_unlock(&tfcp_req->reqlock); + if (rport->targetport) + nvmet_fc_rcv_fcp_abort(rport->targetport, + &tfcp_req->tgt_fcp_req); + +finish: /* post the aborted io completion */ fcpreq->status = -ECANCELED; schedule_work(&inireq->iniwork); Patches currently in stable-queue which might be from jsmart2021(a)gmail.com are queue-4.15/nvme_fcloop-fix-abort-race-condition.patch queue-4.15/nvme_fcloop-disassocate-local-port-structs.patch

7 years, 2 months

1
0
0 0

Patch "nvme_fcloop: disassocate local port structs" 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 nvme_fcloop: disassocate local port structs 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: nvme_fcloop-disassocate-local-port-structs.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: James Smart <jsmart2021(a)gmail.com> Date: Wed, 29 Nov 2017 16:47:31 -0800 Subject: nvme_fcloop: disassocate local port structs From: James Smart <jsmart2021(a)gmail.com> [ Upstream commit 6fda20283e55b9d288cd56822ce39fc8e64f2208 ] The current fcloop driver gets its lport structure from the private area co-allocated with the fc_localport. All is fine except the teardown path, which wants to wait on the completion, which is marked complete by the delete_localport callback performed after unregister_localport. The issue is, the nvme_fc transport frees the localport structure immediately after delete_localport is called, meaning the original routine is trying to wait on a complete that was just freed. Change such that a lport struct is allocated coincident with the addition and registration of a localport. The private area of the localport now contains just a backpointer to the real lport struct. Now, the completion can be waited for, and after completing, the new structure can be kfree'd. Signed-off-by: James Smart <james.smart(a)broadcom.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/nvme/target/fcloop.c | 35 +++++++++++++++++++++++++---------- 1 file changed, 25 insertions(+), 10 deletions(-) --- a/drivers/nvme/target/fcloop.c +++ b/drivers/nvme/target/fcloop.c @@ -204,6 +204,10 @@ struct fcloop_lport { struct completion unreg_done; }; +struct fcloop_lport_priv { + struct fcloop_lport *lport; +}; + struct fcloop_rport { struct nvme_fc_remote_port *remoteport; struct nvmet_fc_target_port *targetport; @@ -657,7 +661,8 @@ fcloop_nport_get(struct fcloop_nport *np static void fcloop_localport_delete(struct nvme_fc_local_port *localport) { - struct fcloop_lport *lport = localport->private; + struct fcloop_lport_priv *lport_priv = localport->private; + struct fcloop_lport *lport = lport_priv->lport; /* release any threads waiting for the unreg to complete */ complete(&lport->unreg_done); @@ -697,7 +702,7 @@ static struct nvme_fc_port_template fcte .max_dif_sgl_segments = FCLOOP_SGL_SEGS, .dma_boundary = FCLOOP_DMABOUND_4G, /* sizes of additional private data for data structures */ - .local_priv_sz = sizeof(struct fcloop_lport), + .local_priv_sz = sizeof(struct fcloop_lport_priv), .remote_priv_sz = sizeof(struct fcloop_rport), .lsrqst_priv_sz = sizeof(struct fcloop_lsreq), .fcprqst_priv_sz = sizeof(struct fcloop_ini_fcpreq), @@ -728,11 +733,17 @@ fcloop_create_local_port(struct device * struct fcloop_ctrl_options *opts; struct nvme_fc_local_port *localport; struct fcloop_lport *lport; - int ret; + struct fcloop_lport_priv *lport_priv; + unsigned long flags; + int ret = -ENOMEM; + + lport = kzalloc(sizeof(*lport), GFP_KERNEL); + if (!lport) + return -ENOMEM; opts = kzalloc(sizeof(*opts), GFP_KERNEL); if (!opts) - return -ENOMEM; + goto out_free_lport; ret = fcloop_parse_options(opts, buf); if (ret) @@ -752,23 +763,25 @@ fcloop_create_local_port(struct device * ret = nvme_fc_register_localport(&pinfo, &fctemplate, NULL, &localport); if (!ret) { - unsigned long flags; - /* success */ - lport = localport->private; + lport_priv = localport->private; + lport_priv->lport = lport; + lport->localport = localport; INIT_LIST_HEAD(&lport->lport_list); spin_lock_irqsave(&fcloop_lock, flags); list_add_tail(&lport->lport_list, &fcloop_lports); spin_unlock_irqrestore(&fcloop_lock, flags); - - /* mark all of the input buffer consumed */ - ret = count; } out_free_opts: kfree(opts); +out_free_lport: + /* free only if we're going to fail */ + if (ret) + kfree(lport); + return ret ? ret : count; } @@ -790,6 +803,8 @@ __wait_localport_unreg(struct fcloop_lpo wait_for_completion(&lport->unreg_done); + kfree(lport); + return ret; } Patches currently in stable-queue which might be from jsmart2021(a)gmail.com are queue-4.15/nvme_fcloop-fix-abort-race-condition.patch queue-4.15/nvme_fcloop-disassocate-local-port-structs.patch

7 years, 2 months

1
0
0 0

Patch "net_sch: red: Fix the new offload indication" 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 net_sch: red: Fix the new offload indication 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: net_sch-red-fix-the-new-offload-indication.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Nogah Frankel <nogahf(a)mellanox.com> Date: Mon, 25 Dec 2017 10:51:41 +0200 Subject: net_sch: red: Fix the new offload indication From: Nogah Frankel <nogahf(a)mellanox.com> [ Upstream commit 8234af2db3614d78b49e77ef46ea8cfab6586568 ] Update the offload flag, TCQ_F_OFFLOADED, in each dump call (and ignore the offloading function return value in relation to this flag). This is done because a qdisc is being initialized, and therefore offloaded before being grafted. Since the ability of the driver to offload the qdisc depends on its location, a qdisc can be offloaded and un-offloaded by graft calls, that doesn't effect the qdisc itself. Fixes: 428a68af3a7c ("net: sched: Move to new offload indication in RED" Signed-off-by: Nogah Frankel <nogahf(a)mellanox.com> Reviewed-by: Yuval Mintz <yuvalm(a)mellanox.com> Acked-by: Jiri Pirko <jiri(a)mellanox.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/sched/sch_red.c | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-) --- a/net/sched/sch_red.c +++ b/net/sched/sch_red.c @@ -157,7 +157,6 @@ static int red_offload(struct Qdisc *sch .handle = sch->handle, .parent = sch->parent, }; - int err; if (!tc_can_offload(dev) || !dev->netdev_ops->ndo_setup_tc) return -EOPNOTSUPP; @@ -172,14 +171,7 @@ static int red_offload(struct Qdisc *sch opt.command = TC_RED_DESTROY; } - err = dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_QDISC_RED, &opt); - - if (!err && enable) - sch->flags |= TCQ_F_OFFLOADED; - else - sch->flags &= ~TCQ_F_OFFLOADED; - - return err; + return dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_QDISC_RED, &opt); } static void red_destroy(struct Qdisc *sch) @@ -294,12 +286,22 @@ static int red_dump_offload_stats(struct .stats.qstats = &sch->qstats, }, }; + int err; + + sch->flags &= ~TCQ_F_OFFLOADED; - if (!(sch->flags & TCQ_F_OFFLOADED)) + if (!tc_can_offload(dev) || !dev->netdev_ops->ndo_setup_tc) + return 0; + + err = dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_QDISC_RED, + &hw_stats); + if (err == -EOPNOTSUPP) return 0; - return dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_QDISC_RED, - &hw_stats); + if (!err) + sch->flags |= TCQ_F_OFFLOADED; + + return err; } static int red_dump(struct Qdisc *sch, struct sk_buff *skb) Patches currently in stable-queue which might be from nogahf(a)mellanox.com are queue-4.15/net_sch-red-fix-the-new-offload-indication.patch

7 years, 2 months

1
0
0 0

Patch "net/mlx5e: IPoIB, Use correct timestamp in child receive flow" 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 net/mlx5e: IPoIB, Use correct timestamp in child receive flow 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: net-mlx5e-ipoib-use-correct-timestamp-in-child-receive-flow.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Feras Daoud <ferasda(a)mellanox.com> Date: Tue, 31 Oct 2017 14:57:27 +0200 Subject: net/mlx5e: IPoIB, Use correct timestamp in child receive flow From: Feras Daoud <ferasda(a)mellanox.com> [ Upstream commit 36e564b76f1862914ad32c35bab433e07da2ebf8 ] The current implementation takes the child timestamp object from the parent since the rq in mlx5i_complete_rx_cqe belongs to the parent. This change fixes the issue by taking the correct timestamp. Fixes: 7e7f4780c340 ("net/mlx5e: IPoIB, Use hash-table to map between QPN to child netdev") Signed-off-by: Feras Daoud <ferasda(a)mellanox.com> Signed-off-by: Saeed Mahameed <saeedm(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c @@ -1196,7 +1196,9 @@ static inline void mlx5i_complete_rx_cqe u32 cqe_bcnt, struct sk_buff *skb) { + struct hwtstamp_config *tstamp; struct net_device *netdev; + struct mlx5e_priv *priv; char *pseudo_header; u32 qpn; u8 *dgid; @@ -1215,6 +1217,9 @@ static inline void mlx5i_complete_rx_cqe return; } + priv = mlx5i_epriv(netdev); + tstamp = &priv->tstamp; + g = (be32_to_cpu(cqe->flags_rqpn) >> 28) & 3; dgid = skb->data + MLX5_IB_GRH_DGID_OFFSET; if ((!g) || dgid[0] != 0xff) @@ -1235,7 +1240,7 @@ static inline void mlx5i_complete_rx_cqe skb->ip_summed = CHECKSUM_COMPLETE; skb->csum = csum_unfold((__force __sum16)cqe->check_sum); - if (unlikely(mlx5e_rx_hw_stamp(rq->tstamp))) + if (unlikely(mlx5e_rx_hw_stamp(tstamp))) skb_hwtstamps(skb)->hwtstamp = mlx5_timecounter_cyc2time(rq->clock, get_cqe_ts(cqe)); Patches currently in stable-queue which might be from ferasda(a)mellanox.com are queue-4.15/net-mlx5e-ipoib-use-correct-timestamp-in-child-receive-flow.patch

7 years, 2 months

1
0
0 0

Patch "net/mlx5: Fix race for multiple RoCE enable" 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 net/mlx5: Fix race for multiple RoCE enable 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: net-mlx5-fix-race-for-multiple-roce-enable.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Daniel Jurgens <danielj(a)mellanox.com> Date: Thu, 4 Jan 2018 17:25:31 +0200 Subject: net/mlx5: Fix race for multiple RoCE enable From: Daniel Jurgens <danielj(a)mellanox.com> [ Upstream commit 734dc065fc41f6143ff88225aa5d335cb1e0f6aa ] There are two potential problems with the existing implementation. 1. Enable and disable can race after the atomic operations. 2. If a command fails the refcount is left in an inconsistent state. Introduce a lock and perform error checking. Fixes: a6f7d2aff623 ("net/mlx5: Add support for multiple RoCE enable") Signed-off-by: Daniel Jurgens <danielj(a)mellanox.com> Reviewed-by: Parav Pandit <parav(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/mellanox/mlx5/core/vport.c | 33 +++++++++++++++++++----- include/linux/mlx5/driver.h | 2 - 2 files changed, 28 insertions(+), 7 deletions(-) --- a/drivers/net/ethernet/mellanox/mlx5/core/vport.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/vport.c @@ -36,6 +36,9 @@ #include <linux/mlx5/vport.h> #include "mlx5_core.h" +/* Mutex to hold while enabling or disabling RoCE */ +static DEFINE_MUTEX(mlx5_roce_en_lock); + static int _mlx5_query_vport_state(struct mlx5_core_dev *mdev, u8 opmod, u16 vport, u32 *out, int outlen) { @@ -998,17 +1001,35 @@ static int mlx5_nic_vport_update_roce_st int mlx5_nic_vport_enable_roce(struct mlx5_core_dev *mdev) { - if (atomic_inc_return(&mdev->roce.roce_en) != 1) - return 0; - return mlx5_nic_vport_update_roce_state(mdev, MLX5_VPORT_ROCE_ENABLED); + int err = 0; + + mutex_lock(&mlx5_roce_en_lock); + if (!mdev->roce.roce_en) + err = mlx5_nic_vport_update_roce_state(mdev, MLX5_VPORT_ROCE_ENABLED); + + if (!err) + mdev->roce.roce_en++; + mutex_unlock(&mlx5_roce_en_lock); + + return err; } EXPORT_SYMBOL_GPL(mlx5_nic_vport_enable_roce); int mlx5_nic_vport_disable_roce(struct mlx5_core_dev *mdev) { - if (atomic_dec_return(&mdev->roce.roce_en) != 0) - return 0; - return mlx5_nic_vport_update_roce_state(mdev, MLX5_VPORT_ROCE_DISABLED); + int err = 0; + + mutex_lock(&mlx5_roce_en_lock); + if (mdev->roce.roce_en) { + mdev->roce.roce_en--; + if (mdev->roce.roce_en == 0) + err = mlx5_nic_vport_update_roce_state(mdev, MLX5_VPORT_ROCE_DISABLED); + + if (err) + mdev->roce.roce_en++; + } + mutex_unlock(&mlx5_roce_en_lock); + return err; } EXPORT_SYMBOL_GPL(mlx5_nic_vport_disable_roce); --- a/include/linux/mlx5/driver.h +++ b/include/linux/mlx5/driver.h @@ -826,7 +826,7 @@ struct mlx5_core_dev { struct mlx5e_resources mlx5e_res; struct { struct mlx5_rsvd_gids reserved_gids; - atomic_t roce_en; + u32 roce_en; } roce; #ifdef CONFIG_MLX5_FPGA struct mlx5_fpga_device *fpga; Patches currently in stable-queue which might be from danielj(a)mellanox.com are queue-4.15/net-mlx5-fix-race-for-multiple-roce-enable.patch

7 years, 2 months

1
0
0 0

Patch "net/mlx4_en: Change default QoS settings" 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 net/mlx4_en: Change default QoS settings 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: net-mlx4_en-change-default-qos-settings.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Moni Shoua <monis(a)mellanox.com> Date: Thu, 28 Dec 2017 16:26:11 +0200 Subject: net/mlx4_en: Change default QoS settings From: Moni Shoua <monis(a)mellanox.com> [ Upstream commit a42b63c1ac1986f17f71bc91a6b0aaa14d4dae71 ] Change the default mapping between TC and TCG as follows: Prio | TC/TCG | from to | (set by FW) (set by SW) ---------+----------------------------------- 0 | 0/0 0/7 1 | 1/0 0/6 2 | 2/0 0/5 3 | 3/0 0/4 4 | 4/0 0/3 5 | 5/0 0/2 6 | 6/0 0/1 7 | 7/0 0/0 These new settings cause that a pause frame for any prio stops traffic for all prios. Fixes: 564c274c3df0 ("net/mlx4_en: DCB QoS support") Signed-off-by: Moni Shoua <monis(a)mellanox.com> Signed-off-by: Maor Gottlieb <maorg(a)mellanox.com> Signed-off-by: Tariq Toukan <tariqt(a)mellanox.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c | 5 +++++ drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 7 +++++++ drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 + 3 files changed, 13 insertions(+) --- a/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c +++ b/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c @@ -310,6 +310,7 @@ static int mlx4_en_ets_validate(struct m } switch (ets->tc_tsa[i]) { + case IEEE_8021QAZ_TSA_VENDOR: case IEEE_8021QAZ_TSA_STRICT: break; case IEEE_8021QAZ_TSA_ETS: @@ -347,6 +348,10 @@ static int mlx4_en_config_port_scheduler /* higher TC means higher priority => lower pg */ for (i = IEEE_8021QAZ_MAX_TCS - 1; i >= 0; i--) { switch (ets->tc_tsa[i]) { + case IEEE_8021QAZ_TSA_VENDOR: + pg[i] = MLX4_EN_TC_VENDOR; + tc_tx_bw[i] = MLX4_EN_BW_MAX; + break; case IEEE_8021QAZ_TSA_STRICT: pg[i] = num_strict++; tc_tx_bw[i] = MLX4_EN_BW_MAX; --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c @@ -3336,6 +3336,13 @@ int mlx4_en_init_netdev(struct mlx4_en_d priv->msg_enable = MLX4_EN_MSG_LEVEL; #ifdef CONFIG_MLX4_EN_DCB if (!mlx4_is_slave(priv->mdev->dev)) { + u8 prio; + + for (prio = 0; prio < IEEE_8021QAZ_MAX_TCS; ++prio) { + priv->ets.prio_tc[prio] = prio; + priv->ets.tc_tsa[prio] = IEEE_8021QAZ_TSA_VENDOR; + } + priv->dcbx_cap = DCB_CAP_DCBX_VER_CEE | DCB_CAP_DCBX_HOST | DCB_CAP_DCBX_VER_IEEE; priv->flags |= MLX4_EN_DCB_ENABLED; --- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h +++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h @@ -479,6 +479,7 @@ struct mlx4_en_frag_info { #define MLX4_EN_BW_MIN 1 #define MLX4_EN_BW_MAX 100 /* Utilize 100% of the line */ +#define MLX4_EN_TC_VENDOR 0 #define MLX4_EN_TC_ETS 7 enum dcb_pfc_type { Patches currently in stable-queue which might be from monis(a)mellanox.com are queue-4.15/net-mlx4_en-change-default-qos-settings.patch

7 years, 2 months

1
0
0 0

Patch "net: hns3: fix for changing MTU" 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 net: hns3: fix for changing MTU 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: net-hns3-fix-for-changing-mtu.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Fuyun Liang <liangfuyun1(a)huawei.com> Date: Fri, 5 Jan 2018 18:18:20 +0800 Subject: net: hns3: fix for changing MTU From: Fuyun Liang <liangfuyun1(a)huawei.com> [ Upstream commit 5bad95a1e55f4d5bb41e130db859d57eaf1b1549 ] when changing MTU, The new MTU must need to be set to netdevice. Fixes: a8e8b7ff3517 ("net: hns3: Add support to change MTU in HNS3 hardware") Signed-off-by: Fuyun Liang <liangfuyun1(a)huawei.com> Signed-off-by: Peng Li <lipeng321(a)huawei.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c @@ -1324,6 +1324,8 @@ static int hns3_nic_change_mtu(struct ne return ret; } + netdev->mtu = new_mtu; + /* if the netdev was running earlier, bring it up again */ if (if_running && hns3_nic_net_open(netdev)) ret = -EINVAL; Patches currently in stable-queue which might be from liangfuyun1(a)huawei.com are queue-4.15/net-hns3-fix-for-getting-auto-negotiation-state-in-hclge_get_autoneg.patch queue-4.15/net-hns3-add-asym-pause-support-to-phy-default-features.patch queue-4.15/net-hns3-fix-for-changing-mtu.patch

7 years, 2 months

1
0
0 0

Patch "net: hns3: fix for getting auto-negotiation state in hclge_get_autoneg" 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 net: hns3: fix for getting auto-negotiation state in hclge_get_autoneg 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: net-hns3-fix-for-getting-auto-negotiation-state-in-hclge_get_autoneg.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Fuyun Liang <liangfuyun1(a)huawei.com> Date: Fri, 22 Dec 2017 12:21:50 +0800 Subject: net: hns3: fix for getting auto-negotiation state in hclge_get_autoneg From: Fuyun Liang <liangfuyun1(a)huawei.com> [ Upstream commit 27b5bf49f0924fd62d2b1ef8467b40773973da34 ] When phy exists, we use the value of phydev.autoneg to represent the auto-negotiation state of hardware. Otherwise, we use the value of mac.autoneg to represent it. This patch fixes for getting a error value of auto-negotiation state in hclge_get_autoneg(). Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by: Fuyun Liang <liangfuyun1(a)huawei.com> Signed-off-by: Peng Li <lipeng321(a)huawei.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c @@ -2189,6 +2189,10 @@ static int hclge_get_autoneg(struct hnae { struct hclge_vport *vport = hclge_get_vport(handle); struct hclge_dev *hdev = vport->back; + struct phy_device *phydev = hdev->hw.mac.phydev; + + if (phydev) + return phydev->autoneg; hclge_query_autoneg_result(hdev); Patches currently in stable-queue which might be from liangfuyun1(a)huawei.com are queue-4.15/net-hns3-fix-for-getting-auto-negotiation-state-in-hclge_get_autoneg.patch queue-4.15/net-hns3-add-asym-pause-support-to-phy-default-features.patch queue-4.15/net-hns3-fix-for-changing-mtu.patch

7 years, 2 months

1
0
0 0

Patch "net: hns3: free the ring_data structrue when change tqps" 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 net: hns3: free the ring_data structrue when change tqps 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: net-hns3-free-the-ring_data-structrue-when-change-tqps.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Peng Li <lipeng321(a)huawei.com> Date: Fri, 22 Dec 2017 12:21:43 +0800 Subject: net: hns3: free the ring_data structrue when change tqps From: Peng Li <lipeng321(a)huawei.com> [ Upstream commit 99fdf6b1cadf41bb253408589788f025027274f3 ] This patch fixes a memory leak problems in change tqps process, the function hns3_uninit_all_ring and hns3_init_all_ring may be called many times. Signed-off-by: Peng Li <lipeng321(a)huawei.com> Signed-off-by: Mingguang Qu <qumingguang(a)huawei.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c @@ -2785,8 +2785,12 @@ int hns3_uninit_all_ring(struct hns3_nic h->ae_algo->ops->reset_queue(h, i); hns3_fini_ring(priv->ring_data[i].ring); + devm_kfree(priv->dev, priv->ring_data[i].ring); hns3_fini_ring(priv->ring_data[i + h->kinfo.num_tqps].ring); + devm_kfree(priv->dev, + priv->ring_data[i + h->kinfo.num_tqps].ring); } + devm_kfree(priv->dev, priv->ring_data); return 0; } Patches currently in stable-queue which might be from lipeng321(a)huawei.com are queue-4.15/net-hns3-fix-for-getting-auto-negotiation-state-in-hclge_get_autoneg.patch queue-4.15/net-hns3-free-the-ring_data-structrue-when-change-tqps.patch queue-4.15/net-hns3-fix-a-loop-index-error-of-tqp-statistics-query.patch queue-4.15/net-hns3-fix-an-error-macro-definition-of-hns3_tqp_stat.patch queue-4.15/net-hns3-add-asym-pause-support-to-phy-default-features.patch queue-4.15/net-hns3-fix-an-error-of-total-drop-packet-statistics.patch queue-4.15/net-hns3-fix-for-changing-mtu.patch

7 years, 2 months

1
0
0 0

Patch "net: hns3: Fix an error of total drop packet statistics" 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 net: hns3: Fix an error of total drop packet statistics 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: net-hns3-fix-an-error-of-total-drop-packet-statistics.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Jian Shen <shenjian15(a)huawei.com> Date: Fri, 5 Jan 2018 18:18:12 +0800 Subject: net: hns3: Fix an error of total drop packet statistics From: Jian Shen <shenjian15(a)huawei.com> [ Upstream commit d2a5dca8404871be683c6bbc175ebf9c56dd2865 ] The dropped tx/rx packets number of each tqp should also be counted into the total drop tx/rx packets numbers. Fixes: 76ad4f0ee74 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC") Signed-off-by: Jian Shen <shenjian15(a)huawei.com> Signed-off-by: Peng Li <lipeng321(a)huawei.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c @@ -1055,6 +1055,8 @@ hns3_nic_get_stats64(struct net_device * u64 rx_bytes = 0; u64 tx_pkts = 0; u64 rx_pkts = 0; + u64 tx_drop = 0; + u64 rx_drop = 0; for (idx = 0; idx < queue_num; idx++) { /* fetch the tx stats */ @@ -1063,6 +1065,8 @@ hns3_nic_get_stats64(struct net_device * start = u64_stats_fetch_begin_irq(&ring->syncp); tx_bytes += ring->stats.tx_bytes; tx_pkts += ring->stats.tx_pkts; + tx_drop += ring->stats.tx_busy; + tx_drop += ring->stats.sw_err_cnt; } while (u64_stats_fetch_retry_irq(&ring->syncp, start)); /* fetch the rx stats */ @@ -1071,6 +1075,9 @@ hns3_nic_get_stats64(struct net_device * start = u64_stats_fetch_begin_irq(&ring->syncp); rx_bytes += ring->stats.rx_bytes; rx_pkts += ring->stats.rx_pkts; + rx_drop += ring->stats.non_vld_descs; + rx_drop += ring->stats.err_pkt_len; + rx_drop += ring->stats.l2_err; } while (u64_stats_fetch_retry_irq(&ring->syncp, start)); } @@ -1086,8 +1093,8 @@ hns3_nic_get_stats64(struct net_device * stats->rx_missed_errors = netdev->stats.rx_missed_errors; stats->tx_errors = netdev->stats.tx_errors; - stats->rx_dropped = netdev->stats.rx_dropped; - stats->tx_dropped = netdev->stats.tx_dropped; + stats->rx_dropped = rx_drop + netdev->stats.rx_dropped; + stats->tx_dropped = tx_drop + netdev->stats.tx_dropped; stats->collisions = netdev->stats.collisions; stats->rx_over_errors = netdev->stats.rx_over_errors; stats->rx_frame_errors = netdev->stats.rx_frame_errors; Patches currently in stable-queue which might be from shenjian15(a)huawei.com are queue-4.15/net-hns3-fix-a-loop-index-error-of-tqp-statistics-query.patch queue-4.15/net-hns3-fix-an-error-macro-definition-of-hns3_tqp_stat.patch queue-4.15/net-hns3-fix-an-error-of-total-drop-packet-statistics.patch

7 years, 2 months

1
0
0 0

Patch "net: hns3: Fix an error macro definition of HNS3_TQP_STAT" 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 net: hns3: Fix an error macro definition of HNS3_TQP_STAT 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: net-hns3-fix-an-error-macro-definition-of-hns3_tqp_stat.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Jian Shen <shenjian15(a)huawei.com> Date: Fri, 5 Jan 2018 18:18:14 +0800 Subject: net: hns3: Fix an error macro definition of HNS3_TQP_STAT From: Jian Shen <shenjian15(a)huawei.com> [ Upstream commit 57ffee737b36dbb81e8e60a37e01791553157a5e ] The member "stats_offset" was designed to indicate the offset of each member of struct ring_stats in struct hns3_enet_ring, but forgot to add the offset of the member in struct ring_stats. Fixes: 496d03e960a ("net: hns3: Add Ethtool support to HNS3 driver") Signed-off-by: Jian Shen <shenjian15(a)huawei.com> Signed-off-by: Peng Li <lipeng321(a)huawei.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c @@ -23,7 +23,8 @@ struct hns3_stats { #define HNS3_TQP_STAT(_string, _member) { \ .stats_string = _string, \ .stats_size = FIELD_SIZEOF(struct ring_stats, _member), \ - .stats_offset = offsetof(struct hns3_enet_ring, stats), \ + .stats_offset = offsetof(struct hns3_enet_ring, stats) +\ + offsetof(struct ring_stats, _member), \ } \ static const struct hns3_stats hns3_txq_stats[] = { Patches currently in stable-queue which might be from shenjian15(a)huawei.com are queue-4.15/net-hns3-fix-a-loop-index-error-of-tqp-statistics-query.patch queue-4.15/net-hns3-fix-an-error-macro-definition-of-hns3_tqp_stat.patch queue-4.15/net-hns3-fix-an-error-of-total-drop-packet-statistics.patch

7 years, 2 months

1
0
0 0

Patch "net: hns3: Fix a loop index error of tqp statistics query" 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 net: hns3: Fix a loop index error of tqp statistics query 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: net-hns3-fix-a-loop-index-error-of-tqp-statistics-query.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Jian Shen <shenjian15(a)huawei.com> Date: Fri, 5 Jan 2018 18:18:13 +0800 Subject: net: hns3: Fix a loop index error of tqp statistics query From: Jian Shen <shenjian15(a)huawei.com> [ Upstream commit 94bfaafac9d2a3c0bcca00d01e38f7597b741799 ] An error loop index was used while querying statistics data of tqps, which may cause call trace. Fixes: 496d03e960ae ("net: hns3: Add Ethtool support to HNS3 driver") Signed-off-by: Jian Shen <shenjian15(a)huawei.com> Signed-off-by: Peng Li <lipeng321(a)huawei.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c @@ -455,13 +455,13 @@ static u64 *hns3_get_stats_tqps(struct h struct hnae3_knic_private_info *kinfo = &handle->kinfo; struct hns3_enet_ring *ring; u8 *stat; - u32 i; + int i, j; /* get stats for Tx */ for (i = 0; i < kinfo->num_tqps; i++) { ring = nic_priv->ring_data[i].ring; - for (i = 0; i < HNS3_TXQ_STATS_COUNT; i++) { - stat = (u8 *)ring + hns3_txq_stats[i].stats_offset; + for (j = 0; j < HNS3_TXQ_STATS_COUNT; j++) { + stat = (u8 *)ring + hns3_txq_stats[j].stats_offset; *data++ = *(u64 *)stat; } } @@ -469,8 +469,8 @@ static u64 *hns3_get_stats_tqps(struct h /* get stats for Rx */ for (i = 0; i < kinfo->num_tqps; i++) { ring = nic_priv->ring_data[i + kinfo->num_tqps].ring; - for (i = 0; i < HNS3_RXQ_STATS_COUNT; i++) { - stat = (u8 *)ring + hns3_rxq_stats[i].stats_offset; + for (j = 0; j < HNS3_RXQ_STATS_COUNT; j++) { + stat = (u8 *)ring + hns3_rxq_stats[j].stats_offset; *data++ = *(u64 *)stat; } } Patches currently in stable-queue which might be from shenjian15(a)huawei.com are queue-4.15/net-hns3-fix-a-loop-index-error-of-tqp-statistics-query.patch queue-4.15/net-hns3-fix-an-error-macro-definition-of-hns3_tqp_stat.patch queue-4.15/net-hns3-fix-an-error-of-total-drop-packet-statistics.patch

7 years, 2 months

1
0
0 0

Patch "net: Fix netdev_WARN_ONCE macro" 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 net: Fix netdev_WARN_ONCE macro 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: net-fix-netdev_warn_once-macro.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Gal Pressman <galp(a)mellanox.com> Date: Sun, 7 Jan 2018 12:08:35 +0200 Subject: net: Fix netdev_WARN_ONCE macro From: Gal Pressman <galp(a)mellanox.com> [ Upstream commit 72dd831e24cc9487a9cd534fdd675fe97e3c1839 ] netdev_WARN_ONCE is broken (whoops..), this fix will remove the unnecessary "condition" parameter, add the missing comma and change "arg" to "args". Fixes: 375ef2b1f0d0 ("net: Introduce netdev_*_once functions") Signed-off-by: Gal Pressman <galp(a)mellanox.com> Reviewed-by: Saeed Mahameed <saeedm(a)mellanox.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/netdevice.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -4402,8 +4402,8 @@ do { \ WARN(1, "netdevice: %s%s\n" format, netdev_name(dev), \ netdev_reg_state(dev), ##args) -#define netdev_WARN_ONCE(dev, condition, format, arg...) \ - WARN_ONCE(1, "netdevice: %s%s\n" format, netdev_name(dev) \ +#define netdev_WARN_ONCE(dev, format, args...) \ + WARN_ONCE(1, "netdevice: %s%s\n" format, netdev_name(dev), \ netdev_reg_state(dev), ##args) /* netif printk helpers, similar to netdev_printk */ Patches currently in stable-queue which might be from galp(a)mellanox.com are queue-4.15/net-fix-netdev_warn_once-macro.patch

7 years, 2 months

1
0
0 0

Patch "net: hns3: add Asym Pause support to phy default features" 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 net: hns3: add Asym Pause support to phy default features 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: net-hns3-add-asym-pause-support-to-phy-default-features.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Fuyun Liang <liangfuyun1(a)huawei.com> Date: Fri, 22 Dec 2017 12:21:53 +0800 Subject: net: hns3: add Asym Pause support to phy default features From: Fuyun Liang <liangfuyun1(a)huawei.com> [ Upstream commit f16121c80c8ee4dab3c41363cb8b24f8d8eaf45f ] commit c4fb2cdf575d ("net: hns3: fix a bug for phy supported feature initialization") adds default supported features for phy, but our hardware also supports Asym Pause. This patch adds Asym Pause support to phy default features to prevent Asym Pause can not be advertised when the phy negotiates flow control. Fixes: c4fb2cdf575d ("net: hns3: fix a bug for phy supported feature initialization") Signed-off-by: Fuyun Liang <liangfuyun1(a)huawei.com> Signed-off-by: Peng Li <lipeng321(a)huawei.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c @@ -17,6 +17,7 @@ #define HCLGE_PHY_SUPPORTED_FEATURES (SUPPORTED_Autoneg | \ SUPPORTED_TP | \ SUPPORTED_Pause | \ + SUPPORTED_Asym_Pause | \ PHY_10BT_FEATURES | \ PHY_100BT_FEATURES | \ PHY_1000BT_FEATURES) Patches currently in stable-queue which might be from liangfuyun1(a)huawei.com are queue-4.15/net-hns3-fix-for-getting-auto-negotiation-state-in-hclge_get_autoneg.patch queue-4.15/net-hns3-add-asym-pause-support-to-phy-default-features.patch queue-4.15/net-hns3-fix-for-changing-mtu.patch

7 years, 2 months

1
0
0 0

Patch "media: videobuf2-core: don't go out of the buffer range" 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 media: videobuf2-core: don't go out of the buffer range 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: media-videobuf2-core-don-t-go-out-of-the-buffer-range.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Date: Thu, 28 Dec 2017 09:16:47 -0500 Subject: media: videobuf2-core: don't go out of the buffer range From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> [ Upstream commit df93dc61b0d8b19a5c9db545cf3fcc24f88dfde4 ] Currently, there's no check if an invalid buffer range is passed. However, while testing DVB memory mapped apps, I got this: videobuf2_core: VB: num_buffers -2143943680, buffer 33, index -2143943647 unable to handle kernel paging request at ffff888b773c0890 IP: __vb2_queue_alloc+0x134/0x4e0 [videobuf2_core] PGD 4142c7067 P4D 4142c7067 PUD 0 Oops: 0002 [#1] SMP Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables bluetooth rfkill ecdh_generic binfmt_misc rc_dvbsky sp2 ts2020 intel_rapl x86_pkg_temp_thermal dvb_usb_dvbsky intel_powerclamp dvb_usb_v2 coretemp m88ds3103 kvm_intel i2c_mux dvb_core snd_hda_codec_hdmi crct10dif_pclmul crc32_pclmul videobuf2_vmalloc videobuf2_memops snd_hda_intel ghash_clmulni_intel videobuf2_core snd_hda_codec rc_core mei_me intel_cstate snd_hwdep snd_hda_core videodev intel_uncore snd_pcm mei media tpm_tis tpm_tis_core intel_rapl_perf tpm snd_timer lpc_ich snd soundcore kvm irqbypass libcrc32c i915 i2c_algo_bit drm_kms_helper e1000e ptp drm crc32c_intel video pps_core CPU: 3 PID: 1776 Comm: dvbv5-zap Not tainted 4.14.0+ #78 Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0364.2017.0511.0949 05/11/2017 task: ffff88877c73bc80 task.stack: ffffb7c402418000 RIP: 0010:__vb2_queue_alloc+0x134/0x4e0 [videobuf2_core] RSP: 0018:ffffb7c40241bc60 EFLAGS: 00010246 RAX: 0000000080360421 RBX: 0000000000000021 RCX: 000000000000000a RDX: ffffb7c40241bcf4 RSI: ffff888780362c60 RDI: ffff888796d8e130 RBP: ffffb7c40241bcc8 R08: 0000000000000316 R09: 0000000000000004 R10: ffff888780362c00 R11: 0000000000000001 R12: 000000000002f000 R13: ffff8887758be700 R14: 0000000000021000 R15: 0000000000000001 FS: 00007f2849024740(0000) GS:ffff888796d80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff888b773c0890 CR3: 000000043beb2005 CR4: 00000000003606e0 Call Trace: vb2_core_reqbufs+0x226/0x420 [videobuf2_core] dvb_vb2_reqbufs+0x2d/0xc0 [dvb_core] dvb_dvr_do_ioctl+0x98/0x1d0 [dvb_core] dvb_usercopy+0x53/0x1b0 [dvb_core] ? dvb_demux_ioctl+0x20/0x20 [dvb_core] ? tty_ldisc_deref+0x16/0x20 ? tty_write+0x1f9/0x310 ? process_echoes+0x70/0x70 dvb_dvr_ioctl+0x15/0x20 [dvb_core] do_vfs_ioctl+0xa5/0x600 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x1a/0xa5 RIP: 0033:0x7f28486f7ea7 RSP: 002b:00007ffc13b2db18 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000055b10fc06130 RCX: 00007f28486f7ea7 RDX: 00007ffc13b2db48 RSI: 00000000c0086f3c RDI: 0000000000000007 RBP: 0000000000000203 R08: 000055b10df1e02c R09: 000000000000002e R10: 0036b42415108357 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f2849062f60 R14: 00000000000001f1 R15: 00007ffc13b2da54 Code: 74 0a 60 8b 0a 48 83 c0 30 48 83 c2 04 89 48 d0 89 48 d4 48 39 f0 75 eb 41 8b 42 08 83 7d d4 01 41 c7 82 ec 01 00 00 ff ff ff ff <4d> 89 94 c5 88 00 00 00 74 14 83 c3 01 41 39 dc 0f 85 f1 fe ff RIP: __vb2_queue_alloc+0x134/0x4e0 [videobuf2_core] RSP: ffffb7c40241bc60 CR2: ffff888b773c0890 So, add a sanity check in order to prevent going past array. Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Acked-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/v4l2-core/videobuf2-core.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -332,6 +332,10 @@ static int __vb2_queue_alloc(struct vb2_ struct vb2_buffer *vb; int ret; + /* Ensure that q->num_buffers+num_buffers is below VB2_MAX_FRAME */ + num_buffers = min_t(unsigned int, num_buffers, + VB2_MAX_FRAME - q->num_buffers); + for (buffer = 0; buffer < num_buffers; ++buffer) { /* Allocate videobuf buffer structures */ vb = kzalloc(q->buf_struct_size, GFP_KERNEL); Patches currently in stable-queue which might be from mchehab(a)s-opensource.com are queue-4.15/media-videobuf2-core-don-t-go-out-of-the-buffer-range.patch

7 years, 2 months

1
0
0 0

Patch "mtd: mtd_oobtest: Handle bitflips during reads" 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 mtd: mtd_oobtest: Handle bitflips during reads 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: mtd-mtd_oobtest-handle-bitflips-during-reads.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Miquel Raynal <miquel.raynal(a)free-electrons.com> Date: Thu, 11 Jan 2018 21:39:20 +0100 Subject: mtd: mtd_oobtest: Handle bitflips during reads From: Miquel Raynal <miquel.raynal(a)free-electrons.com> [ Upstream commit 12663b442e5ac5aa3d6097cd3f287c71ba46d26e ] Reads from NAND devices usually trigger bitflips, this is an expected behavior. While bitflips are under a given threshold, the MTD core returns 0. However, when the number of corrected bitflips is above this same threshold, -EUCLEAN is returned to inform the upper layer that this block is slightly dying and soon the ECC engine will be overtaken so actions should be taken to move the data out of it. This particular condition should not be treated like an error and the test should continue. Signed-off-by: Miquel Raynal <miquel.raynal(a)free-electrons.com> Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mtd/tests/oobtest.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) --- a/drivers/mtd/tests/oobtest.c +++ b/drivers/mtd/tests/oobtest.c @@ -193,6 +193,9 @@ static int verify_eraseblock(int ebnum) ops.datbuf = NULL; ops.oobbuf = readbuf; err = mtd_read_oob(mtd, addr, &ops); + if (mtd_is_bitflip(err)) + err = 0; + if (err || ops.oobretlen != use_len) { pr_err("error: readoob failed at %#llx\n", (long long)addr); @@ -227,6 +230,9 @@ static int verify_eraseblock(int ebnum) ops.datbuf = NULL; ops.oobbuf = readbuf; err = mtd_read_oob(mtd, addr, &ops); + if (mtd_is_bitflip(err)) + err = 0; + if (err || ops.oobretlen != mtd->oobavail) { pr_err("error: readoob failed at %#llx\n", (long long)addr); @@ -286,6 +292,9 @@ static int verify_eraseblock_in_one_go(i /* read entire block's OOB at one go */ err = mtd_read_oob(mtd, addr, &ops); + if (mtd_is_bitflip(err)) + err = 0; + if (err || ops.oobretlen != len) { pr_err("error: readoob failed at %#llx\n", (long long)addr); @@ -527,6 +536,9 @@ static int __init mtd_oobtest_init(void) pr_info("attempting to start read past end of OOB\n"); pr_info("an error is expected...\n"); err = mtd_read_oob(mtd, addr0, &ops); + if (mtd_is_bitflip(err)) + err = 0; + if (err) { pr_info("error occurred as expected\n"); err = 0; @@ -571,6 +583,9 @@ static int __init mtd_oobtest_init(void) pr_info("attempting to read past end of device\n"); pr_info("an error is expected...\n"); err = mtd_read_oob(mtd, mtd->size - mtd->writesize, &ops); + if (mtd_is_bitflip(err)) + err = 0; + if (err) { pr_info("error occurred as expected\n"); err = 0; @@ -615,6 +630,9 @@ static int __init mtd_oobtest_init(void) pr_info("attempting to read past end of device\n"); pr_info("an error is expected...\n"); err = mtd_read_oob(mtd, mtd->size - mtd->writesize, &ops); + if (mtd_is_bitflip(err)) + err = 0; + if (err) { pr_info("error occurred as expected\n"); err = 0; @@ -684,6 +702,9 @@ static int __init mtd_oobtest_init(void) ops.datbuf = NULL; ops.oobbuf = readbuf; err = mtd_read_oob(mtd, addr, &ops); + if (mtd_is_bitflip(err)) + err = 0; + if (err) goto out; if (memcmpshow(addr, readbuf, writebuf, Patches currently in stable-queue which might be from miquel.raynal(a)free-electrons.com are queue-4.15/mtd-mtd_oobtest-handle-bitflips-during-reads.patch

7 years, 2 months

1
0
0 0

Patch "mac80211: Fix setting TX power on monitor interfaces" 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 mac80211: Fix setting TX power on monitor interfaces 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: mac80211-fix-setting-tx-power-on-monitor-interfaces.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: "Peter Große" <pegro(a)friiks.de> Date: Wed, 13 Dec 2017 18:29:46 +0100 Subject: mac80211: Fix setting TX power on monitor interfaces From: "Peter Große" <pegro(a)friiks.de> [ Upstream commit 3a3713ec360138f806c6fc368d1de570f692b347 ] Instead of calling ieee80211_recalc_txpower on monitor interfaces directly, call it using the virtual monitor interface, if one exists. In case of a single monitor interface given, reject setting TX power, if no virtual monitor interface exists. That being checked, don't warn in ieee80211_bss_info_change_notify, after setting TX power on a monitor interface. Fixes warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 2193 at net/mac80211/driver-ops.h:167 ieee80211_bss_info_change_notify+0x111/0x190 Modules linked in: uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core rndis_host cdc_ether usbnet mii tp_smapi(O) thinkpad_ec(O) ohci_hcd vboxpci(O) vboxnetadp(O) vboxnetflt(O) v boxdrv(O) x86_pkg_temp_thermal kvm_intel kvm irqbypass iwldvm iwlwifi ehci_pci ehci_hcd tpm_tis tpm_tis_core tpm CPU: 0 PID: 2193 Comm: iw Tainted: G O 4.12.12-gentoo #2 task: ffff880186fd5cc0 task.stack: ffffc90001b54000 RIP: 0010:ieee80211_bss_info_change_notify+0x111/0x190 RSP: 0018:ffffc90001b57a10 EFLAGS: 00010246 RAX: 0000000000000006 RBX: ffff8801052ce840 RCX: 0000000000000064 RDX: 00000000fffffffc RSI: 0000000000040000 RDI: ffff8801052ce840 RBP: ffffc90001b57a38 R08: 0000000000000062 R09: 0000000000000000 R10: ffff8802144b5000 R11: ffff880049dc4614 R12: 0000000000040000 R13: 0000000000000064 R14: ffff8802105f0760 R15: ffffc90001b57b48 FS: 00007f92644b4580(0000) GS:ffff88021e200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9263c109f0 CR3: 00000001df850000 CR4: 00000000000406f0 Call Trace: ieee80211_recalc_txpower+0x33/0x40 ieee80211_set_tx_power+0x40/0x180 nl80211_set_wiphy+0x32e/0x950 Reported-by: Peter GroÃe <pegro(a)friiks.de> Signed-off-by: Peter GroÃe <pegro(a)friiks.de> Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/mac80211/cfg.c | 28 +++++++++++++++++++++++++++- net/mac80211/driver-ops.h | 3 ++- 2 files changed, 29 insertions(+), 2 deletions(-) --- a/net/mac80211/cfg.c +++ b/net/mac80211/cfg.c @@ -2373,10 +2373,17 @@ static int ieee80211_set_tx_power(struct struct ieee80211_sub_if_data *sdata; enum nl80211_tx_power_setting txp_type = type; bool update_txp_type = false; + bool has_monitor = false; if (wdev) { sdata = IEEE80211_WDEV_TO_SUB_IF(wdev); + if (sdata->vif.type == NL80211_IFTYPE_MONITOR) { + sdata = rtnl_dereference(local->monitor_sdata); + if (!sdata) + return -EOPNOTSUPP; + } + switch (type) { case NL80211_TX_POWER_AUTOMATIC: sdata->user_power_level = IEEE80211_UNSET_POWER_LEVEL; @@ -2415,15 +2422,34 @@ static int ieee80211_set_tx_power(struct mutex_lock(&local->iflist_mtx); list_for_each_entry(sdata, &local->interfaces, list) { + if (sdata->vif.type == NL80211_IFTYPE_MONITOR) { + has_monitor = true; + continue; + } sdata->user_power_level = local->user_power_level; if (txp_type != sdata->vif.bss_conf.txpower_type) update_txp_type = true; sdata->vif.bss_conf.txpower_type = txp_type; } - list_for_each_entry(sdata, &local->interfaces, list) + list_for_each_entry(sdata, &local->interfaces, list) { + if (sdata->vif.type == NL80211_IFTYPE_MONITOR) + continue; ieee80211_recalc_txpower(sdata, update_txp_type); + } mutex_unlock(&local->iflist_mtx); + if (has_monitor) { + sdata = rtnl_dereference(local->monitor_sdata); + if (sdata) { + sdata->user_power_level = local->user_power_level; + if (txp_type != sdata->vif.bss_conf.txpower_type) + update_txp_type = true; + sdata->vif.bss_conf.txpower_type = txp_type; + + ieee80211_recalc_txpower(sdata, update_txp_type); + } + } + return 0; } --- a/net/mac80211/driver-ops.h +++ b/net/mac80211/driver-ops.h @@ -165,7 +165,8 @@ static inline void drv_bss_info_changed( if (WARN_ON_ONCE(sdata->vif.type == NL80211_IFTYPE_P2P_DEVICE || sdata->vif.type == NL80211_IFTYPE_NAN || (sdata->vif.type == NL80211_IFTYPE_MONITOR && - !sdata->vif.mu_mimo_owner))) + !sdata->vif.mu_mimo_owner && + !(changed & BSS_CHANGED_TXPOWER)))) return; if (!check_sdata_in_driver(sdata)) Patches currently in stable-queue which might be from pegro(a)friiks.de are queue-4.15/mac80211-fix-setting-tx-power-on-monitor-interfaces.patch

7 years, 2 months

1
0
0 0

Patch "irqchip/ompic: fix return value check in ompic_of_init()" 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 irqchip/ompic: fix return value check in ompic_of_init() 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: irqchip-ompic-fix-return-value-check-in-ompic_of_init.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Wei Yongjun <weiyongjun1(a)huawei.com> Date: Tue, 2 Jan 2018 11:47:19 +0000 Subject: irqchip/ompic: fix return value check in ompic_of_init() From: Wei Yongjun <weiyongjun1(a)huawei.com> [ Upstream commit 404e6bea10662f0e142748353169d25378271e49 ] In case of error, the function ioremap() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Fixes: 9b54470afd83 ("irqchip: add initial support for ompic") Acked-by: Stafford Horne <shorne(a)gmail.com> Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com> Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/irqchip/irq-ompic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/irqchip/irq-ompic.c +++ b/drivers/irqchip/irq-ompic.c @@ -171,9 +171,9 @@ static int __init ompic_of_init(struct d /* Setup the device */ ompic_base = ioremap(res.start, resource_size(&res)); - if (IS_ERR(ompic_base)) { + if (!ompic_base) { pr_err("ompic: unable to map registers"); - return PTR_ERR(ompic_base); + return -ENOMEM; } irq = irq_of_parse_and_map(node, 0); Patches currently in stable-queue which might be from weiyongjun1(a)huawei.com are queue-4.15/gpio-thunderx-fix-error-return-code-in-thunderx_gpio_probe.patch queue-4.15/irqchip-ompic-fix-return-value-check-in-ompic_of_init.patch

7 years, 2 months

1
0
0 0

Patch "l2tp: fix missing print session offset info" 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 l2tp: fix missing print session offset info 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: l2tp-fix-missing-print-session-offset-info.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Hangbin Liu <liuhangbin(a)gmail.com> Date: Fri, 22 Dec 2017 15:10:17 +0100 Subject: l2tp: fix missing print session offset info From: Hangbin Liu <liuhangbin(a)gmail.com> [ Upstream commit 820da5357572715c6235ba3b3daa2d5b43a1198f ] Report offset parameter in L2TP_CMD_SESSION_GET command if it has been configured by userspace Fixes: 309795f4bec ("l2tp: Add netlink control API for L2TP") Reported-by: Jianlin Shi <jishi(a)redhat.com> Signed-off-by: Hangbin Liu <liuhangbin(a)gmail.com> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi(a)redhat.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/l2tp/l2tp_netlink.c | 2 ++ 1 file changed, 2 insertions(+) --- a/net/l2tp/l2tp_netlink.c +++ b/net/l2tp/l2tp_netlink.c @@ -761,6 +761,8 @@ static int l2tp_nl_session_send(struct s if ((session->ifname[0] && nla_put_string(skb, L2TP_ATTR_IFNAME, session->ifname)) || + (session->offset && + nla_put_u16(skb, L2TP_ATTR_OFFSET, session->offset)) || (session->cookie_len && nla_put(skb, L2TP_ATTR_COOKIE, session->cookie_len, &session->cookie[0])) || Patches currently in stable-queue which might be from liuhangbin(a)gmail.com are queue-4.15/l2tp-fix-missing-print-session-offset-info.patch

7 years, 2 months

1
0
0 0

Patch "ipv6: Reinject IPv6 packets if IPsec policy matches after SNAT" 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 ipv6: Reinject IPv6 packets if IPsec policy matches after SNAT 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: ipv6-reinject-ipv6-packets-if-ipsec-policy-matches-after-snat.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Tobias Brunner <tobias(a)strongswan.org> Date: Thu, 21 Dec 2017 17:32:24 +0100 Subject: ipv6: Reinject IPv6 packets if IPsec policy matches after SNAT From: Tobias Brunner <tobias(a)strongswan.org> [ Upstream commit 09ee9dba9611cd382fd360a99ad1c2fa23bfdca8 ] If SNAT modifies the source address the resulting packet might match an IPsec policy, reinject the packet if that's the case. The exact same thing is already done for IPv4. Signed-off-by: Tobias Brunner <tobias(a)strongswan.org> Acked-by: Steffen Klassert <steffen.klassert(a)secunet.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv6/ip6_output.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -138,6 +138,14 @@ static int ip6_finish_output(struct net return ret; } +#if defined(CONFIG_NETFILTER) && defined(CONFIG_XFRM) + /* Policy lookup after SNAT yielded a new policy */ + if (skb_dst(skb)->xfrm) { + IPCB(skb)->flags |= IPSKB_REROUTED; + return dst_output(net, sk, skb); + } +#endif + if ((skb->len > ip6_skb_dst_mtu(skb) && !skb_is_gso(skb)) || dst_allfrag(skb_dst(skb)) || (IP6CB(skb)->frag_max_size && skb->len > IP6CB(skb)->frag_max_size)) Patches currently in stable-queue which might be from tobias(a)strongswan.org are queue-4.15/ipv6-reinject-ipv6-packets-if-ipsec-policy-matches-after-snat.patch

7 years, 2 months

1
0
0 0

Patch "irqchip/gic-v3: Fix the driver probe() fail due to disabled GICC entry" 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 irqchip/gic-v3: Fix the driver probe() fail due to disabled GICC entry 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: irqchip-gic-v3-fix-the-driver-probe-fail-due-to-disabled-gicc-entry.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Shanker Donthineni <shankerd(a)codeaurora.org> Date: Tue, 5 Dec 2017 13:16:21 -0600 Subject: irqchip/gic-v3: Fix the driver probe() fail due to disabled GICC entry From: Shanker Donthineni <shankerd(a)codeaurora.org> [ Upstream commit ebe2f8718007d5a1238bb3cb8141b5bb2b4d5773 ] The ACPI specification says OS shouldn't attempt to use GICC configuration parameters if the flag ACPI_MADT_ENABLED is cleared. The ARM64-SMP code skips the disabled GICC entries but not causing any issue. However the current GICv3 driver probe bails out causing kernel panic() instead of skipping the disabled GICC interfaces. This issue happens on systems where redistributor regions are not in the always-on power domain and one of GICC interface marked with ACPI_MADT_ENABLED=0. This patch does the two things to fix the panic. - Don't return an error in gic_acpi_match_gicc() for disabled GICC entry. - No need to keep GICR region information for disabled GICC entry. Observed kernel crash on QDF2400 platform GICC entry is disabled. Kernel crash traces: Kernel panic - not syncing: No interrupt controller found. CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.13.5 #26 [<ffff000008087770>] dump_backtrace+0x0/0x218 [<ffff0000080879dc>] show_stack+0x14/0x20 [<ffff00000883b078>] dump_stack+0x98/0xb8 [<ffff0000080c5c14>] panic+0x118/0x26c [<ffff000008b62348>] init_IRQ+0x24/0x2c [<ffff000008b609fc>] start_kernel+0x230/0x394 [<ffff000008b601e4>] __primary_switched+0x64/0x6c ---[ end Kernel panic - not syncing: No interrupt controller found. Disabled GICC subtable example: Subtable Type : 0B [Generic Interrupt Controller] Length : 50 Reserved : 0000 CPU Interface Number : 0000003D Processor UID : 0000003D Flags (decoded below) : 00000000 Processor Enabled : 0 Performance Interrupt Trig Mode : 0 Virtual GIC Interrupt Trig Mode : 0 Parking Protocol Version : 00000000 Performance Interrupt : 00000017 Parked Address : 0000000000000000 Base Address : 0000000000000000 Virtual GIC Base Address : 0000000000000000 Hypervisor GIC Base Address : 0000000000000000 Virtual GIC Interrupt : 00000019 Redistributor Base Address : 0000FFFF88F40000 ARM MPIDR : 000000000000000D Efficiency Class : 00 Reserved : 000000 Signed-off-by: Shanker Donthineni <shankerd(a)codeaurora.org> Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/irqchip/irq-gic-v3.c | 11 +++++++++++ 1 file changed, 11 insertions(+) --- a/drivers/irqchip/irq-gic-v3.c +++ b/drivers/irqchip/irq-gic-v3.c @@ -1331,6 +1331,10 @@ gic_acpi_parse_madt_gicc(struct acpi_sub u32 size = reg == GIC_PIDR2_ARCH_GICv4 ? SZ_64K * 4 : SZ_64K * 2; void __iomem *redist_base; + /* GICC entry which has !ACPI_MADT_ENABLED is not unusable so skip */ + if (!(gicc->flags & ACPI_MADT_ENABLED)) + return 0; + redist_base = ioremap(gicc->gicr_base_address, size); if (!redist_base) return -ENOMEM; @@ -1380,6 +1384,13 @@ static int __init gic_acpi_match_gicc(st if ((gicc->flags & ACPI_MADT_ENABLED) && gicc->gicr_base_address) return 0; + /* + * It's perfectly valid firmware can pass disabled GICC entry, driver + * should not treat as errors, skip the entry instead of probe fail. + */ + if (!(gicc->flags & ACPI_MADT_ENABLED)) + return 0; + return -ENODEV; } Patches currently in stable-queue which might be from shankerd(a)codeaurora.org are queue-4.15/irqchip-gic-v3-fix-the-driver-probe-fail-due-to-disabled-gicc-entry.patch

7 years, 2 months

1
0
0 0

Patch "ibmvnic: Don't handle RX interrupts when not up." 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 ibmvnic: Don't handle RX interrupts when not up. 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: ibmvnic-don-t-handle-rx-interrupts-when-not-up.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Nathan Fontenot <nfont(a)linux.vnet.ibm.com> Date: Wed, 10 Jan 2018 10:40:09 -0600 Subject: ibmvnic: Don't handle RX interrupts when not up. From: Nathan Fontenot <nfont(a)linux.vnet.ibm.com> [ Upstream commit 09fb35ead58cd557aa9b20576d15816bc91a4deb ] Initiating a kdump via the command line can cause a pending interrupt to be handled by the ibmvnic driver when initializing the sub-CRQ irqs during driver initialization. NIP [d000000000ca34f0] ibmvnic_interrupt_rx+0x40/0xd0 [ibmvnic] LR [c000000008132ef0] __handle_irq_event_percpu+0xa0/0x2f0 Call Trace: [c000000047fcfde0] [c000000008132ef0] __handle_irq_event_percpu+0xa0/0x2f0 [c000000047fcfea0] [c00000000813317c] handle_irq_event_percpu+0x3c/0x90 [c000000047fcfee0] [c00000000813323c] handle_irq_event+0x6c/0xd0 [c000000047fcff10] [c0000000081385e0] handle_fasteoi_irq+0xf0/0x250 [c000000047fcff40] [c0000000081320a0] generic_handle_irq+0x50/0x80 [c000000047fcff60] [c000000008014984] __do_irq+0x84/0x1d0 [c000000047fcff90] [c000000008027564] call_do_irq+0x14/0x24 [c00000003c92af00] [c000000008014b70] do_IRQ+0xa0/0x120 [c00000003c92af50] [c000000008002594] hardware_interrupt_common+0x114/0x180 Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/ibm/ibmvnic.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/net/ethernet/ibm/ibmvnic.c +++ b/drivers/net/ethernet/ibm/ibmvnic.c @@ -2484,6 +2484,12 @@ static irqreturn_t ibmvnic_interrupt_rx( struct ibmvnic_sub_crq_queue *scrq = instance; struct ibmvnic_adapter *adapter = scrq->adapter; + /* When booting a kdump kernel we can hit pending interrupts + * prior to completing driver initialization. + */ + if (unlikely(adapter->state != VNIC_OPEN)) + return IRQ_NONE; + adapter->rx_stats_buffers[scrq->scrq_num].interrupts++; if (napi_schedule_prep(&adapter->napi[scrq->scrq_num])) { Patches currently in stable-queue which might be from nfont(a)linux.vnet.ibm.com are queue-4.15/ibmvnic-don-t-handle-rx-interrupts-when-not-up.patch

7 years, 2 months

1
0
0 0

Patch "Input: goodix - disable IRQs while suspended" 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 Input: goodix - disable IRQs while suspended 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: input-goodix-disable-irqs-while-suspended.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Hans de Goede <hdegoede(a)redhat.com> Date: Fri, 12 Jan 2018 00:36:48 -0800 Subject: Input: goodix - disable IRQs while suspended From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit faec44b6838312484d63e82286087cf2d5ebb891 ] We should not try to do any i2c transfers before the controller is resumed (which happens before our resume method gets called). So we need to disable our IRQ while suspended to enforce this. The code paths for devices with GPIOs for the int and reset pins already disable the IRQ the through goodix_free_irq(). This commit also disables the IRQ while suspended for devices without GPIOs for the int and reset pins. This fixes the i2c bus sometimes getting stuck after a suspend/resume causing the touchscreen to sometimes not work after a suspend/resume. This has been tested on a GPD pocked device. BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10 BugLink: https://www.reddit.com/r/GPDPocket/comments/7niut2/fix_for_broken_touch_aft… Tested-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Reviewed-by: Bastien Nocera <hadess(a)hadess.net> Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/input/touchscreen/goodix.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/drivers/input/touchscreen/goodix.c +++ b/drivers/input/touchscreen/goodix.c @@ -878,8 +878,10 @@ static int __maybe_unused goodix_suspend int error; /* We need gpio pins to suspend/resume */ - if (!ts->gpiod_int || !ts->gpiod_rst) + if (!ts->gpiod_int || !ts->gpiod_rst) { + disable_irq(client->irq); return 0; + } wait_for_completion(&ts->firmware_loading_complete); @@ -919,8 +921,10 @@ static int __maybe_unused goodix_resume( struct goodix_ts_data *ts = i2c_get_clientdata(client); int error; - if (!ts->gpiod_int || !ts->gpiod_rst) + if (!ts->gpiod_int || !ts->gpiod_rst) { + enable_irq(client->irq); return 0; + } /* * Exit sleep mode by outputting HIGH level to INT pin Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.15/serdev-fix-serdev_uevent-failure-on-acpi-enumerated-serdev-controllers.patch queue-4.15/acpi-video-default-lcd_only-to-true-on-win8-ready-and-newer-machines.patch queue-4.15/bluetooth-hci_bcm-mandate-presence-of-shutdown-and-device-wake-gpio.patch queue-4.15/input-goodix-disable-irqs-while-suspended.patch queue-4.15/asoc-intel-cht_bsw_rt5645-analog-mic-support.patch queue-4.15/power-supply-axp288_charger-properly-stop-work-on-probe-error-remove.patch queue-4.15/pinctrl-baytrail-enable-glitch-filter-for-gpios-used-as-interrupts.patch

7 years, 2 months

1
0
0 0

Patch "IB/mlx5: Report inner RSS capability" 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 IB/mlx5: Report inner RSS capability 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: ib-mlx5-report-inner-rss-capability.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Maor Gottlieb <maorg(a)mellanox.com> Date: Sun, 24 Dec 2017 14:51:25 +0200 Subject: IB/mlx5: Report inner RSS capability From: Maor Gottlieb <maorg(a)mellanox.com> [ Upstream commit 4e2b53a5cb5a8243284dd7ec4980d2dc556e79f0 ] Add missing inner RSS support capability as part of the RSS supported fields. In addition change MLX5_RX_HASH_INNER to 1UL << 31 in order to define it as unsigned. Fixes: 309fa3470fca ("IB/mlx5: Add support for RSS on the inner packet") Signed-off-by: Maor Gottlieb <maorg(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/mlx5/main.c | 3 ++- include/uapi/rdma/mlx5-abi.h | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) --- a/drivers/infiniband/hw/mlx5/main.c +++ b/drivers/infiniband/hw/mlx5/main.c @@ -682,7 +682,8 @@ static int mlx5_ib_query_device(struct i MLX5_RX_HASH_SRC_PORT_TCP | MLX5_RX_HASH_DST_PORT_TCP | MLX5_RX_HASH_SRC_PORT_UDP | - MLX5_RX_HASH_DST_PORT_UDP; + MLX5_RX_HASH_DST_PORT_UDP | + MLX5_RX_HASH_INNER; resp.response_length += sizeof(resp.rss_caps); } } else { --- a/include/uapi/rdma/mlx5-abi.h +++ b/include/uapi/rdma/mlx5-abi.h @@ -307,7 +307,7 @@ enum mlx5_rx_hash_fields { MLX5_RX_HASH_SRC_PORT_UDP = 1 << 6, MLX5_RX_HASH_DST_PORT_UDP = 1 << 7, /* Save bits for future fields */ - MLX5_RX_HASH_INNER = 1 << 31 + MLX5_RX_HASH_INNER = (1UL << 31), }; struct mlx5_ib_create_qp_rss { Patches currently in stable-queue which might be from maorg(a)mellanox.com are queue-4.15/net-mlx4_en-change-default-qos-settings.patch queue-4.15/ib-mlx5-report-inner-rss-capability.patch

7 years, 2 months

1
0
0 0

Patch "IB/rdmavt: Allocate CQ memory on the correct node" 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 IB/rdmavt: Allocate CQ memory on the correct node 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: ib-rdmavt-allocate-cq-memory-on-the-correct-node.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Mike Marciniszyn <mike.marciniszyn(a)intel.com> Date: Mon, 18 Dec 2017 19:57:06 -0800 Subject: IB/rdmavt: Allocate CQ memory on the correct node From: Mike Marciniszyn <mike.marciniszyn(a)intel.com> [ Upstream commit db9a2c6f9b6196b889b98e961cb9a37617b11ccf ] CQ allocation does not ensure that completion queue entries and the completion queue structure are allocated on the correct numa node. Fix by allocating the rvt_cq and kernel CQ entries on the device node, leaving the user CQ entries on the default local node. Also ensure CQ resizes use the correct allocator when extending a CQ. Reviewed-by: Sebastian Sanchez <sebastian.sanchez(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: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/sw/rdmavt/cq.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) --- a/drivers/infiniband/sw/rdmavt/cq.c +++ b/drivers/infiniband/sw/rdmavt/cq.c @@ -198,7 +198,7 @@ struct ib_cq *rvt_create_cq(struct ib_de return ERR_PTR(-EINVAL); /* Allocate the completion queue structure. */ - cq = kzalloc(sizeof(*cq), GFP_KERNEL); + cq = kzalloc_node(sizeof(*cq), GFP_KERNEL, rdi->dparms.node); if (!cq) return ERR_PTR(-ENOMEM); @@ -214,7 +214,9 @@ struct ib_cq *rvt_create_cq(struct ib_de sz += sizeof(struct ib_uverbs_wc) * (entries + 1); else sz += sizeof(struct ib_wc) * (entries + 1); - wc = vmalloc_user(sz); + wc = udata ? + vmalloc_user(sz) : + vzalloc_node(sz, rdi->dparms.node); if (!wc) { ret = ERR_PTR(-ENOMEM); goto bail_cq; @@ -369,7 +371,9 @@ int rvt_resize_cq(struct ib_cq *ibcq, in sz += sizeof(struct ib_uverbs_wc) * (cqe + 1); else sz += sizeof(struct ib_wc) * (cqe + 1); - wc = vmalloc_user(sz); + wc = udata ? + vmalloc_user(sz) : + vzalloc_node(sz, rdi->dparms.node); if (!wc) return -ENOMEM; Patches currently in stable-queue which might be from mike.marciniszyn(a)intel.com are queue-4.15/ib-ipoib-fix-for-notify-send-cq-failure-messages.patch queue-4.15/ib-rdmavt-allocate-cq-memory-on-the-correct-node.patch

7 years, 2 months

1
0
0 0

Patch "i40iw: Validate correct IRD/ORD connection parameters" 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 i40iw: Validate correct IRD/ORD connection parameters 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: i40iw-validate-correct-ird-ord-connection-parameters.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Tatyana Nikolova <tatyana.e.nikolova(a)intel.com> Date: Fri, 22 Dec 2017 09:47:01 -0600 Subject: i40iw: Validate correct IRD/ORD connection parameters From: Tatyana Nikolova <tatyana.e.nikolova(a)intel.com> [ Upstream commit ce9ce74145aa6814a370a9ff4f5a1d719baaced1 ] Casting to u16 before validating IRD/ORD connection parameters could cause recording wrong IRD/ORD values in the cm_node. Validate the IRD/ORD parameters as they are passed by the application before recording them. Fixes: f27b4746f378 ("i40iw: add connection management code") Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova(a)intel.com> Signed-off-by: Shiraz Saleem <shiraz.saleem(a)intel.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/i40iw/i40iw_cm.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/drivers/infiniband/hw/i40iw/i40iw_cm.c +++ b/drivers/infiniband/hw/i40iw/i40iw_cm.c @@ -125,7 +125,8 @@ static u8 i40iw_derive_hw_ird_setting(u1 * @conn_ird: connection IRD * @conn_ord: connection ORD */ -static void i40iw_record_ird_ord(struct i40iw_cm_node *cm_node, u16 conn_ird, u16 conn_ord) +static void i40iw_record_ird_ord(struct i40iw_cm_node *cm_node, u32 conn_ird, + u32 conn_ord) { if (conn_ird > I40IW_MAX_IRD_SIZE) conn_ird = I40IW_MAX_IRD_SIZE; @@ -3849,7 +3850,7 @@ int i40iw_connect(struct iw_cm_id *cm_id } cm_node->apbvt_set = true; - i40iw_record_ird_ord(cm_node, (u16)conn_param->ird, (u16)conn_param->ord); + i40iw_record_ird_ord(cm_node, conn_param->ird, conn_param->ord); if (cm_node->send_rdma0_op == SEND_RDMA_READ_ZERO && !cm_node->ord_size) cm_node->ord_size = 1; Patches currently in stable-queue which might be from tatyana.e.nikolova(a)intel.com are queue-4.15/i40iw-validate-correct-ird-ord-connection-parameters.patch

7 years, 2 months

1
0
0 0

Patch "IB/ipoib: Fix for notify send CQ failure messages" 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 IB/ipoib: Fix for notify send CQ failure messages 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: ib-ipoib-fix-for-notify-send-cq-failure-messages.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Alex Estrin <alex.estrin(a)intel.com> Date: Wed, 3 Jan 2018 07:39:50 -0500 Subject: IB/ipoib: Fix for notify send CQ failure messages From: Alex Estrin <alex.estrin(a)intel.com> [ Upstream commit 809cb6955650d892c6ef95f1d55f28fceded0ce1 ] If IB_CQ_REPORT_MISSED_EVENTS flag is passed in ib_req_notify_cq() it may return positive value indicating non-empty CQ. If return code not verified the log might be flooded with false warning messages "request notify on send CQ failed". Fixes: 8966e28d2e40 ("IB/ipoib: Use NAPI in UD/TX flows") Reviewed-by: Mike Marciniszyn <mike.marciniszyn(a)intel.com> Signed-off-by: Alex Estrin <alex.estrin(a)intel.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/ulp/ipoib/ipoib_cm.c | 10 ++++++---- drivers/infiniband/ulp/ipoib/ipoib_ib.c | 2 +- 2 files changed, 7 insertions(+), 5 deletions(-) --- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c +++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c @@ -766,12 +766,14 @@ void ipoib_cm_send(struct net_device *de skb_orphan(skb); skb_dst_drop(skb); - if (netif_queue_stopped(dev)) - if (ib_req_notify_cq(priv->send_cq, IB_CQ_NEXT_COMP | - IB_CQ_REPORT_MISSED_EVENTS)) { + if (netif_queue_stopped(dev)) { + rc = ib_req_notify_cq(priv->send_cq, IB_CQ_NEXT_COMP | + IB_CQ_REPORT_MISSED_EVENTS); + if (unlikely(rc < 0)) ipoib_warn(priv, "IPoIB/CM:request notify on send CQ failed\n"); + else if (rc) napi_schedule(&priv->send_napi); - } + } rc = post_send(priv, tx, tx->tx_head & (ipoib_sendq_size - 1), tx_req); if (unlikely(rc)) { --- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c +++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c @@ -644,7 +644,7 @@ int ipoib_send(struct net_device *dev, s if (netif_queue_stopped(dev)) if (ib_req_notify_cq(priv->send_cq, IB_CQ_NEXT_COMP | - IB_CQ_REPORT_MISSED_EVENTS)) + IB_CQ_REPORT_MISSED_EVENTS) < 0) ipoib_warn(priv, "request notify on send CQ failed\n"); rc = post_send(priv, priv->tx_head & (ipoib_sendq_size - 1), Patches currently in stable-queue which might be from alex.estrin(a)intel.com are queue-4.15/ib-ipoib-fix-for-notify-send-cq-failure-messages.patch

7 years, 2 months

1
0
0 0

Patch "i40evf: don't rely on netif_running() outside rtnl_lock()" 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 i40evf: don't rely on netif_running() outside rtnl_lock() 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: i40evf-don-t-rely-on-netif_running-outside-rtnl_lock.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Jacob Keller <jacob.e.keller(a)intel.com> Date: Fri, 27 Oct 2017 11:06:49 -0400 Subject: i40evf: don't rely on netif_running() outside rtnl_lock() From: Jacob Keller <jacob.e.keller(a)intel.com> [ Upstream commit 44b034b406211fc103159f82b9e601e05675c739 ] In i40evf_reset_task we use netif_running() to determine whether or not the device is currently up. This allows us to properly free queue memory and shut down things before we request the hardware reset. It turns out that we cannot be guaranteed of netif_running() returning false until the device is fully up, as the kernel core code sets __LINK_STATE_START prior to calling .ndo_open. Since we're not holding the rtnl_lock(), it's possible that the driver's i40evf_open handler function is currently being called while we're resetting. We can't simply hold the rtnl_lock() while checking netif_running() as this could cause a deadlock with the i40evf_open() function. Additionally, we can't avoid the deadlock by holding the rtnl_lock() over the whole reset path, as this essentially serializes all resets, and can cause massive delays if we have multiple VFs on a system. Instead, lets just check our own internal state __I40EVF_RUNNING state field. This allows us to ensure that the state is correct and is only set after we've finished bringing the device up. Without this change we might free data structures about device queues and other memory before they've been fully allocated. Signed-off-by: Jacob Keller <jacob.e.keller(a)intel.com> Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/i40evf/i40evf_main.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c +++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c @@ -1796,7 +1796,11 @@ static void i40evf_disable_vf(struct i40 adapter->flags |= I40EVF_FLAG_PF_COMMS_FAILED; - if (netif_running(adapter->netdev)) { + /* We don't use netif_running() because it may be true prior to + * ndo_open() returning, so we can't assume it means all our open + * tasks have finished, since we're not holding the rtnl_lock here. + */ + if (adapter->state == __I40EVF_RUNNING) { set_bit(__I40E_VSI_DOWN, adapter->vsi.state); netif_carrier_off(adapter->netdev); netif_tx_disable(adapter->netdev); @@ -1854,6 +1858,7 @@ static void i40evf_reset_task(struct wor struct i40evf_mac_filter *f; u32 reg_val; int i = 0, err; + bool running; while (test_and_set_bit(__I40EVF_IN_CLIENT_TASK, &adapter->crit_section)) @@ -1913,7 +1918,13 @@ static void i40evf_reset_task(struct wor } continue_reset: - if (netif_running(netdev)) { + /* We don't use netif_running() because it may be true prior to + * ndo_open() returning, so we can't assume it means all our open + * tasks have finished, since we're not holding the rtnl_lock here. + */ + running = (adapter->state == __I40EVF_RUNNING); + + if (running) { netif_carrier_off(netdev); netif_tx_stop_all_queues(netdev); adapter->link_up = false; @@ -1964,7 +1975,10 @@ continue_reset: mod_timer(&adapter->watchdog_timer, jiffies + 2); - if (netif_running(adapter->netdev)) { + /* We were running when the reset started, so we need to restore some + * state here. + */ + if (running) { /* allocate transmit descriptors */ err = i40evf_setup_all_tx_resources(adapter); if (err) Patches currently in stable-queue which might be from jacob.e.keller(a)intel.com are queue-4.15/i40evf-don-t-rely-on-netif_running-outside-rtnl_lock.patch

7 years, 2 months

1
0
0 0

Patch "i40iw: Fix sequence number for the first partial FPDU" 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 i40iw: Fix sequence number for the first partial FPDU 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: i40iw-fix-sequence-number-for-the-first-partial-fpdu.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Shiraz Saleem <shiraz.saleem(a)intel.com> Date: Fri, 22 Dec 2017 09:46:59 -0600 Subject: i40iw: Fix sequence number for the first partial FPDU From: Shiraz Saleem <shiraz.saleem(a)intel.com> [ Upstream commit df8b13a1b23356d01dfc4647a5629cdb0f4ce566 ] Partial FPDU processing is broken as the sequence number for the first partial FPDU is wrong due to incorrect Q2 buffer offset. The offset should be 64 rather than 16. Fixes: 786c6adb3a94 ("i40iw: add puda code") Signed-off-by: Shiraz Saleem <shiraz.saleem(a)intel.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/i40iw/i40iw_d.h | 1 + drivers/infiniband/hw/i40iw/i40iw_puda.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) --- a/drivers/infiniband/hw/i40iw/i40iw_d.h +++ b/drivers/infiniband/hw/i40iw/i40iw_d.h @@ -97,6 +97,7 @@ #define RDMA_OPCODE_MASK 0x0f #define RDMA_READ_REQ_OPCODE 1 #define Q2_BAD_FRAME_OFFSET 72 +#define Q2_FPSN_OFFSET 64 #define CQE_MAJOR_DRV 0x8000 #define I40IW_TERM_SENT 0x01 --- a/drivers/infiniband/hw/i40iw/i40iw_puda.c +++ b/drivers/infiniband/hw/i40iw/i40iw_puda.c @@ -1378,7 +1378,7 @@ static void i40iw_ieq_handle_exception(s u32 *hw_host_ctx = (u32 *)qp->hw_host_ctx; u32 rcv_wnd = hw_host_ctx[23]; /* first partial seq # in q2 */ - u32 fps = qp->q2_buf[16]; + u32 fps = *(u32 *)(qp->q2_buf + Q2_FPSN_OFFSET); struct list_head *rxlist = &pfpdu->rxlist; struct list_head *plist; Patches currently in stable-queue which might be from shiraz.saleem(a)intel.com are queue-4.15/i40iw-fix-sequence-number-for-the-first-partial-fpdu.patch queue-4.15/i40iw-correct-q1-xf-object-count-equation.patch queue-4.15/i40iw-validate-correct-ird-ord-connection-parameters.patch

7 years, 2 months

1
0
0 0

Patch "i40iw: Correct Q1/XF object count equation" 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 i40iw: Correct Q1/XF object count equation 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: i40iw-correct-q1-xf-object-count-equation.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Shiraz Saleem <shiraz.saleem(a)intel.com> Date: Fri, 22 Dec 2017 09:46:56 -0600 Subject: i40iw: Correct Q1/XF object count equation From: Shiraz Saleem <shiraz.saleem(a)intel.com> [ Upstream commit fe99afd1febd74e0ef1fed7e3283f09effe1f4f0 ] Lower Inbound RDMA Read Queue (Q1) object count by a factor of 2 as it is incorrectly doubled. Also, round up Q1 and Transmit FIFO (XF) object count to power of 2 to satisfy hardware requirement. Fixes: 86dbcd0f12e9 ("i40iw: add file to handle cqp calls") Signed-off-by: Shiraz Saleem <shiraz.saleem(a)intel.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/i40iw/i40iw_ctrl.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/infiniband/hw/i40iw/i40iw_ctrl.c +++ b/drivers/infiniband/hw/i40iw/i40iw_ctrl.c @@ -3928,8 +3928,10 @@ enum i40iw_status_code i40iw_config_fpm_ hmc_info->hmc_obj[I40IW_HMC_IW_APBVT_ENTRY].cnt = 1; hmc_info->hmc_obj[I40IW_HMC_IW_MR].cnt = mrwanted; - hmc_info->hmc_obj[I40IW_HMC_IW_XF].cnt = I40IW_MAX_WQ_ENTRIES * qpwanted; - hmc_info->hmc_obj[I40IW_HMC_IW_Q1].cnt = 4 * I40IW_MAX_IRD_SIZE * qpwanted; + hmc_info->hmc_obj[I40IW_HMC_IW_XF].cnt = + roundup_pow_of_two(I40IW_MAX_WQ_ENTRIES * qpwanted); + hmc_info->hmc_obj[I40IW_HMC_IW_Q1].cnt = + roundup_pow_of_two(2 * I40IW_MAX_IRD_SIZE * qpwanted); hmc_info->hmc_obj[I40IW_HMC_IW_XFFL].cnt = hmc_info->hmc_obj[I40IW_HMC_IW_XF].cnt / hmc_fpm_misc->xf_block_size; hmc_info->hmc_obj[I40IW_HMC_IW_Q1FL].cnt = Patches currently in stable-queue which might be from shiraz.saleem(a)intel.com are queue-4.15/i40iw-fix-sequence-number-for-the-first-partial-fpdu.patch queue-4.15/i40iw-correct-q1-xf-object-count-equation.patch queue-4.15/i40iw-validate-correct-ird-ord-connection-parameters.patch

7 years, 2 months

1
0
0 0

Patch "hwmon: (ina2xx) Make calibration register value fixed" 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 hwmon: (ina2xx) Make calibration register value fixed 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: hwmon-ina2xx-make-calibration-register-value-fixed.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Maciej Purski <m.purski(a)samsung.com> Date: Wed, 22 Nov 2017 16:32:15 +0100 Subject: hwmon: (ina2xx) Make calibration register value fixed From: Maciej Purski <m.purski(a)samsung.com> [ Upstream commit 5d389b125186cf254ad5b8015763ac07c151aea4 ] Calibration register is used for calculating current register in hardware according to datasheet: current = shunt_volt * calib_register / 2048 (ina 226) current = shunt_volt * calib_register / 4096 (ina 219) Fix calib_register value to 2048 for ina226 and 4096 for ina 219 in order to avoid truncation error and provide best precision allowed by shunt_voltage measurement. Make current scale value follow changes of shunt_resistor from sysfs as calib_register value is now fixed. Power_lsb value should also follow shunt_resistor changes as stated in datasheet: power_lsb = 25 * current_lsb (ina 226) power_lsb = 20 * current_lsb (ina 219) Signed-off-by: Maciej Purski <m.purski(a)samsung.com> Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hwmon/ina2xx.c | 87 ++++++++++++++++++++++++++++--------------------- 1 file changed, 50 insertions(+), 37 deletions(-) --- a/drivers/hwmon/ina2xx.c +++ b/drivers/hwmon/ina2xx.c @@ -95,18 +95,20 @@ enum ina2xx_ids { ina219, ina226 }; struct ina2xx_config { u16 config_default; - int calibration_factor; + int calibration_value; int registers; int shunt_div; int bus_voltage_shift; int bus_voltage_lsb; /* uV */ - int power_lsb; /* uW */ + int power_lsb_factor; }; struct ina2xx_data { const struct ina2xx_config *config; long rshunt; + long current_lsb_uA; + long power_lsb_uW; struct mutex config_lock; struct regmap *regmap; @@ -116,21 +118,21 @@ struct ina2xx_data { static const struct ina2xx_config ina2xx_config[] = { [ina219] = { .config_default = INA219_CONFIG_DEFAULT, - .calibration_factor = 40960000, + .calibration_value = 4096, .registers = INA219_REGISTERS, .shunt_div = 100, .bus_voltage_shift = 3, .bus_voltage_lsb = 4000, - .power_lsb = 20000, + .power_lsb_factor = 20, }, [ina226] = { .config_default = INA226_CONFIG_DEFAULT, - .calibration_factor = 5120000, + .calibration_value = 2048, .registers = INA226_REGISTERS, .shunt_div = 400, .bus_voltage_shift = 0, .bus_voltage_lsb = 1250, - .power_lsb = 25000, + .power_lsb_factor = 25, }, }; @@ -169,12 +171,16 @@ static u16 ina226_interval_to_reg(int in return INA226_SHIFT_AVG(avg_bits); } +/* + * Calibration register is set to the best value, which eliminates + * truncation errors on calculating current register in hardware. + * According to datasheet (eq. 3) the best values are 2048 for + * ina226 and 4096 for ina219. They are hardcoded as calibration_value. + */ static int ina2xx_calibrate(struct ina2xx_data *data) { - u16 val = DIV_ROUND_CLOSEST(data->config->calibration_factor, - data->rshunt); - - return regmap_write(data->regmap, INA2XX_CALIBRATION, val); + return regmap_write(data->regmap, INA2XX_CALIBRATION, + data->config->calibration_value); } /* @@ -187,10 +193,6 @@ static int ina2xx_init(struct ina2xx_dat if (ret < 0) return ret; - /* - * Set current LSB to 1mA, shunt is in uOhms - * (equation 13 in datasheet). - */ return ina2xx_calibrate(data); } @@ -268,15 +270,15 @@ static int ina2xx_get_value(struct ina2x val = DIV_ROUND_CLOSEST(val, 1000); break; case INA2XX_POWER: - val = regval * data->config->power_lsb; + val = regval * data->power_lsb_uW; break; case INA2XX_CURRENT: - /* signed register, LSB=1mA (selected), in mA */ - val = (s16)regval; + /* signed register, result in mA */ + val = regval * data->current_lsb_uA; + val = DIV_ROUND_CLOSEST(val, 1000); break; case INA2XX_CALIBRATION: - val = DIV_ROUND_CLOSEST(data->config->calibration_factor, - regval); + val = regval; break; default: /* programmer goofed */ @@ -304,9 +306,32 @@ static ssize_t ina2xx_show_value(struct ina2xx_get_value(data, attr->index, regval)); } -static ssize_t ina2xx_set_shunt(struct device *dev, - struct device_attribute *da, - const char *buf, size_t count) +/* + * In order to keep calibration register value fixed, the product + * of current_lsb and shunt_resistor should also be fixed and equal + * to shunt_voltage_lsb = 1 / shunt_div multiplied by 10^9 in order + * to keep the scale. + */ +static int ina2xx_set_shunt(struct ina2xx_data *data, long val) +{ + unsigned int dividend = DIV_ROUND_CLOSEST(1000000000, + data->config->shunt_div); + if (val <= 0 || val > dividend) + return -EINVAL; + + mutex_lock(&data->config_lock); + data->rshunt = val; + data->current_lsb_uA = DIV_ROUND_CLOSEST(dividend, val); + data->power_lsb_uW = data->config->power_lsb_factor * + data->current_lsb_uA; + mutex_unlock(&data->config_lock); + + return 0; +} + +static ssize_t ina2xx_store_shunt(struct device *dev, + struct device_attribute *da, + const char *buf, size_t count) { unsigned long val; int status; @@ -316,18 +341,9 @@ static ssize_t ina2xx_set_shunt(struct d if (status < 0) return status; - if (val == 0 || - /* Values greater than the calibration factor make no sense. */ - val > data->config->calibration_factor) - return -EINVAL; - - mutex_lock(&data->config_lock); - data->rshunt = val; - status = ina2xx_calibrate(data); - mutex_unlock(&data->config_lock); + status = ina2xx_set_shunt(data, val); if (status < 0) return status; - return count; } @@ -387,7 +403,7 @@ static SENSOR_DEVICE_ATTR(power1_input, /* shunt resistance */ static SENSOR_DEVICE_ATTR(shunt_resistor, S_IRUGO | S_IWUSR, - ina2xx_show_value, ina2xx_set_shunt, + ina2xx_show_value, ina2xx_store_shunt, INA2XX_CALIBRATION); /* update interval (ina226 only) */ @@ -448,10 +464,7 @@ static int ina2xx_probe(struct i2c_clien val = INA2XX_RSHUNT_DEFAULT; } - if (val <= 0 || val > data->config->calibration_factor) - return -ENODEV; - - data->rshunt = val; + ina2xx_set_shunt(data, val); ina2xx_regmap_config.max_register = data->config->registers; Patches currently in stable-queue which might be from m.purski(a)samsung.com are queue-4.15/hwmon-ina2xx-make-calibration-register-value-fixed.patch

7 years, 2 months

1
0
0 0

Patch "gpio: thunderx: fix error return code in thunderx_gpio_probe()" 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 gpio: thunderx: fix error return code in thunderx_gpio_probe() 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: gpio-thunderx-fix-error-return-code-in-thunderx_gpio_probe.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Wei Yongjun <weiyongjun1(a)huawei.com> Date: Wed, 10 Jan 2018 14:37:13 +0000 Subject: gpio: thunderx: fix error return code in thunderx_gpio_probe() From: Wei Yongjun <weiyongjun1(a)huawei.com> [ Upstream commit 76e28f5ffed82b1e81a86c4eb8d0420515765620 ] Fix to return error code -ENOMEM from the error handling case instead of 0, as done elsewhere in this function. Fixes: 5a2a30024d8c ("gpio: Add gpio driver support for ThunderX and OCTEON-TX") Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com> Acked-by: David Daney <david.daney(a)cavium.com> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpio/gpio-thunderx.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/gpio/gpio-thunderx.c +++ b/drivers/gpio/gpio-thunderx.c @@ -553,8 +553,10 @@ static int thunderx_gpio_probe(struct pc txgpio->irqd = irq_domain_create_hierarchy(irq_get_irq_data(txgpio->msix_entries[0].vector)->domain, 0, 0, of_node_to_fwnode(dev->of_node), &thunderx_gpio_irqd_ops, txgpio); - if (!txgpio->irqd) + if (!txgpio->irqd) { + err = -ENOMEM; goto out; + } /* Push on irq_data and the domain for each line. */ for (i = 0; i < ngpio; i++) { Patches currently in stable-queue which might be from weiyongjun1(a)huawei.com are queue-4.15/gpio-thunderx-fix-error-return-code-in-thunderx_gpio_probe.patch queue-4.15/irqchip-ompic-fix-return-value-check-in-ompic_of_init.patch

7 years, 2 months

1
0
0 0

Patch "gpiolib: don't dereference a desc before validation" 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 gpiolib: don't dereference a desc before validation 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: gpiolib-don-t-dereference-a-desc-before-validation.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Vladimir Zapolskiy <vz(a)mleia.com> Date: Thu, 21 Dec 2017 18:37:24 +0200 Subject: gpiolib: don't dereference a desc before validation From: Vladimir Zapolskiy <vz(a)mleia.com> [ Upstream commit 30322bcf82d74cad0d6e1cf9ba7fa7fa48c7a026 ] The fix restores a proper validation of an input gpio desc, which might be needed to deal with optional GPIOs correctly. Fixes: 02e479808b5d ("gpio: Alter semantics of *raw* operations to actually be raw") Signed-off-by: Vladimir Zapolskiy <vz(a)mleia.com> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpio/gpiolib.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -2468,7 +2468,7 @@ EXPORT_SYMBOL_GPL(gpiod_direction_output */ int gpiod_direction_output(struct gpio_desc *desc, int value) { - struct gpio_chip *gc = desc->gdev->chip; + struct gpio_chip *gc; int ret; VALIDATE_DESC(desc); @@ -2485,6 +2485,7 @@ int gpiod_direction_output(struct gpio_d return -EIO; } + gc = desc->gdev->chip; if (test_bit(FLAG_OPEN_DRAIN, &desc->flags)) { /* First see if we can enable open drain in hardware */ ret = gpio_set_drive_single_ended(gc, gpio_chip_hwgpio(desc), Patches currently in stable-queue which might be from vz(a)mleia.com are queue-4.15/gpiolib-don-t-dereference-a-desc-before-validation.patch

7 years, 2 months

1
0
0 0

Patch "f2fs: fix lock dependency in between dio_rwsem & i_mmap_sem" 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 f2fs: fix lock dependency in between dio_rwsem & i_mmap_sem 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: f2fs-fix-lock-dependency-in-between-dio_rwsem-i_mmap_sem.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Chao Yu <yuchao0(a)huawei.com> Date: Thu, 23 Nov 2017 23:26:52 +0800 Subject: f2fs: fix lock dependency in between dio_rwsem & i_mmap_sem From: Chao Yu <yuchao0(a)huawei.com> [ Upstream commit 21020812c9e1ab593367fad9ce579f842a0b406d ] test/generic/208 reports a potential deadlock as below: Chain exists of: &mm->mmap_sem --> &fi->i_mmap_sem --> &fi->dio_rwsem[WRITE] Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&fi->dio_rwsem[WRITE]); lock(&fi->i_mmap_sem); lock(&fi->dio_rwsem[WRITE]); lock(&mm->mmap_sem); This patch changes the lock dependency as below in fallocate() to fix this issue: - dio_rwsem - i_mmap_sem Fixes: bb06664a534b ("f2fs: avoid race in between GC and block exchange") Signed-off-by: Chao Yu <yuchao0(a)huawei.com> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/f2fs/file.c | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -1186,14 +1186,14 @@ static int f2fs_collapse_range(struct in pg_start = offset >> PAGE_SHIFT; pg_end = (offset + len) >> PAGE_SHIFT; + /* avoid gc operation during block exchange */ + down_write(&F2FS_I(inode)->dio_rwsem[WRITE]); + down_write(&F2FS_I(inode)->i_mmap_sem); /* write out all dirty pages from offset */ ret = filemap_write_and_wait_range(inode->i_mapping, offset, LLONG_MAX); if (ret) - goto out; - - /* avoid gc operation during block exchange */ - down_write(&F2FS_I(inode)->dio_rwsem[WRITE]); + goto out_unlock; truncate_pagecache(inode, offset); @@ -1212,9 +1212,8 @@ static int f2fs_collapse_range(struct in if (!ret) f2fs_i_size_write(inode, new_size); out_unlock: - up_write(&F2FS_I(inode)->dio_rwsem[WRITE]); -out: up_write(&F2FS_I(inode)->i_mmap_sem); + up_write(&F2FS_I(inode)->dio_rwsem[WRITE]); return ret; } @@ -1385,6 +1384,9 @@ static int f2fs_insert_range(struct inod f2fs_balance_fs(sbi, true); + /* avoid gc operation during block exchange */ + down_write(&F2FS_I(inode)->dio_rwsem[WRITE]); + down_write(&F2FS_I(inode)->i_mmap_sem); ret = truncate_blocks(inode, i_size_read(inode), true); if (ret) @@ -1395,9 +1397,6 @@ static int f2fs_insert_range(struct inod if (ret) goto out; - /* avoid gc operation during block exchange */ - down_write(&F2FS_I(inode)->dio_rwsem[WRITE]); - truncate_pagecache(inode, offset); pg_start = offset >> PAGE_SHIFT; @@ -1425,10 +1424,9 @@ static int f2fs_insert_range(struct inod if (!ret) f2fs_i_size_write(inode, new_size); - - up_write(&F2FS_I(inode)->dio_rwsem[WRITE]); out: up_write(&F2FS_I(inode)->i_mmap_sem); + up_write(&F2FS_I(inode)->dio_rwsem[WRITE]); return ret; } Patches currently in stable-queue which might be from yuchao0(a)huawei.com are queue-4.15/f2fs-fix-lock-dependency-in-between-dio_rwsem-i_mmap_sem.patch

7 years, 2 months

1
0
0 0

Patch "gpio: label descriptors using the device name" 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 gpio: label descriptors using the device name 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: gpio-label-descriptors-using-the-device-name.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Linus Walleij <linus.walleij(a)linaro.org> Date: Thu, 4 Jan 2018 22:31:11 +0100 Subject: gpio: label descriptors using the device name From: Linus Walleij <linus.walleij(a)linaro.org> [ Upstream commit 24e78079bf2250874e33da2e7cfbb6db72d3caf4 ] Some GPIO lines appear named "?" in the lsgpio dump due to their requesting drivers not passing a reasonable label. Most typically this happens if a device tree node just defines gpios = <...> and not foo-gpios = <...>, the former gets named "foo" and the latter gets named "?". However the struct device passed in is always valid so let's just label the GPIO with dev_name() on the device if no proper label was passed. Cc: Reported-by: Jason Kridner <jkridner(a)beagleboard.org> Reported-by: Jason Kridner <jkridner(a)beagleboard.org> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpio/gpiolib.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -3647,7 +3647,8 @@ struct gpio_desc *__must_check gpiod_get return desc; } - status = gpiod_request(desc, con_id); + /* If a connection label was passed use that, else use the device name as label */ + status = gpiod_request(desc, con_id ? con_id : dev_name(dev)); if (status < 0) return ERR_PTR(status); Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are queue-4.15/gpio-label-descriptors-using-the-device-name.patch queue-4.15/gpio-thunderx-fix-error-return-code-in-thunderx_gpio_probe.patch queue-4.15/bluetooth-hci_bcm-mandate-presence-of-shutdown-and-device-wake-gpio.patch queue-4.15/pinctrl-baytrail-enable-glitch-filter-for-gpios-used-as-interrupts.patch queue-4.15/gpiolib-don-t-dereference-a-desc-before-validation.patch

7 years, 2 months

1
0
0 0

Patch "drm/amd/powerplay: fix memory leakage when reload (v2)" 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 drm/amd/powerplay: fix memory leakage when reload (v2) 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: drm-amd-powerplay-fix-memory-leakage-when-reload-v2.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Yintian Tao <yttao(a)amd.com> Date: Thu, 4 Jan 2018 11:45:23 +0800 Subject: drm/amd/powerplay: fix memory leakage when reload (v2) From: Yintian Tao <yttao(a)amd.com> [ Upstream commit a25513e7b9b15c318ec44113682e988829aef746 ] add smu_free_memory when smu fini to prevent memory leakage v2: squash in typo fix (Yintian) and warning (Harry) Signed-off-by: Yintian Tao <yttao(a)amd.com> Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c +++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c @@ -648,6 +648,12 @@ int smu7_init(struct pp_hwmgr *hwmgr) int smu7_smu_fini(struct pp_hwmgr *hwmgr) { + struct smu7_smumgr *smu_data = (struct smu7_smumgr *)(hwmgr->smu_backend); + + smu_free_memory(hwmgr->device, (void *) smu_data->header_buffer.handle); + if (!cgs_is_virtualization_enabled(hwmgr->device)) + smu_free_memory(hwmgr->device, (void *) smu_data->smu_buffer.handle); + kfree(hwmgr->smu_backend); hwmgr->smu_backend = NULL; cgs_rel_firmware(hwmgr->device, CGS_UCODE_ID_SMU); Patches currently in stable-queue which might be from yttao(a)amd.com are queue-4.15/drm-amd-powerplay-fix-memory-leakage-when-reload-v2.patch

7 years, 2 months

1
0
0 0

Patch "EDAC, mv64x60: Fix an error handling path" 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 EDAC, mv64x60: Fix an error handling path 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: edac-mv64x60-fix-an-error-handling-path.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Sun, 7 Jan 2018 21:54:00 +0100 Subject: EDAC, mv64x60: Fix an error handling path From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> [ Upstream commit 68fa24f9121c04ef146b5158f538c8b32f285be5 ] We should not call edac_mc_del_mc() if a corresponding call to edac_mc_add_mc() has not been performed yet. So here, we should go to err instead of err2 to branch at the right place of the error handling path. Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Cc: linux-edac <linux-edac(a)vger.kernel.org> Link: http://lkml.kernel.org/r/20180107205400.14068-1-christophe.jaillet@wanadoo.… Signed-off-by: Borislav Petkov <bp(a)suse.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/edac/mv64x60_edac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/edac/mv64x60_edac.c +++ b/drivers/edac/mv64x60_edac.c @@ -758,7 +758,7 @@ static int mv64x60_mc_err_probe(struct p /* Non-ECC RAM? */ printk(KERN_WARNING "%s: No ECC DIMMs discovered\n", __func__); res = -ENODEV; - goto err2; + goto err; } edac_dbg(3, "init mci\n"); Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-4.15/edac-mv64x60-fix-an-error-handling-path.patch queue-4.15/asoc-intel-sst-fix-the-return-value-of-sst_send_byte_stream_mrfld.patch

7 years, 2 months

1
0
0 0

Patch "drm/msm: Fix NULL deref in adreno_load_gpu" 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 drm/msm: Fix NULL deref in adreno_load_gpu 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: drm-msm-fix-null-deref-in-adreno_load_gpu.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Archit Taneja <architt(a)codeaurora.org> Date: Fri, 22 Dec 2017 15:41:13 +0530 Subject: drm/msm: Fix NULL deref in adreno_load_gpu From: Archit Taneja <architt(a)codeaurora.org> [ Upstream commit 9dcfbc182f1aac0aa5ea194733d21e67dd2ba1fd ] The msm/kms driver should work even if there is no GPU device specified in DT. Currently, we get a NULL dereference crash in adreno_load_gpu since the driver assumes that priv->gpu_pdev is non-NULL. Perform an additional check on priv->gpu_pdev before trying to retrieve the msm_gpu pointer from it. v2: Incorporate Jordan's comments: - Simplify the check to share the same error message. - Use dev_err_once() to avoid an error message every time we open the drm device fd. Fixes: eec874ce5ff1 (drm/msm/adreno: load gpu at probe/bind time) Signed-off-by: Archit Taneja <architt(a)codeaurora.org> Acked-by: Jordan Crouse <jcrouse(a)codeaurora.org> Signed-off-by: Rob Clark <robdclark(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/msm/adreno/adreno_device.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/msm/adreno/adreno_device.c +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c @@ -125,11 +125,14 @@ struct msm_gpu *adreno_load_gpu(struct d { struct msm_drm_private *priv = dev->dev_private; struct platform_device *pdev = priv->gpu_pdev; - struct msm_gpu *gpu = platform_get_drvdata(priv->gpu_pdev); + struct msm_gpu *gpu = NULL; int ret; + if (pdev) + gpu = platform_get_drvdata(pdev); + if (!gpu) { - dev_err(dev->dev, "no adreno device\n"); + dev_err_once(dev->dev, "no GPU device was found\n"); return NULL; } Patches currently in stable-queue which might be from architt(a)codeaurora.org are queue-4.15/drm-msm-fix-null-deref-in-adreno_load_gpu.patch

7 years, 2 months

1
0
0 0

Patch "cxgb4vf: Fix SGE FL buffer initialization logic for 64K pages" 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 cxgb4vf: Fix SGE FL buffer initialization logic for 64K pages 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: cxgb4vf-fix-sge-fl-buffer-initialization-logic-for-64k-pages.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Arjun Vynipadath <arjun(a)chelsio.com> Date: Wed, 10 Jan 2018 12:02:13 +0530 Subject: cxgb4vf: Fix SGE FL buffer initialization logic for 64K pages From: Arjun Vynipadath <arjun(a)chelsio.com> [ Upstream commit ea0a42109aee7b92e631c4eb3f2219fadf58acdd ] We'd come in with SGE_FL_BUFFER_SIZE[0] and [1] both equal to 64KB and the extant logic would flag that as an error. This was already fixed in cxgb4 driver with "92ddcc7 cxgb4: Fix some small bugs in t4_sge_init_soft() when our Page Size is 64KB". Original Work by: Casey Leedom <leedom(a)chelsio.com> Signed-off-by: Arjun Vynipadath <arjun(a)chelsio.com> Signed-off-by: Ganesh Goudar <ganeshgr(a)chelsio.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/chelsio/cxgb4vf/sge.c | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) --- a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c +++ b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c @@ -2619,8 +2619,8 @@ void t4vf_sge_stop(struct adapter *adapt int t4vf_sge_init(struct adapter *adapter) { struct sge_params *sge_params = &adapter->params.sge; - u32 fl0 = sge_params->sge_fl_buffer_size[0]; - u32 fl1 = sge_params->sge_fl_buffer_size[1]; + u32 fl_small_pg = sge_params->sge_fl_buffer_size[0]; + u32 fl_large_pg = sge_params->sge_fl_buffer_size[1]; struct sge *s = &adapter->sge; /* @@ -2628,9 +2628,20 @@ int t4vf_sge_init(struct adapter *adapte * the Physical Function Driver. Ideally we should be able to deal * with _any_ configuration. Practice is different ... */ - if (fl0 != PAGE_SIZE || (fl1 != 0 && fl1 <= fl0)) { + + /* We only bother using the Large Page logic if the Large Page Buffer + * is larger than our Page Size Buffer. + */ + if (fl_large_pg <= fl_small_pg) + fl_large_pg = 0; + + /* The Page Size Buffer must be exactly equal to our Page Size and the + * Large Page Size Buffer should be 0 (per above) or a power of 2. + */ + if (fl_small_pg != PAGE_SIZE || + (fl_large_pg & (fl_large_pg - 1)) != 0) { dev_err(adapter->pdev_dev, "bad SGE FL buffer sizes [%d, %d]\n", - fl0, fl1); + fl_small_pg, fl_large_pg); return -EINVAL; } if ((sge_params->sge_control & RXPKTCPLMODE_F) != @@ -2642,8 +2653,8 @@ int t4vf_sge_init(struct adapter *adapte /* * Now translate the adapter parameters into our internal forms. */ - if (fl1) - s->fl_pg_order = ilog2(fl1) - PAGE_SHIFT; + if (fl_large_pg) + s->fl_pg_order = ilog2(fl_large_pg) - PAGE_SHIFT; s->stat_len = ((sge_params->sge_control & EGRSTATUSPAGESIZE_F) ? 128 : 64); s->pktshift = PKTSHIFT_G(sge_params->sge_control); Patches currently in stable-queue which might be from arjun(a)chelsio.com are queue-4.15/cxgb4vf-fix-sge-fl-buffer-initialization-logic-for-64k-pages.patch

7 years, 2 months

1
0
0 0

Patch "crypto: crypto4xx - perform aead icv check in the driver" 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 crypto: crypto4xx - perform aead icv check in the driver 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: crypto-crypto4xx-perform-aead-icv-check-in-the-driver.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Christian Lamparter <chunkeey(a)gmail.com> Date: Sat, 23 Dec 2017 19:45:46 +0100 Subject: crypto: crypto4xx - perform aead icv check in the driver From: Christian Lamparter <chunkeey(a)gmail.com> [ Upstream commit 0b5a7f71b4c557b15ec54a1b49023bc1b21044cc ] The ccm-aes-ppc4xx now fails one of testmgr's expected failure test cases as such: |decryption failed on test 10 for ccm-aes-ppc4xx: |ret was 0, |expected -EBADMSG It doesn't look like the hardware sets the authentication failure flag. The original vendor source from which this was ported does not have any special code or notes about why this would happen or if there are any WAs. Hence, this patch converts the aead_done callback handler to perform the icv check in the driver. And this fixes the false negative and the ccm-aes-ppc4xx passes the selftests once again. |name : ccm(aes) |driver : ccm-aes-ppc4xx |module : crypto4xx |priority : 300 |refcnt : 1 |selftest : passed |internal : no |type : aead |async : yes |blocksize : 1 |ivsize : 16 |maxauthsize : 16 |geniv : <none> Signed-off-by: Christian Lamparter <chunkeey(a)gmail.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/crypto/amcc/crypto4xx_alg.c | 6 --- drivers/crypto/amcc/crypto4xx_core.c | 54 +++++++++++++++++------------------ 2 files changed, 28 insertions(+), 32 deletions(-) --- a/drivers/crypto/amcc/crypto4xx_alg.c +++ b/drivers/crypto/amcc/crypto4xx_alg.c @@ -256,10 +256,6 @@ static inline bool crypto4xx_aead_need_f if (is_ccm && !(req->iv[0] == 1 || req->iv[0] == 3)) return true; - /* CCM - fix CBC MAC mismatch in special case */ - if (is_ccm && decrypt && !req->assoclen) - return true; - return false; } @@ -330,7 +326,7 @@ int crypto4xx_setkey_aes_ccm(struct cryp sa = (struct dynamic_sa_ctl *) ctx->sa_in; sa->sa_contents.w = SA_AES_CCM_CONTENTS | (keylen << 2); - set_dynamic_sa_command_0(sa, SA_NOT_SAVE_HASH, SA_NOT_SAVE_IV, + set_dynamic_sa_command_0(sa, SA_SAVE_HASH, SA_NOT_SAVE_IV, SA_LOAD_HASH_FROM_SA, SA_LOAD_IV_FROM_STATE, SA_NO_HEADER_PROC, SA_HASH_ALG_CBC_MAC, SA_CIPHER_ALG_AES, --- a/drivers/crypto/amcc/crypto4xx_core.c +++ b/drivers/crypto/amcc/crypto4xx_core.c @@ -570,15 +570,14 @@ static void crypto4xx_aead_done(struct c struct pd_uinfo *pd_uinfo, struct ce_pd *pd) { - struct aead_request *aead_req; - struct crypto4xx_ctx *ctx; + struct aead_request *aead_req = container_of(pd_uinfo->async_req, + struct aead_request, base); struct scatterlist *dst = pd_uinfo->dest_va; + size_t cp_len = crypto_aead_authsize( + crypto_aead_reqtfm(aead_req)); + u32 icv[cp_len]; int err = 0; - aead_req = container_of(pd_uinfo->async_req, struct aead_request, - base); - ctx = crypto_tfm_ctx(aead_req->base.tfm); - if (pd_uinfo->using_sd) { crypto4xx_copy_pkt_to_dst(dev, pd, pd_uinfo, pd->pd_ctl_len.bf.pkt_len, @@ -590,38 +589,39 @@ static void crypto4xx_aead_done(struct c if (pd_uinfo->sa_va->sa_command_0.bf.dir == DIR_OUTBOUND) { /* append icv at the end */ - size_t cp_len = crypto_aead_authsize( - crypto_aead_reqtfm(aead_req)); - u32 icv[cp_len]; - crypto4xx_memcpy_from_le32(icv, pd_uinfo->sr_va->save_digest, cp_len); scatterwalk_map_and_copy(icv, dst, aead_req->cryptlen, cp_len, 1); + } else { + /* check icv at the end */ + scatterwalk_map_and_copy(icv, aead_req->src, + aead_req->assoclen + aead_req->cryptlen - + cp_len, cp_len, 0); + + crypto4xx_memcpy_from_le32(icv, icv, cp_len); + + if (crypto_memneq(icv, pd_uinfo->sr_va->save_digest, cp_len)) + err = -EBADMSG; } crypto4xx_ret_sg_desc(dev, pd_uinfo); if (pd->pd_ctl.bf.status & 0xff) { - if (pd->pd_ctl.bf.status & 0x1) { - /* authentication error */ - err = -EBADMSG; - } else { - if (!__ratelimit(&dev->aead_ratelimit)) { - if (pd->pd_ctl.bf.status & 2) - pr_err("pad fail error\n"); - if (pd->pd_ctl.bf.status & 4) - pr_err("seqnum fail\n"); - if (pd->pd_ctl.bf.status & 8) - pr_err("error _notify\n"); - pr_err("aead return err status = 0x%02x\n", - pd->pd_ctl.bf.status & 0xff); - pr_err("pd pad_ctl = 0x%08x\n", - pd->pd_ctl.bf.pd_pad_ctl); - } - err = -EINVAL; + if (!__ratelimit(&dev->aead_ratelimit)) { + if (pd->pd_ctl.bf.status & 2) + pr_err("pad fail error\n"); + if (pd->pd_ctl.bf.status & 4) + pr_err("seqnum fail\n"); + if (pd->pd_ctl.bf.status & 8) + pr_err("error _notify\n"); + pr_err("aead return err status = 0x%02x\n", + pd->pd_ctl.bf.status & 0xff); + pr_err("pd pad_ctl = 0x%08x\n", + pd->pd_ctl.bf.pd_pad_ctl); } + err = -EINVAL; } if (pd_uinfo->state & PD_ENTRY_BUSY) Patches currently in stable-queue which might be from chunkeey(a)gmail.com are queue-4.15/crypto-crypto4xx-perform-aead-icv-check-in-the-driver.patch

7 years, 2 months

1
0
0 0

Patch "crypto: aes-generic - build with -Os on gcc-7+" 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 crypto: aes-generic - build with -Os on gcc-7+ 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: crypto-aes-generic-build-with-os-on-gcc-7.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Arnd Bergmann <arnd(a)arndb.de> Date: Wed, 3 Jan 2018 23:39:27 +0100 Subject: crypto: aes-generic - build with -Os on gcc-7+ From: Arnd Bergmann <arnd(a)arndb.de> [ Upstream commit 148b974deea927f5dbb6c468af2707b488bfa2de ] While testing other changes, I discovered that gcc-7.2.1 produces badly optimized code for aes_encrypt/aes_decrypt. This is especially true when CONFIG_UBSAN_SANITIZE_ALL is enabled, where it leads to extremely large stack usage that in turn might cause kernel stack overflows: crypto/aes_generic.c: In function 'aes_encrypt': crypto/aes_generic.c:1371:1: warning: the frame size of 4880 bytes is larger than 2048 bytes [-Wframe-larger-than=] crypto/aes_generic.c: In function 'aes_decrypt': crypto/aes_generic.c:1441:1: warning: the frame size of 4864 bytes is larger than 2048 bytes [-Wframe-larger-than=] I verified that this problem exists on all architectures that are supported by gcc-7.2, though arm64 in particular is less affected than the others. I also found that gcc-7.1 and gcc-8 do not show the extreme stack usage but still produce worse code than earlier versions for this file, apparently because of optimization passes that generally provide a substantial improvement in object code quality but understandably fail to find any shortcuts in the AES algorithm. Possible workarounds include a) disabling -ftree-pre and -ftree-sra optimizations, this was an earlier patch I tried, which reliably fixed the stack usage, but caused a serious performance regression in some versions, as later testing found. b) disabling UBSAN on this file or all ciphers, as suggested by Ard Biesheuvel. This would lead to massively better crypto performance in UBSAN-enabled kernels and avoid the stack usage, but there is a concern over whether we should exclude arbitrary files from UBSAN at all. c) Forcing the optimization level in a different way. Similar to a), but rather than deselecting specific optimization stages, this now uses "gcc -Os" for this file, regardless of the CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE/SIZE option. This is a reliable workaround for the stack consumption on all architecture, and I've retested the performance results now on x86, cycles/byte (lower is better) for cbc(aes-generic) with 256 bit keys: -O2 -Os gcc-6.3.1 14.9 15.1 gcc-7.0.1 14.7 15.3 gcc-7.1.1 15.3 14.7 gcc-7.2.1 16.8 15.9 gcc-8.0.0 15.5 15.6 This implements the option c) by enabling forcing -Os on all compiler versions starting with gcc-7.1. As a workaround for PR83356, it would only be needed for gcc-7.2+ with UBSAN enabled, but since it also shows better performance on gcc-7.1 without UBSAN, it seems appropriate to use the faster version here as well. Side note: during testing, I also played with the AES code in libressl, which had a similar performance regression from gcc-6 to gcc-7.2, but was three times slower overall. It might be interesting to investigate that further and possibly port the Linux implementation into that. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356 Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651 Cc: Richard Biener <rguenther(a)suse.de> Cc: Jakub Jelinek <jakub(a)gcc.gnu.org> Cc: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Acked-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- crypto/Makefile | 1 + 1 file changed, 1 insertion(+) --- a/crypto/Makefile +++ b/crypto/Makefile @@ -99,6 +99,7 @@ obj-$(CONFIG_CRYPTO_TWOFISH_COMMON) += t obj-$(CONFIG_CRYPTO_SERPENT) += serpent_generic.o CFLAGS_serpent_generic.o := $(call cc-option,-fsched-pressure) # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149 obj-$(CONFIG_CRYPTO_AES) += aes_generic.o +CFLAGS_aes_generic.o := $(call cc-ifversion, -ge, 0701, -Os) # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356 obj-$(CONFIG_CRYPTO_AES_TI) += aes_ti.o obj-$(CONFIG_CRYPTO_CAMELLIA) += camellia_generic.o obj-$(CONFIG_CRYPTO_CAST_COMMON) += cast_common.o Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.15/crypto-aes-generic-build-with-os-on-gcc-7.patch

7 years, 2 months

1
0
0 0

Patch "clk: sunxi-ng: a83t: Add M divider to TCON1 clock" 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 clk: sunxi-ng: a83t: Add M divider to TCON1 clock 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: clk-sunxi-ng-a83t-add-m-divider-to-tcon1-clock.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: "Jernej Škrabec" <jernej.skrabec(a)siol.net> Date: Sat, 30 Dec 2017 22:01:54 +0100 Subject: clk: sunxi-ng: a83t: Add M divider to TCON1 clock From: "Jernej Škrabec" <jernej.skrabec(a)siol.net> [ Upstream commit 7dbc7f5f4904cfddc199af171ea095490a434f15 ] TCON1 also has M divider, contrary to TCON0. And the mux is only 2 bits wide, instead of 3. Fixes: 05359be1176b ("clk: sunxi-ng: Add driver for A83T CCU") Signed-off-by: Jernej Skrabec <jernej.skrabec(a)siol.net> [wens(a)csie.org: Add description about mux width difference] Signed-off-by: Chen-Yu Tsai <wens(a)csie.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c @@ -493,8 +493,8 @@ static SUNXI_CCU_MUX_WITH_GATE(tcon0_clk 0x118, 24, 3, BIT(31), CLK_SET_RATE_PARENT); static const char * const tcon1_parents[] = { "pll-video1" }; -static SUNXI_CCU_MUX_WITH_GATE(tcon1_clk, "tcon1", tcon1_parents, - 0x11c, 24, 3, BIT(31), CLK_SET_RATE_PARENT); +static SUNXI_CCU_M_WITH_MUX_GATE(tcon1_clk, "tcon1", tcon1_parents, + 0x11c, 0, 4, 24, 2, BIT(31), CLK_SET_RATE_PARENT); static SUNXI_CCU_GATE(csi_misc_clk, "csi-misc", "osc24M", 0x130, BIT(16), 0); Patches currently in stable-queue which might be from jernej.skrabec(a)siol.net are queue-4.15/clk-sunxi-ng-a83t-add-m-divider-to-tcon1-clock.patch

7 years, 2 months

1
0
0 0

Patch "clk: sunxi-ng: fix the A64/H5 clock description of DE2 CCU" 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 clk: sunxi-ng: fix the A64/H5 clock description of DE2 CCU 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: clk-sunxi-ng-fix-the-a64-h5-clock-description-of-de2-ccu.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Icenowy Zheng <icenowy(a)aosc.io> Date: Fri, 22 Dec 2017 20:22:35 +0800 Subject: clk: sunxi-ng: fix the A64/H5 clock description of DE2 CCU From: Icenowy Zheng <icenowy(a)aosc.io> [ Upstream commit cf4881c1293516c1975606e8f2af7948789168b8 ] The clocks of A64/H5 SoCs in the DE2 CCU is the same as the clocks in H3 DE2 CCU rather than the A83T DE2 CCU (the parent of them is the DE module clock). Fix this by change the clock descriptions to use the clocks of H3. Fixes: 763c5bd045b1 ("clk: sunxi-ng: add support for DE2 CCU") Signed-off-by: Icenowy Zheng <icenowy(a)aosc.io> Signed-off-by: Chen-Yu Tsai <wens(a)csie.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/sunxi-ng/ccu-sun8i-de2.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/clk/sunxi-ng/ccu-sun8i-de2.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c @@ -134,10 +134,10 @@ static const struct sunxi_ccu_desc sun8i }; static const struct sunxi_ccu_desc sun50i_a64_de2_clk_desc = { - .ccu_clks = sun8i_a83t_de2_clks, - .num_ccu_clks = ARRAY_SIZE(sun8i_a83t_de2_clks), + .ccu_clks = sun8i_h3_de2_clks, + .num_ccu_clks = ARRAY_SIZE(sun8i_h3_de2_clks), - .hw_clks = &sun8i_a83t_de2_hw_clks, + .hw_clks = &sun8i_h3_de2_hw_clks, .resets = sun50i_a64_de2_resets, .num_resets = ARRAY_SIZE(sun50i_a64_de2_resets), Patches currently in stable-queue which might be from icenowy(a)aosc.io are queue-4.15/clk-sunxi-ng-fix-the-a64-h5-clock-description-of-de2-ccu.patch

7 years, 2 months

1
0
0 0

Patch "clk: meson: mpll: use 64-bit maths in params_from_rate" 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 clk: meson: mpll: use 64-bit maths in params_from_rate 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: clk-meson-mpll-use-64-bit-maths-in-params_from_rate.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> Date: Sat, 23 Dec 2017 22:38:32 +0100 Subject: clk: meson: mpll: use 64-bit maths in params_from_rate From: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> [ Upstream commit 86aacdca66774051cbc0958110a48074b57a060b ] "rem * SDM_DEN" can easily overflow on the 32-bit Meson8 and Meson8b SoCs if the "remainder" (after the division operation) is greater than 262143Hz. This is likely to happen since the input clock for the MPLLs on Meson8 and Meson8b is "fixed_pll", which is running at a rate of 2550MHz. One example where this was observed to be problematic was the Ethernet clock calculation (which takes MPLL2 as input). When requesting a rate of 125MHz there is a remainder of 2500000Hz. The resulting MPLL2 rate before this patch was 127488329Hz. The resulting MPLL2 rate after this patch is 124999103Hz. Commit b609338b26f5 ("clk: meson: mpll: use 64bit math in rate_from_params") already fixed a similar issue in rate_from_params. Fixes: 007e6e5c5f01d3 ("clk: meson: mpll: add rw operation") Signed-off-by: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/meson/clk-mpll.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/clk/meson/clk-mpll.c +++ b/drivers/clk/meson/clk-mpll.c @@ -98,7 +98,7 @@ static void params_from_rate(unsigned lo *sdm = SDM_DEN - 1; } else { *n2 = div; - *sdm = DIV_ROUND_UP(rem * SDM_DEN, requested_rate); + *sdm = DIV_ROUND_UP_ULL((u64)rem * SDM_DEN, requested_rate); } } Patches currently in stable-queue which might be from martin.blumenstingl(a)googlemail.com are queue-4.15/clk-meson-mpll-use-64-bit-maths-in-params_from_rate.patch

7 years, 2 months

1
0
0 0

Patch "clk: divider: fix incorrect usage of container_of" 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 clk: divider: fix incorrect usage of container_of 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: clk-divider-fix-incorrect-usage-of-container_of.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Jerome Brunet <jbrunet(a)baylibre.com> Date: Thu, 21 Dec 2017 17:30:54 +0100 Subject: clk: divider: fix incorrect usage of container_of From: Jerome Brunet <jbrunet(a)baylibre.com> [ Upstream commit 12a26c298d2a8b1cab498533fa65198e49e3afd3 ] divider_recalc_rate() is an helper function used by clock divider of different types, so the structure containing the 'hw' pointer is not always a 'struct clk_divider' At the following line: > div = _get_div(table, val, flags, divider->width); in several cases, the value of 'divider->width' is garbage as the actual structure behind this memory is not a 'struct clk_divider' Fortunately, this width value is used by _get_val() only when CLK_DIVIDER_MAX_AT_ZERO flag is set. This has never been the case so far when the structure is not a 'struct clk_divider'. This is probably why we did not notice this bug before Fixes: afe76c8fd030 ("clk: allow a clk divider with max divisor when zero") Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com> Acked-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com> Acked-by: Sylvain Lemieux <slemieux.tyco(a)gmail.com> Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/clk-divider.c | 7 +++---- drivers/clk/hisilicon/clkdivider-hi6220.c | 2 +- drivers/clk/nxp/clk-lpc32xx.c | 2 +- drivers/clk/qcom/clk-regmap-divider.c | 2 +- drivers/clk/sunxi-ng/ccu_div.c | 2 +- drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c | 2 +- drivers/rtc/rtc-ac100.c | 6 ++++-- include/linux/clk-provider.h | 2 +- 8 files changed, 13 insertions(+), 12 deletions(-) --- a/drivers/clk/clk-divider.c +++ b/drivers/clk/clk-divider.c @@ -118,12 +118,11 @@ static unsigned int _get_val(const struc unsigned long divider_recalc_rate(struct clk_hw *hw, unsigned long parent_rate, unsigned int val, const struct clk_div_table *table, - unsigned long flags) + unsigned long flags, unsigned long width) { - struct clk_divider *divider = to_clk_divider(hw); unsigned int div; - div = _get_div(table, val, flags, divider->width); + div = _get_div(table, val, flags, width); if (!div) { WARN(!(flags & CLK_DIVIDER_ALLOW_ZERO), "%s: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not set\n", @@ -145,7 +144,7 @@ static unsigned long clk_divider_recalc_ val &= div_mask(divider->width); return divider_recalc_rate(hw, parent_rate, val, divider->table, - divider->flags); + divider->flags, divider->width); } static bool _is_valid_table_div(const struct clk_div_table *table, --- a/drivers/clk/hisilicon/clkdivider-hi6220.c +++ b/drivers/clk/hisilicon/clkdivider-hi6220.c @@ -56,7 +56,7 @@ static unsigned long hi6220_clkdiv_recal val &= div_mask(dclk->width); return divider_recalc_rate(hw, parent_rate, val, dclk->table, - CLK_DIVIDER_ROUND_CLOSEST); + CLK_DIVIDER_ROUND_CLOSEST, dclk->width); } static long hi6220_clkdiv_round_rate(struct clk_hw *hw, unsigned long rate, --- a/drivers/clk/nxp/clk-lpc32xx.c +++ b/drivers/clk/nxp/clk-lpc32xx.c @@ -956,7 +956,7 @@ static unsigned long clk_divider_recalc_ val &= div_mask(divider->width); return divider_recalc_rate(hw, parent_rate, val, divider->table, - divider->flags); + divider->flags, divider->width); } static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate, --- a/drivers/clk/qcom/clk-regmap-divider.c +++ b/drivers/clk/qcom/clk-regmap-divider.c @@ -59,7 +59,7 @@ static unsigned long div_recalc_rate(str div &= BIT(divider->width) - 1; return divider_recalc_rate(hw, parent_rate, div, NULL, - CLK_DIVIDER_ROUND_CLOSEST); + CLK_DIVIDER_ROUND_CLOSEST, divider->width); } const struct clk_ops clk_regmap_div_ops = { --- a/drivers/clk/sunxi-ng/ccu_div.c +++ b/drivers/clk/sunxi-ng/ccu_div.c @@ -71,7 +71,7 @@ static unsigned long ccu_div_recalc_rate parent_rate); val = divider_recalc_rate(hw, parent_rate, val, cd->div.table, - cd->div.flags); + cd->div.flags, cd->div.width); if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV) val /= cd->fixed_post_div; --- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c +++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c @@ -698,7 +698,7 @@ static unsigned long dsi_pll_14nm_postdi val &= div_mask(width); return divider_recalc_rate(hw, parent_rate, val, NULL, - postdiv->flags); + postdiv->flags, width); } static long dsi_pll_14nm_postdiv_round_rate(struct clk_hw *hw, --- a/drivers/rtc/rtc-ac100.c +++ b/drivers/rtc/rtc-ac100.c @@ -137,13 +137,15 @@ static unsigned long ac100_clkout_recalc div = (reg >> AC100_CLKOUT_PRE_DIV_SHIFT) & ((1 << AC100_CLKOUT_PRE_DIV_WIDTH) - 1); prate = divider_recalc_rate(hw, prate, div, - ac100_clkout_prediv, 0); + ac100_clkout_prediv, 0, + AC100_CLKOUT_PRE_DIV_WIDTH); } div = (reg >> AC100_CLKOUT_DIV_SHIFT) & (BIT(AC100_CLKOUT_DIV_WIDTH) - 1); return divider_recalc_rate(hw, prate, div, NULL, - CLK_DIVIDER_POWER_OF_TWO); + CLK_DIVIDER_POWER_OF_TWO, + AC100_CLKOUT_DIV_WIDTH); } static long ac100_clkout_round_rate(struct clk_hw *hw, unsigned long rate, --- a/include/linux/clk-provider.h +++ b/include/linux/clk-provider.h @@ -412,7 +412,7 @@ extern const struct clk_ops clk_divider_ unsigned long divider_recalc_rate(struct clk_hw *hw, unsigned long parent_rate, unsigned int val, const struct clk_div_table *table, - unsigned long flags); + unsigned long flags, unsigned long width); long divider_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent, unsigned long rate, unsigned long *prate, const struct clk_div_table *table, Patches currently in stable-queue which might be from jbrunet(a)baylibre.com are queue-4.15/clk-divider-fix-incorrect-usage-of-container_of.patch queue-4.15/clk-meson-mpll-use-64-bit-maths-in-params_from_rate.patch

7 years, 2 months

1
0
0 0

Patch "Bluetooth: hci_bcm: Validate IRQ before using it" 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 Bluetooth: hci_bcm: Validate IRQ before using it 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: bluetooth-hci_bcm-validate-irq-before-using-it.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: "Ronald Tschalär" <ronald(a)innovation.ch> Date: Wed, 10 Jan 2018 16:32:10 +0100 Subject: Bluetooth: hci_bcm: Validate IRQ before using it From: "Ronald Tschalär" <ronald(a)innovation.ch> [ Upstream commit 4a59f1fab91e9445e34c69d8e4401a0d6bdbe914 ] The ->close, ->suspend and ->resume hooks assume presence of a valid IRQ if the device is wakeup capable. However it's entirely possible that wakeup was enabled by some other entity besides this driver and in this case the user will get a WARN splat if no valid IRQ was found. Avoid by checking if the IRQ is valid, i.e. > 0. Case in point: On recent MacBook Pros, the Bluetooth device lacks an IRQ (because host wakeup is handled by the SMC, independently of the operating system), but it does possess a _PRW method (which specifies the SMC's GPE as wake event). The ACPI core therefore automatically marks the physical Bluetooth device wakeup capable upon binding it to its ACPI companion: device_set_wakeup_capable+0x96/0xb0 acpi_bind_one+0x28a/0x310 acpi_platform_notify+0x20/0xa0 device_add+0x215/0x690 serdev_device_add+0x57/0xf0 acpi_serdev_add_device+0xc9/0x110 acpi_ns_walk_namespace+0x131/0x280 acpi_walk_namespace+0xf5/0x13d serdev_controller_add+0x6f/0x110 serdev_tty_port_register+0x98/0xf0 tty_port_register_device_attr_serdev+0x3a/0x70 uart_add_one_port+0x268/0x500 serial8250_register_8250_port+0x32e/0x490 dw8250_probe+0x46c/0x720 platform_drv_probe+0x35/0x90 driver_probe_device+0x300/0x450 bus_for_each_drv+0x67/0xb0 __device_attach+0xde/0x160 bus_probe_device+0x9c/0xb0 device_add+0x448/0x690 platform_device_add+0x10e/0x260 mfd_add_device+0x392/0x4c0 mfd_add_devices+0xb1/0x110 intel_lpss_probe+0x2a9/0x610 [intel_lpss] intel_lpss_pci_probe+0x7a/0xa8 [intel_lpss_pci] Reviewed-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Ronald TschalÃ¤r <ronald(a)innovation.ch> [lukas: fix up ->suspend and ->resume as well, add commit message] Signed-off-by: Lukas Wunner <lukas(a)wunner.de> Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bluetooth/hci_bcm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/bluetooth/hci_bcm.c +++ b/drivers/bluetooth/hci_bcm.c @@ -379,7 +379,7 @@ static int bcm_close(struct hci_uart *hu pm_runtime_disable(bdev->dev); pm_runtime_set_suspended(bdev->dev); - if (device_can_wakeup(bdev->dev)) { + if (bdev->irq > 0) { devm_free_irq(bdev->dev, bdev->irq, bdev); device_init_wakeup(bdev->dev, false); } @@ -628,7 +628,7 @@ static int bcm_suspend(struct device *de if (pm_runtime_active(dev)) bcm_suspend_device(dev); - if (device_may_wakeup(dev)) { + if (device_may_wakeup(dev) && bdev->irq > 0) { error = enable_irq_wake(bdev->irq); if (!error) bt_dev_dbg(bdev, "BCM irq: enabled"); @@ -658,7 +658,7 @@ static int bcm_resume(struct device *dev if (!bdev->hu) goto unlock; - if (device_may_wakeup(dev)) { + if (device_may_wakeup(dev) && bdev->irq > 0) { disable_irq_wake(bdev->irq); bt_dev_dbg(bdev, "BCM irq: disabled"); } Patches currently in stable-queue which might be from ronald(a)innovation.ch are queue-4.15/bluetooth-hci_bcm-validate-irq-before-using-it.patch

7 years, 2 months

1
0
0 0

Patch "Bluetooth: Add a new 04ca:3015 QCA_ROME device" 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 Bluetooth: Add a new 04ca:3015 QCA_ROME device 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: bluetooth-add-a-new-04ca-3015-qca_rome-device.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Ioan Moldovan <ioan.moldovan1999(a)gmail.com> Date: Mon, 28 Aug 2017 18:09:39 +0300 Subject: Bluetooth: Add a new 04ca:3015 QCA_ROME device From: Ioan Moldovan <ioan.moldovan1999(a)gmail.com> [ Upstream commit 0a03f98b98c201191e3ba15a0e33f46d8660e1fd ] This patch adds the 04ca:3015 (from a QCA9377 board) Bluetooth device to the btusb blacklist and makes the kernel use the btqca module instead of btusb. The patch is necessary because, without it the 04ca:3015 device defaults to using the btusb driver, which makes the WIFI side of the QCA9377 board unusable (obtains 0 MBps in speedtest, when the 04ca:3015 bluetooth is used with an audio headset). /sys/kernel/debug/usb/devices: T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3015 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Ioan Moldovan <ioan.moldovan1999(a)gmail.com> Signed-off-by: Johan Hedberg <johan.hedberg(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bluetooth/btusb.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -272,6 +272,7 @@ static const struct usb_device_id blackl { USB_DEVICE(0x0489, 0xe09f), .driver_info = BTUSB_QCA_ROME }, { USB_DEVICE(0x0489, 0xe0a2), .driver_info = BTUSB_QCA_ROME }, { USB_DEVICE(0x04ca, 0x3011), .driver_info = BTUSB_QCA_ROME }, + { USB_DEVICE(0x04ca, 0x3015), .driver_info = BTUSB_QCA_ROME }, { USB_DEVICE(0x04ca, 0x3016), .driver_info = BTUSB_QCA_ROME }, /* Broadcom BCM2035 */ Patches currently in stable-queue which might be from ioan.moldovan1999(a)gmail.com are queue-4.15/bluetooth-add-a-new-04ca-3015-qca_rome-device.patch

7 years, 2 months

1
0
0 0

Patch "block, bfq: put async queues for root bfq groups too" 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 block, bfq: put async queues for root bfq groups too 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: block-bfq-put-async-queues-for-root-bfq-groups-too.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Paolo Valente <paolo.valente(a)linaro.org> Date: Tue, 9 Jan 2018 10:27:58 +0100 Subject: block, bfq: put async queues for root bfq groups too From: Paolo Valente <paolo.valente(a)linaro.org> [ Upstream commit 52257ffbfcaf58d247b13fb148e27ed17c33e526 ] For each pair [device for which bfq is selected as I/O scheduler, group in blkio/io], bfq maintains a corresponding bfq group. Each such bfq group contains a set of async queues, with each async queue created on demand, i.e., when some I/O request arrives for it. On creation, an async queue gets an extra reference, to make sure that the queue is not freed as long as its bfq group exists. Accordingly, to allow the queue to be freed after the group exited, this extra reference must released on group exit. The above holds also for a bfq root group, i.e., for the bfq group corresponding to the root blkio/io root for a given device. Yet, by mistake, the references to the existing async queues of a root group are not released when the latter exits. This causes a memory leak when the instance of bfq for a given device exits. In a similar vein, bfqg_stats_xfer_dead is not executed for a root group. This commit fixes bfq_pd_offline so that the latter executes the above missing operations for a root group too. Reported-by: Holger Hoffstätte <holger(a)applied-asynchrony.com> Reported-by: Guoqing Jiang <gqjiang(a)suse.com> Tested-by: Holger Hoffstätte <holger(a)applied-asynchrony.com> Signed-off-by: Davide Ferrari <davideferrari8(a)gmail.com> Signed-off-by: Paolo Valente <paolo.valente(a)linaro.org> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- block/bfq-cgroup.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/block/bfq-cgroup.c +++ b/block/bfq-cgroup.c @@ -775,10 +775,11 @@ static void bfq_pd_offline(struct blkg_p unsigned long flags; int i; + spin_lock_irqsave(&bfqd->lock, flags); + if (!entity) /* root group */ - return; + goto put_async_queues; - spin_lock_irqsave(&bfqd->lock, flags); /* * Empty all service_trees belonging to this group before * deactivating the group itself. @@ -809,6 +810,8 @@ static void bfq_pd_offline(struct blkg_p } __bfq_deactivate_entity(entity, false); + +put_async_queues: bfq_put_async_queues(bfqd, bfqg); spin_unlock_irqrestore(&bfqd->lock, flags); Patches currently in stable-queue which might be from paolo.valente(a)linaro.org are queue-4.15/block-bfq-put-async-queues-for-root-bfq-groups-too.patch

7 years, 2 months

1
0
0 0

Patch "blk-mq: fix race between updating nr_hw_queues and switching io sched" 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 blk-mq: fix race between updating nr_hw_queues and switching io sched 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: blk-mq-fix-race-between-updating-nr_hw_queues-and-switching-io-sched.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Ming Lei <ming.lei(a)redhat.com> Date: Sat, 6 Jan 2018 16:27:40 +0800 Subject: blk-mq: fix race between updating nr_hw_queues and switching io sched From: Ming Lei <ming.lei(a)redhat.com> [ Upstream commit fb350e0ad99359768e1e80b4784692031ec340e4 ] In both elevator_switch_mq() and blk_mq_update_nr_hw_queues(), sched tags can be allocated, and q->nr_hw_queue is used, and race is inevitable, for example: blk_mq_init_sched() may trigger use-after-free on hctx, which is freed in blk_mq_realloc_hw_ctxs() when nr_hw_queues is decreased. This patch fixes the race be holding q->sysfs_lock. Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reported-by: Yi Zhang <yi.zhang(a)redhat.com> Tested-by: Yi Zhang <yi.zhang(a)redhat.com> Signed-off-by: Ming Lei <ming.lei(a)redhat.com> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- block/blk-mq.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -2388,6 +2388,9 @@ static void blk_mq_realloc_hw_ctxs(struc struct blk_mq_hw_ctx **hctxs = q->queue_hw_ctx; blk_mq_sysfs_unregister(q); + + /* protect against switching io scheduler */ + mutex_lock(&q->sysfs_lock); for (i = 0; i < set->nr_hw_queues; i++) { int node; @@ -2432,6 +2435,7 @@ static void blk_mq_realloc_hw_ctxs(struc } } q->nr_hw_queues = i; + mutex_unlock(&q->sysfs_lock); blk_mq_sysfs_register(q); } Patches currently in stable-queue which might be from ming.lei(a)redhat.com are queue-4.15/blk-mq-avoid-to-map-cpu-into-stale-hw-queue.patch queue-4.15/blk-mq-fix-kernel-oops-in-blk_mq_tag_idle.patch queue-4.15/blk-mq-fix-race-between-updating-nr_hw_queues-and-switching-io-sched.patch

7 years, 2 months

1
0
0 0

Patch "blk-mq: fix kernel oops in blk_mq_tag_idle()" 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 blk-mq: fix kernel oops in blk_mq_tag_idle() 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: blk-mq-fix-kernel-oops-in-blk_mq_tag_idle.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Ming Lei <ming.lei(a)redhat.com> Date: Tue, 9 Jan 2018 21:28:29 +0800 Subject: blk-mq: fix kernel oops in blk_mq_tag_idle() From: Ming Lei <ming.lei(a)redhat.com> [ Upstream commit 8ab0b7dc73e1b3e2987d42554b2bff503f692772 ] HW queues may be unmapped in some cases, such as blk_mq_update_nr_hw_queues(), then we need to check it before calling blk_mq_tag_idle(), otherwise the following kernel oops can be triggered, so fix it by checking if the hw queue is unmapped since it doesn't make sense to idle the tags any more after hw queues are unmapped. [ 440.771298] Workqueue: nvme-wq nvme_rdma_del_ctrl_work [nvme_rdma] [ 440.779104] task: ffff894bae755ee0 ti: ffff893bf9bc8000 task.ti: ffff893bf9bc8000 [ 440.788359] RIP: 0010:[<ffffffffb730e2b4>] [<ffffffffb730e2b4>] __blk_mq_tag_idle+0x24/0x40 [ 440.798697] RSP: 0018:ffff893bf9bcbd10 EFLAGS: 00010286 [ 440.805538] RAX: 0000000000000000 RBX: ffff895bb131dc00 RCX: 000000000000011f [ 440.814426] RDX: 00000000ffffffff RSI: 0000000000000120 RDI: ffff895bb131dc00 [ 440.823301] RBP: ffff893bf9bcbd10 R08: 000000000001b860 R09: 4a51d361c00c0000 [ 440.832193] R10: b5907f32b4cc7003 R11: ffffd6cabfb57000 R12: ffff894bafd1e008 [ 440.841091] R13: 0000000000000001 R14: ffff895baf770000 R15: 0000000000000080 [ 440.849988] FS: 0000000000000000(0000) GS:ffff894bbdcc0000(0000) knlGS:0000000000000000 [ 440.859955] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 440.867274] CR2: 0000000000000008 CR3: 000000103d098000 CR4: 00000000001407e0 [ 440.876169] Call Trace: [ 440.879818] [<ffffffffb7309d68>] blk_mq_exit_hctx+0xd8/0xe0 [ 440.887051] [<ffffffffb730dc40>] blk_mq_free_queue+0xf0/0x160 [ 440.894465] [<ffffffffb72ff679>] blk_cleanup_queue+0xd9/0x150 [ 440.901881] [<ffffffffc08a802b>] nvme_ns_remove+0x5b/0xb0 [nvme_core] [ 440.910068] [<ffffffffc08a811b>] nvme_remove_namespaces+0x3b/0x60 [nvme_core] [ 440.919026] [<ffffffffc08b817b>] __nvme_rdma_remove_ctrl+0x2b/0xb0 [nvme_rdma] [ 440.928079] [<ffffffffc08b8237>] nvme_rdma_del_ctrl_work+0x17/0x20 [nvme_rdma] [ 440.937126] [<ffffffffb70ab58a>] process_one_work+0x17a/0x440 [ 440.944517] [<ffffffffb70ac3a8>] worker_thread+0x278/0x3c0 [ 440.951607] [<ffffffffb70ac130>] ? manage_workers.isra.24+0x2a0/0x2a0 [ 440.959760] [<ffffffffb70b352f>] kthread+0xcf/0xe0 [ 440.966055] [<ffffffffb70b3460>] ? insert_kthread_work+0x40/0x40 [ 440.973715] [<ffffffffb76d8658>] ret_from_fork+0x58/0x90 [ 440.980586] [<ffffffffb70b3460>] ? insert_kthread_work+0x40/0x40 [ 440.988229] Code: 5b 41 5c 5d c3 66 90 0f 1f 44 00 00 48 8b 87 20 01 00 00 f0 0f ba 77 40 01 19 d2 85 d2 75 08 c3 0f 1f 80 00 00 00 00 55 48 89 e5 <f0> ff 48 08 48 8d 78 10 e8 7f 0f 05 00 5d c3 0f 1f 00 66 2e 0f [ 441.011620] RIP [<ffffffffb730e2b4>] __blk_mq_tag_idle+0x24/0x40 [ 441.019301] RSP <ffff893bf9bcbd10> [ 441.024052] CR2: 0000000000000008 Reported-by: Zhang Yi <yizhan(a)redhat.com> Tested-by: Zhang Yi <yizhan(a)redhat.com> Signed-off-by: Ming Lei <ming.lei(a)redhat.com> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- block/blk-mq.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -1996,7 +1996,8 @@ static void blk_mq_exit_hctx(struct requ { blk_mq_debugfs_unregister_hctx(hctx); - blk_mq_tag_idle(hctx); + if (blk_mq_hw_queue_mapped(hctx)) + blk_mq_tag_idle(hctx); if (set->ops->exit_request) set->ops->exit_request(set, hctx->fq->flush_rq, hctx_idx); Patches currently in stable-queue which might be from ming.lei(a)redhat.com are queue-4.15/blk-mq-avoid-to-map-cpu-into-stale-hw-queue.patch queue-4.15/blk-mq-fix-kernel-oops-in-blk_mq_tag_idle.patch queue-4.15/blk-mq-fix-race-between-updating-nr_hw_queues-and-switching-io-sched.patch

7 years, 2 months

1
0
0 0

Patch "blk-mq: avoid to map CPU into stale hw queue" 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 blk-mq: avoid to map CPU into stale hw queue 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: blk-mq-avoid-to-map-cpu-into-stale-hw-queue.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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Ming Lei <ming.lei(a)redhat.com> Date: Sat, 6 Jan 2018 16:27:39 +0800 Subject: blk-mq: avoid to map CPU into stale hw queue From: Ming Lei <ming.lei(a)redhat.com> [ Upstream commit 7d4901a90d02500c8011472a060f9b2e60e6e605 ] blk_mq_pci_map_queues() may not map one CPU into any hw queue, but its previous map isn't cleared yet, and may point to one stale hw queue index. This patch fixes the following issue by clearing the mapping table before setting it up in blk_mq_pci_map_queues(). This patches fixes this following issue reported by Zhang Yi: [ 101.202734] BUG: unable to handle kernel NULL pointer dereference at 0000000094d3013f [ 101.211487] IP: blk_mq_map_swqueue+0xbc/0x200 [ 101.216346] PGD 0 P4D 0 [ 101.219171] Oops: 0000 [#1] SMP [ 101.222674] Modules linked in: sunrpc ipmi_ssif vfat fat intel_rapl sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel intel_cstate intel_uncore mxm_wmi intel_rapl_perf iTCO_wdt ipmi_si ipmi_devintf pcspkr iTCO_vendor_support sg dcdbas ipmi_msghandler wmi mei_me lpc_ich shpchp mei acpi_power_meter dm_multipath ip_tables xfs libcrc32c sd_mod mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm ahci libahci crc32c_intel libata tg3 nvme nvme_core megaraid_sas ptp i2c_core pps_core dm_mirror dm_region_hash dm_log dm_mod [ 101.284881] CPU: 0 PID: 504 Comm: kworker/u25:5 Not tainted 4.15.0-rc2 #1 [ 101.292455] Hardware name: Dell Inc. PowerEdge R730xd/072T6D, BIOS 2.5.5 08/16/2017 [ 101.301001] Workqueue: nvme-wq nvme_reset_work [nvme] [ 101.306636] task: 00000000f2c53190 task.stack: 000000002da874f9 [ 101.313241] RIP: 0010:blk_mq_map_swqueue+0xbc/0x200 [ 101.318681] RSP: 0018:ffffc9000234fd70 EFLAGS: 00010282 [ 101.324511] RAX: ffff88047ffc9480 RBX: ffff88047e130850 RCX: 0000000000000000 [ 101.332471] RDX: ffffe8ffffd40580 RSI: ffff88047e509b40 RDI: ffff88046f37a008 [ 101.340432] RBP: 000000000000000b R08: ffff88046f37a008 R09: 0000000011f94280 [ 101.348392] R10: ffff88047ffd4d00 R11: 0000000000000000 R12: ffff88046f37a008 [ 101.356353] R13: ffff88047e130f38 R14: 000000000000000b R15: ffff88046f37a558 [ 101.364314] FS: 0000000000000000(0000) GS:ffff880277c00000(0000) knlGS:0000000000000000 [ 101.373342] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 101.379753] CR2: 0000000000000098 CR3: 000000047f409004 CR4: 00000000001606f0 [ 101.387714] Call Trace: [ 101.390445] blk_mq_update_nr_hw_queues+0xbf/0x130 [ 101.395791] nvme_reset_work+0x6f4/0xc06 [nvme] [ 101.400848] ? pick_next_task_fair+0x290/0x5f0 [ 101.405807] ? __switch_to+0x1f5/0x430 [ 101.409988] ? put_prev_entity+0x2f/0xd0 [ 101.414365] process_one_work+0x141/0x340 [ 101.418836] worker_thread+0x47/0x3e0 [ 101.422921] kthread+0xf5/0x130 [ 101.426424] ? rescuer_thread+0x380/0x380 [ 101.430896] ? kthread_associate_blkcg+0x90/0x90 [ 101.436048] ret_from_fork+0x1f/0x30 [ 101.440034] Code: 48 83 3c ca 00 0f 84 2b 01 00 00 48 63 cd 48 8b 93 10 01 00 00 8b 0c 88 48 8b 83 20 01 00 00 4a 03 14 f5 60 04 af 81 48 8b 0c c8 <48> 8b 81 98 00 00 00 f0 4c 0f ab 30 8b 81 f8 00 00 00 89 42 44 [ 101.461116] RIP: blk_mq_map_swqueue+0xbc/0x200 RSP: ffffc9000234fd70 [ 101.468205] CR2: 0000000000000098 [ 101.471907] ---[ end trace 5fe710f98228a3ca ]--- [ 101.482489] Kernel panic - not syncing: Fatal exception [ 101.488505] Kernel Offset: disabled [ 101.497752] ---[ end Kernel panic - not syncing: Fatal exception Reviewed-by: Christoph Hellwig <hch(a)lst.de> Suggested-by: Christoph Hellwig <hch(a)lst.de> Reported-by: Yi Zhang <yi.zhang(a)redhat.com> Tested-by: Yi Zhang <yi.zhang(a)redhat.com> Signed-off-by: Ming Lei <ming.lei(a)redhat.com> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- block/blk-mq.c | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -2603,9 +2603,27 @@ static int blk_mq_alloc_rq_maps(struct b static int blk_mq_update_queue_map(struct blk_mq_tag_set *set) { - if (set->ops->map_queues) + if (set->ops->map_queues) { + int cpu; + /* + * transport .map_queues is usually done in the following + * way: + * + * for (queue = 0; queue < set->nr_hw_queues; queue++) { + * mask = get_cpu_mask(queue) + * for_each_cpu(cpu, mask) + * set->mq_map[cpu] = queue; + * } + * + * When we need to remap, the table has to be cleared for + * killing stale mapping since one CPU may not be mapped + * to any hw queue. + */ + for_each_possible_cpu(cpu) + set->mq_map[cpu] = 0; + return set->ops->map_queues(set); - else + } else return blk_mq_map_queues(set); } Patches currently in stable-queue which might be from ming.lei(a)redhat.com are queue-4.15/blk-mq-avoid-to-map-cpu-into-stale-hw-queue.patch queue-4.15/blk-mq-fix-kernel-oops-in-blk_mq_tag_idle.patch queue-4.15/blk-mq-fix-race-between-updating-nr_hw_queues-and-switching-io-sched.patch

7 years, 2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror