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

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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror