* patch "serial: exar: Fix stuck MSIs" added to tty-linus
From: gregkh @ 2017-05-18 14:44 UTC (permalink / raw)
To: jan.kiszka, andriy.shevchenko, gregkh, stable
This is a note to let you know that I've just added the patch titled
serial: exar: Fix stuck MSIs
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 2c0ac5b48a3586f612b85755b041ed7733dc8e6b Mon Sep 17 00:00:00 2001
From: Jan Kiszka <jan.kiszka@siemens.com>
Date: Mon, 24 Apr 2017 12:30:15 +0200
Subject: serial: exar: Fix stuck MSIs
After migrating 8250_exar to MSI in 172c33cb61da, we can get stuck
without further interrupts because of the special wake-up event these
chips send. They are only cleared by reading INT0. As we fail to do so
during startup and shutdown, we can leave the interrupt line asserted,
which is fatal with edge-triggered MSIs.
Add the required reading of INT0 to startup and shutdown. Also account
for the fact that a pending wake-up interrupt means we have to return 1
from exar_handle_irq. Drop the unneeded reading of INT1..3 along with
this - those never reset anything.
An alternative approach would have been disabling the wake-up interrupt.
Unfortunately, this feature (REGB[17] = 1) is not available on the
XR17D15X.
Fixes: 172c33cb61da ("serial: exar: Enable MSI support")
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serial/8250/8250_port.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index e7765f010fe8..68fd045a7025 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -47,6 +47,7 @@
/*
* These are definitions for the Exar XR17V35X and XR17(C|D)15X
*/
+#define UART_EXAR_INT0 0x80
#define UART_EXAR_SLEEP 0x8b /* Sleep mode */
#define UART_EXAR_DVID 0x8d /* Device identification */
@@ -1869,17 +1870,13 @@ static int serial8250_default_handle_irq(struct uart_port *port)
static int exar_handle_irq(struct uart_port *port)
{
unsigned int iir = serial_port_in(port, UART_IIR);
- int ret;
+ int ret = 0;
- ret = serial8250_handle_irq(port, iir);
+ if (((port->type == PORT_XR17V35X) || (port->type == PORT_XR17D15X)) &&
+ serial_port_in(port, UART_EXAR_INT0) != 0)
+ ret = 1;
- if ((port->type == PORT_XR17V35X) ||
- (port->type == PORT_XR17D15X)) {
- serial_port_in(port, 0x80);
- serial_port_in(port, 0x81);
- serial_port_in(port, 0x82);
- serial_port_in(port, 0x83);
- }
+ ret |= serial8250_handle_irq(port, iir);
return ret;
}
@@ -2177,6 +2174,8 @@ int serial8250_do_startup(struct uart_port *port)
serial_port_in(port, UART_RX);
serial_port_in(port, UART_IIR);
serial_port_in(port, UART_MSR);
+ if ((port->type == PORT_XR17V35X) || (port->type == PORT_XR17D15X))
+ serial_port_in(port, UART_EXAR_INT0);
/*
* At this point, there's no way the LSR could still be 0xff;
@@ -2335,6 +2334,8 @@ int serial8250_do_startup(struct uart_port *port)
serial_port_in(port, UART_RX);
serial_port_in(port, UART_IIR);
serial_port_in(port, UART_MSR);
+ if ((port->type == PORT_XR17V35X) || (port->type == PORT_XR17D15X))
+ serial_port_in(port, UART_EXAR_INT0);
up->lsr_saved_flags = 0;
up->msr_saved_flags = 0;
--
2.13.0
^ permalink raw reply related
* Re: FAILED: patch "[PATCH] libnvdimm: fix clear length of nvdimm_forget_poison()" failed to apply to 4.11-stable tree
From: Kani, Toshimitsu @ 2017-05-18 14:43 UTC (permalink / raw)
To: dan.j.williams@intel.com, dave.jiang@intel.com,
gregkh@linuxfoundation.org, stable@vger.kernel.org,
vishal.l.verma@intel.com
In-Reply-To: <149509916324377@kroah.com>
On Thu, 2017-05-18 at 11:19 +0200, gregkh@linuxfoundation.org wrote:
> The patch below does not apply to the 4.11-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git
> commit id to <stable@vger.kernel.org>.
Sorry for the trouble. The func name has changed in 4.12. I will send
a patch that can be applied to pre-4.12 trees.
Thanks,
-Toshi
>
> thanks,
>
> greg k-h
>
> ------------------ original commit in Linus's tree ------------------
>
> From 8d13c0290655b883df9083a2a0af0d782bc38aef Mon Sep 17 00:00:00
> 2001
> From: Toshi Kani <toshi.kani@hpe.com>
> Date: Thu, 27 Apr 2017 16:57:05 -0600
> Subject: [PATCH] libnvdimm: fix clear length of
> nvdimm_forget_poison()
>
> ND_CMD_CLEAR_ERROR command returns 'clear_err.cleared', the length
> of error actually cleared, which may be smaller than its requested
> 'len'.
>
> Change nvdimm_clear_poison() to call nvdimm_forget_poison() with
> 'clear_err.cleared' when this value is valid.
>
> Cc: <stable@vger.kernel.org>
> Fixes: e046114af5fc ("libnvdimm: clear the internal poison_list when
> clearing badblocks")
> Cc: Dave Jiang <dave.jiang@intel.com>
> Cc: Vishal Verma <vishal.l.verma@intel.com>
> Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>
> diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c
> index d214ac44d111..43ddfd487c85 100644
> --- a/drivers/nvdimm/bus.c
> +++ b/drivers/nvdimm/bus.c
> @@ -219,7 +219,9 @@ long nvdimm_clear_poison(struct device *dev,
> phys_addr_t phys,
> if (cmd_rc < 0)
> return cmd_rc;
>
> - nvdimm_forget_poison(nvdimm_bus, phys, len);
> + if (clear_err.cleared > 0)
> + nvdimm_forget_poison(nvdimm_bus, phys,
> clear_err.cleared);
> +
> return clear_err.cleared;
> }
> EXPORT_SYMBOL_GPL(nvdimm_clear_poison);
>
^ permalink raw reply
* patch "serdev: fix tty-port client deregistration" added to tty-linus
From: gregkh @ 2017-05-18 14:42 UTC (permalink / raw)
To: johan, gregkh, robh, stable
This is a note to let you know that I've just added the patch titled
serdev: fix tty-port client deregistration
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From aee5da7838787f8ed47f825dbe09e2812acdf97b Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan@kernel.org>
Date: Tue, 11 Apr 2017 19:07:29 +0200
Subject: serdev: fix tty-port client deregistration
The port client data must be set when registering the serdev controller
or client deregistration will fail (and the serdev devices are left
registered and allocated) if the port was never opened in between.
Make sure to clear the port client data on any probe errors to avoid a
use-after-free when the client is later deregistered unconditionally
(e.g. in a tty-port deregistration helper).
Also move port client operation initialisation to registration. Note
that the client ops must be restored on failed probe.
Fixes: bed35c6dfa6a ("serdev: add a tty port controller driver")
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serdev/serdev-ttyport.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serdev/serdev-ttyport.c b/drivers/tty/serdev/serdev-ttyport.c
index 487c88f6aa0e..013efffd2e82 100644
--- a/drivers/tty/serdev/serdev-ttyport.c
+++ b/drivers/tty/serdev/serdev-ttyport.c
@@ -102,9 +102,6 @@ static int ttyport_open(struct serdev_controller *ctrl)
return PTR_ERR(tty);
serport->tty = tty;
- serport->port->client_ops = &client_ops;
- serport->port->client_data = ctrl;
-
if (tty->ops->open)
tty->ops->open(serport->tty, NULL);
else
@@ -215,6 +212,7 @@ struct device *serdev_tty_port_register(struct tty_port *port,
struct device *parent,
struct tty_driver *drv, int idx)
{
+ const struct tty_port_client_operations *old_ops;
struct serdev_controller *ctrl;
struct serport *serport;
int ret;
@@ -233,15 +231,22 @@ struct device *serdev_tty_port_register(struct tty_port *port,
ctrl->ops = &ctrl_ops;
+ old_ops = port->client_ops;
+ port->client_ops = &client_ops;
+ port->client_data = ctrl;
+
ret = serdev_controller_add(ctrl);
if (ret)
- goto err_controller_put;
+ goto err_reset_data;
dev_info(&ctrl->dev, "tty port %s%d registered\n", drv->name, idx);
return &ctrl->dev;
-err_controller_put:
+err_reset_data:
+ port->client_data = NULL;
+ port->client_ops = old_ops;
serdev_controller_put(ctrl);
+
return ERR_PTR(ret);
}
--
2.13.0
^ permalink raw reply related
* patch "Revert "tty_port: register tty ports with serdev bus"" added to tty-linus
From: gregkh @ 2017-05-18 14:42 UTC (permalink / raw)
To: johan, gregkh, robh, stable
This is a note to let you know that I've just added the patch titled
Revert "tty_port: register tty ports with serdev bus"
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From d3ba126a226a6b6da021ebfea444a2a807cde945 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan@kernel.org>
Date: Tue, 11 Apr 2017 19:07:28 +0200
Subject: Revert "tty_port: register tty ports with serdev bus"
This reverts commit 8ee3fde047589dc9c201251f07d0ca1dc776feca.
The new serdev bus hooked into the tty layer in
tty_port_register_device() by registering a serdev controller instead of
a tty device whenever a serdev client is present, and by deregistering
the controller in the tty-port destructor. This is broken in several
ways:
Firstly, it leads to a NULL-pointer dereference whenever a tty driver
later deregisters its devices as no corresponding character device will
exist.
Secondly, far from every tty driver uses tty-port refcounting (e.g.
serial core) so the serdev devices might never be deregistered or
deallocated.
Thirdly, deregistering at tty-port destruction is too late as the
underlying device and structures may be long gone by then. A port is not
released before an open tty device is closed, something which a
registered serdev client can prevent from ever happening. A driver
callback while the device is gone typically also leads to crashes.
Many tty drivers even keep their ports around until the driver is
unloaded (e.g. serial core), something which even if a late callback
never happens, leads to leaks if a device is unbound from its driver and
is later rebound.
The right solution here is to add a new tty_port_unregister_device()
helper and to never call tty_device_unregister() whenever the port has
been claimed by serdev, but since this requires modifying just about
every tty driver (and multiple subsystems) it will need to be done
incrementally.
Reverting the offending patch is the first step in fixing the broken
lifetime assumptions. A follow-up patch will add a new pair of
tty-device registration helpers, which a vetted tty driver can use to
support serdev (initially serial core). When every tty driver uses the
serdev helpers (at least for deregistration), we can add serdev
registration to tty_port_register_device() again.
Note that this also fixes another issue with serdev, which currently
allocates and registers a serdev controller for every tty device
registered using tty_port_device_register() only to immediately
deregister and deallocate it when the corresponding OF node or serdev
child node is missing. This should be addressed before enabling serdev
for hot-pluggable buses.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/tty_port.c | 12 ------------
1 file changed, 12 deletions(-)
diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index 1d21a9c1d33e..0c880f17d27e 100644
--- a/drivers/tty/tty_port.c
+++ b/drivers/tty/tty_port.c
@@ -16,7 +16,6 @@
#include <linux/bitops.h>
#include <linux/delay.h>
#include <linux/module.h>
-#include <linux/serdev.h>
static int tty_port_default_receive_buf(struct tty_port *port,
const unsigned char *p,
@@ -129,15 +128,7 @@ struct device *tty_port_register_device_attr(struct tty_port *port,
struct device *device, void *drvdata,
const struct attribute_group **attr_grp)
{
- struct device *dev;
-
tty_port_link_device(port, driver, index);
-
- dev = serdev_tty_port_register(port, device, driver, index);
- if (PTR_ERR(dev) != -ENODEV)
- /* Skip creating cdev if we registered a serdev device */
- return dev;
-
return tty_register_device_attr(driver, index, device, drvdata,
attr_grp);
}
@@ -189,9 +180,6 @@ static void tty_port_destructor(struct kref *kref)
/* check if last port ref was dropped before tty release */
if (WARN_ON(port->itty))
return;
-
- serdev_tty_port_unregister(port);
-
if (port->xmit_buf)
free_page((unsigned long)port->xmit_buf);
tty_port_destroy(port);
--
2.13.0
^ permalink raw reply related
* patch "drivers/tty: 8250: only call fintek_8250_probe when doing port I/O" added to tty-linus
From: gregkh @ 2017-05-18 14:40 UTC (permalink / raw)
To: ard.biesheuvel, arnd, gregkh, ricardo.ribalda, stable
This is a note to let you know that I've just added the patch titled
drivers/tty: 8250: only call fintek_8250_probe when doing port I/O
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 4c4fc90964b1cf205a67df566cc82ea1731bcb00 Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Thu, 18 May 2017 12:29:55 +0100
Subject: drivers/tty: 8250: only call fintek_8250_probe when doing port I/O
Commit fa01e2ca9f53 ("serial: 8250: Integrate Fintek into 8250_base")
modified the probing logic for PNP0501 devices, to remove a collision
between the generic 16550A driver and the Fintek driver, which reused
the same ACPI _HID.
The Fintek device probe is now incorporated into the common 8250 probe
path, and gets called for all discovered 16550A compatible devices,
including ones that are MMIO mapped rather than IO mapped. However,
the Fintek driver assumes the port base is a I/O address, and proceeds
to probe some arbitrary offsets above it.
This is generally a wrong thing to do, but on ARM systems (having no
native port I/O), this may result in faulting accesses of completely
unrelated MMIO regions in the PCI I/O space. Given that this is at
serial probe time, this results in hard to diagnose crashes at boot.
So let's restrict the Fintek probe to devices that we know are using
port I/O in the first place.
Fixes: fa01e2ca9f53 ("serial: 8250: Integrate Fintek into 8250_base")
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Ricardo Ribalda <ricardo.ribalda@gmail.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serial/8250/8250_port.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 09a65a3ec7f7..e7765f010fe8 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -1337,7 +1337,7 @@ static void autoconfig(struct uart_8250_port *up)
/*
* Check if the device is a Fintek F81216A
*/
- if (port->type == PORT_16550A)
+ if (port->type == PORT_16550A && port->iotype == UPIO_PORT)
fintek_8250_probe(up);
if (up->capabilities != old_capabilities) {
--
2.13.0
^ permalink raw reply related
* Re: Patch "net/ipv6: add sysctl option accept_ra_min_hop_limit" has been added to the 3.18-stable tree
From: Amit Pundir @ 2017-05-18 14:08 UTC (permalink / raw)
To: Greg KH
Cc: 吉藤英明, Hangbin Liu, David Miller,
stable, stable-commits, YOSHIFUJI Hideaki
In-Reply-To: <20170518130527.GA24424@kroah.com>
On 18 May 2017 at 18:35, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Thu, May 18, 2017 at 09:39:12PM +0900, 吉藤英明 wrote:
>> Hi,
>>
>> 2017-05-18 21:22 GMT+09:00 <gregkh@linuxfoundation.org>:
>> >
>> >
>> > This is a note to let you know that I've just added the patch titled
>> >
>> > net/ipv6: add sysctl option accept_ra_min_hop_limit
>> >
>> > to the 3.18-stable tree which can be found at:
>> > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
>> >
>> > The filename of the patch is:
>> > net-ipv6-add-sysctl-option-accept_ra_min_hop_limit.patch
>> > and it can be found in the queue-3.18 subdirectory.
>> >
>> > If you, or anyone else, feels it should not be added to the stable tree,
>> > please let <stable@vger.kernel.org> know about it.
>> >
>> >
>> > From 8013d1d7eafb0589ca766db6b74026f76b7f5cb4 Mon Sep 17 00:00:00 2001
>> > From: Hangbin Liu <liuhangbin@gmail.com>
>> > Date: Thu, 30 Jul 2015 14:28:42 +0800
>> > Subject: net/ipv6: add sysctl option accept_ra_min_hop_limit
>> >
>> > From: Hangbin Liu <liuhangbin@gmail.com>
>> >
>> > commit 8013d1d7eafb0589ca766db6b74026f76b7f5cb4 upstream.
>> >
>> > Commit 6fd99094de2b ("ipv6: Don't reduce hop limit for an interface")
>> > disabled accept hop limit from RA if it is smaller than the current hop
>> > limit for security stuff. But this behavior kind of break the RFC definition.
>> >
>> > RFC 4861, 6.3.4. Processing Received Router Advertisements
>> > A Router Advertisement field (e.g., Cur Hop Limit, Reachable Time,
>> > and Retrans Timer) may contain a value denoting that it is
>> > unspecified. In such cases, the parameter should be ignored and the
>> > host should continue using whatever value it is already using.
>> >
>> > If the received Cur Hop Limit value is non-zero, the host SHOULD set
>> > its CurHopLimit variable to the received value.
>> >
>> > So add sysctl option accept_ra_min_hop_limit to let user choose the minimum
>> > hop limit value they can accept from RA. And set default to 1 to meet RFC
>> > standards.
>> >
>> > Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
>> > Acked-by: YOSHIFUJI Hideaki <hideaki.yoshifuji@miraclelinux.com>
>> > Signed-off-by: David S. Miller <davem@davemloft.net>
>> > Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
>> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> > ---
>> > Documentation/networking/ip-sysctl.txt | 8 ++++++++
>> > include/linux/ipv6.h | 1 +
>> > include/uapi/linux/ipv6.h | 1 +
>> > net/ipv6/addrconf.c | 10 ++++++++++
>> > net/ipv6/ndisc.c | 16 +++++++---------
>> > 5 files changed, 27 insertions(+), 9 deletions(-)
>> >
>> > --- a/Documentation/networking/ip-sysctl.txt
>> > +++ b/Documentation/networking/ip-sysctl.txt
>> > @@ -1256,6 +1256,14 @@ accept_ra_from_local - BOOLEAN
>> > disabled if accept_ra_from_local is disabled
>> > on a specific interface.
>> >
>> > +accept_ra_min_hop_limit - INTEGER
>> > + Minimum hop limit Information in Router Advertisement.
>> > +
>> > + Hop limit Information in Router Advertisement less than this
>> > + variable shall be ignored.
>> > +
>> > + Default: 1
>> > +
>> > accept_ra_pinfo - BOOLEAN
>> > Learn Prefix Information in Router Advertisement.
>> >
>> > --- a/include/linux/ipv6.h
>> > +++ b/include/linux/ipv6.h
>> > @@ -29,6 +29,7 @@ struct ipv6_devconf {
>> > __s32 max_desync_factor;
>> > __s32 max_addresses;
>> > __s32 accept_ra_defrtr;
>> > + __s32 accept_ra_min_hop_limit;
>> > __s32 accept_ra_pinfo;
>> > #ifdef CONFIG_IPV6_ROUTER_PREF
>> > __s32 accept_ra_rtr_pref;
>> > --- a/include/uapi/linux/ipv6.h
>> > +++ b/include/uapi/linux/ipv6.h
>> > @@ -164,6 +164,7 @@ enum {
>> > DEVCONF_MLDV2_UNSOLICITED_REPORT_INTERVAL,
>> > DEVCONF_SUPPRESS_FRAG_NDISC,
>> > DEVCONF_ACCEPT_RA_FROM_LOCAL,
>> > + DEVCONF_ACCEPT_RA_MIN_HOP_LIMIT,
>> > DEVCONF_MAX
>> > };
>> >
>>
>> Please do not do this. This is not compatible with current
>> linus-tree.
>>
>> >From Linux 4.11:
>> DEVCONF_SUPPRESS_FRAG_NDISC,
>> DEVCONF_ACCEPT_RA_FROM_LOCAL,
>> DEVCONF_USE_OPTIMISTIC,
>> DEVCONF_ACCEPT_RA_MTU,
>> DEVCONF_STABLE_SECRET,
>> DEVCONF_USE_OIF_ADDRS_ONLY,
>> DEVCONF_ACCEPT_RA_MIN_HOP_LIMIT,
>> DEVCONF_IGNORE_ROUTES_WITH_LINKDOWN,
>
> Oh, nice catch. I'll go drop this.
>
> Amit, can you send the _correct_ patch? Looks like Google messed up on
> their backport :)
Hi,
Thanks for catching this. Please drop this one. This is not an AOSP
backport, I just didn't think this one through.
Regards,
Amit Pundir
>
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [PATCH 1/2] nvme: fix race between removing and reseting failure
From: Keith Busch @ 2017-05-18 14:13 UTC (permalink / raw)
To: Ming Lei
Cc: Jens Axboe, Christoph Hellwig, Sagi Grimberg, linux-nvme,
Zhang Yi, linux-block, stable
In-Reply-To: <20170517012729.13469-2-ming.lei@redhat.com>
On Wed, May 17, 2017 at 09:27:28AM +0800, Ming Lei wrote:
> When one NVMe PCI device is being resetted and found reset failue,
> nvme_remove_dead_ctrl() is called to handle the failure: blk-mq hw queues
> are put into stopped first, then schedule .remove_work to release the driver.
>
> Unfortunately if the driver is being released via sysfs store
> just before the .remove_work is run, del_gendisk() from
> nvme_remove() may hang forever because hw queues are stopped and
> the submitted writeback IOs from fsync_bdev() can't be completed at all.
>
> This patch fixes the following issue[1][2] by moving nvme_kill_queues()
> into nvme_remove_dead_ctrl() to avoid the issue because nvme_remove()
> flushs .reset_work, and this way is reasonable and safe because
> nvme_dev_disable() has started to suspend queues and canceled requests
> already.
I'm still not sure moving where we kill the queues is the correct way
to fix this problem. The nvme_kill_queues restarts all the hardware
queues to force all IO to failure already, so why is this really stuck?
We should be able to make forward progress even if we kill the queues
while calling into del_gendisk, right? That could happen with a different
sequence of events, so that also needs to work.
^ permalink raw reply
* Re: Build failures in v4.1.y-stable-queue
From: alexander.levin @ 2017-05-18 13:39 UTC (permalink / raw)
To: Guenter Roeck; +Cc: stable
In-Reply-To: <09ab5966-667f-92c4-d9cf-35386e43bf0f@roeck-us.net>
On Wed, May 17, 2017 at 02:18:30AM -0700, Guenter Roeck wrote:
> This is probably not a complete list.
>
>
> drivers/usb/gadget/function/f_hid.c: In function 'f_hidg_read':
> drivers/usb/gadget/function/f_hid.c:253:4: error: implicit declaration of function 'free_ep_req'
>
> drivers/tty/serial/atmel_serial.c: In function 'atmel_flush_buffer':
> drivers/tty/serial/atmel_serial.c:1872:12: error: 'struct atmel_uart_port' has no member named 'tx_len'
>
> arch/mips/mm/tlbex.c: In function 'build_huge_handler_tail':
> arch/mips/mm/tlbex.c:763:6: error: 'cpu_has_ftlb' undeclared (first use in this function)
>
> arch/nios2/kernel/setup.c: In function ‘setup_arch’:
> arch/nios2/kernel/setup.c:198:2: error: implicit declaration of function ‘early_init_fdt_reserve_self’
>
> In file included from arch/um/os-Linux/aio.c:13:0:
> build/arch/um/include/shared/init.h:129:26: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘__used’
>
Should be fixed now (plus a few more), thanks Guenter!
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH 2/2] nvme: avoid to hang in remove disk
From: Christoph Hellwig @ 2017-05-18 13:49 UTC (permalink / raw)
To: Ming Lei
Cc: Jens Axboe, Keith Busch, Christoph Hellwig, Sagi Grimberg,
linux-nvme, Zhang Yi, linux-block, stable
In-Reply-To: <20170517012729.13469-3-ming.lei@redhat.com>
On Wed, May 17, 2017 at 09:27:29AM +0800, Ming Lei wrote:
> If some writeback requests are submitted just before queue is killed,
> and these requests may not be canceled in nvme_dev_disable() because
> they are not started yet, it is still possible for blk-mq to hold
> these requests in .requeue list.
>
> So we have to abort these requests first before del_gendisk(), because
> del_gendisk() may wait for completion of these requests.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Ming Lei <ming.lei@redhat.com>
> ---
> drivers/nvme/host/core.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index d5e0906262ea..8eaeea86509a 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -2097,6 +2097,14 @@ static void nvme_ns_remove(struct nvme_ns *ns)
> &nvme_ns_attr_group);
> if (ns->ndev)
> nvme_nvm_unregister_sysfs(ns);
> + /*
> + * If queue is dead, we have to abort requests in
> + * requeue list because fsync_bdev() in removing disk
> + * path may wait for these IOs, which can't
> + * be submitted to hardware too.
> + */
> + if (blk_queue_dying(ns->queue))
> + blk_mq_abort_requeue_list(ns->queue);
> del_gendisk(ns->disk);
> blk_mq_abort_requeue_list(ns->queue);
Why can't we just move the blk_mq_abort_requeue_list call before
del_gendisk in general?
^ permalink raw reply
* Re: [PATCH 1/2] nvme: fix race between removing and reseting failure
From: Christoph Hellwig @ 2017-05-18 13:47 UTC (permalink / raw)
To: Ming Lei
Cc: Jens Axboe, Keith Busch, Christoph Hellwig, Sagi Grimberg,
linux-nvme, Zhang Yi, linux-block, stable
In-Reply-To: <20170517012729.13469-2-ming.lei@redhat.com>
On Wed, May 17, 2017 at 09:27:28AM +0800, Ming Lei wrote:
> When one NVMe PCI device is being resetted and found reset failue,
> nvme_remove_dead_ctrl() is called to handle the failure: blk-mq hw queues
> are put into stopped first, then schedule .remove_work to release the driver.
>
> Unfortunately if the driver is being released via sysfs store
> just before the .remove_work is run, del_gendisk() from
> nvme_remove() may hang forever because hw queues are stopped and
> the submitted writeback IOs from fsync_bdev() can't be completed at all.
>
> This patch fixes the following issue[1][2] by moving nvme_kill_queues()
> into nvme_remove_dead_ctrl() to avoid the issue because nvme_remove()
> flushs .reset_work, and this way is reasonable and safe because
> nvme_dev_disable() has started to suspend queues and canceled requests
> already.
>
> [1] test script
> fio -filename=$NVME_DISK -iodepth=1 -thread -rw=randwrite -ioengine=psync \
> -bssplit=5k/10:9k/10:13k/10:17k/10:21k/10:25k/10:29k/10:33k/10:37k/10:41k/10 \
> -bs_unaligned -runtime=1200 -size=-group_reporting -name=mytest -numjobs=60
>
> sleep 35
> echo 1 > $SYSFS_NVME_PCI_PATH/rescan
> echo 1 > $SYSFS_NVME_PCI_PATH/reset
> echo 1 > $SYSFS_NVME_PCI_PATH/remove
> echo 1 > /sys/bus/pci/rescan
>
> [2] kernel hang log
> [ 492.232593] INFO: task nvme-test:5939 blocked for more than 120 seconds.
> [ 492.240081] Not tainted 4.11.0.nvme_v4.11_debug_hang+ #3
> [ 492.246600] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 492.255346] nvme-test D 0 5939 5938 0x00000080
> [ 492.261475] Call Trace:
> [ 492.264215] __schedule+0x289/0x8f0
> [ 492.268105] ? write_cache_pages+0x14c/0x510
> [ 492.272873] schedule+0x36/0x80
> [ 492.276381] io_schedule+0x16/0x40
> [ 492.280181] wait_on_page_bit_common+0x137/0x220
> [ 492.285336] ? page_cache_tree_insert+0x120/0x120
> [ 492.290589] __filemap_fdatawait_range+0x128/0x1a0
> [ 492.295941] filemap_fdatawait_range+0x14/0x30
> [ 492.300902] filemap_fdatawait+0x23/0x30
> [ 492.305282] filemap_write_and_wait+0x4c/0x80
> [ 492.310151] __sync_blockdev+0x1f/0x40
> [ 492.314336] fsync_bdev+0x44/0x50
> [ 492.318039] invalidate_partition+0x24/0x50
> [ 492.322710] del_gendisk+0xcd/0x2e0
> [ 492.326608] nvme_ns_remove+0x105/0x130 [nvme_core]
> [ 492.332054] nvme_remove_namespaces+0x32/0x50 [nvme_core]
> [ 492.338082] nvme_uninit_ctrl+0x2d/0xa0 [nvme_core]
> [ 492.343519] nvme_remove+0x5d/0x170 [nvme]
> [ 492.348096] pci_device_remove+0x39/0xc0
> [ 492.352477] device_release_driver_internal+0x141/0x1f0
> [ 492.358311] device_release_driver+0x12/0x20
> [ 492.363072] pci_stop_bus_device+0x8c/0xa0
> [ 492.367646] pci_stop_and_remove_bus_device_locked+0x1a/0x30
> [ 492.373965] remove_store+0x7c/0x90
> [ 492.377852] dev_attr_store+0x18/0x30
> [ 492.381941] sysfs_kf_write+0x3a/0x50
> [ 492.386028] kernfs_fop_write+0xff/0x180
> [ 492.390409] __vfs_write+0x37/0x160
> [ 492.394304] ? selinux_file_permission+0xe5/0x120
> [ 492.399556] ? security_file_permission+0x3b/0xc0
> [ 492.404807] vfs_write+0xb2/0x1b0
> [ 492.408508] ? syscall_trace_enter+0x1d0/0x2b0
> [ 492.413462] SyS_write+0x55/0xc0
> [ 492.417064] do_syscall_64+0x67/0x180
> [ 492.421155] entry_SYSCALL64_slow_path+0x25/0x25
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Ming Lei <ming.lei@redhat.com>
> ---
> drivers/nvme/host/pci.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> index fed803232edc..5e39abe57c56 100644
> --- a/drivers/nvme/host/pci.c
> +++ b/drivers/nvme/host/pci.c
> @@ -1887,6 +1887,14 @@ static void nvme_remove_dead_ctrl(struct nvme_dev *dev, int status)
>
> kref_get(&dev->ctrl.kref);
> nvme_dev_disable(dev, false);
> + /*
> + * nvme_dev_disable() has suspended queues, then no new I/O
> + * can be submitted to hardware successfully any more, so
> + * kill queues now for avoiding race between reset failure
> + * and remove.
How about this instead:
/*
* nvme_dev_disable() has suspended the I/O queues and no new I/O can
* be submitted now. Kill the queues now to avoid races between a
* possible reset failure and the controller removal work.
*/
Otherwise this looks fine to me:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* [PATCH v2 2/4] crypto: drbg wait for crypto op not signal safe
From: Gilad Ben-Yossef @ 2017-05-18 13:29 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Jonathan Corbet, David Howells
Cc: Ofir Drang, stable, linux-crypto, linux-doc, linux-kernel,
keyrings
In-Reply-To: <1495114167-3073-1-git-send-email-gilad@benyossef.com>
drbg_kcapi_sym_ctr() was using wait_for_completion_interruptible() to
wait for completion of async crypto op but if a signal occurs it
may return before DMA ops of HW crypto provider finish, thus
corrupting the output buffer.
Resolve this by using wait_for_completion() instead.
Reported-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
CC: stable@vger.kernel.org
---
crypto/drbg.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index fa749f4..cdb27ac 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1767,9 +1767,8 @@ static int drbg_kcapi_sym_ctr(struct drbg_state *drbg,
break;
case -EINPROGRESS:
case -EBUSY:
- ret = wait_for_completion_interruptible(
- &drbg->ctr_completion);
- if (!ret && !drbg->ctr_async_err) {
+ wait_for_completion(&drbg->ctr_completion);
+ if (!drbg->ctr_async_err) {
reinit_completion(&drbg->ctr_completion);
break;
}
--
2.1.4
^ permalink raw reply related
* [PATCH v2 3/4] crypto: gcm wait for crypto op not signal safe
From: Gilad Ben-Yossef @ 2017-05-18 13:29 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Jonathan Corbet, David Howells
Cc: Ofir Drang, stable, linux-crypto, linux-doc, linux-kernel,
keyrings
In-Reply-To: <1495114167-3073-1-git-send-email-gilad@benyossef.com>
crypto_gcm_setkey() was using wait_for_completion_interruptible() to
wait for completion of async crypto op but if a signal occurs it
may return before DMA ops of HW crypto provider finish, thus
corrupting the data buffer that is kfree'ed in this case.
Resolve this by using wait_for_completion() instead.
Reported-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
CC: stable@vger.kernel.org
---
crypto/gcm.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/crypto/gcm.c b/crypto/gcm.c
index b7ad808..3841b5e 100644
--- a/crypto/gcm.c
+++ b/crypto/gcm.c
@@ -152,10 +152,8 @@ static int crypto_gcm_setkey(struct crypto_aead *aead, const u8 *key,
err = crypto_skcipher_encrypt(&data->req);
if (err == -EINPROGRESS || err == -EBUSY) {
- err = wait_for_completion_interruptible(
- &data->result.completion);
- if (!err)
- err = data->result.err;
+ wait_for_completion(&data->result.completion);
+ err = data->result.err;
}
if (err)
--
2.1.4
^ permalink raw reply related
* [PATCH v2 1/4] crypto: handle EBUSY due to backlog correctly
From: Gilad Ben-Yossef @ 2017-05-18 13:29 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Jonathan Corbet, David Howells
Cc: Ofir Drang, stable, linux-crypto, linux-doc, linux-kernel,
keyrings
In-Reply-To: <1495114167-3073-1-git-send-email-gilad@benyossef.com>
public_key_verify_signature() was passing the CRYPTO_TFM_REQ_MAY_BACKLOG
flag to akcipher_request_set_callback() but was not handling correctly
the case where a -EBUSY error could be returned from the call to
crypto_akcipher_verify() if backlog was used, possibly casuing
data corruption due to use-after-free of buffers.
Resolve this by handling -EBUSY correctly.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
CC: stable@vger.kernel.org
---
crypto/asymmetric_keys/public_key.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/asymmetric_keys/public_key.c b/crypto/asymmetric_keys/public_key.c
index d3a989e..3cd6e12 100644
--- a/crypto/asymmetric_keys/public_key.c
+++ b/crypto/asymmetric_keys/public_key.c
@@ -141,7 +141,7 @@ int public_key_verify_signature(const struct public_key *pkey,
* signature and returns that to us.
*/
ret = crypto_akcipher_verify(req);
- if (ret == -EINPROGRESS) {
+ if ((ret == -EINPROGRESS) || (ret == -EBUSY)) {
wait_for_completion(&compl.completion);
ret = compl.err;
}
--
2.1.4
^ permalink raw reply related
* [PATCH v2 0/4] crypto: async crypto op fixes
From: Gilad Ben-Yossef @ 2017-05-18 13:29 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Jonathan Corbet, David Howells
Cc: Ofir Drang, stable, Eric Biggers, linux-crypto, linux-doc,
linux-kernel, keyrings
This patch set fixes various usage and documentation errors
in waiting for async crypto op to complete which can result
in data corruption.
Note: these were discovered in the process of working on a
patch set that replaces these call sites and more with a
generic implementation that will prevent these problems
going forward. These are just the fix ups for current code.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
CC: stable@vger.kernel.org
CC: Eric Biggers <ebiggers3@gmail.com>
Gilad Ben-Yossef (4):
crypto: handle EBUSY due to backlog correctly
crypto: drbg wait for crypto op not signal safe
crypto: gcm wait for crypto op not signal safe
crypto: Documentation: fix none signal safe sample
Changes from v1:
- Fix a brown paper bug compile error due to bad git rebase squashing
Documentation/crypto/api-samples.rst | 2 +-
crypto/asymmetric_keys/public_key.c | 2 +-
crypto/drbg.c | 5 ++---
crypto/gcm.c | 6 ++----
4 files changed, 6 insertions(+), 9 deletions(-)
--
2.1.4
^ permalink raw reply
* patch "usb: musb: tusb6010_omap: Do not reset the other direction's packet" added to usb-linus
From: gregkh @ 2017-05-18 13:21 UTC (permalink / raw)
To: peter.ujfalusi, b-liu, gregkh, stable, tony
This is a note to let you know that I've just added the patch titled
usb: musb: tusb6010_omap: Do not reset the other direction's packet
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 6df2b42f7c040d57d9ecb67244e04e905ab87ac6 Mon Sep 17 00:00:00 2001
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
Date: Wed, 17 May 2017 11:23:11 -0500
Subject: usb: musb: tusb6010_omap: Do not reset the other direction's packet
size
We have one register for each EP to set the maximum packet size for both
TX and RX.
If for example an RX programming would happen before the previous TX
transfer finishes we would reset the TX packet side.
To fix this issue, only modify the TX or RX part of the register.
Fixes: 550a7375fe72 ("USB: Add MUSB and TUSB support")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/musb/tusb6010_omap.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/musb/tusb6010_omap.c b/drivers/usb/musb/tusb6010_omap.c
index 8b43c4b99f04..7870b37e0ea5 100644
--- a/drivers/usb/musb/tusb6010_omap.c
+++ b/drivers/usb/musb/tusb6010_omap.c
@@ -219,6 +219,7 @@ static int tusb_omap_dma_program(struct dma_channel *channel, u16 packet_sz,
u32 dma_remaining;
int src_burst, dst_burst;
u16 csr;
+ u32 psize;
int ch;
s8 dmareq;
s8 sync_dev;
@@ -390,15 +391,19 @@ static int tusb_omap_dma_program(struct dma_channel *channel, u16 packet_sz,
if (chdat->tx) {
/* Send transfer_packet_sz packets at a time */
- musb_writel(ep_conf, TUSB_EP_MAX_PACKET_SIZE_OFFSET,
- chdat->transfer_packet_sz);
+ psize = musb_readl(ep_conf, TUSB_EP_MAX_PACKET_SIZE_OFFSET);
+ psize &= ~0x7ff;
+ psize |= chdat->transfer_packet_sz;
+ musb_writel(ep_conf, TUSB_EP_MAX_PACKET_SIZE_OFFSET, psize);
musb_writel(ep_conf, TUSB_EP_TX_OFFSET,
TUSB_EP_CONFIG_XFR_SIZE(chdat->transfer_len));
} else {
/* Receive transfer_packet_sz packets at a time */
- musb_writel(ep_conf, TUSB_EP_MAX_PACKET_SIZE_OFFSET,
- chdat->transfer_packet_sz << 16);
+ psize = musb_readl(ep_conf, TUSB_EP_MAX_PACKET_SIZE_OFFSET);
+ psize &= ~(0x7ff << 16);
+ psize |= (chdat->transfer_packet_sz << 16);
+ musb_writel(ep_conf, TUSB_EP_MAX_PACKET_SIZE_OFFSET, psize);
musb_writel(ep_conf, TUSB_EP_RX_OFFSET,
TUSB_EP_CONFIG_XFR_SIZE(chdat->transfer_len));
--
2.13.0
^ permalink raw reply related
* patch "usb: musb: Fix trying to suspend while active for OTG configurations" added to usb-linus
From: gregkh @ 2017-05-18 13:21 UTC (permalink / raw)
To: tony, b-liu, gregkh, johan, laurent.pinchart, peter.ujfalusi,
stable
This is a note to let you know that I've just added the patch titled
usb: musb: Fix trying to suspend while active for OTG configurations
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 3c50ffef25855a9d9e4b07b02d756a8cdd653069 Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Wed, 17 May 2017 11:23:10 -0500
Subject: usb: musb: Fix trying to suspend while active for OTG configurations
Commit d8e5f0eca1e8 ("usb: musb: Fix hardirq-safe hardirq-unsafe
lock order error") caused a regression where musb keeps trying to
enable host mode with no cable connected. This seems to be caused
by the fact that now phy is enabled earlier, and we are wrongly
trying to force USB host mode on an OTG port. The errors we are
getting are "trying to suspend as a_idle while active".
For ports configured as OTG, we should not need to do anything
to try to force USB host mode on it's OTG port. Trying to force host
mode in this case just seems to completely confuse the musb state
machine.
Let's fix the issue by making musb_host_setup() attempt to force the
mode only if port_mode is configured for host mode.
Fixes: d8e5f0eca1e8 ("usb: musb: Fix hardirq-safe hardirq-unsafe lock order error")
Cc: Johan Hovold <johan@kernel.org>
Cc: stable <stable@vger.kernel.org>
Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reported-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/musb/musb_host.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index ac3a4952abb4..dbe617a735d8 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2780,10 +2780,11 @@ int musb_host_setup(struct musb *musb, int power_budget)
int ret;
struct usb_hcd *hcd = musb->hcd;
- MUSB_HST_MODE(musb);
- musb->xceiv->otg->default_a = 1;
- musb->xceiv->otg->state = OTG_STATE_A_IDLE;
-
+ if (musb->port_mode == MUSB_PORT_MODE_HOST) {
+ MUSB_HST_MODE(musb);
+ musb->xceiv->otg->default_a = 1;
+ musb->xceiv->otg->state = OTG_STATE_A_IDLE;
+ }
otg_set_host(musb->xceiv->otg, &hcd->self);
hcd->self.otg_port = 1;
musb->xceiv->otg->host = &hcd->self;
--
2.13.0
^ permalink raw reply related
* patch "xhci: Fix command ring stop regression in 4.11" added to usb-linus
From: gregkh @ 2017-05-18 13:20 UTC (permalink / raw)
To: mathias.nyman, gregkh, stable
This is a note to let you know that I've just added the patch titled
xhci: Fix command ring stop regression in 4.11
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 604d02a2a66ab7f93fd3b2bde3698c29ef057b65 Mon Sep 17 00:00:00 2001
From: Mathias Nyman <mathias.nyman@linux.intel.com>
Date: Wed, 17 May 2017 18:32:05 +0300
Subject: xhci: Fix command ring stop regression in 4.11
In 4.11 TRB completion codes were renamed to match spec.
Completion codes for command ring stopped and endpoint stopped
were mixed, leading to failures while handling a stopped command ring.
Use the correct completion code for command ring stopped events.
Fixes: 0b7c105a04ca ("usb: host: xhci: rename completion codes to match spec")
Cc: <stable@vger.kernel.org> # 4.11
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-hub.c | 2 +-
drivers/usb/host/xhci-ring.c | 8 ++++----
drivers/usb/host/xhci.c | 8 ++++----
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 5e3e9d4c6956..0dde49c35dd2 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -419,7 +419,7 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int slot_id, int suspend)
wait_for_completion(cmd->completion);
if (cmd->status == COMP_COMMAND_ABORTED ||
- cmd->status == COMP_STOPPED) {
+ cmd->status == COMP_COMMAND_RING_STOPPED) {
xhci_warn(xhci, "Timeout while waiting for stop endpoint command\n");
ret = -ETIME;
}
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 6d2492c1c643..03f63f50afb6 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -323,7 +323,7 @@ static void xhci_handle_stopped_cmd_ring(struct xhci_hcd *xhci,
if (i_cmd->status != COMP_COMMAND_ABORTED)
continue;
- i_cmd->status = COMP_STOPPED;
+ i_cmd->status = COMP_COMMAND_RING_STOPPED;
xhci_dbg(xhci, "Turn aborted command %p to no-op\n",
i_cmd->command_trb);
@@ -1380,7 +1380,7 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
cmd_comp_code = GET_COMP_CODE(le32_to_cpu(event->status));
/* If CMD ring stopped we own the trbs between enqueue and dequeue */
- if (cmd_comp_code == COMP_STOPPED) {
+ if (cmd_comp_code == COMP_COMMAND_RING_STOPPED) {
complete_all(&xhci->cmd_ring_stop_completion);
return;
}
@@ -1436,8 +1436,8 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
break;
case TRB_CMD_NOOP:
/* Is this an aborted command turned to NO-OP? */
- if (cmd->status == COMP_STOPPED)
- cmd_comp_code = COMP_STOPPED;
+ if (cmd->status == COMP_COMMAND_RING_STOPPED)
+ cmd_comp_code = COMP_COMMAND_RING_STOPPED;
break;
case TRB_RESET_EP:
WARN_ON(slot_id != TRB_TO_SLOT_ID(
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 71eb2991c698..30f47d92a610 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1764,7 +1764,7 @@ static int xhci_configure_endpoint_result(struct xhci_hcd *xhci,
switch (*cmd_status) {
case COMP_COMMAND_ABORTED:
- case COMP_STOPPED:
+ case COMP_COMMAND_RING_STOPPED:
xhci_warn(xhci, "Timeout while waiting for configure endpoint command\n");
ret = -ETIME;
break;
@@ -1814,7 +1814,7 @@ static int xhci_evaluate_context_result(struct xhci_hcd *xhci,
switch (*cmd_status) {
case COMP_COMMAND_ABORTED:
- case COMP_STOPPED:
+ case COMP_COMMAND_RING_STOPPED:
xhci_warn(xhci, "Timeout while waiting for evaluate context command\n");
ret = -ETIME;
break;
@@ -3433,7 +3433,7 @@ static int xhci_discover_or_reset_device(struct usb_hcd *hcd,
ret = reset_device_cmd->status;
switch (ret) {
case COMP_COMMAND_ABORTED:
- case COMP_STOPPED:
+ case COMP_COMMAND_RING_STOPPED:
xhci_warn(xhci, "Timeout waiting for reset device command\n");
ret = -ETIME;
goto command_cleanup;
@@ -3818,7 +3818,7 @@ static int xhci_setup_device(struct usb_hcd *hcd, struct usb_device *udev,
*/
switch (command->status) {
case COMP_COMMAND_ABORTED:
- case COMP_STOPPED:
+ case COMP_COMMAND_RING_STOPPED:
xhci_warn(xhci, "Timeout while waiting for setup device command\n");
ret = -ETIME;
break;
--
2.13.0
^ permalink raw reply related
* patch "xhci: remove GFP_DMA flag from allocation" added to usb-linus
From: gregkh @ 2017-05-18 13:20 UTC (permalink / raw)
To: matthias.lange, gregkh, mathias.nyman, stable
This is a note to let you know that I've just added the patch titled
xhci: remove GFP_DMA flag from allocation
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 5db851cf20857c5504b146046e97cb7781f2a743 Mon Sep 17 00:00:00 2001
From: Matthias Lange <matthias.lange@kernkonzept.com>
Date: Wed, 17 May 2017 18:32:04 +0300
Subject: xhci: remove GFP_DMA flag from allocation
There is no reason to restrict allocations to the first 16MB ISA DMA
addresses.
It is causing problems in a virtualization setup with enabled IOMMU
(x86_64). The result is that USB is not working in the VM.
CC: <stable@vger.kernel.org>
Signed-off-by: Matthias Lange <matthias.lange@kernkonzept.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 12b573cfb846..1f1687e888d6 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -56,7 +56,7 @@ static struct xhci_segment *xhci_segment_alloc(struct xhci_hcd *xhci,
}
if (max_packet) {
- seg->bounce_buf = kzalloc(max_packet, flags | GFP_DMA);
+ seg->bounce_buf = kzalloc(max_packet, flags);
if (!seg->bounce_buf) {
dma_pool_free(xhci->segment_pool, seg->trbs, dma);
kfree(seg);
--
2.13.0
^ permalink raw reply related
* patch "usb: host: xhci-plat: propagate return value of platform_get_irq()" added to usb-linus
From: gregkh @ 2017-05-18 13:20 UTC (permalink / raw)
To: thomas.petazzoni, gregkh, mathias.nyman, stable
This is a note to let you know that I've just added the patch titled
usb: host: xhci-plat: propagate return value of platform_get_irq()
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 4b148d5144d64ee135b8924350cb0b3a7fd21150 Mon Sep 17 00:00:00 2001
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date: Wed, 17 May 2017 18:32:06 +0300
Subject: usb: host: xhci-plat: propagate return value of platform_get_irq()
platform_get_irq() returns an error code, but the xhci-plat driver
ignores it and always returns -ENODEV. This is not correct, and
prevents -EPROBE_DEFER from being propagated properly.
CC: <stable@vger.kernel.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-plat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 7c2a9e7c8e0f..c04144b25a67 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -177,7 +177,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
irq = platform_get_irq(pdev, 0);
if (irq < 0)
- return -ENODEV;
+ return irq;
/*
* sysdev must point to a device that is known to the system firmware
--
2.13.0
^ permalink raw reply related
* patch "usb: host: xhci-mem: allocate zeroed Scratchpad Buffer" added to usb-linus
From: gregkh @ 2017-05-18 13:20 UTC (permalink / raw)
To: peter.chen, gregkh, mathias.nyman, stable
This is a note to let you know that I've just added the patch titled
usb: host: xhci-mem: allocate zeroed Scratchpad Buffer
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 7480d912d549f414e0ce39331870899e89a5598c Mon Sep 17 00:00:00 2001
From: Peter Chen <peter.chen@nxp.com>
Date: Wed, 17 May 2017 18:32:01 +0300
Subject: usb: host: xhci-mem: allocate zeroed Scratchpad Buffer
According to xHCI ch4.20 Scratchpad Buffers, the Scratchpad
Buffer needs to be zeroed.
...
The following operations take place to allocate
Scratchpad Buffers to the xHC:
...
b. Software clears the Scratchpad Buffer to '0'
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 69428e970925..12b573cfb846 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1724,7 +1724,7 @@ static int scratchpad_alloc(struct xhci_hcd *xhci, gfp_t flags)
xhci->dcbaa->dev_context_ptrs[0] = cpu_to_le64(xhci->scratchpad->sp_dma);
for (i = 0; i < num_sp; i++) {
dma_addr_t dma;
- void *buf = dma_alloc_coherent(dev, xhci->page_size, &dma,
+ void *buf = dma_zalloc_coherent(dev, xhci->page_size, &dma,
flags);
if (!buf)
goto fail_sp4;
--
2.13.0
^ permalink raw reply related
* patch "xhci: apply PME_STUCK_QUIRK and MISSING_CAS quirk for Denverton" added to usb-linus
From: gregkh @ 2017-05-18 13:20 UTC (permalink / raw)
To: mathias.nyman, gregkh, stable
This is a note to let you know that I've just added the patch titled
xhci: apply PME_STUCK_QUIRK and MISSING_CAS quirk for Denverton
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From a0c16630d35a874e82bdf2088f58ecaca1024315 Mon Sep 17 00:00:00 2001
From: Mathias Nyman <mathias.nyman@linux.intel.com>
Date: Wed, 17 May 2017 18:32:00 +0300
Subject: xhci: apply PME_STUCK_QUIRK and MISSING_CAS quirk for Denverton
Intel Denverton microserver is Atom based and need the PME and CAS quirks
as well.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-pci.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 7b86508ac8cf..fcf1f3f63e7a 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -52,6 +52,7 @@
#define PCI_DEVICE_ID_INTEL_BROXTON_M_XHCI 0x0aa8
#define PCI_DEVICE_ID_INTEL_BROXTON_B_XHCI 0x1aa8
#define PCI_DEVICE_ID_INTEL_APL_XHCI 0x5aa8
+#define PCI_DEVICE_ID_INTEL_DNV_XHCI 0x19d0
static const char hcd_name[] = "xhci_hcd";
@@ -166,7 +167,8 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
pdev->device == PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI ||
pdev->device == PCI_DEVICE_ID_INTEL_BROXTON_M_XHCI ||
pdev->device == PCI_DEVICE_ID_INTEL_BROXTON_B_XHCI ||
- pdev->device == PCI_DEVICE_ID_INTEL_APL_XHCI)) {
+ pdev->device == PCI_DEVICE_ID_INTEL_APL_XHCI ||
+ pdev->device == PCI_DEVICE_ID_INTEL_DNV_XHCI)) {
xhci->quirks |= XHCI_PME_STUCK_QUIRK;
}
if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
@@ -175,7 +177,8 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
}
if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
(pdev->device == PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI ||
- pdev->device == PCI_DEVICE_ID_INTEL_APL_XHCI))
+ pdev->device == PCI_DEVICE_ID_INTEL_APL_XHCI ||
+ pdev->device == PCI_DEVICE_ID_INTEL_DNV_XHCI))
xhci->quirks |= XHCI_MISSING_CAS;
if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
--
2.13.0
^ permalink raw reply related
* [PATCH 3.18 33/49] perf: Fix race in swevent hash
From: Greg Kroah-Hartman @ 2017-05-18 13:16 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sasha Levin, Peter Zijlstra (Intel),
Arnaldo Carvalho de Melo, Frederic Weisbecker, Jiri Olsa,
Linus Torvalds, Stephane Eranian, Thomas Gleixner, Vince Weaver,
Ingo Molnar, Amit Pundir
In-Reply-To: <20170518131643.028057293@linuxfoundation.org>
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Zijlstra <peterz@infradead.org>
commit 12ca6ad2e3a896256f086497a7c7406a547ee373 upstream.
There's a race on CPU unplug where we free the swevent hash array
while it can still have events on. This will result in a
use-after-free which is BAD.
Simply do not free the hash array on unplug. This leaves the thing
around and no use-after-free takes place.
When the last swevent dies, we do a for_each_possible_cpu() iteration
anyway to clean these up, at which time we'll free it, so no leakage
will occur.
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Tested-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/events/core.c | 20 +-------------------
1 file changed, 1 insertion(+), 19 deletions(-)
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5851,9 +5851,6 @@ struct swevent_htable {
/* Recursion avoidance in each contexts */
int recursion[PERF_NR_CONTEXTS];
-
- /* Keeps track of cpu being initialized/exited */
- bool online;
};
static DEFINE_PER_CPU(struct swevent_htable, swevent_htable);
@@ -6111,14 +6108,8 @@ static int perf_swevent_add(struct perf_
hwc->state = !(flags & PERF_EF_START);
head = find_swevent_head(swhash, event);
- if (!head) {
- /*
- * We can race with cpu hotplug code. Do not
- * WARN if the cpu just got unplugged.
- */
- WARN_ON_ONCE(swhash->online);
+ if (WARN_ON_ONCE(!head))
return -EINVAL;
- }
hlist_add_head_rcu(&event->hlist_entry, head);
@@ -6185,7 +6176,6 @@ static int swevent_hlist_get_cpu(struct
int err = 0;
mutex_lock(&swhash->hlist_mutex);
-
if (!swevent_hlist_deref(swhash) && cpu_online(cpu)) {
struct swevent_hlist *hlist;
@@ -8342,7 +8332,6 @@ static void perf_event_init_cpu(int cpu)
struct swevent_htable *swhash = &per_cpu(swevent_htable, cpu);
mutex_lock(&swhash->hlist_mutex);
- swhash->online = true;
if (swhash->hlist_refcount > 0) {
struct swevent_hlist *hlist;
@@ -8395,14 +8384,7 @@ static void perf_event_exit_cpu_context(
static void perf_event_exit_cpu(int cpu)
{
- struct swevent_htable *swhash = &per_cpu(swevent_htable, cpu);
-
perf_event_exit_cpu_context(cpu);
-
- mutex_lock(&swhash->hlist_mutex);
- swhash->online = false;
- swevent_hlist_release(swhash);
- mutex_unlock(&swhash->hlist_mutex);
}
#else
static inline void perf_event_exit_cpu(int cpu) { }
^ permalink raw reply
* [PATCH 3.18 41/49] ppp: defer netns reference release for ppp channel
From: Greg Kroah-Hartman @ 2017-05-18 13:16 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Matt Bennett, Paul Mackerras,
linux-ppp, Guillaume Nault, Cyrill Gorcunov, Cong Wang,
David S. Miller, Amit Pundir
In-Reply-To: <20170518131643.028057293@linuxfoundation.org>
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: WANG Cong <xiyou.wangcong@gmail.com>
commit 205e1e255c479f3fd77446415706463b282f94e4 upstream.
Matt reported that we have a NULL pointer dereference
in ppp_pernet() from ppp_connect_channel(),
i.e. pch->chan_net is NULL.
This is due to that a parallel ppp_unregister_channel()
could happen while we are in ppp_connect_channel(), during
which pch->chan_net set to NULL. Since we need a reference
to net per channel, it makes sense to sync the refcnt
with the life time of the channel, therefore we should
release this reference when we destroy it.
Fixes: 1f461dcdd296 ("ppp: take reference on channels netns")
Reported-by: Matt Bennett <Matt.Bennett@alliedtelesis.co.nz>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linux-ppp@vger.kernel.org
Cc: Guillaume Nault <g.nault@alphalink.fr>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ppp/ppp_generic.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -2342,8 +2342,6 @@ ppp_unregister_channel(struct ppp_channe
spin_lock_bh(&pn->all_channels_lock);
list_del(&pch->list);
spin_unlock_bh(&pn->all_channels_lock);
- put_net(pch->chan_net);
- pch->chan_net = NULL;
pch->file.dead = 1;
wake_up_interruptible(&pch->file.rwait);
@@ -2960,6 +2958,9 @@ ppp_disconnect_channel(struct channel *p
*/
static void ppp_destroy_channel(struct channel *pch)
{
+ put_net(pch->chan_net);
+ pch->chan_net = NULL;
+
atomic_dec(&channel_count);
if (!pch->file.dead) {
^ permalink raw reply
* [PATCH 3.18 39/49] ipv6: sctp: fix lockdep splat in sctp_v6_get_dst()
From: Greg Kroah-Hartman @ 2017-05-18 13:16 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dave Jones, Eric Dumazet,
David S. Miller, Amit Pundir
In-Reply-To: <20170518131643.028057293@linuxfoundation.org>
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <edumazet@google.com>
commit 69ce6487dcd364245a3d26322fc8f4ffd1e8d947 upstream.
While cooking the sctp np->opt rcu fixes, I forgot to move
one rcu_read_unlock() after the added rcu_dereference() in
sctp_v6_get_dst()
This gave lockdep warnings reported by Dave Jones.
Fixes: c836a8ba9386 ("ipv6: sctp: add rcu protection around np->opt")
Reported-by: Dave Jones <davej@codemonkey.org.uk>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sctp/ipv6.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -323,14 +323,13 @@ static void sctp_v6_get_dst(struct sctp_
}
}
}
- rcu_read_unlock();
-
if (baddr) {
fl6->saddr = baddr->v6.sin6_addr;
fl6->fl6_sport = baddr->v6.sin6_port;
final_p = fl6_update_dst(fl6, rcu_dereference(np->opt), &final);
dst = ip6_dst_lookup_flow(sk, fl6, final_p);
}
+ rcu_read_unlock();
out:
if (!IS_ERR_OR_NULL(dst)) {
^ permalink raw reply
* [PATCH 3.18 46/49] ALSA: timer: Fix race among timer ioctls
From: Greg Kroah-Hartman @ 2017-05-18 13:16 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dmitry Vyukov, Takashi Iwai,
Amit Pundir
In-Reply-To: <20170518131643.028057293@linuxfoundation.org>
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <tiwai@suse.de>
commit af368027a49a751d6ff4ee9e3f9961f35bb4fede upstream.
ALSA timer ioctls have an open race and this may lead to a
use-after-free of timer instance object. A simplistic fix is to make
each ioctl exclusive. We have already tread_sem for controlling the
tread, and extend this as a global mutex to be applied to each ioctl.
The downside is, of course, the worse concurrency. But these ioctls
aren't to be parallel accessible, in anyway, so it should be fine to
serialize there.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Tested-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/core/timer.c | 32 +++++++++++++++++++-------------
1 file changed, 19 insertions(+), 13 deletions(-)
--- a/sound/core/timer.c
+++ b/sound/core/timer.c
@@ -77,7 +77,7 @@ struct snd_timer_user {
struct timespec tstamp; /* trigger tstamp */
wait_queue_head_t qchange_sleep;
struct fasync_struct *fasync;
- struct mutex tread_sem;
+ struct mutex ioctl_lock;
};
/* list of timers */
@@ -1342,7 +1342,7 @@ static int snd_timer_user_open(struct in
return -ENOMEM;
spin_lock_init(&tu->qlock);
init_waitqueue_head(&tu->qchange_sleep);
- mutex_init(&tu->tread_sem);
+ mutex_init(&tu->ioctl_lock);
tu->ticks = 1;
tu->queue_size = 128;
tu->queue = kmalloc(tu->queue_size * sizeof(struct snd_timer_read),
@@ -1362,8 +1362,10 @@ static int snd_timer_user_release(struct
if (file->private_data) {
tu = file->private_data;
file->private_data = NULL;
+ mutex_lock(&tu->ioctl_lock);
if (tu->timeri)
snd_timer_close(tu->timeri);
+ mutex_unlock(&tu->ioctl_lock);
kfree(tu->queue);
kfree(tu->tqueue);
kfree(tu);
@@ -1601,7 +1603,6 @@ static int snd_timer_user_tselect(struct
int err = 0;
tu = file->private_data;
- mutex_lock(&tu->tread_sem);
if (tu->timeri) {
snd_timer_close(tu->timeri);
tu->timeri = NULL;
@@ -1645,7 +1646,6 @@ static int snd_timer_user_tselect(struct
}
__err:
- mutex_unlock(&tu->tread_sem);
return err;
}
@@ -1861,7 +1861,7 @@ enum {
SNDRV_TIMER_IOCTL_PAUSE_OLD = _IO('T', 0x23),
};
-static long snd_timer_user_ioctl(struct file *file, unsigned int cmd,
+static long __snd_timer_user_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
{
struct snd_timer_user *tu;
@@ -1878,17 +1878,11 @@ static long snd_timer_user_ioctl(struct
{
int xarg;
- mutex_lock(&tu->tread_sem);
- if (tu->timeri) { /* too late */
- mutex_unlock(&tu->tread_sem);
+ if (tu->timeri) /* too late */
return -EBUSY;
- }
- if (get_user(xarg, p)) {
- mutex_unlock(&tu->tread_sem);
+ if (get_user(xarg, p))
return -EFAULT;
- }
tu->tread = xarg ? 1 : 0;
- mutex_unlock(&tu->tread_sem);
return 0;
}
case SNDRV_TIMER_IOCTL_GINFO:
@@ -1921,6 +1915,18 @@ static long snd_timer_user_ioctl(struct
return -ENOTTY;
}
+static long snd_timer_user_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ struct snd_timer_user *tu = file->private_data;
+ long ret;
+
+ mutex_lock(&tu->ioctl_lock);
+ ret = __snd_timer_user_ioctl(file, cmd, arg);
+ mutex_unlock(&tu->ioctl_lock);
+ return ret;
+}
+
static int snd_timer_user_fasync(int fd, struct file * file, int on)
{
struct snd_timer_user *tu;
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox