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

[Linux-stable-mirror] patch "usbip: prevent leaking socket pointer address in messages" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usbip: prevent leaking socket pointer address in messages 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 90120d15f4c397272aaf41077960a157fc4212bf Mon Sep 17 00:00:00 2001 From: Shuah Khan <shuahkh(a)osg.samsung.com> Date: Fri, 15 Dec 2017 10:50:09 -0700 Subject: usbip: prevent leaking socket pointer address in messages usbip driver is leaking socket pointer address in messages. Remove the messages that aren't useful and print sockfd in the ones that are useful for debugging. Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/usbip/stub_dev.c | 3 +-- drivers/usb/usbip/usbip_common.c | 16 +++++----------- drivers/usb/usbip/vhci_hcd.c | 2 +- 3 files changed, 7 insertions(+), 14 deletions(-) diff --git a/drivers/usb/usbip/stub_dev.c b/drivers/usb/usbip/stub_dev.c index a3df8ee82faf..e31a6f204397 100644 --- a/drivers/usb/usbip/stub_dev.c +++ b/drivers/usb/usbip/stub_dev.c @@ -149,8 +149,7 @@ static void stub_shutdown_connection(struct usbip_device *ud) * step 1? */ if (ud->tcp_socket) { - dev_dbg(&sdev->udev->dev, "shutdown tcp_socket %p\n", - ud->tcp_socket); + dev_dbg(&sdev->udev->dev, "shutdown sockfd %d\n", ud->sockfd); kernel_sock_shutdown(ud->tcp_socket, SHUT_RDWR); } diff --git a/drivers/usb/usbip/usbip_common.c b/drivers/usb/usbip/usbip_common.c index f7978933b402..7b219d9109b4 100644 --- a/drivers/usb/usbip/usbip_common.c +++ b/drivers/usb/usbip/usbip_common.c @@ -317,26 +317,20 @@ int usbip_recv(struct socket *sock, void *buf, int size) struct msghdr msg = {.msg_flags = MSG_NOSIGNAL}; int total = 0; + if (!sock || !buf || !size) + return -EINVAL; + iov_iter_kvec(&msg.msg_iter, READ|ITER_KVEC, &iov, 1, size); usbip_dbg_xmit("enter\n"); - if (!sock || !buf || !size) { - pr_err("invalid arg, sock %p buff %p size %d\n", sock, buf, - size); - return -EINVAL; - } - do { - int sz = msg_data_left(&msg); + msg_data_left(&msg); sock->sk->sk_allocation = GFP_NOIO; result = sock_recvmsg(sock, &msg, MSG_WAITALL); - if (result <= 0) { - pr_debug("receive sock %p buf %p size %u ret %d total %d\n", - sock, buf + total, sz, result, total); + if (result <= 0) goto err; - } total += result; } while (msg_data_left(&msg)); diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c index 9efab3dc3734..c3e1008aa491 100644 --- a/drivers/usb/usbip/vhci_hcd.c +++ b/drivers/usb/usbip/vhci_hcd.c @@ -965,7 +965,7 @@ static void vhci_shutdown_connection(struct usbip_device *ud) /* need this? see stub_dev.c */ if (ud->tcp_socket) { - pr_debug("shutdown tcp_socket %p\n", ud->tcp_socket); + pr_debug("shutdown tcp_socket %d\n", ud->sockfd); kernel_sock_shutdown(ud->tcp_socket, SHUT_RDWR); } -- 2.15.1

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] patch "usbip: stub: stop printing kernel pointer addresses in messages" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usbip: stub: stop printing kernel pointer addresses in messages 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 248a22044366f588d46754c54dfe29ffe4f8b4df Mon Sep 17 00:00:00 2001 From: Shuah Khan <shuahkh(a)osg.samsung.com> Date: Mon, 18 Dec 2017 17:23:37 -0700 Subject: usbip: stub: stop printing kernel pointer addresses in messages Remove and/or change debug, info. and error messages to not print kernel pointer addresses. Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/usbip/stub_main.c | 5 +++-- drivers/usb/usbip/stub_rx.c | 7 ++----- drivers/usb/usbip/stub_tx.c | 6 +++--- 3 files changed, 8 insertions(+), 10 deletions(-) diff --git a/drivers/usb/usbip/stub_main.c b/drivers/usb/usbip/stub_main.c index 4f48b306713f..c31c8402a0c5 100644 --- a/drivers/usb/usbip/stub_main.c +++ b/drivers/usb/usbip/stub_main.c @@ -237,11 +237,12 @@ void stub_device_cleanup_urbs(struct stub_device *sdev) struct stub_priv *priv; struct urb *urb; - dev_dbg(&sdev->udev->dev, "free sdev %p\n", sdev); + dev_dbg(&sdev->udev->dev, "Stub device cleaning up urbs\n"); while ((priv = stub_priv_pop(sdev))) { urb = priv->urb; - dev_dbg(&sdev->udev->dev, "free urb %p\n", urb); + dev_dbg(&sdev->udev->dev, "free urb seqnum %lu\n", + priv->seqnum); usb_kill_urb(urb); kmem_cache_free(stub_priv_cache, priv); diff --git a/drivers/usb/usbip/stub_rx.c b/drivers/usb/usbip/stub_rx.c index 493ac2928391..2f29be474098 100644 --- a/drivers/usb/usbip/stub_rx.c +++ b/drivers/usb/usbip/stub_rx.c @@ -211,9 +211,6 @@ static int stub_recv_cmd_unlink(struct stub_device *sdev, if (priv->seqnum != pdu->u.cmd_unlink.seqnum) continue; - dev_info(&priv->urb->dev->dev, "unlink urb %p\n", - priv->urb); - /* * This matched urb is not completed yet (i.e., be in * flight in usb hcd hardware/driver). Now we are @@ -252,8 +249,8 @@ static int stub_recv_cmd_unlink(struct stub_device *sdev, ret = usb_unlink_urb(priv->urb); if (ret != -EINPROGRESS) dev_err(&priv->urb->dev->dev, - "failed to unlink a urb %p, ret %d\n", - priv->urb, ret); + "failed to unlink a urb # %lu, ret %d\n", + priv->seqnum, ret); return 0; } diff --git a/drivers/usb/usbip/stub_tx.c b/drivers/usb/usbip/stub_tx.c index 53172b1f6257..f0ec41a50cbc 100644 --- a/drivers/usb/usbip/stub_tx.c +++ b/drivers/usb/usbip/stub_tx.c @@ -88,7 +88,7 @@ void stub_complete(struct urb *urb) /* link a urb to the queue of tx. */ spin_lock_irqsave(&sdev->priv_lock, flags); if (sdev->ud.tcp_socket == NULL) { - usbip_dbg_stub_tx("ignore urb for closed connection %p", urb); + usbip_dbg_stub_tx("ignore urb for closed connection\n"); /* It will be freed in stub_device_cleanup_urbs(). */ } else if (priv->unlinking) { stub_enqueue_ret_unlink(sdev, priv->seqnum, urb->status); @@ -190,8 +190,8 @@ static int stub_send_ret_submit(struct stub_device *sdev) /* 1. setup usbip_header */ setup_ret_submit_pdu(&pdu_header, urb); - usbip_dbg_stub_tx("setup txdata seqnum: %d urb: %p\n", - pdu_header.base.seqnum, urb); + usbip_dbg_stub_tx("setup txdata seqnum: %d\n", + pdu_header.base.seqnum); usbip_header_correct_endian(&pdu_header, 1); iov[iovnum].iov_base = &pdu_header; -- 2.15.1

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] patch "USB: Fix off by one in type-specific length check of BOS SSP" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: Fix off by one in type-specific length check of BOS SSP 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 07b9f12864d16c3a861aef4817eb1efccbc5d0e6 Mon Sep 17 00:00:00 2001 From: Mathias Nyman <mathias.nyman(a)linux.intel.com> Date: Tue, 19 Dec 2017 11:14:42 +0200 Subject: USB: Fix off by one in type-specific length check of BOS SSP capability USB 3.1 devices are not detected as 3.1 capable since 4.15-rc3 due to a off by one in commit 81cf4a45360f ("USB: core: Add type-specific length check of BOS descriptors") It uses USB_DT_USB_SSP_CAP_SIZE() to get SSP capability size which takes the zero based SSAC as argument, not the actual count of sublink speed attributes. USB3 spec 9.6.2.5 says "The number of Sublink Speed Attributes = SSAC + 1." The type-specific length check patch was added to stable and needs to be fixed there as well Fixes: 81cf4a45360f ("USB: core: Add type-specific length check of BOS descriptors") Cc: linux-stable <stable(a)vger.kernel.org> CC: Masakazu Mokuno <masakazu.mokuno(a)gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/config.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c index 78e92d29f8d9..c821b4b9647e 100644 --- a/drivers/usb/core/config.c +++ b/drivers/usb/core/config.c @@ -1007,7 +1007,7 @@ int usb_get_bos_descriptor(struct usb_device *dev) case USB_SSP_CAP_TYPE: ssp_cap = (struct usb_ssp_cap_descriptor *)buffer; ssac = (le32_to_cpu(ssp_cap->bmAttributes) & - USB_SSP_SUBLINK_SPEED_ATTRIBS) + 1; + USB_SSP_SUBLINK_SPEED_ATTRIBS); if (length >= USB_DT_USB_SSP_CAP_SIZE(ssac)) dev->bos->ssp_cap = ssp_cap; break; -- 2.15.1

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] patch "usbip: vhci: stop printing kernel pointer addresses in messages" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usbip: vhci: stop printing kernel pointer addresses in messages 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 8272d099d05f7ab2776cf56a2ab9f9443be18907 Mon Sep 17 00:00:00 2001 From: Shuah Khan <shuahkh(a)osg.samsung.com> Date: Mon, 18 Dec 2017 17:24:22 -0700 Subject: usbip: vhci: stop printing kernel pointer addresses in messages Remove and/or change debug, info. and error messages to not print kernel pointer addresses. Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/usbip/vhci_hcd.c | 10 ---------- drivers/usb/usbip/vhci_rx.c | 23 +++++++++++------------ drivers/usb/usbip/vhci_tx.c | 3 ++- 3 files changed, 13 insertions(+), 23 deletions(-) diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c index 6b3278c4b72a..9efab3dc3734 100644 --- a/drivers/usb/usbip/vhci_hcd.c +++ b/drivers/usb/usbip/vhci_hcd.c @@ -656,9 +656,6 @@ static int vhci_urb_enqueue(struct usb_hcd *hcd, struct urb *urb, gfp_t mem_flag struct vhci_device *vdev; unsigned long flags; - usbip_dbg_vhci_hc("enter, usb_hcd %p urb %p mem_flags %d\n", - hcd, urb, mem_flags); - if (portnum > VHCI_HC_PORTS) { pr_err("invalid port number %d\n", portnum); return -ENODEV; @@ -822,8 +819,6 @@ static int vhci_urb_dequeue(struct usb_hcd *hcd, struct urb *urb, int status) struct vhci_device *vdev; unsigned long flags; - pr_info("dequeue a urb %p\n", urb); - spin_lock_irqsave(&vhci->lock, flags); priv = urb->hcpriv; @@ -851,7 +846,6 @@ static int vhci_urb_dequeue(struct usb_hcd *hcd, struct urb *urb, int status) /* tcp connection is closed */ spin_lock(&vdev->priv_lock); - pr_info("device %p seems to be disconnected\n", vdev); list_del(&priv->list); kfree(priv); urb->hcpriv = NULL; @@ -863,8 +857,6 @@ static int vhci_urb_dequeue(struct usb_hcd *hcd, struct urb *urb, int status) * vhci_rx will receive RET_UNLINK and give back the URB. * Otherwise, we give back it here. */ - pr_info("gives back urb %p\n", urb); - usb_hcd_unlink_urb_from_ep(hcd, urb); spin_unlock_irqrestore(&vhci->lock, flags); @@ -892,8 +884,6 @@ static int vhci_urb_dequeue(struct usb_hcd *hcd, struct urb *urb, int status) unlink->unlink_seqnum = priv->seqnum; - pr_info("device %p seems to be still connected\n", vdev); - /* send cmd_unlink and try to cancel the pending URB in the * peer */ list_add_tail(&unlink->list, &vdev->unlink_tx); diff --git a/drivers/usb/usbip/vhci_rx.c b/drivers/usb/usbip/vhci_rx.c index 90577e8b2282..112ebb90d8c9 100644 --- a/drivers/usb/usbip/vhci_rx.c +++ b/drivers/usb/usbip/vhci_rx.c @@ -23,24 +23,23 @@ struct urb *pickup_urb_and_free_priv(struct vhci_device *vdev, __u32 seqnum) urb = priv->urb; status = urb->status; - usbip_dbg_vhci_rx("find urb %p vurb %p seqnum %u\n", - urb, priv, seqnum); + usbip_dbg_vhci_rx("find urb seqnum %u\n", seqnum); switch (status) { case -ENOENT: /* fall through */ case -ECONNRESET: - dev_info(&urb->dev->dev, - "urb %p was unlinked %ssynchronuously.\n", urb, - status == -ENOENT ? "" : "a"); + dev_dbg(&urb->dev->dev, + "urb seq# %u was unlinked %ssynchronuously\n", + seqnum, status == -ENOENT ? "" : "a"); break; case -EINPROGRESS: /* no info output */ break; default: - dev_info(&urb->dev->dev, - "urb %p may be in a error, status %d\n", urb, - status); + dev_dbg(&urb->dev->dev, + "urb seq# %u may be in a error, status %d\n", + seqnum, status); } list_del(&priv->list); @@ -67,8 +66,8 @@ static void vhci_recv_ret_submit(struct vhci_device *vdev, spin_unlock_irqrestore(&vdev->priv_lock, flags); if (!urb) { - pr_err("cannot find a urb of seqnum %u\n", pdu->base.seqnum); - pr_info("max seqnum %d\n", + pr_err("cannot find a urb of seqnum %u max seqnum %d\n", + pdu->base.seqnum, atomic_read(&vhci_hcd->seqnum)); usbip_event_add(ud, VDEV_EVENT_ERROR_TCP); return; @@ -91,7 +90,7 @@ static void vhci_recv_ret_submit(struct vhci_device *vdev, if (usbip_dbg_flag_vhci_rx) usbip_dump_urb(urb); - usbip_dbg_vhci_rx("now giveback urb %p\n", urb); + usbip_dbg_vhci_rx("now giveback urb %u\n", pdu->base.seqnum); spin_lock_irqsave(&vhci->lock, flags); usb_hcd_unlink_urb_from_ep(vhci_hcd_to_hcd(vhci_hcd), urb); @@ -158,7 +157,7 @@ static void vhci_recv_ret_unlink(struct vhci_device *vdev, pr_info("the urb (seqnum %d) was already given back\n", pdu->base.seqnum); } else { - usbip_dbg_vhci_rx("now giveback urb %p\n", urb); + usbip_dbg_vhci_rx("now giveback urb %d\n", pdu->base.seqnum); /* If unlink is successful, status is -ECONNRESET */ urb->status = pdu->u.ret_unlink.status; diff --git a/drivers/usb/usbip/vhci_tx.c b/drivers/usb/usbip/vhci_tx.c index d625a2ff4b71..9aed15a358b7 100644 --- a/drivers/usb/usbip/vhci_tx.c +++ b/drivers/usb/usbip/vhci_tx.c @@ -69,7 +69,8 @@ static int vhci_send_cmd_submit(struct vhci_device *vdev) memset(&msg, 0, sizeof(msg)); memset(&iov, 0, sizeof(iov)); - usbip_dbg_vhci_tx("setup txdata urb %p\n", urb); + usbip_dbg_vhci_tx("setup txdata urb seqnum %lu\n", + priv->seqnum); /* 1. setup usbip_header */ setup_cmd_submit_pdu(&pdu_header, urb); -- 2.15.1

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] patch "phy: tegra: fix device-tree node lookups" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled phy: tegra: fix device-tree node lookups 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 046046737bd35bed047460f080ea47e186be731e Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan(a)kernel.org> Date: Wed, 15 Nov 2017 10:43:16 +0100 Subject: phy: tegra: fix device-tree node lookups Fix child-node lookups during probe, which ended up searching the whole device tree depth-first starting at the parents rather than just matching on their children. To make things worse, some parent nodes could end up being being prematurely freed (by tegra_xusb_pad_register()) as of_find_node_by_name() drops a reference to its first argument. Fixes: 53d2a715c240 ("phy: Add Tegra XUSB pad controller support") Cc: stable <stable(a)vger.kernel.org> # 4.7 Cc: Thierry Reding <treding(a)nvidia.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com> --- drivers/phy/tegra/xusb.c | 58 ++++++++++++++++++++++++------------------------ 1 file changed, 29 insertions(+), 29 deletions(-) diff --git a/drivers/phy/tegra/xusb.c b/drivers/phy/tegra/xusb.c index 4307bf0013e1..63e916d4d069 100644 --- a/drivers/phy/tegra/xusb.c +++ b/drivers/phy/tegra/xusb.c @@ -75,14 +75,14 @@ MODULE_DEVICE_TABLE(of, tegra_xusb_padctl_of_match); static struct device_node * tegra_xusb_find_pad_node(struct tegra_xusb_padctl *padctl, const char *name) { - /* - * of_find_node_by_name() drops a reference, so make sure to grab one. - */ - struct device_node *np = of_node_get(padctl->dev->of_node); + struct device_node *pads, *np; + + pads = of_get_child_by_name(padctl->dev->of_node, "pads"); + if (!pads) + return NULL; - np = of_find_node_by_name(np, "pads"); - if (np) - np = of_find_node_by_name(np, name); + np = of_get_child_by_name(pads, name); + of_node_put(pads); return np; } @@ -90,16 +90,16 @@ tegra_xusb_find_pad_node(struct tegra_xusb_padctl *padctl, const char *name) static struct device_node * tegra_xusb_pad_find_phy_node(struct tegra_xusb_pad *pad, unsigned int index) { - /* - * of_find_node_by_name() drops a reference, so make sure to grab one. - */ - struct device_node *np = of_node_get(pad->dev.of_node); + struct device_node *np, *lanes; - np = of_find_node_by_name(np, "lanes"); - if (!np) + lanes = of_get_child_by_name(pad->dev.of_node, "lanes"); + if (!lanes) return NULL; - return of_find_node_by_name(np, pad->soc->lanes[index].name); + np = of_get_child_by_name(lanes, pad->soc->lanes[index].name); + of_node_put(lanes); + + return np; } static int @@ -195,7 +195,7 @@ int tegra_xusb_pad_register(struct tegra_xusb_pad *pad, unsigned int i; int err; - children = of_find_node_by_name(pad->dev.of_node, "lanes"); + children = of_get_child_by_name(pad->dev.of_node, "lanes"); if (!children) return -ENODEV; @@ -444,21 +444,21 @@ static struct device_node * tegra_xusb_find_port_node(struct tegra_xusb_padctl *padctl, const char *type, unsigned int index) { - /* - * of_find_node_by_name() drops a reference, so make sure to grab one. - */ - struct device_node *np = of_node_get(padctl->dev->of_node); + struct device_node *ports, *np; + char *name; - np = of_find_node_by_name(np, "ports"); - if (np) { - char *name; + ports = of_get_child_by_name(padctl->dev->of_node, "ports"); + if (!ports) + return NULL; - name = kasprintf(GFP_KERNEL, "%s-%u", type, index); - if (!name) - return ERR_PTR(-ENOMEM); - np = of_find_node_by_name(np, name); - kfree(name); + name = kasprintf(GFP_KERNEL, "%s-%u", type, index); + if (!name) { + of_node_put(ports); + return ERR_PTR(-ENOMEM); } + np = of_get_child_by_name(ports, name); + kfree(name); + of_node_put(ports); return np; } @@ -847,7 +847,7 @@ static void tegra_xusb_remove_ports(struct tegra_xusb_padctl *padctl) static int tegra_xusb_padctl_probe(struct platform_device *pdev) { - struct device_node *np = of_node_get(pdev->dev.of_node); + struct device_node *np = pdev->dev.of_node; const struct tegra_xusb_padctl_soc *soc; struct tegra_xusb_padctl *padctl; const struct of_device_id *match; @@ -855,7 +855,7 @@ static int tegra_xusb_padctl_probe(struct platform_device *pdev) int err; /* for backwards compatibility with old device trees */ - np = of_find_node_by_name(np, "pads"); + np = of_get_child_by_name(np, "pads"); if (!np) { dev_warn(&pdev->dev, "deprecated DT, using legacy driver\n"); return tegra_xusb_padctl_legacy_probe(pdev); -- 2.15.1

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] [PATCH] fscache: Fix the default for fscache_maybe_release_page()

by David Howells

Fix the default for fscache_maybe_release_page() for when the cookie isn't valid or the page isn't cached. It mustn't return false as that indicates the page cannot yet be freed. The problem with the default is that if, say, there's no cache, but a network filesystem's pages are using up almost all the available memory, a system can OOM because the filesystem ->releasepage() op will not allow them to be released as fscache_maybe_release_page() incorrectly prevents it. This can be tested by writing a sequence of 512MiB files to an AFS mount. It does not affect NFS or CIFS because both of those wrap the call in a check of PG_fscache and it shouldn't bother Ceph as that only has PG_private set whilst writeback is in progress. This might be an issue for 9P, however. Note that the pages aren't entirely stuck. Removing a file or unmounting will clear things because that uses ->invalidatepage() instead. Fixes: 201a15428bd5 ("FS-Cache: Handle pages pending storage that get evicted under OOM conditions") Reported-by: Marc Dionne <marc.dionne(a)auristor.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Reviewed-by: Jeff Layton <jlayton(a)redhat.com> Acked-by: Al Viro <viro(a)zeniv.linux.org.uk> cc: stable(a)vger.kernel.org # 2.6.32+ --- include/linux/fscache.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/fscache.h b/include/linux/fscache.h index f4ff47d4a893..fe0c349684fa 100644 --- a/include/linux/fscache.h +++ b/include/linux/fscache.h @@ -755,7 +755,7 @@ bool fscache_maybe_release_page(struct fscache_cookie *cookie, { if (fscache_cookie_valid(cookie) && PageFsCache(page)) return __fscache_maybe_release_page(cookie, page, gfp); - return false; + return true; } /**

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] [PATCH] fscache: Fix the default for fscache_maybe_release_page()

by David Howells

Fix the default for fscache_maybe_release_page() for when the cookie isn't valid or the page isn't cached. It mustn't return false as that indicates the page cannot yet be freed. The problem with the default is that if, say, there's no cache, but a network filesystem's pages are using up almost all the available memory, a system can OOM because the filesystem ->releasepage() op will not allow them to be released as fscache_maybe_release_page() incorrectly prevents it. This can be tested by writing a sequence of 512MiB files to an AFS mount. It does not affect NFS or CIFS because both of those wrap the call in a check of PG_fscache and it shouldn't bother Ceph as that only has PG_private set whilst writeback is in progress. This might be an issue for 9P, however. Note that the pages aren't entirely stuck. Removing a file or unmounting will clear things because that uses ->invalidatepage() instead. Fixes: 201a15428bd5 ("FS-Cache: Handle pages pending storage that get evicted under OOM conditions") Reported-by: Marc Dionne <marc.dionne(a)auristor.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Reviewed-by: Jeff Layton <jlayton(a)redhat.com> Acked-by: Al Viro <viro(a)zeniv.linux.org.uk> cc: stable(a)vger.kernel.org # 2.6.32+ --- include/linux/fscache.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/fscache.h b/include/linux/fscache.h index f4ff47d4a893..fe0c349684fa 100644 --- a/include/linux/fscache.h +++ b/include/linux/fscache.h @@ -755,7 +755,7 @@ bool fscache_maybe_release_page(struct fscache_cookie *cookie, { if (fscache_cookie_valid(cookie) && PageFsCache(page)) return __fscache_maybe_release_page(cookie, page, gfp); - return false; + return true; } /**

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] [PATCH stable-queue] drop platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch

by alexander.levin＠verizon.com

Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> --- ...ix-error-handling-in-sony_nc_setup_rfkill.patch | 56 ---------------------- queue-3.18/series | 1 - ...ix-error-handling-in-sony_nc_setup_rfkill.patch | 56 ---------------------- queue-4.14/series | 1 - ...ix-error-handling-in-sony_nc_setup_rfkill.patch | 56 ---------------------- queue-4.4/series | 1 - ...ix-error-handling-in-sony_nc_setup_rfkill.patch | 56 ---------------------- queue-4.9/series | 1 - 8 files changed, 228 deletions(-) delete mode 100644 queue-3.18/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch delete mode 100644 queue-4.14/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch delete mode 100644 queue-4.4/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch delete mode 100644 queue-4.9/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch diff --git a/queue-3.18/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch b/queue-3.18/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch deleted file mode 100644 index 29eccbffe..000000000 --- a/queue-3.18/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch +++ /dev/null @@ -1,56 +0,0 @@ -From foo@baz Mon Dec 18 15:03:25 CET 2017 -From: Markus Elfring <elfring(a)users.sourceforge.net> -Date: Wed, 1 Nov 2017 18:42:45 +0100 -Subject: platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill() - -From: Markus Elfring <elfring(a)users.sourceforge.net> - - -[ Upstream commit f6c8a317ab208aee223776327c06f23342492d54 ] - -Source code review for a specific software refactoring showed the need -for another correction because the error code "-1" was returned so far -if a call of the function "sony_call_snc_handle" failed here. -Thus assign the return value from these two function calls also to -the variable "err" and provide it in case of a failure. - -Fixes: d6f15ed876b83a1a0eba1d0473eef58acc95444a ("sony-laptop: use soft rfkill status stored in hw") -Suggested-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> -Link: https://lkml.org/lkml/2017/10/31/463 -Link: https://lkml.kernel.org/r/<CAHp75VcMkXCioCzmLE0+BTmkqc5RSOx9yPO0ectVHMrMvewgwg(a)mail.gmail.com> -Signed-off-by: Markus Elfring <elfring(a)users.sourceforge.net> -Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> -Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> -Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> ---- - drivers/platform/x86/sony-laptop.c | 14 ++++++++------ - 1 file changed, 8 insertions(+), 6 deletions(-) - ---- a/drivers/platform/x86/sony-laptop.c -+++ b/drivers/platform/x86/sony-laptop.c -@@ -1654,17 +1654,19 @@ static int sony_nc_setup_rfkill(struct a - if (!rfk) - return -ENOMEM; - -- if (sony_call_snc_handle(sony_rfkill_handle, 0x200, &result) < 0) { -+ err = sony_call_snc_handle(sony_rfkill_handle, 0x200, &result); -+ if (err < 0) { - rfkill_destroy(rfk); -- return -1; -+ return err; - } - hwblock = !(result & 0x1); - -- if (sony_call_snc_handle(sony_rfkill_handle, -- sony_rfkill_address[nc_type], -- &result) < 0) { -+ err = sony_call_snc_handle(sony_rfkill_handle, -+ sony_rfkill_address[nc_type], -+ &result); -+ if (err < 0) { - rfkill_destroy(rfk); -- return -1; -+ return err; - } - swblock = !(result & 0x2); - diff --git a/queue-3.18/series b/queue-3.18/series index ed60ddbc4..8525d16ff 100644 --- a/queue-3.18/series +++ b/queue-3.18/series @@ -43,7 +43,6 @@ pci-pme-handle-invalid-data-when-reading-root-status.patch powerpc-powernv-cpufreq-fix-the-frequency-read-by-proc-cpuinfo.patch powerpc-opal-fix-ebusy-bug-in-acquiring-tokens.patch powerpc-ipic-fix-status-get-and-status-clear.patch -platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch iscsi-target-fix-memory-leak-in-lio_target_tiqn_addtpg.patch target-fix-condition-return-in-core_pr_dump_initiator_port.patch diff --git a/queue-4.14/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch b/queue-4.14/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch deleted file mode 100644 index 80673c2e3..000000000 --- a/queue-4.14/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch +++ /dev/null @@ -1,56 +0,0 @@ -From foo@baz Mon Dec 18 13:28:59 CET 2017 -From: Markus Elfring <elfring(a)users.sourceforge.net> -Date: Wed, 1 Nov 2017 18:42:45 +0100 -Subject: platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill() - -From: Markus Elfring <elfring(a)users.sourceforge.net> - - -[ Upstream commit f6c8a317ab208aee223776327c06f23342492d54 ] - -Source code review for a specific software refactoring showed the need -for another correction because the error code "-1" was returned so far -if a call of the function "sony_call_snc_handle" failed here. -Thus assign the return value from these two function calls also to -the variable "err" and provide it in case of a failure. - -Fixes: d6f15ed876b83a1a0eba1d0473eef58acc95444a ("sony-laptop: use soft rfkill status stored in hw") -Suggested-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> -Link: https://lkml.org/lkml/2017/10/31/463 -Link: https://lkml.kernel.org/r/<CAHp75VcMkXCioCzmLE0+BTmkqc5RSOx9yPO0ectVHMrMvewgwg(a)mail.gmail.com> -Signed-off-by: Markus Elfring <elfring(a)users.sourceforge.net> -Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> -Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> -Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> ---- - drivers/platform/x86/sony-laptop.c | 14 ++++++++------ - 1 file changed, 8 insertions(+), 6 deletions(-) - ---- a/drivers/platform/x86/sony-laptop.c -+++ b/drivers/platform/x86/sony-laptop.c -@@ -1660,17 +1660,19 @@ static int sony_nc_setup_rfkill(struct a - if (!rfk) - return -ENOMEM; - -- if (sony_call_snc_handle(sony_rfkill_handle, 0x200, &result) < 0) { -+ err = sony_call_snc_handle(sony_rfkill_handle, 0x200, &result); -+ if (err < 0) { - rfkill_destroy(rfk); -- return -1; -+ return err; - } - hwblock = !(result & 0x1); - -- if (sony_call_snc_handle(sony_rfkill_handle, -- sony_rfkill_address[nc_type], -- &result) < 0) { -+ err = sony_call_snc_handle(sony_rfkill_handle, -+ sony_rfkill_address[nc_type], -+ &result); -+ if (err < 0) { - rfkill_destroy(rfk); -- return -1; -+ return err; - } - swblock = !(result & 0x2); - diff --git a/queue-4.14/series b/queue-4.14/series index 8d3089853..7e1d0f7a3 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -68,7 +68,6 @@ powerpc-opal-fix-ebusy-bug-in-acquiring-tokens.patch powerpc-ipic-fix-status-get-and-status-clear.patch powerpc-pseries-vio-dispose-of-virq-mapping-on-vdevice-unregister.patch platform-x86-intel_punit_ipc-fix-resource-ioremap-warning.patch -platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch target-iscsi-detect-conn_cmd_list-corruption-early.patch target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch iscsi-target-fix-memory-leak-in-lio_target_tiqn_addtpg.patch diff --git a/queue-4.4/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch b/queue-4.4/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch deleted file mode 100644 index 7dd8d3d60..000000000 --- a/queue-4.4/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch +++ /dev/null @@ -1,56 +0,0 @@ -From foo@baz Mon Dec 18 14:47:43 CET 2017 -From: Markus Elfring <elfring(a)users.sourceforge.net> -Date: Wed, 1 Nov 2017 18:42:45 +0100 -Subject: platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill() - -From: Markus Elfring <elfring(a)users.sourceforge.net> - - -[ Upstream commit f6c8a317ab208aee223776327c06f23342492d54 ] - -Source code review for a specific software refactoring showed the need -for another correction because the error code "-1" was returned so far -if a call of the function "sony_call_snc_handle" failed here. -Thus assign the return value from these two function calls also to -the variable "err" and provide it in case of a failure. - -Fixes: d6f15ed876b83a1a0eba1d0473eef58acc95444a ("sony-laptop: use soft rfkill status stored in hw") -Suggested-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> -Link: https://lkml.org/lkml/2017/10/31/463 -Link: https://lkml.kernel.org/r/<CAHp75VcMkXCioCzmLE0+BTmkqc5RSOx9yPO0ectVHMrMvewgwg(a)mail.gmail.com> -Signed-off-by: Markus Elfring <elfring(a)users.sourceforge.net> -Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> -Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> -Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> ---- - drivers/platform/x86/sony-laptop.c | 14 ++++++++------ - 1 file changed, 8 insertions(+), 6 deletions(-) - ---- a/drivers/platform/x86/sony-laptop.c -+++ b/drivers/platform/x86/sony-laptop.c -@@ -1655,17 +1655,19 @@ static int sony_nc_setup_rfkill(struct a - if (!rfk) - return -ENOMEM; - -- if (sony_call_snc_handle(sony_rfkill_handle, 0x200, &result) < 0) { -+ err = sony_call_snc_handle(sony_rfkill_handle, 0x200, &result); -+ if (err < 0) { - rfkill_destroy(rfk); -- return -1; -+ return err; - } - hwblock = !(result & 0x1); - -- if (sony_call_snc_handle(sony_rfkill_handle, -- sony_rfkill_address[nc_type], -- &result) < 0) { -+ err = sony_call_snc_handle(sony_rfkill_handle, -+ sony_rfkill_address[nc_type], -+ &result); -+ if (err < 0) { - rfkill_destroy(rfk); -- return -1; -+ return err; - } - swblock = !(result & 0x2); - diff --git a/queue-4.4/series b/queue-4.4/series index d52e15576..d1ebd64a3 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -76,7 +76,6 @@ powerpc-powernv-cpufreq-fix-the-frequency-read-by-proc-cpuinfo.patch netfilter-ipvs-fix-inappropriate-output-of-procfs.patch powerpc-opal-fix-ebusy-bug-in-acquiring-tokens.patch powerpc-ipic-fix-status-get-and-status-clear.patch -platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch iscsi-target-fix-memory-leak-in-lio_target_tiqn_addtpg.patch target-fix-condition-return-in-core_pr_dump_initiator_port.patch diff --git a/queue-4.9/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch b/queue-4.9/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch deleted file mode 100644 index be1bf544f..000000000 --- a/queue-4.9/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch +++ /dev/null @@ -1,56 +0,0 @@ -From foo@baz Mon Dec 18 14:12:35 CET 2017 -From: Markus Elfring <elfring(a)users.sourceforge.net> -Date: Wed, 1 Nov 2017 18:42:45 +0100 -Subject: platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill() - -From: Markus Elfring <elfring(a)users.sourceforge.net> - - -[ Upstream commit f6c8a317ab208aee223776327c06f23342492d54 ] - -Source code review for a specific software refactoring showed the need -for another correction because the error code "-1" was returned so far -if a call of the function "sony_call_snc_handle" failed here. -Thus assign the return value from these two function calls also to -the variable "err" and provide it in case of a failure. - -Fixes: d6f15ed876b83a1a0eba1d0473eef58acc95444a ("sony-laptop: use soft rfkill status stored in hw") -Suggested-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> -Link: https://lkml.org/lkml/2017/10/31/463 -Link: https://lkml.kernel.org/r/<CAHp75VcMkXCioCzmLE0+BTmkqc5RSOx9yPO0ectVHMrMvewgwg(a)mail.gmail.com> -Signed-off-by: Markus Elfring <elfring(a)users.sourceforge.net> -Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> -Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> -Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> ---- - drivers/platform/x86/sony-laptop.c | 14 ++++++++------ - 1 file changed, 8 insertions(+), 6 deletions(-) - ---- a/drivers/platform/x86/sony-laptop.c -+++ b/drivers/platform/x86/sony-laptop.c -@@ -1660,17 +1660,19 @@ static int sony_nc_setup_rfkill(struct a - if (!rfk) - return -ENOMEM; - -- if (sony_call_snc_handle(sony_rfkill_handle, 0x200, &result) < 0) { -+ err = sony_call_snc_handle(sony_rfkill_handle, 0x200, &result); -+ if (err < 0) { - rfkill_destroy(rfk); -- return -1; -+ return err; - } - hwblock = !(result & 0x1); - -- if (sony_call_snc_handle(sony_rfkill_handle, -- sony_rfkill_address[nc_type], -- &result) < 0) { -+ err = sony_call_snc_handle(sony_rfkill_handle, -+ sony_rfkill_address[nc_type], -+ &result); -+ if (err < 0) { - rfkill_destroy(rfk); -- return -1; -+ return err; - } - swblock = !(result & 0x2); - diff --git a/queue-4.9/series b/queue-4.9/series index ddb7a33cf..295f28ae2 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -121,7 +121,6 @@ netfilter-ipvs-fix-inappropriate-output-of-procfs.patch powerpc-opal-fix-ebusy-bug-in-acquiring-tokens.patch powerpc-ipic-fix-status-get-and-status-clear.patch platform-x86-intel_punit_ipc-fix-resource-ioremap-warning.patch -platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch iscsi-target-fix-memory-leak-in-lio_target_tiqn_addtpg.patch target-fix-condition-return-in-core_pr_dump_initiator_port.patch -- 2.11.0

7 years, 6 months

2
1
0 0

[Linux-stable-mirror] [PATCH 01/14] MIPS: Fix CM region target definitions

by thirtsa.dreyfus＠intel.com

From: Paul Burton <paul.burton(a)imgtec.com> The default CM target field in the GCR_BASE register is encoded with 0 meaning memory & 1 being reserved. However the definitions we use for those bits effectively get these two values backwards - likely because they were copied from the definitions for the CM regions where the target is encoded differently. This results in use setting up GCR_BASE with the reserved target value by default, rather than targeting memory as intended. Although we currently seem to get away with this it's not a great idea to rely upon. Fix this by changing our macros to match the documentated target values. The incorrect encoding became used as of commit 9f98f3dd0c51 ("MIPS: Add generic CM probe & access code") in the Linux v3.15 cycle, and was likely carried forwards from older but unused code introduced by commit 39b8d5254246 ("[MIPS] Add support for MIPS CMP platform.") in the v2.6.26 cycle. Signed-off-by: Paul Burton <paul.burton(a)imgtec.com> Reported-by: Matt Redfearn <matt.redfearn(a)imgtec.com> Cc: Matt Redfearn <matt.redfearn(a)imgtec.com> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: linux-mips(a)linux-mips.org Cc: <stable(a)vger.kernel.org> # v3.15+ --- arch/mips/include/asm/mips-cm.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/mips/include/asm/mips-cm.h b/arch/mips/include/asm/mips-cm.h index f6231b9..c6aaabd 100644 --- a/arch/mips/include/asm/mips-cm.h +++ b/arch/mips/include/asm/mips-cm.h @@ -142,8 +142,8 @@ static inline bool mips_cm_has_l2sync(void) GCR_ACCESSOR_RW(64, 0x008, base) #define CM_GCR_BASE_GCRBASE GENMASK_ULL(47, 15) #define CM_GCR_BASE_CMDEFTGT GENMASK(1, 0) -#define CM_GCR_BASE_CMDEFTGT_DISABLED 0 -#define CM_GCR_BASE_CMDEFTGT_MEM 1 +#define CM_GCR_BASE_CMDEFTGT_MEM 0 +#define CM_GCR_BASE_CMDEFTGT_RESERVED 1 #define CM_GCR_BASE_CMDEFTGT_IOCU0 2 #define CM_GCR_BASE_CMDEFTGT_IOCU1 3 -- 1.9.1 --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

7 years, 6 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH for-4.14.y 0/5] e1000e: Upstream fixes for linux-4.14.y

by Greg KH

On Mon, Dec 11, 2017 at 10:58:10PM +0100, Christian Hesse wrote: > Greg KH <gregkh(a)linuxfoundation.org> on Tue, 2017/12/05 08:35: > > On Tue, Dec 05, 2017 at 08:23:27AM +0100, Christian Hesse wrote: > > > Greg KH <gregkh(a)linuxfoundation.org> on Mon, 2017/12/04 19:37: > > > > On Mon, Dec 04, 2017 at 04:47:00PM +0100, Christian Hesse wrote: > > > > > Amit Pundir <amit.pundir(a)linaro.org> on Mon, 2017/11/27 18:23: > > > > > > Hi Greg, > > > > > > > > > > > > Found few e100e upstream fixes from Benjamin Poirier in lede > > > > > > source tree, https://git.lede-project.org/?p=source.git, and > > > > > > these fixes seem reasonable enough for 4.14.y too. > > > > > > > > > > > > Also submitting an e1000e buffer overrun fix by Sasha Neftin. > > > > > > > > > > > > Cherry-picked and build tested for linux v4.14.2 for ARCH=arm/arm64. > > > > > > > > > > > > Regards, > > > > > > Amit Pundir > > > > > > > > > > > > > > > > > > Benjamin Poirier (4): > > > > > > e1000e: Fix error path in link detection > > > > > > e1000e: Fix return value test > > > > > > e1000e: Separate signaling for link check/link up > > > > > > e1000e: Avoid receiver overrun interrupt bursts > > > > > > > > > > > > Sasha Neftin (1): > > > > > > e1000e: fix buffer overrun while the I219 is processing DMA > > > > > > transactions > > > > > > > > > > Hello everybody, > > > > > > > > > > looks like one of these breaks connectivity on my Thinkpad X250. > > > > > Just downgraded to linux 4.14.2 to verify. > > > > > > > > Can you try the -rc release I just did? It has a fix for this series in > > > > it. > > > > > > It connects with the notebook's built in ethernet port (did not check with > > > 4.14.3) but still fails to see a link when placed in docking station. > > > > Do you have the same issues with 4.15-rc2? > > Just a short heads-up and final result for this thread... > The issue is fixed with Benjamin's patch: > > https://patchwork.kernel.org/patch/10104349/ Any word on getting this patch into Linus's tree anytime soon? thanks, greg k-h

7 years, 6 months

2
1
0 0

[Linux-stable-mirror] [PATCH] clk: sunxi: sun9i-mmc: Implement reset callback for reset controls

by Chen-Yu Tsai

Our MMC host driver now issues a reset, instead of just deasserting the reset control, since commit c34eda69ad4c ("mmc: sunxi: Reset the device at probe time"). The sun9i-mmc clock driver does not support this, and will fail, which results in MMC not probing. This patch implements the reset callback by asserting the reset control, then deasserting it after a small delay. Fixes: 7a6fca879f59 ("clk: sunxi: Add driver for A80 MMC config clocks/resets") Cc: <stable(a)vger.kernel.org> # 4.14.x Signed-off-by: Chen-Yu Tsai <wens(a)csie.org> --- drivers/clk/sunxi/clk-sun9i-mmc.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/clk/sunxi/clk-sun9i-mmc.c b/drivers/clk/sunxi/clk-sun9i-mmc.c index a1a634253d6f..f00d8758ba24 100644 --- a/drivers/clk/sunxi/clk-sun9i-mmc.c +++ b/drivers/clk/sunxi/clk-sun9i-mmc.c @@ -16,6 +16,7 @@ #include <linux/clk.h> #include <linux/clk-provider.h> +#include <linux/delay.h> #include <linux/init.h> #include <linux/of.h> #include <linux/of_device.h> @@ -83,9 +84,20 @@ static int sun9i_mmc_reset_deassert(struct reset_controller_dev *rcdev, return 0; } +static int sun9i_mmc_reset_reset(struct reset_controller_dev *rcdev, + unsigned long id) +{ + sun9i_mmc_reset_assert(rcdev, id); + udelay(10); + sun9i_mmc_reset_deassert(rcdev, id); + + return 0; +} + static const struct reset_control_ops sun9i_mmc_reset_ops = { .assert = sun9i_mmc_reset_assert, .deassert = sun9i_mmc_reset_deassert, + .reset = sun9i_mmc_reset_reset, }; static int sun9i_a80_mmc_config_clk_probe(struct platform_device *pdev) -- 2.15.0

7 years, 6 months

3
2
0 0

Re: [Linux-stable-mirror] [PATCH] mtd: cfi: convert inline functions to macros

by Richard Weinberger

Am Mittwoch, 11. Oktober 2017, 15:54:10 CET schrieb Arnd Bergmann: > The map_word_() functions, dating back to linux-2.6.8, try to perform > bitwise operations on a 'map_word' structure. This may have worked > with compilers that were current then (gcc-3.4 or earlier), but end > up being rather inefficient on any version I could try now (gcc-4.4 or > higher). Specifically we hit a problem analyzed in gcc PR81715 where we > fail to reuse the stack space for local variables. > > This can be seen immediately in the stack consumption for > cfi_staa_erase_varsize() and other functions that (with CONFIG_KASAN) > can be up to 2200 bytes. Changing the inline functions into macros brings > this down to 1280 bytes. Without KASAN, the same problem exists, but > the stack consumption is lower to start with, my patch shrinks it from > 920 to 496 bytes on with arm-linux-gnueabi-gcc-5.4, and saves around > 1KB in .text size for cfi_cmdset_0020.c, as it avoids copying map_word > structures for each call to one of these helpers. > > With the latest gcc-8 snapshot, the problem is fixed in upstream gcc, > but nobody uses that yet, so we should still work around it in mainline > kernels and probably backport the workaround to stable kernels as well. > We had a couple of other functions that suffered from the same gcc bug, > and all of those had a simpler workaround involving dummy variables > in the inline function. Unfortunately that did not work here, the > macro hack was the best I could come up with. > > It would also be helpful to have someone to a little performance testing > on the patch, to see how much it helps in terms of CPU utilitzation. > > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 > Cc: stable(a)vger.kernel.org > Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Acked-by: Richard Weinberger <richard(a)nod.at> Marek, I know you are not super happy with this patch but IMHO this is the solution with the least hassle. While functions offer better type checking I think this functions are trivial enough to exist as macros too. Also forcing users to upgrade/fix their compilers is only possible in a perfect world. Thanks, //richard

7 years, 6 months

4
5
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] usb: musb: da8xx: fix babble condition handling" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From bd3486ded7a0c313a6575343e6c2b21d14476645 Mon Sep 17 00:00:00 2001 From: Bin Liu <b-liu(a)ti.com> Date: Tue, 5 Dec 2017 08:45:30 -0600 Subject: [PATCH] usb: musb: da8xx: fix babble condition handling When babble condition happens, the musb controller might automatically turns off VBUS. On DA8xx platform, the controller generates drvvbus interrupt for turning off VBUS along with the babble interrupt. In this case, we should handle the babble interrupt first and recover from the babble condition. This change ignores the drvvbus interrupt if babble interrupt is also generated at the same time, so the babble recovery routine works properly. Cc: stable(a)vger.kernel.org # v3.16+ Signed-off-by: Bin Liu <b-liu(a)ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c index 0397606a211b..6c036de63272 100644 --- a/drivers/usb/musb/da8xx.c +++ b/drivers/usb/musb/da8xx.c @@ -284,7 +284,15 @@ static irqreturn_t da8xx_musb_interrupt(int irq, void *hci) musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE; portstate(musb->port1_status |= USB_PORT_STAT_POWER); del_timer(&musb->dev_timer); - } else { + } else if (!(musb->int_usb & MUSB_INTR_BABBLE)) { + /* + * When babble condition happens, drvvbus interrupt + * is also generated. Ignore this drvvbus interrupt + * and let babble interrupt handler recovers the + * controller; otherwise, the host-mode flag is lost + * due to the MUSB_DEV_MODE() call below and babble + * recovery logic will not be called. + */ musb->is_active = 0; MUSB_DEV_MODE(musb); otg->default_a = 0;

7 years, 6 months

3
3
0 0

[Linux-stable-mirror] Patch "usb: musb: da8xx: fix babble condition handling" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: musb: da8xx: fix babble condition handling to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-musb-da8xx-fix-babble-condition-handling.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From bd3486ded7a0c313a6575343e6c2b21d14476645 Mon Sep 17 00:00:00 2001 From: Bin Liu <b-liu(a)ti.com> Date: Tue, 5 Dec 2017 08:45:30 -0600 Subject: usb: musb: da8xx: fix babble condition handling From: Bin Liu <b-liu(a)ti.com> commit bd3486ded7a0c313a6575343e6c2b21d14476645 upstream. When babble condition happens, the musb controller might automatically turns off VBUS. On DA8xx platform, the controller generates drvvbus interrupt for turning off VBUS along with the babble interrupt. In this case, we should handle the babble interrupt first and recover from the babble condition. This change ignores the drvvbus interrupt if babble interrupt is also generated at the same time, so the babble recovery routine works properly. Signed-off-by: Bin Liu <b-liu(a)ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/musb/da8xx.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/drivers/usb/musb/da8xx.c +++ b/drivers/usb/musb/da8xx.c @@ -302,7 +302,15 @@ static irqreturn_t da8xx_musb_interrupt( musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE; portstate(musb->port1_status |= USB_PORT_STAT_POWER); del_timer(&otg_workaround); - } else { + } else if (!(musb->int_usb & MUSB_INTR_BABBLE)){ + /* + * When babble condition happens, drvvbus interrupt + * is also generated. Ignore this drvvbus interrupt + * and let babble interrupt handler recovers the + * controller; otherwise, the host-mode flag is lost + * due to the MUSB_DEV_MODE() call below and babble + * recovery logic will not called. + */ musb->is_active = 0; MUSB_DEV_MODE(musb); otg->default_a = 0; Patches currently in stable-queue which might be from b-liu(a)ti.com are queue-4.9/usb-musb-da8xx-fix-babble-condition-handling.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: musb: da8xx: fix babble condition handling" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: musb: da8xx: fix babble condition handling to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-musb-da8xx-fix-babble-condition-handling.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From bd3486ded7a0c313a6575343e6c2b21d14476645 Mon Sep 17 00:00:00 2001 From: Bin Liu <b-liu(a)ti.com> Date: Tue, 5 Dec 2017 08:45:30 -0600 Subject: usb: musb: da8xx: fix babble condition handling From: Bin Liu <b-liu(a)ti.com> commit bd3486ded7a0c313a6575343e6c2b21d14476645 upstream. When babble condition happens, the musb controller might automatically turns off VBUS. On DA8xx platform, the controller generates drvvbus interrupt for turning off VBUS along with the babble interrupt. In this case, we should handle the babble interrupt first and recover from the babble condition. This change ignores the drvvbus interrupt if babble interrupt is also generated at the same time, so the babble recovery routine works properly. Signed-off-by: Bin Liu <b-liu(a)ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/musb/da8xx.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/drivers/usb/musb/da8xx.c +++ b/drivers/usb/musb/da8xx.c @@ -350,7 +350,15 @@ static irqreturn_t da8xx_musb_interrupt( musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE; portstate(musb->port1_status |= USB_PORT_STAT_POWER); del_timer(&otg_workaround); - } else { + } else if (!(musb->int_usb & MUSB_INTR_BABBLE)){ + /* + * When babble condition happens, drvvbus interrupt + * is also generated. Ignore this drvvbus interrupt + * and let babble interrupt handler recovers the + * controller; otherwise, the host-mode flag is lost + * due to the MUSB_DEV_MODE() call below and babble + * recovery logic will not called. + */ musb->is_active = 0; MUSB_DEV_MODE(musb); otg->default_a = 0; Patches currently in stable-queue which might be from b-liu(a)ti.com are queue-4.4/usb-musb-da8xx-fix-babble-condition-handling.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: musb: da8xx: fix babble condition handling" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: musb: da8xx: fix babble condition handling to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-musb-da8xx-fix-babble-condition-handling.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From bd3486ded7a0c313a6575343e6c2b21d14476645 Mon Sep 17 00:00:00 2001 From: Bin Liu <b-liu(a)ti.com> Date: Tue, 5 Dec 2017 08:45:30 -0600 Subject: usb: musb: da8xx: fix babble condition handling From: Bin Liu <b-liu(a)ti.com> commit bd3486ded7a0c313a6575343e6c2b21d14476645 upstream. When babble condition happens, the musb controller might automatically turns off VBUS. On DA8xx platform, the controller generates drvvbus interrupt for turning off VBUS along with the babble interrupt. In this case, we should handle the babble interrupt first and recover from the babble condition. This change ignores the drvvbus interrupt if babble interrupt is also generated at the same time, so the babble recovery routine works properly. Signed-off-by: Bin Liu <b-liu(a)ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/musb/da8xx.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/drivers/usb/musb/da8xx.c +++ b/drivers/usb/musb/da8xx.c @@ -305,7 +305,15 @@ static irqreturn_t da8xx_musb_interrupt( musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE; portstate(musb->port1_status |= USB_PORT_STAT_POWER); del_timer(&otg_workaround); - } else { + } else if (!(musb->int_usb & MUSB_INTR_BABBLE)){ + /* + * When babble condition happens, drvvbus interrupt + * is also generated. Ignore this drvvbus interrupt + * and let babble interrupt handler recovers the + * controller; otherwise, the host-mode flag is lost + * due to the MUSB_DEV_MODE() call below and babble + * recovery logic will not called. + */ musb->is_active = 0; MUSB_DEV_MODE(musb); otg->default_a = 0; Patches currently in stable-queue which might be from b-liu(a)ti.com are queue-4.14/usb-musb-da8xx-fix-babble-condition-handling.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: musb: da8xx: fix babble condition handling" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: musb: da8xx: fix babble condition handling 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=sum… The filename of the patch is: usb-musb-da8xx-fix-babble-condition-handling.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(a)vger.kernel.org> know about it. >From bd3486ded7a0c313a6575343e6c2b21d14476645 Mon Sep 17 00:00:00 2001 From: Bin Liu <b-liu(a)ti.com> Date: Tue, 5 Dec 2017 08:45:30 -0600 Subject: usb: musb: da8xx: fix babble condition handling From: Bin Liu <b-liu(a)ti.com> commit bd3486ded7a0c313a6575343e6c2b21d14476645 upstream. When babble condition happens, the musb controller might automatically turns off VBUS. On DA8xx platform, the controller generates drvvbus interrupt for turning off VBUS along with the babble interrupt. In this case, we should handle the babble interrupt first and recover from the babble condition. This change ignores the drvvbus interrupt if babble interrupt is also generated at the same time, so the babble recovery routine works properly. Signed-off-by: Bin Liu <b-liu(a)ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/musb/da8xx.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/drivers/usb/musb/da8xx.c +++ b/drivers/usb/musb/da8xx.c @@ -350,7 +350,15 @@ static irqreturn_t da8xx_musb_interrupt( musb->xceiv->state = OTG_STATE_A_WAIT_VRISE; portstate(musb->port1_status |= USB_PORT_STAT_POWER); del_timer(&otg_workaround); - } else { + } else if (!(musb->int_usb & MUSB_INTR_BABBLE)){ + /* + * When babble condition happens, drvvbus interrupt + * is also generated. Ignore this drvvbus interrupt + * and let babble interrupt handler recovers the + * controller; otherwise, the host-mode flag is lost + * due to the MUSB_DEV_MODE() call below and babble + * recovery logic will not called. + */ musb->is_active = 0; MUSB_DEV_MODE(musb); otg->default_a = 0; Patches currently in stable-queue which might be from b-liu(a)ti.com are queue-3.18/usb-musb-da8xx-fix-babble-condition-handling.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] patch "binder: fix proc->files use-after-free" added to char-misc-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled binder: fix proc->files use-after-free to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-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 7f3dc0088b98533f17128058fac73cd8b2752ef1 Mon Sep 17 00:00:00 2001 From: Todd Kjos <tkjos(a)android.com> Date: Mon, 27 Nov 2017 09:32:33 -0800 Subject: binder: fix proc->files use-after-free proc->files cleanup is initiated by binder_vma_close. Therefore a reference on the binder_proc is not enough to prevent the files_struct from being released while the binder_proc still has a reference. This can lead to an attempt to dereference the stale pointer obtained from proc->files prior to proc->files cleanup. This has been seen once in task_get_unused_fd_flags() when __alloc_fd() is called with a stale "files". The fix is to protect proc->files with a mutex to prevent cleanup while in use. Signed-off-by: Todd Kjos <tkjos(a)google.com> Cc: stable <stable(a)vger.kernel.org> # 4.14 Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/android/binder.c | 44 +++++++++++++++++++++++++++++++------------- 1 file changed, 31 insertions(+), 13 deletions(-) diff --git a/drivers/android/binder.c b/drivers/android/binder.c index bccec9de0533..a7ecfde66b7b 100644 --- a/drivers/android/binder.c +++ b/drivers/android/binder.c @@ -482,7 +482,8 @@ enum binder_deferred_state { * @tsk task_struct for group_leader of process * (invariant after initialized) * @files files_struct for process - * (invariant after initialized) + * (protected by @files_lock) + * @files_lock mutex to protect @files * @deferred_work_node: element for binder_deferred_list * (protected by binder_deferred_lock) * @deferred_work: bitmap of deferred work to perform @@ -530,6 +531,7 @@ struct binder_proc { int pid; struct task_struct *tsk; struct files_struct *files; + struct mutex files_lock; struct hlist_node deferred_work_node; int deferred_work; bool is_dead; @@ -877,20 +879,26 @@ static void binder_inc_node_tmpref_ilocked(struct binder_node *node); static int task_get_unused_fd_flags(struct binder_proc *proc, int flags) { - struct files_struct *files = proc->files; unsigned long rlim_cur; unsigned long irqs; + int ret; - if (files == NULL) - return -ESRCH; - - if (!lock_task_sighand(proc->tsk, &irqs)) - return -EMFILE; - + mutex_lock(&proc->files_lock); + if (proc->files == NULL) { + ret = -ESRCH; + goto err; + } + if (!lock_task_sighand(proc->tsk, &irqs)) { + ret = -EMFILE; + goto err; + } rlim_cur = task_rlimit(proc->tsk, RLIMIT_NOFILE); unlock_task_sighand(proc->tsk, &irqs); - return __alloc_fd(files, 0, rlim_cur, flags); + ret = __alloc_fd(proc->files, 0, rlim_cur, flags); +err: + mutex_unlock(&proc->files_lock); + return ret; } /* @@ -899,8 +907,10 @@ static int task_get_unused_fd_flags(struct binder_proc *proc, int flags) static void task_fd_install( struct binder_proc *proc, unsigned int fd, struct file *file) { + mutex_lock(&proc->files_lock); if (proc->files) __fd_install(proc->files, fd, file); + mutex_unlock(&proc->files_lock); } /* @@ -910,9 +920,11 @@ static long task_close_fd(struct binder_proc *proc, unsigned int fd) { int retval; - if (proc->files == NULL) - return -ESRCH; - + mutex_lock(&proc->files_lock); + if (proc->files == NULL) { + retval = -ESRCH; + goto err; + } retval = __close_fd(proc->files, fd); /* can't restart close syscall because file table entry was cleared */ if (unlikely(retval == -ERESTARTSYS || @@ -920,7 +932,8 @@ static long task_close_fd(struct binder_proc *proc, unsigned int fd) retval == -ERESTARTNOHAND || retval == -ERESTART_RESTARTBLOCK)) retval = -EINTR; - +err: + mutex_unlock(&proc->files_lock); return retval; } @@ -4627,7 +4640,9 @@ static int binder_mmap(struct file *filp, struct vm_area_struct *vma) ret = binder_alloc_mmap_handler(&proc->alloc, vma); if (ret) return ret; + mutex_lock(&proc->files_lock); proc->files = get_files_struct(current); + mutex_unlock(&proc->files_lock); return 0; err_bad_arg: @@ -4651,6 +4666,7 @@ static int binder_open(struct inode *nodp, struct file *filp) spin_lock_init(&proc->outer_lock); get_task_struct(current->group_leader); proc->tsk = current->group_leader; + mutex_init(&proc->files_lock); INIT_LIST_HEAD(&proc->todo); proc->default_priority = task_nice(current); binder_dev = container_of(filp->private_data, struct binder_device, @@ -4903,9 +4919,11 @@ static void binder_deferred_func(struct work_struct *work) files = NULL; if (defer & BINDER_DEFERRED_PUT_FILES) { + mutex_lock(&proc->files_lock); files = proc->files; if (files) proc->files = NULL; + mutex_unlock(&proc->files_lock); } if (defer & BINDER_DEFERRED_FLUSH) -- 2.15.1

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] usb: musb: da8xx: fix babble condition handling" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From bd3486ded7a0c313a6575343e6c2b21d14476645 Mon Sep 17 00:00:00 2001 From: Bin Liu <b-liu(a)ti.com> Date: Tue, 5 Dec 2017 08:45:30 -0600 Subject: [PATCH] usb: musb: da8xx: fix babble condition handling When babble condition happens, the musb controller might automatically turns off VBUS. On DA8xx platform, the controller generates drvvbus interrupt for turning off VBUS along with the babble interrupt. In this case, we should handle the babble interrupt first and recover from the babble condition. This change ignores the drvvbus interrupt if babble interrupt is also generated at the same time, so the babble recovery routine works properly. Cc: stable(a)vger.kernel.org # v3.16+ Signed-off-by: Bin Liu <b-liu(a)ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c index 0397606a211b..6c036de63272 100644 --- a/drivers/usb/musb/da8xx.c +++ b/drivers/usb/musb/da8xx.c @@ -284,7 +284,15 @@ static irqreturn_t da8xx_musb_interrupt(int irq, void *hci) musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE; portstate(musb->port1_status |= USB_PORT_STAT_POWER); del_timer(&musb->dev_timer); - } else { + } else if (!(musb->int_usb & MUSB_INTR_BABBLE)) { + /* + * When babble condition happens, drvvbus interrupt + * is also generated. Ignore this drvvbus interrupt + * and let babble interrupt handler recovers the + * controller; otherwise, the host-mode flag is lost + * due to the MUSB_DEV_MODE() call below and babble + * recovery logic will not be called. + */ musb->is_active = 0; MUSB_DEV_MODE(musb); otg->default_a = 0;

7 years, 6 months

2
1
0 0

[Linux-stable-mirror] Patch "xfs: fix log block underflow during recovery cycle verification" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xfs: fix log block underflow during recovery cycle verification 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=sum… The filename of the patch is: xfs-fix-log-block-underflow-during-recovery-cycle-verification.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Brian Foster <bfoster(a)redhat.com> Date: Thu, 26 Oct 2017 09:31:16 -0700 Subject: xfs: fix log block underflow during recovery cycle verification From: Brian Foster <bfoster(a)redhat.com> [ Upstream commit 9f2a4505800607e537e9dd9dea4f55c4b0c30c7a ] It is possible for mkfs to format very small filesystems with too small of an internal log with respect to the various minimum size and block count requirements. If this occurs when the log happens to be smaller than the scan window used for cycle verification and the scan wraps the end of the log, the start_blk calculation in xlog_find_head() underflows and leads to an attempt to scan an invalid range of log blocks. This results in log recovery failure and a failed mount. Since there may be filesystems out in the wild with this kind of geometry, we cannot simply refuse to mount. Instead, cap the scan window for cycle verification to the size of the physical log. This ensures that the cycle verification proceeds as expected when the scan wraps the end of the log. Reported-by: Zorro Lang <zlang(a)redhat.com> Signed-off-by: Brian Foster <bfoster(a)redhat.com> Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/xfs/xfs_log_recover.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/xfs/xfs_log_recover.c +++ b/fs/xfs/xfs_log_recover.c @@ -740,7 +740,7 @@ xlog_find_head( * in the in-core log. The following number can be made tighter if * we actually look at the block size of the filesystem. */ - num_scan_bblks = XLOG_TOTAL_REC_SHIFT(log); + num_scan_bblks = min_t(int, log_bbnum, XLOG_TOTAL_REC_SHIFT(log)); if (head_blk >= num_scan_bblks) { /* * We are guaranteed that the entire check can be performed Patches currently in stable-queue which might be from bfoster(a)redhat.com are queue-3.18/xfs-fix-log-block-underflow-during-recovery-cycle-verification.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "video: udlfb: Fix read EDID timeout" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled video: udlfb: Fix read EDID timeout 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=sum… The filename of the patch is: video-udlfb-fix-read-edid-timeout.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Ladislav Michl <ladis(a)linux-mips.org> Date: Thu, 9 Nov 2017 18:09:30 +0100 Subject: video: udlfb: Fix read EDID timeout From: Ladislav Michl <ladis(a)linux-mips.org> [ Upstream commit c98769475575c8a585f5b3952f4b5f90266f699b ] While usb_control_msg function expects timeout in miliseconds, a value of HZ is used. Replace it with USB_CTRL_GET_TIMEOUT and also fix error message which looks like: udlfb: Read EDID byte 78 failed err ffffff92 as error is either negative errno or number of bytes transferred use %d format specifier. Returned EDID is in second byte, so return error when less than two bytes are received. Fixes: 18dffdf8913a ("staging: udlfb: enhance EDID and mode handling support") Signed-off-by: Ladislav Michl <ladis(a)linux-mips.org> Cc: Bernie Thompson <bernie(a)plugable.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/fbdev/udlfb.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- a/drivers/video/fbdev/udlfb.c +++ b/drivers/video/fbdev/udlfb.c @@ -769,11 +769,11 @@ static int dlfb_get_edid(struct dlfb_dat for (i = 0; i < len; i++) { ret = usb_control_msg(dev->udev, - usb_rcvctrlpipe(dev->udev, 0), (0x02), - (0x80 | (0x02 << 5)), i << 8, 0xA1, rbuf, 2, - HZ); - if (ret < 1) { - pr_err("Read EDID byte %d failed err %x\n", i, ret); + usb_rcvctrlpipe(dev->udev, 0), 0x02, + (0x80 | (0x02 << 5)), i << 8, 0xA1, + rbuf, 2, USB_CTRL_GET_TIMEOUT); + if (ret < 2) { + pr_err("Read EDID byte %d failed: %d\n", i, ret); i--; break; } Patches currently in stable-queue which might be from ladis(a)linux-mips.org are queue-3.18/video-udlfb-fix-read-edid-timeout.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "video: fbdev: au1200fb: Return an error code if a memory allocation fails" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled video: fbdev: au1200fb: Return an error code if a memory allocation fails 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=sum… The filename of the patch is: video-fbdev-au1200fb-return-an-error-code-if-a-memory-allocation-fails.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Thu, 9 Nov 2017 18:09:28 +0100 Subject: video: fbdev: au1200fb: Return an error code if a memory allocation fails From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> [ Upstream commit 8cae353e6b01ac3f18097f631cdbceb5ff28c7f3 ] 'ret' is known to be 0 at this point. In case of memory allocation error in 'framebuffer_alloc()', return -ENOMEM instead. Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Cc: Tejun Heo <tj(a)kernel.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/fbdev/au1200fb.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/video/fbdev/au1200fb.c +++ b/drivers/video/fbdev/au1200fb.c @@ -1680,8 +1680,10 @@ static int au1200fb_drv_probe(struct pla fbi = framebuffer_alloc(sizeof(struct au1200fb_device), &dev->dev); - if (!fbi) + if (!fbi) { + ret = -ENOMEM; goto failed; + } _au1200fb_infos[plane] = fbi; fbdev = fbi->par; Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-3.18/video-fbdev-au1200fb-release-some-resources-if-a-memory-allocation-fails.patch queue-3.18/video-fbdev-au1200fb-return-an-error-code-if-a-memory-allocation-fails.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "video: fbdev: au1200fb: Release some resources if a memory allocation fails" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled video: fbdev: au1200fb: Release some resources if a memory allocation fails 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=sum… The filename of the patch is: video-fbdev-au1200fb-release-some-resources-if-a-memory-allocation-fails.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Thu, 9 Nov 2017 18:09:28 +0100 Subject: video: fbdev: au1200fb: Release some resources if a memory allocation fails From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> [ Upstream commit 451f130602619a17c8883dd0b71b11624faffd51 ] We should go through the error handling code instead of returning -ENOMEM directly. Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Cc: Tejun Heo <tj(a)kernel.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/fbdev/au1200fb.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/video/fbdev/au1200fb.c +++ b/drivers/video/fbdev/au1200fb.c @@ -1699,7 +1699,8 @@ static int au1200fb_drv_probe(struct pla if (!fbdev->fb_mem) { print_err("fail to allocate frambuffer (size: %dK))", fbdev->fb_len / 1024); - return -ENOMEM; + ret = -ENOMEM; + goto failed; } /* Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-3.18/video-fbdev-au1200fb-release-some-resources-if-a-memory-allocation-fails.patch queue-3.18/video-fbdev-au1200fb-return-an-error-code-if-a-memory-allocation-fails.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "tty fix oops when rmmod 8250" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tty fix oops when rmmod 8250 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=sum… The filename of the patch is: tty-fix-oops-when-rmmod-8250.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: nixiaoming <nixiaoming(a)huawei.com> Date: Fri, 15 Sep 2017 17:45:56 +0800 Subject: tty fix oops when rmmod 8250 From: nixiaoming <nixiaoming(a)huawei.com> [ Upstream commit c79dde629d2027ca80329c62854a7635e623d527 ] After rmmod 8250.ko tty_kref_put starts kwork (release_one_tty) to release proc interface oops when accessing driver->driver_name in proc_tty_unregister_driver Use jprobe, found driver->driver_name point to 8250.ko static static struct uart_driver serial8250_reg .driver_name= serial, Use name in proc_dir_entry instead of driver->driver_name to fix oops test on linux 4.1.12: BUG: unable to handle kernel paging request at ffffffffa01979de IP: [<ffffffff81310f40>] strchr+0x0/0x30 PGD 1a0d067 PUD 1a0e063 PMD 851c1f067 PTE 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: ... ... [last unloaded: 8250] CPU: 7 PID: 116 Comm: kworker/7:1 Tainted: G O 4.1.12 #1 Hardware name: Insyde RiverForest/Type2 - Board Product Name1, BIOS NE5KV904 12/21/2015 Workqueue: events release_one_tty task: ffff88085b684960 ti: ffff880852884000 task.ti: ffff880852884000 RIP: 0010:[<ffffffff81310f40>] [<ffffffff81310f40>] strchr+0x0/0x30 RSP: 0018:ffff880852887c90 EFLAGS: 00010282 RAX: ffffffff81a5eca0 RBX: ffffffffa01979de RCX: 0000000000000004 RDX: ffff880852887d10 RSI: 000000000000002f RDI: ffffffffa01979de RBP: ffff880852887cd8 R08: 0000000000000000 R09: ffff88085f5d94d0 R10: 0000000000000195 R11: 0000000000000000 R12: ffffffffa01979de R13: ffff880852887d00 R14: ffffffffa01979de R15: ffff88085f02e840 FS: 0000000000000000(0000) GS:ffff88085f5c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffa01979de CR3: 0000000001a0c000 CR4: 00000000001406e0 Stack: ffffffff812349b1 ffff880852887cb8 ffff880852887d10 ffff88085f5cd6c2 ffff880852800a80 ffffffffa01979de ffff880852800a84 0000000000000010 ffff88085bb28bd8 ffff880852887d38 ffffffff812354f0 ffff880852887d08 Call Trace: [<ffffffff812349b1>] ? __xlate_proc_name+0x71/0xd0 [<ffffffff812354f0>] remove_proc_entry+0x40/0x180 [<ffffffff815f6811>] ? _raw_spin_lock_irqsave+0x41/0x60 [<ffffffff813be520>] ? destruct_tty_driver+0x60/0xe0 [<ffffffff81237c68>] proc_tty_unregister_driver+0x28/0x40 [<ffffffff813be548>] destruct_tty_driver+0x88/0xe0 [<ffffffff813be5bd>] tty_driver_kref_put+0x1d/0x20 [<ffffffff813becca>] release_one_tty+0x5a/0xd0 [<ffffffff81074159>] process_one_work+0x139/0x420 [<ffffffff810745a1>] worker_thread+0x121/0x450 [<ffffffff81074480>] ? process_scheduled_works+0x40/0x40 [<ffffffff8107a16c>] kthread+0xec/0x110 [<ffffffff81080000>] ? tg_rt_schedulable+0x210/0x220 [<ffffffff8107a080>] ? kthread_freezable_should_stop+0x80/0x80 [<ffffffff815f7292>] ret_from_fork+0x42/0x70 [<ffffffff8107a080>] ? kthread_freezable_should_stop+0x80/0x80 Signed-off-by: nixiaoming <nixiaoming(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/proc/proc_tty.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/proc/proc_tty.c +++ b/fs/proc/proc_tty.c @@ -14,6 +14,7 @@ #include <linux/tty.h> #include <linux/seq_file.h> #include <linux/bitops.h> +#include "internal.h" /* * The /proc/tty directory inodes... @@ -164,7 +165,7 @@ void proc_tty_unregister_driver(struct t if (!ent) return; - remove_proc_entry(driver->driver_name, proc_tty_driver); + remove_proc_entry(ent->name, proc_tty_driver); driver->proc_entry = NULL; } Patches currently in stable-queue which might be from nixiaoming(a)huawei.com are queue-3.18/tty-fix-oops-when-rmmod-8250.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: phy: isp1301: Add OF device ID table" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: phy: isp1301: Add OF device ID table 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=sum… The filename of the patch is: usb-phy-isp1301-add-of-device-id-table.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Javier Martinez Canillas <javier(a)osg.samsung.com> Date: Wed, 22 Feb 2017 15:23:22 -0300 Subject: usb: phy: isp1301: Add OF device ID table From: Javier Martinez Canillas <javier(a)osg.samsung.com> [ Upstream commit fd567653bdb908009b650f079bfd4b63169e2ac4 ] The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/phy/phy-isp1301.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/drivers/usb/phy/phy-isp1301.c +++ b/drivers/usb/phy/phy-isp1301.c @@ -32,6 +32,12 @@ static const struct i2c_device_id isp130 { } }; +static const struct of_device_id isp1301_of_match[] = { + {.compatible = "nxp,isp1301" }, + { }, +}; +MODULE_DEVICE_TABLE(of, isp1301_of_match); + static struct i2c_client *isp1301_i2c_client; static int __isp1301_write(struct isp1301 *isp, u8 reg, u8 value, u8 clear) @@ -129,6 +135,7 @@ static int isp1301_remove(struct i2c_cli static struct i2c_driver isp1301_driver = { .driver = { .name = DRV_NAME, + .of_match_table = of_match_ptr(isp1301_of_match), }, .probe = isp1301_probe, .remove = isp1301_remove, Patches currently in stable-queue which might be from javier(a)osg.samsung.com are queue-3.18/usb-phy-isp1301-add-of-device-id-table.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "udf: Avoid overflow when session starts at large offset" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled udf: Avoid overflow when session starts at large offset 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=sum… The filename of the patch is: udf-avoid-overflow-when-session-starts-at-large-offset.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Jan Kara <jack(a)suse.cz> Date: Mon, 16 Oct 2017 11:38:11 +0200 Subject: udf: Avoid overflow when session starts at large offset From: Jan Kara <jack(a)suse.cz> [ Upstream commit abdc0eb06964fe1d2fea6dd1391b734d0590365d ] When session starts beyond offset 2^31 the arithmetics in udf_check_vsd() would overflow. Make sure the computation is done in large enough type. Reported-by: Cezary Sliwa <sliwa(a)ifpan.edu.pl> Signed-off-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/udf/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/udf/super.c +++ b/fs/udf/super.c @@ -706,7 +706,7 @@ static loff_t udf_check_vsd(struct super else sectorsize = sb->s_blocksize; - sector += (sbi->s_session << sb->s_blocksize_bits); + sector += (((loff_t)sbi->s_session) << sb->s_blocksize_bits); udf_debug("Starting at sector %u (%ld byte sectors)\n", (unsigned int)(sector >> sb->s_blocksize_bits), Patches currently in stable-queue which might be from jack(a)suse.cz are queue-3.18/mm-handle-0-flags-in-_calc_vm_trans-macro.patch queue-3.18/udf-avoid-overflow-when-session-starts-at-large-offset.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "thermal/drivers/step_wise: Fix temperature regulation misbehavior" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled thermal/drivers/step_wise: Fix temperature regulation misbehavior 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=sum… The filename of the patch is: thermal-drivers-step_wise-fix-temperature-regulation-misbehavior.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Daniel Lezcano <daniel.lezcano(a)linaro.org> Date: Thu, 19 Oct 2017 19:05:58 +0200 Subject: thermal/drivers/step_wise: Fix temperature regulation misbehavior From: Daniel Lezcano <daniel.lezcano(a)linaro.org> [ Upstream commit 07209fcf33542c1ff1e29df2dbdf8f29cdaacb10 ] There is a particular situation when the cooling device is cpufreq and the heat dissipation is not efficient enough where the temperature increases little by little until reaching the critical threshold and leading to a SoC reset. The behavior is reproducible on a hikey6220 with bad heat dissipation (eg. stacked with other boards). Running a simple C program doing while(1); for each CPU of the SoC makes the temperature to reach the passive regulation trip point and ends up to the maximum allowed temperature followed by a reset. This issue has been also reported by running the libhugetlbfs test suite. What is observed is a ping pong between two cpu frequencies, 1.2GHz and 900MHz while the temperature continues to grow. It appears the step wise governor calls get_target_state() the first time with the throttle set to true and the trend to 'raising'. The code selects logically the next state, so the cpu frequency decreases from 1.2GHz to 900MHz, so far so good. The temperature decreases immediately but still stays greater than the trip point, then get_target_state() is called again, this time with the throttle set to true *and* the trend to 'dropping'. From there the algorithm assumes we have to step down the state and the cpu frequency jumps back to 1.2GHz. But the temperature is still higher than the trip point, so get_target_state() is called with throttle=1 and trend='raising' again, we jump to 900MHz, then get_target_state() is called with throttle=1 and trend='dropping', we jump to 1.2GHz, etc ... but the temperature does not stabilizes and continues to increase. [ 237.922654] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 237.922678] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1 [ 237.922690] thermal cooling_device0: cur_state=0 [ 237.922701] thermal cooling_device0: old_target=0, target=1 [ 238.026656] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1 [ 238.026680] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=1 [ 238.026694] thermal cooling_device0: cur_state=1 [ 238.026707] thermal cooling_device0: old_target=1, target=0 [ 238.134647] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 238.134667] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1 [ 238.134679] thermal cooling_device0: cur_state=0 [ 238.134690] thermal cooling_device0: old_target=0, target=1 In this situation the temperature continues to increase while the trend is oscillating between 'dropping' and 'raising'. We need to keep the current state untouched if the throttle is set, so the temperature can decrease or a higher state could be selected, thus preventing this oscillation. Keeping the next_target untouched when 'throttle' is true at 'dropping' time fixes the issue. The following traces show the governor does not change the next state if trend==2 (dropping) and throttle==1. [ 2306.127987] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 2306.128009] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1 [ 2306.128021] thermal cooling_device0: cur_state=0 [ 2306.128031] thermal cooling_device0: old_target=0, target=1 [ 2306.231991] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1 [ 2306.232016] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=1 [ 2306.232030] thermal cooling_device0: cur_state=1 [ 2306.232042] thermal cooling_device0: old_target=1, target=1 [ 2306.335982] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1 [ 2306.336006] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=1 [ 2306.336021] thermal cooling_device0: cur_state=1 [ 2306.336034] thermal cooling_device0: old_target=1, target=1 [ 2306.439984] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1 [ 2306.440008] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=0 [ 2306.440022] thermal cooling_device0: cur_state=1 [ 2306.440034] thermal cooling_device0: old_target=1, target=0 [ ... ] After a while, if the temperature continues to increase, the next state becomes 2 which is 720MHz on the hikey. That results in the temperature stabilizing around the trip point. [ 2455.831982] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 2455.832006] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=0 [ 2455.832019] thermal cooling_device0: cur_state=1 [ 2455.832032] thermal cooling_device0: old_target=1, target=1 [ 2455.935985] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1 [ 2455.936013] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=0 [ 2455.936027] thermal cooling_device0: cur_state=1 [ 2455.936040] thermal cooling_device0: old_target=1, target=1 [ 2456.043984] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1 [ 2456.044009] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=0 [ 2456.044023] thermal cooling_device0: cur_state=1 [ 2456.044036] thermal cooling_device0: old_target=1, target=1 [ 2456.148001] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 2456.148028] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1 [ 2456.148042] thermal cooling_device0: cur_state=1 [ 2456.148055] thermal cooling_device0: old_target=1, target=2 [ 2456.252009] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1 [ 2456.252041] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=0 [ 2456.252058] thermal cooling_device0: cur_state=2 [ 2456.252075] thermal cooling_device0: old_target=2, target=1 IOW, this change is needed to keep the state for a cooling device if the temperature trend is oscillating while the temperature increases slightly. Without this change, the situation above leads to a catastrophic crash by a hardware reset on hikey. This issue has been reported to happen on an OMAP dra7xx also. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> Cc: Keerthy <j-keerthy(a)ti.com> Cc: John Stultz <john.stultz(a)linaro.org> Cc: Leo Yan <leo.yan(a)linaro.org> Tested-by: Keerthy <j-keerthy(a)ti.com> Reviewed-by: Keerthy <j-keerthy(a)ti.com> Signed-off-by: Eduardo Valentin <edubezval(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/thermal/step_wise.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) --- a/drivers/thermal/step_wise.c +++ b/drivers/thermal/step_wise.c @@ -31,8 +31,7 @@ * If the temperature is higher than a trip point, * a. if the trend is THERMAL_TREND_RAISING, use higher cooling * state for this trip point - * b. if the trend is THERMAL_TREND_DROPPING, use lower cooling - * state for this trip point + * b. if the trend is THERMAL_TREND_DROPPING, do nothing * c. if the trend is THERMAL_TREND_RAISE_FULL, use upper limit * for this trip point * d. if the trend is THERMAL_TREND_DROP_FULL, use lower limit @@ -94,9 +93,11 @@ static unsigned long get_target_state(st if (!throttle) next_target = THERMAL_NO_TARGET; } else { - next_target = cur_state - 1; - if (next_target > instance->upper) - next_target = instance->upper; + if (!throttle) { + next_target = cur_state - 1; + if (next_target > instance->upper) + next_target = instance->upper; + } } break; case THERMAL_TREND_DROP_FULL: Patches currently in stable-queue which might be from daniel.lezcano(a)linaro.org are queue-3.18/thermal-drivers-step_wise-fix-temperature-regulation-misbehavior.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "target: Use system workqueue for ALUA transitions" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled target: Use system workqueue for ALUA transitions 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=sum… The filename of the patch is: target-use-system-workqueue-for-alua-transitions.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Mike Christie <mchristi(a)redhat.com> Date: Wed, 1 Mar 2017 23:13:26 -0600 Subject: target: Use system workqueue for ALUA transitions From: Mike Christie <mchristi(a)redhat.com> [ Upstream commit 207ee84133c00a8a2a5bdec94df4a5b37d78881c ] If tcmu-runner is processing a STPG and needs to change the kernel's ALUA state then we cannot use the same work queue for task management requests and ALUA transitions, because we could deadlock. The problem occurs when a STPG times out before tcmu-runner is able to call into target_tg_pt_gp_alua_access_state_store-> core_alua_do_port_transition -> core_alua_do_transition_tg_pt -> queue_work. In this case, the tmr is on the work queue waiting for the STPG to complete, but the STPG transition is now queued behind the waiting tmr. Note: This bug will also be fixed by this patch: http://www.spinics.net/lists/target-devel/msg14560.html which switches the tmr code to use the system workqueues. For both, I am not sure if we need a dedicated workqueue since it is not a performance path and I do not think we need WQ_MEM_RECLAIM to make forward progress to free up memory like the block layer does. 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)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/target_core_alua.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) --- a/drivers/target/target_core_alua.c +++ b/drivers/target/target_core_alua.c @@ -1126,13 +1126,11 @@ static int core_alua_do_transition_tg_pt unsigned long transition_tmo; transition_tmo = tg_pt_gp->tg_pt_gp_implicit_trans_secs * HZ; - queue_delayed_work(tg_pt_gp->tg_pt_gp_dev->tmr_wq, - &tg_pt_gp->tg_pt_gp_transition_work, - transition_tmo); + schedule_delayed_work(&tg_pt_gp->tg_pt_gp_transition_work, + transition_tmo); } else { tg_pt_gp->tg_pt_gp_transition_complete = &wait; - queue_delayed_work(tg_pt_gp->tg_pt_gp_dev->tmr_wq, - &tg_pt_gp->tg_pt_gp_transition_work, 0); + schedule_delayed_work(&tg_pt_gp->tg_pt_gp_transition_work, 0); wait_for_completion(&wait); tg_pt_gp->tg_pt_gp_transition_complete = NULL; } Patches currently in stable-queue which might be from mchristi(a)redhat.com are queue-3.18/target-use-system-workqueue-for-alua-transitions.patch queue-3.18/target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "target:fix condition return in core_pr_dump_initiator_port()" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled target:fix condition return in core_pr_dump_initiator_port() 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=sum… The filename of the patch is: target-fix-condition-return-in-core_pr_dump_initiator_port.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: tangwenji <tang.wenji(a)zte.com.cn> Date: Thu, 24 Aug 2017 19:59:37 +0800 Subject: target:fix condition return in core_pr_dump_initiator_port() From: tangwenji <tang.wenji(a)zte.com.cn> [ Upstream commit 24528f089d0a444070aa4f715ace537e8d6bf168 ] When is pr_reg->isid_present_at_reg is false,this function should return. This fixes a regression originally introduced by: commit d2843c173ee53cf4c12e7dfedc069a5bc76f0ac5 Author: Andy Grover <agrover(a)redhat.com> Date: Thu May 16 10:40:55 2013 -0700 target: Alter core_pr_dump_initiator_port for ease of use Signed-off-by: tangwenji <tang.wenji(a)zte.com.cn> Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/target_core_pr.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/target/target_core_pr.c +++ b/drivers/target/target_core_pr.c @@ -58,8 +58,10 @@ void core_pr_dump_initiator_port( char *buf, u32 size) { - if (!pr_reg->isid_present_at_reg) + if (!pr_reg->isid_present_at_reg) { buf[0] = '\0'; + return; + } snprintf(buf, size, ",i,0x%s", pr_reg->pr_reg_isid); } Patches currently in stable-queue which might be from tang.wenji(a)zte.com.cn are queue-3.18/target-fix-condition-return-in-core_pr_dump_initiator_port.patch queue-3.18/iscsi-target-fix-memory-leak-in-lio_target_tiqn_addtpg.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "target/iscsi: Fix a race condition in iscsit_add_reject_from_cmd()" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled target/iscsi: Fix a race condition in iscsit_add_reject_from_cmd() 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=sum… The filename of the patch is: target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Bart Van Assche <bart.vanassche(a)wdc.com> Date: Tue, 31 Oct 2017 11:03:17 -0700 Subject: target/iscsi: Fix a race condition in iscsit_add_reject_from_cmd() From: Bart Van Assche <bart.vanassche(a)wdc.com> [ Upstream commit cfe2b621bb18d86e93271febf8c6e37622da2d14 ] Avoid that cmd->se_cmd.se_tfo is read after a command has already been freed. Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Mike Christie <mchristi(a)redhat.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/iscsi/iscsi_target.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/target/iscsi/iscsi_target.c +++ b/drivers/target/iscsi/iscsi_target.c @@ -674,6 +674,7 @@ static int iscsit_add_reject_from_cmd( unsigned char *buf) { struct iscsi_conn *conn; + const bool do_put = cmd->se_cmd.se_tfo != NULL; if (!cmd->conn) { pr_err("cmd->conn is NULL for ITT: 0x%08x\n", @@ -704,7 +705,7 @@ static int iscsit_add_reject_from_cmd( * Perform the kref_put now if se_cmd has already been setup by * scsit_setup_scsi_cmd() */ - if (cmd->se_cmd.se_tfo != NULL) { + if (do_put) { pr_debug("iscsi reject: calling target_put_sess_cmd >>>>>>\n"); target_put_sess_cmd(&cmd->se_cmd); } Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are queue-3.18/target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "target/file: Do not return error for UNMAP if length is zero" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled target/file: Do not return error for UNMAP if length is zero 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=sum… The filename of the patch is: target-file-do-not-return-error-for-unmap-if-length-is-zero.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Jiang Yi <jiangyilism(a)gmail.com> Date: Fri, 11 Aug 2017 11:29:44 +0800 Subject: target/file: Do not return error for UNMAP if length is zero From: Jiang Yi <jiangyilism(a)gmail.com> [ Upstream commit 594e25e73440863981032d76c9b1e33409ceff6e ] The function fd_execute_unmap() in target_core_file.c calles ret = file->f_op->fallocate(file, mode, pos, len); Some filesystems implement fallocate() to return error if length is zero (e.g. btrfs) but according to SCSI Block Commands spec UNMAP should return success for zero length. Signed-off-by: Jiang Yi <jiangyilism(a)gmail.com> Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/target_core_file.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/target/target_core_file.c +++ b/drivers/target/target_core_file.c @@ -592,6 +592,10 @@ fd_do_unmap(struct se_cmd *cmd, void *pr struct inode *inode = file->f_mapping->host; int ret; + if (!nolb) { + return 0; + } + if (cmd->se_dev->dev_attrib.pi_prot_type) { ret = fd_do_prot_unmap(cmd, lba, nolb); if (ret) Patches currently in stable-queue which might be from jiangyilism(a)gmail.com are queue-3.18/target-file-do-not-return-error-for-unmap-if-length-is-zero.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "scsi: bfa: integer overflow in debugfs" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: bfa: integer overflow in debugfs 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=sum… The filename of the patch is: scsi-bfa-integer-overflow-in-debugfs.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Dan Carpenter <dan.carpenter(a)oracle.com> Date: Wed, 4 Oct 2017 10:50:37 +0300 Subject: scsi: bfa: integer overflow in debugfs From: Dan Carpenter <dan.carpenter(a)oracle.com> [ Upstream commit 3e351275655d3c84dc28abf170def9786db5176d ] We could allocate less memory than intended because we do: bfad->regdata = kzalloc(len << 2, GFP_KERNEL); The shift can overflow leading to a crash. This is debugfs code so the impact is very small. I fixed the network version of this in March with commit 13e2d5187f6b ("bna: integer overflow bug in debugfs"). Fixes: ab2a9ba189e8 ("[SCSI] bfa: add debugfs support") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/bfa/bfad_debugfs.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/drivers/scsi/bfa/bfad_debugfs.c +++ b/drivers/scsi/bfa/bfad_debugfs.c @@ -254,7 +254,8 @@ bfad_debugfs_write_regrd(struct file *fi struct bfad_s *bfad = port->bfad; struct bfa_s *bfa = &bfad->bfa; struct bfa_ioc_s *ioc = &bfa->ioc; - int addr, len, rc, i; + int addr, rc, i; + u32 len; u32 *regbuf; void __iomem *rb, *reg_addr; unsigned long flags; @@ -274,7 +275,7 @@ bfad_debugfs_write_regrd(struct file *fi } rc = sscanf(kern_buf, "%x:%x", &addr, &len); - if (rc < 2) { + if (rc < 2 || len > (UINT_MAX >> 2)) { printk(KERN_INFO "bfad[%d]: %s failed to read user buf\n", bfad->inst_no, __func__); Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are queue-3.18/scsi-bfa-integer-overflow-in-debugfs.patch queue-3.18/fbdev-controlfb-add-missing-modes-to-fix-out-of-bounds-access.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "scsi: scsi_devinfo: Add REPORTLUN2 to EMC SYMMETRIX blacklist entry" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: scsi_devinfo: Add REPORTLUN2 to EMC SYMMETRIX blacklist entry 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=sum… The filename of the patch is: scsi-scsi_devinfo-add-reportlun2-to-emc-symmetrix-blacklist-entry.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Kurt Garloff <garloff(a)suse.de> Date: Tue, 17 Oct 2017 09:10:45 +0200 Subject: scsi: scsi_devinfo: Add REPORTLUN2 to EMC SYMMETRIX blacklist entry From: Kurt Garloff <garloff(a)suse.de> [ Upstream commit 909cf3e16a5274fe2127cf3cea5c8dba77b2c412 ] All EMC SYMMETRIX support REPORT_LUNS, even if configured to report SCSI-2 for whatever reason. Signed-off-by: Kurt Garloff <garloff(a)suse.de> Signed-off-by: Hannes Reinecke <hare(a)suse.de> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/scsi_devinfo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/scsi/scsi_devinfo.c +++ b/drivers/scsi/scsi_devinfo.c @@ -160,7 +160,7 @@ static struct { {"DGC", "RAID", NULL, BLIST_SPARSELUN}, /* Dell PV 650F, storage on LUN 0 */ {"DGC", "DISK", NULL, BLIST_SPARSELUN}, /* Dell PV 650F, no storage on LUN 0 */ {"EMC", "Invista", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, - {"EMC", "SYMMETRIX", NULL, BLIST_SPARSELUN | BLIST_LARGELUN | BLIST_FORCELUN}, + {"EMC", "SYMMETRIX", NULL, BLIST_SPARSELUN | BLIST_LARGELUN | BLIST_REPORTLUN2}, {"EMULEX", "MD21/S2 ESDI", NULL, BLIST_SINGLELUN}, {"easyRAID", "16P", NULL, BLIST_NOREPORTLUN}, {"easyRAID", "X6P", NULL, BLIST_NOREPORTLUN}, Patches currently in stable-queue which might be from garloff(a)suse.de are queue-3.18/scsi-scsi_devinfo-add-reportlun2-to-emc-symmetrix-blacklist-entry.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "sched/deadline: Use deadline instead of period when calculating overflow" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sched/deadline: Use deadline instead of period when calculating overflow 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=sum… The filename of the patch is: sched-deadline-use-deadline-instead-of-period-when-calculating-overflow.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org> Date: Thu, 2 Mar 2017 15:10:59 +0100 Subject: sched/deadline: Use deadline instead of period when calculating overflow From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org> [ Upstream commit 2317d5f1c34913bac5971d93d69fb6c31bb74670 ] I was testing Daniel's changes with his test case, and tweaked it a little. Instead of having the runtime equal to the deadline, I increased the deadline ten fold. Daniel's test case had: attr.sched_runtime = 2 * 1000 * 1000; /* 2 ms */ attr.sched_deadline = 2 * 1000 * 1000; /* 2 ms */ attr.sched_period = 2 * 1000 * 1000 * 1000; /* 2 s */ To make it more interesting, I changed it to: attr.sched_runtime = 2 * 1000 * 1000; /* 2 ms */ attr.sched_deadline = 20 * 1000 * 1000; /* 20 ms */ attr.sched_period = 2 * 1000 * 1000 * 1000; /* 2 s */ The results were rather surprising. The behavior that Daniel's patch was fixing came back. The task started using much more than .1% of the CPU. More like 20%. Looking into this I found that it was due to the dl_entity_overflow() constantly returning true. That's because it uses the relative period against relative runtime vs the absolute deadline against absolute runtime. runtime / (deadline - t) > dl_runtime / dl_period There's even a comment mentioning this, and saying that when relative deadline equals relative period, that the equation is the same as using deadline instead of period. That comment is backwards! What we really want is: runtime / (deadline - t) > dl_runtime / dl_deadline We care about if the runtime can make its deadline, not its period. And then we can say "when the deadline equals the period, the equation is the same as using dl_period instead of dl_deadline". After correcting this, now when the task gets enqueued, it can throttle correctly, and Daniel's fix to the throttling of sleeping deadline tasks works even when the runtime and deadline are not the same. Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Reviewed-by: Daniel Bristot de Oliveira <bristot(a)redhat.com> Cc: Juri Lelli <juri.lelli(a)arm.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Luca Abeni <luca.abeni(a)santannapisa.it> Cc: Mike Galbraith <efault(a)gmx.de> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Romulo Silva de Oliveira <romulo.deoliveira(a)ufsc.br> Cc: Steven Rostedt <rostedt(a)goodmis.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Tommaso Cucinotta <tommaso.cucinotta(a)sssup.it> Link: http://lkml.kernel.org/r/02135a27f1ae3fe5fd032568a5a2f370e190e8d7.148839293… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/sched/deadline.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -368,13 +368,13 @@ static void replenish_dl_entity(struct s * * This function returns true if: * - * runtime / (deadline - t) > dl_runtime / dl_period , + * runtime / (deadline - t) > dl_runtime / dl_deadline , * * IOW we can't recycle current parameters. * - * Notice that the bandwidth check is done against the period. For + * Notice that the bandwidth check is done against the deadline. For * task with deadline equal to period this is the same of using - * dl_deadline instead of dl_period in the equation above. + * dl_period instead of dl_deadline in the equation above. */ static bool dl_entity_overflow(struct sched_dl_entity *dl_se, struct sched_dl_entity *pi_se, u64 t) @@ -399,7 +399,7 @@ static bool dl_entity_overflow(struct sc * of anything below microseconds resolution is actually fiction * (but still we want to give the user that illusion >;). */ - left = (pi_se->dl_period >> DL_SCALE) * (dl_se->runtime >> DL_SCALE); + left = (pi_se->dl_deadline >> DL_SCALE) * (dl_se->runtime >> DL_SCALE); right = ((dl_se->deadline - t) >> DL_SCALE) * (pi_se->dl_runtime >> DL_SCALE); Patches currently in stable-queue which might be from rostedt(a)goodmis.org are queue-3.18/sched-deadline-use-deadline-instead-of-period-when-calculating-overflow.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "raid5: Set R5_Expanded on parity devices as well as data." has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled raid5: Set R5_Expanded on parity devices as well as data. 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=sum… The filename of the patch is: raid5-set-r5_expanded-on-parity-devices-as-well-as-data.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: NeilBrown <neilb(a)suse.com> Date: Tue, 17 Oct 2017 16:18:36 +1100 Subject: raid5: Set R5_Expanded on parity devices as well as data. From: NeilBrown <neilb(a)suse.com> [ Upstream commit 235b6003fb28f0dd8e7ed8fbdb088bb548291766 ] When reshaping a fully degraded raid5/raid6 to a larger nubmer of devices, the new device(s) are not in-sync and so that can make the newly grown stripe appear to be "failed". To avoid this, we set the R5_Expanded flag to say "Even though this device is not fully in-sync, this block is safe so don't treat the device as failed for this stripe". This flag is set for data devices, not not for parity devices. Consequently, if you have a RAID6 with two devices that are partly recovered and a spare, and start a reshape to include the spare, then when the reshape gets past the point where the recovery was up to, it will think the stripes are failed and will get into an infinite loop, failing to make progress. So when contructing parity on an EXPAND_READY stripe, set R5_Expanded. Reported-by: Curt <lightspd(a)gmail.com> Signed-off-by: NeilBrown <neilb(a)suse.com> Signed-off-by: Shaohua Li <shli(a)fb.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/raid5.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/md/raid5.c +++ b/drivers/md/raid5.c @@ -1454,8 +1454,11 @@ static void ops_complete_reconstruct(voi struct r5dev *dev = &sh->dev[i]; if (dev->written || i == pd_idx || i == qd_idx) { - if (!discard && !test_bit(R5_SkipCopy, &dev->flags)) + if (!discard && !test_bit(R5_SkipCopy, &dev->flags)) { set_bit(R5_UPTODATE, &dev->flags); + if (test_bit(STRIPE_EXPAND_READY, &sh->state)) + set_bit(R5_Expanded, &dev->flags); + } if (fua) set_bit(R5_WantFUA, &dev->flags); if (sync) Patches currently in stable-queue which might be from neilb(a)suse.com are queue-3.18/autofs-fix-careless-error-in-recent-commit.patch queue-3.18/raid5-set-r5_expanded-on-parity-devices-as-well-as-data.patch queue-3.18/nfsd-fix-nfsd_reset_versions-for-nfsv4.patch queue-3.18/nfsd-fix-nfsd_minorversion-..-nfsd_avail.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "ppp: Destroy the mutex when cleanup" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ppp: Destroy the mutex when cleanup 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=sum… The filename of the patch is: ppp-destroy-the-mutex-when-cleanup.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Gao Feng <gfree.wind(a)vip.163.com> Date: Tue, 31 Oct 2017 18:25:37 +0800 Subject: ppp: Destroy the mutex when cleanup From: Gao Feng <gfree.wind(a)vip.163.com> [ Upstream commit f02b2320b27c16b644691267ee3b5c110846f49e ] The mutex_destroy only makes sense when enable DEBUG_MUTEX. For the good readbility, it's better to invoke it in exit func when the init func invokes mutex_init. Signed-off-by: Gao Feng <gfree.wind(a)vip.163.com> Acked-by: Guillaume Nault <g.nault(a)alphalink.fr> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ppp/ppp_generic.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/net/ppp/ppp_generic.c +++ b/drivers/net/ppp/ppp_generic.c @@ -916,6 +916,7 @@ static __net_exit void ppp_exit_net(stru { struct ppp_net *pn = net_generic(net, ppp_net_id); + mutex_destroy(&pn->all_ppp_mutex); idr_destroy(&pn->units_idr); } Patches currently in stable-queue which might be from gfree.wind(a)vip.163.com are queue-3.18/ppp-destroy-the-mutex-when-cleanup.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo 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=sum… The filename of the patch is: powerpc-powernv-cpufreq-fix-the-frequency-read-by-proc-cpuinfo.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Shriya <shriyak(a)linux.vnet.ibm.com> Date: Fri, 13 Oct 2017 10:06:41 +0530 Subject: powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo From: Shriya <shriyak(a)linux.vnet.ibm.com> [ Upstream commit cd77b5ce208c153260ed7882d8910f2395bfaabd ] The call to /proc/cpuinfo in turn calls cpufreq_quick_get() which returns the last frequency requested by the kernel, but may not reflect the actual frequency the processor is running at. This patch makes a call to cpufreq_get() instead which returns the current frequency reported by the hardware. Fixes: fb5153d05a7d ("powerpc: powernv: Implement ppc_md.get_proc_freq()") Signed-off-by: Shriya <shriyak(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/platforms/powernv/setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/platforms/powernv/setup.c +++ b/arch/powerpc/platforms/powernv/setup.c @@ -319,7 +319,7 @@ static unsigned long pnv_get_proc_freq(u { unsigned long ret_freq; - ret_freq = cpufreq_quick_get(cpu) * 1000ul; + ret_freq = cpufreq_get(cpu) * 1000ul; /* * If the backend cpufreq driver does not exist, Patches currently in stable-queue which might be from shriyak(a)linux.vnet.ibm.com are queue-3.18/powerpc-powernv-cpufreq-fix-the-frequency-read-by-proc-cpuinfo.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/opal: Fix EBUSY bug in acquiring tokens" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/opal: Fix EBUSY bug in acquiring tokens 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=sum… The filename of the patch is: powerpc-opal-fix-ebusy-bug-in-acquiring-tokens.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: "William A. Kennington III" <wak(a)google.com> Date: Fri, 22 Sep 2017 16:58:00 -0700 Subject: powerpc/opal: Fix EBUSY bug in acquiring tokens From: "William A. Kennington III" <wak(a)google.com> [ Upstream commit 71e24d7731a2903b1ae2bba2b2971c654d9c2aa6 ] The current code checks the completion map to look for the first token that is complete. In some cases, a completion can come in but the token can still be on lease to the caller processing the completion. If this completed but unreleased token is the first token found in the bitmap by another tasks trying to acquire a token, then the __test_and_set_bit call will fail since the token will still be on lease. The acquisition will then fail with an EBUSY. This patch reorganizes the acquisition code to look at the opal_async_token_map for an unleased token. If the token has no lease it must have no outstanding completions so we should never see an EBUSY, unless we have leased out too many tokens. Since opal_async_get_token_inrerruptible is protected by a semaphore, we will practically never see EBUSY anymore. Fixes: 8d7248232208 ("powerpc/powernv: Infrastructure to support OPAL async completion") Signed-off-by: William A. Kennington III <wak(a)google.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/platforms/powernv/opal-async.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/arch/powerpc/platforms/powernv/opal-async.c +++ b/arch/powerpc/platforms/powernv/opal-async.c @@ -39,18 +39,18 @@ int __opal_async_get_token(void) int token; spin_lock_irqsave(&opal_async_comp_lock, flags); - token = find_first_bit(opal_async_complete_map, opal_max_async_tokens); + token = find_first_zero_bit(opal_async_token_map, opal_max_async_tokens); if (token >= opal_max_async_tokens) { token = -EBUSY; goto out; } - if (__test_and_set_bit(token, opal_async_token_map)) { + if (!__test_and_clear_bit(token, opal_async_complete_map)) { token = -EBUSY; goto out; } - __clear_bit(token, opal_async_complete_map); + __set_bit(token, opal_async_token_map); out: spin_unlock_irqrestore(&opal_async_comp_lock, flags); Patches currently in stable-queue which might be from wak(a)google.com are queue-3.18/powerpc-opal-fix-ebusy-bug-in-acquiring-tokens.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill()" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill() 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=sum… The filename of the patch is: platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Markus Elfring <elfring(a)users.sourceforge.net> Date: Wed, 1 Nov 2017 18:42:45 +0100 Subject: platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill() From: Markus Elfring <elfring(a)users.sourceforge.net> [ Upstream commit f6c8a317ab208aee223776327c06f23342492d54 ] Source code review for a specific software refactoring showed the need for another correction because the error code "-1" was returned so far if a call of the function "sony_call_snc_handle" failed here. Thus assign the return value from these two function calls also to the variable "err" and provide it in case of a failure. Fixes: d6f15ed876b83a1a0eba1d0473eef58acc95444a ("sony-laptop: use soft rfkill status stored in hw") Suggested-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> Link: https://lkml.org/lkml/2017/10/31/463 Link: https://lkml.kernel.org/r/<CAHp75VcMkXCioCzmLE0+BTmkqc5RSOx9yPO0ectVHMrMvewgwg(a)mail.gmail.com> Signed-off-by: Markus Elfring <elfring(a)users.sourceforge.net> Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/platform/x86/sony-laptop.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) --- a/drivers/platform/x86/sony-laptop.c +++ b/drivers/platform/x86/sony-laptop.c @@ -1654,17 +1654,19 @@ static int sony_nc_setup_rfkill(struct a if (!rfk) return -ENOMEM; - if (sony_call_snc_handle(sony_rfkill_handle, 0x200, &result) < 0) { + err = sony_call_snc_handle(sony_rfkill_handle, 0x200, &result); + if (err < 0) { rfkill_destroy(rfk); - return -1; + return err; } hwblock = !(result & 0x1); - if (sony_call_snc_handle(sony_rfkill_handle, - sony_rfkill_address[nc_type], - &result) < 0) { + err = sony_call_snc_handle(sony_rfkill_handle, + sony_rfkill_address[nc_type], + &result); + if (err < 0) { rfkill_destroy(rfk); - return -1; + return err; } swblock = !(result & 0x2); Patches currently in stable-queue which might be from elfring(a)users.sourceforge.net are queue-3.18/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "pinctrl: adi2: Fix Kconfig build problem" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled pinctrl: adi2: Fix Kconfig build problem 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=sum… The filename of the patch is: pinctrl-adi2-fix-kconfig-build-problem.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Linus Walleij <linus.walleij(a)linaro.org> Date: Wed, 11 Oct 2017 11:57:15 +0200 Subject: pinctrl: adi2: Fix Kconfig build problem From: Linus Walleij <linus.walleij(a)linaro.org> [ Upstream commit 1c363531dd814dc4fe10865722bf6b0f72ce4673 ] The build robot is complaining on Blackfin: drivers/pinctrl/pinctrl-adi2.c: In function 'port_setup': >> drivers/pinctrl/pinctrl-adi2.c:221:21: error: dereferencing pointer to incomplete type 'struct gpio_port_t' writew(readw(&regs->port_fer) & ~BIT(offset), ^~ drivers/pinctrl/pinctrl-adi2.c: In function 'adi_gpio_ack_irq': >> drivers/pinctrl/pinctrl-adi2.c:266:18: error: dereferencing pointer to incomplete type 'struct bfin_pint_regs' if (readl(&regs->invert_set) & pintbit) ^~ It seems the driver need to include <asm/gpio.h> and <asm/irq.h> to compile. The Blackfin architecture was re-defining the Kconfig PINCTRL symbol which is not OK, so replaced this with PINCTRL_BLACKFIN_ADI2 which selects PINCTRL and PINCTRL_ADI2 just like most arches do. Further, the old GPIO driver symbol GPIO_ADI was possible to select at the same time as selecting PINCTRL. This was not working because the arch-local <asm/gpio.h> header contains an explicit #ifndef PINCTRL clause making compilation break if you combine them. The same is true for DEBUG_MMRS. Make sure the ADI2 pinctrl driver is not selected at the same time as the old GPIO implementation. (This should be converted to use gpiolib or pincontrol and move to drivers/...) Also make sure the old GPIO_ADI driver or DEBUG_MMRS is not selected at the same time as the new PINCTRL implementation, and only make PINCTRL_ADI2 selectable for the Blackfin families that actually have it. This way it is still possible to add e.g. I2C-based pin control expanders on the Blackfin. Cc: Steven Miao <realmz6(a)gmail.com> Cc: Huanhuan Feng <huanhuan.feng(a)analog.com> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/blackfin/Kconfig | 7 +++++-- arch/blackfin/Kconfig.debug | 1 + drivers/pinctrl/Kconfig | 3 ++- 3 files changed, 8 insertions(+), 3 deletions(-) --- a/arch/blackfin/Kconfig +++ b/arch/blackfin/Kconfig @@ -318,11 +318,14 @@ config BF53x config GPIO_ADI def_bool y + depends on !PINCTRL depends on (BF51x || BF52x || BF53x || BF538 || BF539 || BF561) -config PINCTRL +config PINCTRL_BLACKFIN_ADI2 def_bool y - depends on BF54x || BF60x + depends on (BF54x || BF60x) + select PINCTRL + select PINCTRL_ADI2 config MEM_MT48LC64M4A2FB_7E bool --- a/arch/blackfin/Kconfig.debug +++ b/arch/blackfin/Kconfig.debug @@ -17,6 +17,7 @@ config DEBUG_VERBOSE config DEBUG_MMRS tristate "Generate Blackfin MMR tree" + depends on !PINCTRL select DEBUG_FS help Create a tree of Blackfin MMRs via the debugfs tree. If --- a/drivers/pinctrl/Kconfig +++ b/drivers/pinctrl/Kconfig @@ -28,7 +28,8 @@ config DEBUG_PINCTRL config PINCTRL_ADI2 bool "ADI pin controller driver" - depends on BLACKFIN + depends on (BF54x || BF60x) + depends on !GPIO_ADI select PINMUX select IRQ_DOMAIN help Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are queue-3.18/pinctrl-adi2-fix-kconfig-build-problem.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/ipic: Fix status get and status clear" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/ipic: Fix status get and status clear 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=sum… The filename of the patch is: powerpc-ipic-fix-status-get-and-status-clear.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Christophe Leroy <christophe.leroy(a)c-s.fr> Date: Wed, 18 Oct 2017 11:16:47 +0200 Subject: powerpc/ipic: Fix status get and status clear From: Christophe Leroy <christophe.leroy(a)c-s.fr> [ Upstream commit 6b148a7ce72a7f87c81cbcde48af014abc0516a9 ] IPIC Status is provided by register IPIC_SERSR and not by IPIC_SERMR which is the mask register. Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/sysdev/ipic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/powerpc/sysdev/ipic.c +++ b/arch/powerpc/sysdev/ipic.c @@ -844,12 +844,12 @@ void ipic_disable_mcp(enum ipic_mcp_irq u32 ipic_get_mcp_status(void) { - return ipic_read(primary_ipic->regs, IPIC_SERMR); + return ipic_read(primary_ipic->regs, IPIC_SERSR); } void ipic_clear_mcp_status(u32 mask) { - ipic_write(primary_ipic->regs, IPIC_SERMR, mask); + ipic_write(primary_ipic->regs, IPIC_SERSR, mask); } /* Return an interrupt vector or NO_IRQ if no interrupt is pending. */ Patches currently in stable-queue which might be from christophe.leroy(a)c-s.fr are queue-3.18/powerpc-ipic-fix-status-get-and-status-clear.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "perf symbols: Fix symbols__fixup_end heuristic for corner cases" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf symbols: Fix symbols__fixup_end heuristic for corner cases 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=sum… The filename of the patch is: perf-symbols-fix-symbols__fixup_end-heuristic-for-corner-cases.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Daniel Borkmann <daniel(a)iogearbox.net> Date: Wed, 15 Mar 2017 22:53:37 +0100 Subject: perf symbols: Fix symbols__fixup_end heuristic for corner cases From: Daniel Borkmann <daniel(a)iogearbox.net> [ Upstream commit e7ede72a6d40cb3a30c087142d79381ca8a31dab ] The current symbols__fixup_end() heuristic for the last entry in the rb tree is suboptimal as it leads to not being able to recognize the symbol in the call graph in a couple of corner cases, for example: i) If the symbol has a start address (f.e. exposed via kallsyms) that is at a page boundary, then the roundup(curr->start, 4096) for the last entry will result in curr->start == curr->end with a symbol length of zero. ii) If the symbol has a start address that is shortly before a page boundary, then also here, curr->end - curr->start will just be very few bytes, where it's unrealistic that we could perform a match against. Instead, change the heuristic to roundup(curr->start, 4096) + 4096, so that we can catch such corner cases and have a better chance to find that specific symbol. It's still just best effort as the real end of the symbol is unknown to us (and could even be at a larger offset than the current range), but better than the current situation. Alexei reported that he recently run into case i) with a JITed eBPF program (these are all page aligned) as the last symbol which wasn't properly shown in the call graph (while other eBPF program symbols in the rb tree were displayed correctly). Since this is a generic issue, lets try to improve the heuristic a bit. Reported-and-Tested-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Fixes: 2e538c4a1847 ("perf tools: Improve kernel/modules symbol lookup") Link: http://lkml.kernel.org/r/bb5c80d27743be6f12afc68405f1956a330e1bc9.148961436… Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/util/symbol.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/perf/util/symbol.c +++ b/tools/perf/util/symbol.c @@ -191,7 +191,7 @@ void symbols__fixup_end(struct rb_root * /* Last entry */ if (curr->end == curr->start) - curr->end = roundup(curr->start, 4096); + curr->end = roundup(curr->start, 4096) + 4096; } void __map_groups__fixup_end(struct map_groups *mg, enum map_type type) Patches currently in stable-queue which might be from daniel(a)iogearbox.net are queue-3.18/perf-symbols-fix-symbols__fixup_end-heuristic-for-corner-cases.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "PCI/PME: Handle invalid data when reading Root Status" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled PCI/PME: Handle invalid data when reading Root Status 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=sum… The filename of the patch is: pci-pme-handle-invalid-data-when-reading-root-status.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Qiang <zhengqiang10(a)huawei.com> Date: Thu, 28 Sep 2017 11:54:34 +0800 Subject: PCI/PME: Handle invalid data when reading Root Status From: Qiang <zhengqiang10(a)huawei.com> [ Upstream commit 3ad3f8ce50914288731a3018b27ee44ab803e170 ] PCIe PME and native hotplug share the same interrupt number, so hotplug interrupts are also processed by PME. In some cases, e.g., a Link Down interrupt, a device may be present but unreachable, so when we try to read its Root Status register, the read fails and we get all ones data (0xffffffff). Previously, we interpreted that data as PCI_EXP_RTSTA_PME being set, i.e., "some device has asserted PME," so we scheduled pcie_pme_work_fn(). This caused an infinite loop because pcie_pme_work_fn() tried to handle PME requests until PCI_EXP_RTSTA_PME is cleared, but with the link down, PCI_EXP_RTSTA_PME can't be cleared. Check for the invalid 0xffffffff data everywhere we read the Root Status register. 1469d17dd341 ("PCI: pciehp: Handle invalid data when reading from non-existent devices") added similar checks in the hotplug driver. Signed-off-by: Qiang Zheng <zhengqiang10(a)huawei.com> [bhelgaas: changelog, also check in pcie_pme_work_fn(), use "~0" to follow other similar checks] Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pci/pcie/pme.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/pci/pcie/pme.c +++ b/drivers/pci/pcie/pme.c @@ -233,6 +233,9 @@ static void pcie_pme_work_fn(struct work break; pcie_capability_read_dword(port, PCI_EXP_RTSTA, &rtsta); + if (rtsta == (u32) ~0) + break; + if (rtsta & PCI_EXP_RTSTA_PME) { /* * Clear PME status of the port. If there are other @@ -280,7 +283,7 @@ static irqreturn_t pcie_pme_irq(int irq, spin_lock_irqsave(&data->lock, flags); pcie_capability_read_dword(port, PCI_EXP_RTSTA, &rtsta); - if (!(rtsta & PCI_EXP_RTSTA_PME)) { + if (rtsta == (u32) ~0 || !(rtsta & PCI_EXP_RTSTA_PME)) { spin_unlock_irqrestore(&data->lock, flags); return IRQ_NONE; } Patches currently in stable-queue which might be from zhengqiang10(a)huawei.com are queue-3.18/pci-pme-handle-invalid-data-when-reading-root-status.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "PCI: Detach driver before procfs & sysfs teardown on device remove" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled PCI: Detach driver before procfs & sysfs teardown on device remove 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=sum… The filename of the patch is: pci-detach-driver-before-procfs-sysfs-teardown-on-device-remove.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Alex Williamson <alex.williamson(a)redhat.com> Date: Wed, 11 Oct 2017 15:35:56 -0600 Subject: PCI: Detach driver before procfs & sysfs teardown on device remove From: Alex Williamson <alex.williamson(a)redhat.com> [ Upstream commit 16b6c8bb687cc3bec914de09061fcb8411951fda ] When removing a device, for example a VF being removed due to SR-IOV teardown, a "soft" hot-unplug via 'echo 1 > remove' in sysfs, or an actual hot-unplug, we first remove the procfs and sysfs attributes for the device before attempting to release the device from any driver bound to it. Unbinding the driver from the device can take time. The device might need to write out data or it might be actively in use. If it's in use by userspace through a vfio driver, the unbind might block until the user releases the device. This leads to a potentially non-trivial amount of time where the device exists, but we've torn down the interfaces that userspace uses to examine devices, for instance lspci might generate this sort of error: pcilib: Cannot open /sys/bus/pci/devices/0000:01:0a.3/config lspci: Unable to read the standard configuration space header of device 0000:01:0a.3 We don't seem to have any dependence on this teardown ordering in the kernel, so let's unbind the driver first, which is also more symmetric with the instantiation of the device in pci_bus_add_device(). Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pci/remove.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/pci/remove.c +++ b/drivers/pci/remove.c @@ -20,9 +20,9 @@ static void pci_stop_dev(struct pci_dev pci_pme_active(dev, false); if (dev->is_added) { + device_release_driver(&dev->dev); pci_proc_detach_device(dev); pci_remove_sysfs_dev_files(dev); - device_release_driver(&dev->dev); dev->is_added = 0; } Patches currently in stable-queue which might be from alex.williamson(a)redhat.com are queue-3.18/pci-detach-driver-before-procfs-sysfs-teardown-on-device-remove.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "openrisc: fix issue handling 8 byte get_user calls" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled openrisc: fix issue handling 8 byte get_user calls 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=sum… The filename of the patch is: openrisc-fix-issue-handling-8-byte-get_user-calls.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Stafford Horne <shorne(a)gmail.com> Date: Mon, 13 Mar 2017 07:44:45 +0900 Subject: openrisc: fix issue handling 8 byte get_user calls From: Stafford Horne <shorne(a)gmail.com> [ Upstream commit 154e67cd8e8f964809d0e75e44bb121b169c75b3 ] Was getting the following error with allmodconfig: ERROR: "__get_user_bad" [lib/test_user_copy.ko] undefined! This was simply a missing break statement, causing an unwanted fall through. Signed-off-by: Stafford Horne <shorne(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/openrisc/include/asm/uaccess.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/openrisc/include/asm/uaccess.h +++ b/arch/openrisc/include/asm/uaccess.h @@ -215,7 +215,7 @@ do { \ case 1: __get_user_asm(x, ptr, retval, "l.lbz"); break; \ case 2: __get_user_asm(x, ptr, retval, "l.lhz"); break; \ case 4: __get_user_asm(x, ptr, retval, "l.lwz"); break; \ - case 8: __get_user_asm2(x, ptr, retval); \ + case 8: __get_user_asm2(x, ptr, retval); break; \ default: (x) = __get_user_bad(); \ } \ } while (0) Patches currently in stable-queue which might be from shorne(a)gmail.com are queue-3.18/openrisc-fix-issue-handling-8-byte-get_user-calls.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "dmaengine: rcar-dmac: use TCRB instead of TCR for residue" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dmaengine: rcar-dmac: use TCRB instead of TCR for residue to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dmaengine-rcar-dmac-use-tcrb-instead-of-tcr-for-residue.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 13:28:59 CET 2017 From: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com> Date: Thu, 19 Oct 2017 01:15:13 +0000 Subject: dmaengine: rcar-dmac: use TCRB instead of TCR for residue From: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com> [ Upstream commit 847449f23dcbff68234525f90dd53c7c7db18cad ] SYS/RT/Audio DMAC includes independent data buffers for reading and writing. Therefore, the read transfer counter and write transfer counter have different values. TCR indicates read counter, and TCRB indicates write counter. The relationship is like below. TCR TCRB [SOURCE] -> [DMAC] -> [SINK] In the MEM_TO_DEV direction, what really matters is how much data has been written to the device. If the DMA is interrupted between read and write, then, the data doesn't end up in the destination, so shouldn't be counted. TCRB is thus the register we should use in this cases. In the DEV_TO_MEM direction, the situation is more complex. Both the read and write side are important. What matters from a data consumer point of view is how much data has been written to memory. On the other hand, if the transfer is interrupted between read and write, we'll end up losing data. It can also be important to report. In the MEM_TO_MEM direction, what matters is of course how much data has been written to memory from data consumer point of view. Here, because read and write have independent data buffers, it will take a while for TCR and TCRB to become equal. Thus we should check TCRB in this case, too. Thus, all cases we should check TCRB instead of TCR. Without this patch, Sound Capture has noise after PluseAudio support (= 07b7acb51d2 ("ASoC: rsnd: update pointer more accurate")), because the recorder will use wrong residue counter which indicates transferred from sound device, but in reality the data was not yet put to memory and recorder will record it. Signed-off-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com> [Kuninori: added detail information in log] Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma/sh/rcar-dmac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/dma/sh/rcar-dmac.c +++ b/drivers/dma/sh/rcar-dmac.c @@ -1310,7 +1310,7 @@ static unsigned int rcar_dmac_chan_get_r } /* Add the residue for the current chunk. */ - residue += rcar_dmac_chan_read(chan, RCAR_DMATCR) << desc->xfer_shift; + residue += rcar_dmac_chan_read(chan, RCAR_DMATCRB) << desc->xfer_shift; return residue; } Patches currently in stable-queue which might be from hiroyuki.yokoyama.vx(a)renesas.com are queue-4.14/dmaengine-rcar-dmac-use-tcrb-instead-of-tcr-for-residue.patch

7 years, 6 months

3
2
0 0

[Linux-stable-mirror] Patch "NFSv4.1 respect server's max size in CREATE_SESSION" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled NFSv4.1 respect server's max size in CREATE_SESSION 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=sum… The filename of the patch is: nfsv4.1-respect-server-s-max-size-in-create_session.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Olga Kornievskaia <kolga(a)netapp.com> Date: Wed, 8 Mar 2017 14:39:15 -0500 Subject: NFSv4.1 respect server's max size in CREATE_SESSION From: Olga Kornievskaia <kolga(a)netapp.com> [ Upstream commit 033853325fe3bdc70819a8b97915bd3bca41d3af ] Currently client doesn't respect max sizes server returns in CREATE_SESSION. nfs4_session_set_rwsize() gets called and server->rsize, server->wsize are 0 so they never get set to the sizes returned by the server. Signed-off-by: Olga Kornievskaia <kolga(a)netapp.com> Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfs/nfs4client.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/fs/nfs/nfs4client.c +++ b/fs/nfs/nfs4client.c @@ -894,9 +894,9 @@ static void nfs4_session_set_rwsize(stru server_resp_sz = sess->fc_attrs.max_resp_sz - nfs41_maxread_overhead; server_rqst_sz = sess->fc_attrs.max_rqst_sz - nfs41_maxwrite_overhead; - if (server->rsize > server_resp_sz) + if (!server->rsize || server->rsize > server_resp_sz) server->rsize = server_resp_sz; - if (server->wsize > server_rqst_sz) + if (!server->wsize || server->wsize > server_rqst_sz) server->wsize = server_rqst_sz; #endif /* CONFIG_NFS_V4_1 */ } Patches currently in stable-queue which might be from kolga(a)netapp.com are queue-3.18/nfsv4.1-respect-server-s-max-size-in-create_session.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "NFSD: fix nfsd_minorversion(.., NFSD_AVAIL)" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled NFSD: fix nfsd_minorversion(.., NFSD_AVAIL) 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=sum… The filename of the patch is: nfsd-fix-nfsd_minorversion-..-nfsd_avail.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: NeilBrown <neilb(a)suse.com> Date: Fri, 10 Mar 2017 11:36:39 +1100 Subject: NFSD: fix nfsd_minorversion(.., NFSD_AVAIL) From: NeilBrown <neilb(a)suse.com> [ Upstream commit 928c6fb3a9bfd6c5b287aa3465226add551c13c0 ] Current code will return 1 if the version is supported, and -1 if it isn't. This is confusing and inconsistent with the one place where this is used. So change to return 1 if it is supported, and zero if not. i.e. an error is never returned. Signed-off-by: NeilBrown <neilb(a)suse.com> Signed-off-by: J. Bruce Fields <bfields(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfsd/nfssvc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/nfsd/nfssvc.c +++ b/fs/nfsd/nfssvc.c @@ -150,7 +150,8 @@ int nfsd_vers(int vers, enum vers_op cha int nfsd_minorversion(u32 minorversion, enum vers_op change) { - if (minorversion > NFSD_SUPPORTED_MINOR_VERSION) + if (minorversion > NFSD_SUPPORTED_MINOR_VERSION && + change != NFSD_AVAIL) return -1; switch(change) { case NFSD_SET: Patches currently in stable-queue which might be from neilb(a)suse.com are queue-3.18/autofs-fix-careless-error-in-recent-commit.patch queue-3.18/raid5-set-r5_expanded-on-parity-devices-as-well-as-data.patch queue-3.18/nfsd-fix-nfsd_reset_versions-for-nfsv4.patch queue-3.18/nfsd-fix-nfsd_minorversion-..-nfsd_avail.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "NFSD: fix nfsd_reset_versions for NFSv4." has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled NFSD: fix nfsd_reset_versions for NFSv4. 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=sum… The filename of the patch is: nfsd-fix-nfsd_reset_versions-for-nfsv4.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: NeilBrown <neilb(a)suse.com> Date: Fri, 10 Mar 2017 11:36:39 +1100 Subject: NFSD: fix nfsd_reset_versions for NFSv4. From: NeilBrown <neilb(a)suse.com> [ Upstream commit 800a938f0bf9130c8256116649c0cc5806bfb2fd ] If you write "-2 -3 -4" to the "versions" file, it will notice that no versions are enabled, and nfsd_reset_versions() is called. This enables all major versions, not no minor versions. So we lose the invariant that NFSv4 is only advertised when at least one minor is enabled. Fix the code to explicitly enable minor versions for v4, change it to use nfsd_vers() to test and set, and simplify the code. Signed-off-by: NeilBrown <neilb(a)suse.com> Signed-off-by: J. Bruce Fields <bfields(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfsd/nfssvc.c | 25 +++++++++++-------------- 1 file changed, 11 insertions(+), 14 deletions(-) --- a/fs/nfsd/nfssvc.c +++ b/fs/nfsd/nfssvc.c @@ -329,23 +329,20 @@ static void nfsd_last_thread(struct svc_ void nfsd_reset_versions(void) { - int found_one = 0; int i; - for (i = NFSD_MINVERS; i < NFSD_NRVERS; i++) { - if (nfsd_program.pg_vers[i]) - found_one = 1; - } + for (i = 0; i < NFSD_NRVERS; i++) + if (nfsd_vers(i, NFSD_TEST)) + return; - if (!found_one) { - for (i = NFSD_MINVERS; i < NFSD_NRVERS; i++) - nfsd_program.pg_vers[i] = nfsd_version[i]; -#if defined(CONFIG_NFSD_V2_ACL) || defined(CONFIG_NFSD_V3_ACL) - for (i = NFSD_ACL_MINVERS; i < NFSD_ACL_NRVERS; i++) - nfsd_acl_program.pg_vers[i] = - nfsd_acl_version[i]; -#endif - } + for (i = 0; i < NFSD_NRVERS; i++) + if (i != 4) + nfsd_vers(i, NFSD_SET); + else { + int minor = 0; + while (nfsd_minorversion(minor, NFSD_SET) >= 0) + minor++; + } } /* Patches currently in stable-queue which might be from neilb(a)suse.com are queue-3.18/autofs-fix-careless-error-in-recent-commit.patch queue-3.18/raid5-set-r5_expanded-on-parity-devices-as-well-as-data.patch queue-3.18/nfsd-fix-nfsd_reset_versions-for-nfsv4.patch queue-3.18/nfsd-fix-nfsd_minorversion-..-nfsd_avail.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "net: wimax/i2400m: fix NULL-deref at probe" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: wimax/i2400m: fix NULL-deref at probe 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=sum… The filename of the patch is: net-wimax-i2400m-fix-null-deref-at-probe.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Johan Hovold <johan(a)kernel.org> Date: Mon, 13 Mar 2017 13:42:03 +0100 Subject: net: wimax/i2400m: fix NULL-deref at probe From: Johan Hovold <johan(a)kernel.org> [ Upstream commit 6e526fdff7be4f13b24f929a04c0e9ae6761291e ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory beyond the endpoint array should a malicious device lack the expected endpoints. The endpoints are specifically dereferenced in the i2400m_bootrom_init path during probe (e.g. in i2400mu_tx_bulk_out). Fixes: f398e4240fce ("i2400m/USB: probe/disconnect, dev init/shutdown and reset backends") Cc: Inaky Perez-Gonzalez <inaky(a)linux.intel.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wimax/i2400m/usb.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/net/wimax/i2400m/usb.c +++ b/drivers/net/wimax/i2400m/usb.c @@ -467,6 +467,9 @@ int i2400mu_probe(struct usb_interface * struct i2400mu *i2400mu; struct usb_device *usb_dev = interface_to_usbdev(iface); + if (iface->cur_altsetting->desc.bNumEndpoints < 4) + return -ENODEV; + if (usb_dev->speed != USB_SPEED_HIGH) dev_err(dev, "device not connected as high speed\n"); Patches currently in stable-queue which might be from johan(a)kernel.org are queue-3.18/net-wimax-i2400m-fix-null-deref-at-probe.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "net: Resend IGMP memberships upon peer notification." has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: Resend IGMP memberships upon peer notification. 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=sum… The filename of the patch is: net-resend-igmp-memberships-upon-peer-notification.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Vlad Yasevich <vyasevich(a)gmail.com> Date: Tue, 14 Mar 2017 08:58:08 -0400 Subject: net: Resend IGMP memberships upon peer notification. From: Vlad Yasevich <vyasevich(a)gmail.com> [ Upstream commit 37c343b4f4e70e9dc328ab04903c0ec8d154c1a4 ] When we notify peers of potential changes, it's also good to update IGMP memberships. For example, during VM migration, updating IGMP memberships will redirect existing multicast streams to the VM at the new location. Signed-off-by: Vladislav Yasevich <vyasevic(a)redhat.com> Acked-by: Michael S. Tsirkin <mst(a)redhat.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/core/dev.c | 1 + 1 file changed, 1 insertion(+) --- a/net/core/dev.c +++ b/net/core/dev.c @@ -1248,6 +1248,7 @@ void netdev_notify_peers(struct net_devi { rtnl_lock(); call_netdevice_notifiers(NETDEV_NOTIFY_PEERS, dev); + call_netdevice_notifiers(NETDEV_RESEND_IGMP, dev); rtnl_unlock(); } EXPORT_SYMBOL(netdev_notify_peers); Patches currently in stable-queue which might be from vyasevich(a)gmail.com are queue-3.18/net-resend-igmp-memberships-upon-peer-notification.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "net: bcmgenet: correct the RBUF_OVFL_CNT and RBUF_ERR_CNT MIB values" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: bcmgenet: correct the RBUF_OVFL_CNT and RBUF_ERR_CNT MIB values 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=sum… The filename of the patch is: net-bcmgenet-correct-the-rbuf_ovfl_cnt-and-rbuf_err_cnt-mib-values.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Doug Berger <opendmb(a)gmail.com> Date: Thu, 9 Mar 2017 16:58:43 -0800 Subject: net: bcmgenet: correct the RBUF_OVFL_CNT and RBUF_ERR_CNT MIB values From: Doug Berger <opendmb(a)gmail.com> [ Upstream commit ffff71328a3c321f7c14cc1edd33577717037744 ] The location of the RBUF overflow and error counters has moved between different version of the GENET MAC. This commit corrects the driver to read from the correct locations depending on the version of the GENET MAC. Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file") Signed-off-by: Doug Berger <opendmb(a)gmail.com> Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/broadcom/genet/bcmgenet.c | 60 ++++++++++++++++++++++--- drivers/net/ethernet/broadcom/genet/bcmgenet.h | 10 ++-- 2 files changed, 60 insertions(+), 10 deletions(-) --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c @@ -1,7 +1,7 @@ /* * Broadcom GENET (Gigabit Ethernet) controller driver * - * Copyright (c) 2014 Broadcom Corporation + * Copyright (c) 2014-2017 Broadcom * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -610,8 +610,9 @@ static const struct bcmgenet_stats bcmge STAT_GENET_RUNT("rx_runt_bytes", mib.rx_runt_bytes), /* Misc UniMAC counters */ STAT_GENET_MISC("rbuf_ovflow_cnt", mib.rbuf_ovflow_cnt, - UMAC_RBUF_OVFL_CNT), - STAT_GENET_MISC("rbuf_err_cnt", mib.rbuf_err_cnt, UMAC_RBUF_ERR_CNT), + UMAC_RBUF_OVFL_CNT_V1), + STAT_GENET_MISC("rbuf_err_cnt", mib.rbuf_err_cnt, + UMAC_RBUF_ERR_CNT_V1), STAT_GENET_MISC("mdf_err_cnt", mib.mdf_err_cnt, UMAC_MDF_ERR_CNT), }; @@ -651,6 +652,45 @@ static void bcmgenet_get_strings(struct } } +static u32 bcmgenet_update_stat_misc(struct bcmgenet_priv *priv, u16 offset) +{ + u16 new_offset; + u32 val; + + switch (offset) { + case UMAC_RBUF_OVFL_CNT_V1: + if (GENET_IS_V2(priv)) + new_offset = RBUF_OVFL_CNT_V2; + else + new_offset = RBUF_OVFL_CNT_V3PLUS; + + val = bcmgenet_rbuf_readl(priv, new_offset); + /* clear if overflowed */ + if (val == ~0) + bcmgenet_rbuf_writel(priv, 0, new_offset); + break; + case UMAC_RBUF_ERR_CNT_V1: + if (GENET_IS_V2(priv)) + new_offset = RBUF_ERR_CNT_V2; + else + new_offset = RBUF_ERR_CNT_V3PLUS; + + val = bcmgenet_rbuf_readl(priv, new_offset); + /* clear if overflowed */ + if (val == ~0) + bcmgenet_rbuf_writel(priv, 0, new_offset); + break; + default: + val = bcmgenet_umac_readl(priv, offset); + /* clear if overflowed */ + if (val == ~0) + bcmgenet_umac_writel(priv, 0, offset); + break; + } + + return val; +} + static void bcmgenet_update_mib_counters(struct bcmgenet_priv *priv) { int i, j = 0; @@ -674,10 +714,16 @@ static void bcmgenet_update_mib_counters UMAC_MIB_START + j + offset); break; case BCMGENET_STAT_MISC: - val = bcmgenet_umac_readl(priv, s->reg_offset); - /* clear if overflowed */ - if (val == ~0) - bcmgenet_umac_writel(priv, 0, s->reg_offset); + if (GENET_IS_V1(priv)) { + val = bcmgenet_umac_readl(priv, s->reg_offset); + /* clear if overflowed */ + if (val == ~0) + bcmgenet_umac_writel(priv, 0, + s->reg_offset); + } else { + val = bcmgenet_update_stat_misc(priv, + s->reg_offset); + } break; } --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.h +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.h @@ -1,5 +1,5 @@ /* - * Copyright (c) 2014 Broadcom Corporation + * Copyright (c) 2014-2017 Broadcom * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -196,7 +196,9 @@ struct bcmgenet_mib_counters { #define MDIO_REG_SHIFT 16 #define MDIO_REG_MASK 0x1F -#define UMAC_RBUF_OVFL_CNT 0x61C +#define UMAC_RBUF_OVFL_CNT_V1 0x61C +#define RBUF_OVFL_CNT_V2 0x80 +#define RBUF_OVFL_CNT_V3PLUS 0x94 #define UMAC_MPD_CTRL 0x620 #define MPD_EN (1 << 0) @@ -206,7 +208,9 @@ struct bcmgenet_mib_counters { #define UMAC_MPD_PW_MS 0x624 #define UMAC_MPD_PW_LS 0x628 -#define UMAC_RBUF_ERR_CNT 0x634 +#define UMAC_RBUF_ERR_CNT_V1 0x634 +#define RBUF_ERR_CNT_V2 0x84 +#define RBUF_ERR_CNT_V3PLUS 0x98 #define UMAC_MDF_ERR_CNT 0x638 #define UMAC_MDF_CTRL 0x650 #define UMAC_MDF_ADDR 0x654 Patches currently in stable-queue which might be from opendmb(a)gmail.com are queue-3.18/net-bcmgenet-correct-the-rbuf_ovfl_cnt-and-rbuf_err_cnt-mib-values.patch queue-3.18/net-bcmgenet-correct-mib-access-of-unimac-runt-counters.patch queue-3.18/net-bcmgenet-power-up-the-internal-phy-before-probing-the-mii.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "net: bcmgenet: Power up the internal PHY before probing the MII" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: bcmgenet: Power up the internal PHY before probing the MII 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=sum… The filename of the patch is: net-bcmgenet-power-up-the-internal-phy-before-probing-the-mii.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Doug Berger <opendmb(a)gmail.com> Date: Thu, 9 Mar 2017 16:58:48 -0800 Subject: net: bcmgenet: Power up the internal PHY before probing the MII From: Doug Berger <opendmb(a)gmail.com> [ Upstream commit 6be371b053dc86f11465cc1abce2e99bda0a0574 ] When using the internal PHY it must be powered up when the MII is probed or the PHY will not be detected. Since the PHY is powered up at reset this has not been a problem. However, when the kernel is restarted with kexec the PHY will likely be powered down when the kernel starts so it will not be detected and the Ethernet link will not be established. This commit explicitly powers up the internal PHY when the GENET driver is probed to correct this behavior. Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file") Signed-off-by: Doug Berger <opendmb(a)gmail.com> Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/broadcom/genet/bcmgenet.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c @@ -2598,6 +2598,7 @@ static int bcmgenet_probe(struct platfor const void *macaddr; struct resource *r; int err = -EIO; + const char *phy_mode_str; /* Up to GENET_MAX_MQ_CNT + 1 TX queues and a single RX queue */ dev = alloc_etherdev_mqs(sizeof(*priv), GENET_MAX_MQ_CNT + 1, 1); @@ -2685,6 +2686,13 @@ static int bcmgenet_probe(struct platfor if (IS_ERR(priv->clk_wol)) dev_warn(&priv->pdev->dev, "failed to get enet-wol clock\n"); + /* If this is an internal GPHY, power it on now, before UniMAC is + * brought out of reset as absolutely no UniMAC activity is allowed + */ + if (dn && !of_property_read_string(dn, "phy-mode", &phy_mode_str) && + !strcasecmp(phy_mode_str, "internal")) + bcmgenet_power_up(priv, GENET_POWER_PASSIVE); + err = reset_umac(priv); if (err) goto err_clk_disable; Patches currently in stable-queue which might be from opendmb(a)gmail.com are queue-3.18/net-bcmgenet-correct-the-rbuf_ovfl_cnt-and-rbuf_err_cnt-mib-values.patch queue-3.18/net-bcmgenet-correct-mib-access-of-unimac-runt-counters.patch queue-3.18/net-bcmgenet-power-up-the-internal-phy-before-probing-the-mii.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "mm: Handle 0 flags in _calc_vm_trans() macro" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mm: Handle 0 flags in _calc_vm_trans() macro 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=sum… The filename of the patch is: mm-handle-0-flags-in-_calc_vm_trans-macro.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Jan Kara <jack(a)suse.cz> Date: Fri, 3 Nov 2017 12:21:21 +0100 Subject: mm: Handle 0 flags in _calc_vm_trans() macro From: Jan Kara <jack(a)suse.cz> [ Upstream commit 592e254502041f953e84d091eae2c68cba04c10b ] _calc_vm_trans() does not handle the situation when some of the passed flags are 0 (which can happen if these VM flags do not make sense for the architecture). Improve the _calc_vm_trans() macro to return 0 in such situation. Since all passed flags are constant, this does not add any runtime overhead. Signed-off-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/mman.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/include/linux/mman.h +++ b/include/linux/mman.h @@ -63,8 +63,9 @@ static inline int arch_validate_prot(uns * ("bit1" and "bit2" must be single bits) */ #define _calc_vm_trans(x, bit1, bit2) \ + ((!(bit1) || !(bit2)) ? 0 : \ ((bit1) <= (bit2) ? ((x) & (bit1)) * ((bit2) / (bit1)) \ - : ((x) & (bit1)) / ((bit1) / (bit2))) + : ((x) & (bit1)) / ((bit1) / (bit2)))) /* * Combine the mmap "prot" argument into "vm_flags" used internally. Patches currently in stable-queue which might be from jack(a)suse.cz are queue-3.18/mm-handle-0-flags-in-_calc_vm_trans-macro.patch queue-3.18/udf-avoid-overflow-when-session-starts-at-large-offset.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "macvlan: Only deliver one copy of the frame to the macvlan interface" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled macvlan: Only deliver one copy of the frame to the macvlan interface 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=sum… The filename of the patch is: macvlan-only-deliver-one-copy-of-the-frame-to-the-macvlan-interface.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Alexander Duyck <alexander.h.duyck(a)intel.com> Date: Fri, 13 Oct 2017 13:40:24 -0700 Subject: macvlan: Only deliver one copy of the frame to the macvlan interface From: Alexander Duyck <alexander.h.duyck(a)intel.com> [ Upstream commit dd6b9c2c332b40f142740d1b11fb77c653ff98ea ] This patch intoduces a slight adjustment for macvlan to address the fact that in source mode I was seeing two copies of any packet addressed to the macvlan interface being delivered where there should have been only one. The issue appears to be that one copy was delivered based on the source MAC address and then the second copy was being delivered based on the destination MAC address. To fix it I am just treating a unicast address match as though it is not a match since source based macvlan isn't supposed to be matching based on the destination MAC anyway. Fixes: 79cf79abce71 ("macvlan: add source mode") Signed-off-by: Alexander Duyck <alexander.h.duyck(a)intel.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/macvlan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/macvlan.c +++ b/drivers/net/macvlan.c @@ -440,7 +440,7 @@ static rx_handler_result_t macvlan_handl struct macvlan_dev, list); else vlan = macvlan_hash_lookup(port, eth->h_dest); - if (vlan == NULL) + if (!vlan || vlan->mode == MACVLAN_MODE_SOURCE) return RX_HANDLER_PASS; dev = vlan->dev; Patches currently in stable-queue which might be from alexander.h.duyck(a)intel.com are queue-3.18/macvlan-only-deliver-one-copy-of-the-frame-to-the-macvlan-interface.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "net: bcmgenet: correct MIB access of UniMAC RUNT counters" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: bcmgenet: correct MIB access of UniMAC RUNT counters 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=sum… The filename of the patch is: net-bcmgenet-correct-mib-access-of-unimac-runt-counters.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Doug Berger <opendmb(a)gmail.com> Date: Thu, 9 Mar 2017 16:58:44 -0800 Subject: net: bcmgenet: correct MIB access of UniMAC RUNT counters From: Doug Berger <opendmb(a)gmail.com> [ Upstream commit 1ad3d225e5a40ca6c586989b4baaca710544c15a ] The gap between the Tx status counters and the Rx RUNT counters is now being added to allow correct reporting of the registers. Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file") Signed-off-by: Doug Berger <opendmb(a)gmail.com> Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/broadcom/genet/bcmgenet.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c @@ -705,13 +705,16 @@ static void bcmgenet_update_mib_counters switch (s->type) { case BCMGENET_STAT_NETDEV: continue; - case BCMGENET_STAT_MIB_RX: - case BCMGENET_STAT_MIB_TX: case BCMGENET_STAT_RUNT: - if (s->type != BCMGENET_STAT_MIB_RX) - offset = BCMGENET_STAT_OFFSET; + offset += BCMGENET_STAT_OFFSET; + /* fall through */ + case BCMGENET_STAT_MIB_TX: + offset += BCMGENET_STAT_OFFSET; + /* fall through */ + case BCMGENET_STAT_MIB_RX: val = bcmgenet_umac_readl(priv, UMAC_MIB_START + j + offset); + offset = 0; /* Reset Offset */ break; case BCMGENET_STAT_MISC: if (GENET_IS_V1(priv)) { Patches currently in stable-queue which might be from opendmb(a)gmail.com are queue-3.18/net-bcmgenet-correct-the-rbuf_ovfl_cnt-and-rbuf_err_cnt-mib-values.patch queue-3.18/net-bcmgenet-correct-mib-access-of-unimac-runt-counters.patch queue-3.18/net-bcmgenet-power-up-the-internal-phy-before-probing-the-mii.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "iscsi-target: fix memory leak in lio_target_tiqn_addtpg()" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iscsi-target: fix memory leak in lio_target_tiqn_addtpg() 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=sum… The filename of the patch is: iscsi-target-fix-memory-leak-in-lio_target_tiqn_addtpg.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: tangwenji <tang.wenji(a)zte.com.cn> Date: Fri, 15 Sep 2017 16:03:13 +0800 Subject: iscsi-target: fix memory leak in lio_target_tiqn_addtpg() From: tangwenji <tang.wenji(a)zte.com.cn> [ Upstream commit 12d5a43b2dffb6cd28062b4e19024f7982393288 ] tpg must free when call core_tpg_register() return fail Signed-off-by: tangwenji <tang.wenji(a)zte.com.cn> Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/iscsi/iscsi_target_configfs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/target/iscsi/iscsi_target_configfs.c +++ b/drivers/target/iscsi/iscsi_target_configfs.c @@ -1458,7 +1458,7 @@ static struct se_portal_group *lio_targe wwn, &tpg->tpg_se_tpg, tpg, TRANSPORT_TPG_TYPE_NORMAL); if (ret < 0) - return NULL; + goto free_out; ret = iscsit_tpg_add_portal_group(tiqn, tpg); if (ret != 0) @@ -1470,6 +1470,7 @@ static struct se_portal_group *lio_targe return &tpg->tpg_se_tpg; out: core_tpg_deregister(&tpg->tpg_se_tpg); +free_out: kfree(tpg); return NULL; } Patches currently in stable-queue which might be from tang.wenji(a)zte.com.cn are queue-3.18/target-fix-condition-return-in-core_pr_dump_initiator_port.patch queue-3.18/iscsi-target-fix-memory-leak-in-lio_target_tiqn_addtpg.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "Input: i8042 - add TUXEDO BU1406 (N24_25BU) to the nomux list" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Input: i8042 - add TUXEDO BU1406 (N24_25BU) to the nomux list 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=sum… The filename of the patch is: input-i8042-add-tuxedo-bu1406-n24_25bu-to-the-nomux-list.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Date: Tue, 28 Feb 2017 17:14:41 -0800 Subject: Input: i8042 - add TUXEDO BU1406 (N24_25BU) to the nomux list From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> [ Upstream commit a4c2a13129f7c5bcf81704c06851601593303fd5 ] TUXEDO BU1406 does not implement active multiplexing mode properly, and takes around 550 ms in i8042_set_mux_mode(). Given that the device does not have external AUX port, there is no downside in disabling the MUX mode. Reported-by: Paul Menzel <pmenzel(a)molgen.mpg.de> Suggested-by: Vojtech Pavlik <vojtech(a)suse.cz> Reviewed-by: Marcos Paulo de Souza <marcos.souza.org(a)gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/input/serio/i8042-x86ia64io.h | 7 +++++++ 1 file changed, 7 insertions(+) --- a/drivers/input/serio/i8042-x86ia64io.h +++ b/drivers/input/serio/i8042-x86ia64io.h @@ -514,6 +514,13 @@ static const struct dmi_system_id __init DMI_MATCH(DMI_PRODUCT_NAME, "IC4I"), }, }, + { + /* TUXEDO BU1406 */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Notebook"), + DMI_MATCH(DMI_PRODUCT_NAME, "N24_25BU"), + }, + }, { } }; Patches currently in stable-queue which might be from dmitry.torokhov(a)gmail.com are queue-3.18/input-i8042-add-tuxedo-bu1406-n24_25bu-to-the-nomux-list.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "GFS2: Take inode off order_write list when setting jdata flag" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled GFS2: Take inode off order_write list when setting jdata flag 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=sum… The filename of the patch is: gfs2-take-inode-off-order_write-list-when-setting-jdata-flag.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Bob Peterson <rpeterso(a)redhat.com> Date: Wed, 20 Sep 2017 08:30:04 -0500 Subject: GFS2: Take inode off order_write list when setting jdata flag From: Bob Peterson <rpeterso(a)redhat.com> [ Upstream commit cc555b09d8c3817aeebda43a14ab67049a5653f7 ] This patch fixes a deadlock caused when the jdata flag is set for inodes that are already on the ordered write list. Since it is on the ordered write list, log_flush calls gfs2_ordered_write which calls filemap_fdatawrite. But since the inode had the jdata flag set, that calls gfs2_jdata_writepages, which tries to start a new transaction. A new transaction cannot be started because it tries to acquire the log_flush rwsem which is already locked by the log flush operation. The bottom line is: We cannot switch an inode from ordered to jdata until we eliminate any ordered data pages (via log flush) or any log_flush operation afterward will create the circular dependency above. So we need to flush the log before setting the diskflags to switch the file mode, then we need to remove the inode from the ordered writes list. Before this patch, the log flush was done for jdata->ordered, but that's wrong. If we're going from jdata to ordered, we don't need to call gfs2_log_flush because the call to filemap_fdatawrite will do it for us: filemap_fdatawrite() -> __filemap_fdatawrite_range() __filemap_fdatawrite_range() -> do_writepages() do_writepages() -> gfs2_jdata_writepages() gfs2_jdata_writepages() -> gfs2_log_flush() This patch modifies function do_gfs2_set_flags so that if a file has its jdata flag set, and it's already on the ordered write list, the log will be flushed and it will be removed from the list before setting the flag. Signed-off-by: Bob Peterson <rpeterso(a)redhat.com> Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com> Acked-by: Abhijith Das <adas(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/gfs2/file.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/fs/gfs2/file.c +++ b/fs/gfs2/file.c @@ -256,7 +256,7 @@ static int do_gfs2_set_flags(struct file goto out; } if ((flags ^ new_flags) & GFS2_DIF_JDATA) { - if (flags & GFS2_DIF_JDATA) + if (new_flags & GFS2_DIF_JDATA) gfs2_log_flush(sdp, ip->i_gl, NORMAL_FLUSH); error = filemap_fdatawrite(inode->i_mapping); if (error) @@ -264,6 +264,8 @@ static int do_gfs2_set_flags(struct file error = filemap_fdatawait(inode->i_mapping); if (error) goto out; + if (new_flags & GFS2_DIF_JDATA) + gfs2_ordered_del_inode(ip); } error = gfs2_trans_begin(sdp, RES_DINODE, 0); if (error) Patches currently in stable-queue which might be from rpeterso(a)redhat.com are queue-3.18/gfs2-take-inode-off-order_write-list-when-setting-jdata-flag.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/radeon/si: add dpm quirk for Oland" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/radeon/si: add dpm quirk for Oland 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=sum… The filename of the patch is: drm-radeon-si-add-dpm-quirk-for-oland.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Alex Deucher <alexander.deucher(a)amd.com> Date: Tue, 14 Mar 2017 14:42:03 -0400 Subject: drm/radeon/si: add dpm quirk for Oland From: Alex Deucher <alexander.deucher(a)amd.com> [ Upstream commit 0f424de1fd9bc4ab24bd1fe5430ab5618e803e31 ] OLAND 0x1002:0x6604 0x1028:0x066F 0x00 seems to have problems with higher sclks. Acked-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/radeon/si_dpm.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/gpu/drm/radeon/si_dpm.c +++ b/drivers/gpu/drm/radeon/si_dpm.c @@ -2988,6 +2988,12 @@ static void si_apply_state_adjust_rules( max_sclk = 75000; max_mclk = 80000; } + } else if (rdev->family == CHIP_OLAND) { + if ((rdev->pdev->device == 0x6604) && + (rdev->pdev->subsystem_vendor == 0x1028) && + (rdev->pdev->subsystem_device == 0x066F)) { + max_sclk = 75000; + } } /* Apply dpm quirks */ while (p && p->chip_device != 0) { Patches currently in stable-queue which might be from alexander.deucher(a)amd.com are queue-3.18/drm-radeon-reinstate-oland-workaround-for-sclk.patch queue-3.18/drm-radeon-si-add-dpm-quirk-for-oland.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "fbdev: controlfb: Add missing modes to fix out of bounds access" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled fbdev: controlfb: Add missing modes to fix out of bounds access 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=sum… The filename of the patch is: fbdev-controlfb-add-missing-modes-to-fix-out-of-bounds-access.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Geert Uytterhoeven <geert(a)linux-m68k.org> Date: Thu, 9 Nov 2017 18:09:33 +0100 Subject: fbdev: controlfb: Add missing modes to fix out of bounds access From: Geert Uytterhoeven <geert(a)linux-m68k.org> [ Upstream commit ac831a379d34109451b3c41a44a20ee10ecb615f ] Dan's static analysis says: drivers/video/fbdev/controlfb.c:560 control_setup() error: buffer overflow 'control_mac_modes' 20 <= 21 Indeed, control_mac_modes[] has only 20 elements, while VMODE_MAX is 22, which may lead to an out of bounds read when parsing vmode commandline options. The bug was introduced in v2.4.5.6, when 2 new modes were added to macmodes.h, but control_mac_modes[] wasn't updated: https://kernel.opensuse.org/cgit/kernel/diff/include/video/macmodes.h?h=v2.… Augment control_mac_modes[] with the two new video modes to fix this. Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Cc: Dan Carpenter <dan.carpenter(a)oracle.com> Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/fbdev/controlfb.h | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/video/fbdev/controlfb.h +++ b/drivers/video/fbdev/controlfb.h @@ -141,5 +141,7 @@ static struct max_cmodes control_mac_mod {{ 1, 2}}, /* 1152x870, 75Hz */ {{ 0, 1}}, /* 1280x960, 75Hz */ {{ 0, 1}}, /* 1280x1024, 75Hz */ + {{ 1, 2}}, /* 1152x768, 60Hz */ + {{ 0, 1}}, /* 1600x1024, 60Hz */ }; Patches currently in stable-queue which might be from geert(a)linux-m68k.org are queue-3.18/fbdev-controlfb-add-missing-modes-to-fix-out-of-bounds-access.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/radeon: reinstate oland workaround for sclk" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/radeon: reinstate oland workaround for sclk 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=sum… The filename of the patch is: drm-radeon-reinstate-oland-workaround-for-sclk.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Alex Deucher <alexander.deucher(a)amd.com> Date: Wed, 15 Mar 2017 21:11:46 -0400 Subject: drm/radeon: reinstate oland workaround for sclk From: Alex Deucher <alexander.deucher(a)amd.com> [ Upstream commit 66822d815ae61ecb2d9dba9031517e8a8476969d ] Higher sclks seem to be unstable on some boards. bug: https://bugs.freedesktop.org/show_bug.cgi?id=100222 Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/radeon/si_dpm.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) --- a/drivers/gpu/drm/radeon/si_dpm.c +++ b/drivers/gpu/drm/radeon/si_dpm.c @@ -2989,9 +2989,13 @@ static void si_apply_state_adjust_rules( max_mclk = 80000; } } else if (rdev->family == CHIP_OLAND) { - if ((rdev->pdev->device == 0x6604) && - (rdev->pdev->subsystem_vendor == 0x1028) && - (rdev->pdev->subsystem_device == 0x066F)) { + if ((rdev->pdev->revision == 0xC7) || + (rdev->pdev->revision == 0x80) || + (rdev->pdev->revision == 0x81) || + (rdev->pdev->revision == 0x83) || + (rdev->pdev->revision == 0x87) || + (rdev->pdev->device == 0x6604) || + (rdev->pdev->device == 0x6605)) { max_sclk = 75000; } } Patches currently in stable-queue which might be from alexander.deucher(a)amd.com are queue-3.18/drm-radeon-reinstate-oland-workaround-for-sclk.patch queue-3.18/drm-radeon-si-add-dpm-quirk-for-oland.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "dmaengine: Fix array index out of bounds warning in __get_unmap_pool()" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dmaengine: Fix array index out of bounds warning in __get_unmap_pool() 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=sum… The filename of the patch is: dmaengine-fix-array-index-out-of-bounds-warning-in-__get_unmap_pool.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Matthias Kaehlcke <mka(a)chromium.org> Date: Mon, 13 Mar 2017 14:30:29 -0700 Subject: dmaengine: Fix array index out of bounds warning in __get_unmap_pool() From: Matthias Kaehlcke <mka(a)chromium.org> [ Upstream commit 23f963e91fd81f44f6b316b1c24db563354c6be8 ] This fixes the following warning when building with clang and CONFIG_DMA_ENGINE_RAID=n : drivers/dma/dmaengine.c:1102:11: error: array index 2 is past the end of the array (which contains 1 element) [-Werror,-Warray-bounds] return &unmap_pool[2]; ^ ~ drivers/dma/dmaengine.c:1083:1: note: array 'unmap_pool' declared here static struct dmaengine_unmap_pool unmap_pool[] = { ^ drivers/dma/dmaengine.c:1104:11: error: array index 3 is past the end of the array (which contains 1 element) [-Werror,-Warray-bounds] return &unmap_pool[3]; ^ ~ drivers/dma/dmaengine.c:1083:1: note: array 'unmap_pool' declared here static struct dmaengine_unmap_pool unmap_pool[] = { Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org> Reviewed-by: Dan Williams <dan.j.williams(a)intel.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma/dmaengine.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/dma/dmaengine.c +++ b/drivers/dma/dmaengine.c @@ -976,12 +976,14 @@ static struct dmaengine_unmap_pool *__ge switch (order) { case 0 ... 1: return &unmap_pool[0]; +#if IS_ENABLED(CONFIG_DMA_ENGINE_RAID) case 2 ... 4: return &unmap_pool[1]; case 5 ... 7: return &unmap_pool[2]; case 8: return &unmap_pool[3]; +#endif default: BUG(); return NULL; Patches currently in stable-queue which might be from mka(a)chromium.org are queue-3.18/dmaengine-fix-array-index-out-of-bounds-warning-in-__get_unmap_pool.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "clk: tegra: Fix cclk_lp divisor register" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: tegra: Fix cclk_lp divisor register 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=sum… The filename of the patch is: clk-tegra-fix-cclk_lp-divisor-register.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Michał Mirosław <mirq-linux(a)rere.qmqm.pl> Date: Tue, 19 Sep 2017 04:48:10 +0200 Subject: clk: tegra: Fix cclk_lp divisor register From: Michał Mirosław <mirq-linux(a)rere.qmqm.pl> [ Upstream commit 54eff2264d3e9fd7e3987de1d7eba1d3581c631e ] According to comments in code and common sense, cclk_lp uses its own divisor, not cclk_g's. Fixes: b08e8c0ecc42 ("clk: tegra: add clock support for Tegra30") Signed-off-by: Michał Mirosław <mirq-linux(a)rere.qmqm.pl> Acked-By: Peter De Schrijver <pdeschrijver(a)nvidia.com> Signed-off-by: Thierry Reding <treding(a)nvidia.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/tegra/clk-tegra30.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/clk/tegra/clk-tegra30.c +++ b/drivers/clk/tegra/clk-tegra30.c @@ -1063,7 +1063,7 @@ static void __init tegra30_super_clk_ini * U71 divider of cclk_lp. */ clk = tegra_clk_register_divider("pll_p_out3_cclklp", "pll_p_out3", - clk_base + SUPER_CCLKG_DIVIDER, 0, + clk_base + SUPER_CCLKLP_DIVIDER, 0, TEGRA_DIVIDER_INT, 16, 8, 1, NULL); clk_register_clkdev(clk, "pll_p_out3_cclklp", NULL); Patches currently in stable-queue which might be from mirq-linux(a)rere.qmqm.pl are queue-3.18/clk-tegra-fix-cclk_lp-divisor-register.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "btrfs: add missing memset while reading compressed inline extents" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: add missing memset while reading compressed inline extents 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=sum… The filename of the patch is: btrfs-add-missing-memset-while-reading-compressed-inline-extents.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org> Date: Fri, 10 Mar 2017 16:45:44 -0500 Subject: btrfs: add missing memset while reading compressed inline extents From: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org> [ Upstream commit e1699d2d7bf6e6cce3e1baff19f9dd4595a58664 ] This is a story about 4 distinct (and very old) btrfs bugs. Commit c8b978188c ("Btrfs: Add zlib compression support") added three data corruption bugs for inline extents (bugs #1-3). Commit 93c82d5750 ("Btrfs: zero page past end of inline file items") fixed bug #1: uncompressed inline extents followed by a hole and more extents could get non-zero data in the hole as they were read. The fix was to add a memset in btrfs_get_extent to zero out the hole. Commit 166ae5a418 ("btrfs: fix inline compressed read err corruption") fixed bug #2: compressed inline extents which contained non-zero bytes might be replaced with zero bytes in some cases. This patch removed an unhelpful memset from uncompress_inline, but the case where memset is required was missed. There is also a memset in the decompression code, but this only covers decompressed data that is shorter than the ram_bytes from the extent ref record. This memset doesn't cover the region between the end of the decompressed data and the end of the page. It has also moved around a few times over the years, so there's no single patch to refer to. This patch fixes bug #3: compressed inline extents followed by a hole and more extents could get non-zero data in the hole as they were read (i.e. bug #3 is the same as bug #1, but s/uncompressed/compressed/). The fix is the same: zero out the hole in the compressed case too, by putting a memset back in uncompress_inline, but this time with correct parameters. The last and oldest bug, bug #0, is the cause of the offending inline extent/hole/extent pattern. Bug #0 is a subtle and mostly-harmless quirk of behavior somewhere in the btrfs write code. In a few special cases, an inline extent and hole are allowed to persist where they normally would be combined with later extents in the file. A fast reproducer for bug #0 is presented below. A few offending extents are also created in the wild during large rsync transfers with the -S flag. A Linux kernel build (git checkout; make allyesconfig; make -j8) will produce a handful of offending files as well. Once an offending file is created, it can present different content to userspace each time it is read. Bug #0 is at least 4 and possibly 8 years old. I verified every vX.Y kernel back to v3.5 has this behavior. There are fossil records of this bug's effects in commits all the way back to v2.6.32. I have no reason to believe bug #0 wasn't present at the beginning of btrfs compression support in v2.6.29, but I can't easily test kernels that old to be sure. It is not clear whether bug #0 is worth fixing. A fix would likely require injecting extra reads into currently write-only paths, and most of the exceptional cases caused by bug #0 are already handled now. Whether we like them or not, bug #0's inline extents followed by holes are part of the btrfs de-facto disk format now, and we need to be able to read them without data corruption or an infoleak. So enough about bug #0, let's get back to bug #3 (this patch). An example of on-disk structure leading to data corruption found in the wild: item 61 key (606890 INODE_ITEM 0) itemoff 9662 itemsize 160 inode generation 50 transid 50 size 47424 nbytes 49141 block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0 flags 0x0(none) item 62 key (606890 INODE_REF 603050) itemoff 9642 itemsize 20 inode ref index 3 namelen 10 name: DB_File.so item 63 key (606890 EXTENT_DATA 0) itemoff 8280 itemsize 1362 inline extent data size 1341 ram 4085 compress(zlib) item 64 key (606890 EXTENT_DATA 4096) itemoff 8227 itemsize 53 extent data disk byte 5367308288 nr 20480 extent data offset 0 nr 45056 ram 45056 extent compression(zlib) Different data appears in userspace during each read of the 11 bytes between 4085 and 4096. The extent in item 63 is not long enough to fill the first page of the file, so a memset is required to fill the space between item 63 (ending at 4085) and item 64 (beginning at 4096) with zero. Here is a reproducer from Liu Bo, which demonstrates another method of creating the same inline extent and hole pattern: Using 'page_poison=on' kernel command line (or enable CONFIG_PAGE_POISONING) run the following: # touch foo # chattr +c foo # xfs_io -f -c "pwrite -W 0 1000" foo # xfs_io -f -c "falloc 4 8188" foo # od -x foo # echo 3 >/proc/sys/vm/drop_caches # od -x foo This produce the following on my box: Correct output: file contains 1000 data bytes followed by zeros: 0000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 0001740 cdcd cdcd cdcd cdcd 0000 0000 0000 0000 0001760 0000 0000 0000 0000 0000 0000 0000 0000 * 0020000 Actual output: the data after the first 1000 bytes will be different each run: 0000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 0001740 cdcd cdcd cdcd cdcd 6c63 7400 635f 006d 0001760 5f74 6f43 7400 435f 0053 5f74 7363 7400 0002000 435f 0056 5f74 6164 7400 645f 0062 5f74 (...) Signed-off-by: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org> Reviewed-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Chris Mason <clm(a)fb.com> Signed-off-by: Chris Mason <clm(a)fb.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/inode.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -6325,6 +6325,20 @@ static noinline int uncompress_inline(st max_size = min_t(unsigned long, PAGE_CACHE_SIZE, max_size); ret = btrfs_decompress(compress_type, tmp, page, extent_offset, inline_size, max_size); + + /* + * decompression code contains a memset to fill in any space between the end + * of the uncompressed data and the end of max_size in case the decompressed + * data ends up shorter than ram_bytes. That doesn't cover the hole between + * the end of an inline extent and the beginning of the next block, so we + * cover that region here. + */ + + if (max_size + pg_offset < PAGE_SIZE) { + char *map = kmap(page); + memset(map + pg_offset + max_size, 0, PAGE_SIZE - max_size - pg_offset); + kunmap(page); + } kfree(tmp); return ret; } Patches currently in stable-queue which might be from ce3g8jdj(a)umail.furryterror.org are queue-3.18/btrfs-add-missing-memset-while-reading-compressed-inline-extents.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "bcache: fix wrong cache_misses statistics" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bcache: fix wrong cache_misses statistics 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=sum… The filename of the patch is: bcache-fix-wrong-cache_misses-statistics.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: "tang.junhui" <tang.junhui(a)zte.com.cn> Date: Mon, 30 Oct 2017 14:46:34 -0700 Subject: bcache: fix wrong cache_misses statistics From: "tang.junhui" <tang.junhui(a)zte.com.cn> [ Upstream commit c157313791a999646901b3e3c6888514ebc36d62 ] Currently, Cache missed IOs are identified by s->cache_miss, but actually, there are many situations that missed IOs are not assigned a value for s->cache_miss in cached_dev_cache_miss(), for example, a bypassed IO (s->iop.bypass = 1), or the cache_bio allocate failed. In these situations, it will go to out_put or out_submit, and s->cache_miss is null, which leads bch_mark_cache_accounting() to treat this IO as a hit IO. [ML: applied by 3-way merge] Signed-off-by: tang.junhui <tang.junhui(a)zte.com.cn> Reviewed-by: Michael Lyle <mlyle(a)lyle.org> Reviewed-by: Coly Li <colyli(a)suse.de> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/bcache/request.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/drivers/md/bcache/request.c +++ b/drivers/md/bcache/request.c @@ -464,6 +464,7 @@ struct search { unsigned recoverable:1; unsigned write:1; unsigned read_dirty_data:1; + unsigned cache_missed:1; unsigned long start_time; @@ -651,6 +652,7 @@ static inline struct search *search_allo s->orig_bio = bio; s->cache_miss = NULL; + s->cache_missed = 0; s->d = d; s->recoverable = 1; s->write = (bio->bi_rw & REQ_WRITE) != 0; @@ -774,7 +776,7 @@ static void cached_dev_read_done_bh(stru struct cached_dev *dc = container_of(s->d, struct cached_dev, disk); bch_mark_cache_accounting(s->iop.c, s->d, - !s->cache_miss, s->iop.bypass); + !s->cache_missed, s->iop.bypass); trace_bcache_read(s->orig_bio, !s->cache_miss, s->iop.bypass); if (s->iop.error) @@ -793,6 +795,8 @@ static int cached_dev_cache_miss(struct struct cached_dev *dc = container_of(s->d, struct cached_dev, disk); struct bio *miss, *cache_bio; + s->cache_missed = 1; + if (s->cache_miss || s->iop.bypass) { miss = bio_next_split(bio, sectors, GFP_NOIO, s->d->bio_split); ret = miss == bio ? MAP_DONE : MAP_CONTINUE; Patches currently in stable-queue which might be from tang.junhui(a)zte.com.cn are queue-3.18/bcache-fix-wrong-cache_misses-statistics.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "ath9k: fix tx99 potential info leak" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ath9k: fix tx99 potential info leak 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=sum… The filename of the patch is: ath9k-fix-tx99-potential-info-leak.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Miaoqing Pan <miaoqing(a)codeaurora.org> Date: Wed, 27 Sep 2017 09:13:34 +0800 Subject: ath9k: fix tx99 potential info leak From: Miaoqing Pan <miaoqing(a)codeaurora.org> [ Upstream commit ee0a47186e2fa9aa1c56cadcea470ca0ba8c8692 ] When the user sets count to zero the string buffer would remain completely uninitialized which causes the kernel to parse its own stack data, potentially leading to an info leak. In addition to that, the string might be not terminated properly when the user data does not contain a 0-terminator. Signed-off-by: Miaoqing Pan <miaoqing(a)codeaurora.org> Reviewed-by: Christoph Böhmwalder <christoph(a)boehmwalder.at> Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ath/ath9k/tx99.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/net/wireless/ath/ath9k/tx99.c +++ b/drivers/net/wireless/ath/ath9k/tx99.c @@ -180,6 +180,9 @@ static ssize_t write_file_tx99(struct fi ssize_t len; int r; + if (count < 1) + return -EINVAL; + if (sc->cur_chan->nvifs > 1) return -EOPNOTSUPP; @@ -187,6 +190,8 @@ static ssize_t write_file_tx99(struct fi if (copy_from_user(buf, user_buf, len)) return -EFAULT; + buf[len] = '\0'; + if (strtobool(buf, &start)) return -EINVAL; Patches currently in stable-queue which might be from miaoqing(a)codeaurora.org are queue-3.18/ath9k-fix-tx99-potential-info-leak.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "bcache: explicitly destroy mutex while exiting" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bcache: explicitly destroy mutex while exiting 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=sum… The filename of the patch is: bcache-explicitly-destroy-mutex-while-exiting.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Liang Chen <liangchen.linux(a)gmail.com> Date: Mon, 30 Oct 2017 14:46:35 -0700 Subject: bcache: explicitly destroy mutex while exiting From: Liang Chen <liangchen.linux(a)gmail.com> [ Upstream commit 330a4db89d39a6b43f36da16824eaa7a7509d34d ] mutex_destroy does nothing most of time, but it's better to call it to make the code future proof and it also has some meaning for like mutex debug. As Coly pointed out in a previous review, bcache_exit() may not be able to handle all the references properly if userspace registers cache and backing devices right before bch_debug_init runs and bch_debug_init failes later. So not exposing userspace interface until everything is ready to avoid that issue. Signed-off-by: Liang Chen <liangchen.linux(a)gmail.com> Reviewed-by: Michael Lyle <mlyle(a)lyle.org> Reviewed-by: Coly Li <colyli(a)suse.de> Reviewed-by: Eric Wheeler <bcache(a)linux.ewheeler.net> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/bcache/super.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/md/bcache/super.c +++ b/drivers/md/bcache/super.c @@ -2120,6 +2120,7 @@ static void bcache_exit(void) if (bcache_major) unregister_blkdev(bcache_major, "bcache"); unregister_reboot_notifier(&reboot); + mutex_destroy(&bch_register_lock); } static int __init bcache_init(void) @@ -2138,14 +2139,15 @@ static int __init bcache_init(void) bcache_major = register_blkdev(0, "bcache"); if (bcache_major < 0) { unregister_reboot_notifier(&reboot); + mutex_destroy(&bch_register_lock); return bcache_major; } if (!(bcache_wq = create_workqueue("bcache")) || !(bcache_kobj = kobject_create_and_add("bcache", fs_kobj)) || - sysfs_create_files(bcache_kobj, files) || bch_request_init() || - bch_debug_init(bcache_kobj)) + bch_debug_init(bcache_kobj) || + sysfs_create_files(bcache_kobj, files)) goto err; return 0; Patches currently in stable-queue which might be from liangchen.linux(a)gmail.com are queue-3.18/bcache-explicitly-destroy-mutex-while-exiting.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Populate and use client modification time" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Populate and use client modification time 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=sum… The filename of the patch is: afs-populate-and-use-client-modification-time.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Marc Dionne <marc.dionne(a)auristor.com> Date: Thu, 16 Mar 2017 16:27:47 +0000 Subject: afs: Populate and use client modification time From: Marc Dionne <marc.dionne(a)auristor.com> [ Upstream commit ab94f5d0dd6fd82e7eeca5e7c8096eaea0a0261f ] The inode timestamps should be set from the client time in the status received from the server, rather than the server time which is meant for internal server use. Set AFS_SET_MTIME and populate the mtime for operations that take an input status, such as file/dir creation and StoreData. If an input time is not provided the server will set the vnode times based on the current server time. In a situation where the server has some skew with the client, this could lead to the client seeing a timestamp in the future for a file that it just created or wrote. Signed-off-by: Marc Dionne <marc.dionne(a)auristor.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/afs/fsclient.c | 18 +++++++++--------- fs/afs/inode.c | 2 +- 2 files changed, 10 insertions(+), 10 deletions(-) --- a/fs/afs/fsclient.c +++ b/fs/afs/fsclient.c @@ -105,7 +105,7 @@ static void xdr_decode_AFSFetchStatus(co vnode->vfs_inode.i_mode = mode; } - vnode->vfs_inode.i_ctime.tv_sec = status->mtime_server; + vnode->vfs_inode.i_ctime.tv_sec = status->mtime_client; vnode->vfs_inode.i_mtime = vnode->vfs_inode.i_ctime; vnode->vfs_inode.i_atime = vnode->vfs_inode.i_ctime; vnode->vfs_inode.i_version = data_version; @@ -703,8 +703,8 @@ int afs_fs_create(struct afs_server *ser memset(bp, 0, padsz); bp = (void *) bp + padsz; } - *bp++ = htonl(AFS_SET_MODE); - *bp++ = 0; /* mtime */ + *bp++ = htonl(AFS_SET_MODE | AFS_SET_MTIME); + *bp++ = htonl(vnode->vfs_inode.i_mtime.tv_sec); /* mtime */ *bp++ = 0; /* owner */ *bp++ = 0; /* group */ *bp++ = htonl(mode & S_IALLUGO); /* unix mode */ @@ -981,8 +981,8 @@ int afs_fs_symlink(struct afs_server *se memset(bp, 0, c_padsz); bp = (void *) bp + c_padsz; } - *bp++ = htonl(AFS_SET_MODE); - *bp++ = 0; /* mtime */ + *bp++ = htonl(AFS_SET_MODE | AFS_SET_MTIME); + *bp++ = htonl(vnode->vfs_inode.i_mtime.tv_sec); /* mtime */ *bp++ = 0; /* owner */ *bp++ = 0; /* group */ *bp++ = htonl(S_IRWXUGO); /* unix mode */ @@ -1192,8 +1192,8 @@ static int afs_fs_store_data64(struct af *bp++ = htonl(vnode->fid.vnode); *bp++ = htonl(vnode->fid.unique); - *bp++ = 0; /* mask */ - *bp++ = 0; /* mtime */ + *bp++ = htonl(AFS_SET_MTIME); /* mask */ + *bp++ = htonl(vnode->vfs_inode.i_mtime.tv_sec); /* mtime */ *bp++ = 0; /* owner */ *bp++ = 0; /* group */ *bp++ = 0; /* unix mode */ @@ -1269,8 +1269,8 @@ int afs_fs_store_data(struct afs_server *bp++ = htonl(vnode->fid.vnode); *bp++ = htonl(vnode->fid.unique); - *bp++ = 0; /* mask */ - *bp++ = 0; /* mtime */ + *bp++ = htonl(AFS_SET_MTIME); /* mask */ + *bp++ = htonl(vnode->vfs_inode.i_mtime.tv_sec); /* mtime */ *bp++ = 0; /* owner */ *bp++ = 0; /* group */ *bp++ = 0; /* unix mode */ --- a/fs/afs/inode.c +++ b/fs/afs/inode.c @@ -71,7 +71,7 @@ static int afs_inode_map_status(struct a inode->i_uid = vnode->status.owner; inode->i_gid = vnode->status.group; inode->i_size = vnode->status.size; - inode->i_ctime.tv_sec = vnode->status.mtime_server; + inode->i_ctime.tv_sec = vnode->status.mtime_client; inode->i_ctime.tv_nsec = 0; inode->i_atime = inode->i_mtime = inode->i_ctime; inode->i_blocks = 0; Patches currently in stable-queue which might be from marc.dionne(a)auristor.com are queue-3.18/afs-populate-group-id-from-vnode-status.patch queue-3.18/afs-adjust-mode-bits-processing.patch queue-3.18/afs-populate-and-use-client-modification-time.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "arm-ccn: perf: Prevent module unload while PMU is in use" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm-ccn: perf: Prevent module unload while PMU is in use 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=sum… The filename of the patch is: arm-ccn-perf-prevent-module-unload-while-pmu-is-in-use.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Suzuki K Poulose <suzuki.poulose(a)arm.com> Date: Fri, 3 Nov 2017 11:45:18 +0000 Subject: arm-ccn: perf: Prevent module unload while PMU is in use From: Suzuki K Poulose <suzuki.poulose(a)arm.com> [ Upstream commit c7f5828bf77dcbd61d51f4736c1d5aa35663fbb4 ] When the PMU driver is built as a module, the perf expects the pmu->module to be valid, so that the driver is prevented from being unloaded while it is in use. Fix the CCN pmu driver to fill in this field. Fixes: a33b0daab73a0 ("bus: ARM CCN PMU driver") Cc: Pawel Moll <pawel.moll(a)arm.com> Cc: Will Deacon <will.deacon(a)arm.com> Acked-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> Signed-off-by: Will Deacon <will.deacon(a)arm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bus/arm-ccn.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/bus/arm-ccn.c +++ b/drivers/bus/arm-ccn.c @@ -1157,6 +1157,7 @@ static int arm_ccn_pmu_init(struct arm_c /* Perf driver registration */ ccn->dt.pmu = (struct pmu) { + .module = THIS_MODULE, .attr_groups = arm_ccn_pmu_attr_groups, .task_ctx_nr = perf_invalid_context, .event_init = arm_ccn_pmu_event_init, Patches currently in stable-queue which might be from suzuki.poulose(a)arm.com are queue-3.18/arm-ccn-perf-prevent-module-unload-while-pmu-is-in-use.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Populate group ID from vnode status" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Populate group ID from vnode status 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=sum… The filename of the patch is: afs-populate-group-id-from-vnode-status.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Marc Dionne <marc.dionne(a)auristor.com> Date: Thu, 16 Mar 2017 16:27:43 +0000 Subject: afs: Populate group ID from vnode status From: Marc Dionne <marc.dionne(a)auristor.com> [ Upstream commit 6186f0788b31f44affceeedc7b48eb10faea120d ] The group was hard coded to GLOBAL_ROOT_GID; use the group ID that was received from the server. Signed-off-by: Marc Dionne <marc.dionne(a)auristor.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/afs/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/afs/inode.c +++ b/fs/afs/inode.c @@ -69,7 +69,7 @@ static int afs_inode_map_status(struct a set_nlink(inode, vnode->status.nlink); inode->i_uid = vnode->status.owner; - inode->i_gid = GLOBAL_ROOT_GID; + inode->i_gid = vnode->status.group; inode->i_size = vnode->status.size; inode->i_ctime.tv_sec = vnode->status.mtime_server; inode->i_ctime.tv_nsec = 0; Patches currently in stable-queue which might be from marc.dionne(a)auristor.com are queue-3.18/afs-populate-group-id-from-vnode-status.patch queue-3.18/afs-adjust-mode-bits-processing.patch queue-3.18/afs-populate-and-use-client-modification-time.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Flush outstanding writes when an fd is closed" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Flush outstanding writes when an fd is closed 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=sum… The filename of the patch is: afs-flush-outstanding-writes-when-an-fd-is-closed.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: David Howells <dhowells(a)redhat.com> Date: Thu, 16 Mar 2017 16:27:45 +0000 Subject: afs: Flush outstanding writes when an fd is closed From: David Howells <dhowells(a)redhat.com> [ Upstream commit 58fed94dfb17e89556b5705f20f90e5b2971b6a1 ] Flush outstanding writes in afs when an fd is closed. This is what NFS and CIFS do. Reported-by: Marc Dionne <marc.c.dionne(a)gmail.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/afs/file.c | 1 + fs/afs/internal.h | 1 + fs/afs/write.c | 14 ++++++++++++++ 3 files changed, 16 insertions(+) --- a/fs/afs/file.c +++ b/fs/afs/file.c @@ -29,6 +29,7 @@ static int afs_readpages(struct file *fi const struct file_operations afs_file_operations = { .open = afs_open, + .flush = afs_flush, .release = afs_release, .llseek = generic_file_llseek, .read = new_sync_read, --- a/fs/afs/internal.h +++ b/fs/afs/internal.h @@ -749,6 +749,7 @@ extern int afs_writepages(struct address extern void afs_pages_written_back(struct afs_vnode *, struct afs_call *); extern ssize_t afs_file_write(struct kiocb *, struct iov_iter *); extern int afs_writeback_all(struct afs_vnode *); +extern int afs_flush(struct file *, fl_owner_t); extern int afs_fsync(struct file *, loff_t, loff_t, int); --- a/fs/afs/write.c +++ b/fs/afs/write.c @@ -743,6 +743,20 @@ out: } /* + * Flush out all outstanding writes on a file opened for writing when it is + * closed. + */ +int afs_flush(struct file *file, fl_owner_t id) +{ + _enter(""); + + if ((file->f_mode & FMODE_WRITE) == 0) + return 0; + + return vfs_fsync(file, 0); +} + +/* * notification that a previously read-only page is about to become writable * - if it returns an error, the caller will deliver a bus error signal */ Patches currently in stable-queue which might be from dhowells(a)redhat.com are queue-3.18/afs-flush-outstanding-writes-when-an-fd-is-closed.patch queue-3.18/afs-fix-the-maths-in-afs_fs_store_data.patch queue-3.18/keys-don-t-permit-request_key-to-construct-a-new-keyring.patch queue-3.18/afs-populate-group-id-from-vnode-status.patch queue-3.18/afs-adjust-mode-bits-processing.patch queue-3.18/afs-fix-page-leak-in-afs_write_begin.patch queue-3.18/afs-fix-missing-put_page.patch queue-3.18/afs-populate-and-use-client-modification-time.patch queue-3.18/afs-fix-afs_kill_pages.patch queue-3.18/don-t-leak-a-key-reference-if-request_key-tries-to-use-a-revoked-keyring.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Fix the maths in afs_fs_store_data()" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Fix the maths in afs_fs_store_data() 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=sum… The filename of the patch is: afs-fix-the-maths-in-afs_fs_store_data.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: David Howells <dhowells(a)redhat.com> Date: Thu, 16 Mar 2017 16:27:47 +0000 Subject: afs: Fix the maths in afs_fs_store_data() From: David Howells <dhowells(a)redhat.com> [ Upstream commit 146a1192783697810b63a1e41c4d59fc93387340 ] afs_fs_store_data() works out of the size of the write it's going to make, but it uses 32-bit unsigned subtraction in one place that gets automatically cast to loff_t. However, if to < offset, then the number goes negative, but as the result isn't signed, this doesn't get sign-extended to 64-bits when placed in a loff_t. Fix by casting the operands to loff_t. Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/afs/fsclient.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/afs/fsclient.c +++ b/fs/afs/fsclient.c @@ -1225,7 +1225,7 @@ int afs_fs_store_data(struct afs_server _enter(",%x,{%x:%u},,", key_serial(wb->key), vnode->fid.vid, vnode->fid.vnode); - size = to - offset; + size = (loff_t)to - (loff_t)offset; if (first != last) size += (loff_t)(last - first) << PAGE_SHIFT; pos = (loff_t)first << PAGE_SHIFT; Patches currently in stable-queue which might be from dhowells(a)redhat.com are queue-3.18/afs-flush-outstanding-writes-when-an-fd-is-closed.patch queue-3.18/afs-fix-the-maths-in-afs_fs_store_data.patch queue-3.18/keys-don-t-permit-request_key-to-construct-a-new-keyring.patch queue-3.18/afs-populate-group-id-from-vnode-status.patch queue-3.18/afs-adjust-mode-bits-processing.patch queue-3.18/afs-fix-page-leak-in-afs_write_begin.patch queue-3.18/afs-fix-missing-put_page.patch queue-3.18/afs-populate-and-use-client-modification-time.patch queue-3.18/afs-fix-afs_kill_pages.patch queue-3.18/don-t-leak-a-key-reference-if-request_key-tries-to-use-a-revoked-keyring.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Fix page leak in afs_write_begin()" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Fix page leak in afs_write_begin() 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=sum… The filename of the patch is: afs-fix-page-leak-in-afs_write_begin.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: David Howells <dhowells(a)redhat.com> Date: Thu, 16 Mar 2017 16:27:48 +0000 Subject: afs: Fix page leak in afs_write_begin() From: David Howells <dhowells(a)redhat.com> [ Upstream commit 6d06b0d25209c80e99c1e89700f1e09694a3766b ] afs_write_begin() leaks a ref and a lock on a page if afs_fill_page() fails. Fix the leak by unlocking and releasing the page in the error path. Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/afs/write.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/fs/afs/write.c +++ b/fs/afs/write.c @@ -149,12 +149,12 @@ int afs_write_begin(struct file *file, s kfree(candidate); return -ENOMEM; } - *pagep = page; - /* page won't leak in error case: it eventually gets cleaned off LRU */ if (!PageUptodate(page) && len != PAGE_CACHE_SIZE) { ret = afs_fill_page(vnode, key, index << PAGE_CACHE_SHIFT, page); if (ret < 0) { + unlock_page(page); + put_page(page); kfree(candidate); _leave(" = %d [prep]", ret); return ret; @@ -162,6 +162,9 @@ int afs_write_begin(struct file *file, s SetPageUptodate(page); } + /* page won't leak in error case: it eventually gets cleaned off LRU */ + *pagep = page; + try_again: spin_lock(&vnode->writeback_lock); Patches currently in stable-queue which might be from dhowells(a)redhat.com are queue-3.18/afs-flush-outstanding-writes-when-an-fd-is-closed.patch queue-3.18/afs-fix-the-maths-in-afs_fs_store_data.patch queue-3.18/keys-don-t-permit-request_key-to-construct-a-new-keyring.patch queue-3.18/afs-populate-group-id-from-vnode-status.patch queue-3.18/afs-adjust-mode-bits-processing.patch queue-3.18/afs-fix-page-leak-in-afs_write_begin.patch queue-3.18/afs-fix-missing-put_page.patch queue-3.18/afs-populate-and-use-client-modification-time.patch queue-3.18/afs-fix-afs_kill_pages.patch queue-3.18/don-t-leak-a-key-reference-if-request_key-tries-to-use-a-revoked-keyring.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Fix afs_kill_pages()" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Fix afs_kill_pages() 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=sum… The filename of the patch is: afs-fix-afs_kill_pages.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: David Howells <dhowells(a)redhat.com> Date: Thu, 16 Mar 2017 16:27:48 +0000 Subject: afs: Fix afs_kill_pages() From: David Howells <dhowells(a)redhat.com> [ Upstream commit 7286a35e893176169b09715096a4aca557e2ccd2 ] Fix afs_kill_pages() in two ways: (1) If a writeback has been partially flushed, then if we try and kill the pages it contains, some of them may no longer be undergoing writeback and end_page_writeback() will assert. Fix this by checking to see whether the page in question is actually undergoing writeback before ending that writeback. (2) The loop that scans for pages to kill doesn't increase the first page index, and so the loop may not terminate, but it will try to process the same pages over and over again. Fix this by increasing the first page index to one after the last page we processed. Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/afs/write.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) --- a/fs/afs/write.c +++ b/fs/afs/write.c @@ -300,10 +300,14 @@ static void afs_kill_pages(struct afs_vn ASSERTCMP(pv.nr, ==, count); for (loop = 0; loop < count; loop++) { - ClearPageUptodate(pv.pages[loop]); + struct page *page = pv.pages[loop]; + ClearPageUptodate(page); if (error) - SetPageError(pv.pages[loop]); - end_page_writeback(pv.pages[loop]); + SetPageError(page); + if (PageWriteback(page)) + end_page_writeback(page); + if (page->index >= first) + first = page->index + 1; } __pagevec_release(&pv); Patches currently in stable-queue which might be from dhowells(a)redhat.com are queue-3.18/afs-flush-outstanding-writes-when-an-fd-is-closed.patch queue-3.18/afs-fix-the-maths-in-afs_fs_store_data.patch queue-3.18/keys-don-t-permit-request_key-to-construct-a-new-keyring.patch queue-3.18/afs-populate-group-id-from-vnode-status.patch queue-3.18/afs-adjust-mode-bits-processing.patch queue-3.18/afs-fix-page-leak-in-afs_write_begin.patch queue-3.18/afs-fix-missing-put_page.patch queue-3.18/afs-populate-and-use-client-modification-time.patch queue-3.18/afs-fix-afs_kill_pages.patch queue-3.18/don-t-leak-a-key-reference-if-request_key-tries-to-use-a-revoked-keyring.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Fix missing put_page()" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Fix missing put_page() 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=sum… The filename of the patch is: afs-fix-missing-put_page.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: David Howells <dhowells(a)redhat.com> Date: Thu, 16 Mar 2017 16:27:43 +0000 Subject: afs: Fix missing put_page() From: David Howells <dhowells(a)redhat.com> [ Upstream commit 29c8bbbd6e21daa0997d1c3ee886b897ee7ad652 ] In afs_writepages_region(), inside the loop where we find dirty pages to deal with, one of the if-statements is missing a put_page(). Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/afs/write.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/afs/write.c +++ b/fs/afs/write.c @@ -504,6 +504,7 @@ static int afs_writepages_region(struct if (PageWriteback(page) || !PageDirty(page)) { unlock_page(page); + put_page(page); continue; } Patches currently in stable-queue which might be from dhowells(a)redhat.com are queue-3.18/afs-flush-outstanding-writes-when-an-fd-is-closed.patch queue-3.18/afs-fix-the-maths-in-afs_fs_store_data.patch queue-3.18/keys-don-t-permit-request_key-to-construct-a-new-keyring.patch queue-3.18/afs-populate-group-id-from-vnode-status.patch queue-3.18/afs-adjust-mode-bits-processing.patch queue-3.18/afs-fix-page-leak-in-afs_write_begin.patch queue-3.18/afs-fix-missing-put_page.patch queue-3.18/afs-populate-and-use-client-modification-time.patch queue-3.18/afs-fix-afs_kill_pages.patch queue-3.18/don-t-leak-a-key-reference-if-request_key-tries-to-use-a-revoked-keyring.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Adjust mode bits processing" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Adjust mode bits processing 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=sum… The filename of the patch is: afs-adjust-mode-bits-processing.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(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 15:03:25 CET 2017 From: Marc Dionne <marc.dionne(a)auristor.com> Date: Thu, 16 Mar 2017 16:27:44 +0000 Subject: afs: Adjust mode bits processing From: Marc Dionne <marc.dionne(a)auristor.com> [ Upstream commit 627f46943ff90bcc32ddeb675d881c043c6fa2ae ] Mode bits for an afs file should not be enforced in the usual way. For files, the absence of user bits can restrict file access with respect to what is granted by the server. These bits apply regardless of the owner or the current uid; the rest of the mode bits (group, other) are ignored. Signed-off-by: Marc Dionne <marc.dionne(a)auristor.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/afs/security.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) --- a/fs/afs/security.c +++ b/fs/afs/security.c @@ -340,17 +340,22 @@ int afs_permission(struct inode *inode, } else { if (!(access & AFS_ACE_LOOKUP)) goto permission_denied; + if ((mask & MAY_EXEC) && !(inode->i_mode & S_IXUSR)) + goto permission_denied; if (mask & (MAY_EXEC | MAY_READ)) { if (!(access & AFS_ACE_READ)) goto permission_denied; + if (!(inode->i_mode & S_IRUSR)) + goto permission_denied; } else if (mask & MAY_WRITE) { if (!(access & AFS_ACE_WRITE)) goto permission_denied; + if (!(inode->i_mode & S_IWUSR)) + goto permission_denied; } } key_put(key); - ret = generic_permission(inode, mask); _leave(" = %d", ret); return ret; Patches currently in stable-queue which might be from marc.dionne(a)auristor.com are queue-3.18/afs-populate-group-id-from-vnode-status.patch queue-3.18/afs-adjust-mode-bits-processing.patch queue-3.18/afs-populate-and-use-client-modification-time.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] [GIT PULL] commits for Linux 3.18

by alexander.levin＠verizon.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Greg, Pleae pull commits for Linux 3.18 . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== The following changes since commit 1d2acf22c2539c568e0a4bd63bf464e10acd8070: Linux 3.18.86 (2017-12-05 11:20:47 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git tags/for-greg-3.18-14122017 for you to fetch changes up to b15af543ba146d4d241a2f754473a388952ffca2: ath9k: fix tx99 potential info leak (2017-12-14 10:27:20 -0500) - ---------------------------------------------------------------- for-greg-3.18-14122017 - ---------------------------------------------------------------- Alex Deucher (2): drm/radeon/si: add dpm quirk for Oland drm/radeon: reinstate oland workaround for sclk Alex Williamson (1): PCI: Detach driver before procfs & sysfs teardown on device remove Alexander Duyck (1): macvlan: Only deliver one copy of the frame to the macvlan interface Bart Van Assche (1): target/iscsi: Fix a race condition in iscsit_add_reject_from_cmd() Bob Peterson (1): GFS2: Take inode off order_write list when setting jdata flag Brian Foster (1): xfs: fix log block underflow during recovery cycle verification Christophe JAILLET (2): video: fbdev: au1200fb: Release some resources if a memory allocation fails video: fbdev: au1200fb: Return an error code if a memory allocation fails Christophe Leroy (1): powerpc/ipic: Fix status get and status clear Dan Carpenter (1): scsi: bfa: integer overflow in debugfs Daniel Borkmann (1): perf symbols: Fix symbols__fixup_end heuristic for corner cases Daniel Lezcano (1): thermal/drivers/step_wise: Fix temperature regulation misbehavior David Howells (5): afs: Fix missing put_page() afs: Flush outstanding writes when an fd is closed afs: Fix the maths in afs_fs_store_data() afs: Fix page leak in afs_write_begin() afs: Fix afs_kill_pages() Dmitry Torokhov (1): Input: i8042 - add TUXEDO BU1406 (N24_25BU) to the nomux list Doug Berger (3): net: bcmgenet: correct the RBUF_OVFL_CNT and RBUF_ERR_CNT MIB values net: bcmgenet: correct MIB access of UniMAC RUNT counters net: bcmgenet: Power up the internal PHY before probing the MII Gao Feng (1): ppp: Destroy the mutex when cleanup Geert Uytterhoeven (1): fbdev: controlfb: Add missing modes to fix out of bounds access Jan Kara (2): mm: Handle 0 flags in _calc_vm_trans() macro udf: Avoid overflow when session starts at large offset Javier Martinez Canillas (1): usb: phy: isp1301: Add OF device ID table Jiang Yi (1): target/file: Do not return error for UNMAP if length is zero Johan Hovold (1): net: wimax/i2400m: fix NULL-deref at probe Kurt Garloff (1): scsi: scsi_devinfo: Add REPORTLUN2 to EMC SYMMETRIX blacklist entry Ladislav Michl (1): video: udlfb: Fix read EDID timeout Liang Chen (1): bcache: explicitly destroy mutex while exiting Linus Walleij (1): pinctrl: adi2: Fix Kconfig build problem Marc Dionne (3): afs: Populate group ID from vnode status afs: Adjust mode bits processing afs: Populate and use client modification time Markus Elfring (1): platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill() Matthias Kaehlcke (1): dmaengine: Fix array index out of bounds warning in __get_unmap_pool() Miaoqing Pan (1): ath9k: fix tx99 potential info leak MichaÅ‚ MirosÅ‚aw (1): clk: tegra: Fix cclk_lp divisor register Mike Christie (1): target: Use system workqueue for ALUA transitions NeilBrown (3): NFSD: fix nfsd_minorversion(.., NFSD_AVAIL) NFSD: fix nfsd_reset_versions for NFSv4. raid5: Set R5_Expanded on parity devices as well as data. Olga Kornievskaia (1): NFSv4.1 respect server's max size in CREATE_SESSION Qiang (1): PCI/PME: Handle invalid data when reading Root Status Shriya (1): powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo Stafford Horne (1): openrisc: fix issue handling 8 byte get_user calls Steven Rostedt (VMware) (1): sched/deadline: Use deadline instead of period when calculating overflow Suzuki K Poulose (1): arm-ccn: perf: Prevent module unload while PMU is in use Vlad Yasevich (1): net: Resend IGMP memberships upon peer notification. William A. Kennington III (1): powerpc/opal: Fix EBUSY bug in acquiring tokens Zygo Blaxell (1): btrfs: add missing memset while reading compressed inline extents nixiaoming (1): tty fix oops when rmmod 8250 tang.junhui (1): bcache: fix wrong cache_misses statistics tangwenji (2): iscsi-target: fix memory leak in lio_target_tiqn_addtpg() target:fix condition return in core_pr_dump_initiator_port() arch/blackfin/Kconfig | 7 ++- arch/blackfin/Kconfig.debug | 1 + arch/openrisc/include/asm/uaccess.h | 2 +- arch/powerpc/platforms/powernv/opal-async.c | 6 +- arch/powerpc/platforms/powernv/setup.c | 2 +- arch/powerpc/sysdev/ipic.c | 4 +- drivers/bus/arm-ccn.c | 1 + drivers/clk/tegra/clk-tegra30.c | 2 +- drivers/dma/dmaengine.c | 2 + drivers/gpu/drm/radeon/si_dpm.c | 10 ++++ drivers/input/serio/i8042-x86ia64io.h | 7 +++ drivers/md/bcache/request.c | 6 +- drivers/md/bcache/super.c | 6 +- drivers/md/raid5.c | 5 +- drivers/net/ethernet/broadcom/genet/bcmgenet.c | 79 ++++++++++++++++++++++---- drivers/net/ethernet/broadcom/genet/bcmgenet.h | 10 +++- drivers/net/macvlan.c | 2 +- drivers/net/ppp/ppp_generic.c | 1 + drivers/net/wimax/i2400m/usb.c | 3 + drivers/net/wireless/ath/ath9k/tx99.c | 5 ++ drivers/pci/pcie/pme.c | 5 +- drivers/pci/remove.c | 2 +- drivers/pinctrl/Kconfig | 3 +- drivers/platform/x86/sony-laptop.c | 14 +++-- drivers/scsi/bfa/bfad_debugfs.c | 5 +- drivers/scsi/scsi_devinfo.c | 2 +- drivers/target/iscsi/iscsi_target.c | 3 +- drivers/target/iscsi/iscsi_target_configfs.c | 3 +- drivers/target/target_core_alua.c | 8 +-- drivers/target/target_core_file.c | 4 ++ drivers/target/target_core_pr.c | 4 +- drivers/thermal/step_wise.c | 11 ++-- drivers/usb/phy/phy-isp1301.c | 7 +++ drivers/video/fbdev/au1200fb.c | 7 ++- drivers/video/fbdev/controlfb.h | 2 + drivers/video/fbdev/udlfb.c | 10 ++-- fs/afs/file.c | 1 + fs/afs/fsclient.c | 20 +++---- fs/afs/inode.c | 4 +- fs/afs/internal.h | 1 + fs/afs/security.c | 7 ++- fs/afs/write.c | 32 +++++++++-- fs/btrfs/inode.c | 14 +++++ fs/gfs2/file.c | 4 +- fs/nfs/nfs4client.c | 4 +- fs/nfsd/nfssvc.c | 30 +++++----- fs/proc/proc_tty.c | 3 +- fs/udf/super.c | 2 +- fs/xfs/xfs_log_recover.c | 2 +- include/linux/mman.h | 3 +- kernel/sched/deadline.c | 8 +-- net/core/dev.c | 1 + tools/perf/util/symbol.c | 2 +- 53 files changed, 282 insertions(+), 107 deletions(-) -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaMqM3AAoJEN6mb/eXdyzceNMQAIK3SrQ/pnyfmQJNq8rWjkcO ahYO2eYjmdnGZ5oP7KWF8BhI/cDRVyWfdy8UJNQxemqjqlucbDSJpFxd+1D4Hkkd xpPmdsPTrZM7KR9rDC9tRQMd4l+cY5erZEWPUbGIKLth86e3/+k+bKebEwiWKuFx cXeYLWYd+DgdNUL0t1y3UZWZZD4cF/UX+VPEr/ecMC9ONUftOSdyTNLDX8eLKnXf XPt09JVHLm51mtd6sS2UeA/sjVx9RrNshY0be0reDIJ/4bMpvVVrKTwKnosDU7v0 0ksiGWRgk/OhRYqeUWjb4SR4otNnGluDj3HBRgrzfs8LzLp/1pB52E9Xh1IuCVg+ YmDJA43G+XTnGyZfCKwZSfMhnHP2psj8eN0viQS+fpCC72G9SEGGDecxC/U9agej dJ9XonCBguHNHF7MM/gH58ZjtOONhAGnr0GlRZaYCU05HdriF408tq4uV2Gv9xT1 ctqvTW23SaWDcJ58/cAvUyU9710yOS1uftoAUG3UmG9KZM/600vtOsXIKD/1CUmG 1GeJd/bW6iBnILzRn4qAGQZyCUyD3XuLyQB5mfaVByHKdbX543iHlVu/JWvgH3cp hxLnlPClawWnYmVSQ8vqfwGnON4mfscORQeZo5QS/TQfgMPNkXAeOvWUxFzqoDEP gdzTvc+DRnMB2+EyM916 =SeOH -----END PGP SIGNATURE-----

7 years, 6 months

2
1
0 0

[Linux-stable-mirror] [GIT PULL] commits for Linux 4.4

by alexander.levin＠verizon.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Greg, Pleae pull commits for Linux 4.4 . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== The following changes since commit bd379939182247ace70e425ab60b3b1352db601b: Linux 4.4.104 (2017-12-05 11:22:52 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git tags/for-greg-4.4-14122017 for you to fetch changes up to 641f751d70659f695a9cbaaa35bd3f670be7a272: ath9k: fix tx99 potential info leak (2017-12-14 10:25:31 -0500) - ---------------------------------------------------------------- for-greg-4.4-14122017 - ---------------------------------------------------------------- Alex Deucher (2): drm/radeon/si: add dpm quirk for Oland drm/radeon: reinstate oland workaround for sclk Alex Vesker (1): IB/ipoib: Grab rtnl lock on heavy flush when calling ndo_open/stop Alex Williamson (1): PCI: Detach driver before procfs & sysfs teardown on device remove Alexander Duyck (1): macvlan: Only deliver one copy of the frame to the macvlan interface Alexander Potapenko (1): net: initialize msg.msg_flags in recvfrom Alexander Shishkin (1): intel_th: pci: Add Gemini Lake support Andrea Arcangeli (2): userfaultfd: shmem: __do_fault requires VM_FAULT_NOPAGE userfaultfd: selftest: vm: allow to build in vm/ directory Bart Van Assche (2): target/iscsi: Fix a race condition in iscsit_add_reject_from_cmd() RDMA/cma: Avoid triggering undefined behavior Bob Peterson (1): GFS2: Take inode off order_write list when setting jdata flag Brian Foster (1): xfs: fix log block underflow during recovery cycle verification Chen Zhong (1): clk: mediatek: add the option for determining PLL source clock Christoph Hellwig (1): xfs: fix incorrect extent state in xfs_bmap_add_extent_unwritten_real Christophe JAILLET (2): video: fbdev: au1200fb: Release some resources if a memory allocation fails video: fbdev: au1200fb: Return an error code if a memory allocation fails Christophe Leroy (1): powerpc/ipic: Fix status get and status clear Dan Carpenter (1): scsi: bfa: integer overflow in debugfs Daniel Borkmann (1): perf symbols: Fix symbols__fixup_end heuristic for corner cases Daniel Bristot de Oliveira (2): sched/deadline: Make sure the replenishment timer fires in the next period sched/deadline: Throttle a constrained deadline task activated after the deadline Daniel Drake (1): efi/esrt: Cleanup bad memory map log messages Daniel Lezcano (1): thermal/drivers/step_wise: Fix temperature regulation misbehavior David Howells (5): afs: Fix missing put_page() afs: Flush outstanding writes when an fd is closed afs: Fix the maths in afs_fs_store_data() afs: Fix page leak in afs_write_begin() afs: Fix afs_kill_pages() Dmitry Torokhov (1): Input: i8042 - add TUXEDO BU1406 (N24_25BU) to the nomux list Don Brace (2): scsi: hpsa: update check for logical volume status scsi: hpsa: limit outstanding rescans Doug Berger (5): net: bcmgenet: correct the RBUF_OVFL_CNT and RBUF_ERR_CNT MIB values net: bcmgenet: correct MIB access of UniMAC RUNT counters net: bcmgenet: reserved phy revisions must be checked first net: bcmgenet: power down internal phy if open or resume fails net: bcmgenet: Power up the internal PHY before probing the MII Florian Westphal (1): netfilter: bridge: honor frag_max_size when refragmenting Gao Feng (1): ppp: Destroy the mutex when cleanup Geert Uytterhoeven (1): fbdev: controlfb: Add missing modes to fix out of bounds access Guoqing Jiang (1): md-cluster: free md_cluster_info if node leave cluster Hiroyuki Yokoyama (1): dmaengine: rcar-dmac: use TCRB instead of TCR for residue Jack Morgenstein (1): net/mlx4_core: Avoid delays during VF driver device shutdown Jan Kara (2): mm: Handle 0 flags in _calc_vm_trans() macro udf: Avoid overflow when session starts at large offset Javier Martinez Canillas (1): usb: phy: isp1301: Add OF device ID table Jia-Ju Bai (1): vt6655: Fix a possible sleep-in-atomic bug in vt6655_suspend Jiang Yi (1): target/file: Do not return error for UNMAP if length is zero Jiri Pirko (2): mlxsw: reg: Fix SPVM max record count mlxsw: reg: Fix SPVMLR max record count Jiri Slaby (1): l2tp: cleanup l2tp_tunnel_delete calls Johan Hovold (1): net: wimax/i2400m: fix NULL-deref at probe KUWAZAWA Takuya (1): netfilter: ipvs: Fix inappropriate output of procfs Kurt Garloff (1): scsi: scsi_devinfo: Add REPORTLUN2 to EMC SYMMETRIX blacklist entry Ladislav Michl (1): video: udlfb: Fix read EDID timeout Liang Chen (1): bcache: explicitly destroy mutex while exiting Linus Walleij (1): pinctrl: adi2: Fix Kconfig build problem Marc Dionne (3): afs: Populate group ID from vnode status afs: Adjust mode bits processing afs: Populate and use client modification time Markus Elfring (1): platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill() Martin Wilck (2): scsi: hpsa: cleanup sas_phy structures in sysfs when unloading scsi: hpsa: destroy sas transport properties before scsi_host Matthias Kaehlcke (1): dmaengine: Fix array index out of bounds warning in __get_unmap_pool() Miaoqing Pan (1): ath9k: fix tx99 potential info leak Michael Ellerman (1): powerpc/perf/hv-24x7: Fix incorrect comparison in memord MichaÅ‚ MirosÅ‚aw (1): clk: tegra: Fix cclk_lp divisor register Mike Christie (3): target: Use system workqueue for ALUA transitions target: fix ALUA transition timeout handling target: fix race during implicit transition work flushes NeilBrown (3): NFSD: fix nfsd_minorversion(.., NFSD_AVAIL) NFSD: fix nfsd_reset_versions for NFSv4. raid5: Set R5_Expanded on parity devices as well as data. Olga Kornievskaia (1): NFSv4.1 respect server's max size in CREATE_SESSION Peter Ujfalusi (1): dmaengine: ti-dma-crossbar: Correct am335x/am43xx mux value type Philipp Zabel (1): rtc: pcf8563: fix output clock rate Qiang (1): PCI/PME: Handle invalid data when reading Root Status Robert Baronescu (1): crypto: tcrypt - fix buffer lengths in test_aead_speed() Robert Stonehouse (1): sfc: don't warn on successful change of MAC Shriya (1): powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo Stafford Horne (1): openrisc: fix issue handling 8 byte get_user calls Steven Rostedt (VMware) (1): sched/deadline: Use deadline instead of period when calculating overflow Suzuki K Poulose (1): arm-ccn: perf: Prevent module unload while PMU is in use SÃ©bastien Szymanski (1): clk: imx6: refine hdmi_isfr's parent to make HDMI work on i.MX6 SoCs w/o VPU Tahsin Erdogan (1): writeback: fix memory leak in wb_queue_work() Taku Izumi (1): fjes: Fix wrong netdevice feature flags Tina Ruchandani (2): afs: Migrate vlocation fields to 64-bit afs: Prevent callback expiry timer overflow Tomi Valkeinen (1): drm/omap: fix dmabuf mmap for dma_alloc'ed buffers Vlad Yasevich (1): net: Resend IGMP memberships upon peer notification. William A. Kennington III (1): powerpc/opal: Fix EBUSY bug in acquiring tokens Zygo Blaxell (1): btrfs: add missing memset while reading compressed inline extents nixiaoming (1): tty fix oops when rmmod 8250 tang.junhui (1): bcache: fix wrong cache_misses statistics tangwenji (2): iscsi-target: fix memory leak in lio_target_tiqn_addtpg() target:fix condition return in core_pr_dump_initiator_port() weiping zhang (2): scsi: sd: change manage_start_stop to bool in sysfs interface scsi: sd: change allow_restart to bool in sysfs interface yong mao (1): mmc: mediatek: Fixed bug where clock frequency could be set wrong arch/blackfin/Kconfig | 7 +- arch/blackfin/Kconfig.debug | 1 + arch/openrisc/include/asm/uaccess.h | 2 +- arch/powerpc/perf/hv-24x7.c | 2 +- arch/powerpc/platforms/powernv/opal-async.c | 6 +- arch/powerpc/platforms/powernv/setup.c | 2 +- arch/powerpc/sysdev/ipic.c | 4 +- crypto/tcrypt.c | 6 +- drivers/bus/arm-ccn.c | 1 + drivers/clk/imx/clk-imx6q.c | 2 +- drivers/clk/mediatek/clk-mtk.h | 1 + drivers/clk/mediatek/clk-pll.c | 5 +- drivers/clk/tegra/clk-tegra30.c | 2 +- drivers/dma/dmaengine.c | 2 + drivers/dma/sh/rcar-dmac.c | 2 +- drivers/dma/ti-dma-crossbar.c | 8 +-- drivers/firmware/efi/efi.c | 1 - drivers/firmware/efi/esrt.c | 2 +- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 3 - drivers/gpu/drm/radeon/si_dpm.c | 10 +++ drivers/hwtracing/intel_th/pci.c | 5 ++ drivers/infiniband/core/cma.c | 11 +-- drivers/infiniband/ulp/ipoib/ipoib_ib.c | 7 +- drivers/input/serio/i8042-x86ia64io.h | 7 ++ drivers/md/bcache/request.c | 6 +- drivers/md/bcache/super.c | 6 +- drivers/md/md-cluster.c | 1 + drivers/md/raid5.c | 5 +- drivers/mmc/host/mtk-sd.c | 4 +- drivers/net/ethernet/broadcom/genet/bcmgenet.c | 95 +++++++++++++++++++++----- drivers/net/ethernet/broadcom/genet/bcmgenet.h | 10 ++- drivers/net/ethernet/mellanox/mlx4/cmd.c | 11 +++ drivers/net/ethernet/mellanox/mlx4/main.c | 11 +++ drivers/net/ethernet/mellanox/mlxsw/reg.h | 4 +- drivers/net/ethernet/sfc/ef10.c | 2 +- drivers/net/fjes/fjes_main.c | 2 +- drivers/net/macvlan.c | 2 +- drivers/net/ppp/ppp_generic.c | 1 + drivers/net/wimax/i2400m/usb.c | 3 + drivers/net/wireless/ath/ath9k/tx99.c | 5 ++ drivers/pci/pcie/pme.c | 5 +- drivers/pci/remove.c | 2 +- drivers/pinctrl/Kconfig | 3 +- drivers/platform/x86/sony-laptop.c | 14 ++-- drivers/rtc/rtc-pcf8563.c | 2 +- drivers/scsi/bfa/bfad_debugfs.c | 5 +- drivers/scsi/hpsa.c | 57 +++++++++------- drivers/scsi/hpsa.h | 1 + drivers/scsi/hpsa_cmd.h | 2 + drivers/scsi/scsi_devinfo.c | 2 +- drivers/scsi/sd.c | 12 +++- drivers/staging/vt6655/device_main.c | 3 +- drivers/target/iscsi/iscsi_target.c | 3 +- drivers/target/iscsi/iscsi_target_configfs.c | 3 +- drivers/target/target_core_alua.c | 33 +++------ drivers/target/target_core_file.c | 4 ++ drivers/target/target_core_pr.c | 4 +- drivers/thermal/step_wise.c | 11 +-- drivers/usb/phy/phy-isp1301.c | 7 ++ drivers/video/fbdev/au1200fb.c | 7 +- drivers/video/fbdev/controlfb.h | 2 + drivers/video/fbdev/udlfb.c | 10 +-- fs/afs/callback.c | 7 +- fs/afs/file.c | 1 + fs/afs/fsclient.c | 22 +++--- fs/afs/inode.c | 11 +-- fs/afs/internal.h | 12 ++-- fs/afs/security.c | 7 +- fs/afs/server.c | 6 +- fs/afs/vlocation.c | 16 +++-- fs/afs/write.c | 32 +++++++-- fs/btrfs/inode.c | 14 ++++ fs/fs-writeback.c | 35 ++++++---- fs/gfs2/file.c | 4 +- fs/nfs/nfs4client.c | 4 +- fs/nfsd/nfssvc.c | 30 ++++---- fs/proc/proc_tty.c | 3 +- fs/udf/super.c | 2 +- fs/userfaultfd.c | 2 +- fs/xfs/libxfs/xfs_bmap.c | 2 +- fs/xfs/xfs_log_recover.c | 2 +- include/linux/mlx4/device.h | 1 + include/linux/mman.h | 3 +- include/target/target_core_base.h | 2 +- kernel/sched/deadline.c | 62 +++++++++++++++-- net/bridge/br_netfilter_hooks.c | 12 ++-- net/core/dev.c | 1 + net/l2tp/l2tp_core.c | 2 +- net/l2tp/l2tp_netlink.c | 2 +- net/netfilter/ipvs/ip_vs_ctl.c | 4 ++ net/socket.c | 1 + tools/perf/util/symbol.c | 2 +- tools/testing/selftests/vm/Makefile | 4 ++ 93 files changed, 533 insertions(+), 234 deletions(-) -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaMqMuAAoJEN6mb/eXdyzcMBwP/3TUW/yQFmpqUSHHOGlLTMpW b+0/Aa+F5aYKJxLtLq8VtH7QnI81vzZfOiI3P0HAlyvx8GctaQGKlJ3nc4JEJ/OK WwswHEXP0DNdeYA0vYEyl+inzfjVAERJSXHj0r2nBaGdMpP22hGmL9+HT52uSIy9 59K+yURNkevrVTvCvuF3aCxHaULL+kb9/pHWTEGRvlHfG8W1npj1wf8mhPwt0mJ0 s9avnjGsegUZ7sCrre7dYdjTFlbjezH+5U3YrJPlxc+eYElHDHOnreFc5iuR1gO+ ahieKX01spDzRRjC3TJG3ORDa3IN4UKppAg6TgnBEy2OiFGhZC1QCgDqIag/t9Pu tMPlInkTeObyGH0yIb02I+iCONF8SyjqeWCVMzZun4a99V+siHCxKFYVfZwga4A9 PTAvH+DEJIifGkMeDAttIWx9zLq5SYQOPF7WBx/97UB8/31JZEup9QstqtC2MWJN 8QW8HLgN6UR6dPsReUdJ+eOQeFCG6+Lrt5J2JQ+LTYheJwZu39cqiBDLmimNrIkQ t+p42yPJozKKaJv+By+NGvmeug7BqK3kADEYPs7iNmqj8U+BSmnyX2zU1PichxLi sEHlo2ds7t543dy4F4n7Vg7kO2nFDYN5NhYFSunjMSAlZJED9+L1mU3AgWgPHm85 4dJEyRmojvzpGt1CN5UI =lEhB -----END PGP SIGNATURE-----

7 years, 6 months

2
1
0 0

[Linux-stable-mirror] Patch "xfs: fix log block underflow during recovery cycle verification" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xfs: fix log block underflow during recovery cycle verification to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: xfs-fix-log-block-underflow-during-recovery-cycle-verification.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Brian Foster <bfoster(a)redhat.com> Date: Thu, 26 Oct 2017 09:31:16 -0700 Subject: xfs: fix log block underflow during recovery cycle verification From: Brian Foster <bfoster(a)redhat.com> [ Upstream commit 9f2a4505800607e537e9dd9dea4f55c4b0c30c7a ] It is possible for mkfs to format very small filesystems with too small of an internal log with respect to the various minimum size and block count requirements. If this occurs when the log happens to be smaller than the scan window used for cycle verification and the scan wraps the end of the log, the start_blk calculation in xlog_find_head() underflows and leads to an attempt to scan an invalid range of log blocks. This results in log recovery failure and a failed mount. Since there may be filesystems out in the wild with this kind of geometry, we cannot simply refuse to mount. Instead, cap the scan window for cycle verification to the size of the physical log. This ensures that the cycle verification proceeds as expected when the scan wraps the end of the log. Reported-by: Zorro Lang <zlang(a)redhat.com> Signed-off-by: Brian Foster <bfoster(a)redhat.com> Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/xfs/xfs_log_recover.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/xfs/xfs_log_recover.c +++ b/fs/xfs/xfs_log_recover.c @@ -738,7 +738,7 @@ xlog_find_head( * in the in-core log. The following number can be made tighter if * we actually look at the block size of the filesystem. */ - num_scan_bblks = XLOG_TOTAL_REC_SHIFT(log); + num_scan_bblks = min_t(int, log_bbnum, XLOG_TOTAL_REC_SHIFT(log)); if (head_blk >= num_scan_bblks) { /* * We are guaranteed that the entire check can be performed Patches currently in stable-queue which might be from bfoster(a)redhat.com are queue-4.4/xfs-fix-incorrect-extent-state-in-xfs_bmap_add_extent_unwritten_real.patch queue-4.4/xfs-fix-log-block-underflow-during-recovery-cycle-verification.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "xfs: fix incorrect extent state in xfs_bmap_add_extent_unwritten_real" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xfs: fix incorrect extent state in xfs_bmap_add_extent_unwritten_real to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: xfs-fix-incorrect-extent-state-in-xfs_bmap_add_extent_unwritten_real.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Christoph Hellwig <hch(a)lst.de> Date: Tue, 17 Oct 2017 14:16:19 -0700 Subject: xfs: fix incorrect extent state in xfs_bmap_add_extent_unwritten_real From: Christoph Hellwig <hch(a)lst.de> [ Upstream commit 5e422f5e4fd71d18bc6b851eeb3864477b3d842e ] There was one spot in xfs_bmap_add_extent_unwritten_real that didn't use the passed in new extent state but always converted to normal, leading to wrong behavior when converting from normal to unwritten. Only found by code inspection, it seems like this code path to move partial extent from written to unwritten while merging it with the next extent is rarely exercised. Signed-off-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Brian Foster <bfoster(a)redhat.com> Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/xfs/libxfs/xfs_bmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/xfs/libxfs/xfs_bmap.c +++ b/fs/xfs/libxfs/xfs_bmap.c @@ -2670,7 +2670,7 @@ xfs_bmap_add_extent_unwritten_real( &i))) goto done; XFS_WANT_CORRUPTED_GOTO(mp, i == 0, done); - cur->bc_rec.b.br_state = XFS_EXT_NORM; + cur->bc_rec.b.br_state = new->br_state; if ((error = xfs_btree_insert(cur, &i))) goto done; XFS_WANT_CORRUPTED_GOTO(mp, i == 1, done); Patches currently in stable-queue which might be from hch(a)lst.de are queue-4.4/xfs-fix-incorrect-extent-state-in-xfs_bmap_add_extent_unwritten_real.patch queue-4.4/target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "writeback: fix memory leak in wb_queue_work()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled writeback: fix memory leak in wb_queue_work() to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: writeback-fix-memory-leak-in-wb_queue_work.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Tahsin Erdogan <tahsin(a)google.com> Date: Fri, 10 Mar 2017 12:09:49 -0800 Subject: writeback: fix memory leak in wb_queue_work() From: Tahsin Erdogan <tahsin(a)google.com> [ Upstream commit 4a3a485b1ed0e109718cc8c9d094fa0f552de9b2 ] When WB_registered flag is not set, wb_queue_work() skips queuing the work, but does not perform the necessary clean up. In particular, if work->auto_free is true, it should free the memory. The leak condition can be reprouced by following these steps: mount /dev/sdb /mnt/sdb /* In qemu console: device_del sdb */ umount /dev/sdb Above will result in a wb_queue_work() call on an unregistered wb and thus leak memory. Reported-by: John Sperbeck <jsperbeck(a)google.com> Signed-off-by: Tahsin Erdogan <tahsin(a)google.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Jens Axboe <axboe(a)fb.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/fs-writeback.c | 35 +++++++++++++++++++++-------------- 1 file changed, 21 insertions(+), 14 deletions(-) --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -173,19 +173,33 @@ static void wb_wakeup(struct bdi_writeba spin_unlock_bh(&wb->work_lock); } +static void finish_writeback_work(struct bdi_writeback *wb, + struct wb_writeback_work *work) +{ + struct wb_completion *done = work->done; + + if (work->auto_free) + kfree(work); + if (done && atomic_dec_and_test(&done->cnt)) + wake_up_all(&wb->bdi->wb_waitq); +} + static void wb_queue_work(struct bdi_writeback *wb, struct wb_writeback_work *work) { trace_writeback_queue(wb, work); - spin_lock_bh(&wb->work_lock); - if (!test_bit(WB_registered, &wb->state)) - goto out_unlock; if (work->done) atomic_inc(&work->done->cnt); - list_add_tail(&work->list, &wb->work_list); - mod_delayed_work(bdi_wq, &wb->dwork, 0); -out_unlock: + + spin_lock_bh(&wb->work_lock); + + if (test_bit(WB_registered, &wb->state)) { + list_add_tail(&work->list, &wb->work_list); + mod_delayed_work(bdi_wq, &wb->dwork, 0); + } else + finish_writeback_work(wb, work); + spin_unlock_bh(&wb->work_lock); } @@ -1839,16 +1853,9 @@ static long wb_do_writeback(struct bdi_w set_bit(WB_writeback_running, &wb->state); while ((work = get_next_work_item(wb)) != NULL) { - struct wb_completion *done = work->done; - trace_writeback_exec(wb, work); - wrote += wb_writeback(wb, work); - - if (work->auto_free) - kfree(work); - if (done && atomic_dec_and_test(&done->cnt)) - wake_up_all(&wb->bdi->wb_waitq); + finish_writeback_work(wb, work); } /* Patches currently in stable-queue which might be from tahsin(a)google.com are queue-4.4/writeback-fix-memory-leak-in-wb_queue_work.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "vt6655: Fix a possible sleep-in-atomic bug in vt6655_suspend" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled vt6655: Fix a possible sleep-in-atomic bug in vt6655_suspend to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: vt6655-fix-a-possible-sleep-in-atomic-bug-in-vt6655_suspend.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Jia-Ju Bai <baijiaju1990(a)163.com> Date: Mon, 9 Oct 2017 16:45:55 +0800 Subject: vt6655: Fix a possible sleep-in-atomic bug in vt6655_suspend From: Jia-Ju Bai <baijiaju1990(a)163.com> [ Upstream commit 42c8eb3f6e15367981b274cb79ee4657e2c6949d ] The driver may sleep under a spinlock, and the function call path is: vt6655_suspend (acquire the spinlock) pci_set_power_state __pci_start_power_transition (drivers/pci/pci.c) msleep --> may sleep To fix it, pci_set_power_state is called without having a spinlock. This bug is found by my static analysis tool and my code review. Signed-off-by: Jia-Ju Bai <baijiaju1990(a)163.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/vt6655/device_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/staging/vt6655/device_main.c +++ b/drivers/staging/vt6655/device_main.c @@ -1693,10 +1693,11 @@ static int vt6655_suspend(struct pci_dev MACbShutdown(priv->PortOffset); pci_disable_device(pcid); - pci_set_power_state(pcid, pci_choose_state(pcid, state)); spin_unlock_irqrestore(&priv->lock, flags); + pci_set_power_state(pcid, pci_choose_state(pcid, state)); + return 0; } Patches currently in stable-queue which might be from baijiaju1990(a)163.com are queue-4.4/vt6655-fix-a-possible-sleep-in-atomic-bug-in-vt6655_suspend.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "video: udlfb: Fix read EDID timeout" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled video: udlfb: Fix read EDID timeout to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: video-udlfb-fix-read-edid-timeout.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Ladislav Michl <ladis(a)linux-mips.org> Date: Thu, 9 Nov 2017 18:09:30 +0100 Subject: video: udlfb: Fix read EDID timeout From: Ladislav Michl <ladis(a)linux-mips.org> [ Upstream commit c98769475575c8a585f5b3952f4b5f90266f699b ] While usb_control_msg function expects timeout in miliseconds, a value of HZ is used. Replace it with USB_CTRL_GET_TIMEOUT and also fix error message which looks like: udlfb: Read EDID byte 78 failed err ffffff92 as error is either negative errno or number of bytes transferred use %d format specifier. Returned EDID is in second byte, so return error when less than two bytes are received. Fixes: 18dffdf8913a ("staging: udlfb: enhance EDID and mode handling support") Signed-off-by: Ladislav Michl <ladis(a)linux-mips.org> Cc: Bernie Thompson <bernie(a)plugable.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/fbdev/udlfb.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- a/drivers/video/fbdev/udlfb.c +++ b/drivers/video/fbdev/udlfb.c @@ -769,11 +769,11 @@ static int dlfb_get_edid(struct dlfb_dat for (i = 0; i < len; i++) { ret = usb_control_msg(dev->udev, - usb_rcvctrlpipe(dev->udev, 0), (0x02), - (0x80 | (0x02 << 5)), i << 8, 0xA1, rbuf, 2, - HZ); - if (ret < 1) { - pr_err("Read EDID byte %d failed err %x\n", i, ret); + usb_rcvctrlpipe(dev->udev, 0), 0x02, + (0x80 | (0x02 << 5)), i << 8, 0xA1, + rbuf, 2, USB_CTRL_GET_TIMEOUT); + if (ret < 2) { + pr_err("Read EDID byte %d failed: %d\n", i, ret); i--; break; } Patches currently in stable-queue which might be from ladis(a)linux-mips.org are queue-4.4/video-udlfb-fix-read-edid-timeout.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "video: fbdev: au1200fb: Return an error code if a memory allocation fails" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled video: fbdev: au1200fb: Return an error code if a memory allocation fails to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: video-fbdev-au1200fb-return-an-error-code-if-a-memory-allocation-fails.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Thu, 9 Nov 2017 18:09:28 +0100 Subject: video: fbdev: au1200fb: Return an error code if a memory allocation fails From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> [ Upstream commit 8cae353e6b01ac3f18097f631cdbceb5ff28c7f3 ] 'ret' is known to be 0 at this point. In case of memory allocation error in 'framebuffer_alloc()', return -ENOMEM instead. Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Cc: Tejun Heo <tj(a)kernel.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/fbdev/au1200fb.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/video/fbdev/au1200fb.c +++ b/drivers/video/fbdev/au1200fb.c @@ -1680,8 +1680,10 @@ static int au1200fb_drv_probe(struct pla fbi = framebuffer_alloc(sizeof(struct au1200fb_device), &dev->dev); - if (!fbi) + if (!fbi) { + ret = -ENOMEM; goto failed; + } _au1200fb_infos[plane] = fbi; fbdev = fbi->par; Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-4.4/video-fbdev-au1200fb-release-some-resources-if-a-memory-allocation-fails.patch queue-4.4/video-fbdev-au1200fb-return-an-error-code-if-a-memory-allocation-fails.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "video: fbdev: au1200fb: Release some resources if a memory allocation fails" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled video: fbdev: au1200fb: Release some resources if a memory allocation fails to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: video-fbdev-au1200fb-release-some-resources-if-a-memory-allocation-fails.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Thu, 9 Nov 2017 18:09:28 +0100 Subject: video: fbdev: au1200fb: Release some resources if a memory allocation fails From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> [ Upstream commit 451f130602619a17c8883dd0b71b11624faffd51 ] We should go through the error handling code instead of returning -ENOMEM directly. Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Cc: Tejun Heo <tj(a)kernel.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/fbdev/au1200fb.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/video/fbdev/au1200fb.c +++ b/drivers/video/fbdev/au1200fb.c @@ -1699,7 +1699,8 @@ static int au1200fb_drv_probe(struct pla if (!fbdev->fb_mem) { print_err("fail to allocate frambuffer (size: %dK))", fbdev->fb_len / 1024); - return -ENOMEM; + ret = -ENOMEM; + goto failed; } /* Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-4.4/video-fbdev-au1200fb-release-some-resources-if-a-memory-allocation-fails.patch queue-4.4/video-fbdev-au1200fb-return-an-error-code-if-a-memory-allocation-fails.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "userfaultfd: shmem: __do_fault requires VM_FAULT_NOPAGE" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled userfaultfd: shmem: __do_fault requires VM_FAULT_NOPAGE to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: userfaultfd-shmem-__do_fault-requires-vm_fault_nopage.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Andrea Arcangeli <aarcange(a)redhat.com> Date: Thu, 9 Mar 2017 16:16:28 -0800 Subject: userfaultfd: shmem: __do_fault requires VM_FAULT_NOPAGE From: Andrea Arcangeli <aarcange(a)redhat.com> [ Upstream commit 6bbc4a4144b1a69743022ac68dfaf6e7d993abb9 ] __do_fault assumes vmf->page has been initialized and is valid if VM_FAULT_NOPAGE is not returned by vma->vm_ops->fault(vma, vmf). handle_userfault() in turn should return VM_FAULT_NOPAGE if it doesn't return VM_FAULT_SIGBUS or VM_FAULT_RETRY (the other two possibilities). This VM_FAULT_NOPAGE case is only invoked when signal are pending and it didn't matter for anonymous memory before. It only started to matter since shmem was introduced. hugetlbfs also takes a different path and doesn't exercise __do_fault. Link: http://lkml.kernel.org/r/20170228154201.GH5816@redhat.com Signed-off-by: Andrea Arcangeli <aarcange(a)redhat.com> Reported-by: Dmitry Vyukov <dvyukov(a)google.com> Cc: "Kirill A. Shutemov" <kirill(a)shutemov.name> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/userfaultfd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/userfaultfd.c +++ b/fs/userfaultfd.c @@ -386,7 +386,7 @@ int handle_userfault(struct vm_area_stru * in such case. */ down_read(&mm->mmap_sem); - ret = 0; + ret = VM_FAULT_NOPAGE; } } Patches currently in stable-queue which might be from aarcange(a)redhat.com are queue-4.4/userfaultfd-selftest-vm-allow-to-build-in-vm-directory.patch queue-4.4/userfaultfd-shmem-__do_fault-requires-vm_fault_nopage.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "userfaultfd: selftest: vm: allow to build in vm/ directory" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled userfaultfd: selftest: vm: allow to build in vm/ directory to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: userfaultfd-selftest-vm-allow-to-build-in-vm-directory.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Andrea Arcangeli <aarcange(a)redhat.com> Date: Thu, 9 Mar 2017 16:17:14 -0800 Subject: userfaultfd: selftest: vm: allow to build in vm/ directory From: Andrea Arcangeli <aarcange(a)redhat.com> [ Upstream commit 46aa6a302b53f543f8e8b8e1714dc5e449ad36a6 ] linux/tools/testing/selftests/vm $ make gcc -Wall -I ../../../../usr/include compaction_test.c -lrt -o /compaction_test /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/../../../../x86_64-pc-linux-gnu/bin/ld: cannot open output file /compaction_test: Permission denied collect2: error: ld returned 1 exit status make: *** [../lib.mk:54: /compaction_test] Error 1 Since commit a8ba798bc8ec ("selftests: enable O and KBUILD_OUTPUT") selftests/vm build fails if run from the "selftests/vm" directory, but it works in the selftests/ directory. It's quicker to be able to do a local vm-only build after a tree wipe and this patch allows for it again. Link: http://lkml.kernel.org/r/20170302173738.18994-4-aarcange@redhat.com Signed-off-by: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Mike Rapoport <rppt(a)linux.vnet.ibm.com> Cc: "Dr. David Alan Gilbert" <dgilbert(a)redhat.com> Cc: Mike Kravetz <mike.kravetz(a)oracle.com> Cc: Pavel Emelyanov <xemul(a)parallels.com> Cc: Hillf Danton <hillf.zj(a)alibaba-inc.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/vm/Makefile | 4 ++++ 1 file changed, 4 insertions(+) --- a/tools/testing/selftests/vm/Makefile +++ b/tools/testing/selftests/vm/Makefile @@ -1,5 +1,9 @@ # Makefile for vm selftests +ifndef OUTPUT + OUTPUT := $(shell pwd) +endif + CFLAGS = -Wall -I ../../../../usr/include $(EXTRA_CFLAGS) BINARIES = compaction_test BINARIES += hugepage-mmap Patches currently in stable-queue which might be from aarcange(a)redhat.com are queue-4.4/userfaultfd-selftest-vm-allow-to-build-in-vm-directory.patch queue-4.4/userfaultfd-shmem-__do_fault-requires-vm_fault_nopage.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: phy: isp1301: Add OF device ID table" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: phy: isp1301: Add OF device ID table to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-phy-isp1301-add-of-device-id-table.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Javier Martinez Canillas <javier(a)osg.samsung.com> Date: Wed, 22 Feb 2017 15:23:22 -0300 Subject: usb: phy: isp1301: Add OF device ID table From: Javier Martinez Canillas <javier(a)osg.samsung.com> [ Upstream commit fd567653bdb908009b650f079bfd4b63169e2ac4 ] The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/phy/phy-isp1301.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/drivers/usb/phy/phy-isp1301.c +++ b/drivers/usb/phy/phy-isp1301.c @@ -33,6 +33,12 @@ static const struct i2c_device_id isp130 }; MODULE_DEVICE_TABLE(i2c, isp1301_id); +static const struct of_device_id isp1301_of_match[] = { + {.compatible = "nxp,isp1301" }, + { }, +}; +MODULE_DEVICE_TABLE(of, isp1301_of_match); + static struct i2c_client *isp1301_i2c_client; static int __isp1301_write(struct isp1301 *isp, u8 reg, u8 value, u8 clear) @@ -130,6 +136,7 @@ static int isp1301_remove(struct i2c_cli static struct i2c_driver isp1301_driver = { .driver = { .name = DRV_NAME, + .of_match_table = of_match_ptr(isp1301_of_match), }, .probe = isp1301_probe, .remove = isp1301_remove, Patches currently in stable-queue which might be from javier(a)osg.samsung.com are queue-4.4/usb-phy-isp1301-add-of-device-id-table.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "udf: Avoid overflow when session starts at large offset" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled udf: Avoid overflow when session starts at large offset to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: udf-avoid-overflow-when-session-starts-at-large-offset.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Jan Kara <jack(a)suse.cz> Date: Mon, 16 Oct 2017 11:38:11 +0200 Subject: udf: Avoid overflow when session starts at large offset From: Jan Kara <jack(a)suse.cz> [ Upstream commit abdc0eb06964fe1d2fea6dd1391b734d0590365d ] When session starts beyond offset 2^31 the arithmetics in udf_check_vsd() would overflow. Make sure the computation is done in large enough type. Reported-by: Cezary Sliwa <sliwa(a)ifpan.edu.pl> Signed-off-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/udf/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/udf/super.c +++ b/fs/udf/super.c @@ -705,7 +705,7 @@ static loff_t udf_check_vsd(struct super else sectorsize = sb->s_blocksize; - sector += (sbi->s_session << sb->s_blocksize_bits); + sector += (((loff_t)sbi->s_session) << sb->s_blocksize_bits); udf_debug("Starting at sector %u (%ld byte sectors)\n", (unsigned int)(sector >> sb->s_blocksize_bits), Patches currently in stable-queue which might be from jack(a)suse.cz are queue-4.4/writeback-fix-memory-leak-in-wb_queue_work.patch queue-4.4/mm-handle-0-flags-in-_calc_vm_trans-macro.patch queue-4.4/udf-avoid-overflow-when-session-starts-at-large-offset.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "tty fix oops when rmmod 8250" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tty fix oops when rmmod 8250 to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: tty-fix-oops-when-rmmod-8250.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: nixiaoming <nixiaoming(a)huawei.com> Date: Fri, 15 Sep 2017 17:45:56 +0800 Subject: tty fix oops when rmmod 8250 From: nixiaoming <nixiaoming(a)huawei.com> [ Upstream commit c79dde629d2027ca80329c62854a7635e623d527 ] After rmmod 8250.ko tty_kref_put starts kwork (release_one_tty) to release proc interface oops when accessing driver->driver_name in proc_tty_unregister_driver Use jprobe, found driver->driver_name point to 8250.ko static static struct uart_driver serial8250_reg .driver_name= serial, Use name in proc_dir_entry instead of driver->driver_name to fix oops test on linux 4.1.12: BUG: unable to handle kernel paging request at ffffffffa01979de IP: [<ffffffff81310f40>] strchr+0x0/0x30 PGD 1a0d067 PUD 1a0e063 PMD 851c1f067 PTE 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: ... ... [last unloaded: 8250] CPU: 7 PID: 116 Comm: kworker/7:1 Tainted: G O 4.1.12 #1 Hardware name: Insyde RiverForest/Type2 - Board Product Name1, BIOS NE5KV904 12/21/2015 Workqueue: events release_one_tty task: ffff88085b684960 ti: ffff880852884000 task.ti: ffff880852884000 RIP: 0010:[<ffffffff81310f40>] [<ffffffff81310f40>] strchr+0x0/0x30 RSP: 0018:ffff880852887c90 EFLAGS: 00010282 RAX: ffffffff81a5eca0 RBX: ffffffffa01979de RCX: 0000000000000004 RDX: ffff880852887d10 RSI: 000000000000002f RDI: ffffffffa01979de RBP: ffff880852887cd8 R08: 0000000000000000 R09: ffff88085f5d94d0 R10: 0000000000000195 R11: 0000000000000000 R12: ffffffffa01979de R13: ffff880852887d00 R14: ffffffffa01979de R15: ffff88085f02e840 FS: 0000000000000000(0000) GS:ffff88085f5c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffa01979de CR3: 0000000001a0c000 CR4: 00000000001406e0 Stack: ffffffff812349b1 ffff880852887cb8 ffff880852887d10 ffff88085f5cd6c2 ffff880852800a80 ffffffffa01979de ffff880852800a84 0000000000000010 ffff88085bb28bd8 ffff880852887d38 ffffffff812354f0 ffff880852887d08 Call Trace: [<ffffffff812349b1>] ? __xlate_proc_name+0x71/0xd0 [<ffffffff812354f0>] remove_proc_entry+0x40/0x180 [<ffffffff815f6811>] ? _raw_spin_lock_irqsave+0x41/0x60 [<ffffffff813be520>] ? destruct_tty_driver+0x60/0xe0 [<ffffffff81237c68>] proc_tty_unregister_driver+0x28/0x40 [<ffffffff813be548>] destruct_tty_driver+0x88/0xe0 [<ffffffff813be5bd>] tty_driver_kref_put+0x1d/0x20 [<ffffffff813becca>] release_one_tty+0x5a/0xd0 [<ffffffff81074159>] process_one_work+0x139/0x420 [<ffffffff810745a1>] worker_thread+0x121/0x450 [<ffffffff81074480>] ? process_scheduled_works+0x40/0x40 [<ffffffff8107a16c>] kthread+0xec/0x110 [<ffffffff81080000>] ? tg_rt_schedulable+0x210/0x220 [<ffffffff8107a080>] ? kthread_freezable_should_stop+0x80/0x80 [<ffffffff815f7292>] ret_from_fork+0x42/0x70 [<ffffffff8107a080>] ? kthread_freezable_should_stop+0x80/0x80 Signed-off-by: nixiaoming <nixiaoming(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/proc/proc_tty.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/proc/proc_tty.c +++ b/fs/proc/proc_tty.c @@ -14,6 +14,7 @@ #include <linux/tty.h> #include <linux/seq_file.h> #include <linux/bitops.h> +#include "internal.h" /* * The /proc/tty directory inodes... @@ -164,7 +165,7 @@ void proc_tty_unregister_driver(struct t if (!ent) return; - remove_proc_entry(driver->driver_name, proc_tty_driver); + remove_proc_entry(ent->name, proc_tty_driver); driver->proc_entry = NULL; } Patches currently in stable-queue which might be from nixiaoming(a)huawei.com are queue-4.4/tty-fix-oops-when-rmmod-8250.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "thermal/drivers/step_wise: Fix temperature regulation misbehavior" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled thermal/drivers/step_wise: Fix temperature regulation misbehavior to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: thermal-drivers-step_wise-fix-temperature-regulation-misbehavior.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Daniel Lezcano <daniel.lezcano(a)linaro.org> Date: Thu, 19 Oct 2017 19:05:58 +0200 Subject: thermal/drivers/step_wise: Fix temperature regulation misbehavior From: Daniel Lezcano <daniel.lezcano(a)linaro.org> [ Upstream commit 07209fcf33542c1ff1e29df2dbdf8f29cdaacb10 ] There is a particular situation when the cooling device is cpufreq and the heat dissipation is not efficient enough where the temperature increases little by little until reaching the critical threshold and leading to a SoC reset. The behavior is reproducible on a hikey6220 with bad heat dissipation (eg. stacked with other boards). Running a simple C program doing while(1); for each CPU of the SoC makes the temperature to reach the passive regulation trip point and ends up to the maximum allowed temperature followed by a reset. This issue has been also reported by running the libhugetlbfs test suite. What is observed is a ping pong between two cpu frequencies, 1.2GHz and 900MHz while the temperature continues to grow. It appears the step wise governor calls get_target_state() the first time with the throttle set to true and the trend to 'raising'. The code selects logically the next state, so the cpu frequency decreases from 1.2GHz to 900MHz, so far so good. The temperature decreases immediately but still stays greater than the trip point, then get_target_state() is called again, this time with the throttle set to true *and* the trend to 'dropping'. From there the algorithm assumes we have to step down the state and the cpu frequency jumps back to 1.2GHz. But the temperature is still higher than the trip point, so get_target_state() is called with throttle=1 and trend='raising' again, we jump to 900MHz, then get_target_state() is called with throttle=1 and trend='dropping', we jump to 1.2GHz, etc ... but the temperature does not stabilizes and continues to increase. [ 237.922654] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 237.922678] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1 [ 237.922690] thermal cooling_device0: cur_state=0 [ 237.922701] thermal cooling_device0: old_target=0, target=1 [ 238.026656] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1 [ 238.026680] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=1 [ 238.026694] thermal cooling_device0: cur_state=1 [ 238.026707] thermal cooling_device0: old_target=1, target=0 [ 238.134647] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 238.134667] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1 [ 238.134679] thermal cooling_device0: cur_state=0 [ 238.134690] thermal cooling_device0: old_target=0, target=1 In this situation the temperature continues to increase while the trend is oscillating between 'dropping' and 'raising'. We need to keep the current state untouched if the throttle is set, so the temperature can decrease or a higher state could be selected, thus preventing this oscillation. Keeping the next_target untouched when 'throttle' is true at 'dropping' time fixes the issue. The following traces show the governor does not change the next state if trend==2 (dropping) and throttle==1. [ 2306.127987] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 2306.128009] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1 [ 2306.128021] thermal cooling_device0: cur_state=0 [ 2306.128031] thermal cooling_device0: old_target=0, target=1 [ 2306.231991] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1 [ 2306.232016] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=1 [ 2306.232030] thermal cooling_device0: cur_state=1 [ 2306.232042] thermal cooling_device0: old_target=1, target=1 [ 2306.335982] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1 [ 2306.336006] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=1 [ 2306.336021] thermal cooling_device0: cur_state=1 [ 2306.336034] thermal cooling_device0: old_target=1, target=1 [ 2306.439984] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1 [ 2306.440008] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=0 [ 2306.440022] thermal cooling_device0: cur_state=1 [ 2306.440034] thermal cooling_device0: old_target=1, target=0 [ ... ] After a while, if the temperature continues to increase, the next state becomes 2 which is 720MHz on the hikey. That results in the temperature stabilizing around the trip point. [ 2455.831982] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 2455.832006] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=0 [ 2455.832019] thermal cooling_device0: cur_state=1 [ 2455.832032] thermal cooling_device0: old_target=1, target=1 [ 2455.935985] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1 [ 2455.936013] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=0 [ 2455.936027] thermal cooling_device0: cur_state=1 [ 2455.936040] thermal cooling_device0: old_target=1, target=1 [ 2456.043984] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1 [ 2456.044009] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=0 [ 2456.044023] thermal cooling_device0: cur_state=1 [ 2456.044036] thermal cooling_device0: old_target=1, target=1 [ 2456.148001] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 2456.148028] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1 [ 2456.148042] thermal cooling_device0: cur_state=1 [ 2456.148055] thermal cooling_device0: old_target=1, target=2 [ 2456.252009] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1 [ 2456.252041] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=0 [ 2456.252058] thermal cooling_device0: cur_state=2 [ 2456.252075] thermal cooling_device0: old_target=2, target=1 IOW, this change is needed to keep the state for a cooling device if the temperature trend is oscillating while the temperature increases slightly. Without this change, the situation above leads to a catastrophic crash by a hardware reset on hikey. This issue has been reported to happen on an OMAP dra7xx also. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> Cc: Keerthy <j-keerthy(a)ti.com> Cc: John Stultz <john.stultz(a)linaro.org> Cc: Leo Yan <leo.yan(a)linaro.org> Tested-by: Keerthy <j-keerthy(a)ti.com> Reviewed-by: Keerthy <j-keerthy(a)ti.com> Signed-off-by: Eduardo Valentin <edubezval(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/thermal/step_wise.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) --- a/drivers/thermal/step_wise.c +++ b/drivers/thermal/step_wise.c @@ -31,8 +31,7 @@ * If the temperature is higher than a trip point, * a. if the trend is THERMAL_TREND_RAISING, use higher cooling * state for this trip point - * b. if the trend is THERMAL_TREND_DROPPING, use lower cooling - * state for this trip point + * b. if the trend is THERMAL_TREND_DROPPING, do nothing * c. if the trend is THERMAL_TREND_RAISE_FULL, use upper limit * for this trip point * d. if the trend is THERMAL_TREND_DROP_FULL, use lower limit @@ -94,9 +93,11 @@ static unsigned long get_target_state(st if (!throttle) next_target = THERMAL_NO_TARGET; } else { - next_target = cur_state - 1; - if (next_target > instance->upper) - next_target = instance->upper; + if (!throttle) { + next_target = cur_state - 1; + if (next_target > instance->upper) + next_target = instance->upper; + } } break; case THERMAL_TREND_DROP_FULL: Patches currently in stable-queue which might be from daniel.lezcano(a)linaro.org are queue-4.4/thermal-drivers-step_wise-fix-temperature-regulation-misbehavior.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "target: Use system workqueue for ALUA transitions" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled target: Use system workqueue for ALUA transitions to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: target-use-system-workqueue-for-alua-transitions.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Mike Christie <mchristi(a)redhat.com> Date: Wed, 1 Mar 2017 23:13:26 -0600 Subject: target: Use system workqueue for ALUA transitions From: Mike Christie <mchristi(a)redhat.com> [ Upstream commit 207ee84133c00a8a2a5bdec94df4a5b37d78881c ] If tcmu-runner is processing a STPG and needs to change the kernel's ALUA state then we cannot use the same work queue for task management requests and ALUA transitions, because we could deadlock. The problem occurs when a STPG times out before tcmu-runner is able to call into target_tg_pt_gp_alua_access_state_store-> core_alua_do_port_transition -> core_alua_do_transition_tg_pt -> queue_work. In this case, the tmr is on the work queue waiting for the STPG to complete, but the STPG transition is now queued behind the waiting tmr. Note: This bug will also be fixed by this patch: http://www.spinics.net/lists/target-devel/msg14560.html which switches the tmr code to use the system workqueues. For both, I am not sure if we need a dedicated workqueue since it is not a performance path and I do not think we need WQ_MEM_RECLAIM to make forward progress to free up memory like the block layer does. 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)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/target_core_alua.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) --- a/drivers/target/target_core_alua.c +++ b/drivers/target/target_core_alua.c @@ -1118,13 +1118,11 @@ static int core_alua_do_transition_tg_pt unsigned long transition_tmo; transition_tmo = tg_pt_gp->tg_pt_gp_implicit_trans_secs * HZ; - queue_delayed_work(tg_pt_gp->tg_pt_gp_dev->tmr_wq, - &tg_pt_gp->tg_pt_gp_transition_work, - transition_tmo); + schedule_delayed_work(&tg_pt_gp->tg_pt_gp_transition_work, + transition_tmo); } else { tg_pt_gp->tg_pt_gp_transition_complete = &wait; - queue_delayed_work(tg_pt_gp->tg_pt_gp_dev->tmr_wq, - &tg_pt_gp->tg_pt_gp_transition_work, 0); + schedule_delayed_work(&tg_pt_gp->tg_pt_gp_transition_work, 0); wait_for_completion(&wait); tg_pt_gp->tg_pt_gp_transition_complete = NULL; } Patches currently in stable-queue which might be from mchristi(a)redhat.com are queue-4.4/target-use-system-workqueue-for-alua-transitions.patch queue-4.4/target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch queue-4.4/target-fix-alua-transition-timeout-handling.patch queue-4.4/target-fix-race-during-implicit-transition-work-flushes.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "target/iscsi: Fix a race condition in iscsit_add_reject_from_cmd()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled target/iscsi: Fix a race condition in iscsit_add_reject_from_cmd() to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Bart Van Assche <bart.vanassche(a)wdc.com> Date: Tue, 31 Oct 2017 11:03:17 -0700 Subject: target/iscsi: Fix a race condition in iscsit_add_reject_from_cmd() From: Bart Van Assche <bart.vanassche(a)wdc.com> [ Upstream commit cfe2b621bb18d86e93271febf8c6e37622da2d14 ] Avoid that cmd->se_cmd.se_tfo is read after a command has already been freed. Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Mike Christie <mchristi(a)redhat.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/iscsi/iscsi_target.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/target/iscsi/iscsi_target.c +++ b/drivers/target/iscsi/iscsi_target.c @@ -674,6 +674,7 @@ static int iscsit_add_reject_from_cmd( unsigned char *buf) { struct iscsi_conn *conn; + const bool do_put = cmd->se_cmd.se_tfo != NULL; if (!cmd->conn) { pr_err("cmd->conn is NULL for ITT: 0x%08x\n", @@ -704,7 +705,7 @@ static int iscsit_add_reject_from_cmd( * Perform the kref_put now if se_cmd has already been setup by * scsit_setup_scsi_cmd() */ - if (cmd->se_cmd.se_tfo != NULL) { + if (do_put) { pr_debug("iscsi reject: calling target_put_sess_cmd >>>>>>\n"); target_put_sess_cmd(&cmd->se_cmd); } Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are queue-4.4/target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch queue-4.4/rdma-cma-avoid-triggering-undefined-behavior.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "target: fix race during implicit transition work flushes" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled target: fix race during implicit transition work flushes to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: target-fix-race-during-implicit-transition-work-flushes.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Mike Christie <mchristi(a)redhat.com> Date: Thu, 2 Mar 2017 04:59:50 -0600 Subject: target: fix race during implicit transition work flushes From: Mike Christie <mchristi(a)redhat.com> [ Upstream commit 760bf578edf8122f2503a3a6a3f4b0de3b6ce0bb ] This fixes the following races: 1. core_alua_do_transition_tg_pt could have read tg_pt_gp_alua_access_state and gone into this if chunk: if (!explicit && atomic_read(&tg_pt_gp->tg_pt_gp_alua_access_state) == ALUA_ACCESS_STATE_TRANSITION) { and then core_alua_do_transition_tg_pt_work could update the state. core_alua_do_transition_tg_pt would then only set tg_pt_gp_alua_pending_state and the tg_pt_gp_alua_access_state would not get updated with the second calls state. 2. core_alua_do_transition_tg_pt could be setting tg_pt_gp_transition_complete while the tg_pt_gp_transition_work is already completing. core_alua_do_transition_tg_pt then waits on the completion that will never be called. To handle these issues, we just call flush_work which will return when core_alua_do_transition_tg_pt_work has completed so there is no need to do the complete/wait. And, if core_alua_do_transition_tg_pt_work was running, instead of trying to sneak in the state change, we just schedule up another core_alua_do_transition_tg_pt_work call. Note that this does not handle a possible race where there are multiple threads call core_alua_do_transition_tg_pt at the same time. I think we need a mutex in target_tg_pt_gp_alua_access_state_store. 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)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/target_core_alua.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) --- a/drivers/target/target_core_alua.c +++ b/drivers/target/target_core_alua.c @@ -1073,16 +1073,8 @@ static int core_alua_do_transition_tg_pt /* * Flush any pending transitions */ - if (!explicit && atomic_read(&tg_pt_gp->tg_pt_gp_alua_access_state) == - ALUA_ACCESS_STATE_TRANSITION) { - /* Just in case */ - tg_pt_gp->tg_pt_gp_alua_pending_state = new_state; - tg_pt_gp->tg_pt_gp_transition_complete = &wait; + if (!explicit) flush_work(&tg_pt_gp->tg_pt_gp_transition_work); - wait_for_completion(&wait); - tg_pt_gp->tg_pt_gp_transition_complete = NULL; - return 0; - } /* * Save the old primary ALUA access state, and set the current state Patches currently in stable-queue which might be from mchristi(a)redhat.com are queue-4.4/target-use-system-workqueue-for-alua-transitions.patch queue-4.4/target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch queue-4.4/target-fix-alua-transition-timeout-handling.patch queue-4.4/target-fix-race-during-implicit-transition-work-flushes.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "target:fix condition return in core_pr_dump_initiator_port()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled target:fix condition return in core_pr_dump_initiator_port() to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: target-fix-condition-return-in-core_pr_dump_initiator_port.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: tangwenji <tang.wenji(a)zte.com.cn> Date: Thu, 24 Aug 2017 19:59:37 +0800 Subject: target:fix condition return in core_pr_dump_initiator_port() From: tangwenji <tang.wenji(a)zte.com.cn> [ Upstream commit 24528f089d0a444070aa4f715ace537e8d6bf168 ] When is pr_reg->isid_present_at_reg is false,this function should return. This fixes a regression originally introduced by: commit d2843c173ee53cf4c12e7dfedc069a5bc76f0ac5 Author: Andy Grover <agrover(a)redhat.com> Date: Thu May 16 10:40:55 2013 -0700 target: Alter core_pr_dump_initiator_port for ease of use Signed-off-by: tangwenji <tang.wenji(a)zte.com.cn> Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/target_core_pr.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/target/target_core_pr.c +++ b/drivers/target/target_core_pr.c @@ -56,8 +56,10 @@ void core_pr_dump_initiator_port( char *buf, u32 size) { - if (!pr_reg->isid_present_at_reg) + if (!pr_reg->isid_present_at_reg) { buf[0] = '\0'; + return; + } snprintf(buf, size, ",i,0x%s", pr_reg->pr_reg_isid); } Patches currently in stable-queue which might be from tang.wenji(a)zte.com.cn are queue-4.4/target-fix-condition-return-in-core_pr_dump_initiator_port.patch queue-4.4/iscsi-target-fix-memory-leak-in-lio_target_tiqn_addtpg.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "target: fix ALUA transition timeout handling" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled target: fix ALUA transition timeout handling to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: target-fix-alua-transition-timeout-handling.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Mike Christie <mchristi(a)redhat.com> Date: Thu, 2 Mar 2017 04:59:48 -0600 Subject: target: fix ALUA transition timeout handling From: Mike Christie <mchristi(a)redhat.com> [ Upstream commit d7175373f2745ed4abe5b388d5aabd06304f801e ] The implicit transition time tells initiators the min time to wait before timing out a transition. We currently schedule the transition to occur in tg_pt_gp_implicit_trans_secs seconds so there is no room for delays. If core_alua_do_transition_tg_pt_work->core_alua_update_tpg_primary_metadata needs to write out info to a remote file, then the initiator can easily time out the operation. 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)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/target_core_alua.c | 23 ++++++++--------------- include/target/target_core_base.h | 2 +- 2 files changed, 9 insertions(+), 16 deletions(-) --- a/drivers/target/target_core_alua.c +++ b/drivers/target/target_core_alua.c @@ -1010,7 +1010,7 @@ static void core_alua_queue_state_change static void core_alua_do_transition_tg_pt_work(struct work_struct *work) { struct t10_alua_tg_pt_gp *tg_pt_gp = container_of(work, - struct t10_alua_tg_pt_gp, tg_pt_gp_transition_work.work); + struct t10_alua_tg_pt_gp, tg_pt_gp_transition_work); struct se_device *dev = tg_pt_gp->tg_pt_gp_dev; bool explicit = (tg_pt_gp->tg_pt_gp_alua_access_status == ALUA_STATUS_ALTERED_BY_EXPLICIT_STPG); @@ -1073,13 +1073,12 @@ static int core_alua_do_transition_tg_pt /* * Flush any pending transitions */ - if (!explicit && tg_pt_gp->tg_pt_gp_implicit_trans_secs && - atomic_read(&tg_pt_gp->tg_pt_gp_alua_access_state) == + if (!explicit && atomic_read(&tg_pt_gp->tg_pt_gp_alua_access_state) == ALUA_ACCESS_STATE_TRANSITION) { /* Just in case */ tg_pt_gp->tg_pt_gp_alua_pending_state = new_state; tg_pt_gp->tg_pt_gp_transition_complete = &wait; - flush_delayed_work(&tg_pt_gp->tg_pt_gp_transition_work); + flush_work(&tg_pt_gp->tg_pt_gp_transition_work); wait_for_completion(&wait); tg_pt_gp->tg_pt_gp_transition_complete = NULL; return 0; @@ -1114,15 +1113,9 @@ static int core_alua_do_transition_tg_pt atomic_inc(&tg_pt_gp->tg_pt_gp_ref_cnt); spin_unlock(&dev->t10_alua.tg_pt_gps_lock); - if (!explicit && tg_pt_gp->tg_pt_gp_implicit_trans_secs) { - unsigned long transition_tmo; - - transition_tmo = tg_pt_gp->tg_pt_gp_implicit_trans_secs * HZ; - schedule_delayed_work(&tg_pt_gp->tg_pt_gp_transition_work, - transition_tmo); - } else { + schedule_work(&tg_pt_gp->tg_pt_gp_transition_work); + if (explicit) { tg_pt_gp->tg_pt_gp_transition_complete = &wait; - schedule_delayed_work(&tg_pt_gp->tg_pt_gp_transition_work, 0); wait_for_completion(&wait); tg_pt_gp->tg_pt_gp_transition_complete = NULL; } @@ -1690,8 +1683,8 @@ struct t10_alua_tg_pt_gp *core_alua_allo mutex_init(&tg_pt_gp->tg_pt_gp_md_mutex); spin_lock_init(&tg_pt_gp->tg_pt_gp_lock); atomic_set(&tg_pt_gp->tg_pt_gp_ref_cnt, 0); - INIT_DELAYED_WORK(&tg_pt_gp->tg_pt_gp_transition_work, - core_alua_do_transition_tg_pt_work); + INIT_WORK(&tg_pt_gp->tg_pt_gp_transition_work, + core_alua_do_transition_tg_pt_work); tg_pt_gp->tg_pt_gp_dev = dev; atomic_set(&tg_pt_gp->tg_pt_gp_alua_access_state, ALUA_ACCESS_STATE_ACTIVE_OPTIMIZED); @@ -1799,7 +1792,7 @@ void core_alua_free_tg_pt_gp( dev->t10_alua.alua_tg_pt_gps_counter--; spin_unlock(&dev->t10_alua.tg_pt_gps_lock); - flush_delayed_work(&tg_pt_gp->tg_pt_gp_transition_work); + flush_work(&tg_pt_gp->tg_pt_gp_transition_work); /* * Allow a struct t10_alua_tg_pt_gp_member * referenced by --- a/include/target/target_core_base.h +++ b/include/target/target_core_base.h @@ -299,7 +299,7 @@ struct t10_alua_tg_pt_gp { struct list_head tg_pt_gp_lun_list; struct se_lun *tg_pt_gp_alua_lun; struct se_node_acl *tg_pt_gp_alua_nacl; - struct delayed_work tg_pt_gp_transition_work; + struct work_struct tg_pt_gp_transition_work; struct completion *tg_pt_gp_transition_complete; }; Patches currently in stable-queue which might be from mchristi(a)redhat.com are queue-4.4/target-use-system-workqueue-for-alua-transitions.patch queue-4.4/target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch queue-4.4/target-fix-alua-transition-timeout-handling.patch queue-4.4/target-fix-race-during-implicit-transition-work-flushes.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "target/file: Do not return error for UNMAP if length is zero" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled target/file: Do not return error for UNMAP if length is zero to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: target-file-do-not-return-error-for-unmap-if-length-is-zero.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Jiang Yi <jiangyilism(a)gmail.com> Date: Fri, 11 Aug 2017 11:29:44 +0800 Subject: target/file: Do not return error for UNMAP if length is zero From: Jiang Yi <jiangyilism(a)gmail.com> [ Upstream commit 594e25e73440863981032d76c9b1e33409ceff6e ] The function fd_execute_unmap() in target_core_file.c calles ret = file->f_op->fallocate(file, mode, pos, len); Some filesystems implement fallocate() to return error if length is zero (e.g. btrfs) but according to SCSI Block Commands spec UNMAP should return success for zero length. Signed-off-by: Jiang Yi <jiangyilism(a)gmail.com> Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/target_core_file.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/target/target_core_file.c +++ b/drivers/target/target_core_file.c @@ -466,6 +466,10 @@ fd_execute_unmap(struct se_cmd *cmd, sec struct inode *inode = file->f_mapping->host; int ret; + if (!nolb) { + return 0; + } + if (cmd->se_dev->dev_attrib.pi_prot_type) { ret = fd_do_prot_unmap(cmd, lba, nolb); if (ret) Patches currently in stable-queue which might be from jiangyilism(a)gmail.com are queue-4.4/target-file-do-not-return-error-for-unmap-if-length-is-zero.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "sfc: don't warn on successful change of MAC" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sfc: don't warn on successful change of MAC to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sfc-don-t-warn-on-successful-change-of-mac.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Robert Stonehouse <rstonehouse(a)solarflare.com> Date: Tue, 7 Nov 2017 17:30:30 +0000 Subject: sfc: don't warn on successful change of MAC From: Robert Stonehouse <rstonehouse(a)solarflare.com> [ Upstream commit cbad52e92ad7f01f0be4ca58bde59462dc1afe3a ] Fixes: 535a61777f44e ("sfc: suppress handled MCDI failures when changing the MAC address") Signed-off-by: Bert Kenward <bkenward(a)solarflare.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/sfc/ef10.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/sfc/ef10.c +++ b/drivers/net/ethernet/sfc/ef10.c @@ -4307,7 +4307,7 @@ static int efx_ef10_set_mac_address(stru * MCFW do not support VFs. */ rc = efx_ef10_vport_set_mac_address(efx); - } else { + } else if (rc) { efx_mcdi_display_error(efx, MC_CMD_VADAPTOR_SET_MAC, sizeof(inbuf), NULL, 0, rc); } Patches currently in stable-queue which might be from rstonehouse(a)solarflare.com are queue-4.4/sfc-don-t-warn-on-successful-change-of-mac.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "scsi: sd: change manage_start_stop to bool in sysfs interface" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: sd: change manage_start_stop to bool in sysfs interface to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-sd-change-manage_start_stop-to-bool-in-sysfs-interface.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: weiping zhang <zhangweiping(a)didichuxing.com> Date: Thu, 12 Oct 2017 14:57:06 +0800 Subject: scsi: sd: change manage_start_stop to bool in sysfs interface From: weiping zhang <zhangweiping(a)didichuxing.com> [ Upstream commit 623401ee33e42cee64d333877892be8db02951eb ] /sys/class/scsi_disk/0:2:0:0/manage_start_stop can be changed to 0 unexpectly by writing an invalid string. Signed-off-by: weiping zhang <zhangweiping(a)didichuxing.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/sd.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -233,11 +233,15 @@ manage_start_stop_store(struct device *d { struct scsi_disk *sdkp = to_scsi_disk(dev); struct scsi_device *sdp = sdkp->device; + bool v; if (!capable(CAP_SYS_ADMIN)) return -EACCES; - sdp->manage_start_stop = simple_strtoul(buf, NULL, 10); + if (kstrtobool(buf, &v)) + return -EINVAL; + + sdp->manage_start_stop = v; return count; } Patches currently in stable-queue which might be from zhangweiping(a)didichuxing.com are queue-4.4/scsi-sd-change-allow_restart-to-bool-in-sysfs-interface.patch queue-4.4/scsi-sd-change-manage_start_stop-to-bool-in-sysfs-interface.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "scsi: sd: change allow_restart to bool in sysfs interface" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: sd: change allow_restart to bool in sysfs interface to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-sd-change-allow_restart-to-bool-in-sysfs-interface.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: weiping zhang <zhangweiping(a)didichuxing.com> Date: Thu, 12 Oct 2017 14:56:44 +0800 Subject: scsi: sd: change allow_restart to bool in sysfs interface From: weiping zhang <zhangweiping(a)didichuxing.com> [ Upstream commit 658e9a6dc1126f21fa417cd213e1cdbff8be0ba2 ] /sys/class/scsi_disk/0:2:0:0/allow_restart can be changed to 0 unexpectedly by writing an invalid string such as the following: echo asdf > /sys/class/scsi_disk/0:2:0:0/allow_restart Signed-off-by: weiping zhang <zhangweiping(a)didichuxing.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/sd.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -259,6 +259,7 @@ static ssize_t allow_restart_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count) { + bool v; struct scsi_disk *sdkp = to_scsi_disk(dev); struct scsi_device *sdp = sdkp->device; @@ -268,7 +269,10 @@ allow_restart_store(struct device *dev, if (sdp->type != TYPE_DISK) return -EINVAL; - sdp->allow_restart = simple_strtoul(buf, NULL, 10); + if (kstrtobool(buf, &v)) + return -EINVAL; + + sdp->allow_restart = v; return count; } Patches currently in stable-queue which might be from zhangweiping(a)didichuxing.com are queue-4.4/scsi-sd-change-allow_restart-to-bool-in-sysfs-interface.patch queue-4.4/scsi-sd-change-manage_start_stop-to-bool-in-sysfs-interface.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "scsi: scsi_devinfo: Add REPORTLUN2 to EMC SYMMETRIX blacklist entry" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: scsi_devinfo: Add REPORTLUN2 to EMC SYMMETRIX blacklist entry to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-scsi_devinfo-add-reportlun2-to-emc-symmetrix-blacklist-entry.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Kurt Garloff <garloff(a)suse.de> Date: Tue, 17 Oct 2017 09:10:45 +0200 Subject: scsi: scsi_devinfo: Add REPORTLUN2 to EMC SYMMETRIX blacklist entry From: Kurt Garloff <garloff(a)suse.de> [ Upstream commit 909cf3e16a5274fe2127cf3cea5c8dba77b2c412 ] All EMC SYMMETRIX support REPORT_LUNS, even if configured to report SCSI-2 for whatever reason. Signed-off-by: Kurt Garloff <garloff(a)suse.de> Signed-off-by: Hannes Reinecke <hare(a)suse.de> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/scsi_devinfo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/scsi/scsi_devinfo.c +++ b/drivers/scsi/scsi_devinfo.c @@ -160,7 +160,7 @@ static struct { {"DGC", "RAID", NULL, BLIST_SPARSELUN}, /* Dell PV 650F, storage on LUN 0 */ {"DGC", "DISK", NULL, BLIST_SPARSELUN}, /* Dell PV 650F, no storage on LUN 0 */ {"EMC", "Invista", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, - {"EMC", "SYMMETRIX", NULL, BLIST_SPARSELUN | BLIST_LARGELUN | BLIST_FORCELUN}, + {"EMC", "SYMMETRIX", NULL, BLIST_SPARSELUN | BLIST_LARGELUN | BLIST_REPORTLUN2}, {"EMULEX", "MD21/S2 ESDI", NULL, BLIST_SINGLELUN}, {"easyRAID", "16P", NULL, BLIST_NOREPORTLUN}, {"easyRAID", "X6P", NULL, BLIST_NOREPORTLUN}, Patches currently in stable-queue which might be from garloff(a)suse.de are queue-4.4/scsi-scsi_devinfo-add-reportlun2-to-emc-symmetrix-blacklist-entry.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "scsi: hpsa: update check for logical volume status" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: hpsa: update check for logical volume status to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-hpsa-update-check-for-logical-volume-status.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Don Brace <don.brace(a)microsemi.com> Date: Fri, 10 Mar 2017 14:35:11 -0600 Subject: scsi: hpsa: update check for logical volume status From: Don Brace <don.brace(a)microsemi.com> [ Upstream commit 85b29008d8af6d94a0723aaa8d93cfb6e041158b ] - Add in a new case for volume offline. Resolves internal testing bug for multilun array management. - Return correct status for failed TURs. Reviewed-by: Scott Benesh <scott.benesh(a)microsemi.com> Reviewed-by: Scott Teel <scott.teel(a)microsemi.com> Signed-off-by: Don Brace <don.brace(a)microsemi.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/hpsa.c | 35 ++++++++++++++++------------------- drivers/scsi/hpsa_cmd.h | 2 ++ 2 files changed, 18 insertions(+), 19 deletions(-) --- a/drivers/scsi/hpsa.c +++ b/drivers/scsi/hpsa.c @@ -3466,7 +3466,7 @@ exit_failed: * # (integer code indicating one of several NOT READY states * describing why a volume is to be kept offline) */ -static int hpsa_volume_offline(struct ctlr_info *h, +static unsigned char hpsa_volume_offline(struct ctlr_info *h, unsigned char scsi3addr[]) { struct CommandList *c; @@ -3486,7 +3486,7 @@ static int hpsa_volume_offline(struct ct rc = hpsa_scsi_do_simple_cmd(h, c, DEFAULT_REPLY_QUEUE, NO_TIMEOUT); if (rc) { cmd_free(h, c); - return 0; + return HPSA_VPD_LV_STATUS_UNSUPPORTED; } sense = c->err_info->SenseInfo; if (c->err_info->SenseLen > sizeof(c->err_info->SenseInfo)) @@ -3497,19 +3497,13 @@ static int hpsa_volume_offline(struct ct cmd_status = c->err_info->CommandStatus; scsi_status = c->err_info->ScsiStatus; cmd_free(h, c); - /* Is the volume 'not ready'? */ - if (cmd_status != CMD_TARGET_STATUS || - scsi_status != SAM_STAT_CHECK_CONDITION || - sense_key != NOT_READY || - asc != ASC_LUN_NOT_READY) { - return 0; - } /* Determine the reason for not ready state */ ldstat = hpsa_get_volume_status(h, scsi3addr); /* Keep volume offline in certain cases: */ switch (ldstat) { + case HPSA_LV_FAILED: case HPSA_LV_UNDERGOING_ERASE: case HPSA_LV_NOT_AVAILABLE: case HPSA_LV_UNDERGOING_RPI: @@ -3531,7 +3525,7 @@ static int hpsa_volume_offline(struct ct default: break; } - return 0; + return HPSA_LV_OK; } /* @@ -3615,10 +3609,10 @@ static int hpsa_update_device_info(struc /* Do an inquiry to the device to see what it is. */ if (hpsa_scsi_do_inquiry(h, scsi3addr, 0, inq_buff, (unsigned char) OBDR_TAPE_INQ_SIZE) != 0) { - /* Inquiry failed (msg printed already) */ dev_err(&h->pdev->dev, - "hpsa_update_device_info: inquiry failed\n"); - rc = -EIO; + "%s: inquiry failed, device will be skipped.\n", + __func__); + rc = HPSA_INQUIRY_FAILED; goto bail_out; } @@ -3638,15 +3632,19 @@ static int hpsa_update_device_info(struc if (this_device->devtype == TYPE_DISK && is_logical_dev_addr_mode(scsi3addr)) { - int volume_offline; + unsigned char volume_offline; hpsa_get_raid_level(h, scsi3addr, &this_device->raid_level); if (h->fw_support & MISC_FW_RAID_OFFLOAD_BASIC) hpsa_get_ioaccel_status(h, scsi3addr, this_device); volume_offline = hpsa_volume_offline(h, scsi3addr); - if (volume_offline < 0 || volume_offline > 0xff) - volume_offline = HPSA_VPD_LV_STATUS_UNSUPPORTED; - this_device->volume_offline = volume_offline & 0xff; + if (volume_offline == HPSA_LV_FAILED) { + rc = HPSA_LV_FAILED; + dev_err(&h->pdev->dev, + "%s: LV failed, device will be skipped.\n", + __func__); + goto bail_out; + } } else { this_device->raid_level = RAID_UNKNOWN; this_device->offload_config = 0; @@ -4115,8 +4113,7 @@ static void hpsa_update_scsi_devices(str goto out; } if (rc) { - dev_warn(&h->pdev->dev, - "Inquiry failed, skipping device.\n"); + h->drv_req_rescan = 1; continue; } --- a/drivers/scsi/hpsa_cmd.h +++ b/drivers/scsi/hpsa_cmd.h @@ -155,6 +155,7 @@ #define CFGTBL_BusType_Fibre2G 0x00000200l /* VPD Inquiry types */ +#define HPSA_INQUIRY_FAILED 0x02 #define HPSA_VPD_SUPPORTED_PAGES 0x00 #define HPSA_VPD_LV_DEVICE_GEOMETRY 0xC1 #define HPSA_VPD_LV_IOACCEL_STATUS 0xC2 @@ -164,6 +165,7 @@ /* Logical volume states */ #define HPSA_VPD_LV_STATUS_UNSUPPORTED 0xff #define HPSA_LV_OK 0x0 +#define HPSA_LV_FAILED 0x01 #define HPSA_LV_NOT_AVAILABLE 0x0b #define HPSA_LV_UNDERGOING_ERASE 0x0F #define HPSA_LV_UNDERGOING_RPI 0x12 Patches currently in stable-queue which might be from don.brace(a)microsemi.com are queue-4.4/scsi-hpsa-limit-outstanding-rescans.patch queue-4.4/scsi-hpsa-cleanup-sas_phy-structures-in-sysfs-when-unloading.patch queue-4.4/scsi-hpsa-destroy-sas-transport-properties-before-scsi_host.patch queue-4.4/scsi-hpsa-update-check-for-logical-volume-status.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "scsi: hpsa: limit outstanding rescans" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: hpsa: limit outstanding rescans to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-hpsa-limit-outstanding-rescans.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Don Brace <don.brace(a)microsemi.com> Date: Fri, 10 Mar 2017 14:35:17 -0600 Subject: scsi: hpsa: limit outstanding rescans From: Don Brace <don.brace(a)microsemi.com> [ Upstream commit 87b9e6aa87d9411f1059aa245c0c79976bc557ac ] Avoid rescan storms. No need to queue another if one is pending. Reviewed-by: Scott Benesh <scott.benesh(a)microsemi.com> Reviewed-by: Scott Teel <scott.teel(a)microsemi.com> Reviewed-by: Tomas Henzl <thenzl(a)redhat.com> Signed-off-by: Don Brace <don.brace(a)microsemi.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/hpsa.c | 16 +++++++++++++++- drivers/scsi/hpsa.h | 1 + 2 files changed, 16 insertions(+), 1 deletion(-) --- a/drivers/scsi/hpsa.c +++ b/drivers/scsi/hpsa.c @@ -5254,7 +5254,7 @@ static void hpsa_scan_complete(struct ct spin_lock_irqsave(&h->scan_lock, flags); h->scan_finished = 1; - wake_up_all(&h->scan_wait_queue); + wake_up(&h->scan_wait_queue); spin_unlock_irqrestore(&h->scan_lock, flags); } @@ -5272,11 +5272,23 @@ static void hpsa_scan_start(struct Scsi_ if (unlikely(lockup_detected(h))) return hpsa_scan_complete(h); + /* + * If a scan is already waiting to run, no need to add another + */ + spin_lock_irqsave(&h->scan_lock, flags); + if (h->scan_waiting) { + spin_unlock_irqrestore(&h->scan_lock, flags); + return; + } + + spin_unlock_irqrestore(&h->scan_lock, flags); + /* wait until any scan already in progress is finished. */ while (1) { spin_lock_irqsave(&h->scan_lock, flags); if (h->scan_finished) break; + h->scan_waiting = 1; spin_unlock_irqrestore(&h->scan_lock, flags); wait_event(h->scan_wait_queue, h->scan_finished); /* Note: We don't need to worry about a race between this @@ -5286,6 +5298,7 @@ static void hpsa_scan_start(struct Scsi_ */ } h->scan_finished = 0; /* mark scan as in progress */ + h->scan_waiting = 0; spin_unlock_irqrestore(&h->scan_lock, flags); if (unlikely(lockup_detected(h))) @@ -8502,6 +8515,7 @@ reinit_after_soft_reset: init_waitqueue_head(&h->event_sync_wait_queue); mutex_init(&h->reset_mutex); h->scan_finished = 1; /* no scan currently in progress */ + h->scan_waiting = 0; pci_set_drvdata(pdev, h); h->ndevices = 0; --- a/drivers/scsi/hpsa.h +++ b/drivers/scsi/hpsa.h @@ -200,6 +200,7 @@ struct ctlr_info { dma_addr_t errinfo_pool_dhandle; unsigned long *cmd_pool_bits; int scan_finished; + u8 scan_waiting : 1; spinlock_t scan_lock; wait_queue_head_t scan_wait_queue; Patches currently in stable-queue which might be from don.brace(a)microsemi.com are queue-4.4/scsi-hpsa-limit-outstanding-rescans.patch queue-4.4/scsi-hpsa-cleanup-sas_phy-structures-in-sysfs-when-unloading.patch queue-4.4/scsi-hpsa-destroy-sas-transport-properties-before-scsi_host.patch queue-4.4/scsi-hpsa-update-check-for-logical-volume-status.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "scsi: hpsa: destroy sas transport properties before scsi_host" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: hpsa: destroy sas transport properties before scsi_host to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-hpsa-destroy-sas-transport-properties-before-scsi_host.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Martin Wilck <mwilck(a)suse.de> Date: Fri, 20 Oct 2017 16:51:08 -0500 Subject: scsi: hpsa: destroy sas transport properties before scsi_host From: Martin Wilck <mwilck(a)suse.de> [ Upstream commit dfb2e6f46b3074eb85203d8f0888b71ec1c2e37a ] This patch cleans up a lot of warnings when unloading the driver. A current example of the stack trace starts with: [ 142.570715] sysfs group 'power' not found for kobject 'port-5:0' There can be hundreds of these messages during a driver unload. I am resubmitting this patch on behalf of Martin Wilck with his permission. His original patch can be found here: https://www.spinics.net/lists/linux-scsi/msg102085.html This patch did not help until Hannes's commit 9441284fbc39 ("scsi-fixup-kernel-warning-during-rmmod") was applied to the kernel. --------------------------- Original patch description: --------------------------- Unloading the hpsa driver causes warnings [ 1063.793652] WARNING: CPU: 1 PID: 4850 at ../fs/sysfs/group.c:237 device_del+0x54/0x240() [ 1063.793659] sysfs group ffffffff81cf21a0 not found for kobject 'port-2:0' with two different stacks: 1) [ 1063.793774] [<ffffffff81448af4>] device_del+0x54/0x240 [ 1063.793780] [<ffffffff8145178a>] transport_remove_classdev+0x4a/0x60 [ 1063.793784] [<ffffffff81451216>] attribute_container_device_trigger+0xa6/0xb0 [ 1063.793802] [<ffffffffa0105d46>] sas_port_delete+0x126/0x160 [scsi_transport_sas] [ 1063.793819] [<ffffffffa036ebcc>] hpsa_free_sas_port+0x3c/0x70 [hpsa] 2) [ 1063.797103] [<ffffffff81448af4>] device_del+0x54/0x240 [ 1063.797118] [<ffffffffa0105d4e>] sas_port_delete+0x12e/0x160 [scsi_transport_sas] [ 1063.797134] [<ffffffffa036ebcc>] hpsa_free_sas_port+0x3c/0x70 [hpsa] This is caused by the fact that host device hostX is deleted before the SAS transport devices hostX/port-a:b. This patch fixes this by reverting the order of device deletions. Tested-by: Don Brace <don.brace(a)microsemi.com> Reviewed-by: Don Brace <don.brace(a)microsemi.com> Signed-off-by: Martin Wilck <mwilck(a)suse.de> Signed-off-by: Don Brace <don.brace(a)microsemi.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/hpsa.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/scsi/hpsa.c +++ b/drivers/scsi/hpsa.c @@ -8808,6 +8808,8 @@ static void hpsa_remove_one(struct pci_d destroy_workqueue(h->rescan_ctlr_wq); destroy_workqueue(h->resubmit_wq); + hpsa_delete_sas_host(h); + /* * Call before disabling interrupts. * scsi_remove_host can trigger I/O operations especially @@ -8842,8 +8844,6 @@ static void hpsa_remove_one(struct pci_d h->lockup_detected = NULL; /* init_one 2 */ /* (void) pci_disable_pcie_error_reporting(pdev); */ /* init_one 1 */ - hpsa_delete_sas_host(h); - kfree(h); /* init_one 1 */ } Patches currently in stable-queue which might be from mwilck(a)suse.de are queue-4.4/scsi-hpsa-cleanup-sas_phy-structures-in-sysfs-when-unloading.patch queue-4.4/scsi-hpsa-destroy-sas-transport-properties-before-scsi_host.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "scsi: hpsa: cleanup sas_phy structures in sysfs when unloading" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: hpsa: cleanup sas_phy structures in sysfs when unloading to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-hpsa-cleanup-sas_phy-structures-in-sysfs-when-unloading.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Martin Wilck <mwilck(a)suse.de> Date: Fri, 20 Oct 2017 16:51:14 -0500 Subject: scsi: hpsa: cleanup sas_phy structures in sysfs when unloading From: Martin Wilck <mwilck(a)suse.de> [ Upstream commit 55ca38b4255bb336c2d35990bdb2b368e19b435a ] I am resubmitting this patch on behalf of Martin Wilck with his permission. The original patch can be found here: https://www.spinics.net/lists/linux-scsi/msg102083.html This patch did not help until Hannes's commit 9441284fbc39 ("scsi-fixup-kernel-warning-during-rmmod") was applied to the kernel. -------------------------------------- Original patch description from Martin: -------------------------------------- When the hpsa module is unloaded using rmmod, dangling symlinks remain under /sys/class/sas_phy. Fix this by calling sas_phy_delete() rather than sas_phy_free (which, according to comments, should not be called for PHYs that have been set up successfully, anyway). Tested-by: Don Brace <don.brace(a)microsemi.com> Reviewed-by: Don Brace <don.brace(a)microsemi.com> Signed-off-by: Martin Wilck <mwilck(a)suse.de> Signed-off-by: Don Brace <don.brace(a)microsemi.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/hpsa.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/scsi/hpsa.c +++ b/drivers/scsi/hpsa.c @@ -9335,9 +9335,9 @@ static void hpsa_free_sas_phy(struct hps struct sas_phy *phy = hpsa_sas_phy->phy; sas_port_delete_phy(hpsa_sas_phy->parent_port->port, phy); - sas_phy_free(phy); if (hpsa_sas_phy->added_to_port) list_del(&hpsa_sas_phy->phy_list_entry); + sas_phy_delete(phy); kfree(hpsa_sas_phy); } Patches currently in stable-queue which might be from mwilck(a)suse.de are queue-4.4/scsi-hpsa-cleanup-sas_phy-structures-in-sysfs-when-unloading.patch queue-4.4/scsi-hpsa-destroy-sas-transport-properties-before-scsi_host.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "scsi: bfa: integer overflow in debugfs" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: bfa: integer overflow in debugfs to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-bfa-integer-overflow-in-debugfs.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Dan Carpenter <dan.carpenter(a)oracle.com> Date: Wed, 4 Oct 2017 10:50:37 +0300 Subject: scsi: bfa: integer overflow in debugfs From: Dan Carpenter <dan.carpenter(a)oracle.com> [ Upstream commit 3e351275655d3c84dc28abf170def9786db5176d ] We could allocate less memory than intended because we do: bfad->regdata = kzalloc(len << 2, GFP_KERNEL); The shift can overflow leading to a crash. This is debugfs code so the impact is very small. I fixed the network version of this in March with commit 13e2d5187f6b ("bna: integer overflow bug in debugfs"). Fixes: ab2a9ba189e8 ("[SCSI] bfa: add debugfs support") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/bfa/bfad_debugfs.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/drivers/scsi/bfa/bfad_debugfs.c +++ b/drivers/scsi/bfa/bfad_debugfs.c @@ -254,7 +254,8 @@ bfad_debugfs_write_regrd(struct file *fi struct bfad_s *bfad = port->bfad; struct bfa_s *bfa = &bfad->bfa; struct bfa_ioc_s *ioc = &bfa->ioc; - int addr, len, rc, i; + int addr, rc, i; + u32 len; u32 *regbuf; void __iomem *rb, *reg_addr; unsigned long flags; @@ -265,7 +266,7 @@ bfad_debugfs_write_regrd(struct file *fi return PTR_ERR(kern_buf); rc = sscanf(kern_buf, "%x:%x", &addr, &len); - if (rc < 2) { + if (rc < 2 || len > (UINT_MAX >> 2)) { printk(KERN_INFO "bfad[%d]: %s failed to read user buf\n", bfad->inst_no, __func__); Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are queue-4.4/scsi-bfa-integer-overflow-in-debugfs.patch queue-4.4/fbdev-controlfb-add-missing-modes-to-fix-out-of-bounds-access.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "sched/deadline: Use deadline instead of period when calculating overflow" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sched/deadline: Use deadline instead of period when calculating overflow to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sched-deadline-use-deadline-instead-of-period-when-calculating-overflow.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org> Date: Thu, 2 Mar 2017 15:10:59 +0100 Subject: sched/deadline: Use deadline instead of period when calculating overflow From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org> [ Upstream commit 2317d5f1c34913bac5971d93d69fb6c31bb74670 ] I was testing Daniel's changes with his test case, and tweaked it a little. Instead of having the runtime equal to the deadline, I increased the deadline ten fold. Daniel's test case had: attr.sched_runtime = 2 * 1000 * 1000; /* 2 ms */ attr.sched_deadline = 2 * 1000 * 1000; /* 2 ms */ attr.sched_period = 2 * 1000 * 1000 * 1000; /* 2 s */ To make it more interesting, I changed it to: attr.sched_runtime = 2 * 1000 * 1000; /* 2 ms */ attr.sched_deadline = 20 * 1000 * 1000; /* 20 ms */ attr.sched_period = 2 * 1000 * 1000 * 1000; /* 2 s */ The results were rather surprising. The behavior that Daniel's patch was fixing came back. The task started using much more than .1% of the CPU. More like 20%. Looking into this I found that it was due to the dl_entity_overflow() constantly returning true. That's because it uses the relative period against relative runtime vs the absolute deadline against absolute runtime. runtime / (deadline - t) > dl_runtime / dl_period There's even a comment mentioning this, and saying that when relative deadline equals relative period, that the equation is the same as using deadline instead of period. That comment is backwards! What we really want is: runtime / (deadline - t) > dl_runtime / dl_deadline We care about if the runtime can make its deadline, not its period. And then we can say "when the deadline equals the period, the equation is the same as using dl_period instead of dl_deadline". After correcting this, now when the task gets enqueued, it can throttle correctly, and Daniel's fix to the throttling of sleeping deadline tasks works even when the runtime and deadline are not the same. Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Reviewed-by: Daniel Bristot de Oliveira <bristot(a)redhat.com> Cc: Juri Lelli <juri.lelli(a)arm.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Luca Abeni <luca.abeni(a)santannapisa.it> Cc: Mike Galbraith <efault(a)gmx.de> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Romulo Silva de Oliveira <romulo.deoliveira(a)ufsc.br> Cc: Steven Rostedt <rostedt(a)goodmis.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Tommaso Cucinotta <tommaso.cucinotta(a)sssup.it> Link: http://lkml.kernel.org/r/02135a27f1ae3fe5fd032568a5a2f370e190e8d7.148839293… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/sched/deadline.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -441,13 +441,13 @@ static void replenish_dl_entity(struct s * * This function returns true if: * - * runtime / (deadline - t) > dl_runtime / dl_period , + * runtime / (deadline - t) > dl_runtime / dl_deadline , * * IOW we can't recycle current parameters. * - * Notice that the bandwidth check is done against the period. For + * Notice that the bandwidth check is done against the deadline. For * task with deadline equal to period this is the same of using - * dl_deadline instead of dl_period in the equation above. + * dl_period instead of dl_deadline in the equation above. */ static bool dl_entity_overflow(struct sched_dl_entity *dl_se, struct sched_dl_entity *pi_se, u64 t) @@ -472,7 +472,7 @@ static bool dl_entity_overflow(struct sc * of anything below microseconds resolution is actually fiction * (but still we want to give the user that illusion >;). */ - left = (pi_se->dl_period >> DL_SCALE) * (dl_se->runtime >> DL_SCALE); + left = (pi_se->dl_deadline >> DL_SCALE) * (dl_se->runtime >> DL_SCALE); right = ((dl_se->deadline - t) >> DL_SCALE) * (pi_se->dl_runtime >> DL_SCALE); Patches currently in stable-queue which might be from rostedt(a)goodmis.org are queue-4.4/sched-deadline-make-sure-the-replenishment-timer-fires-in-the-next-period.patch queue-4.4/sched-rt-do-not-pull-from-current-cpu-if-only-one-cpu-to-pull.patch queue-4.4/tracing-allocate-mask_str-buffer-dynamically.patch queue-4.4/sched-deadline-throttle-a-constrained-deadline-task-activated-after-the-deadline.patch queue-4.4/sched-deadline-use-deadline-instead-of-period-when-calculating-overflow.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "sched/deadline: Throttle a constrained deadline task activated after the deadline" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sched/deadline: Throttle a constrained deadline task activated after the deadline to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sched-deadline-throttle-a-constrained-deadline-task-activated-after-the-deadline.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Daniel Bristot de Oliveira <bristot(a)redhat.com> Date: Thu, 2 Mar 2017 15:10:58 +0100 Subject: sched/deadline: Throttle a constrained deadline task activated after the deadline From: Daniel Bristot de Oliveira <bristot(a)redhat.com> [ Upstream commit df8eac8cafce7d086be3bd5cf5a838fa37594dfb ] During the activation, CBS checks if it can reuse the current task's runtime and period. If the deadline of the task is in the past, CBS cannot use the runtime, and so it replenishes the task. This rule works fine for implicit deadline tasks (deadline == period), and the CBS was designed for implicit deadline tasks. However, a task with constrained deadline (deadine < period) might be awakened after the deadline, but before the next period. In this case, replenishing the task would allow it to run for runtime / deadline. As in this case deadline < period, CBS enables a task to run for more than the runtime / period. In a very loaded system, this can cause a domino effect, making other tasks miss their deadlines. To avoid this problem, in the activation of a constrained deadline task after the deadline but before the next period, throttle the task and set the replenishing timer to the begin of the next period, unless it is boosted. Reproducer: --------------- %< --------------- int main (int argc, char **argv) { int ret; int flags = 0; unsigned long l = 0; struct timespec ts; struct sched_attr attr; memset(&attr, 0, sizeof(attr)); attr.size = sizeof(attr); attr.sched_policy = SCHED_DEADLINE; attr.sched_runtime = 2 * 1000 * 1000; /* 2 ms */ attr.sched_deadline = 2 * 1000 * 1000; /* 2 ms */ attr.sched_period = 2 * 1000 * 1000 * 1000; /* 2 s */ ts.tv_sec = 0; ts.tv_nsec = 2000 * 1000; /* 2 ms */ ret = sched_setattr(0, &attr, flags); if (ret < 0) { perror("sched_setattr"); exit(-1); } for(;;) { /* XXX: you may need to adjust the loop */ for (l = 0; l < 150000; l++); /* * The ideia is to go to sleep right before the deadline * and then wake up before the next period to receive * a new replenishment. */ nanosleep(&ts, NULL); } exit(0); } --------------- >% --------------- On my box, this reproducer uses almost 50% of the CPU time, which is obviously wrong for a task with 2/2000 reservation. Signed-off-by: Daniel Bristot de Oliveira <bristot(a)redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: Juri Lelli <juri.lelli(a)arm.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Luca Abeni <luca.abeni(a)santannapisa.it> Cc: Mike Galbraith <efault(a)gmx.de> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Romulo Silva de Oliveira <romulo.deoliveira(a)ufsc.br> Cc: Steven Rostedt <rostedt(a)goodmis.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Tommaso Cucinotta <tommaso.cucinotta(a)sssup.it> Link: http://lkml.kernel.org/r/edf58354e01db46bf42df8d2dd32418833f68c89.148839293… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/sched/deadline.c | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -704,6 +704,37 @@ void init_dl_task_timer(struct sched_dl_ timer->function = dl_task_timer; } +/* + * During the activation, CBS checks if it can reuse the current task's + * runtime and period. If the deadline of the task is in the past, CBS + * cannot use the runtime, and so it replenishes the task. This rule + * works fine for implicit deadline tasks (deadline == period), and the + * CBS was designed for implicit deadline tasks. However, a task with + * constrained deadline (deadine < period) might be awakened after the + * deadline, but before the next period. In this case, replenishing the + * task would allow it to run for runtime / deadline. As in this case + * deadline < period, CBS enables a task to run for more than the + * runtime / period. In a very loaded system, this can cause a domino + * effect, making other tasks miss their deadlines. + * + * To avoid this problem, in the activation of a constrained deadline + * task after the deadline but before the next period, throttle the + * task and set the replenishing timer to the begin of the next period, + * unless it is boosted. + */ +static inline void dl_check_constrained_dl(struct sched_dl_entity *dl_se) +{ + struct task_struct *p = dl_task_of(dl_se); + struct rq *rq = rq_of_dl_rq(dl_rq_of_se(dl_se)); + + if (dl_time_before(dl_se->deadline, rq_clock(rq)) && + dl_time_before(rq_clock(rq), dl_next_period(dl_se))) { + if (unlikely(dl_se->dl_boosted || !start_dl_timer(p))) + return; + dl_se->dl_throttled = 1; + } +} + static int dl_runtime_exceeded(struct sched_dl_entity *dl_se) { @@ -958,6 +989,11 @@ static void dequeue_dl_entity(struct sch __dequeue_dl_entity(dl_se); } +static inline bool dl_is_constrained(struct sched_dl_entity *dl_se) +{ + return dl_se->dl_deadline < dl_se->dl_period; +} + static void enqueue_task_dl(struct rq *rq, struct task_struct *p, int flags) { struct task_struct *pi_task = rt_mutex_get_top_task(p); @@ -984,6 +1020,15 @@ static void enqueue_task_dl(struct rq *r } /* + * Check if a constrained deadline task was activated + * after the deadline but before the next period. + * If that is the case, the task will be throttled and + * the replenishment timer will be set to the next period. + */ + if (!p->dl.dl_throttled && dl_is_constrained(&p->dl)) + dl_check_constrained_dl(&p->dl); + + /* * If p is throttled, we do nothing. In fact, if it exhausted * its budget it needs a replenishment and, since it now is on * its rq, the bandwidth timer callback (which clearly has not Patches currently in stable-queue which might be from bristot(a)redhat.com are queue-4.4/sched-deadline-make-sure-the-replenishment-timer-fires-in-the-next-period.patch queue-4.4/sched-deadline-throttle-a-constrained-deadline-task-activated-after-the-deadline.patch queue-4.4/sched-deadline-use-deadline-instead-of-period-when-calculating-overflow.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "sched/deadline: Make sure the replenishment timer fires in the next period" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sched/deadline: Make sure the replenishment timer fires in the next period to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sched-deadline-make-sure-the-replenishment-timer-fires-in-the-next-period.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Daniel Bristot de Oliveira <bristot(a)redhat.com> Date: Thu, 2 Mar 2017 15:10:57 +0100 Subject: sched/deadline: Make sure the replenishment timer fires in the next period From: Daniel Bristot de Oliveira <bristot(a)redhat.com> [ Upstream commit 5ac69d37784b237707a7b15d199cdb6c6fdb6780 ] Currently, the replenishment timer is set to fire at the deadline of a task. Although that works for implicit deadline tasks because the deadline is equals to the begin of the next period, that is not correct for constrained deadline tasks (deadline < period). For instance: f.c: --------------- %< --------------- int main (void) { for(;;); } --------------- >% --------------- # gcc -o f f.c # trace-cmd record -e sched:sched_switch \ -e syscalls:sys_exit_sched_setattr \ chrt -d --sched-runtime 490000000 \ --sched-deadline 500000000 \ --sched-period 1000000000 0 ./f # trace-cmd report | grep "{pid of ./f}" After setting parameters, the task is replenished and continue running until being throttled: f-11295 [003] 13322.113776: sys_exit_sched_setattr: 0x0 The task is throttled after running 492318 ms, as expected: f-11295 [003] 13322.606094: sched_switch: f:11295 [-1] R ==> watchdog/3:32 [0] But then, the task is replenished 500719 ms after the first replenishment: <idle>-0 [003] 13322.614495: sched_switch: swapper/3:0 [120] R ==> f:11295 [-1] Running for 490277 ms: f-11295 [003] 13323.104772: sched_switch: f:11295 [-1] R ==> swapper/3:0 [120] Hence, in the first period, the task runs 2 * runtime, and that is a bug. During the first replenishment, the next deadline is set one period away. So the runtime / period starts to be respected. However, as the second replenishment took place in the wrong instant, the next replenishment will also be held in a wrong instant of time. Rather than occurring in the nth period away from the first activation, it is taking place in the (nth period - relative deadline). Signed-off-by: Daniel Bristot de Oliveira <bristot(a)redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Reviewed-by: Luca Abeni <luca.abeni(a)santannapisa.it> Reviewed-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> Reviewed-by: Juri Lelli <juri.lelli(a)arm.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Mike Galbraith <efault(a)gmx.de> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Romulo Silva de Oliveira <romulo.deoliveira(a)ufsc.br> Cc: Steven Rostedt <rostedt(a)goodmis.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Tommaso Cucinotta <tommaso.cucinotta(a)sssup.it> Link: http://lkml.kernel.org/r/ac50d89887c25285b47465638354b63362f8adff.148839293… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/sched/deadline.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -510,10 +510,15 @@ static void update_dl_entity(struct sche } } +static inline u64 dl_next_period(struct sched_dl_entity *dl_se) +{ + return dl_se->deadline - dl_se->dl_deadline + dl_se->dl_period; +} + /* * If the entity depleted all its runtime, and if we want it to sleep * while waiting for some new execution time to become available, we - * set the bandwidth enforcement timer to the replenishment instant + * set the bandwidth replenishment timer to the replenishment instant * and try to activate it. * * Notice that it is important for the caller to know if the timer @@ -535,7 +540,7 @@ static int start_dl_timer(struct task_st * that it is actually coming from rq->clock and not from * hrtimer's time base reading. */ - act = ns_to_ktime(dl_se->deadline); + act = ns_to_ktime(dl_next_period(dl_se)); now = hrtimer_cb_get_time(timer); delta = ktime_to_ns(now) - rq_clock(rq); act = ktime_add_ns(act, delta); Patches currently in stable-queue which might be from bristot(a)redhat.com are queue-4.4/sched-deadline-make-sure-the-replenishment-timer-fires-in-the-next-period.patch queue-4.4/sched-deadline-throttle-a-constrained-deadline-task-activated-after-the-deadline.patch queue-4.4/sched-deadline-use-deadline-instead-of-period-when-calculating-overflow.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "rtc: pcf8563: fix output clock rate" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rtc: pcf8563: fix output clock rate to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rtc-pcf8563-fix-output-clock-rate.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Philipp Zabel <p.zabel(a)pengutronix.de> Date: Tue, 7 Nov 2017 13:12:17 +0100 Subject: rtc: pcf8563: fix output clock rate From: Philipp Zabel <p.zabel(a)pengutronix.de> [ Upstream commit a3350f9c57ffad569c40f7320b89da1f3061c5bb ] The pcf8563_clkout_recalc_rate function erroneously ignores the frequency index read from the CLKO register and always returns 32768 Hz. Fixes: a39a6405d5f9 ("rtc: pcf8563: add CLKOUT to common clock framework") Signed-off-by: Philipp Zabel <p.zabel(a)pengutronix.de> Signed-off-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/rtc/rtc-pcf8563.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/rtc/rtc-pcf8563.c +++ b/drivers/rtc/rtc-pcf8563.c @@ -427,7 +427,7 @@ static unsigned long pcf8563_clkout_reca return 0; buf &= PCF8563_REG_CLKO_F_MASK; - return clkout_rates[ret]; + return clkout_rates[buf]; } static long pcf8563_clkout_round_rate(struct clk_hw *hw, unsigned long rate, Patches currently in stable-queue which might be from p.zabel(a)pengutronix.de are queue-4.4/rtc-pcf8563-fix-output-clock-rate.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "RDMA/cma: Avoid triggering undefined behavior" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDMA/cma: Avoid triggering undefined behavior to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rdma-cma-avoid-triggering-undefined-behavior.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Bart Van Assche <bart.vanassche(a)wdc.com> Date: Wed, 11 Oct 2017 10:48:45 -0700 Subject: RDMA/cma: Avoid triggering undefined behavior From: Bart Van Assche <bart.vanassche(a)wdc.com> [ Upstream commit c0b64f58e8d49570aa9ee55d880f92c20ff0166b ] According to the C standard the behavior of computations with integer operands is as follows: * A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type. * The behavior for signed integer underflow and overflow is undefined. Hence only use unsigned integers when checking for integer overflow. This patch is what I came up with after having analyzed the following smatch warnings: drivers/infiniband/core/cma.c:3448: cma_resolve_ib_udp() warn: signed overflow undefined. 'offset + conn_param->private_data_len < conn_param->private_data_len' drivers/infiniband/core/cma.c:3505: cma_connect_ib() warn: signed overflow undefined. 'offset + conn_param->private_data_len < conn_param->private_data_len' Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Acked-by: Sean Hefty <sean.hefty(a)intel.com> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/core/cma.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) --- a/drivers/infiniband/core/cma.c +++ b/drivers/infiniband/core/cma.c @@ -1353,7 +1353,7 @@ static struct rdma_id_private *cma_id_fr return id_priv; } -static inline int cma_user_data_offset(struct rdma_id_private *id_priv) +static inline u8 cma_user_data_offset(struct rdma_id_private *id_priv) { return cma_family(id_priv) == AF_IB ? 0 : sizeof(struct cma_hdr); } @@ -1731,7 +1731,8 @@ static int cma_req_handler(struct ib_cm_ struct rdma_id_private *listen_id, *conn_id; struct rdma_cm_event event; struct net_device *net_dev; - int offset, ret; + u8 offset; + int ret; listen_id = cma_id_from_event(cm_id, ib_event, &net_dev); if (IS_ERR(listen_id)) @@ -3118,7 +3119,8 @@ static int cma_resolve_ib_udp(struct rdm struct ib_cm_sidr_req_param req; struct ib_cm_id *id; void *private_data; - int offset, ret; + u8 offset; + int ret; memset(&req, 0, sizeof req); offset = cma_user_data_offset(id_priv); @@ -3175,7 +3177,8 @@ static int cma_connect_ib(struct rdma_id struct rdma_route *route; void *private_data; struct ib_cm_id *id; - int offset, ret; + u8 offset; + int ret; memset(&req, 0, sizeof req); offset = cma_user_data_offset(id_priv); Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are queue-4.4/target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch queue-4.4/rdma-cma-avoid-triggering-undefined-behavior.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "raid5: Set R5_Expanded on parity devices as well as data." has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled raid5: Set R5_Expanded on parity devices as well as data. to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: raid5-set-r5_expanded-on-parity-devices-as-well-as-data.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: NeilBrown <neilb(a)suse.com> Date: Tue, 17 Oct 2017 16:18:36 +1100 Subject: raid5: Set R5_Expanded on parity devices as well as data. From: NeilBrown <neilb(a)suse.com> [ Upstream commit 235b6003fb28f0dd8e7ed8fbdb088bb548291766 ] When reshaping a fully degraded raid5/raid6 to a larger nubmer of devices, the new device(s) are not in-sync and so that can make the newly grown stripe appear to be "failed". To avoid this, we set the R5_Expanded flag to say "Even though this device is not fully in-sync, this block is safe so don't treat the device as failed for this stripe". This flag is set for data devices, not not for parity devices. Consequently, if you have a RAID6 with two devices that are partly recovered and a spare, and start a reshape to include the spare, then when the reshape gets past the point where the recovery was up to, it will think the stripes are failed and will get into an infinite loop, failing to make progress. So when contructing parity on an EXPAND_READY stripe, set R5_Expanded. Reported-by: Curt <lightspd(a)gmail.com> Signed-off-by: NeilBrown <neilb(a)suse.com> Signed-off-by: Shaohua Li <shli(a)fb.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/raid5.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/md/raid5.c +++ b/drivers/md/raid5.c @@ -1681,8 +1681,11 @@ static void ops_complete_reconstruct(voi struct r5dev *dev = &sh->dev[i]; if (dev->written || i == pd_idx || i == qd_idx) { - if (!discard && !test_bit(R5_SkipCopy, &dev->flags)) + if (!discard && !test_bit(R5_SkipCopy, &dev->flags)) { set_bit(R5_UPTODATE, &dev->flags); + if (test_bit(STRIPE_EXPAND_READY, &sh->state)) + set_bit(R5_Expanded, &dev->flags); + } if (fua) set_bit(R5_WantFUA, &dev->flags); if (sync) Patches currently in stable-queue which might be from neilb(a)suse.com are queue-4.4/md-cluster-free-md_cluster_info-if-node-leave-cluster.patch queue-4.4/autofs-fix-careless-error-in-recent-commit.patch queue-4.4/raid5-set-r5_expanded-on-parity-devices-as-well-as-data.patch queue-4.4/nfsd-fix-nfsd_reset_versions-for-nfsv4.patch queue-4.4/nfsd-fix-nfsd_minorversion-..-nfsd_avail.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "ppp: Destroy the mutex when cleanup" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ppp: Destroy the mutex when cleanup to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ppp-destroy-the-mutex-when-cleanup.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Gao Feng <gfree.wind(a)vip.163.com> Date: Tue, 31 Oct 2017 18:25:37 +0800 Subject: ppp: Destroy the mutex when cleanup From: Gao Feng <gfree.wind(a)vip.163.com> [ Upstream commit f02b2320b27c16b644691267ee3b5c110846f49e ] The mutex_destroy only makes sense when enable DEBUG_MUTEX. For the good readbility, it's better to invoke it in exit func when the init func invokes mutex_init. Signed-off-by: Gao Feng <gfree.wind(a)vip.163.com> Acked-by: Guillaume Nault <g.nault(a)alphalink.fr> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ppp/ppp_generic.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/net/ppp/ppp_generic.c +++ b/drivers/net/ppp/ppp_generic.c @@ -942,6 +942,7 @@ static __net_exit void ppp_exit_net(stru unregister_netdevice_many(&list); rtnl_unlock(); + mutex_destroy(&pn->all_ppp_mutex); idr_destroy(&pn->units_idr); } Patches currently in stable-queue which might be from gfree.wind(a)vip.163.com are queue-4.4/ppp-destroy-the-mutex-when-cleanup.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-powernv-cpufreq-fix-the-frequency-read-by-proc-cpuinfo.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Shriya <shriyak(a)linux.vnet.ibm.com> Date: Fri, 13 Oct 2017 10:06:41 +0530 Subject: powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo From: Shriya <shriyak(a)linux.vnet.ibm.com> [ Upstream commit cd77b5ce208c153260ed7882d8910f2395bfaabd ] The call to /proc/cpuinfo in turn calls cpufreq_quick_get() which returns the last frequency requested by the kernel, but may not reflect the actual frequency the processor is running at. This patch makes a call to cpufreq_get() instead which returns the current frequency reported by the hardware. Fixes: fb5153d05a7d ("powerpc: powernv: Implement ppc_md.get_proc_freq()") Signed-off-by: Shriya <shriyak(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/platforms/powernv/setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/platforms/powernv/setup.c +++ b/arch/powerpc/platforms/powernv/setup.c @@ -295,7 +295,7 @@ static unsigned long pnv_get_proc_freq(u { unsigned long ret_freq; - ret_freq = cpufreq_quick_get(cpu) * 1000ul; + ret_freq = cpufreq_get(cpu) * 1000ul; /* * If the backend cpufreq driver does not exist, Patches currently in stable-queue which might be from shriyak(a)linux.vnet.ibm.com are queue-4.4/powerpc-powernv-cpufreq-fix-the-frequency-read-by-proc-cpuinfo.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/perf/hv-24x7: Fix incorrect comparison in memord" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/perf/hv-24x7: Fix incorrect comparison in memord to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-perf-hv-24x7-fix-incorrect-comparison-in-memord.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Michael Ellerman <mpe(a)ellerman.id.au> Date: Mon, 9 Oct 2017 21:52:44 +1100 Subject: powerpc/perf/hv-24x7: Fix incorrect comparison in memord From: Michael Ellerman <mpe(a)ellerman.id.au> [ Upstream commit 05c14c03138532a3cb2aa29c2960445c8753343b ] In the hv-24x7 code there is a function memord() which tries to implement a sort function return -1, 0, 1. However one of the conditions is incorrect, such that it can never be true, because we will have already returned. I don't believe there is a bug in practice though, because the comparisons are an optimisation prior to calling memcmp(). Fix it by swapping the second comparision, so it can be true. Reported-by: David Binderman <dcb314(a)hotmail.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/perf/hv-24x7.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/perf/hv-24x7.c +++ b/arch/powerpc/perf/hv-24x7.c @@ -514,7 +514,7 @@ static int memord(const void *d1, size_t { if (s1 < s2) return 1; - if (s2 > s1) + if (s1 > s2) return -1; return memcmp(d1, d2, s1); Patches currently in stable-queue which might be from mpe(a)ellerman.id.au are queue-4.4/powerpc-perf-hv-24x7-fix-incorrect-comparison-in-memord.patch queue-4.4/powerpc-powernv-cpufreq-fix-the-frequency-read-by-proc-cpuinfo.patch queue-4.4/powerpc-ipic-fix-status-get-and-status-clear.patch queue-4.4/powerpc-opal-fix-ebusy-bug-in-acquiring-tokens.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/opal: Fix EBUSY bug in acquiring tokens" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/opal: Fix EBUSY bug in acquiring tokens to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-opal-fix-ebusy-bug-in-acquiring-tokens.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: "William A. Kennington III" <wak(a)google.com> Date: Fri, 22 Sep 2017 16:58:00 -0700 Subject: powerpc/opal: Fix EBUSY bug in acquiring tokens From: "William A. Kennington III" <wak(a)google.com> [ Upstream commit 71e24d7731a2903b1ae2bba2b2971c654d9c2aa6 ] The current code checks the completion map to look for the first token that is complete. In some cases, a completion can come in but the token can still be on lease to the caller processing the completion. If this completed but unreleased token is the first token found in the bitmap by another tasks trying to acquire a token, then the __test_and_set_bit call will fail since the token will still be on lease. The acquisition will then fail with an EBUSY. This patch reorganizes the acquisition code to look at the opal_async_token_map for an unleased token. If the token has no lease it must have no outstanding completions so we should never see an EBUSY, unless we have leased out too many tokens. Since opal_async_get_token_inrerruptible is protected by a semaphore, we will practically never see EBUSY anymore. Fixes: 8d7248232208 ("powerpc/powernv: Infrastructure to support OPAL async completion") Signed-off-by: William A. Kennington III <wak(a)google.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/platforms/powernv/opal-async.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/arch/powerpc/platforms/powernv/opal-async.c +++ b/arch/powerpc/platforms/powernv/opal-async.c @@ -39,18 +39,18 @@ int __opal_async_get_token(void) int token; spin_lock_irqsave(&opal_async_comp_lock, flags); - token = find_first_bit(opal_async_complete_map, opal_max_async_tokens); + token = find_first_zero_bit(opal_async_token_map, opal_max_async_tokens); if (token >= opal_max_async_tokens) { token = -EBUSY; goto out; } - if (__test_and_set_bit(token, opal_async_token_map)) { + if (!__test_and_clear_bit(token, opal_async_complete_map)) { token = -EBUSY; goto out; } - __clear_bit(token, opal_async_complete_map); + __set_bit(token, opal_async_token_map); out: spin_unlock_irqrestore(&opal_async_comp_lock, flags); Patches currently in stable-queue which might be from wak(a)google.com are queue-4.4/powerpc-opal-fix-ebusy-bug-in-acquiring-tokens.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/ipic: Fix status get and status clear" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/ipic: Fix status get and status clear to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-ipic-fix-status-get-and-status-clear.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Christophe Leroy <christophe.leroy(a)c-s.fr> Date: Wed, 18 Oct 2017 11:16:47 +0200 Subject: powerpc/ipic: Fix status get and status clear From: Christophe Leroy <christophe.leroy(a)c-s.fr> [ Upstream commit 6b148a7ce72a7f87c81cbcde48af014abc0516a9 ] IPIC Status is provided by register IPIC_SERSR and not by IPIC_SERMR which is the mask register. Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/sysdev/ipic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/powerpc/sysdev/ipic.c +++ b/arch/powerpc/sysdev/ipic.c @@ -845,12 +845,12 @@ void ipic_disable_mcp(enum ipic_mcp_irq u32 ipic_get_mcp_status(void) { - return ipic_read(primary_ipic->regs, IPIC_SERMR); + return ipic_read(primary_ipic->regs, IPIC_SERSR); } void ipic_clear_mcp_status(u32 mask) { - ipic_write(primary_ipic->regs, IPIC_SERMR, mask); + ipic_write(primary_ipic->regs, IPIC_SERSR, mask); } /* Return an interrupt vector or NO_IRQ if no interrupt is pending. */ Patches currently in stable-queue which might be from christophe.leroy(a)c-s.fr are queue-4.4/powerpc-ipic-fix-status-get-and-status-clear.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill() to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Markus Elfring <elfring(a)users.sourceforge.net> Date: Wed, 1 Nov 2017 18:42:45 +0100 Subject: platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill() From: Markus Elfring <elfring(a)users.sourceforge.net> [ Upstream commit f6c8a317ab208aee223776327c06f23342492d54 ] Source code review for a specific software refactoring showed the need for another correction because the error code "-1" was returned so far if a call of the function "sony_call_snc_handle" failed here. Thus assign the return value from these two function calls also to the variable "err" and provide it in case of a failure. Fixes: d6f15ed876b83a1a0eba1d0473eef58acc95444a ("sony-laptop: use soft rfkill status stored in hw") Suggested-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> Link: https://lkml.org/lkml/2017/10/31/463 Link: https://lkml.kernel.org/r/<CAHp75VcMkXCioCzmLE0+BTmkqc5RSOx9yPO0ectVHMrMvewgwg(a)mail.gmail.com> Signed-off-by: Markus Elfring <elfring(a)users.sourceforge.net> Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/platform/x86/sony-laptop.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) --- a/drivers/platform/x86/sony-laptop.c +++ b/drivers/platform/x86/sony-laptop.c @@ -1655,17 +1655,19 @@ static int sony_nc_setup_rfkill(struct a if (!rfk) return -ENOMEM; - if (sony_call_snc_handle(sony_rfkill_handle, 0x200, &result) < 0) { + err = sony_call_snc_handle(sony_rfkill_handle, 0x200, &result); + if (err < 0) { rfkill_destroy(rfk); - return -1; + return err; } hwblock = !(result & 0x1); - if (sony_call_snc_handle(sony_rfkill_handle, - sony_rfkill_address[nc_type], - &result) < 0) { + err = sony_call_snc_handle(sony_rfkill_handle, + sony_rfkill_address[nc_type], + &result); + if (err < 0) { rfkill_destroy(rfk); - return -1; + return err; } swblock = !(result & 0x2); Patches currently in stable-queue which might be from elfring(a)users.sourceforge.net are queue-4.4/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "pinctrl: adi2: Fix Kconfig build problem" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled pinctrl: adi2: Fix Kconfig build problem to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: pinctrl-adi2-fix-kconfig-build-problem.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Linus Walleij <linus.walleij(a)linaro.org> Date: Wed, 11 Oct 2017 11:57:15 +0200 Subject: pinctrl: adi2: Fix Kconfig build problem From: Linus Walleij <linus.walleij(a)linaro.org> [ Upstream commit 1c363531dd814dc4fe10865722bf6b0f72ce4673 ] The build robot is complaining on Blackfin: drivers/pinctrl/pinctrl-adi2.c: In function 'port_setup': >> drivers/pinctrl/pinctrl-adi2.c:221:21: error: dereferencing pointer to incomplete type 'struct gpio_port_t' writew(readw(&regs->port_fer) & ~BIT(offset), ^~ drivers/pinctrl/pinctrl-adi2.c: In function 'adi_gpio_ack_irq': >> drivers/pinctrl/pinctrl-adi2.c:266:18: error: dereferencing pointer to incomplete type 'struct bfin_pint_regs' if (readl(&regs->invert_set) & pintbit) ^~ It seems the driver need to include <asm/gpio.h> and <asm/irq.h> to compile. The Blackfin architecture was re-defining the Kconfig PINCTRL symbol which is not OK, so replaced this with PINCTRL_BLACKFIN_ADI2 which selects PINCTRL and PINCTRL_ADI2 just like most arches do. Further, the old GPIO driver symbol GPIO_ADI was possible to select at the same time as selecting PINCTRL. This was not working because the arch-local <asm/gpio.h> header contains an explicit #ifndef PINCTRL clause making compilation break if you combine them. The same is true for DEBUG_MMRS. Make sure the ADI2 pinctrl driver is not selected at the same time as the old GPIO implementation. (This should be converted to use gpiolib or pincontrol and move to drivers/...) Also make sure the old GPIO_ADI driver or DEBUG_MMRS is not selected at the same time as the new PINCTRL implementation, and only make PINCTRL_ADI2 selectable for the Blackfin families that actually have it. This way it is still possible to add e.g. I2C-based pin control expanders on the Blackfin. Cc: Steven Miao <realmz6(a)gmail.com> Cc: Huanhuan Feng <huanhuan.feng(a)analog.com> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/blackfin/Kconfig | 7 +++++-- arch/blackfin/Kconfig.debug | 1 + drivers/pinctrl/Kconfig | 3 ++- 3 files changed, 8 insertions(+), 3 deletions(-) --- a/arch/blackfin/Kconfig +++ b/arch/blackfin/Kconfig @@ -318,11 +318,14 @@ config BF53x config GPIO_ADI def_bool y + depends on !PINCTRL depends on (BF51x || BF52x || BF53x || BF538 || BF539 || BF561) -config PINCTRL +config PINCTRL_BLACKFIN_ADI2 def_bool y - depends on BF54x || BF60x + depends on (BF54x || BF60x) + select PINCTRL + select PINCTRL_ADI2 config MEM_MT48LC64M4A2FB_7E bool --- a/arch/blackfin/Kconfig.debug +++ b/arch/blackfin/Kconfig.debug @@ -17,6 +17,7 @@ config DEBUG_VERBOSE config DEBUG_MMRS tristate "Generate Blackfin MMR tree" + depends on !PINCTRL select DEBUG_FS help Create a tree of Blackfin MMRs via the debugfs tree. If --- a/drivers/pinctrl/Kconfig +++ b/drivers/pinctrl/Kconfig @@ -26,7 +26,8 @@ config DEBUG_PINCTRL config PINCTRL_ADI2 bool "ADI pin controller driver" - depends on BLACKFIN + depends on (BF54x || BF60x) + depends on !GPIO_ADI select PINMUX select IRQ_DOMAIN help Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are queue-4.4/pinctrl-adi2-fix-kconfig-build-problem.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "perf symbols: Fix symbols__fixup_end heuristic for corner cases" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf symbols: Fix symbols__fixup_end heuristic for corner cases to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: perf-symbols-fix-symbols__fixup_end-heuristic-for-corner-cases.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Daniel Borkmann <daniel(a)iogearbox.net> Date: Wed, 15 Mar 2017 22:53:37 +0100 Subject: perf symbols: Fix symbols__fixup_end heuristic for corner cases From: Daniel Borkmann <daniel(a)iogearbox.net> [ Upstream commit e7ede72a6d40cb3a30c087142d79381ca8a31dab ] The current symbols__fixup_end() heuristic for the last entry in the rb tree is suboptimal as it leads to not being able to recognize the symbol in the call graph in a couple of corner cases, for example: i) If the symbol has a start address (f.e. exposed via kallsyms) that is at a page boundary, then the roundup(curr->start, 4096) for the last entry will result in curr->start == curr->end with a symbol length of zero. ii) If the symbol has a start address that is shortly before a page boundary, then also here, curr->end - curr->start will just be very few bytes, where it's unrealistic that we could perform a match against. Instead, change the heuristic to roundup(curr->start, 4096) + 4096, so that we can catch such corner cases and have a better chance to find that specific symbol. It's still just best effort as the real end of the symbol is unknown to us (and could even be at a larger offset than the current range), but better than the current situation. Alexei reported that he recently run into case i) with a JITed eBPF program (these are all page aligned) as the last symbol which wasn't properly shown in the call graph (while other eBPF program symbols in the rb tree were displayed correctly). Since this is a generic issue, lets try to improve the heuristic a bit. Reported-and-Tested-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Fixes: 2e538c4a1847 ("perf tools: Improve kernel/modules symbol lookup") Link: http://lkml.kernel.org/r/bb5c80d27743be6f12afc68405f1956a330e1bc9.148961436… Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/util/symbol.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/perf/util/symbol.c +++ b/tools/perf/util/symbol.c @@ -200,7 +200,7 @@ void symbols__fixup_end(struct rb_root * /* Last entry */ if (curr->end == curr->start) - curr->end = roundup(curr->start, 4096); + curr->end = roundup(curr->start, 4096) + 4096; } void __map_groups__fixup_end(struct map_groups *mg, enum map_type type) Patches currently in stable-queue which might be from daniel(a)iogearbox.net are queue-4.4/perf-symbols-fix-symbols__fixup_end-heuristic-for-corner-cases.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "PCI/PME: Handle invalid data when reading Root Status" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled PCI/PME: Handle invalid data when reading Root Status to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: pci-pme-handle-invalid-data-when-reading-root-status.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Qiang <zhengqiang10(a)huawei.com> Date: Thu, 28 Sep 2017 11:54:34 +0800 Subject: PCI/PME: Handle invalid data when reading Root Status From: Qiang <zhengqiang10(a)huawei.com> [ Upstream commit 3ad3f8ce50914288731a3018b27ee44ab803e170 ] PCIe PME and native hotplug share the same interrupt number, so hotplug interrupts are also processed by PME. In some cases, e.g., a Link Down interrupt, a device may be present but unreachable, so when we try to read its Root Status register, the read fails and we get all ones data (0xffffffff). Previously, we interpreted that data as PCI_EXP_RTSTA_PME being set, i.e., "some device has asserted PME," so we scheduled pcie_pme_work_fn(). This caused an infinite loop because pcie_pme_work_fn() tried to handle PME requests until PCI_EXP_RTSTA_PME is cleared, but with the link down, PCI_EXP_RTSTA_PME can't be cleared. Check for the invalid 0xffffffff data everywhere we read the Root Status register. 1469d17dd341 ("PCI: pciehp: Handle invalid data when reading from non-existent devices") added similar checks in the hotplug driver. Signed-off-by: Qiang Zheng <zhengqiang10(a)huawei.com> [bhelgaas: changelog, also check in pcie_pme_work_fn(), use "~0" to follow other similar checks] Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pci/pcie/pme.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/pci/pcie/pme.c +++ b/drivers/pci/pcie/pme.c @@ -233,6 +233,9 @@ static void pcie_pme_work_fn(struct work break; pcie_capability_read_dword(port, PCI_EXP_RTSTA, &rtsta); + if (rtsta == (u32) ~0) + break; + if (rtsta & PCI_EXP_RTSTA_PME) { /* * Clear PME status of the port. If there are other @@ -280,7 +283,7 @@ static irqreturn_t pcie_pme_irq(int irq, spin_lock_irqsave(&data->lock, flags); pcie_capability_read_dword(port, PCI_EXP_RTSTA, &rtsta); - if (!(rtsta & PCI_EXP_RTSTA_PME)) { + if (rtsta == (u32) ~0 || !(rtsta & PCI_EXP_RTSTA_PME)) { spin_unlock_irqrestore(&data->lock, flags); return IRQ_NONE; } Patches currently in stable-queue which might be from zhengqiang10(a)huawei.com are queue-4.4/pci-pme-handle-invalid-data-when-reading-root-status.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "PCI: Detach driver before procfs & sysfs teardown on device remove" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled PCI: Detach driver before procfs & sysfs teardown on device remove to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: pci-detach-driver-before-procfs-sysfs-teardown-on-device-remove.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Alex Williamson <alex.williamson(a)redhat.com> Date: Wed, 11 Oct 2017 15:35:56 -0600 Subject: PCI: Detach driver before procfs & sysfs teardown on device remove From: Alex Williamson <alex.williamson(a)redhat.com> [ Upstream commit 16b6c8bb687cc3bec914de09061fcb8411951fda ] When removing a device, for example a VF being removed due to SR-IOV teardown, a "soft" hot-unplug via 'echo 1 > remove' in sysfs, or an actual hot-unplug, we first remove the procfs and sysfs attributes for the device before attempting to release the device from any driver bound to it. Unbinding the driver from the device can take time. The device might need to write out data or it might be actively in use. If it's in use by userspace through a vfio driver, the unbind might block until the user releases the device. This leads to a potentially non-trivial amount of time where the device exists, but we've torn down the interfaces that userspace uses to examine devices, for instance lspci might generate this sort of error: pcilib: Cannot open /sys/bus/pci/devices/0000:01:0a.3/config lspci: Unable to read the standard configuration space header of device 0000:01:0a.3 We don't seem to have any dependence on this teardown ordering in the kernel, so let's unbind the driver first, which is also more symmetric with the instantiation of the device in pci_bus_add_device(). Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pci/remove.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/pci/remove.c +++ b/drivers/pci/remove.c @@ -20,9 +20,9 @@ static void pci_stop_dev(struct pci_dev pci_pme_active(dev, false); if (dev->is_added) { + device_release_driver(&dev->dev); pci_proc_detach_device(dev); pci_remove_sysfs_dev_files(dev); - device_release_driver(&dev->dev); dev->is_added = 0; } Patches currently in stable-queue which might be from alex.williamson(a)redhat.com are queue-4.4/pci-detach-driver-before-procfs-sysfs-teardown-on-device-remove.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "openrisc: fix issue handling 8 byte get_user calls" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled openrisc: fix issue handling 8 byte get_user calls to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: openrisc-fix-issue-handling-8-byte-get_user-calls.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Stafford Horne <shorne(a)gmail.com> Date: Mon, 13 Mar 2017 07:44:45 +0900 Subject: openrisc: fix issue handling 8 byte get_user calls From: Stafford Horne <shorne(a)gmail.com> [ Upstream commit 154e67cd8e8f964809d0e75e44bb121b169c75b3 ] Was getting the following error with allmodconfig: ERROR: "__get_user_bad" [lib/test_user_copy.ko] undefined! This was simply a missing break statement, causing an unwanted fall through. Signed-off-by: Stafford Horne <shorne(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/openrisc/include/asm/uaccess.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/openrisc/include/asm/uaccess.h +++ b/arch/openrisc/include/asm/uaccess.h @@ -215,7 +215,7 @@ do { \ case 1: __get_user_asm(x, ptr, retval, "l.lbz"); break; \ case 2: __get_user_asm(x, ptr, retval, "l.lhz"); break; \ case 4: __get_user_asm(x, ptr, retval, "l.lwz"); break; \ - case 8: __get_user_asm2(x, ptr, retval); \ + case 8: __get_user_asm2(x, ptr, retval); break; \ default: (x) = __get_user_bad(); \ } \ } while (0) Patches currently in stable-queue which might be from shorne(a)gmail.com are queue-4.4/openrisc-fix-issue-handling-8-byte-get_user-calls.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "NFSv4.1 respect server's max size in CREATE_SESSION" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled NFSv4.1 respect server's max size in CREATE_SESSION to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nfsv4.1-respect-server-s-max-size-in-create_session.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Olga Kornievskaia <kolga(a)netapp.com> Date: Wed, 8 Mar 2017 14:39:15 -0500 Subject: NFSv4.1 respect server's max size in CREATE_SESSION From: Olga Kornievskaia <kolga(a)netapp.com> [ Upstream commit 033853325fe3bdc70819a8b97915bd3bca41d3af ] Currently client doesn't respect max sizes server returns in CREATE_SESSION. nfs4_session_set_rwsize() gets called and server->rsize, server->wsize are 0 so they never get set to the sizes returned by the server. Signed-off-by: Olga Kornievskaia <kolga(a)netapp.com> Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfs/nfs4client.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/fs/nfs/nfs4client.c +++ b/fs/nfs/nfs4client.c @@ -895,9 +895,9 @@ static void nfs4_session_set_rwsize(stru server_resp_sz = sess->fc_attrs.max_resp_sz - nfs41_maxread_overhead; server_rqst_sz = sess->fc_attrs.max_rqst_sz - nfs41_maxwrite_overhead; - if (server->rsize > server_resp_sz) + if (!server->rsize || server->rsize > server_resp_sz) server->rsize = server_resp_sz; - if (server->wsize > server_rqst_sz) + if (!server->wsize || server->wsize > server_rqst_sz) server->wsize = server_rqst_sz; #endif /* CONFIG_NFS_V4_1 */ } Patches currently in stable-queue which might be from kolga(a)netapp.com are queue-4.4/nfsv4.1-respect-server-s-max-size-in-create_session.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "NFSD: fix nfsd_reset_versions for NFSv4." has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled NFSD: fix nfsd_reset_versions for NFSv4. to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nfsd-fix-nfsd_reset_versions-for-nfsv4.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: NeilBrown <neilb(a)suse.com> Date: Fri, 10 Mar 2017 11:36:39 +1100 Subject: NFSD: fix nfsd_reset_versions for NFSv4. From: NeilBrown <neilb(a)suse.com> [ Upstream commit 800a938f0bf9130c8256116649c0cc5806bfb2fd ] If you write "-2 -3 -4" to the "versions" file, it will notice that no versions are enabled, and nfsd_reset_versions() is called. This enables all major versions, not no minor versions. So we lose the invariant that NFSv4 is only advertised when at least one minor is enabled. Fix the code to explicitly enable minor versions for v4, change it to use nfsd_vers() to test and set, and simplify the code. Signed-off-by: NeilBrown <neilb(a)suse.com> Signed-off-by: J. Bruce Fields <bfields(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfsd/nfssvc.c | 25 +++++++++++-------------- 1 file changed, 11 insertions(+), 14 deletions(-) --- a/fs/nfsd/nfssvc.c +++ b/fs/nfsd/nfssvc.c @@ -330,23 +330,20 @@ static void nfsd_last_thread(struct svc_ void nfsd_reset_versions(void) { - int found_one = 0; int i; - for (i = NFSD_MINVERS; i < NFSD_NRVERS; i++) { - if (nfsd_program.pg_vers[i]) - found_one = 1; - } + for (i = 0; i < NFSD_NRVERS; i++) + if (nfsd_vers(i, NFSD_TEST)) + return; - if (!found_one) { - for (i = NFSD_MINVERS; i < NFSD_NRVERS; i++) - nfsd_program.pg_vers[i] = nfsd_version[i]; -#if defined(CONFIG_NFSD_V2_ACL) || defined(CONFIG_NFSD_V3_ACL) - for (i = NFSD_ACL_MINVERS; i < NFSD_ACL_NRVERS; i++) - nfsd_acl_program.pg_vers[i] = - nfsd_acl_version[i]; -#endif - } + for (i = 0; i < NFSD_NRVERS; i++) + if (i != 4) + nfsd_vers(i, NFSD_SET); + else { + int minor = 0; + while (nfsd_minorversion(minor, NFSD_SET) >= 0) + minor++; + } } /* Patches currently in stable-queue which might be from neilb(a)suse.com are queue-4.4/md-cluster-free-md_cluster_info-if-node-leave-cluster.patch queue-4.4/autofs-fix-careless-error-in-recent-commit.patch queue-4.4/raid5-set-r5_expanded-on-parity-devices-as-well-as-data.patch queue-4.4/nfsd-fix-nfsd_reset_versions-for-nfsv4.patch queue-4.4/nfsd-fix-nfsd_minorversion-..-nfsd_avail.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "NFSD: fix nfsd_minorversion(.., NFSD_AVAIL)" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled NFSD: fix nfsd_minorversion(.., NFSD_AVAIL) to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nfsd-fix-nfsd_minorversion-..-nfsd_avail.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: NeilBrown <neilb(a)suse.com> Date: Fri, 10 Mar 2017 11:36:39 +1100 Subject: NFSD: fix nfsd_minorversion(.., NFSD_AVAIL) From: NeilBrown <neilb(a)suse.com> [ Upstream commit 928c6fb3a9bfd6c5b287aa3465226add551c13c0 ] Current code will return 1 if the version is supported, and -1 if it isn't. This is confusing and inconsistent with the one place where this is used. So change to return 1 if it is supported, and zero if not. i.e. an error is never returned. Signed-off-by: NeilBrown <neilb(a)suse.com> Signed-off-by: J. Bruce Fields <bfields(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfsd/nfssvc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/nfsd/nfssvc.c +++ b/fs/nfsd/nfssvc.c @@ -151,7 +151,8 @@ int nfsd_vers(int vers, enum vers_op cha int nfsd_minorversion(u32 minorversion, enum vers_op change) { - if (minorversion > NFSD_SUPPORTED_MINOR_VERSION) + if (minorversion > NFSD_SUPPORTED_MINOR_VERSION && + change != NFSD_AVAIL) return -1; switch(change) { case NFSD_SET: Patches currently in stable-queue which might be from neilb(a)suse.com are queue-4.4/md-cluster-free-md_cluster_info-if-node-leave-cluster.patch queue-4.4/autofs-fix-careless-error-in-recent-commit.patch queue-4.4/raid5-set-r5_expanded-on-parity-devices-as-well-as-data.patch queue-4.4/nfsd-fix-nfsd_reset_versions-for-nfsv4.patch queue-4.4/nfsd-fix-nfsd_minorversion-..-nfsd_avail.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "netfilter: ipvs: Fix inappropriate output of procfs" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled netfilter: ipvs: Fix inappropriate output of procfs to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: netfilter-ipvs-fix-inappropriate-output-of-procfs.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: KUWAZAWA Takuya <albatross0(a)gmail.com> Date: Sun, 15 Oct 2017 20:54:10 +0900 Subject: netfilter: ipvs: Fix inappropriate output of procfs From: KUWAZAWA Takuya <albatross0(a)gmail.com> [ Upstream commit c5504f724c86ee925e7ffb80aa342cfd57959b13 ] Information about ipvs in different network namespace can be seen via procfs. How to reproduce: # ip netns add ns01 # ip netns add ns02 # ip netns exec ns01 ip a add dev lo 127.0.0.1/8 # ip netns exec ns02 ip a add dev lo 127.0.0.1/8 # ip netns exec ns01 ipvsadm -A -t 10.1.1.1:80 # ip netns exec ns02 ipvsadm -A -t 10.1.1.2:80 The ipvsadm displays information about its own network namespace only. # ip netns exec ns01 ipvsadm -Ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.1.1.1:80 wlc # ip netns exec ns02 ipvsadm -Ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.1.1.2:80 wlc But I can see information about other network namespace via procfs. # ip netns exec ns01 cat /proc/net/ip_vs IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 0A010101:0050 wlc TCP 0A010102:0050 wlc # ip netns exec ns02 cat /proc/net/ip_vs IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 0A010102:0050 wlc Signed-off-by: KUWAZAWA Takuya <albatross0(a)gmail.com> Acked-by: Julian Anastasov <ja(a)ssi.bg> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/netfilter/ipvs/ip_vs_ctl.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/net/netfilter/ipvs/ip_vs_ctl.c +++ b/net/netfilter/ipvs/ip_vs_ctl.c @@ -1999,12 +1999,16 @@ static int ip_vs_info_seq_show(struct se seq_puts(seq, " -> RemoteAddress:Port Forward Weight ActiveConn InActConn\n"); } else { + struct net *net = seq_file_net(seq); + struct netns_ipvs *ipvs = net_ipvs(net); const struct ip_vs_service *svc = v; const struct ip_vs_iter *iter = seq->private; const struct ip_vs_dest *dest; struct ip_vs_scheduler *sched = rcu_dereference(svc->scheduler); char *sched_name = sched ? sched->name : "none"; + if (svc->ipvs != ipvs) + return 0; if (iter->table == ip_vs_svc_table) { #ifdef CONFIG_IP_VS_IPV6 if (svc->af == AF_INET6) Patches currently in stable-queue which might be from albatross0(a)gmail.com are queue-4.4/netfilter-ipvs-fix-inappropriate-output-of-procfs.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "netfilter: bridge: honor frag_max_size when refragmenting" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled netfilter: bridge: honor frag_max_size when refragmenting to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: netfilter-bridge-honor-frag_max_size-when-refragmenting.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Florian Westphal <fw(a)strlen.de> Date: Thu, 9 Mar 2017 23:22:30 +0100 Subject: netfilter: bridge: honor frag_max_size when refragmenting From: Florian Westphal <fw(a)strlen.de> [ Upstream commit 4ca60d08cbe65f501baad64af50fceba79c19fbb ] consider a bridge with mtu 9000, but end host sending smaller packets to another host with mtu < 9000. In this case, after reassembly, bridge+defrag would refragment, and then attempt to send the reassembled packet as long as it was below 9k. Instead we have to cap by the largest fragment size seen. 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)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/bridge/br_netfilter_hooks.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) --- a/net/bridge/br_netfilter_hooks.c +++ b/net/bridge/br_netfilter_hooks.c @@ -701,18 +701,20 @@ static unsigned int nf_bridge_mtu_reduct static int br_nf_dev_queue_xmit(struct net *net, struct sock *sk, struct sk_buff *skb) { - struct nf_bridge_info *nf_bridge; - unsigned int mtu_reserved; + struct nf_bridge_info *nf_bridge = nf_bridge_info_get(skb); + unsigned int mtu, mtu_reserved; mtu_reserved = nf_bridge_mtu_reduction(skb); + mtu = skb->dev->mtu; - if (skb_is_gso(skb) || skb->len + mtu_reserved <= skb->dev->mtu) { + if (nf_bridge->frag_max_size && nf_bridge->frag_max_size < mtu) + mtu = nf_bridge->frag_max_size; + + if (skb_is_gso(skb) || skb->len + mtu_reserved <= mtu) { nf_bridge_info_free(skb); return br_dev_queue_push_xmit(net, sk, skb); } - nf_bridge = nf_bridge_info_get(skb); - /* This is wrong! We should preserve the original fragment * boundaries by preserving frag_list rather than refragmenting. */ Patches currently in stable-queue which might be from fw(a)strlen.de are queue-4.4/netfilter-bridge-honor-frag_max_size-when-refragmenting.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "net: wimax/i2400m: fix NULL-deref at probe" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: wimax/i2400m: fix NULL-deref at probe to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-wimax-i2400m-fix-null-deref-at-probe.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Johan Hovold <johan(a)kernel.org> Date: Mon, 13 Mar 2017 13:42:03 +0100 Subject: net: wimax/i2400m: fix NULL-deref at probe From: Johan Hovold <johan(a)kernel.org> [ Upstream commit 6e526fdff7be4f13b24f929a04c0e9ae6761291e ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory beyond the endpoint array should a malicious device lack the expected endpoints. The endpoints are specifically dereferenced in the i2400m_bootrom_init path during probe (e.g. in i2400mu_tx_bulk_out). Fixes: f398e4240fce ("i2400m/USB: probe/disconnect, dev init/shutdown and reset backends") Cc: Inaky Perez-Gonzalez <inaky(a)linux.intel.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wimax/i2400m/usb.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/net/wimax/i2400m/usb.c +++ b/drivers/net/wimax/i2400m/usb.c @@ -467,6 +467,9 @@ int i2400mu_probe(struct usb_interface * struct i2400mu *i2400mu; struct usb_device *usb_dev = interface_to_usbdev(iface); + if (iface->cur_altsetting->desc.bNumEndpoints < 4) + return -ENODEV; + if (usb_dev->speed != USB_SPEED_HIGH) dev_err(dev, "device not connected as high speed\n"); Patches currently in stable-queue which might be from johan(a)kernel.org are queue-4.4/net-wimax-i2400m-fix-null-deref-at-probe.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "net: Resend IGMP memberships upon peer notification." has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: Resend IGMP memberships upon peer notification. to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-resend-igmp-memberships-upon-peer-notification.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Vlad Yasevich <vyasevich(a)gmail.com> Date: Tue, 14 Mar 2017 08:58:08 -0400 Subject: net: Resend IGMP memberships upon peer notification. From: Vlad Yasevich <vyasevich(a)gmail.com> [ Upstream commit 37c343b4f4e70e9dc328ab04903c0ec8d154c1a4 ] When we notify peers of potential changes, it's also good to update IGMP memberships. For example, during VM migration, updating IGMP memberships will redirect existing multicast streams to the VM at the new location. Signed-off-by: Vladislav Yasevich <vyasevic(a)redhat.com> Acked-by: Michael S. Tsirkin <mst(a)redhat.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/core/dev.c | 1 + 1 file changed, 1 insertion(+) --- a/net/core/dev.c +++ b/net/core/dev.c @@ -1300,6 +1300,7 @@ void netdev_notify_peers(struct net_devi { rtnl_lock(); call_netdevice_notifiers(NETDEV_NOTIFY_PEERS, dev); + call_netdevice_notifiers(NETDEV_RESEND_IGMP, dev); rtnl_unlock(); } EXPORT_SYMBOL(netdev_notify_peers); Patches currently in stable-queue which might be from vyasevich(a)gmail.com are queue-4.4/net-resend-igmp-memberships-upon-peer-notification.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "net/mlx4_core: Avoid delays during VF driver device shutdown" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net/mlx4_core: Avoid delays during VF driver device shutdown to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-mlx4_core-avoid-delays-during-vf-driver-device-shutdown.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Jack Morgenstein <jackm(a)dev.mellanox.co.il> Date: Mon, 13 Mar 2017 19:29:08 +0200 Subject: net/mlx4_core: Avoid delays during VF driver device shutdown From: Jack Morgenstein <jackm(a)dev.mellanox.co.il> [ Upstream commit 4cbe4dac82e423ecc9a0ba46af24a860853259f4 ] Some Hypervisors detach VFs from VMs by instantly causing an FLR event to be generated for a VF. In the mlx4 case, this will cause that VF's comm channel to be disabled before the VM has an opportunity to invoke the VF device's "shutdown" method. For such Hypervisors, there is a race condition between the VF's shutdown method and its internal-error detection/reset thread. The internal-error detection/reset thread (which runs every 5 seconds) also detects a disabled comm channel. If the internal-error detection/reset flow wins the race, we still get delays (while that flow tries repeatedly to detect comm-channel recovery). The cited commit fixed the command timeout problem when the internal-error detection/reset flow loses the race. This commit avoids the unneeded delays when the internal-error detection/reset flow wins. Fixes: d585df1c5ccf ("net/mlx4_core: Avoid command timeouts during VF driver device shutdown") Signed-off-by: Jack Morgenstein <jackm(a)dev.mellanox.co.il> Reported-by: Simon Xiao <sixiao(a)microsoft.com> Signed-off-by: Tariq Toukan <tariqt(a)mellanox.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/mellanox/mlx4/cmd.c | 11 +++++++++++ drivers/net/ethernet/mellanox/mlx4/main.c | 11 +++++++++++ include/linux/mlx4/device.h | 1 + 3 files changed, 23 insertions(+) --- a/drivers/net/ethernet/mellanox/mlx4/cmd.c +++ b/drivers/net/ethernet/mellanox/mlx4/cmd.c @@ -2278,6 +2278,17 @@ static int sync_toggles(struct mlx4_dev rd_toggle = swab32(readl(&priv->mfunc.comm->slave_read)); if (wr_toggle == 0xffffffff || rd_toggle == 0xffffffff) { /* PCI might be offline */ + + /* If device removal has been requested, + * do not continue retrying. + */ + if (dev->persist->interface_state & + MLX4_INTERFACE_STATE_NOWAIT) { + mlx4_warn(dev, + "communication channel is offline\n"); + return -EIO; + } + msleep(100); wr_toggle = swab32(readl(&priv->mfunc.comm-> slave_write)); --- a/drivers/net/ethernet/mellanox/mlx4/main.c +++ b/drivers/net/ethernet/mellanox/mlx4/main.c @@ -1763,6 +1763,14 @@ static int mlx4_comm_check_offline(struc (u32)(1 << COMM_CHAN_OFFLINE_OFFSET)); if (!offline_bit) return 0; + + /* If device removal has been requested, + * do not continue retrying. + */ + if (dev->persist->interface_state & + MLX4_INTERFACE_STATE_NOWAIT) + break; + /* There are cases as part of AER/Reset flow that PF needs * around 100 msec to load. We therefore sleep for 100 msec * to allow other tasks to make use of that CPU during this @@ -3690,6 +3698,9 @@ static void mlx4_remove_one(struct pci_d struct mlx4_priv *priv = mlx4_priv(dev); int active_vfs = 0; + if (mlx4_is_slave(dev)) + persist->interface_state |= MLX4_INTERFACE_STATE_NOWAIT; + mutex_lock(&persist->interface_state_mutex); persist->interface_state |= MLX4_INTERFACE_STATE_DELETION; mutex_unlock(&persist->interface_state_mutex); --- a/include/linux/mlx4/device.h +++ b/include/linux/mlx4/device.h @@ -460,6 +460,7 @@ enum { enum { MLX4_INTERFACE_STATE_UP = 1 << 0, MLX4_INTERFACE_STATE_DELETION = 1 << 1, + MLX4_INTERFACE_STATE_NOWAIT = 1 << 2, }; #define MSTR_SM_CHANGE_MASK (MLX4_EQ_PORT_INFO_MSTR_SM_SL_CHANGE_MASK | \ Patches currently in stable-queue which might be from jackm(a)dev.mellanox.co.il are queue-4.4/net-mlx4_core-avoid-delays-during-vf-driver-device-shutdown.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "net: initialize msg.msg_flags in recvfrom" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: initialize msg.msg_flags in recvfrom to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-initialize-msg.msg_flags-in-recvfrom.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Alexander Potapenko <glider(a)google.com> Date: Wed, 8 Mar 2017 18:08:16 +0100 Subject: net: initialize msg.msg_flags in recvfrom From: Alexander Potapenko <glider(a)google.com> [ Upstream commit 9f138fa609c47403374a862a08a41394be53d461 ] KMSAN reports a use of uninitialized memory in put_cmsg() because msg.msg_flags in recvfrom haven't been initialized properly. The flag values don't affect the result on this path, but it's still a good idea to initialize them explicitly. Signed-off-by: Alexander Potapenko <glider(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/socket.c | 1 + 1 file changed, 1 insertion(+) --- a/net/socket.c +++ b/net/socket.c @@ -1697,6 +1697,7 @@ SYSCALL_DEFINE6(recvfrom, int, fd, void /* We assume all kernel code knows the size of sockaddr_storage */ msg.msg_namelen = 0; msg.msg_iocb = NULL; + msg.msg_flags = 0; if (sock->file->f_flags & O_NONBLOCK) flags |= MSG_DONTWAIT; err = sock_recvmsg(sock, &msg, iov_iter_count(&msg.msg_iter), flags); Patches currently in stable-queue which might be from glider(a)google.com are queue-4.4/net-initialize-msg.msg_flags-in-recvfrom.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "net: bcmgenet: reserved phy revisions must be checked first" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: bcmgenet: reserved phy revisions must be checked first to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-bcmgenet-reserved-phy-revisions-must-be-checked-first.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Doug Berger <opendmb(a)gmail.com> Date: Thu, 9 Mar 2017 16:58:45 -0800 Subject: net: bcmgenet: reserved phy revisions must be checked first From: Doug Berger <opendmb(a)gmail.com> [ Upstream commit eca4bad73409aedc6ff22f823c18b67a4f08c851 ] The reserved gphy_rev value of 0x01ff must be tested before the old or new scheme for GPHY major versioning are tested, otherwise it will be treated as 0xff00 according to the old scheme. Fixes: b04a2f5b9ff5 ("net: bcmgenet: add support for new GENET PHY revision scheme") Signed-off-by: Doug Berger <opendmb(a)gmail.com> Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/broadcom/genet/bcmgenet.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c @@ -3326,6 +3326,12 @@ static void bcmgenet_set_hw_params(struc */ gphy_rev = reg & 0xffff; + /* This is reserved so should require special treatment */ + if (gphy_rev == 0 || gphy_rev == 0x01ff) { + pr_warn("Invalid GPHY revision detected: 0x%04x\n", gphy_rev); + return; + } + /* This is the good old scheme, just GPHY major, no minor nor patch */ if ((gphy_rev & 0xf0) != 0) priv->gphy_rev = gphy_rev << 8; @@ -3334,12 +3340,6 @@ static void bcmgenet_set_hw_params(struc else if ((gphy_rev & 0xff00) != 0) priv->gphy_rev = gphy_rev; - /* This is reserved so should require special treatment */ - else if (gphy_rev == 0 || gphy_rev == 0x01ff) { - pr_warn("Invalid GPHY revision detected: 0x%04x\n", gphy_rev); - return; - } - #ifdef CONFIG_PHYS_ADDR_T_64BIT if (!(params->flags & GENET_HAS_40BITS)) pr_warn("GENET does not support 40-bits PA\n"); Patches currently in stable-queue which might be from opendmb(a)gmail.com are queue-4.4/net-bcmgenet-correct-the-rbuf_ovfl_cnt-and-rbuf_err_cnt-mib-values.patch queue-4.4/net-bcmgenet-correct-mib-access-of-unimac-runt-counters.patch queue-4.4/net-bcmgenet-power-down-internal-phy-if-open-or-resume-fails.patch queue-4.4/net-bcmgenet-reserved-phy-revisions-must-be-checked-first.patch queue-4.4/net-bcmgenet-power-up-the-internal-phy-before-probing-the-mii.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "net: bcmgenet: Power up the internal PHY before probing the MII" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: bcmgenet: Power up the internal PHY before probing the MII to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-bcmgenet-power-up-the-internal-phy-before-probing-the-mii.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Doug Berger <opendmb(a)gmail.com> Date: Thu, 9 Mar 2017 16:58:48 -0800 Subject: net: bcmgenet: Power up the internal PHY before probing the MII From: Doug Berger <opendmb(a)gmail.com> [ Upstream commit 6be371b053dc86f11465cc1abce2e99bda0a0574 ] When using the internal PHY it must be powered up when the MII is probed or the PHY will not be detected. Since the PHY is powered up at reset this has not been a problem. However, when the kernel is restarted with kexec the PHY will likely be powered down when the kernel starts so it will not be detected and the Ethernet link will not be established. This commit explicitly powers up the internal PHY when the GENET driver is probed to correct this behavior. Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file") Signed-off-by: Doug Berger <opendmb(a)gmail.com> Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/broadcom/genet/bcmgenet.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c @@ -3384,6 +3384,7 @@ static int bcmgenet_probe(struct platfor const void *macaddr; struct resource *r; int err = -EIO; + const char *phy_mode_str; /* Up to GENET_MAX_MQ_CNT + 1 TX queues and RX queues */ dev = alloc_etherdev_mqs(sizeof(*priv), GENET_MAX_MQ_CNT + 1, @@ -3489,6 +3490,13 @@ static int bcmgenet_probe(struct platfor priv->clk_eee = NULL; } + /* If this is an internal GPHY, power it on now, before UniMAC is + * brought out of reset as absolutely no UniMAC activity is allowed + */ + if (dn && !of_property_read_string(dn, "phy-mode", &phy_mode_str) && + !strcasecmp(phy_mode_str, "internal")) + bcmgenet_power_up(priv, GENET_POWER_PASSIVE); + err = reset_umac(priv); if (err) goto err_clk_disable; Patches currently in stable-queue which might be from opendmb(a)gmail.com are queue-4.4/net-bcmgenet-correct-the-rbuf_ovfl_cnt-and-rbuf_err_cnt-mib-values.patch queue-4.4/net-bcmgenet-correct-mib-access-of-unimac-runt-counters.patch queue-4.4/net-bcmgenet-power-down-internal-phy-if-open-or-resume-fails.patch queue-4.4/net-bcmgenet-reserved-phy-revisions-must-be-checked-first.patch queue-4.4/net-bcmgenet-power-up-the-internal-phy-before-probing-the-mii.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "net: bcmgenet: power down internal phy if open or resume fails" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: bcmgenet: power down internal phy if open or resume fails to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-bcmgenet-power-down-internal-phy-if-open-or-resume-fails.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Doug Berger <opendmb(a)gmail.com> Date: Thu, 9 Mar 2017 16:58:46 -0800 Subject: net: bcmgenet: power down internal phy if open or resume fails From: Doug Berger <opendmb(a)gmail.com> [ Upstream commit 7627409cc4970e8c8b9de6945ad86a575290a94e ] Since the internal PHY is powered up during the open and resume functions it should be powered back down if the functions fail. Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file") Signed-off-by: Doug Berger <opendmb(a)gmail.com> Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/broadcom/genet/bcmgenet.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c @@ -2950,6 +2950,8 @@ err_irq0: err_fini_dma: bcmgenet_fini_dma(priv); err_clk_disable: + if (priv->internal_phy) + bcmgenet_power_down(priv, GENET_POWER_PASSIVE); clk_disable_unprepare(priv->clk); return ret; } @@ -3653,6 +3655,8 @@ static int bcmgenet_resume(struct device return 0; out_clk_disable: + if (priv->internal_phy) + bcmgenet_power_down(priv, GENET_POWER_PASSIVE); clk_disable_unprepare(priv->clk); return ret; } Patches currently in stable-queue which might be from opendmb(a)gmail.com are queue-4.4/net-bcmgenet-correct-the-rbuf_ovfl_cnt-and-rbuf_err_cnt-mib-values.patch queue-4.4/net-bcmgenet-correct-mib-access-of-unimac-runt-counters.patch queue-4.4/net-bcmgenet-power-down-internal-phy-if-open-or-resume-fails.patch queue-4.4/net-bcmgenet-reserved-phy-revisions-must-be-checked-first.patch queue-4.4/net-bcmgenet-power-up-the-internal-phy-before-probing-the-mii.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "net: bcmgenet: correct the RBUF_OVFL_CNT and RBUF_ERR_CNT MIB values" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: bcmgenet: correct the RBUF_OVFL_CNT and RBUF_ERR_CNT MIB values to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-bcmgenet-correct-the-rbuf_ovfl_cnt-and-rbuf_err_cnt-mib-values.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Doug Berger <opendmb(a)gmail.com> Date: Thu, 9 Mar 2017 16:58:43 -0800 Subject: net: bcmgenet: correct the RBUF_OVFL_CNT and RBUF_ERR_CNT MIB values From: Doug Berger <opendmb(a)gmail.com> [ Upstream commit ffff71328a3c321f7c14cc1edd33577717037744 ] The location of the RBUF overflow and error counters has moved between different version of the GENET MAC. This commit corrects the driver to read from the correct locations depending on the version of the GENET MAC. Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file") Signed-off-by: Doug Berger <opendmb(a)gmail.com> Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/broadcom/genet/bcmgenet.c | 60 ++++++++++++++++++++++--- drivers/net/ethernet/broadcom/genet/bcmgenet.h | 10 ++-- 2 files changed, 60 insertions(+), 10 deletions(-) --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c @@ -1,7 +1,7 @@ /* * Broadcom GENET (Gigabit Ethernet) controller driver * - * Copyright (c) 2014 Broadcom Corporation + * Copyright (c) 2014-2017 Broadcom * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -778,8 +778,9 @@ static const struct bcmgenet_stats bcmge STAT_GENET_RUNT("rx_runt_bytes", mib.rx_runt_bytes), /* Misc UniMAC counters */ STAT_GENET_MISC("rbuf_ovflow_cnt", mib.rbuf_ovflow_cnt, - UMAC_RBUF_OVFL_CNT), - STAT_GENET_MISC("rbuf_err_cnt", mib.rbuf_err_cnt, UMAC_RBUF_ERR_CNT), + UMAC_RBUF_OVFL_CNT_V1), + STAT_GENET_MISC("rbuf_err_cnt", mib.rbuf_err_cnt, + UMAC_RBUF_ERR_CNT_V1), STAT_GENET_MISC("mdf_err_cnt", mib.mdf_err_cnt, UMAC_MDF_ERR_CNT), STAT_GENET_SOFT_MIB("alloc_rx_buff_failed", mib.alloc_rx_buff_failed), STAT_GENET_SOFT_MIB("rx_dma_failed", mib.rx_dma_failed), @@ -821,6 +822,45 @@ static void bcmgenet_get_strings(struct } } +static u32 bcmgenet_update_stat_misc(struct bcmgenet_priv *priv, u16 offset) +{ + u16 new_offset; + u32 val; + + switch (offset) { + case UMAC_RBUF_OVFL_CNT_V1: + if (GENET_IS_V2(priv)) + new_offset = RBUF_OVFL_CNT_V2; + else + new_offset = RBUF_OVFL_CNT_V3PLUS; + + val = bcmgenet_rbuf_readl(priv, new_offset); + /* clear if overflowed */ + if (val == ~0) + bcmgenet_rbuf_writel(priv, 0, new_offset); + break; + case UMAC_RBUF_ERR_CNT_V1: + if (GENET_IS_V2(priv)) + new_offset = RBUF_ERR_CNT_V2; + else + new_offset = RBUF_ERR_CNT_V3PLUS; + + val = bcmgenet_rbuf_readl(priv, new_offset); + /* clear if overflowed */ + if (val == ~0) + bcmgenet_rbuf_writel(priv, 0, new_offset); + break; + default: + val = bcmgenet_umac_readl(priv, offset); + /* clear if overflowed */ + if (val == ~0) + bcmgenet_umac_writel(priv, 0, offset); + break; + } + + return val; +} + static void bcmgenet_update_mib_counters(struct bcmgenet_priv *priv) { int i, j = 0; @@ -845,10 +885,16 @@ static void bcmgenet_update_mib_counters UMAC_MIB_START + j + offset); break; case BCMGENET_STAT_MISC: - val = bcmgenet_umac_readl(priv, s->reg_offset); - /* clear if overflowed */ - if (val == ~0) - bcmgenet_umac_writel(priv, 0, s->reg_offset); + if (GENET_IS_V1(priv)) { + val = bcmgenet_umac_readl(priv, s->reg_offset); + /* clear if overflowed */ + if (val == ~0) + bcmgenet_umac_writel(priv, 0, + s->reg_offset); + } else { + val = bcmgenet_update_stat_misc(priv, + s->reg_offset); + } break; } --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.h +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.h @@ -1,5 +1,5 @@ /* - * Copyright (c) 2014 Broadcom Corporation + * Copyright (c) 2014-2017 Broadcom * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -214,7 +214,9 @@ struct bcmgenet_mib_counters { #define MDIO_REG_SHIFT 16 #define MDIO_REG_MASK 0x1F -#define UMAC_RBUF_OVFL_CNT 0x61C +#define UMAC_RBUF_OVFL_CNT_V1 0x61C +#define RBUF_OVFL_CNT_V2 0x80 +#define RBUF_OVFL_CNT_V3PLUS 0x94 #define UMAC_MPD_CTRL 0x620 #define MPD_EN (1 << 0) @@ -224,7 +226,9 @@ struct bcmgenet_mib_counters { #define UMAC_MPD_PW_MS 0x624 #define UMAC_MPD_PW_LS 0x628 -#define UMAC_RBUF_ERR_CNT 0x634 +#define UMAC_RBUF_ERR_CNT_V1 0x634 +#define RBUF_ERR_CNT_V2 0x84 +#define RBUF_ERR_CNT_V3PLUS 0x98 #define UMAC_MDF_ERR_CNT 0x638 #define UMAC_MDF_CTRL 0x650 #define UMAC_MDF_ADDR 0x654 Patches currently in stable-queue which might be from opendmb(a)gmail.com are queue-4.4/net-bcmgenet-correct-the-rbuf_ovfl_cnt-and-rbuf_err_cnt-mib-values.patch queue-4.4/net-bcmgenet-correct-mib-access-of-unimac-runt-counters.patch queue-4.4/net-bcmgenet-power-down-internal-phy-if-open-or-resume-fails.patch queue-4.4/net-bcmgenet-reserved-phy-revisions-must-be-checked-first.patch queue-4.4/net-bcmgenet-power-up-the-internal-phy-before-probing-the-mii.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "net: bcmgenet: correct MIB access of UniMAC RUNT counters" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: bcmgenet: correct MIB access of UniMAC RUNT counters to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-bcmgenet-correct-mib-access-of-unimac-runt-counters.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Doug Berger <opendmb(a)gmail.com> Date: Thu, 9 Mar 2017 16:58:44 -0800 Subject: net: bcmgenet: correct MIB access of UniMAC RUNT counters From: Doug Berger <opendmb(a)gmail.com> [ Upstream commit 1ad3d225e5a40ca6c586989b4baaca710544c15a ] The gap between the Tx status counters and the Rx RUNT counters is now being added to allow correct reporting of the registers. Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file") Signed-off-by: Doug Berger <opendmb(a)gmail.com> Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/broadcom/genet/bcmgenet.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c @@ -876,13 +876,16 @@ static void bcmgenet_update_mib_counters case BCMGENET_STAT_NETDEV: case BCMGENET_STAT_SOFT: continue; - case BCMGENET_STAT_MIB_RX: - case BCMGENET_STAT_MIB_TX: case BCMGENET_STAT_RUNT: - if (s->type != BCMGENET_STAT_MIB_RX) - offset = BCMGENET_STAT_OFFSET; + offset += BCMGENET_STAT_OFFSET; + /* fall through */ + case BCMGENET_STAT_MIB_TX: + offset += BCMGENET_STAT_OFFSET; + /* fall through */ + case BCMGENET_STAT_MIB_RX: val = bcmgenet_umac_readl(priv, UMAC_MIB_START + j + offset); + offset = 0; /* Reset Offset */ break; case BCMGENET_STAT_MISC: if (GENET_IS_V1(priv)) { Patches currently in stable-queue which might be from opendmb(a)gmail.com are queue-4.4/net-bcmgenet-correct-the-rbuf_ovfl_cnt-and-rbuf_err_cnt-mib-values.patch queue-4.4/net-bcmgenet-correct-mib-access-of-unimac-runt-counters.patch queue-4.4/net-bcmgenet-power-down-internal-phy-if-open-or-resume-fails.patch queue-4.4/net-bcmgenet-reserved-phy-revisions-must-be-checked-first.patch queue-4.4/net-bcmgenet-power-up-the-internal-phy-before-probing-the-mii.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "mmc: mediatek: Fixed bug where clock frequency could be set wrong" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mmc: mediatek: Fixed bug where clock frequency could be set wrong to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mmc-mediatek-fixed-bug-where-clock-frequency-could-be-set-wrong.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: yong mao <yong.mao(a)mediatek.com> Date: Sat, 4 Mar 2017 15:10:03 +0800 Subject: mmc: mediatek: Fixed bug where clock frequency could be set wrong From: yong mao <yong.mao(a)mediatek.com> [ Upstream commit 40ceda09c8c84694c2ca6b00bcc6dc71e8e62d96 ] This patch can fix two issues: Issue 1: In previous code, div may be overflow when setting clock frequency as f_min. We can use DIV_ROUND_UP to fix this boundary related issue. Issue 2: In previous code, we can not set the correct clock frequency when div equals 0xff. Signed-off-by: Yong Mao <yong.mao(a)mediatek.com> Signed-off-by: Chaotian Jing <chaotian.jing(a)mediatek.com> Reviewed-by: Daniel Kurtz <djkurtz(a)chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mmc/host/mtk-sd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/mmc/host/mtk-sd.c +++ b/drivers/mmc/host/mtk-sd.c @@ -570,7 +570,7 @@ static void msdc_set_mclk(struct msdc_ho } } sdr_set_field(host->base + MSDC_CFG, MSDC_CFG_CKMOD | MSDC_CFG_CKDIV, - (mode << 8) | (div % 0xff)); + (mode << 8) | div); sdr_set_bits(host->base + MSDC_CFG, MSDC_CFG_CKPDN); while (!(readl(host->base + MSDC_CFG) & MSDC_CFG_CKSTB)) cpu_relax(); @@ -1540,7 +1540,7 @@ static int msdc_drv_probe(struct platfor host->src_clk_freq = clk_get_rate(host->src_clk); /* Set host parameters to mmc */ mmc->ops = &mt_msdc_ops; - mmc->f_min = host->src_clk_freq / (4 * 255); + mmc->f_min = DIV_ROUND_UP(host->src_clk_freq, 4 * 255); mmc->caps |= MMC_CAP_ERASE | MMC_CAP_CMD23; mmc->caps |= MMC_CAP_RUNTIME_RESUME; Patches currently in stable-queue which might be from yong.mao(a)mediatek.com are queue-4.4/mmc-mediatek-fixed-bug-where-clock-frequency-could-be-set-wrong.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "mm: Handle 0 flags in _calc_vm_trans() macro" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mm: Handle 0 flags in _calc_vm_trans() macro to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mm-handle-0-flags-in-_calc_vm_trans-macro.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Jan Kara <jack(a)suse.cz> Date: Fri, 3 Nov 2017 12:21:21 +0100 Subject: mm: Handle 0 flags in _calc_vm_trans() macro From: Jan Kara <jack(a)suse.cz> [ Upstream commit 592e254502041f953e84d091eae2c68cba04c10b ] _calc_vm_trans() does not handle the situation when some of the passed flags are 0 (which can happen if these VM flags do not make sense for the architecture). Improve the _calc_vm_trans() macro to return 0 in such situation. Since all passed flags are constant, this does not add any runtime overhead. Signed-off-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/mman.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/include/linux/mman.h +++ b/include/linux/mman.h @@ -63,8 +63,9 @@ static inline int arch_validate_prot(uns * ("bit1" and "bit2" must be single bits) */ #define _calc_vm_trans(x, bit1, bit2) \ + ((!(bit1) || !(bit2)) ? 0 : \ ((bit1) <= (bit2) ? ((x) & (bit1)) * ((bit2) / (bit1)) \ - : ((x) & (bit1)) / ((bit1) / (bit2))) + : ((x) & (bit1)) / ((bit1) / (bit2)))) /* * Combine the mmap "prot" argument into "vm_flags" used internally. Patches currently in stable-queue which might be from jack(a)suse.cz are queue-4.4/writeback-fix-memory-leak-in-wb_queue_work.patch queue-4.4/mm-handle-0-flags-in-_calc_vm_trans-macro.patch queue-4.4/udf-avoid-overflow-when-session-starts-at-large-offset.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "mlxsw: reg: Fix SPVMLR max record count" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mlxsw: reg: Fix SPVMLR max record count to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mlxsw-reg-fix-spvmlr-max-record-count.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Jiri Pirko <jiri(a)mellanox.com> Date: Tue, 14 Mar 2017 14:00:01 +0100 Subject: mlxsw: reg: Fix SPVMLR max record count From: Jiri Pirko <jiri(a)mellanox.com> [ Upstream commit e9093b1183bbac462d2caef3eac165778c0b1bf1 ] The num_rec field is 8 bit, so the maximal count number is 255. This fixes vlans learning not being enabled for wider ranges than 255. Fixes: a4feea74cd7a ("mlxsw: reg: Add Switch Port VLAN MAC Learning register definition") Signed-off-by: Jiri Pirko <jiri(a)mellanox.com> Reviewed-by: Ido Schimmel <idosch(a)mellanox.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/mellanox/mlxsw/reg.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/mellanox/mlxsw/reg.h +++ b/drivers/net/ethernet/mellanox/mlxsw/reg.h @@ -1139,7 +1139,7 @@ static inline void mlxsw_reg_sfmr_pack(c #define MLXSW_REG_SPVMLR_ID 0x2020 #define MLXSW_REG_SPVMLR_BASE_LEN 0x04 /* base length, without records */ #define MLXSW_REG_SPVMLR_REC_LEN 0x04 /* record length */ -#define MLXSW_REG_SPVMLR_REC_MAX_COUNT 256 +#define MLXSW_REG_SPVMLR_REC_MAX_COUNT 255 #define MLXSW_REG_SPVMLR_LEN (MLXSW_REG_SPVMLR_BASE_LEN + \ MLXSW_REG_SPVMLR_REC_LEN * \ MLXSW_REG_SPVMLR_REC_MAX_COUNT) Patches currently in stable-queue which might be from jiri(a)mellanox.com are queue-4.4/mlxsw-reg-fix-spvmlr-max-record-count.patch queue-4.4/mlxsw-reg-fix-spvm-max-record-count.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "mlxsw: reg: Fix SPVM max record count" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mlxsw: reg: Fix SPVM max record count to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mlxsw-reg-fix-spvm-max-record-count.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Jiri Pirko <jiri(a)mellanox.com> Date: Tue, 14 Mar 2017 14:00:00 +0100 Subject: mlxsw: reg: Fix SPVM max record count From: Jiri Pirko <jiri(a)mellanox.com> [ Upstream commit f004ec065b4879d6bc9ba0211af2169b3ce3097f ] The num_rec field is 8 bit, so the maximal count number is 255. This fixes vlans not being enabled for wider ranges than 255. Fixes: b2e345f9a454 ("mlxsw: reg: Add Switch Port VID and Switch Port VLAN Membership registers definitions") Signed-off-by: Jiri Pirko <jiri(a)mellanox.com> Reviewed-by: Ido Schimmel <idosch(a)mellanox.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/mellanox/mlxsw/reg.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/mellanox/mlxsw/reg.h +++ b/drivers/net/ethernet/mellanox/mlxsw/reg.h @@ -599,7 +599,7 @@ static inline void mlxsw_reg_spvid_pack( #define MLXSW_REG_SPVM_ID 0x200F #define MLXSW_REG_SPVM_BASE_LEN 0x04 /* base length, without records */ #define MLXSW_REG_SPVM_REC_LEN 0x04 /* record length */ -#define MLXSW_REG_SPVM_REC_MAX_COUNT 256 +#define MLXSW_REG_SPVM_REC_MAX_COUNT 255 #define MLXSW_REG_SPVM_LEN (MLXSW_REG_SPVM_BASE_LEN + \ MLXSW_REG_SPVM_REC_LEN * MLXSW_REG_SPVM_REC_MAX_COUNT) Patches currently in stable-queue which might be from jiri(a)mellanox.com are queue-4.4/mlxsw-reg-fix-spvmlr-max-record-count.patch queue-4.4/mlxsw-reg-fix-spvm-max-record-count.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "md-cluster: free md_cluster_info if node leave cluster" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled md-cluster: free md_cluster_info if node leave cluster to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: md-cluster-free-md_cluster_info-if-node-leave-cluster.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Guoqing Jiang <gqjiang(a)suse.com> Date: Fri, 24 Feb 2017 11:15:12 +0800 Subject: md-cluster: free md_cluster_info if node leave cluster From: Guoqing Jiang <gqjiang(a)suse.com> [ Upstream commit 9c8043f337f14d1743006dfc59c03e80a42e3884 ] To avoid memory leak, we need to free the cinfo which is allocated when node join cluster. Reviewed-by: NeilBrown <neilb(a)suse.com> Signed-off-by: Guoqing Jiang <gqjiang(a)suse.com> Signed-off-by: Shaohua Li <shli(a)fb.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/md-cluster.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/md/md-cluster.c +++ b/drivers/md/md-cluster.c @@ -821,6 +821,7 @@ static int leave(struct mddev *mddev) lockres_free(cinfo->no_new_dev_lockres); lockres_free(cinfo->bitmap_lockres); dlm_release_lockspace(cinfo->lockspace, 2); + kfree(cinfo); return 0; } Patches currently in stable-queue which might be from gqjiang(a)suse.com are queue-4.4/md-cluster-free-md_cluster_info-if-node-leave-cluster.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "macvlan: Only deliver one copy of the frame to the macvlan interface" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled macvlan: Only deliver one copy of the frame to the macvlan interface to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: macvlan-only-deliver-one-copy-of-the-frame-to-the-macvlan-interface.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Alexander Duyck <alexander.h.duyck(a)intel.com> Date: Fri, 13 Oct 2017 13:40:24 -0700 Subject: macvlan: Only deliver one copy of the frame to the macvlan interface From: Alexander Duyck <alexander.h.duyck(a)intel.com> [ Upstream commit dd6b9c2c332b40f142740d1b11fb77c653ff98ea ] This patch intoduces a slight adjustment for macvlan to address the fact that in source mode I was seeing two copies of any packet addressed to the macvlan interface being delivered where there should have been only one. The issue appears to be that one copy was delivered based on the source MAC address and then the second copy was being delivered based on the destination MAC address. To fix it I am just treating a unicast address match as though it is not a match since source based macvlan isn't supposed to be matching based on the destination MAC anyway. Fixes: 79cf79abce71 ("macvlan: add source mode") Signed-off-by: Alexander Duyck <alexander.h.duyck(a)intel.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/macvlan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/macvlan.c +++ b/drivers/net/macvlan.c @@ -441,7 +441,7 @@ static rx_handler_result_t macvlan_handl struct macvlan_dev, list); else vlan = macvlan_hash_lookup(port, eth->h_dest); - if (vlan == NULL) + if (!vlan || vlan->mode == MACVLAN_MODE_SOURCE) return RX_HANDLER_PASS; dev = vlan->dev; Patches currently in stable-queue which might be from alexander.h.duyck(a)intel.com are queue-4.4/macvlan-only-deliver-one-copy-of-the-frame-to-the-macvlan-interface.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "l2tp: cleanup l2tp_tunnel_delete calls" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled l2tp: cleanup l2tp_tunnel_delete calls to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: l2tp-cleanup-l2tp_tunnel_delete-calls.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Jiri Slaby <jslaby(a)suse.cz> Date: Wed, 25 Oct 2017 15:57:55 +0200 Subject: l2tp: cleanup l2tp_tunnel_delete calls From: Jiri Slaby <jslaby(a)suse.cz> [ Upstream commit 4dc12ffeaeac939097a3f55c881d3dc3523dff0c ] l2tp_tunnel_delete does not return anything since commit 62b982eeb458 ("l2tp: fix race condition in l2tp_tunnel_delete"). But call sites of l2tp_tunnel_delete still do casts to void to avoid unused return value warnings. Kill these now useless casts. Signed-off-by: Jiri Slaby <jslaby(a)suse.cz> Cc: Sabrina Dubroca <sd(a)queasysnail.net> Cc: Guillaume Nault <g.nault(a)alphalink.fr> Cc: David S. Miller <davem(a)davemloft.net> Cc: netdev(a)vger.kernel.org Acked-by: Guillaume Nault <g.nault(a)alphalink.fr> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/l2tp/l2tp_core.c | 2 +- net/l2tp/l2tp_netlink.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- a/net/l2tp/l2tp_core.c +++ b/net/l2tp/l2tp_core.c @@ -1856,7 +1856,7 @@ static __net_exit void l2tp_exit_net(str rcu_read_lock_bh(); list_for_each_entry_rcu(tunnel, &pn->l2tp_tunnel_list, list) { - (void)l2tp_tunnel_delete(tunnel); + l2tp_tunnel_delete(tunnel); } rcu_read_unlock_bh(); } --- a/net/l2tp/l2tp_netlink.c +++ b/net/l2tp/l2tp_netlink.c @@ -285,7 +285,7 @@ static int l2tp_nl_cmd_tunnel_delete(str l2tp_tunnel_notify(&l2tp_nl_family, info, tunnel, L2TP_CMD_TUNNEL_DELETE); - (void) l2tp_tunnel_delete(tunnel); + l2tp_tunnel_delete(tunnel); out: return ret; Patches currently in stable-queue which might be from jslaby(a)suse.cz are queue-4.4/l2tp-cleanup-l2tp_tunnel_delete-calls.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "iscsi-target: fix memory leak in lio_target_tiqn_addtpg()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iscsi-target: fix memory leak in lio_target_tiqn_addtpg() to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: iscsi-target-fix-memory-leak-in-lio_target_tiqn_addtpg.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: tangwenji <tang.wenji(a)zte.com.cn> Date: Fri, 15 Sep 2017 16:03:13 +0800 Subject: iscsi-target: fix memory leak in lio_target_tiqn_addtpg() From: tangwenji <tang.wenji(a)zte.com.cn> [ Upstream commit 12d5a43b2dffb6cd28062b4e19024f7982393288 ] tpg must free when call core_tpg_register() return fail Signed-off-by: tangwenji <tang.wenji(a)zte.com.cn> Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/iscsi/iscsi_target_configfs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/target/iscsi/iscsi_target_configfs.c +++ b/drivers/target/iscsi/iscsi_target_configfs.c @@ -1210,7 +1210,7 @@ static struct se_portal_group *lio_targe ret = core_tpg_register(wwn, &tpg->tpg_se_tpg, SCSI_PROTOCOL_ISCSI); if (ret < 0) - return NULL; + goto free_out; ret = iscsit_tpg_add_portal_group(tiqn, tpg); if (ret != 0) @@ -1222,6 +1222,7 @@ static struct se_portal_group *lio_targe return &tpg->tpg_se_tpg; out: core_tpg_deregister(&tpg->tpg_se_tpg); +free_out: kfree(tpg); return NULL; } Patches currently in stable-queue which might be from tang.wenji(a)zte.com.cn are queue-4.4/target-fix-condition-return-in-core_pr_dump_initiator_port.patch queue-4.4/iscsi-target-fix-memory-leak-in-lio_target_tiqn_addtpg.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "intel_th: pci: Add Gemini Lake support" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled intel_th: pci: Add Gemini Lake support to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: intel_th-pci-add-gemini-lake-support.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Date: Thu, 30 Jun 2016 16:10:51 +0300 Subject: intel_th: pci: Add Gemini Lake support From: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> [ Upstream commit 340837f985c2cb87ca0868d4aa9ce42b0fab3a21 ] This adds Intel(R) Trace Hub PCI ID for Gemini Lake SOC. Signed-off-by: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hwtracing/intel_th/pci.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/hwtracing/intel_th/pci.c +++ b/drivers/hwtracing/intel_th/pci.c @@ -82,6 +82,11 @@ static const struct pci_device_id intel_ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x9da6), .driver_data = (kernel_ulong_t)0, }, + { + /* Gemini Lake */ + PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x318e), + .driver_data = (kernel_ulong_t)0, + }, { 0 }, }; Patches currently in stable-queue which might be from alexander.shishkin(a)linux.intel.com are queue-4.4/intel_th-pci-add-gemini-lake-support.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "Input: i8042 - add TUXEDO BU1406 (N24_25BU) to the nomux list" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Input: i8042 - add TUXEDO BU1406 (N24_25BU) to the nomux list to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: input-i8042-add-tuxedo-bu1406-n24_25bu-to-the-nomux-list.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Date: Tue, 28 Feb 2017 17:14:41 -0800 Subject: Input: i8042 - add TUXEDO BU1406 (N24_25BU) to the nomux list From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> [ Upstream commit a4c2a13129f7c5bcf81704c06851601593303fd5 ] TUXEDO BU1406 does not implement active multiplexing mode properly, and takes around 550 ms in i8042_set_mux_mode(). Given that the device does not have external AUX port, there is no downside in disabling the MUX mode. Reported-by: Paul Menzel <pmenzel(a)molgen.mpg.de> Suggested-by: Vojtech Pavlik <vojtech(a)suse.cz> Reviewed-by: Marcos Paulo de Souza <marcos.souza.org(a)gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/input/serio/i8042-x86ia64io.h | 7 +++++++ 1 file changed, 7 insertions(+) --- a/drivers/input/serio/i8042-x86ia64io.h +++ b/drivers/input/serio/i8042-x86ia64io.h @@ -520,6 +520,13 @@ static const struct dmi_system_id __init DMI_MATCH(DMI_PRODUCT_NAME, "IC4I"), }, }, + { + /* TUXEDO BU1406 */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Notebook"), + DMI_MATCH(DMI_PRODUCT_NAME, "N24_25BU"), + }, + }, { } }; Patches currently in stable-queue which might be from dmitry.torokhov(a)gmail.com are queue-4.4/input-i8042-add-tuxedo-bu1406-n24_25bu-to-the-nomux-list.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "IB/ipoib: Grab rtnl lock on heavy flush when calling ndo_open/stop" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/ipoib: Grab rtnl lock on heavy flush when calling ndo_open/stop to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-ipoib-grab-rtnl-lock-on-heavy-flush-when-calling-ndo_open-stop.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Alex Vesker <valex(a)mellanox.com> Date: Tue, 10 Oct 2017 10:36:41 +0300 Subject: IB/ipoib: Grab rtnl lock on heavy flush when calling ndo_open/stop From: Alex Vesker <valex(a)mellanox.com> [ Upstream commit b4b678b06f6eef18bff44a338c01870234db0bc9 ] When ndo_open and ndo_stop are called RTNL lock should be held. In this specific case ipoib_ib_dev_open calls the offloaded ndo_open which re-sets the number of TX queue assuming RTNL lock is held. Since RTNL lock is not held, RTNL assert will fail. Signed-off-by: Alex Vesker <valex(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/ulp/ipoib/ipoib_ib.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) --- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c +++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c @@ -1044,10 +1044,15 @@ static void __ipoib_ib_dev_flush(struct ipoib_ib_dev_down(dev); if (level == IPOIB_FLUSH_HEAVY) { + rtnl_lock(); if (test_bit(IPOIB_FLAG_INITIALIZED, &priv->flags)) ipoib_ib_dev_stop(dev); - if (ipoib_ib_dev_open(dev) != 0) + + result = ipoib_ib_dev_open(dev); + rtnl_unlock(); + if (result) return; + if (netif_queue_stopped(dev)) netif_start_queue(dev); } Patches currently in stable-queue which might be from valex(a)mellanox.com are queue-4.4/ib-ipoib-grab-rtnl-lock-on-heavy-flush-when-calling-ndo_open-stop.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "GFS2: Take inode off order_write list when setting jdata flag" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled GFS2: Take inode off order_write list when setting jdata flag to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: gfs2-take-inode-off-order_write-list-when-setting-jdata-flag.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Bob Peterson <rpeterso(a)redhat.com> Date: Wed, 20 Sep 2017 08:30:04 -0500 Subject: GFS2: Take inode off order_write list when setting jdata flag From: Bob Peterson <rpeterso(a)redhat.com> [ Upstream commit cc555b09d8c3817aeebda43a14ab67049a5653f7 ] This patch fixes a deadlock caused when the jdata flag is set for inodes that are already on the ordered write list. Since it is on the ordered write list, log_flush calls gfs2_ordered_write which calls filemap_fdatawrite. But since the inode had the jdata flag set, that calls gfs2_jdata_writepages, which tries to start a new transaction. A new transaction cannot be started because it tries to acquire the log_flush rwsem which is already locked by the log flush operation. The bottom line is: We cannot switch an inode from ordered to jdata until we eliminate any ordered data pages (via log flush) or any log_flush operation afterward will create the circular dependency above. So we need to flush the log before setting the diskflags to switch the file mode, then we need to remove the inode from the ordered writes list. Before this patch, the log flush was done for jdata->ordered, but that's wrong. If we're going from jdata to ordered, we don't need to call gfs2_log_flush because the call to filemap_fdatawrite will do it for us: filemap_fdatawrite() -> __filemap_fdatawrite_range() __filemap_fdatawrite_range() -> do_writepages() do_writepages() -> gfs2_jdata_writepages() gfs2_jdata_writepages() -> gfs2_log_flush() This patch modifies function do_gfs2_set_flags so that if a file has its jdata flag set, and it's already on the ordered write list, the log will be flushed and it will be removed from the list before setting the flag. Signed-off-by: Bob Peterson <rpeterso(a)redhat.com> Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com> Acked-by: Abhijith Das <adas(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/gfs2/file.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/fs/gfs2/file.c +++ b/fs/gfs2/file.c @@ -255,7 +255,7 @@ static int do_gfs2_set_flags(struct file goto out; } if ((flags ^ new_flags) & GFS2_DIF_JDATA) { - if (flags & GFS2_DIF_JDATA) + if (new_flags & GFS2_DIF_JDATA) gfs2_log_flush(sdp, ip->i_gl, NORMAL_FLUSH); error = filemap_fdatawrite(inode->i_mapping); if (error) @@ -263,6 +263,8 @@ static int do_gfs2_set_flags(struct file error = filemap_fdatawait(inode->i_mapping); if (error) goto out; + if (new_flags & GFS2_DIF_JDATA) + gfs2_ordered_del_inode(ip); } error = gfs2_trans_begin(sdp, RES_DINODE, 0); if (error) Patches currently in stable-queue which might be from rpeterso(a)redhat.com are queue-4.4/gfs2-take-inode-off-order_write-list-when-setting-jdata-flag.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "fjes: Fix wrong netdevice feature flags" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled fjes: Fix wrong netdevice feature flags to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: fjes-fix-wrong-netdevice-feature-flags.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Taku Izumi <izumi.taku(a)jp.fujitsu.com> Date: Wed, 15 Mar 2017 13:47:50 +0900 Subject: fjes: Fix wrong netdevice feature flags From: Taku Izumi <izumi.taku(a)jp.fujitsu.com> [ Upstream commit fe8daf5fa715f7214952f06a387e4b7de818c5be ] This patch fixes netdev->features for Extended Socket network device. Currently Extended Socket network device's netdev->feature claims NETIF_F_HW_CSUM, however this is completely wrong. There's no feature of checksum offloading. That causes invalid TCP/UDP checksum and packet rejection when IP forwarding from Extended Socket network device to other network device. NETIF_F_HW_CSUM should be omitted. Signed-off-by: Taku Izumi <izumi.taku(a)jp.fujitsu.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/fjes/fjes_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/fjes/fjes_main.c +++ b/drivers/net/fjes/fjes_main.c @@ -1205,7 +1205,7 @@ static void fjes_netdev_setup(struct net fjes_set_ethtool_ops(netdev); netdev->mtu = fjes_support_mtu[0]; netdev->flags |= IFF_BROADCAST; - netdev->features |= NETIF_F_HW_CSUM | NETIF_F_HW_VLAN_CTAG_FILTER; + netdev->features |= NETIF_F_HW_VLAN_CTAG_FILTER; } static void fjes_irq_watch_task(struct work_struct *work) Patches currently in stable-queue which might be from izumi.taku(a)jp.fujitsu.com are queue-4.4/fjes-fix-wrong-netdevice-feature-flags.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "fbdev: controlfb: Add missing modes to fix out of bounds access" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled fbdev: controlfb: Add missing modes to fix out of bounds access to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: fbdev-controlfb-add-missing-modes-to-fix-out-of-bounds-access.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Geert Uytterhoeven <geert(a)linux-m68k.org> Date: Thu, 9 Nov 2017 18:09:33 +0100 Subject: fbdev: controlfb: Add missing modes to fix out of bounds access From: Geert Uytterhoeven <geert(a)linux-m68k.org> [ Upstream commit ac831a379d34109451b3c41a44a20ee10ecb615f ] Dan's static analysis says: drivers/video/fbdev/controlfb.c:560 control_setup() error: buffer overflow 'control_mac_modes' 20 <= 21 Indeed, control_mac_modes[] has only 20 elements, while VMODE_MAX is 22, which may lead to an out of bounds read when parsing vmode commandline options. The bug was introduced in v2.4.5.6, when 2 new modes were added to macmodes.h, but control_mac_modes[] wasn't updated: https://kernel.opensuse.org/cgit/kernel/diff/include/video/macmodes.h?h=v2.… Augment control_mac_modes[] with the two new video modes to fix this. Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Cc: Dan Carpenter <dan.carpenter(a)oracle.com> Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/fbdev/controlfb.h | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/video/fbdev/controlfb.h +++ b/drivers/video/fbdev/controlfb.h @@ -141,5 +141,7 @@ static struct max_cmodes control_mac_mod {{ 1, 2}}, /* 1152x870, 75Hz */ {{ 0, 1}}, /* 1280x960, 75Hz */ {{ 0, 1}}, /* 1280x1024, 75Hz */ + {{ 1, 2}}, /* 1152x768, 60Hz */ + {{ 0, 1}}, /* 1600x1024, 60Hz */ }; Patches currently in stable-queue which might be from geert(a)linux-m68k.org are queue-4.4/fbdev-controlfb-add-missing-modes-to-fix-out-of-bounds-access.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "efi/esrt: Cleanup bad memory map log messages" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled efi/esrt: Cleanup bad memory map log messages to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: efi-esrt-cleanup-bad-memory-map-log-messages.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Daniel Drake <drake(a)endlessm.com> Date: Tue, 7 Feb 2017 13:08:23 -0600 Subject: efi/esrt: Cleanup bad memory map log messages From: Daniel Drake <drake(a)endlessm.com> [ Upstream commit 822f5845f710e57d7e2df1fd1ee00d6e19d334fe ] The Intel Compute Stick STCK1A8LFC and Weibu F3C platforms both log 2 error messages during boot: efi: requested map not found. esrt: ESRT header is not in the memory map. Searching the web, this seems to affect many other platforms too. Since these messages are logged as errors, they appear on-screen during the boot process even when using the "quiet" boot parameter used by distros. Demote the ESRT error to a warning so that it does not appear on-screen, and delete the error logging from efi_mem_desc_lookup; both callsites of that function log more specific messages upon failure. Out of curiosity I looked closer at the Weibu F3C. There is no entry in the UEFI-provided memory map which corresponds to the ESRT pointer, but hacking the code to map it anyway, the ESRT does appear to be valid with 2 entries. Signed-off-by: Daniel Drake <drake(a)endlessm.com> Cc: Matt Fleming <matt(a)codeblueprint.co.uk> Acked-by: Peter Jones <pjones(a)redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/firmware/efi/efi.c | 1 - drivers/firmware/efi/esrt.c | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) --- a/drivers/firmware/efi/efi.c +++ b/drivers/firmware/efi/efi.c @@ -310,7 +310,6 @@ int __init efi_mem_desc_lookup(u64 phys_ early_memunmap(md, sizeof (*md)); } - pr_err_once("requested map not found.\n"); return -ENOENT; } --- a/drivers/firmware/efi/esrt.c +++ b/drivers/firmware/efi/esrt.c @@ -253,7 +253,7 @@ void __init efi_esrt_init(void) rc = efi_mem_desc_lookup(efi.esrt, &md); if (rc < 0) { - pr_err("ESRT header is not in the memory map.\n"); + pr_warn("ESRT header is not in the memory map.\n"); return; } Patches currently in stable-queue which might be from drake(a)endlessm.com are queue-4.4/efi-esrt-cleanup-bad-memory-map-log-messages.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/radeon/si: add dpm quirk for Oland" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/radeon/si: add dpm quirk for Oland to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-radeon-si-add-dpm-quirk-for-oland.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Alex Deucher <alexander.deucher(a)amd.com> Date: Tue, 14 Mar 2017 14:42:03 -0400 Subject: drm/radeon/si: add dpm quirk for Oland From: Alex Deucher <alexander.deucher(a)amd.com> [ Upstream commit 0f424de1fd9bc4ab24bd1fe5430ab5618e803e31 ] OLAND 0x1002:0x6604 0x1028:0x066F 0x00 seems to have problems with higher sclks. Acked-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/radeon/si_dpm.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/gpu/drm/radeon/si_dpm.c +++ b/drivers/gpu/drm/radeon/si_dpm.c @@ -3029,6 +3029,12 @@ static void si_apply_state_adjust_rules( max_sclk = 75000; max_mclk = 80000; } + } else if (rdev->family == CHIP_OLAND) { + if ((rdev->pdev->device == 0x6604) && + (rdev->pdev->subsystem_vendor == 0x1028) && + (rdev->pdev->subsystem_device == 0x066F)) { + max_sclk = 75000; + } } /* Apply dpm quirks */ while (p && p->chip_device != 0) { Patches currently in stable-queue which might be from alexander.deucher(a)amd.com are queue-4.4/drm-radeon-reinstate-oland-workaround-for-sclk.patch queue-4.4/drm-radeon-si-add-dpm-quirk-for-oland.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/radeon: reinstate oland workaround for sclk" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/radeon: reinstate oland workaround for sclk to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-radeon-reinstate-oland-workaround-for-sclk.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Alex Deucher <alexander.deucher(a)amd.com> Date: Wed, 15 Mar 2017 21:11:46 -0400 Subject: drm/radeon: reinstate oland workaround for sclk From: Alex Deucher <alexander.deucher(a)amd.com> [ Upstream commit 66822d815ae61ecb2d9dba9031517e8a8476969d ] Higher sclks seem to be unstable on some boards. bug: https://bugs.freedesktop.org/show_bug.cgi?id=100222 Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/radeon/si_dpm.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) --- a/drivers/gpu/drm/radeon/si_dpm.c +++ b/drivers/gpu/drm/radeon/si_dpm.c @@ -3030,9 +3030,13 @@ static void si_apply_state_adjust_rules( max_mclk = 80000; } } else if (rdev->family == CHIP_OLAND) { - if ((rdev->pdev->device == 0x6604) && - (rdev->pdev->subsystem_vendor == 0x1028) && - (rdev->pdev->subsystem_device == 0x066F)) { + if ((rdev->pdev->revision == 0xC7) || + (rdev->pdev->revision == 0x80) || + (rdev->pdev->revision == 0x81) || + (rdev->pdev->revision == 0x83) || + (rdev->pdev->revision == 0x87) || + (rdev->pdev->device == 0x6604) || + (rdev->pdev->device == 0x6605)) { max_sclk = 75000; } } Patches currently in stable-queue which might be from alexander.deucher(a)amd.com are queue-4.4/drm-radeon-reinstate-oland-workaround-for-sclk.patch queue-4.4/drm-radeon-si-add-dpm-quirk-for-oland.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/omap: fix dmabuf mmap for dma_alloc'ed buffers" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/omap: fix dmabuf mmap for dma_alloc'ed buffers to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-omap-fix-dmabuf-mmap-for-dma_alloc-ed-buffers.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Date: Tue, 28 Feb 2017 10:11:45 +0200 Subject: drm/omap: fix dmabuf mmap for dma_alloc'ed buffers From: Tomi Valkeinen <tomi.valkeinen(a)ti.com> [ Upstream commit 9fa1d7537242bd580ffa99c4725a0407096aad26 ] omap_gem_dmabuf_mmap() returns an error (with a WARN) when called for a buffer which is allocated with dma_alloc_*(). This prevents dmabuf mmap from working on SoCs without DMM, e.g. AM4 and OMAP3. I could not find any reason for omap_gem_dmabuf_mmap() rejecting such buffers, and just removing the if() fixes the limitation. Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 3 --- 1 file changed, 3 deletions(-) --- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c +++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c @@ -142,9 +142,6 @@ static int omap_gem_dmabuf_mmap(struct d struct drm_gem_object *obj = buffer->priv; int ret = 0; - if (WARN_ON(!obj->filp)) - return -EINVAL; - ret = drm_gem_mmap_obj(obj, omap_gem_mmap_size(obj), vma); if (ret < 0) return ret; Patches currently in stable-queue which might be from tomi.valkeinen(a)ti.com are queue-4.4/drm-omap-fix-dmabuf-mmap-for-dma_alloc-ed-buffers.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "dmaengine: ti-dma-crossbar: Correct am335x/am43xx mux value type" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dmaengine: ti-dma-crossbar: Correct am335x/am43xx mux value type to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dmaengine-ti-dma-crossbar-correct-am335x-am43xx-mux-value-type.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Peter Ujfalusi <peter.ujfalusi(a)ti.com> Date: Wed, 8 Nov 2017 12:02:25 +0200 Subject: dmaengine: ti-dma-crossbar: Correct am335x/am43xx mux value type From: Peter Ujfalusi <peter.ujfalusi(a)ti.com> [ Upstream commit 288e7560e4d3e259aa28f8f58a8dfe63627a1bf6 ] The used 0x1f mask is only valid for am335x family of SoC, different family using this type of crossbar might have different number of electable events. In case of am43xx family 0x3f mask should have been used for example. Instead of trying to handle each family's mask, just use u8 type to store the mux value since the event offsets are aligned to byte offset. Fixes: 42dbdcc6bf965 ("dmaengine: ti-dma-crossbar: Add support for crossbar on AM33xx/AM43xx") Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma/ti-dma-crossbar.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/drivers/dma/ti-dma-crossbar.c +++ b/drivers/dma/ti-dma-crossbar.c @@ -46,12 +46,12 @@ struct ti_am335x_xbar_data { struct ti_am335x_xbar_map { u16 dma_line; - u16 mux_val; + u8 mux_val; }; -static inline void ti_am335x_xbar_write(void __iomem *iomem, int event, u16 val) +static inline void ti_am335x_xbar_write(void __iomem *iomem, int event, u8 val) { - writeb_relaxed(val & 0x1f, iomem + event); + writeb_relaxed(val, iomem + event); } static void ti_am335x_xbar_free(struct device *dev, void *route_data) @@ -102,7 +102,7 @@ static void *ti_am335x_xbar_route_alloca } map->dma_line = (u16)dma_spec->args[0]; - map->mux_val = (u16)dma_spec->args[2]; + map->mux_val = (u8)dma_spec->args[2]; dma_spec->args[2] = 0; dma_spec->args_count = 2; Patches currently in stable-queue which might be from peter.ujfalusi(a)ti.com are queue-4.4/dmaengine-ti-dma-crossbar-correct-am335x-am43xx-mux-value-type.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "dmaengine: rcar-dmac: use TCRB instead of TCR for residue" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dmaengine: rcar-dmac: use TCRB instead of TCR for residue to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dmaengine-rcar-dmac-use-tcrb-instead-of-tcr-for-residue.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com> Date: Thu, 19 Oct 2017 01:15:13 +0000 Subject: dmaengine: rcar-dmac: use TCRB instead of TCR for residue From: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com> [ Upstream commit 847449f23dcbff68234525f90dd53c7c7db18cad ] SYS/RT/Audio DMAC includes independent data buffers for reading and writing. Therefore, the read transfer counter and write transfer counter have different values. TCR indicates read counter, and TCRB indicates write counter. The relationship is like below. TCR TCRB [SOURCE] -> [DMAC] -> [SINK] In the MEM_TO_DEV direction, what really matters is how much data has been written to the device. If the DMA is interrupted between read and write, then, the data doesn't end up in the destination, so shouldn't be counted. TCRB is thus the register we should use in this cases. In the DEV_TO_MEM direction, the situation is more complex. Both the read and write side are important. What matters from a data consumer point of view is how much data has been written to memory. On the other hand, if the transfer is interrupted between read and write, we'll end up losing data. It can also be important to report. In the MEM_TO_MEM direction, what matters is of course how much data has been written to memory from data consumer point of view. Here, because read and write have independent data buffers, it will take a while for TCR and TCRB to become equal. Thus we should check TCRB in this case, too. Thus, all cases we should check TCRB instead of TCR. Without this patch, Sound Capture has noise after PluseAudio support (= 07b7acb51d2 ("ASoC: rsnd: update pointer more accurate")), because the recorder will use wrong residue counter which indicates transferred from sound device, but in reality the data was not yet put to memory and recorder will record it. Signed-off-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com> [Kuninori: added detail information in log] Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma/sh/rcar-dmac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/dma/sh/rcar-dmac.c +++ b/drivers/dma/sh/rcar-dmac.c @@ -1180,7 +1180,7 @@ static unsigned int rcar_dmac_chan_get_r } /* Add the residue for the current chunk. */ - residue += rcar_dmac_chan_read(chan, RCAR_DMATCR) << desc->xfer_shift; + residue += rcar_dmac_chan_read(chan, RCAR_DMATCRB) << desc->xfer_shift; return residue; } Patches currently in stable-queue which might be from hiroyuki.yokoyama.vx(a)renesas.com are queue-4.4/dmaengine-rcar-dmac-use-tcrb-instead-of-tcr-for-residue.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "dmaengine: Fix array index out of bounds warning in __get_unmap_pool()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dmaengine: Fix array index out of bounds warning in __get_unmap_pool() to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dmaengine-fix-array-index-out-of-bounds-warning-in-__get_unmap_pool.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Matthias Kaehlcke <mka(a)chromium.org> Date: Mon, 13 Mar 2017 14:30:29 -0700 Subject: dmaengine: Fix array index out of bounds warning in __get_unmap_pool() From: Matthias Kaehlcke <mka(a)chromium.org> [ Upstream commit 23f963e91fd81f44f6b316b1c24db563354c6be8 ] This fixes the following warning when building with clang and CONFIG_DMA_ENGINE_RAID=n : drivers/dma/dmaengine.c:1102:11: error: array index 2 is past the end of the array (which contains 1 element) [-Werror,-Warray-bounds] return &unmap_pool[2]; ^ ~ drivers/dma/dmaengine.c:1083:1: note: array 'unmap_pool' declared here static struct dmaengine_unmap_pool unmap_pool[] = { ^ drivers/dma/dmaengine.c:1104:11: error: array index 3 is past the end of the array (which contains 1 element) [-Werror,-Warray-bounds] return &unmap_pool[3]; ^ ~ drivers/dma/dmaengine.c:1083:1: note: array 'unmap_pool' declared here static struct dmaengine_unmap_pool unmap_pool[] = { Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org> Reviewed-by: Dan Williams <dan.j.williams(a)intel.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma/dmaengine.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/dma/dmaengine.c +++ b/drivers/dma/dmaengine.c @@ -1023,12 +1023,14 @@ static struct dmaengine_unmap_pool *__ge switch (order) { case 0 ... 1: return &unmap_pool[0]; +#if IS_ENABLED(CONFIG_DMA_ENGINE_RAID) case 2 ... 4: return &unmap_pool[1]; case 5 ... 7: return &unmap_pool[2]; case 8: return &unmap_pool[3]; +#endif default: BUG(); return NULL; Patches currently in stable-queue which might be from mka(a)chromium.org are queue-4.4/bluetooth-btusb-driver-to-enable-the-usb-wakeup-feature.patch queue-4.4/dmaengine-fix-array-index-out-of-bounds-warning-in-__get_unmap_pool.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "crypto: tcrypt - fix buffer lengths in test_aead_speed()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: tcrypt - fix buffer lengths in test_aead_speed() to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: crypto-tcrypt-fix-buffer-lengths-in-test_aead_speed.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Robert Baronescu <robert.baronescu(a)nxp.com> Date: Tue, 10 Oct 2017 13:22:00 +0300 Subject: crypto: tcrypt - fix buffer lengths in test_aead_speed() From: Robert Baronescu <robert.baronescu(a)nxp.com> [ Upstream commit 7aacbfcb331ceff3ac43096d563a1f93ed46e35e ] Fix the way the length of the buffers used for encryption / decryption are computed. For e.g. in case of encryption, input buffer does not contain an authentication tag. Signed-off-by: Robert Baronescu <robert.baronescu(a)nxp.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- crypto/tcrypt.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/crypto/tcrypt.c +++ b/crypto/tcrypt.c @@ -410,7 +410,7 @@ static void test_aead_speed(const char * } sg_init_aead(sg, xbuf, - *b_size + (enc ? authsize : 0)); + *b_size + (enc ? 0 : authsize)); sg_init_aead(sgout, xoutbuf, *b_size + (enc ? authsize : 0)); @@ -418,7 +418,9 @@ static void test_aead_speed(const char * sg_set_buf(&sg[0], assoc, aad_size); sg_set_buf(&sgout[0], assoc, aad_size); - aead_request_set_crypt(req, sg, sgout, *b_size, iv); + aead_request_set_crypt(req, sg, sgout, + *b_size + (enc ? 0 : authsize), + iv); aead_request_set_ad(req, aad_size); if (secs) Patches currently in stable-queue which might be from robert.baronescu(a)nxp.com are queue-4.4/crypto-tcrypt-fix-buffer-lengths-in-test_aead_speed.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "clk: tegra: Fix cclk_lp divisor register" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: tegra: Fix cclk_lp divisor register to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: clk-tegra-fix-cclk_lp-divisor-register.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Michał Mirosław <mirq-linux(a)rere.qmqm.pl> Date: Tue, 19 Sep 2017 04:48:10 +0200 Subject: clk: tegra: Fix cclk_lp divisor register From: Michał Mirosław <mirq-linux(a)rere.qmqm.pl> [ Upstream commit 54eff2264d3e9fd7e3987de1d7eba1d3581c631e ] According to comments in code and common sense, cclk_lp uses its own divisor, not cclk_g's. Fixes: b08e8c0ecc42 ("clk: tegra: add clock support for Tegra30") Signed-off-by: Michał Mirosław <mirq-linux(a)rere.qmqm.pl> Acked-By: Peter De Schrijver <pdeschrijver(a)nvidia.com> Signed-off-by: Thierry Reding <treding(a)nvidia.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/tegra/clk-tegra30.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/clk/tegra/clk-tegra30.c +++ b/drivers/clk/tegra/clk-tegra30.c @@ -1063,7 +1063,7 @@ static void __init tegra30_super_clk_ini * U71 divider of cclk_lp. */ clk = tegra_clk_register_divider("pll_p_out3_cclklp", "pll_p_out3", - clk_base + SUPER_CCLKG_DIVIDER, 0, + clk_base + SUPER_CCLKLP_DIVIDER, 0, TEGRA_DIVIDER_INT, 16, 8, 1, NULL); clk_register_clkdev(clk, "pll_p_out3_cclklp", NULL); Patches currently in stable-queue which might be from mirq-linux(a)rere.qmqm.pl are queue-4.4/clk-tegra-fix-cclk_lp-divisor-register.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "clk: mediatek: add the option for determining PLL source clock" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: mediatek: add the option for determining PLL source clock to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: clk-mediatek-add-the-option-for-determining-pll-source-clock.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Chen Zhong <chen.zhong(a)mediatek.com> Date: Thu, 5 Oct 2017 11:50:23 +0800 Subject: clk: mediatek: add the option for determining PLL source clock From: Chen Zhong <chen.zhong(a)mediatek.com> [ Upstream commit c955bf3998efa3355790a4d8c82874582f1bc727 ] Since the previous setup always sets the PLL using crystal 26MHz, this doesn't always happen in every MediaTek platform. So the patch added flexibility for assigning extra member for determining the PLL source clock. Signed-off-by: Chen Zhong <chen.zhong(a)mediatek.com> Signed-off-by: Sean Wang <sean.wang(a)mediatek.com> Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/mediatek/clk-mtk.h | 1 + drivers/clk/mediatek/clk-pll.c | 5 ++++- 2 files changed, 5 insertions(+), 1 deletion(-) --- a/drivers/clk/mediatek/clk-mtk.h +++ b/drivers/clk/mediatek/clk-mtk.h @@ -174,6 +174,7 @@ struct mtk_pll_data { uint32_t pcw_reg; int pcw_shift; const struct mtk_pll_div_table *div_table; + const char *parent_name; }; void mtk_clk_register_plls(struct device_node *node, --- a/drivers/clk/mediatek/clk-pll.c +++ b/drivers/clk/mediatek/clk-pll.c @@ -302,7 +302,10 @@ static struct clk *mtk_clk_register_pll( init.name = data->name; init.ops = &mtk_pll_ops; - init.parent_names = &parent_name; + if (data->parent_name) + init.parent_names = &data->parent_name; + else + init.parent_names = &parent_name; init.num_parents = 1; clk = clk_register(NULL, &pll->hw); Patches currently in stable-queue which might be from chen.zhong(a)mediatek.com are queue-4.4/clk-mediatek-add-the-option-for-determining-pll-source-clock.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "clk: imx6: refine hdmi_isfr's parent to make HDMI work on i.MX6 SoCs w/o VPU" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: imx6: refine hdmi_isfr's parent to make HDMI work on i.MX6 SoCs w/o VPU to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: clk-imx6-refine-hdmi_isfr-s-parent-to-make-hdmi-work-on-i.mx6-socs-w-o-vpu.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Sébastien Szymanski <sebastien.szymanski(a)armadeus.com> Date: Tue, 1 Aug 2017 12:40:07 +0200 Subject: clk: imx6: refine hdmi_isfr's parent to make HDMI work on i.MX6 SoCs w/o VPU From: Sébastien Szymanski <sebastien.szymanski(a)armadeus.com> [ Upstream commit c68ee58d9ee7b856ac722f18f4f26579c8fbd2b4 ] On i.MX6 SoCs without VPU (in my case MCIMX6D4AVT10AC), the hdmi driver fails to probe: [ 2.540030] dwhdmi-imx 120000.hdmi: Unsupported HDMI controller (0000:00:00) [ 2.548199] imx-drm display-subsystem: failed to bind 120000.hdmi (ops dw_hdmi_imx_ops): -19 [ 2.557403] imx-drm display-subsystem: master bind failed: -19 That's because hdmi_isfr's parent, video_27m, is not correctly ungated. As explained in commit 5ccc248cc537 ("ARM: imx6q: clk: Add support for mipi_core_cfg clock as a shared clock gate"), video_27m is gated by CCM_CCGR3[CG8]. On i.MX6 SoCs with VPU, the hdmi is working thanks to the CCM_CMEOR[mod_en_ov_vpu] bit which makes the video_27m ungated whatever is in CCM_CCGR3[CG8]. The issue can be reproduced by setting CCMEOR[mod_en_ov_vpu] to 0. Make the HDMI work in every case by setting hdmi_isfr's parent to mipi_core_cfg. Signed-off-by: SÃ©bastien Szymanski <sebastien.szymanski(a)armadeus.com> Reviewed-by: Fabio Estevam <fabio.estevam(a)nxp.com> Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/imx/clk-imx6q.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/clk/imx/clk-imx6q.c +++ b/drivers/clk/imx/clk-imx6q.c @@ -419,7 +419,7 @@ static void __init imx6q_clocks_init(str clk[IMX6QDL_CLK_GPU2D_CORE] = imx_clk_gate2("gpu2d_core", "gpu2d_core_podf", base + 0x6c, 24); clk[IMX6QDL_CLK_GPU3D_CORE] = imx_clk_gate2("gpu3d_core", "gpu3d_core_podf", base + 0x6c, 26); clk[IMX6QDL_CLK_HDMI_IAHB] = imx_clk_gate2("hdmi_iahb", "ahb", base + 0x70, 0); - clk[IMX6QDL_CLK_HDMI_ISFR] = imx_clk_gate2("hdmi_isfr", "video_27m", base + 0x70, 4); + clk[IMX6QDL_CLK_HDMI_ISFR] = imx_clk_gate2("hdmi_isfr", "mipi_core_cfg", base + 0x70, 4); clk[IMX6QDL_CLK_I2C1] = imx_clk_gate2("i2c1", "ipg_per", base + 0x70, 6); clk[IMX6QDL_CLK_I2C2] = imx_clk_gate2("i2c2", "ipg_per", base + 0x70, 8); clk[IMX6QDL_CLK_I2C3] = imx_clk_gate2("i2c3", "ipg_per", base + 0x70, 10); Patches currently in stable-queue which might be from sebastien.szymanski(a)armadeus.com are queue-4.4/clk-imx6-refine-hdmi_isfr-s-parent-to-make-hdmi-work-on-i.mx6-socs-w-o-vpu.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "btrfs: add missing memset while reading compressed inline extents" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: add missing memset while reading compressed inline extents to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-add-missing-memset-while-reading-compressed-inline-extents.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org> Date: Fri, 10 Mar 2017 16:45:44 -0500 Subject: btrfs: add missing memset while reading compressed inline extents From: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org> [ Upstream commit e1699d2d7bf6e6cce3e1baff19f9dd4595a58664 ] This is a story about 4 distinct (and very old) btrfs bugs. Commit c8b978188c ("Btrfs: Add zlib compression support") added three data corruption bugs for inline extents (bugs #1-3). Commit 93c82d5750 ("Btrfs: zero page past end of inline file items") fixed bug #1: uncompressed inline extents followed by a hole and more extents could get non-zero data in the hole as they were read. The fix was to add a memset in btrfs_get_extent to zero out the hole. Commit 166ae5a418 ("btrfs: fix inline compressed read err corruption") fixed bug #2: compressed inline extents which contained non-zero bytes might be replaced with zero bytes in some cases. This patch removed an unhelpful memset from uncompress_inline, but the case where memset is required was missed. There is also a memset in the decompression code, but this only covers decompressed data that is shorter than the ram_bytes from the extent ref record. This memset doesn't cover the region between the end of the decompressed data and the end of the page. It has also moved around a few times over the years, so there's no single patch to refer to. This patch fixes bug #3: compressed inline extents followed by a hole and more extents could get non-zero data in the hole as they were read (i.e. bug #3 is the same as bug #1, but s/uncompressed/compressed/). The fix is the same: zero out the hole in the compressed case too, by putting a memset back in uncompress_inline, but this time with correct parameters. The last and oldest bug, bug #0, is the cause of the offending inline extent/hole/extent pattern. Bug #0 is a subtle and mostly-harmless quirk of behavior somewhere in the btrfs write code. In a few special cases, an inline extent and hole are allowed to persist where they normally would be combined with later extents in the file. A fast reproducer for bug #0 is presented below. A few offending extents are also created in the wild during large rsync transfers with the -S flag. A Linux kernel build (git checkout; make allyesconfig; make -j8) will produce a handful of offending files as well. Once an offending file is created, it can present different content to userspace each time it is read. Bug #0 is at least 4 and possibly 8 years old. I verified every vX.Y kernel back to v3.5 has this behavior. There are fossil records of this bug's effects in commits all the way back to v2.6.32. I have no reason to believe bug #0 wasn't present at the beginning of btrfs compression support in v2.6.29, but I can't easily test kernels that old to be sure. It is not clear whether bug #0 is worth fixing. A fix would likely require injecting extra reads into currently write-only paths, and most of the exceptional cases caused by bug #0 are already handled now. Whether we like them or not, bug #0's inline extents followed by holes are part of the btrfs de-facto disk format now, and we need to be able to read them without data corruption or an infoleak. So enough about bug #0, let's get back to bug #3 (this patch). An example of on-disk structure leading to data corruption found in the wild: item 61 key (606890 INODE_ITEM 0) itemoff 9662 itemsize 160 inode generation 50 transid 50 size 47424 nbytes 49141 block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0 flags 0x0(none) item 62 key (606890 INODE_REF 603050) itemoff 9642 itemsize 20 inode ref index 3 namelen 10 name: DB_File.so item 63 key (606890 EXTENT_DATA 0) itemoff 8280 itemsize 1362 inline extent data size 1341 ram 4085 compress(zlib) item 64 key (606890 EXTENT_DATA 4096) itemoff 8227 itemsize 53 extent data disk byte 5367308288 nr 20480 extent data offset 0 nr 45056 ram 45056 extent compression(zlib) Different data appears in userspace during each read of the 11 bytes between 4085 and 4096. The extent in item 63 is not long enough to fill the first page of the file, so a memset is required to fill the space between item 63 (ending at 4085) and item 64 (beginning at 4096) with zero. Here is a reproducer from Liu Bo, which demonstrates another method of creating the same inline extent and hole pattern: Using 'page_poison=on' kernel command line (or enable CONFIG_PAGE_POISONING) run the following: # touch foo # chattr +c foo # xfs_io -f -c "pwrite -W 0 1000" foo # xfs_io -f -c "falloc 4 8188" foo # od -x foo # echo 3 >/proc/sys/vm/drop_caches # od -x foo This produce the following on my box: Correct output: file contains 1000 data bytes followed by zeros: 0000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 0001740 cdcd cdcd cdcd cdcd 0000 0000 0000 0000 0001760 0000 0000 0000 0000 0000 0000 0000 0000 * 0020000 Actual output: the data after the first 1000 bytes will be different each run: 0000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 0001740 cdcd cdcd cdcd cdcd 6c63 7400 635f 006d 0001760 5f74 6f43 7400 435f 0053 5f74 7363 7400 0002000 435f 0056 5f74 6164 7400 645f 0062 5f74 (...) Signed-off-by: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org> Reviewed-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Chris Mason <clm(a)fb.com> Signed-off-by: Chris Mason <clm(a)fb.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/inode.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -6735,6 +6735,20 @@ static noinline int uncompress_inline(st max_size = min_t(unsigned long, PAGE_CACHE_SIZE, max_size); ret = btrfs_decompress(compress_type, tmp, page, extent_offset, inline_size, max_size); + + /* + * decompression code contains a memset to fill in any space between the end + * of the uncompressed data and the end of max_size in case the decompressed + * data ends up shorter than ram_bytes. That doesn't cover the hole between + * the end of an inline extent and the beginning of the next block, so we + * cover that region here. + */ + + if (max_size + pg_offset < PAGE_SIZE) { + char *map = kmap(page); + memset(map + pg_offset + max_size, 0, PAGE_SIZE - max_size - pg_offset); + kunmap(page); + } kfree(tmp); return ret; } Patches currently in stable-queue which might be from ce3g8jdj(a)umail.furryterror.org are queue-4.4/btrfs-add-missing-memset-while-reading-compressed-inline-extents.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "bcache: fix wrong cache_misses statistics" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bcache: fix wrong cache_misses statistics to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bcache-fix-wrong-cache_misses-statistics.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: "tang.junhui" <tang.junhui(a)zte.com.cn> Date: Mon, 30 Oct 2017 14:46:34 -0700 Subject: bcache: fix wrong cache_misses statistics From: "tang.junhui" <tang.junhui(a)zte.com.cn> [ Upstream commit c157313791a999646901b3e3c6888514ebc36d62 ] Currently, Cache missed IOs are identified by s->cache_miss, but actually, there are many situations that missed IOs are not assigned a value for s->cache_miss in cached_dev_cache_miss(), for example, a bypassed IO (s->iop.bypass = 1), or the cache_bio allocate failed. In these situations, it will go to out_put or out_submit, and s->cache_miss is null, which leads bch_mark_cache_accounting() to treat this IO as a hit IO. [ML: applied by 3-way merge] Signed-off-by: tang.junhui <tang.junhui(a)zte.com.cn> Reviewed-by: Michael Lyle <mlyle(a)lyle.org> Reviewed-by: Coly Li <colyli(a)suse.de> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/bcache/request.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/drivers/md/bcache/request.c +++ b/drivers/md/bcache/request.c @@ -468,6 +468,7 @@ struct search { unsigned recoverable:1; unsigned write:1; unsigned read_dirty_data:1; + unsigned cache_missed:1; unsigned long start_time; @@ -653,6 +654,7 @@ static inline struct search *search_allo s->orig_bio = bio; s->cache_miss = NULL; + s->cache_missed = 0; s->d = d; s->recoverable = 1; s->write = (bio->bi_rw & REQ_WRITE) != 0; @@ -776,7 +778,7 @@ static void cached_dev_read_done_bh(stru struct cached_dev *dc = container_of(s->d, struct cached_dev, disk); bch_mark_cache_accounting(s->iop.c, s->d, - !s->cache_miss, s->iop.bypass); + !s->cache_missed, s->iop.bypass); trace_bcache_read(s->orig_bio, !s->cache_miss, s->iop.bypass); if (s->iop.error) @@ -795,6 +797,8 @@ static int cached_dev_cache_miss(struct struct cached_dev *dc = container_of(s->d, struct cached_dev, disk); struct bio *miss, *cache_bio; + s->cache_missed = 1; + if (s->cache_miss || s->iop.bypass) { miss = bio_next_split(bio, sectors, GFP_NOIO, s->d->bio_split); ret = miss == bio ? MAP_DONE : MAP_CONTINUE; Patches currently in stable-queue which might be from tang.junhui(a)zte.com.cn are queue-4.4/bcache-fix-wrong-cache_misses-statistics.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "bcache: explicitly destroy mutex while exiting" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bcache: explicitly destroy mutex while exiting to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bcache-explicitly-destroy-mutex-while-exiting.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Liang Chen <liangchen.linux(a)gmail.com> Date: Mon, 30 Oct 2017 14:46:35 -0700 Subject: bcache: explicitly destroy mutex while exiting From: Liang Chen <liangchen.linux(a)gmail.com> [ Upstream commit 330a4db89d39a6b43f36da16824eaa7a7509d34d ] mutex_destroy does nothing most of time, but it's better to call it to make the code future proof and it also has some meaning for like mutex debug. As Coly pointed out in a previous review, bcache_exit() may not be able to handle all the references properly if userspace registers cache and backing devices right before bch_debug_init runs and bch_debug_init failes later. So not exposing userspace interface until everything is ready to avoid that issue. Signed-off-by: Liang Chen <liangchen.linux(a)gmail.com> Reviewed-by: Michael Lyle <mlyle(a)lyle.org> Reviewed-by: Coly Li <colyli(a)suse.de> Reviewed-by: Eric Wheeler <bcache(a)linux.ewheeler.net> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/bcache/super.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/md/bcache/super.c +++ b/drivers/md/bcache/super.c @@ -2083,6 +2083,7 @@ static void bcache_exit(void) if (bcache_major) unregister_blkdev(bcache_major, "bcache"); unregister_reboot_notifier(&reboot); + mutex_destroy(&bch_register_lock); } static int __init bcache_init(void) @@ -2101,14 +2102,15 @@ static int __init bcache_init(void) bcache_major = register_blkdev(0, "bcache"); if (bcache_major < 0) { unregister_reboot_notifier(&reboot); + mutex_destroy(&bch_register_lock); return bcache_major; } if (!(bcache_wq = create_workqueue("bcache")) || !(bcache_kobj = kobject_create_and_add("bcache", fs_kobj)) || - sysfs_create_files(bcache_kobj, files) || bch_request_init() || - bch_debug_init(bcache_kobj)) + bch_debug_init(bcache_kobj) || + sysfs_create_files(bcache_kobj, files)) goto err; return 0; Patches currently in stable-queue which might be from liangchen.linux(a)gmail.com are queue-4.4/bcache-explicitly-destroy-mutex-while-exiting.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "ath9k: fix tx99 potential info leak" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ath9k: fix tx99 potential info leak to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ath9k-fix-tx99-potential-info-leak.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Miaoqing Pan <miaoqing(a)codeaurora.org> Date: Wed, 27 Sep 2017 09:13:34 +0800 Subject: ath9k: fix tx99 potential info leak From: Miaoqing Pan <miaoqing(a)codeaurora.org> [ Upstream commit ee0a47186e2fa9aa1c56cadcea470ca0ba8c8692 ] When the user sets count to zero the string buffer would remain completely uninitialized which causes the kernel to parse its own stack data, potentially leading to an info leak. In addition to that, the string might be not terminated properly when the user data does not contain a 0-terminator. Signed-off-by: Miaoqing Pan <miaoqing(a)codeaurora.org> Reviewed-by: Christoph Böhmwalder <christoph(a)boehmwalder.at> Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ath/ath9k/tx99.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/net/wireless/ath/ath9k/tx99.c +++ b/drivers/net/wireless/ath/ath9k/tx99.c @@ -180,6 +180,9 @@ static ssize_t write_file_tx99(struct fi ssize_t len; int r; + if (count < 1) + return -EINVAL; + if (sc->cur_chan->nvifs > 1) return -EOPNOTSUPP; @@ -187,6 +190,8 @@ static ssize_t write_file_tx99(struct fi if (copy_from_user(buf, user_buf, len)) return -EFAULT; + buf[len] = '\0'; + if (strtobool(buf, &start)) return -EINVAL; Patches currently in stable-queue which might be from miaoqing(a)codeaurora.org are queue-4.4/ath9k-fix-tx99-potential-info-leak.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "arm-ccn: perf: Prevent module unload while PMU is in use" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm-ccn: perf: Prevent module unload while PMU is in use to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-ccn-perf-prevent-module-unload-while-pmu-is-in-use.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Suzuki K Poulose <suzuki.poulose(a)arm.com> Date: Fri, 3 Nov 2017 11:45:18 +0000 Subject: arm-ccn: perf: Prevent module unload while PMU is in use From: Suzuki K Poulose <suzuki.poulose(a)arm.com> [ Upstream commit c7f5828bf77dcbd61d51f4736c1d5aa35663fbb4 ] When the PMU driver is built as a module, the perf expects the pmu->module to be valid, so that the driver is prevented from being unloaded while it is in use. Fix the CCN pmu driver to fill in this field. Fixes: a33b0daab73a0 ("bus: ARM CCN PMU driver") Cc: Pawel Moll <pawel.moll(a)arm.com> Cc: Will Deacon <will.deacon(a)arm.com> Acked-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> Signed-off-by: Will Deacon <will.deacon(a)arm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bus/arm-ccn.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/bus/arm-ccn.c +++ b/drivers/bus/arm-ccn.c @@ -1260,6 +1260,7 @@ static int arm_ccn_pmu_init(struct arm_c /* Perf driver registration */ ccn->dt.pmu = (struct pmu) { + .module = THIS_MODULE, .attr_groups = arm_ccn_pmu_attr_groups, .task_ctx_nr = perf_invalid_context, .event_init = arm_ccn_pmu_event_init, Patches currently in stable-queue which might be from suzuki.poulose(a)arm.com are queue-4.4/arm-ccn-perf-prevent-module-unload-while-pmu-is-in-use.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Prevent callback expiry timer overflow" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Prevent callback expiry timer overflow to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: afs-prevent-callback-expiry-timer-overflow.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Tina Ruchandani <ruchandani.tina(a)gmail.com> Date: Thu, 16 Mar 2017 16:27:46 +0000 Subject: afs: Prevent callback expiry timer overflow From: Tina Ruchandani <ruchandani.tina(a)gmail.com> [ Upstream commit 56e714312e7dbd6bb83b2f78d3ec19a404c7649f ] get_seconds() returns real wall-clock seconds. On 32-bit systems this value will overflow in year 2038 and beyond. This patch changes afs_vnode record to use ktime_get_real_seconds() instead, for the fields cb_expires and cb_expires_at. Signed-off-by: Tina Ruchandani <ruchandani.tina(a)gmail.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/afs/fsclient.c | 2 +- fs/afs/inode.c | 7 ++++--- fs/afs/internal.h | 4 ++-- 3 files changed, 7 insertions(+), 6 deletions(-) --- a/fs/afs/fsclient.c +++ b/fs/afs/fsclient.c @@ -139,7 +139,7 @@ static void xdr_decode_AFSCallBack(const vnode->cb_version = ntohl(*bp++); vnode->cb_expiry = ntohl(*bp++); vnode->cb_type = ntohl(*bp++); - vnode->cb_expires = vnode->cb_expiry + get_seconds(); + vnode->cb_expires = vnode->cb_expiry + ktime_get_real_seconds(); *_bp = bp; } --- a/fs/afs/inode.c +++ b/fs/afs/inode.c @@ -244,12 +244,13 @@ struct inode *afs_iget(struct super_bloc vnode->cb_version = 0; vnode->cb_expiry = 0; vnode->cb_type = 0; - vnode->cb_expires = get_seconds(); + vnode->cb_expires = ktime_get_real_seconds(); } else { vnode->cb_version = cb->version; vnode->cb_expiry = cb->expiry; vnode->cb_type = cb->type; - vnode->cb_expires = vnode->cb_expiry + get_seconds(); + vnode->cb_expires = vnode->cb_expiry + + ktime_get_real_seconds(); } } @@ -322,7 +323,7 @@ int afs_validate(struct afs_vnode *vnode !test_bit(AFS_VNODE_CB_BROKEN, &vnode->flags) && !test_bit(AFS_VNODE_MODIFIED, &vnode->flags) && !test_bit(AFS_VNODE_ZAP_DATA, &vnode->flags)) { - if (vnode->cb_expires < get_seconds() + 10) { + if (vnode->cb_expires < ktime_get_real_seconds() + 10) { _debug("callback expired"); set_bit(AFS_VNODE_CB_BROKEN, &vnode->flags); } else { --- a/fs/afs/internal.h +++ b/fs/afs/internal.h @@ -375,8 +375,8 @@ struct afs_vnode { struct rb_node server_rb; /* link in server->fs_vnodes */ struct rb_node cb_promise; /* link in server->cb_promises */ struct work_struct cb_broken_work; /* work to be done on callback break */ - time_t cb_expires; /* time at which callback expires */ - time_t cb_expires_at; /* time used to order cb_promise */ + time64_t cb_expires; /* time at which callback expires */ + time64_t cb_expires_at; /* time used to order cb_promise */ unsigned cb_version; /* callback version */ unsigned cb_expiry; /* callback expiry time */ afs_callback_type_t cb_type; /* type of callback */ Patches currently in stable-queue which might be from ruchandani.tina(a)gmail.com are queue-4.4/afs-prevent-callback-expiry-timer-overflow.patch queue-4.4/afs-migrate-vlocation-fields-to-64-bit.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Populate group ID from vnode status" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Populate group ID from vnode status to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: afs-populate-group-id-from-vnode-status.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Marc Dionne <marc.dionne(a)auristor.com> Date: Thu, 16 Mar 2017 16:27:43 +0000 Subject: afs: Populate group ID from vnode status From: Marc Dionne <marc.dionne(a)auristor.com> [ Upstream commit 6186f0788b31f44affceeedc7b48eb10faea120d ] The group was hard coded to GLOBAL_ROOT_GID; use the group ID that was received from the server. Signed-off-by: Marc Dionne <marc.dionne(a)auristor.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/afs/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/afs/inode.c +++ b/fs/afs/inode.c @@ -69,7 +69,7 @@ static int afs_inode_map_status(struct a set_nlink(inode, vnode->status.nlink); inode->i_uid = vnode->status.owner; - inode->i_gid = GLOBAL_ROOT_GID; + inode->i_gid = vnode->status.group; inode->i_size = vnode->status.size; inode->i_ctime.tv_sec = vnode->status.mtime_server; inode->i_ctime.tv_nsec = 0; Patches currently in stable-queue which might be from marc.dionne(a)auristor.com are queue-4.4/afs-populate-group-id-from-vnode-status.patch queue-4.4/afs-adjust-mode-bits-processing.patch queue-4.4/afs-populate-and-use-client-modification-time.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Populate and use client modification time" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Populate and use client modification time to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: afs-populate-and-use-client-modification-time.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Marc Dionne <marc.dionne(a)auristor.com> Date: Thu, 16 Mar 2017 16:27:47 +0000 Subject: afs: Populate and use client modification time From: Marc Dionne <marc.dionne(a)auristor.com> [ Upstream commit ab94f5d0dd6fd82e7eeca5e7c8096eaea0a0261f ] The inode timestamps should be set from the client time in the status received from the server, rather than the server time which is meant for internal server use. Set AFS_SET_MTIME and populate the mtime for operations that take an input status, such as file/dir creation and StoreData. If an input time is not provided the server will set the vnode times based on the current server time. In a situation where the server has some skew with the client, this could lead to the client seeing a timestamp in the future for a file that it just created or wrote. Signed-off-by: Marc Dionne <marc.dionne(a)auristor.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/afs/fsclient.c | 18 +++++++++--------- fs/afs/inode.c | 2 +- 2 files changed, 10 insertions(+), 10 deletions(-) --- a/fs/afs/fsclient.c +++ b/fs/afs/fsclient.c @@ -105,7 +105,7 @@ static void xdr_decode_AFSFetchStatus(co vnode->vfs_inode.i_mode = mode; } - vnode->vfs_inode.i_ctime.tv_sec = status->mtime_server; + vnode->vfs_inode.i_ctime.tv_sec = status->mtime_client; vnode->vfs_inode.i_mtime = vnode->vfs_inode.i_ctime; vnode->vfs_inode.i_atime = vnode->vfs_inode.i_ctime; vnode->vfs_inode.i_version = data_version; @@ -703,8 +703,8 @@ int afs_fs_create(struct afs_server *ser memset(bp, 0, padsz); bp = (void *) bp + padsz; } - *bp++ = htonl(AFS_SET_MODE); - *bp++ = 0; /* mtime */ + *bp++ = htonl(AFS_SET_MODE | AFS_SET_MTIME); + *bp++ = htonl(vnode->vfs_inode.i_mtime.tv_sec); /* mtime */ *bp++ = 0; /* owner */ *bp++ = 0; /* group */ *bp++ = htonl(mode & S_IALLUGO); /* unix mode */ @@ -981,8 +981,8 @@ int afs_fs_symlink(struct afs_server *se memset(bp, 0, c_padsz); bp = (void *) bp + c_padsz; } - *bp++ = htonl(AFS_SET_MODE); - *bp++ = 0; /* mtime */ + *bp++ = htonl(AFS_SET_MODE | AFS_SET_MTIME); + *bp++ = htonl(vnode->vfs_inode.i_mtime.tv_sec); /* mtime */ *bp++ = 0; /* owner */ *bp++ = 0; /* group */ *bp++ = htonl(S_IRWXUGO); /* unix mode */ @@ -1192,8 +1192,8 @@ static int afs_fs_store_data64(struct af *bp++ = htonl(vnode->fid.vnode); *bp++ = htonl(vnode->fid.unique); - *bp++ = 0; /* mask */ - *bp++ = 0; /* mtime */ + *bp++ = htonl(AFS_SET_MTIME); /* mask */ + *bp++ = htonl(vnode->vfs_inode.i_mtime.tv_sec); /* mtime */ *bp++ = 0; /* owner */ *bp++ = 0; /* group */ *bp++ = 0; /* unix mode */ @@ -1269,8 +1269,8 @@ int afs_fs_store_data(struct afs_server *bp++ = htonl(vnode->fid.vnode); *bp++ = htonl(vnode->fid.unique); - *bp++ = 0; /* mask */ - *bp++ = 0; /* mtime */ + *bp++ = htonl(AFS_SET_MTIME); /* mask */ + *bp++ = htonl(vnode->vfs_inode.i_mtime.tv_sec); /* mtime */ *bp++ = 0; /* owner */ *bp++ = 0; /* group */ *bp++ = 0; /* unix mode */ --- a/fs/afs/inode.c +++ b/fs/afs/inode.c @@ -71,7 +71,7 @@ static int afs_inode_map_status(struct a inode->i_uid = vnode->status.owner; inode->i_gid = vnode->status.group; inode->i_size = vnode->status.size; - inode->i_ctime.tv_sec = vnode->status.mtime_server; + inode->i_ctime.tv_sec = vnode->status.mtime_client; inode->i_ctime.tv_nsec = 0; inode->i_atime = inode->i_mtime = inode->i_ctime; inode->i_blocks = 0; Patches currently in stable-queue which might be from marc.dionne(a)auristor.com are queue-4.4/afs-populate-group-id-from-vnode-status.patch queue-4.4/afs-adjust-mode-bits-processing.patch queue-4.4/afs-populate-and-use-client-modification-time.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Migrate vlocation fields to 64-bit" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Migrate vlocation fields to 64-bit to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: afs-migrate-vlocation-fields-to-64-bit.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Tina Ruchandani <ruchandani.tina(a)gmail.com> Date: Thu, 16 Mar 2017 16:27:46 +0000 Subject: afs: Migrate vlocation fields to 64-bit From: Tina Ruchandani <ruchandani.tina(a)gmail.com> [ Upstream commit 8a79790bf0b7da216627ffb85f52cfb4adbf1e4e ] get_seconds() returns real wall-clock seconds. On 32-bit systems this value will overflow in year 2038 and beyond. This patch changes afs's vlocation record to use ktime_get_real_seconds() instead, for the fields time_of_death and update_at. Signed-off-by: Tina Ruchandani <ruchandani.tina(a)gmail.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/afs/callback.c | 7 ++++--- fs/afs/internal.h | 7 ++++--- fs/afs/server.c | 6 +++--- fs/afs/vlocation.c | 16 +++++++++------- 4 files changed, 20 insertions(+), 16 deletions(-) --- a/fs/afs/callback.c +++ b/fs/afs/callback.c @@ -362,7 +362,7 @@ static void afs_callback_updater(struct { struct afs_server *server; struct afs_vnode *vnode, *xvnode; - time_t now; + time64_t now; long timeout; int ret; @@ -370,7 +370,7 @@ static void afs_callback_updater(struct _enter(""); - now = get_seconds(); + now = ktime_get_real_seconds(); /* find the first vnode to update */ spin_lock(&server->cb_lock); @@ -424,7 +424,8 @@ static void afs_callback_updater(struct /* and then reschedule */ _debug("reschedule"); - vnode->update_at = get_seconds() + afs_vnode_update_timeout; + vnode->update_at = ktime_get_real_seconds() + + afs_vnode_update_timeout; spin_lock(&server->cb_lock); --- a/fs/afs/internal.h +++ b/fs/afs/internal.h @@ -11,6 +11,7 @@ #include <linux/compiler.h> #include <linux/kernel.h> +#include <linux/ktime.h> #include <linux/fs.h> #include <linux/pagemap.h> #include <linux/skbuff.h> @@ -247,7 +248,7 @@ struct afs_cache_vhash { */ struct afs_vlocation { atomic_t usage; - time_t time_of_death; /* time at which put reduced usage to 0 */ + time64_t time_of_death; /* time at which put reduced usage to 0 */ struct list_head link; /* link in cell volume location list */ struct list_head grave; /* link in master graveyard list */ struct list_head update; /* link in master update list */ @@ -258,7 +259,7 @@ struct afs_vlocation { struct afs_cache_vlocation vldb; /* volume information DB record */ struct afs_volume *vols[3]; /* volume access record pointer (index by type) */ wait_queue_head_t waitq; /* status change waitqueue */ - time_t update_at; /* time at which record should be updated */ + time64_t update_at; /* time at which record should be updated */ spinlock_t lock; /* access lock */ afs_vlocation_state_t state; /* volume location state */ unsigned short upd_rej_cnt; /* ENOMEDIUM count during update */ @@ -271,7 +272,7 @@ struct afs_vlocation { */ struct afs_server { atomic_t usage; - time_t time_of_death; /* time at which put reduced usage to 0 */ + time64_t time_of_death; /* time at which put reduced usage to 0 */ struct in_addr addr; /* server address */ struct afs_cell *cell; /* cell in which server resides */ struct list_head link; /* link in cell's server list */ --- a/fs/afs/server.c +++ b/fs/afs/server.c @@ -237,7 +237,7 @@ void afs_put_server(struct afs_server *s spin_lock(&afs_server_graveyard_lock); if (atomic_read(&server->usage) == 0) { list_move_tail(&server->grave, &afs_server_graveyard); - server->time_of_death = get_seconds(); + server->time_of_death = ktime_get_real_seconds(); queue_delayed_work(afs_wq, &afs_server_reaper, afs_server_timeout * HZ); } @@ -272,9 +272,9 @@ static void afs_reap_server(struct work_ LIST_HEAD(corpses); struct afs_server *server; unsigned long delay, expiry; - time_t now; + time64_t now; - now = get_seconds(); + now = ktime_get_real_seconds(); spin_lock(&afs_server_graveyard_lock); while (!list_empty(&afs_server_graveyard)) { --- a/fs/afs/vlocation.c +++ b/fs/afs/vlocation.c @@ -340,7 +340,8 @@ static void afs_vlocation_queue_for_upda struct afs_vlocation *xvl; /* wait at least 10 minutes before updating... */ - vl->update_at = get_seconds() + afs_vlocation_update_timeout; + vl->update_at = ktime_get_real_seconds() + + afs_vlocation_update_timeout; spin_lock(&afs_vlocation_updates_lock); @@ -506,7 +507,7 @@ void afs_put_vlocation(struct afs_vlocat if (atomic_read(&vl->usage) == 0) { _debug("buried"); list_move_tail(&vl->grave, &afs_vlocation_graveyard); - vl->time_of_death = get_seconds(); + vl->time_of_death = ktime_get_real_seconds(); queue_delayed_work(afs_wq, &afs_vlocation_reap, afs_vlocation_timeout * HZ); @@ -543,11 +544,11 @@ static void afs_vlocation_reaper(struct LIST_HEAD(corpses); struct afs_vlocation *vl; unsigned long delay, expiry; - time_t now; + time64_t now; _enter(""); - now = get_seconds(); + now = ktime_get_real_seconds(); spin_lock(&afs_vlocation_graveyard_lock); while (!list_empty(&afs_vlocation_graveyard)) { @@ -622,13 +623,13 @@ static void afs_vlocation_updater(struct { struct afs_cache_vlocation vldb; struct afs_vlocation *vl, *xvl; - time_t now; + time64_t now; long timeout; int ret; _enter(""); - now = get_seconds(); + now = ktime_get_real_seconds(); /* find a record to update */ spin_lock(&afs_vlocation_updates_lock); @@ -684,7 +685,8 @@ static void afs_vlocation_updater(struct /* and then reschedule */ _debug("reschedule"); - vl->update_at = get_seconds() + afs_vlocation_update_timeout; + vl->update_at = ktime_get_real_seconds() + + afs_vlocation_update_timeout; spin_lock(&afs_vlocation_updates_lock); Patches currently in stable-queue which might be from ruchandani.tina(a)gmail.com are queue-4.4/afs-prevent-callback-expiry-timer-overflow.patch queue-4.4/afs-migrate-vlocation-fields-to-64-bit.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Flush outstanding writes when an fd is closed" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Flush outstanding writes when an fd is closed to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: afs-flush-outstanding-writes-when-an-fd-is-closed.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: David Howells <dhowells(a)redhat.com> Date: Thu, 16 Mar 2017 16:27:45 +0000 Subject: afs: Flush outstanding writes when an fd is closed From: David Howells <dhowells(a)redhat.com> [ Upstream commit 58fed94dfb17e89556b5705f20f90e5b2971b6a1 ] Flush outstanding writes in afs when an fd is closed. This is what NFS and CIFS do. Reported-by: Marc Dionne <marc.c.dionne(a)gmail.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/afs/file.c | 1 + fs/afs/internal.h | 1 + fs/afs/write.c | 14 ++++++++++++++ 3 files changed, 16 insertions(+) --- a/fs/afs/file.c +++ b/fs/afs/file.c @@ -29,6 +29,7 @@ static int afs_readpages(struct file *fi const struct file_operations afs_file_operations = { .open = afs_open, + .flush = afs_flush, .release = afs_release, .llseek = generic_file_llseek, .read_iter = generic_file_read_iter, --- a/fs/afs/internal.h +++ b/fs/afs/internal.h @@ -749,6 +749,7 @@ extern int afs_writepages(struct address extern void afs_pages_written_back(struct afs_vnode *, struct afs_call *); extern ssize_t afs_file_write(struct kiocb *, struct iov_iter *); extern int afs_writeback_all(struct afs_vnode *); +extern int afs_flush(struct file *, fl_owner_t); extern int afs_fsync(struct file *, loff_t, loff_t, int); --- a/fs/afs/write.c +++ b/fs/afs/write.c @@ -741,6 +741,20 @@ out: } /* + * Flush out all outstanding writes on a file opened for writing when it is + * closed. + */ +int afs_flush(struct file *file, fl_owner_t id) +{ + _enter(""); + + if ((file->f_mode & FMODE_WRITE) == 0) + return 0; + + return vfs_fsync(file, 0); +} + +/* * notification that a previously read-only page is about to become writable * - if it returns an error, the caller will deliver a bus error signal */ Patches currently in stable-queue which might be from dhowells(a)redhat.com are queue-4.4/afs-flush-outstanding-writes-when-an-fd-is-closed.patch queue-4.4/afs-fix-the-maths-in-afs_fs_store_data.patch queue-4.4/afs-populate-group-id-from-vnode-status.patch queue-4.4/afs-prevent-callback-expiry-timer-overflow.patch queue-4.4/keys-add-missing-permission-check-for-request_key-destination.patch queue-4.4/afs-adjust-mode-bits-processing.patch queue-4.4/afs-fix-page-leak-in-afs_write_begin.patch queue-4.4/afs-fix-missing-put_page.patch queue-4.4/afs-migrate-vlocation-fields-to-64-bit.patch queue-4.4/afs-populate-and-use-client-modification-time.patch queue-4.4/afs-fix-afs_kill_pages.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Fix the maths in afs_fs_store_data()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Fix the maths in afs_fs_store_data() to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: afs-fix-the-maths-in-afs_fs_store_data.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: David Howells <dhowells(a)redhat.com> Date: Thu, 16 Mar 2017 16:27:47 +0000 Subject: afs: Fix the maths in afs_fs_store_data() From: David Howells <dhowells(a)redhat.com> [ Upstream commit 146a1192783697810b63a1e41c4d59fc93387340 ] afs_fs_store_data() works out of the size of the write it's going to make, but it uses 32-bit unsigned subtraction in one place that gets automatically cast to loff_t. However, if to < offset, then the number goes negative, but as the result isn't signed, this doesn't get sign-extended to 64-bits when placed in a loff_t. Fix by casting the operands to loff_t. Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/afs/fsclient.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/afs/fsclient.c +++ b/fs/afs/fsclient.c @@ -1225,7 +1225,7 @@ int afs_fs_store_data(struct afs_server _enter(",%x,{%x:%u},,", key_serial(wb->key), vnode->fid.vid, vnode->fid.vnode); - size = to - offset; + size = (loff_t)to - (loff_t)offset; if (first != last) size += (loff_t)(last - first) << PAGE_SHIFT; pos = (loff_t)first << PAGE_SHIFT; Patches currently in stable-queue which might be from dhowells(a)redhat.com are queue-4.4/afs-flush-outstanding-writes-when-an-fd-is-closed.patch queue-4.4/afs-fix-the-maths-in-afs_fs_store_data.patch queue-4.4/afs-populate-group-id-from-vnode-status.patch queue-4.4/afs-prevent-callback-expiry-timer-overflow.patch queue-4.4/keys-add-missing-permission-check-for-request_key-destination.patch queue-4.4/afs-adjust-mode-bits-processing.patch queue-4.4/afs-fix-page-leak-in-afs_write_begin.patch queue-4.4/afs-fix-missing-put_page.patch queue-4.4/afs-migrate-vlocation-fields-to-64-bit.patch queue-4.4/afs-populate-and-use-client-modification-time.patch queue-4.4/afs-fix-afs_kill_pages.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Fix page leak in afs_write_begin()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Fix page leak in afs_write_begin() to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: afs-fix-page-leak-in-afs_write_begin.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: David Howells <dhowells(a)redhat.com> Date: Thu, 16 Mar 2017 16:27:48 +0000 Subject: afs: Fix page leak in afs_write_begin() From: David Howells <dhowells(a)redhat.com> [ Upstream commit 6d06b0d25209c80e99c1e89700f1e09694a3766b ] afs_write_begin() leaks a ref and a lock on a page if afs_fill_page() fails. Fix the leak by unlocking and releasing the page in the error path. Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/afs/write.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/fs/afs/write.c +++ b/fs/afs/write.c @@ -148,12 +148,12 @@ int afs_write_begin(struct file *file, s kfree(candidate); return -ENOMEM; } - *pagep = page; - /* page won't leak in error case: it eventually gets cleaned off LRU */ if (!PageUptodate(page) && len != PAGE_CACHE_SIZE) { ret = afs_fill_page(vnode, key, index << PAGE_CACHE_SHIFT, page); if (ret < 0) { + unlock_page(page); + put_page(page); kfree(candidate); _leave(" = %d [prep]", ret); return ret; @@ -161,6 +161,9 @@ int afs_write_begin(struct file *file, s SetPageUptodate(page); } + /* page won't leak in error case: it eventually gets cleaned off LRU */ + *pagep = page; + try_again: spin_lock(&vnode->writeback_lock); Patches currently in stable-queue which might be from dhowells(a)redhat.com are queue-4.4/afs-flush-outstanding-writes-when-an-fd-is-closed.patch queue-4.4/afs-fix-the-maths-in-afs_fs_store_data.patch queue-4.4/afs-populate-group-id-from-vnode-status.patch queue-4.4/afs-prevent-callback-expiry-timer-overflow.patch queue-4.4/keys-add-missing-permission-check-for-request_key-destination.patch queue-4.4/afs-adjust-mode-bits-processing.patch queue-4.4/afs-fix-page-leak-in-afs_write_begin.patch queue-4.4/afs-fix-missing-put_page.patch queue-4.4/afs-migrate-vlocation-fields-to-64-bit.patch queue-4.4/afs-populate-and-use-client-modification-time.patch queue-4.4/afs-fix-afs_kill_pages.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Fix missing put_page()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Fix missing put_page() to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: afs-fix-missing-put_page.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: David Howells <dhowells(a)redhat.com> Date: Thu, 16 Mar 2017 16:27:43 +0000 Subject: afs: Fix missing put_page() From: David Howells <dhowells(a)redhat.com> [ Upstream commit 29c8bbbd6e21daa0997d1c3ee886b897ee7ad652 ] In afs_writepages_region(), inside the loop where we find dirty pages to deal with, one of the if-statements is missing a put_page(). Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/afs/write.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/afs/write.c +++ b/fs/afs/write.c @@ -503,6 +503,7 @@ static int afs_writepages_region(struct if (PageWriteback(page) || !PageDirty(page)) { unlock_page(page); + put_page(page); continue; } Patches currently in stable-queue which might be from dhowells(a)redhat.com are queue-4.4/afs-flush-outstanding-writes-when-an-fd-is-closed.patch queue-4.4/afs-fix-the-maths-in-afs_fs_store_data.patch queue-4.4/afs-populate-group-id-from-vnode-status.patch queue-4.4/afs-prevent-callback-expiry-timer-overflow.patch queue-4.4/keys-add-missing-permission-check-for-request_key-destination.patch queue-4.4/afs-adjust-mode-bits-processing.patch queue-4.4/afs-fix-page-leak-in-afs_write_begin.patch queue-4.4/afs-fix-missing-put_page.patch queue-4.4/afs-migrate-vlocation-fields-to-64-bit.patch queue-4.4/afs-populate-and-use-client-modification-time.patch queue-4.4/afs-fix-afs_kill_pages.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Fix afs_kill_pages()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Fix afs_kill_pages() to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: afs-fix-afs_kill_pages.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: David Howells <dhowells(a)redhat.com> Date: Thu, 16 Mar 2017 16:27:48 +0000 Subject: afs: Fix afs_kill_pages() From: David Howells <dhowells(a)redhat.com> [ Upstream commit 7286a35e893176169b09715096a4aca557e2ccd2 ] Fix afs_kill_pages() in two ways: (1) If a writeback has been partially flushed, then if we try and kill the pages it contains, some of them may no longer be undergoing writeback and end_page_writeback() will assert. Fix this by checking to see whether the page in question is actually undergoing writeback before ending that writeback. (2) The loop that scans for pages to kill doesn't increase the first page index, and so the loop may not terminate, but it will try to process the same pages over and over again. Fix this by increasing the first page index to one after the last page we processed. Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/afs/write.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) --- a/fs/afs/write.c +++ b/fs/afs/write.c @@ -299,10 +299,14 @@ static void afs_kill_pages(struct afs_vn ASSERTCMP(pv.nr, ==, count); for (loop = 0; loop < count; loop++) { - ClearPageUptodate(pv.pages[loop]); + struct page *page = pv.pages[loop]; + ClearPageUptodate(page); if (error) - SetPageError(pv.pages[loop]); - end_page_writeback(pv.pages[loop]); + SetPageError(page); + if (PageWriteback(page)) + end_page_writeback(page); + if (page->index >= first) + first = page->index + 1; } __pagevec_release(&pv); Patches currently in stable-queue which might be from dhowells(a)redhat.com are queue-4.4/afs-flush-outstanding-writes-when-an-fd-is-closed.patch queue-4.4/afs-fix-the-maths-in-afs_fs_store_data.patch queue-4.4/afs-populate-group-id-from-vnode-status.patch queue-4.4/afs-prevent-callback-expiry-timer-overflow.patch queue-4.4/keys-add-missing-permission-check-for-request_key-destination.patch queue-4.4/afs-adjust-mode-bits-processing.patch queue-4.4/afs-fix-page-leak-in-afs_write_begin.patch queue-4.4/afs-fix-missing-put_page.patch queue-4.4/afs-migrate-vlocation-fields-to-64-bit.patch queue-4.4/afs-populate-and-use-client-modification-time.patch queue-4.4/afs-fix-afs_kill_pages.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Adjust mode bits processing" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Adjust mode bits processing to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: afs-adjust-mode-bits-processing.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Marc Dionne <marc.dionne(a)auristor.com> Date: Thu, 16 Mar 2017 16:27:44 +0000 Subject: afs: Adjust mode bits processing From: Marc Dionne <marc.dionne(a)auristor.com> [ Upstream commit 627f46943ff90bcc32ddeb675d881c043c6fa2ae ] Mode bits for an afs file should not be enforced in the usual way. For files, the absence of user bits can restrict file access with respect to what is granted by the server. These bits apply regardless of the owner or the current uid; the rest of the mode bits (group, other) are ignored. Signed-off-by: Marc Dionne <marc.dionne(a)auristor.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/afs/security.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) --- a/fs/afs/security.c +++ b/fs/afs/security.c @@ -340,17 +340,22 @@ int afs_permission(struct inode *inode, } else { if (!(access & AFS_ACE_LOOKUP)) goto permission_denied; + if ((mask & MAY_EXEC) && !(inode->i_mode & S_IXUSR)) + goto permission_denied; if (mask & (MAY_EXEC | MAY_READ)) { if (!(access & AFS_ACE_READ)) goto permission_denied; + if (!(inode->i_mode & S_IRUSR)) + goto permission_denied; } else if (mask & MAY_WRITE) { if (!(access & AFS_ACE_WRITE)) goto permission_denied; + if (!(inode->i_mode & S_IWUSR)) + goto permission_denied; } } key_put(key); - ret = generic_permission(inode, mask); _leave(" = %d", ret); return ret; Patches currently in stable-queue which might be from marc.dionne(a)auristor.com are queue-4.4/afs-populate-group-id-from-vnode-status.patch queue-4.4/afs-adjust-mode-bits-processing.patch queue-4.4/afs-populate-and-use-client-modification-time.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] [GIT PULL] commits for Linux 4.9

by alexander.levin＠verizon.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Greg, Pleae pull commits for Linux 4.9 . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== The following changes since commit 284bbc782445283e9a5124666dda8010f379f179: Linux 4.9.67 (2017-12-05 11:24:35 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git tags/for-greg-4.9-14122017 for you to fetch changes up to 5a61e82fa8ae21ab86109805e7697c9d53fd046f: ath9k: fix tx99 potential info leak (2017-12-14 10:24:24 -0500) - ---------------------------------------------------------------- for-greg-4.9-14122017 - ---------------------------------------------------------------- Alex Deucher (2): drm/radeon/si: add dpm quirk for Oland drm/radeon: reinstate oland workaround for sclk Alex Vesker (1): IB/ipoib: Grab rtnl lock on heavy flush when calling ndo_open/stop Alex Williamson (1): PCI: Detach driver before procfs & sysfs teardown on device remove Alexander Duyck (1): macvlan: Only deliver one copy of the frame to the macvlan interface Alexander Potapenko (1): net: initialize msg.msg_flags in recvfrom Alexander Shishkin (1): intel_th: pci: Add Gemini Lake support Andrea Arcangeli (2): userfaultfd: shmem: __do_fault requires VM_FAULT_NOPAGE userfaultfd: selftest: vm: allow to build in vm/ directory Arnd Bergmann (2): irqchip/mvebu-odmi: Select GENERIC_MSI_IRQ_DOMAIN drm: amd: remove broken include path Bart Van Assche (2): target/iscsi: Fix a race condition in iscsit_add_reject_from_cmd() RDMA/cma: Avoid triggering undefined behavior Bob Peterson (1): GFS2: Take inode off order_write list when setting jdata flag Brian Foster (1): xfs: fix log block underflow during recovery cycle verification Chen Zhong (1): clk: mediatek: add the option for determining PLL source clock Christoph Hellwig (2): nvme: use kref_get_unless_zero in nvme_find_get_ns xfs: fix incorrect extent state in xfs_bmap_add_extent_unwritten_real Christophe JAILLET (3): video: fbdev: au1200fb: Release some resources if a memory allocation fails video: fbdev: au1200fb: Return an error code if a memory allocation fails btrfs: tests: Fix a memory leak in error handling path in 'run_test()' Christophe Leroy (1): powerpc/ipic: Fix status get and status clear Chunfeng Yun (1): usb: xhci-mtk: check hcc_params after adding primary hcd Dan Carpenter (1): scsi: bfa: integer overflow in debugfs Daniel Borkmann (1): perf symbols: Fix symbols__fixup_end heuristic for corner cases Daniel Bristot de Oliveira (2): sched/deadline: Make sure the replenishment timer fires in the next period sched/deadline: Throttle a constrained deadline task activated after the deadline Daniel Drake (1): efi/esrt: Cleanup bad memory map log messages Daniel Jurgens (1): net/mlx5: Don't save PCI state when PCI error is detected Daniel Lezcano (1): thermal/drivers/step_wise: Fix temperature regulation misbehavior Dave Airlie (1): drm/amdgpu: fix parser init error path to avoid crash in parser fini David Ahern (1): net: mpls: Fix nexthop alive tracking on down events David Howells (10): rxrpc: Wake up the transmitter if Rx window size increases on the peer afs: Fix missing put_page() afs: Flush outstanding writes when an fd is closed afs: Fix the maths in afs_fs_store_data() afs: Invalid op ID should abort with RXGEN_OPCODE afs: Better abort and net error handling afs: Fix page leak in afs_write_begin() afs: Fix afs_kill_pages() afs: Fix abort on signal while waiting for call completion rxrpc: Ignore BUSY packets on old calls Dmitry Torokhov (1): Input: i8042 - add TUXEDO BU1406 (N24_25BU) to the nomux list Dmitry Vyukov (2): tty: don't panic on OOM in tty_set_ldisc() tty: fix data race in tty_ldisc_ref_wait() Don Brace (3): scsi: hpsa: update check for logical volume status scsi: hpsa: limit outstanding rescans scsi: hpsa: do not timeout reset operations Dou Liyang (1): Revert "x86/acpi: Set persistent cpuid <-> nodeid mapping when booting" Doug Berger (6): net: bcmgenet: correct the RBUF_OVFL_CNT and RBUF_ERR_CNT MIB values net: bcmgenet: correct MIB access of UniMAC RUNT counters net: bcmgenet: reserved phy revisions must be checked first net: bcmgenet: power down internal phy if open or resume fails net: bcmgenet: synchronize irq0 status between the isr and task net: bcmgenet: Power up the internal PHY before probing the MII Douglas Gilbert (1): scsi: scsi_debug: write_same: fix error report Eryu Guan (1): xfs: truncate pagecache before writeback in xfs_setattr_size() Florian Westphal (1): netfilter: bridge: honor frag_max_size when refragmenting Gao Feng (1): ppp: Destroy the mutex when cleanup Gary R Hook (1): iommu/amd: Limit the IOVA page range to the specified addresses Geert Uytterhoeven (1): fbdev: controlfb: Add missing modes to fix out of bounds access Guoqing Jiang (1): md-cluster: free md_cluster_info if node leave cluster Hiroyuki Yokoyama (2): ASoC: rsnd: fix sound route path when using SRC6/SRC9 dmaengine: rcar-dmac: use TCRB instead of TCR for residue Jack Morgenstein (1): net/mlx4_core: Avoid delays during VF driver device shutdown Jan Kara (2): mm: Handle 0 flags in _calc_vm_trans() macro udf: Avoid overflow when session starts at large offset Javier Martinez Canillas (1): usb: phy: isp1301: Add OF device ID table Jia-Ju Bai (3): vt6655: Fix a possible sleep-in-atomic bug in vt6655_suspend rtl8188eu: Fix a possible sleep-in-atomic bug in rtw_createbss_cmd rtl8188eu: Fix a possible sleep-in-atomic bug in rtw_disassoc_cmd Jiang Yi (1): target/file: Do not return error for UNMAP if length is zero Jiri Pirko (2): mlxsw: reg: Fix SPVM max record count mlxsw: reg: Fix SPVMLR max record count Jiri Slaby (1): l2tp: cleanup l2tp_tunnel_delete calls Johan Hovold (1): net: wimax/i2400m: fix NULL-deref at probe KUWAZAWA Takuya (1): netfilter: ipvs: Fix inappropriate output of procfs Kuninori Morimoto (2): ASoC: rcar: clear DE bit only in PDMACHCR when it stops ASoC: rsnd: rsnd_ssi_run_mods() needs to care ssi_parent_mod Kuppuswamy Sathyanarayanan (1): platform/x86: intel_punit_ipc: Fix resource ioremap warning Kurt Garloff (1): scsi: scsi_devinfo: Add REPORTLUN2 to EMC SYMMETRIX blacklist entry Ladislav Michl (1): video: udlfb: Fix read EDID timeout Leo Yan (1): clk: hi6220: mark clock cs_atb_syspll as critical Leon Romanovsky (1): RDMA/cxgb4: Declare stag as __be32 Liang Chen (1): bcache: explicitly destroy mutex while exiting Linus Walleij (1): pinctrl: adi2: Fix Kconfig build problem Liu Bo (1): badblocks: fix wrong return value in badblocks_set if badblocks are disabled Marc Dionne (4): afs: Populate group ID from vnode status afs: Adjust mode bits processing afs: Deal with an empty callback array afs: Populate and use client modification time Markus Elfring (1): platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill() Martin Wilck (2): scsi: hpsa: cleanup sas_phy structures in sysfs when unloading scsi: hpsa: destroy sas transport properties before scsi_host Matteo Croce (1): icmp: don't fail on fragment reassembly time exceeded Matthias Brugger (2): iommu/mediatek: Fix driver name soc: mediatek: pwrap: fix compiler errors Matthias Kaehlcke (1): dmaengine: Fix array index out of bounds warning in __get_unmap_pool() Miaoqing Pan (1): ath9k: fix tx99 potential info leak Michael Chan (1): bnxt_en: Ignore 0 value in autoneg supported speed from firmware. Michael Ellerman (1): powerpc/perf/hv-24x7: Fix incorrect comparison in memord Michał Mirosław (1): clk: tegra: Fix cclk_lp divisor register Mika Westerberg (1): PCI: Do not allocate more buses than available in parent Mike Christie (3): target: Use system workqueue for ALUA transitions target: fix ALUA transition timeout handling target: fix race during implicit transition work flushes Mintz, Yuval (1): qed: Fix mapping leak on LL2 rx flow NeilBrown (3): NFSD: fix nfsd_minorversion(.., NFSD_AVAIL) NFSD: fix nfsd_reset_versions for NFSv4. raid5: Set R5_Expanded on parity devices as well as data. Nick Desaulniers (1): arm64: prevent regressions in compressed kernel image size when upgrading to binutils 2.27 Oleksandr Tyshchenko (1): iommu/io-pgtable-arm-v7s: Check for leaf entry before dereferencing it Olga Kornievskaia (1): NFSv4.1 respect server's max size in CREATE_SESSION Osama Khan (1): platform/x86: hp_accel: Add quirk for HP ProBook 440 G4 Pankaj Bharadiya (1): ASoC: Intel: Skylake: Fix uuid_module memory leak in failure case Parav Pandit (1): IB/core: Fix calculation of maximum RoCE MTU Patel Jay P (1): Ib/hfi1: Return actual operational VLs in port info query Paul Blakey (1): net/mlx5: Fix create autogroup prev initializer Peter Ujfalusi (1): dmaengine: ti-dma-crossbar: Correct am335x/am43xx mux value type Philipp Zabel (1): rtc: pcf8563: fix output clock rate Qiang (1): PCI/PME: Handle invalid data when reading Root Status Radim Krčmář (1): KVM: nVMX: do not warn when MSR bitmap address is not backed Ram Amrani (2): qed: Align CIDs according to DORQ requirement qed: Fix interrupt flags on Rx LL2 Robert Baronescu (1): crypto: tcrypt - fix buffer lengths in test_aead_speed() Robert Stonehouse (1): sfc: don't warn on successful change of MAC Sagi Grimberg (4): blk-mq: Fix tagset reinit in the presence of cpu hot-unplug nvme-loop: fix a possible use-after-free when destroying the admin queue nvmet: confirm sq percpu has scheduled and switched to atomic nvmet-rdma: Fix a possible uninitialized variable dereference Sara Sharon (1): iwlwifi: mvm: cleanup pending frames in DQA mode Shriya (1): powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo Stafford Horne (1): openrisc: fix issue handling 8 byte get_user calls Steven Rostedt (VMware) (1): sched/deadline: Use deadline instead of period when calculating overflow Suzuki K Poulose (1): arm-ccn: perf: Prevent module unload while PMU is in use Sébastien Szymanski (2): HID: cp2112: fix broken gpio_direction_input callback clk: imx6: refine hdmi_isfr's parent to make HDMI work on i.MX6 SoCs w/o VPU Tahsin Erdogan (1): writeback: fix memory leak in wb_queue_work() Taku Izumi (1): fjes: Fix wrong netdevice feature flags Tina Ruchandani (2): afs: Migrate vlocation fields to 64-bit afs: Prevent callback expiry timer overflow Tomi Valkeinen (1): drm/omap: fix dmabuf mmap for dma_alloc'ed buffers Vitaly Kuznetsov (1): Drivers: hv: util: move waiting for release to hv_utils_transport itself Vlad Yasevich (1): net: Resend IGMP memberships upon peer notification. Wanpeng Li (1): sched/deadline: Add missing update_rq_clock() in dl_task_timer() William A. Kennington III (1): powerpc/opal: Fix EBUSY bug in acquiring tokens Zygo Blaxell (1): btrfs: add missing memset while reading compressed inline extents nixiaoming (1): tty fix oops when rmmod 8250 tang.junhui (1): bcache: fix wrong cache_misses statistics tangwenji (2): iscsi-target: fix memory leak in lio_target_tiqn_addtpg() target:fix condition return in core_pr_dump_initiator_port() weiping zhang (2): scsi: sd: change manage_start_stop to bool in sysfs interface scsi: sd: change allow_restart to bool in sysfs interface yong mao (1): mmc: mediatek: Fixed bug where clock frequency could be set wrong arch/arm64/Makefile | 8 +- arch/blackfin/Kconfig | 7 +- arch/blackfin/Kconfig.debug | 1 + arch/openrisc/include/asm/uaccess.h | 2 +- arch/powerpc/perf/hv-24x7.c | 2 +- arch/powerpc/platforms/powernv/opal-async.c | 6 +- arch/powerpc/platforms/powernv/setup.c | 2 +- arch/powerpc/sysdev/ipic.c | 4 +- arch/x86/kernel/acpi/boot.c | 2 +- arch/x86/kvm/vmx.c | 4 +- block/badblocks.c | 2 +- block/blk-mq-tag.c | 3 + crypto/tcrypt.c | 6 +- drivers/acpi/acpi_processor.c | 5 - drivers/acpi/bus.c | 1 - drivers/acpi/processor_core.c | 73 ---------- drivers/bus/arm-ccn.c | 1 + drivers/clk/hisilicon/clk-hi6220.c | 2 +- drivers/clk/imx/clk-imx6q.c | 2 +- drivers/clk/mediatek/clk-mtk.h | 1 + drivers/clk/mediatek/clk-pll.c | 5 +- drivers/clk/tegra/clk-tegra30.c | 2 +- drivers/dma/dmaengine.c | 2 + drivers/dma/sh/rcar-dmac.c | 2 +- drivers/dma/ti-dma-crossbar.c | 8 +- drivers/firmware/efi/efi.c | 1 - drivers/firmware/efi/esrt.c | 2 +- drivers/gpu/drm/amd/acp/Makefile | 2 - drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 + drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 3 - drivers/gpu/drm/radeon/si_dpm.c | 10 ++ drivers/hid/hid-cp2112.c | 8 +- drivers/hv/hv_fcopy.c | 4 - drivers/hv/hv_kvp.c | 4 - drivers/hv/hv_snapshot.c | 4 - drivers/hv/hv_utils_transport.c | 12 +- drivers/hv/hv_utils_transport.h | 1 + drivers/hwtracing/intel_th/pci.c | 5 + drivers/infiniband/core/cma.c | 11 +- drivers/infiniband/hw/cxgb4/t4.h | 2 +- drivers/infiniband/hw/hfi1/chip.c | 2 +- drivers/infiniband/ulp/ipoib/ipoib_ib.c | 7 +- drivers/input/serio/i8042-x86ia64io.h | 7 + drivers/iommu/amd_iommu.c | 2 +- drivers/iommu/io-pgtable-arm-v7s.c | 6 +- drivers/iommu/mtk_iommu_v1.c | 2 +- drivers/irqchip/Kconfig | 1 + drivers/md/bcache/request.c | 6 +- drivers/md/bcache/super.c | 6 +- drivers/md/md-cluster.c | 1 + drivers/md/raid5.c | 5 +- drivers/mmc/host/mtk-sd.c | 4 +- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 5 +- drivers/net/ethernet/broadcom/genet/bcmgenet.c | 168 +++++++++++++++------- drivers/net/ethernet/broadcom/genet/bcmgenet.h | 16 ++- drivers/net/ethernet/mellanox/mlx4/cmd.c | 11 ++ drivers/net/ethernet/mellanox/mlx4/main.c | 11 ++ drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 2 +- drivers/net/ethernet/mellanox/mlx5/core/main.c | 5 +- drivers/net/ethernet/mellanox/mlxsw/reg.h | 4 +- drivers/net/ethernet/qlogic/qed/qed_cxt.c | 3 +- drivers/net/ethernet/qlogic/qed/qed_ll2.c | 11 +- drivers/net/ethernet/sfc/ef10.c | 2 +- drivers/net/fjes/fjes_main.c | 2 +- drivers/net/macvlan.c | 2 +- drivers/net/ppp/ppp_generic.c | 1 + drivers/net/wimax/i2400m/usb.c | 3 + drivers/net/wireless/ath/ath9k/tx99.c | 5 + drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 5 +- drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 11 +- drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 2 +- drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 41 +++--- drivers/nvme/host/core.c | 3 +- drivers/nvme/target/core.c | 11 +- drivers/nvme/target/loop.c | 2 +- drivers/nvme/target/nvmet.h | 1 + drivers/nvme/target/rdma.c | 8 +- drivers/pci/pcie/pme.c | 5 +- drivers/pci/probe.c | 7 +- drivers/pci/remove.c | 2 +- drivers/pinctrl/Kconfig | 3 +- drivers/platform/x86/hp_accel.c | 1 + drivers/platform/x86/intel_punit_ipc.c | 8 +- drivers/platform/x86/sony-laptop.c | 14 +- drivers/rtc/rtc-pcf8563.c | 2 +- drivers/scsi/bfa/bfad_debugfs.c | 5 +- drivers/scsi/hpsa.c | 59 ++++---- drivers/scsi/hpsa.h | 1 + drivers/scsi/hpsa_cmd.h | 2 + drivers/scsi/scsi_debug.c | 6 +- drivers/scsi/scsi_devinfo.c | 2 +- drivers/scsi/sd.c | 12 +- drivers/soc/mediatek/mtk-pmic-wrap.c | 2 +- drivers/staging/rtl8188eu/core/rtw_cmd.c | 4 +- drivers/staging/vt6655/device_main.c | 3 +- drivers/target/iscsi/iscsi_target.c | 3 +- drivers/target/iscsi/iscsi_target_configfs.c | 3 +- drivers/target/target_core_alua.c | 33 ++--- drivers/target/target_core_file.c | 4 + drivers/target/target_core_pr.c | 4 +- drivers/thermal/step_wise.c | 11 +- drivers/tty/tty_ldisc.c | 92 +++--------- drivers/usb/host/xhci-mtk.c | 6 +- drivers/usb/phy/phy-isp1301.c | 7 + drivers/video/fbdev/au1200fb.c | 7 +- drivers/video/fbdev/controlfb.h | 2 + drivers/video/fbdev/udlfb.c | 10 +- fs/afs/callback.c | 7 +- fs/afs/cmservice.c | 11 +- fs/afs/file.c | 1 + fs/afs/fsclient.c | 22 +-- fs/afs/inode.c | 11 +- fs/afs/internal.h | 17 ++- fs/afs/misc.c | 2 + fs/afs/rxrpc.c | 52 ++++--- fs/afs/security.c | 7 +- fs/afs/server.c | 6 +- fs/afs/vlocation.c | 16 ++- fs/afs/write.c | 32 ++++- fs/btrfs/inode.c | 14 ++ fs/btrfs/tests/free-space-tree-tests.c | 3 +- fs/fs-writeback.c | 35 +++-- fs/gfs2/file.c | 4 +- fs/nfs/nfs4client.c | 4 +- fs/nfsd/nfssvc.c | 30 ++-- fs/proc/proc_tty.c | 3 +- fs/udf/super.c | 2 +- fs/userfaultfd.c | 2 +- fs/xfs/libxfs/xfs_bmap.c | 2 +- fs/xfs/xfs_iops.c | 36 ++--- fs/xfs/xfs_log_recover.c | 2 +- include/linux/acpi.h | 3 - include/linux/mlx4/device.h | 1 + include/linux/mman.h | 3 +- include/rdma/ib_addr.h | 7 +- include/rdma/ib_pack.h | 19 +-- include/target/target_core_base.h | 2 +- kernel/sched/deadline.c | 63 +++++++- net/bridge/br_netfilter_hooks.c | 12 +- net/core/dev.c | 1 + net/ipv4/icmp.c | 15 +- net/l2tp/l2tp_core.c | 2 +- net/l2tp/l2tp_netlink.c | 2 +- net/mpls/af_mpls.c | 13 +- net/netfilter/ipvs/ip_vs_ctl.c | 4 + net/rxrpc/conn_event.c | 4 + net/rxrpc/input.c | 15 +- net/socket.c | 1 + sound/soc/intel/skylake/skl-sst-utils.c | 15 +- sound/soc/sh/rcar/cmd.c | 36 ++--- sound/soc/sh/rcar/dma.c | 18 ++- sound/soc/sh/rcar/ssi.c | 11 +- tools/perf/util/symbol.c | 2 +- tools/testing/selftests/vm/Makefile | 4 + 154 files changed, 894 insertions(+), 608 deletions(-) -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaMqMnAAoJEN6mb/eXdyzcF+QP/280sLVKmyEUxsBZUeXh08JV 9W3LpSDa3MTKyQLZwBR1Xp/YgryvROK0woem5YwTaec/OYgaPadhugF2qCGpqu44 pJcbx1GjLZKt9zKG32ePU/tRdIzbJQYpsFemqOrprAL416kP34nQ9q0DweP8D39j jAGmBoE6kT5cwK0Ym1ALmxfyVh3jPrJEaVOXfCFDGCJnvKaGaOWWqckTRfUHpXEr xdkLOQdA9VnyGE5I+A+5sQ/xFWwnJsqyG/XiLZ7N4xCIi52qjCjOefCxrMttHUMv /rqASr8OViQDSHHriE9tzjL4BHb6FWbnpNMdteO15sEjGd9R5xGa7+aneEgsBROB X4qrv71fb85MQ2rM9xjk5RybBjBI0QWSXzwT8NOUtSYzSUYLscQkIx95pAylEurj sGBcvq5hvopyTnUdJ0LeBZm2zZWU/2NlaKNc3tXPaVOTQkRydiUF6z87mk8CqkxZ eUVrG6ZN+9ZgvlN3MOvzCojgUx0yoygXVfHT5+9ffio0jzAOPY9TQYS6M3jXP19I 1Dxv1YEVR39PKwK4aRHutRAQQMX6z9iRMqHgwRTkyQiM+xA+3k/qUp1G/U8mUgMt NvKXj0KLO52/MKxtloafIKaLLX7stpe4xWymNFmblXv+l/nnR40qZazRzRBVHmyS nxByMu+iC9dvW3igacXr =wXPp -----END PGP SIGNATURE-----

7 years, 6 months

2
1
0 0

[Linux-stable-mirror] [PATCH] crypto: af_alg - add keylen checking to avoid NULL ptr passing down

by Li Kun

alg_setkey do not check the keylen whether it is zero, so the key may be ZERO_SIZE_PTR when keylen is 0, which will pass the copy_from_user's checking and be passed to the lower functions as key. If the lower functions only check the key if it is NULL, ZERO_SIZE_PTR will pass the checking, and will cause null ptr dereference, so it's better to intercept the invalid parameters in the upper functions. This patch is also suitable to fix CVE-2017-15116 for stable trees. Signed-off-by: Li Kun <hw.likun(a)huawei.com> --- crypto/af_alg.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/crypto/af_alg.c b/crypto/af_alg.c index 337cf38..10f22f3 100644 --- a/crypto/af_alg.c +++ b/crypto/af_alg.c @@ -210,6 +210,8 @@ static int alg_setkey(struct sock *sk, char __user *ukey, u8 *key; int err; + if (!keylen) + return -EINVAL; key = sock_kmalloc(sk, keylen, GFP_KERNEL); if (!key) return -ENOMEM; -- 1.8.3.4

7 years, 6 months

2
2
0 0

[Linux-stable-mirror] Patch "xfs: truncate pagecache before writeback in xfs_setattr_size()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xfs: truncate pagecache before writeback in xfs_setattr_size() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: xfs-truncate-pagecache-before-writeback-in-xfs_setattr_size.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:35 CET 2017 From: Eryu Guan <eguan(a)redhat.com> Date: Wed, 1 Nov 2017 21:43:50 -0700 Subject: xfs: truncate pagecache before writeback in xfs_setattr_size() From: Eryu Guan <eguan(a)redhat.com> [ Upstream commit 350976ae21873b0d36584ea005076356431b8f79 ] On truncate down, if new size is not block size aligned, we zero the rest of block to avoid exposing stale data to user, and iomap_truncate_page() skips zeroing if the range is already in unwritten state or a hole. Then we writeback from on-disk i_size to the new size if this range hasn't been written to disk yet, and truncate page cache beyond new EOF and set in-core i_size. The problem is that we could write data between di_size and newsize before removing the page cache beyond newsize, as the extents may still be in unwritten state right after a buffer write. As such, the page of data that newsize lies in has not been zeroed by page cache invalidation before it is written, and xfs_do_writepage() hasn't triggered it's "zero data beyond EOF" case because we haven't updated in-core i_size yet. Then a subsequent mmap read could see non-zeros past EOF. I occasionally see this in fsx runs in fstests generic/112, a simplified fsx operation sequence is like (assuming 4k block size xfs): fallocate 0x0 0x1000 0x0 keep_size write 0x0 0x1000 0x0 truncate 0x0 0x800 0x1000 punch_hole 0x0 0x800 0x800 mapread 0x0 0x800 0x800 where fallocate allocates unwritten extent but doesn't update i_size, buffer write populates the page cache and extent is still unwritten, truncate skips zeroing page past new EOF and writes the page to disk, punch_hole invalidates the page cache, at last mapread reads the block back and sees non-zero beyond EOF. Fix it by moving truncate_setsize() to before writeback so the page cache invalidation zeros the partial page at the new EOF. This also triggers "zero data beyond EOF" in xfs_do_writepage() at writeback time, because newsize has been set and page straddles the newsize. Also fixed the wrong 'end' param of filemap_write_and_wait_range() call while we're at it, the 'end' is inclusive and should be 'newsize - 1'. Suggested-by: Dave Chinner <dchinner(a)redhat.com> Signed-off-by: Eryu Guan <eguan(a)redhat.com> Acked-by: Dave Chinner <dchinner(a)redhat.com> Reviewed-by: Brian Foster <bfoster(a)redhat.com> Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/xfs/xfs_iops.c | 36 ++++++++++++++++++++---------------- 1 file changed, 20 insertions(+), 16 deletions(-) --- a/fs/xfs/xfs_iops.c +++ b/fs/xfs/xfs_iops.c @@ -871,22 +871,6 @@ xfs_setattr_size( return error; /* - * We are going to log the inode size change in this transaction so - * any previous writes that are beyond the on disk EOF and the new - * EOF that have not been written out need to be written here. If we - * do not write the data out, we expose ourselves to the null files - * problem. Note that this includes any block zeroing we did above; - * otherwise those blocks may not be zeroed after a crash. - */ - if (did_zeroing || - (newsize > ip->i_d.di_size && oldsize != ip->i_d.di_size)) { - error = filemap_write_and_wait_range(VFS_I(ip)->i_mapping, - ip->i_d.di_size, newsize); - if (error) - return error; - } - - /* * We've already locked out new page faults, so now we can safely remove * pages from the page cache knowing they won't get refaulted until we * drop the XFS_MMAP_EXCL lock after the extent manipulations are @@ -902,9 +886,29 @@ xfs_setattr_size( * user visible changes). There's not much we can do about this, except * to hope that the caller sees ENOMEM and retries the truncate * operation. + * + * And we update in-core i_size and truncate page cache beyond newsize + * before writeback the [di_size, newsize] range, so we're guaranteed + * not to write stale data past the new EOF on truncate down. */ truncate_setsize(inode, newsize); + /* + * We are going to log the inode size change in this transaction so + * any previous writes that are beyond the on disk EOF and the new + * EOF that have not been written out need to be written here. If we + * do not write the data out, we expose ourselves to the null files + * problem. Note that this includes any block zeroing we did above; + * otherwise those blocks may not be zeroed after a crash. + */ + if (did_zeroing || + (newsize > ip->i_d.di_size && oldsize != ip->i_d.di_size)) { + error = filemap_write_and_wait_range(VFS_I(ip)->i_mapping, + ip->i_d.di_size, newsize - 1); + if (error) + return error; + } + error = xfs_trans_alloc(mp, &M_RES(mp)->tr_itruncate, 0, 0, 0, &tp); if (error) return error; Patches currently in stable-queue which might be from eguan(a)redhat.com are queue-4.9/ext4-fix-fdatasync-2-after-fallocate-2-operation.patch queue-4.9/xfs-truncate-pagecache-before-writeback-in-xfs_setattr_size.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "xfs: fix log block underflow during recovery cycle verification" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xfs: fix log block underflow during recovery cycle verification to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: xfs-fix-log-block-underflow-during-recovery-cycle-verification.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:35 CET 2017 From: Brian Foster <bfoster(a)redhat.com> Date: Thu, 26 Oct 2017 09:31:16 -0700 Subject: xfs: fix log block underflow during recovery cycle verification From: Brian Foster <bfoster(a)redhat.com> [ Upstream commit 9f2a4505800607e537e9dd9dea4f55c4b0c30c7a ] It is possible for mkfs to format very small filesystems with too small of an internal log with respect to the various minimum size and block count requirements. If this occurs when the log happens to be smaller than the scan window used for cycle verification and the scan wraps the end of the log, the start_blk calculation in xlog_find_head() underflows and leads to an attempt to scan an invalid range of log blocks. This results in log recovery failure and a failed mount. Since there may be filesystems out in the wild with this kind of geometry, we cannot simply refuse to mount. Instead, cap the scan window for cycle verification to the size of the physical log. This ensures that the cycle verification proceeds as expected when the scan wraps the end of the log. Reported-by: Zorro Lang <zlang(a)redhat.com> Signed-off-by: Brian Foster <bfoster(a)redhat.com> Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/xfs/xfs_log_recover.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/xfs/xfs_log_recover.c +++ b/fs/xfs/xfs_log_recover.c @@ -753,7 +753,7 @@ xlog_find_head( * in the in-core log. The following number can be made tighter if * we actually look at the block size of the filesystem. */ - num_scan_bblks = XLOG_TOTAL_REC_SHIFT(log); + num_scan_bblks = min_t(int, log_bbnum, XLOG_TOTAL_REC_SHIFT(log)); if (head_blk >= num_scan_bblks) { /* * We are guaranteed that the entire check can be performed Patches currently in stable-queue which might be from bfoster(a)redhat.com are queue-4.9/xfs-fix-incorrect-extent-state-in-xfs_bmap_add_extent_unwritten_real.patch queue-4.9/xfs-fix-log-block-underflow-during-recovery-cycle-verification.patch queue-4.9/xfs-truncate-pagecache-before-writeback-in-xfs_setattr_size.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "xfs: fix incorrect extent state in xfs_bmap_add_extent_unwritten_real" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xfs: fix incorrect extent state in xfs_bmap_add_extent_unwritten_real to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: xfs-fix-incorrect-extent-state-in-xfs_bmap_add_extent_unwritten_real.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:35 CET 2017 From: Christoph Hellwig <hch(a)lst.de> Date: Tue, 17 Oct 2017 14:16:19 -0700 Subject: xfs: fix incorrect extent state in xfs_bmap_add_extent_unwritten_real From: Christoph Hellwig <hch(a)lst.de> [ Upstream commit 5e422f5e4fd71d18bc6b851eeb3864477b3d842e ] There was one spot in xfs_bmap_add_extent_unwritten_real that didn't use the passed in new extent state but always converted to normal, leading to wrong behavior when converting from normal to unwritten. Only found by code inspection, it seems like this code path to move partial extent from written to unwritten while merging it with the next extent is rarely exercised. Signed-off-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Brian Foster <bfoster(a)redhat.com> Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/xfs/libxfs/xfs_bmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/xfs/libxfs/xfs_bmap.c +++ b/fs/xfs/libxfs/xfs_bmap.c @@ -2713,7 +2713,7 @@ xfs_bmap_add_extent_unwritten_real( &i))) goto done; XFS_WANT_CORRUPTED_GOTO(mp, i == 0, done); - cur->bc_rec.b.br_state = XFS_EXT_NORM; + cur->bc_rec.b.br_state = new->br_state; if ((error = xfs_btree_insert(cur, &i))) goto done; XFS_WANT_CORRUPTED_GOTO(mp, i == 1, done); Patches currently in stable-queue which might be from hch(a)lst.de are queue-4.9/xfs-fix-incorrect-extent-state-in-xfs_bmap_add_extent_unwritten_real.patch queue-4.9/nvmet-confirm-sq-percpu-has-scheduled-and-switched-to-atomic.patch queue-4.9/nvme-use-kref_get_unless_zero-in-nvme_find_get_ns.patch queue-4.9/target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch queue-4.9/nvme-loop-fix-a-possible-use-after-free-when-destroying-the-admin-queue.patch queue-4.9/nvmet-rdma-fix-a-possible-uninitialized-variable-dereference.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "writeback: fix memory leak in wb_queue_work()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled writeback: fix memory leak in wb_queue_work() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: writeback-fix-memory-leak-in-wb_queue_work.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Tahsin Erdogan <tahsin(a)google.com> Date: Fri, 10 Mar 2017 12:09:49 -0800 Subject: writeback: fix memory leak in wb_queue_work() From: Tahsin Erdogan <tahsin(a)google.com> [ Upstream commit 4a3a485b1ed0e109718cc8c9d094fa0f552de9b2 ] When WB_registered flag is not set, wb_queue_work() skips queuing the work, but does not perform the necessary clean up. In particular, if work->auto_free is true, it should free the memory. The leak condition can be reprouced by following these steps: mount /dev/sdb /mnt/sdb /* In qemu console: device_del sdb */ umount /dev/sdb Above will result in a wb_queue_work() call on an unregistered wb and thus leak memory. Reported-by: John Sperbeck <jsperbeck(a)google.com> Signed-off-by: Tahsin Erdogan <tahsin(a)google.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Jens Axboe <axboe(a)fb.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/fs-writeback.c | 35 +++++++++++++++++++++-------------- 1 file changed, 21 insertions(+), 14 deletions(-) --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -173,19 +173,33 @@ static void wb_wakeup(struct bdi_writeba spin_unlock_bh(&wb->work_lock); } +static void finish_writeback_work(struct bdi_writeback *wb, + struct wb_writeback_work *work) +{ + struct wb_completion *done = work->done; + + if (work->auto_free) + kfree(work); + if (done && atomic_dec_and_test(&done->cnt)) + wake_up_all(&wb->bdi->wb_waitq); +} + static void wb_queue_work(struct bdi_writeback *wb, struct wb_writeback_work *work) { trace_writeback_queue(wb, work); - spin_lock_bh(&wb->work_lock); - if (!test_bit(WB_registered, &wb->state)) - goto out_unlock; if (work->done) atomic_inc(&work->done->cnt); - list_add_tail(&work->list, &wb->work_list); - mod_delayed_work(bdi_wq, &wb->dwork, 0); -out_unlock: + + spin_lock_bh(&wb->work_lock); + + if (test_bit(WB_registered, &wb->state)) { + list_add_tail(&work->list, &wb->work_list); + mod_delayed_work(bdi_wq, &wb->dwork, 0); + } else + finish_writeback_work(wb, work); + spin_unlock_bh(&wb->work_lock); } @@ -1875,16 +1889,9 @@ static long wb_do_writeback(struct bdi_w set_bit(WB_writeback_running, &wb->state); while ((work = get_next_work_item(wb)) != NULL) { - struct wb_completion *done = work->done; - trace_writeback_exec(wb, work); - wrote += wb_writeback(wb, work); - - if (work->auto_free) - kfree(work); - if (done && atomic_dec_and_test(&done->cnt)) - wake_up_all(&wb->bdi->wb_waitq); + finish_writeback_work(wb, work); } /* Patches currently in stable-queue which might be from tahsin(a)google.com are queue-4.9/writeback-fix-memory-leak-in-wb_queue_work.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "vt6655: Fix a possible sleep-in-atomic bug in vt6655_suspend" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled vt6655: Fix a possible sleep-in-atomic bug in vt6655_suspend to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: vt6655-fix-a-possible-sleep-in-atomic-bug-in-vt6655_suspend.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:35 CET 2017 From: Jia-Ju Bai <baijiaju1990(a)163.com> Date: Mon, 9 Oct 2017 16:45:55 +0800 Subject: vt6655: Fix a possible sleep-in-atomic bug in vt6655_suspend From: Jia-Ju Bai <baijiaju1990(a)163.com> [ Upstream commit 42c8eb3f6e15367981b274cb79ee4657e2c6949d ] The driver may sleep under a spinlock, and the function call path is: vt6655_suspend (acquire the spinlock) pci_set_power_state __pci_start_power_transition (drivers/pci/pci.c) msleep --> may sleep To fix it, pci_set_power_state is called without having a spinlock. This bug is found by my static analysis tool and my code review. Signed-off-by: Jia-Ju Bai <baijiaju1990(a)163.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/vt6655/device_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/staging/vt6655/device_main.c +++ b/drivers/staging/vt6655/device_main.c @@ -1698,10 +1698,11 @@ static int vt6655_suspend(struct pci_dev MACbShutdown(priv); pci_disable_device(pcid); - pci_set_power_state(pcid, pci_choose_state(pcid, state)); spin_unlock_irqrestore(&priv->lock, flags); + pci_set_power_state(pcid, pci_choose_state(pcid, state)); + return 0; } Patches currently in stable-queue which might be from baijiaju1990(a)163.com are queue-4.9/rtl8188eu-fix-a-possible-sleep-in-atomic-bug-in-rtw_createbss_cmd.patch queue-4.9/rtl8188eu-fix-a-possible-sleep-in-atomic-bug-in-rtw_disassoc_cmd.patch queue-4.9/vt6655-fix-a-possible-sleep-in-atomic-bug-in-vt6655_suspend.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "video: udlfb: Fix read EDID timeout" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled video: udlfb: Fix read EDID timeout to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: video-udlfb-fix-read-edid-timeout.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Ladislav Michl <ladis(a)linux-mips.org> Date: Thu, 9 Nov 2017 18:09:30 +0100 Subject: video: udlfb: Fix read EDID timeout From: Ladislav Michl <ladis(a)linux-mips.org> [ Upstream commit c98769475575c8a585f5b3952f4b5f90266f699b ] While usb_control_msg function expects timeout in miliseconds, a value of HZ is used. Replace it with USB_CTRL_GET_TIMEOUT and also fix error message which looks like: udlfb: Read EDID byte 78 failed err ffffff92 as error is either negative errno or number of bytes transferred use %d format specifier. Returned EDID is in second byte, so return error when less than two bytes are received. Fixes: 18dffdf8913a ("staging: udlfb: enhance EDID and mode handling support") Signed-off-by: Ladislav Michl <ladis(a)linux-mips.org> Cc: Bernie Thompson <bernie(a)plugable.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/fbdev/udlfb.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- a/drivers/video/fbdev/udlfb.c +++ b/drivers/video/fbdev/udlfb.c @@ -769,11 +769,11 @@ static int dlfb_get_edid(struct dlfb_dat for (i = 0; i < len; i++) { ret = usb_control_msg(dev->udev, - usb_rcvctrlpipe(dev->udev, 0), (0x02), - (0x80 | (0x02 << 5)), i << 8, 0xA1, rbuf, 2, - HZ); - if (ret < 1) { - pr_err("Read EDID byte %d failed err %x\n", i, ret); + usb_rcvctrlpipe(dev->udev, 0), 0x02, + (0x80 | (0x02 << 5)), i << 8, 0xA1, + rbuf, 2, USB_CTRL_GET_TIMEOUT); + if (ret < 2) { + pr_err("Read EDID byte %d failed: %d\n", i, ret); i--; break; } Patches currently in stable-queue which might be from ladis(a)linux-mips.org are queue-4.9/video-udlfb-fix-read-edid-timeout.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "video: fbdev: au1200fb: Return an error code if a memory allocation fails" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled video: fbdev: au1200fb: Return an error code if a memory allocation fails to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: video-fbdev-au1200fb-return-an-error-code-if-a-memory-allocation-fails.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Thu, 9 Nov 2017 18:09:28 +0100 Subject: video: fbdev: au1200fb: Return an error code if a memory allocation fails From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> [ Upstream commit 8cae353e6b01ac3f18097f631cdbceb5ff28c7f3 ] 'ret' is known to be 0 at this point. In case of memory allocation error in 'framebuffer_alloc()', return -ENOMEM instead. Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Cc: Tejun Heo <tj(a)kernel.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/fbdev/au1200fb.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/video/fbdev/au1200fb.c +++ b/drivers/video/fbdev/au1200fb.c @@ -1681,8 +1681,10 @@ static int au1200fb_drv_probe(struct pla fbi = framebuffer_alloc(sizeof(struct au1200fb_device), &dev->dev); - if (!fbi) + if (!fbi) { + ret = -ENOMEM; goto failed; + } _au1200fb_infos[plane] = fbi; fbdev = fbi->par; Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-4.9/video-fbdev-au1200fb-release-some-resources-if-a-memory-allocation-fails.patch queue-4.9/video-fbdev-au1200fb-return-an-error-code-if-a-memory-allocation-fails.patch queue-4.9/btrfs-tests-fix-a-memory-leak-in-error-handling-path-in-run_test.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "video: fbdev: au1200fb: Release some resources if a memory allocation fails" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled video: fbdev: au1200fb: Release some resources if a memory allocation fails to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: video-fbdev-au1200fb-release-some-resources-if-a-memory-allocation-fails.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Thu, 9 Nov 2017 18:09:28 +0100 Subject: video: fbdev: au1200fb: Release some resources if a memory allocation fails From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> [ Upstream commit 451f130602619a17c8883dd0b71b11624faffd51 ] We should go through the error handling code instead of returning -ENOMEM directly. Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Cc: Tejun Heo <tj(a)kernel.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/fbdev/au1200fb.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/video/fbdev/au1200fb.c +++ b/drivers/video/fbdev/au1200fb.c @@ -1700,7 +1700,8 @@ static int au1200fb_drv_probe(struct pla if (!fbdev->fb_mem) { print_err("fail to allocate frambuffer (size: %dK))", fbdev->fb_len / 1024); - return -ENOMEM; + ret = -ENOMEM; + goto failed; } /* Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-4.9/video-fbdev-au1200fb-release-some-resources-if-a-memory-allocation-fails.patch queue-4.9/video-fbdev-au1200fb-return-an-error-code-if-a-memory-allocation-fails.patch queue-4.9/btrfs-tests-fix-a-memory-leak-in-error-handling-path-in-run_test.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "userfaultfd: shmem: __do_fault requires VM_FAULT_NOPAGE" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled userfaultfd: shmem: __do_fault requires VM_FAULT_NOPAGE to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: userfaultfd-shmem-__do_fault-requires-vm_fault_nopage.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Andrea Arcangeli <aarcange(a)redhat.com> Date: Thu, 9 Mar 2017 16:16:28 -0800 Subject: userfaultfd: shmem: __do_fault requires VM_FAULT_NOPAGE From: Andrea Arcangeli <aarcange(a)redhat.com> [ Upstream commit 6bbc4a4144b1a69743022ac68dfaf6e7d993abb9 ] __do_fault assumes vmf->page has been initialized and is valid if VM_FAULT_NOPAGE is not returned by vma->vm_ops->fault(vma, vmf). handle_userfault() in turn should return VM_FAULT_NOPAGE if it doesn't return VM_FAULT_SIGBUS or VM_FAULT_RETRY (the other two possibilities). This VM_FAULT_NOPAGE case is only invoked when signal are pending and it didn't matter for anonymous memory before. It only started to matter since shmem was introduced. hugetlbfs also takes a different path and doesn't exercise __do_fault. Link: http://lkml.kernel.org/r/20170228154201.GH5816@redhat.com Signed-off-by: Andrea Arcangeli <aarcange(a)redhat.com> Reported-by: Dmitry Vyukov <dvyukov(a)google.com> Cc: "Kirill A. Shutemov" <kirill(a)shutemov.name> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/userfaultfd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/userfaultfd.c +++ b/fs/userfaultfd.c @@ -419,7 +419,7 @@ int handle_userfault(struct fault_env *f * in such case. */ down_read(&mm->mmap_sem); - ret = 0; + ret = VM_FAULT_NOPAGE; } } Patches currently in stable-queue which might be from aarcange(a)redhat.com are queue-4.9/userfaultfd-selftest-vm-allow-to-build-in-vm-directory.patch queue-4.9/userfaultfd-shmem-__do_fault-requires-vm_fault_nopage.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "userfaultfd: selftest: vm: allow to build in vm/ directory" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled userfaultfd: selftest: vm: allow to build in vm/ directory to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: userfaultfd-selftest-vm-allow-to-build-in-vm-directory.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Andrea Arcangeli <aarcange(a)redhat.com> Date: Thu, 9 Mar 2017 16:17:14 -0800 Subject: userfaultfd: selftest: vm: allow to build in vm/ directory From: Andrea Arcangeli <aarcange(a)redhat.com> [ Upstream commit 46aa6a302b53f543f8e8b8e1714dc5e449ad36a6 ] linux/tools/testing/selftests/vm $ make gcc -Wall -I ../../../../usr/include compaction_test.c -lrt -o /compaction_test /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/../../../../x86_64-pc-linux-gnu/bin/ld: cannot open output file /compaction_test: Permission denied collect2: error: ld returned 1 exit status make: *** [../lib.mk:54: /compaction_test] Error 1 Since commit a8ba798bc8ec ("selftests: enable O and KBUILD_OUTPUT") selftests/vm build fails if run from the "selftests/vm" directory, but it works in the selftests/ directory. It's quicker to be able to do a local vm-only build after a tree wipe and this patch allows for it again. Link: http://lkml.kernel.org/r/20170302173738.18994-4-aarcange@redhat.com Signed-off-by: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Mike Rapoport <rppt(a)linux.vnet.ibm.com> Cc: "Dr. David Alan Gilbert" <dgilbert(a)redhat.com> Cc: Mike Kravetz <mike.kravetz(a)oracle.com> Cc: Pavel Emelyanov <xemul(a)parallels.com> Cc: Hillf Danton <hillf.zj(a)alibaba-inc.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/vm/Makefile | 4 ++++ 1 file changed, 4 insertions(+) --- a/tools/testing/selftests/vm/Makefile +++ b/tools/testing/selftests/vm/Makefile @@ -1,5 +1,9 @@ # Makefile for vm selftests +ifndef OUTPUT + OUTPUT := $(shell pwd) +endif + CFLAGS = -Wall -I ../../../../usr/include $(EXTRA_CFLAGS) BINARIES = compaction_test BINARIES += hugepage-mmap Patches currently in stable-queue which might be from aarcange(a)redhat.com are queue-4.9/userfaultfd-selftest-vm-allow-to-build-in-vm-directory.patch queue-4.9/userfaultfd-shmem-__do_fault-requires-vm_fault_nopage.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: xhci-mtk: check hcc_params after adding primary hcd" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: xhci-mtk: check hcc_params after adding primary hcd to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-xhci-mtk-check-hcc_params-after-adding-primary-hcd.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Chunfeng Yun <chunfeng.yun(a)mediatek.com> Date: Thu, 9 Mar 2017 15:39:34 +0200 Subject: usb: xhci-mtk: check hcc_params after adding primary hcd From: Chunfeng Yun <chunfeng.yun(a)mediatek.com> [ Upstream commit 94a631d91ad341b3b4bdac72d1104d9f090e0ca9 ] hcc_params is set in xhci_gen_setup() called from usb_add_hcd(), so checks the Maximum Primary Stream Array Size in the hcc_params register after adding primary hcd. Signed-off-by: Chunfeng Yun <chunfeng.yun(a)mediatek.com> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/host/xhci-mtk.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/usb/host/xhci-mtk.c +++ b/drivers/usb/host/xhci-mtk.c @@ -632,13 +632,13 @@ static int xhci_mtk_probe(struct platfor goto power_off_phys; } - if (HCC_MAX_PSA(xhci->hcc_params) >= 4) - xhci->shared_hcd->can_do_streams = 1; - ret = usb_add_hcd(hcd, irq, IRQF_SHARED); if (ret) goto put_usb3_hcd; + if (HCC_MAX_PSA(xhci->hcc_params) >= 4) + xhci->shared_hcd->can_do_streams = 1; + ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED); if (ret) goto dealloc_usb2_hcd; Patches currently in stable-queue which might be from chunfeng.yun(a)mediatek.com are queue-4.9/usb-xhci-fix-tds-for-mtk-xhci1.1.patch queue-4.9/usb-xhci-mtk-check-hcc_params-after-adding-primary-hcd.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: phy: isp1301: Add OF device ID table" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: phy: isp1301: Add OF device ID table to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-phy-isp1301-add-of-device-id-table.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Javier Martinez Canillas <javier(a)osg.samsung.com> Date: Wed, 22 Feb 2017 15:23:22 -0300 Subject: usb: phy: isp1301: Add OF device ID table From: Javier Martinez Canillas <javier(a)osg.samsung.com> [ Upstream commit fd567653bdb908009b650f079bfd4b63169e2ac4 ] The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/phy/phy-isp1301.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/drivers/usb/phy/phy-isp1301.c +++ b/drivers/usb/phy/phy-isp1301.c @@ -33,6 +33,12 @@ static const struct i2c_device_id isp130 }; MODULE_DEVICE_TABLE(i2c, isp1301_id); +static const struct of_device_id isp1301_of_match[] = { + {.compatible = "nxp,isp1301" }, + { }, +}; +MODULE_DEVICE_TABLE(of, isp1301_of_match); + static struct i2c_client *isp1301_i2c_client; static int __isp1301_write(struct isp1301 *isp, u8 reg, u8 value, u8 clear) @@ -130,6 +136,7 @@ static int isp1301_remove(struct i2c_cli static struct i2c_driver isp1301_driver = { .driver = { .name = DRV_NAME, + .of_match_table = of_match_ptr(isp1301_of_match), }, .probe = isp1301_probe, .remove = isp1301_remove, Patches currently in stable-queue which might be from javier(a)osg.samsung.com are queue-4.9/usb-phy-isp1301-add-of-device-id-table.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "udf: Avoid overflow when session starts at large offset" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled udf: Avoid overflow when session starts at large offset to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: udf-avoid-overflow-when-session-starts-at-large-offset.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:35 CET 2017 From: Jan Kara <jack(a)suse.cz> Date: Mon, 16 Oct 2017 11:38:11 +0200 Subject: udf: Avoid overflow when session starts at large offset From: Jan Kara <jack(a)suse.cz> [ Upstream commit abdc0eb06964fe1d2fea6dd1391b734d0590365d ] When session starts beyond offset 2^31 the arithmetics in udf_check_vsd() would overflow. Make sure the computation is done in large enough type. Reported-by: Cezary Sliwa <sliwa(a)ifpan.edu.pl> Signed-off-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/udf/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/udf/super.c +++ b/fs/udf/super.c @@ -710,7 +710,7 @@ static loff_t udf_check_vsd(struct super else sectorsize = sb->s_blocksize; - sector += (sbi->s_session << sb->s_blocksize_bits); + sector += (((loff_t)sbi->s_session) << sb->s_blocksize_bits); udf_debug("Starting at sector %u (%ld byte sectors)\n", (unsigned int)(sector >> sb->s_blocksize_bits), Patches currently in stable-queue which might be from jack(a)suse.cz are queue-4.9/writeback-fix-memory-leak-in-wb_queue_work.patch queue-4.9/mm-handle-0-flags-in-_calc_vm_trans-macro.patch queue-4.9/udf-avoid-overflow-when-session-starts-at-large-offset.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "tty fix oops when rmmod 8250" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tty fix oops when rmmod 8250 to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: tty-fix-oops-when-rmmod-8250.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:35 CET 2017 From: nixiaoming <nixiaoming(a)huawei.com> Date: Fri, 15 Sep 2017 17:45:56 +0800 Subject: tty fix oops when rmmod 8250 From: nixiaoming <nixiaoming(a)huawei.com> [ Upstream commit c79dde629d2027ca80329c62854a7635e623d527 ] After rmmod 8250.ko tty_kref_put starts kwork (release_one_tty) to release proc interface oops when accessing driver->driver_name in proc_tty_unregister_driver Use jprobe, found driver->driver_name point to 8250.ko static static struct uart_driver serial8250_reg .driver_name= serial, Use name in proc_dir_entry instead of driver->driver_name to fix oops test on linux 4.1.12: BUG: unable to handle kernel paging request at ffffffffa01979de IP: [<ffffffff81310f40>] strchr+0x0/0x30 PGD 1a0d067 PUD 1a0e063 PMD 851c1f067 PTE 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: ... ... [last unloaded: 8250] CPU: 7 PID: 116 Comm: kworker/7:1 Tainted: G O 4.1.12 #1 Hardware name: Insyde RiverForest/Type2 - Board Product Name1, BIOS NE5KV904 12/21/2015 Workqueue: events release_one_tty task: ffff88085b684960 ti: ffff880852884000 task.ti: ffff880852884000 RIP: 0010:[<ffffffff81310f40>] [<ffffffff81310f40>] strchr+0x0/0x30 RSP: 0018:ffff880852887c90 EFLAGS: 00010282 RAX: ffffffff81a5eca0 RBX: ffffffffa01979de RCX: 0000000000000004 RDX: ffff880852887d10 RSI: 000000000000002f RDI: ffffffffa01979de RBP: ffff880852887cd8 R08: 0000000000000000 R09: ffff88085f5d94d0 R10: 0000000000000195 R11: 0000000000000000 R12: ffffffffa01979de R13: ffff880852887d00 R14: ffffffffa01979de R15: ffff88085f02e840 FS: 0000000000000000(0000) GS:ffff88085f5c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffa01979de CR3: 0000000001a0c000 CR4: 00000000001406e0 Stack: ffffffff812349b1 ffff880852887cb8 ffff880852887d10 ffff88085f5cd6c2 ffff880852800a80 ffffffffa01979de ffff880852800a84 0000000000000010 ffff88085bb28bd8 ffff880852887d38 ffffffff812354f0 ffff880852887d08 Call Trace: [<ffffffff812349b1>] ? __xlate_proc_name+0x71/0xd0 [<ffffffff812354f0>] remove_proc_entry+0x40/0x180 [<ffffffff815f6811>] ? _raw_spin_lock_irqsave+0x41/0x60 [<ffffffff813be520>] ? destruct_tty_driver+0x60/0xe0 [<ffffffff81237c68>] proc_tty_unregister_driver+0x28/0x40 [<ffffffff813be548>] destruct_tty_driver+0x88/0xe0 [<ffffffff813be5bd>] tty_driver_kref_put+0x1d/0x20 [<ffffffff813becca>] release_one_tty+0x5a/0xd0 [<ffffffff81074159>] process_one_work+0x139/0x420 [<ffffffff810745a1>] worker_thread+0x121/0x450 [<ffffffff81074480>] ? process_scheduled_works+0x40/0x40 [<ffffffff8107a16c>] kthread+0xec/0x110 [<ffffffff81080000>] ? tg_rt_schedulable+0x210/0x220 [<ffffffff8107a080>] ? kthread_freezable_should_stop+0x80/0x80 [<ffffffff815f7292>] ret_from_fork+0x42/0x70 [<ffffffff8107a080>] ? kthread_freezable_should_stop+0x80/0x80 Signed-off-by: nixiaoming <nixiaoming(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/proc/proc_tty.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/proc/proc_tty.c +++ b/fs/proc/proc_tty.c @@ -14,6 +14,7 @@ #include <linux/tty.h> #include <linux/seq_file.h> #include <linux/bitops.h> +#include "internal.h" /* * The /proc/tty directory inodes... @@ -164,7 +165,7 @@ void proc_tty_unregister_driver(struct t if (!ent) return; - remove_proc_entry(driver->driver_name, proc_tty_driver); + remove_proc_entry(ent->name, proc_tty_driver); driver->proc_entry = NULL; } Patches currently in stable-queue which might be from nixiaoming(a)huawei.com are queue-4.9/tty-fix-oops-when-rmmod-8250.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "tty: fix data race in tty_ldisc_ref_wait()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tty: fix data race in tty_ldisc_ref_wait() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: tty-fix-data-race-in-tty_ldisc_ref_wait.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Dmitry Vyukov <dvyukov(a)google.com> Date: Sat, 4 Mar 2017 13:46:12 +0100 Subject: tty: fix data race in tty_ldisc_ref_wait() From: Dmitry Vyukov <dvyukov(a)google.com> [ Upstream commit a4a3e061149f09c075f108b6f1cf04d9739a6bc2 ] tty_ldisc_ref_wait() checks tty->ldisc under tty->ldisc_sem. But if ldisc==NULL it releases them sem and reloads tty->ldisc without holding the sem. This is wrong and can lead to returning non-NULL ldisc without protection. Don't reload tty->ldisc second time. Signed-off-by: Dmitry Vyukov <dvyukov(a)google.com> Cc: syzkaller(a)googlegroups.com Cc: linux-kernel(a)vger.kernel.org Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Jiri Slaby <jslaby(a)suse.com> Cc: Peter Hurley <peter(a)hurleysoftware.com> Cc: One Thousand Gnomes <gnomes(a)lxorguk.ukuu.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/tty_ldisc.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/tty/tty_ldisc.c +++ b/drivers/tty/tty_ldisc.c @@ -271,10 +271,13 @@ const struct file_operations tty_ldiscs_ struct tty_ldisc *tty_ldisc_ref_wait(struct tty_struct *tty) { + struct tty_ldisc *ld; + ldsem_down_read(&tty->ldisc_sem, MAX_SCHEDULE_TIMEOUT); - if (!tty->ldisc) + ld = tty->ldisc; + if (!ld) ldsem_up_read(&tty->ldisc_sem); - return tty->ldisc; + return ld; } EXPORT_SYMBOL_GPL(tty_ldisc_ref_wait); Patches currently in stable-queue which might be from dvyukov(a)google.com are queue-4.9/tty-fix-data-race-in-tty_ldisc_ref_wait.patch queue-4.9/kvm-nvmx-do-not-warn-when-msr-bitmap-address-is-not-backed.patch queue-4.9/userfaultfd-shmem-__do_fault-requires-vm_fault_nopage.patch queue-4.9/tty-don-t-panic-on-oom-in-tty_set_ldisc.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "tty: don't panic on OOM in tty_set_ldisc()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tty: don't panic on OOM in tty_set_ldisc() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: tty-don-t-panic-on-oom-in-tty_set_ldisc.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Dmitry Vyukov <dvyukov(a)google.com> Date: Sat, 4 Mar 2017 14:55:19 +0100 Subject: tty: don't panic on OOM in tty_set_ldisc() From: Dmitry Vyukov <dvyukov(a)google.com> [ Upstream commit 5362544bebe85071188dd9e479b5a5040841c895 ] If tty_ldisc_open() fails in tty_set_ldisc(), it tries to go back to the old discipline or N_TTY. But that can fail as well, in such case it panics. This is not a graceful way to handle OOM. Leave ldisc==NULL if all attempts fail instead. Also use existing tty_ldisc_reinit() helper function instead of tty_ldisc_restore(). Also don't WARN/BUG in tty_ldisc_reinit() if N_TTY fails, which would have the same net effect of bringing kernel down on OOM. Instead print a single line message about what has happened. Signed-off-by: Dmitry Vyukov <dvyukov(a)google.com> Cc: syzkaller(a)googlegroups.com Cc: linux-kernel(a)vger.kernel.org Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Jiri Slaby <jslaby(a)suse.com> Cc: Peter Hurley <peter(a)hurleysoftware.com> Cc: One Thousand Gnomes <gnomes(a)lxorguk.ukuu.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/tty_ldisc.c | 85 +++++++++--------------------------------------- 1 file changed, 16 insertions(+), 69 deletions(-) --- a/drivers/tty/tty_ldisc.c +++ b/drivers/tty/tty_ldisc.c @@ -489,41 +489,6 @@ static void tty_ldisc_close(struct tty_s } /** - * tty_ldisc_restore - helper for tty ldisc change - * @tty: tty to recover - * @old: previous ldisc - * - * Restore the previous line discipline or N_TTY when a line discipline - * change fails due to an open error - */ - -static void tty_ldisc_restore(struct tty_struct *tty, struct tty_ldisc *old) -{ - struct tty_ldisc *new_ldisc; - int r; - - /* There is an outstanding reference here so this is safe */ - old = tty_ldisc_get(tty, old->ops->num); - WARN_ON(IS_ERR(old)); - tty->ldisc = old; - tty_set_termios_ldisc(tty, old->ops->num); - if (tty_ldisc_open(tty, old) < 0) { - tty_ldisc_put(old); - /* This driver is always present */ - new_ldisc = tty_ldisc_get(tty, N_TTY); - if (IS_ERR(new_ldisc)) - panic("n_tty: get"); - tty->ldisc = new_ldisc; - tty_set_termios_ldisc(tty, N_TTY); - r = tty_ldisc_open(tty, new_ldisc); - if (r < 0) - panic("Couldn't open N_TTY ldisc for " - "%s --- error %d.", - tty_name(tty), r); - } -} - -/** * tty_set_ldisc - set line discipline * @tty: the terminal to set * @ldisc: the line discipline @@ -536,12 +501,7 @@ static void tty_ldisc_restore(struct tty int tty_set_ldisc(struct tty_struct *tty, int disc) { - int retval; - struct tty_ldisc *old_ldisc, *new_ldisc; - - new_ldisc = tty_ldisc_get(tty, disc); - if (IS_ERR(new_ldisc)) - return PTR_ERR(new_ldisc); + int retval, old_disc; tty_lock(tty); retval = tty_ldisc_lock(tty, 5 * HZ); @@ -554,7 +514,8 @@ int tty_set_ldisc(struct tty_struct *tty } /* Check the no-op case */ - if (tty->ldisc->ops->num == disc) + old_disc = tty->ldisc->ops->num; + if (old_disc == disc) goto out; if (test_bit(TTY_HUPPED, &tty->flags)) { @@ -563,34 +524,25 @@ int tty_set_ldisc(struct tty_struct *tty goto out; } - old_ldisc = tty->ldisc; - - /* Shutdown the old discipline. */ - tty_ldisc_close(tty, old_ldisc); - - /* Now set up the new line discipline. */ - tty->ldisc = new_ldisc; - tty_set_termios_ldisc(tty, disc); - - retval = tty_ldisc_open(tty, new_ldisc); + retval = tty_ldisc_reinit(tty, disc); if (retval < 0) { /* Back to the old one or N_TTY if we can't */ - tty_ldisc_put(new_ldisc); - tty_ldisc_restore(tty, old_ldisc); + if (tty_ldisc_reinit(tty, old_disc) < 0) { + pr_err("tty: TIOCSETD failed, reinitializing N_TTY\n"); + if (tty_ldisc_reinit(tty, N_TTY) < 0) { + /* At this point we have tty->ldisc == NULL. */ + pr_err("tty: reinitializing N_TTY failed\n"); + } + } } - if (tty->ldisc->ops->num != old_ldisc->ops->num && tty->ops->set_ldisc) { + if (tty->ldisc && tty->ldisc->ops->num != old_disc && + tty->ops->set_ldisc) { down_read(&tty->termios_rwsem); tty->ops->set_ldisc(tty); up_read(&tty->termios_rwsem); } - /* At this point we hold a reference to the new ldisc and a - reference to the old ldisc, or we hold two references to - the old ldisc (if it was restored as part of error cleanup - above). In either case, releasing a single reference from - the old ldisc is correct. */ - new_ldisc = old_ldisc; out: tty_ldisc_unlock(tty); @@ -598,7 +550,6 @@ out: already running */ tty_buffer_restart_work(tty->port); err: - tty_ldisc_put(new_ldisc); /* drop the extra reference */ tty_unlock(tty); return retval; } @@ -659,10 +610,8 @@ int tty_ldisc_reinit(struct tty_struct * int retval; ld = tty_ldisc_get(tty, disc); - if (IS_ERR(ld)) { - BUG_ON(disc == N_TTY); + if (IS_ERR(ld)) return PTR_ERR(ld); - } if (tty->ldisc) { tty_ldisc_close(tty, tty->ldisc); @@ -674,10 +623,8 @@ int tty_ldisc_reinit(struct tty_struct * tty_set_termios_ldisc(tty, disc); retval = tty_ldisc_open(tty, tty->ldisc); if (retval) { - if (!WARN_ON(disc == N_TTY)) { - tty_ldisc_put(tty->ldisc); - tty->ldisc = NULL; - } + tty_ldisc_put(tty->ldisc); + tty->ldisc = NULL; } return retval; } Patches currently in stable-queue which might be from dvyukov(a)google.com are queue-4.9/tty-fix-data-race-in-tty_ldisc_ref_wait.patch queue-4.9/kvm-nvmx-do-not-warn-when-msr-bitmap-address-is-not-backed.patch queue-4.9/userfaultfd-shmem-__do_fault-requires-vm_fault_nopage.patch queue-4.9/tty-don-t-panic-on-oom-in-tty_set_ldisc.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "thermal/drivers/step_wise: Fix temperature regulation misbehavior" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled thermal/drivers/step_wise: Fix temperature regulation misbehavior to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: thermal-drivers-step_wise-fix-temperature-regulation-misbehavior.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:35 CET 2017 From: Daniel Lezcano <daniel.lezcano(a)linaro.org> Date: Thu, 19 Oct 2017 19:05:58 +0200 Subject: thermal/drivers/step_wise: Fix temperature regulation misbehavior From: Daniel Lezcano <daniel.lezcano(a)linaro.org> [ Upstream commit 07209fcf33542c1ff1e29df2dbdf8f29cdaacb10 ] There is a particular situation when the cooling device is cpufreq and the heat dissipation is not efficient enough where the temperature increases little by little until reaching the critical threshold and leading to a SoC reset. The behavior is reproducible on a hikey6220 with bad heat dissipation (eg. stacked with other boards). Running a simple C program doing while(1); for each CPU of the SoC makes the temperature to reach the passive regulation trip point and ends up to the maximum allowed temperature followed by a reset. This issue has been also reported by running the libhugetlbfs test suite. What is observed is a ping pong between two cpu frequencies, 1.2GHz and 900MHz while the temperature continues to grow. It appears the step wise governor calls get_target_state() the first time with the throttle set to true and the trend to 'raising'. The code selects logically the next state, so the cpu frequency decreases from 1.2GHz to 900MHz, so far so good. The temperature decreases immediately but still stays greater than the trip point, then get_target_state() is called again, this time with the throttle set to true *and* the trend to 'dropping'. From there the algorithm assumes we have to step down the state and the cpu frequency jumps back to 1.2GHz. But the temperature is still higher than the trip point, so get_target_state() is called with throttle=1 and trend='raising' again, we jump to 900MHz, then get_target_state() is called with throttle=1 and trend='dropping', we jump to 1.2GHz, etc ... but the temperature does not stabilizes and continues to increase. [ 237.922654] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 237.922678] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1 [ 237.922690] thermal cooling_device0: cur_state=0 [ 237.922701] thermal cooling_device0: old_target=0, target=1 [ 238.026656] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1 [ 238.026680] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=1 [ 238.026694] thermal cooling_device0: cur_state=1 [ 238.026707] thermal cooling_device0: old_target=1, target=0 [ 238.134647] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 238.134667] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1 [ 238.134679] thermal cooling_device0: cur_state=0 [ 238.134690] thermal cooling_device0: old_target=0, target=1 In this situation the temperature continues to increase while the trend is oscillating between 'dropping' and 'raising'. We need to keep the current state untouched if the throttle is set, so the temperature can decrease or a higher state could be selected, thus preventing this oscillation. Keeping the next_target untouched when 'throttle' is true at 'dropping' time fixes the issue. The following traces show the governor does not change the next state if trend==2 (dropping) and throttle==1. [ 2306.127987] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 2306.128009] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1 [ 2306.128021] thermal cooling_device0: cur_state=0 [ 2306.128031] thermal cooling_device0: old_target=0, target=1 [ 2306.231991] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1 [ 2306.232016] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=1 [ 2306.232030] thermal cooling_device0: cur_state=1 [ 2306.232042] thermal cooling_device0: old_target=1, target=1 [ 2306.335982] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1 [ 2306.336006] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=1 [ 2306.336021] thermal cooling_device0: cur_state=1 [ 2306.336034] thermal cooling_device0: old_target=1, target=1 [ 2306.439984] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1 [ 2306.440008] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=0 [ 2306.440022] thermal cooling_device0: cur_state=1 [ 2306.440034] thermal cooling_device0: old_target=1, target=0 [ ... ] After a while, if the temperature continues to increase, the next state becomes 2 which is 720MHz on the hikey. That results in the temperature stabilizing around the trip point. [ 2455.831982] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 2455.832006] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=0 [ 2455.832019] thermal cooling_device0: cur_state=1 [ 2455.832032] thermal cooling_device0: old_target=1, target=1 [ 2455.935985] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1 [ 2455.936013] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=0 [ 2455.936027] thermal cooling_device0: cur_state=1 [ 2455.936040] thermal cooling_device0: old_target=1, target=1 [ 2456.043984] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1 [ 2456.044009] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=0 [ 2456.044023] thermal cooling_device0: cur_state=1 [ 2456.044036] thermal cooling_device0: old_target=1, target=1 [ 2456.148001] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 2456.148028] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1 [ 2456.148042] thermal cooling_device0: cur_state=1 [ 2456.148055] thermal cooling_device0: old_target=1, target=2 [ 2456.252009] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1 [ 2456.252041] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=0 [ 2456.252058] thermal cooling_device0: cur_state=2 [ 2456.252075] thermal cooling_device0: old_target=2, target=1 IOW, this change is needed to keep the state for a cooling device if the temperature trend is oscillating while the temperature increases slightly. Without this change, the situation above leads to a catastrophic crash by a hardware reset on hikey. This issue has been reported to happen on an OMAP dra7xx also. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> Cc: Keerthy <j-keerthy(a)ti.com> Cc: John Stultz <john.stultz(a)linaro.org> Cc: Leo Yan <leo.yan(a)linaro.org> Tested-by: Keerthy <j-keerthy(a)ti.com> Reviewed-by: Keerthy <j-keerthy(a)ti.com> Signed-off-by: Eduardo Valentin <edubezval(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/thermal/step_wise.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) --- a/drivers/thermal/step_wise.c +++ b/drivers/thermal/step_wise.c @@ -31,8 +31,7 @@ * If the temperature is higher than a trip point, * a. if the trend is THERMAL_TREND_RAISING, use higher cooling * state for this trip point - * b. if the trend is THERMAL_TREND_DROPPING, use lower cooling - * state for this trip point + * b. if the trend is THERMAL_TREND_DROPPING, do nothing * c. if the trend is THERMAL_TREND_RAISE_FULL, use upper limit * for this trip point * d. if the trend is THERMAL_TREND_DROP_FULL, use lower limit @@ -94,9 +93,11 @@ static unsigned long get_target_state(st if (!throttle) next_target = THERMAL_NO_TARGET; } else { - next_target = cur_state - 1; - if (next_target > instance->upper) - next_target = instance->upper; + if (!throttle) { + next_target = cur_state - 1; + if (next_target > instance->upper) + next_target = instance->upper; + } } break; case THERMAL_TREND_DROP_FULL: Patches currently in stable-queue which might be from daniel.lezcano(a)linaro.org are queue-4.9/thermal-drivers-step_wise-fix-temperature-regulation-misbehavior.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "target: Use system workqueue for ALUA transitions" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled target: Use system workqueue for ALUA transitions to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: target-use-system-workqueue-for-alua-transitions.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Mike Christie <mchristi(a)redhat.com> Date: Wed, 1 Mar 2017 23:13:26 -0600 Subject: target: Use system workqueue for ALUA transitions From: Mike Christie <mchristi(a)redhat.com> [ Upstream commit 207ee84133c00a8a2a5bdec94df4a5b37d78881c ] If tcmu-runner is processing a STPG and needs to change the kernel's ALUA state then we cannot use the same work queue for task management requests and ALUA transitions, because we could deadlock. The problem occurs when a STPG times out before tcmu-runner is able to call into target_tg_pt_gp_alua_access_state_store-> core_alua_do_port_transition -> core_alua_do_transition_tg_pt -> queue_work. In this case, the tmr is on the work queue waiting for the STPG to complete, but the STPG transition is now queued behind the waiting tmr. Note: This bug will also be fixed by this patch: http://www.spinics.net/lists/target-devel/msg14560.html which switches the tmr code to use the system workqueues. For both, I am not sure if we need a dedicated workqueue since it is not a performance path and I do not think we need WQ_MEM_RECLAIM to make forward progress to free up memory like the block layer does. 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)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/target_core_alua.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) --- a/drivers/target/target_core_alua.c +++ b/drivers/target/target_core_alua.c @@ -1118,13 +1118,11 @@ static int core_alua_do_transition_tg_pt unsigned long transition_tmo; transition_tmo = tg_pt_gp->tg_pt_gp_implicit_trans_secs * HZ; - queue_delayed_work(tg_pt_gp->tg_pt_gp_dev->tmr_wq, - &tg_pt_gp->tg_pt_gp_transition_work, - transition_tmo); + schedule_delayed_work(&tg_pt_gp->tg_pt_gp_transition_work, + transition_tmo); } else { tg_pt_gp->tg_pt_gp_transition_complete = &wait; - queue_delayed_work(tg_pt_gp->tg_pt_gp_dev->tmr_wq, - &tg_pt_gp->tg_pt_gp_transition_work, 0); + schedule_delayed_work(&tg_pt_gp->tg_pt_gp_transition_work, 0); wait_for_completion(&wait); tg_pt_gp->tg_pt_gp_transition_complete = NULL; } Patches currently in stable-queue which might be from mchristi(a)redhat.com are queue-4.9/target-use-system-workqueue-for-alua-transitions.patch queue-4.9/target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch queue-4.9/target-fix-alua-transition-timeout-handling.patch queue-4.9/target-fix-race-during-implicit-transition-work-flushes.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "target/iscsi: Fix a race condition in iscsit_add_reject_from_cmd()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled target/iscsi: Fix a race condition in iscsit_add_reject_from_cmd() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:35 CET 2017 From: Bart Van Assche <bart.vanassche(a)wdc.com> Date: Tue, 31 Oct 2017 11:03:17 -0700 Subject: target/iscsi: Fix a race condition in iscsit_add_reject_from_cmd() From: Bart Van Assche <bart.vanassche(a)wdc.com> [ Upstream commit cfe2b621bb18d86e93271febf8c6e37622da2d14 ] Avoid that cmd->se_cmd.se_tfo is read after a command has already been freed. Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Mike Christie <mchristi(a)redhat.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/iscsi/iscsi_target.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/target/iscsi/iscsi_target.c +++ b/drivers/target/iscsi/iscsi_target.c @@ -841,6 +841,7 @@ static int iscsit_add_reject_from_cmd( unsigned char *buf) { struct iscsi_conn *conn; + const bool do_put = cmd->se_cmd.se_tfo != NULL; if (!cmd->conn) { pr_err("cmd->conn is NULL for ITT: 0x%08x\n", @@ -871,7 +872,7 @@ static int iscsit_add_reject_from_cmd( * Perform the kref_put now if se_cmd has already been setup by * scsit_setup_scsi_cmd() */ - if (cmd->se_cmd.se_tfo != NULL) { + if (do_put) { pr_debug("iscsi reject: calling target_put_sess_cmd >>>>>>\n"); target_put_sess_cmd(&cmd->se_cmd); } Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are queue-4.9/target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch queue-4.9/rdma-cma-avoid-triggering-undefined-behavior.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "target: fix race during implicit transition work flushes" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled target: fix race during implicit transition work flushes to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: target-fix-race-during-implicit-transition-work-flushes.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Mike Christie <mchristi(a)redhat.com> Date: Thu, 2 Mar 2017 04:59:50 -0600 Subject: target: fix race during implicit transition work flushes From: Mike Christie <mchristi(a)redhat.com> [ Upstream commit 760bf578edf8122f2503a3a6a3f4b0de3b6ce0bb ] This fixes the following races: 1. core_alua_do_transition_tg_pt could have read tg_pt_gp_alua_access_state and gone into this if chunk: if (!explicit && atomic_read(&tg_pt_gp->tg_pt_gp_alua_access_state) == ALUA_ACCESS_STATE_TRANSITION) { and then core_alua_do_transition_tg_pt_work could update the state. core_alua_do_transition_tg_pt would then only set tg_pt_gp_alua_pending_state and the tg_pt_gp_alua_access_state would not get updated with the second calls state. 2. core_alua_do_transition_tg_pt could be setting tg_pt_gp_transition_complete while the tg_pt_gp_transition_work is already completing. core_alua_do_transition_tg_pt then waits on the completion that will never be called. To handle these issues, we just call flush_work which will return when core_alua_do_transition_tg_pt_work has completed so there is no need to do the complete/wait. And, if core_alua_do_transition_tg_pt_work was running, instead of trying to sneak in the state change, we just schedule up another core_alua_do_transition_tg_pt_work call. Note that this does not handle a possible race where there are multiple threads call core_alua_do_transition_tg_pt at the same time. I think we need a mutex in target_tg_pt_gp_alua_access_state_store. 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)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/target_core_alua.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) --- a/drivers/target/target_core_alua.c +++ b/drivers/target/target_core_alua.c @@ -1073,16 +1073,8 @@ static int core_alua_do_transition_tg_pt /* * Flush any pending transitions */ - if (!explicit && atomic_read(&tg_pt_gp->tg_pt_gp_alua_access_state) == - ALUA_ACCESS_STATE_TRANSITION) { - /* Just in case */ - tg_pt_gp->tg_pt_gp_alua_pending_state = new_state; - tg_pt_gp->tg_pt_gp_transition_complete = &wait; + if (!explicit) flush_work(&tg_pt_gp->tg_pt_gp_transition_work); - wait_for_completion(&wait); - tg_pt_gp->tg_pt_gp_transition_complete = NULL; - return 0; - } /* * Save the old primary ALUA access state, and set the current state Patches currently in stable-queue which might be from mchristi(a)redhat.com are queue-4.9/target-use-system-workqueue-for-alua-transitions.patch queue-4.9/target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch queue-4.9/target-fix-alua-transition-timeout-handling.patch queue-4.9/target-fix-race-during-implicit-transition-work-flushes.patch

7 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror