This is a note to let you know that I've just added the patch titled
mlxsw: spectrum: Relax sanity checks during enslavement
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:
mlxsw-spectrum-relax-sanity-checks-during-enslavement.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 Sat Jan 13 10:51:05 CET 2018
From: Ido Schimmel <idosch(a)mellanox.com>
Date: Mon, 25 Dec 2017 09:05:33 +0100
Subject: mlxsw: spectrum: Relax sanity checks during enslavement
From: Ido Schimmel <idosch(a)mellanox.com>
[ Upstream commit 90045fc9c78855bdc625a0ab185d97b72a937613 ]
Since commit 25cc72a33835 ("mlxsw: spectrum: Forbid linking to devices that
have uppers") the driver forbids enslavement to netdevs that already
have uppers of their own, as this can result in various ordering
problems.
This requirement proved to be too strict for some users who need to be
able to enslave ports to a bridge that already has uppers. In this case,
we can allow the enslavement if the bridge is already known to us, as
any configuration performed on top of the bridge was already reflected
to the device.
Fixes: 25cc72a33835 ("mlxsw: spectrum: Forbid linking to devices that have uppers")
Signed-off-by: Ido Schimmel <idosch(a)mellanox.com>
Reported-by: Alexander Petrovskiy <alexpe(a)mellanox.com>
Tested-by: Alexander Petrovskiy <alexpe(a)mellanox.com>
Signed-off-by: Jiri Pirko <jiri(a)mellanox.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 11 +++++++++--
drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 2 ++
drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 6 ++++++
3 files changed, 17 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -4235,7 +4235,10 @@ static int mlxsw_sp_netdevice_port_upper
return -EINVAL;
if (!info->linking)
break;
- if (netdev_has_any_upper_dev(upper_dev))
+ if (netdev_has_any_upper_dev(upper_dev) &&
+ (!netif_is_bridge_master(upper_dev) ||
+ !mlxsw_sp_bridge_device_is_offloaded(mlxsw_sp,
+ upper_dev)))
return -EINVAL;
if (netif_is_lag_master(upper_dev) &&
!mlxsw_sp_master_lag_check(mlxsw_sp, upper_dev,
@@ -4347,6 +4350,7 @@ static int mlxsw_sp_netdevice_port_vlan_
u16 vid)
{
struct mlxsw_sp_port *mlxsw_sp_port = netdev_priv(dev);
+ struct mlxsw_sp *mlxsw_sp = mlxsw_sp_port->mlxsw_sp;
struct netdev_notifier_changeupper_info *info = ptr;
struct net_device *upper_dev;
int err = 0;
@@ -4358,7 +4362,10 @@ static int mlxsw_sp_netdevice_port_vlan_
return -EINVAL;
if (!info->linking)
break;
- if (netdev_has_any_upper_dev(upper_dev))
+ if (netdev_has_any_upper_dev(upper_dev) &&
+ (!netif_is_bridge_master(upper_dev) ||
+ !mlxsw_sp_bridge_device_is_offloaded(mlxsw_sp,
+ upper_dev)))
return -EINVAL;
break;
case NETDEV_CHANGEUPPER:
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
@@ -326,6 +326,8 @@ int mlxsw_sp_port_bridge_join(struct mlx
void mlxsw_sp_port_bridge_leave(struct mlxsw_sp_port *mlxsw_sp_port,
struct net_device *brport_dev,
struct net_device *br_dev);
+bool mlxsw_sp_bridge_device_is_offloaded(const struct mlxsw_sp *mlxsw_sp,
+ const struct net_device *br_dev);
/* spectrum.c */
int mlxsw_sp_port_ets_set(struct mlxsw_sp_port *mlxsw_sp_port,
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -134,6 +134,12 @@ mlxsw_sp_bridge_device_find(const struct
return NULL;
}
+bool mlxsw_sp_bridge_device_is_offloaded(const struct mlxsw_sp *mlxsw_sp,
+ const struct net_device *br_dev)
+{
+ return !!mlxsw_sp_bridge_device_find(mlxsw_sp->bridge, br_dev);
+}
+
static struct mlxsw_sp_bridge_device *
mlxsw_sp_bridge_device_create(struct mlxsw_sp_bridge *bridge,
struct net_device *br_dev)
Patches currently in stable-queue which might be from idosch(a)mellanox.com are
queue-4.14/mlxsw-spectrum_router-fix-null-pointer-deref.patch
queue-4.14/mlxsw-spectrum-relax-sanity-checks-during-enslavement.patch
This is a note to let you know that I've just added the patch titled
ipv6: sr: fix TLVs not being copied using setsockopt
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ipv6-sr-fix-tlvs-not-being-copied-using-setsockopt.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 Sat Jan 13 10:51:05 CET 2018
From: Mathieu Xhonneux <m.xhonneux(a)gmail.com>
Date: Wed, 10 Jan 2018 13:35:49 +0000
Subject: ipv6: sr: fix TLVs not being copied using setsockopt
From: Mathieu Xhonneux <m.xhonneux(a)gmail.com>
[ Upstream commit ccc12b11c5332c84442ef120dcd631523be75089 ]
Function ipv6_push_rthdr4 allows to add an IPv6 Segment Routing Header
to a socket through setsockopt, but the current implementation doesn't
copy possible TLVs at the end of the SRH received from userspace.
Therefore, the execution of the following branch if (sr_has_hmac(sr_phdr))
{ ... } will never complete since the len and type fields of a possible
HMAC TLV are not copied, hence seg6_get_tlv_hmac will return an error,
and the HMAC will not be computed.
This commit adds a memcpy in case TLVs have been appended to the SRH.
Fixes: a149e7c7ce81 ("ipv6: sr: add support for SRH injection through setsockopt")
Acked-by: David Lebrun <dlebrun(a)google.com>
Signed-off-by: Mathieu Xhonneux <m.xhonneux(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/exthdrs.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -884,6 +884,15 @@ static void ipv6_push_rthdr4(struct sk_b
sr_phdr->segments[0] = **addr_p;
*addr_p = &sr_ihdr->segments[sr_ihdr->segments_left];
+ if (sr_ihdr->hdrlen > hops * 2) {
+ int tlvs_offset, tlvs_length;
+
+ tlvs_offset = (1 + hops * 2) << 3;
+ tlvs_length = (sr_ihdr->hdrlen - hops * 2) << 3;
+ memcpy((char *)sr_phdr + tlvs_offset,
+ (char *)sr_ihdr + tlvs_offset, tlvs_length);
+ }
+
#ifdef CONFIG_IPV6_SEG6_HMAC
if (sr_has_hmac(sr_phdr)) {
struct net *net = NULL;
Patches currently in stable-queue which might be from m.xhonneux(a)gmail.com are
queue-4.14/ipv6-sr-fix-tlvs-not-being-copied-using-setsockopt.patch
This is a note to let you know that I've just added the patch titled
ipv6: fix possible mem leaks in ipv6_make_skb()
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ipv6-fix-possible-mem-leaks-in-ipv6_make_skb.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 Sat Jan 13 10:51:05 CET 2018
From: Eric Dumazet <edumazet(a)google.com>
Date: Wed, 10 Jan 2018 03:45:49 -0800
Subject: ipv6: fix possible mem leaks in ipv6_make_skb()
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit 862c03ee1deb7e19e0f9931682e0294ecd1fcaf9 ]
ip6_setup_cork() might return an error, while memory allocations have
been done and must be rolled back.
Fixes: 6422398c2ab0 ("ipv6: introduce ipv6_make_skb")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Cc: Vlad Yasevich <vyasevich(a)gmail.com>
Reported-by: Mike Maloney <maloney(a)google.com>
Acked-by: Mike Maloney <maloney(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/ip6_output.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1735,9 +1735,10 @@ struct sk_buff *ip6_make_skb(struct sock
cork.base.opt = NULL;
v6_cork.opt = NULL;
err = ip6_setup_cork(sk, &cork, &v6_cork, ipc6, rt, fl6);
- if (err)
+ if (err) {
+ ip6_cork_release(&cork, &v6_cork);
return ERR_PTR(err);
-
+ }
if (ipc6->dontfrag < 0)
ipc6->dontfrag = inet6_sk(sk)->dontfrag;
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.14/ipv6-fix-possible-mem-leaks-in-ipv6_make_skb.patch
This is a note to let you know that I've just added the patch titled
ip6_tunnel: disable dst caching if tunnel is dual-stack
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:
ip6_tunnel-disable-dst-caching-if-tunnel-is-dual-stack.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 Sat Jan 13 10:51:05 CET 2018
From: Eli Cooper <elicooper(a)gmx.com>
Date: Mon, 25 Dec 2017 10:43:49 +0800
Subject: ip6_tunnel: disable dst caching if tunnel is dual-stack
From: Eli Cooper <elicooper(a)gmx.com>
[ Upstream commit 23263ec86a5f44312d2899323872468752324107 ]
When an ip6_tunnel is in mode 'any', where the transport layer
protocol can be either 4 or 41, dst_cache must be disabled.
This is because xfrm policies might apply to only one of the two
protocols. Caching dst would cause xfrm policies for one protocol
incorrectly used for the other.
Signed-off-by: Eli Cooper <elicooper(a)gmx.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/ip6_tunnel.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1081,10 +1081,11 @@ int ip6_tnl_xmit(struct sk_buff *skb, st
memcpy(&fl6->daddr, addr6, sizeof(fl6->daddr));
neigh_release(neigh);
}
- } else if (!(t->parms.flags &
- (IP6_TNL_F_USE_ORIG_TCLASS | IP6_TNL_F_USE_ORIG_FWMARK))) {
- /* enable the cache only only if the routing decision does
- * not depend on the current inner header value
+ } else if (t->parms.proto != 0 && !(t->parms.flags &
+ (IP6_TNL_F_USE_ORIG_TCLASS |
+ IP6_TNL_F_USE_ORIG_FWMARK))) {
+ /* enable the cache only if neither the outer protocol nor the
+ * routing decision depends on the current inner header value
*/
use_cache = true;
}
Patches currently in stable-queue which might be from elicooper(a)gmx.com are
queue-4.14/ip6_tunnel-disable-dst-caching-if-tunnel-is-dual-stack.patch
This is a note to let you know that I've just added the patch titled
ethtool: do not print warning for applications using legacy API
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:
ethtool-do-not-print-warning-for-applications-using-legacy-api.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 Sat Jan 13 10:51:05 CET 2018
From: Stephen Hemminger <stephen(a)networkplumber.org>
Date: Fri, 29 Dec 2017 10:02:52 -0800
Subject: ethtool: do not print warning for applications using legacy API
From: Stephen Hemminger <stephen(a)networkplumber.org>
[ Upstream commit 71891e2dab6b55a870f8f7735e44a2963860b5c6 ]
In kernel log ths message appears on every boot:
"warning: `NetworkChangeNo' uses legacy ethtool link settings API,
link modes are only partially reported"
When ethtool link settings API changed, it started complaining about
usages of old API. Ironically, the original patch was from google but
the application using the legacy API is chrome.
Linux ABI is fixed as much as possible. The kernel must not break it
and should not complain about applications using legacy API's.
This patch just removes the warning since using legacy API's
in Linux is perfectly acceptable.
Fixes: 3f1ac7a700d0 ("net: ethtool: add new ETHTOOL_xLINKSETTINGS API")
Signed-off-by: Stephen Hemminger <stephen(a)networkplumber.org>
Signed-off-by: David Decotigny <decot(a)googlers.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/core/ethtool.c | 15 ++-------------
1 file changed, 2 insertions(+), 13 deletions(-)
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -754,15 +754,6 @@ static int ethtool_set_link_ksettings(st
return dev->ethtool_ops->set_link_ksettings(dev, &link_ksettings);
}
-static void
-warn_incomplete_ethtool_legacy_settings_conversion(const char *details)
-{
- char name[sizeof(current->comm)];
-
- pr_info_once("warning: `%s' uses legacy ethtool link settings API, %s\n",
- get_task_comm(name, current), details);
-}
-
/* Query device for its ethtool_cmd settings.
*
* Backward compatibility note: for compatibility with legacy ethtool,
@@ -789,10 +780,8 @@ static int ethtool_get_settings(struct n
&link_ksettings);
if (err < 0)
return err;
- if (!convert_link_ksettings_to_legacy_settings(&cmd,
- &link_ksettings))
- warn_incomplete_ethtool_legacy_settings_conversion(
- "link modes are only partially reported");
+ convert_link_ksettings_to_legacy_settings(&cmd,
+ &link_ksettings);
/* send a sensible cmd tag back to user */
cmd.cmd = ETHTOOL_GSET;
Patches currently in stable-queue which might be from stephen(a)networkplumber.org are
queue-4.14/ethtool-do-not-print-warning-for-applications-using-legacy-api.patch
This is a note to let you know that I've just added the patch titled
8021q: fix a memory leak for VLAN 0 device
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
8021q-fix-a-memory-leak-for-vlan-0-device.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sat Jan 13 10:51:05 CET 2018
From: Cong Wang <xiyou.wangcong(a)gmail.com>
Date: Tue, 9 Jan 2018 13:40:41 -0800
Subject: 8021q: fix a memory leak for VLAN 0 device
From: Cong Wang <xiyou.wangcong(a)gmail.com>
[ Upstream commit 78bbb15f2239bc8e663aa20bbe1987c91a0b75f6 ]
A vlan device with vid 0 is allow to creat by not able to be fully
cleaned up by unregister_vlan_dev() which checks for vlan_id!=0.
Also, VLAN 0 is probably not a valid number and it is kinda
"reserved" for HW accelerating devices, but it is probably too
late to reject it from creation even if makes sense. Instead,
just remove the check in unregister_vlan_dev().
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Fixes: ad1afb003939 ("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)")
Cc: Vlad Yasevich <vyasevich(a)gmail.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/8021q/vlan.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -111,12 +111,7 @@ void unregister_vlan_dev(struct net_devi
vlan_gvrp_uninit_applicant(real_dev);
}
- /* Take it out of our own structures, but be sure to interlock with
- * HW accelerating devices or SW vlan input packet processing if
- * VLAN is not 0 (leave it there for 802.1p).
- */
- if (vlan_id)
- vlan_vid_del(real_dev, vlan->vlan_proto, vlan_id);
+ vlan_vid_del(real_dev, vlan->vlan_proto, vlan_id);
/* Get rid of the vlan's reference to real_dev */
dev_put(real_dev);
Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are
queue-4.14/8021q-fix-a-memory-leak-for-vlan-0-device.patch
Hello stable list:
This was just posted to 4.15-rc7 since it "defeats the Project Zero PoC
for CVE 2017-5715."
Should it be marked stable? It cherry-picks cleanly into 4.14.12, not
sure about other branches. Full text below.
--
Eric Wheeler
kvm: vmx: Scrub hardware GPRs at VM-exit
Guest GPR values are live in the hardware GPRs at VM-exit. Do not
leave any guest values in hardware GPRs after the guest GPR values are
saved to the vcpu_vmx structure.
This is a partial mitigation for CVE 2017-5715 and CVE 2017-5753.
Specifically, it defeats the Project Zero PoC for CVE 2017-5715.
Suggested-by: Eric Northup <digitaleric(a)google.com>
Signed-off-by: Jim Mattson <jmattson(a)google.com>
Reviewed-by: Eric Northup <digitaleric(a)google.com>
Reviewed-by: Benjamin Serebrin <serebrin(a)google.com>
Reviewed-by: Andrew Honig <ahonig(a)google.com>
[Paolo: Add AMD bits, Signed-off-by: Tom Lendacky <thomas.lendacky(a)amd.com>]
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
This patch series fixes an issue with HS/FS 3-stage control read transfer where
DWC3 incorrectly check when to send ZLP.
Changes in v3:
- Add 'Fixes:' tags
- Minor update to commit message for clarity
Changes in v2:
- Separate from "usb: dwc3: Add new updates for DWC_usb31" patch series
- Add 'Cc' to stable mailing list
Thinh Nguyen (2):
usb: dwc3: gadget: Set maxpacket size for ep0 IN
usb: dwc3: ep0: Reset TRB counter for ep0 IN
drivers/usb/dwc3/ep0.c | 7 ++++++-
drivers/usb/dwc3/gadget.c | 2 ++
2 files changed, 8 insertions(+), 1 deletion(-)
--
2.11.0
From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com>
Subject: kdump: write correct address of mem_section into vmcoreinfo
Depending on configuration mem_section can now be an array or a pointer to
an array allocated dynamically. In most cases, we can continue to refer
to it as 'mem_section' regardless of what it is.
But there's one exception: '&mem_section' means "address of the array" if
mem_section is an array, but if mem_section is a pointer, it would mean
"address of the pointer".
We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section)
writes down address of pointer into vmcoreinfo, not array as we wanted.
Let's introduce VMCOREINFO_SYMBOL_ARRAY() that would handle the situation
correctly for both cases.
Link: http://lkml.kernel.org/r/20180112162532.35896-1-kirill.shutemov@linux.intel…
Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y")
Acked-by: Baoquan He <bhe(a)redhat.com>
Acked-by: Dave Young <dyoung(a)redhat.com>
Cc: Ingo Molnar <mingo(a)redhat.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: "H. Peter Anvin" <hpa(a)zytor.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Dave Young <dyoung(a)redhat.com>
Cc: Baoquan He <bhe(a)redhat.com>
Cc: Vivek Goyal <vgoyal(a)redhat.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
include/linux/crash_core.h | 2 ++
kernel/crash_core.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff -puN include/linux/crash_core.h~kdump-write-a-correct-address-of-mem_section-into-vmcoreinfo include/linux/crash_core.h
--- a/include/linux/crash_core.h~kdump-write-a-correct-address-of-mem_section-into-vmcoreinfo
+++ a/include/linux/crash_core.h
@@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void);
vmcoreinfo_append_str("PAGESIZE=%ld\n", value)
#define VMCOREINFO_SYMBOL(name) \
vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)&name)
+#define VMCOREINFO_SYMBOL_ARRAY(name) \
+ vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name)
#define VMCOREINFO_SIZE(name) \
vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \
(unsigned long)sizeof(name))
diff -puN kernel/crash_core.c~kdump-write-a-correct-address-of-mem_section-into-vmcoreinfo kernel/crash_core.c
--- a/kernel/crash_core.c~kdump-write-a-correct-address-of-mem_section-into-vmcoreinfo
+++ a/kernel/crash_core.c
@@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_
VMCOREINFO_SYMBOL(contig_page_data);
#endif
#ifdef CONFIG_SPARSEMEM
- VMCOREINFO_SYMBOL(mem_section);
+ VMCOREINFO_SYMBOL_ARRAY(mem_section);
VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS);
VMCOREINFO_STRUCT_SIZE(mem_section);
VMCOREINFO_OFFSET(mem_section, section_mem_map);
_
HiSilicon Hip06/Hip07 can work as RC mode and EP mode. The PCIe Root Port
in Hip06/Hip07 SoCs advertises an MSI capability, but it can not generate
MSIs. It can generate MSIs When it works as EP mode, but the vendor id and
device id of RP and EP are the same. Current code also disable MSI for EP
mode, we only need to disable MSI for Root Port.
Cc: <stable(a)vger.kernel.org>
Fixes: 72f2ff0deb87 ("PCI: Disable MSI for HiSilicon Hip06/Hip07 Root Ports")
Signed-off-by: Dongdong Liu <liudongdong3(a)huawei.com>
---
drivers/pci/quirks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 10684b1..d22750e 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -1636,8 +1636,8 @@ static void quirk_pcie_mch(struct pci_dev *pdev)
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E7520_MCH, quirk_pcie_mch);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E7320_MCH, quirk_pcie_mch);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E7525_MCH, quirk_pcie_mch);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_HUAWEI, 0x1610, quirk_pcie_mch);
+DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_HUAWEI, 0x1610, PCI_CLASS_BRIDGE_PCI, 8, quirk_pcie_mch);
/*
* It's possible for the MSI to get corrupted if shpc and acpi
--
1.9.1
From: Nicholas Bellinger <nab(a)linux-iscsi.org>
Hi Sasha,
Here are two target patches for v4.1.y stable, which did not apply
due to minor context changes.
The series has been cut against v4.1.48. Please apply at your earliest
convenience.
Thank you,
--nab
Nicholas Bellinger (2):
iscsi-target: Make TASK_REASSIGN use proper se_cmd->cmd_kref
target: Avoid early CMD_T_PRE_EXECUTE failures during ABORT_TASK
drivers/target/iscsi/iscsi_target.c | 20 +++++++-------------
drivers/target/target_core_tmr.c | 9 +++++++++
drivers/target/target_core_transport.c | 2 ++
include/target/target_core_base.h | 1 +
4 files changed, 19 insertions(+), 13 deletions(-)
--
1.8.5.3
The patch titled
Subject: kdump: write correct address of mem_section into vmcoreinfo
has been added to the -mm tree. Its filename is
kdump-write-a-correct-address-of-mem_section-into-vmcoreinfo.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/kdump-write-a-correct-address-of-m…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/kdump-write-a-correct-address-of-m…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com>
Subject: kdump: write correct address of mem_section into vmcoreinfo
Depending on configuration mem_section can now be an array or a pointer to
an array allocated dynamically. In most cases, we can continue to refer
to it as 'mem_section' regardless of what it is.
But there's one exception: '&mem_section' means "address of the array" if
mem_section is an array, but if mem_section is a pointer, it would mean
"address of the pointer".
We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section)
writes down address of pointer into vmcoreinfo, not array as we wanted.
Let's introduce VMCOREINFO_SYMBOL_ARRAY() that would handle the situation
correctly for both cases.
Link: http://lkml.kernel.org/r/20180112162532.35896-1-kirill.shutemov@linux.intel…
Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y")
Acked-by: Baoquan He <bhe(a)redhat.com>
Acked-by: Dave Young <dyoung(a)redhat.com>
Cc: Ingo Molnar <mingo(a)redhat.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: "H. Peter Anvin" <hpa(a)zytor.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Dave Young <dyoung(a)redhat.com>
Cc: Baoquan He <bhe(a)redhat.com>
Cc: Vivek Goyal <vgoyal(a)redhat.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
include/linux/crash_core.h | 2 ++
kernel/crash_core.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff -puN include/linux/crash_core.h~kdump-write-a-correct-address-of-mem_section-into-vmcoreinfo include/linux/crash_core.h
--- a/include/linux/crash_core.h~kdump-write-a-correct-address-of-mem_section-into-vmcoreinfo
+++ a/include/linux/crash_core.h
@@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void);
vmcoreinfo_append_str("PAGESIZE=%ld\n", value)
#define VMCOREINFO_SYMBOL(name) \
vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)&name)
+#define VMCOREINFO_SYMBOL_ARRAY(name) \
+ vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name)
#define VMCOREINFO_SIZE(name) \
vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \
(unsigned long)sizeof(name))
diff -puN kernel/crash_core.c~kdump-write-a-correct-address-of-mem_section-into-vmcoreinfo kernel/crash_core.c
--- a/kernel/crash_core.c~kdump-write-a-correct-address-of-mem_section-into-vmcoreinfo
+++ a/kernel/crash_core.c
@@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_
VMCOREINFO_SYMBOL(contig_page_data);
#endif
#ifdef CONFIG_SPARSEMEM
- VMCOREINFO_SYMBOL(mem_section);
+ VMCOREINFO_SYMBOL_ARRAY(mem_section);
VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS);
VMCOREINFO_STRUCT_SIZE(mem_section);
VMCOREINFO_OFFSET(mem_section, section_mem_map);
_
Patches currently in -mm which might be from kirill.shutemov(a)linux.intel.com are
kdump-write-a-correct-address-of-mem_section-into-vmcoreinfo.patch
asm-generic-provide-generic_pmdp_establish.patch
arc-use-generic_pmdp_establish-as-pmdp_establish.patch
arm-mm-provide-pmdp_establish-helper.patch
mips-use-generic_pmdp_establish-as-pmdp_establish.patch
x86-mm-provide-pmdp_establish-helper.patch
mm-do-not-lose-dirty-and-access-bits-in-pmdp_invalidate.patch
mm-use-updated-pmdp_invalidate-interface-to-track-dirty-accessed-bits.patch
The patch titled
Subject: userfaultfd: clear the vma->vm_userfaultfd_ctx if UFFD_EVENT_FORK fails
has been removed from the -mm tree. Its filename was
userfaultfd-clear-the-vma-vm_userfaultfd_ctx-if-uffd_event_fork-fails.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Andrea Arcangeli <aarcange(a)redhat.com>
Subject: userfaultfd: clear the vma->vm_userfaultfd_ctx if UFFD_EVENT_FORK fails
The previous fix 384632e67e0829 ("userfaultfd: non-cooperative: fix fork
use after free") corrected the refcounting in case of UFFD_EVENT_FORK
failure for the fork userfault paths. That still didn't clear the
vma->vm_userfaultfd_ctx of the vmas that were set to point to the aborted
new uffd ctx earlier in dup_userfaultfd.
Link: http://lkml.kernel.org/r/20171223002505.593-2-aarcange@redhat.com
Signed-off-by: Andrea Arcangeli <aarcange(a)redhat.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Reviewed-by: Mike Rapoport <rppt(a)linux.vnet.ibm.com>
Cc: Eric Biggers <ebiggers3(a)gmail.com>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/userfaultfd.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff -puN fs/userfaultfd.c~userfaultfd-clear-the-vma-vm_userfaultfd_ctx-if-uffd_event_fork-fails fs/userfaultfd.c
--- a/fs/userfaultfd.c~userfaultfd-clear-the-vma-vm_userfaultfd_ctx-if-uffd_event_fork-fails
+++ a/fs/userfaultfd.c
@@ -570,11 +570,14 @@ out:
static void userfaultfd_event_wait_completion(struct userfaultfd_ctx *ctx,
struct userfaultfd_wait_queue *ewq)
{
+ struct userfaultfd_ctx *release_new_ctx;
+
if (WARN_ON_ONCE(current->flags & PF_EXITING))
goto out;
ewq->ctx = ctx;
init_waitqueue_entry(&ewq->wq, current);
+ release_new_ctx = NULL;
spin_lock(&ctx->event_wqh.lock);
/*
@@ -601,8 +604,7 @@ static void userfaultfd_event_wait_compl
new = (struct userfaultfd_ctx *)
(unsigned long)
ewq->msg.arg.reserved.reserved1;
-
- userfaultfd_ctx_put(new);
+ release_new_ctx = new;
}
break;
}
@@ -617,6 +619,20 @@ static void userfaultfd_event_wait_compl
__set_current_state(TASK_RUNNING);
spin_unlock(&ctx->event_wqh.lock);
+ if (release_new_ctx) {
+ struct vm_area_struct *vma;
+ struct mm_struct *mm = release_new_ctx->mm;
+
+ /* the various vma->vm_userfaultfd_ctx still points to it */
+ down_write(&mm->mmap_sem);
+ for (vma = mm->mmap; vma; vma = vma->vm_next)
+ if (vma->vm_userfaultfd_ctx.ctx == release_new_ctx)
+ vma->vm_userfaultfd_ctx = NULL_VM_UFFD_CTX;
+ up_write(&mm->mmap_sem);
+
+ userfaultfd_ctx_put(release_new_ctx);
+ }
+
/*
* ctx may go away after this if the userfault pseudo fd is
* already released.
_
Patches currently in -mm which might be from aarcange(a)redhat.com are
The patch titled
Subject: mm/sparse.c: wrong allocation for mem_section
has been removed from the -mm tree. Its filename was
mm-sparsec-wrong-allocation-for-mem_section.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Baoquan He <bhe(a)redhat.com>
Subject: mm/sparse.c: wrong allocation for mem_section
In 83e3c48729 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y") mem_section is allocated at runtime to save memory. While it allocates
the first dimension of array with sizeof(struct mem_section). It costs
extra memory, should be sizeof(struct mem_section*).
Fix it.
Link: http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-bhe@redhat.com
Fixes: 83e3c48729 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y")
Signed-off-by: Baoquan He <bhe(a)redhat.com>
Tested-by: Dave Young <dyoung(a)redhat.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Cc: Ingo Molnar <mingo(a)kernel.org>
Cc: Andy Lutomirski <luto(a)amacapital.net>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Atsushi Kumagai <ats-kumagai(a)wm.jp.nec.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/sparse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN mm/sparse.c~mm-sparsec-wrong-allocation-for-mem_section mm/sparse.c
--- a/mm/sparse.c~mm-sparsec-wrong-allocation-for-mem_section
+++ a/mm/sparse.c
@@ -211,7 +211,7 @@ void __init memory_present(int nid, unsi
if (unlikely(!mem_section)) {
unsigned long size, align;
- size = sizeof(struct mem_section) * NR_SECTION_ROOTS;
+ size = sizeof(struct mem_section*) * NR_SECTION_ROOTS;
align = 1 << (INTERNODE_CACHE_SHIFT);
mem_section = memblock_virt_alloc(size, align);
}
_
Patches currently in -mm which might be from bhe(a)redhat.com are
The patch titled
Subject: kernel/acct.c: fix the acct->needcheck check in check_free_space()
has been removed from the -mm tree. Its filename was
acct-fix-the-acct-needcheck-check-in-check_free_space.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Oleg Nesterov <oleg(a)redhat.com>
Subject: kernel/acct.c: fix the acct->needcheck check in check_free_space()
As Tsukada explains, the time_is_before_jiffies(acct->needcheck) check is
very wrong, we need time_is_after_jiffies() to make sys_acct() work.
Ignoring the overflows, the code should "goto out" if needcheck > jiffies,
while currently it checks "needcheck < jiffies" and thus in the likely
case check_free_space() does nothing until jiffies overflow.
In particular this means that sys_acct() is simply broken, acct_on() sets
acct->needcheck = jiffies and expects that check_free_space() should set
acct->active = 1 after the free-space check, but this won't happen if
jiffies increments in between.
This was broken by commit 32dc73086015 ("get rid of timer in kern/acct.c")
in 2011, then another (correct) commit 795a2f22a8ea ("acct() should honour
the limits from the very beginning") made the problem more visible.
Link: http://lkml.kernel.org/r/20171213133940.GA6554@redhat.com
Fixes: 32dc73086015 ("get rid of timer in kern/acct.c")
Reported-by: TSUKADA Koutaro <tsukada(a)ascade.co.jp>
Suggested-by: TSUKADA Koutaro <tsukada(a)ascade.co.jp>
Signed-off-by: Oleg Nesterov <oleg(a)redhat.com>
Cc: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
kernel/acct.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN kernel/acct.c~acct-fix-the-acct-needcheck-check-in-check_free_space kernel/acct.c
--- a/kernel/acct.c~acct-fix-the-acct-needcheck-check-in-check_free_space
+++ a/kernel/acct.c
@@ -102,7 +102,7 @@ static int check_free_space(struct bsd_a
{
struct kstatfs sbuf;
- if (time_is_before_jiffies(acct->needcheck))
+ if (time_is_after_jiffies(acct->needcheck))
goto out;
/* May block */
_
Patches currently in -mm which might be from oleg(a)redhat.com are
Commit b014e96d1abb ("PCI: Protect pci_error_handlers->reset_notify()
usage with device_lock()") resolves races between driver reset and
removal, but it introduces some new deadlock problems. If we see a
timeout while we've already started suspending, removing, or shutting
down the driver, we might see:
(a) a worker thread, running mwifiex_pcie_work() ->
mwifiex_pcie_card_reset_work() -> pci_reset_function()
(b) a removal thread, running mwifiex_pcie_remove() ->
mwifiex_free_adapter() -> mwifiex_unregister() ->
mwifiex_cleanup_pcie() -> cancel_work_sync(&card->work)
Unfortunately, mwifiex_pcie_remove() already holds the device lock that
pci_reset_function() is now requesting, and so we see a deadlock.
It's necessary to cancel and synchronize our outstanding work before
tearing down the driver, so we can't have this work wait indefinitely
for the lock.
It's reasonable to only "try" to reset here, since this will mostly
happen for cases where it's already difficult to reset the firmware
anyway (e.g., while we're suspending or powering off the system). And if
reset *really* needs to happen, we can always try again later.
Fixes: b014e96d1abb ("PCI: Protect pci_error_handlers->reset_notify() usage with device_lock()")
Cc: <stable(a)vger.kernel.org>
Cc: Xinming Hu <huxm(a)marvell.com>
Signed-off-by: Brian Norris <briannorris(a)chromium.org>
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index f666cb2ea7e0..97a6199692ab 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2786,7 +2786,10 @@ static void mwifiex_pcie_card_reset_work(struct mwifiex_adapter *adapter)
{
struct pcie_service_card *card = adapter->card;
- pci_reset_function(card->dev);
+ /* We can't afford to wait here; remove() might be waiting on us. If we
+ * can't grab the device lock, maybe we'll get another chance later.
+ */
+ pci_try_reset_function(card->dev);
}
static void mwifiex_pcie_work(struct work_struct *work)
--
2.16.0.rc1.238.g530d649a79-goog
Setting si_code to 0 is the same a setting si_code to SI_USER which is definitely
not correct. With si_code set to SI_USER si_pid and si_uid will be copied to
userspace instead of si_addr. Which is very wrong.
So fix this by using a sensible si_code (SEGV_MAPERR) for this failure.
Cc: stable(a)vger.kernel.org
Fixes: b920de1b77b7 ("mn10300: add the MN10300/AM33 architecture to the kernel")
Cc: David Howells <dhowells(a)redhat.com>
Cc: Masakazu Urade <urade.masakazu(a)jp.panasonic.com>
Cc: Koichi Yasutake <yasutake.koichi(a)jp.panasonic.com>
Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com>
---
arch/mn10300/mm/misalignment.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mn10300/mm/misalignment.c b/arch/mn10300/mm/misalignment.c
index b39a388825ae..8ace89617c1c 100644
--- a/arch/mn10300/mm/misalignment.c
+++ b/arch/mn10300/mm/misalignment.c
@@ -437,7 +437,7 @@ asmlinkage void misalignment(struct pt_regs *regs, enum exception_code code)
info.si_signo = SIGSEGV;
info.si_errno = 0;
- info.si_code = 0;
+ info.si_code = SEGV_MAPERR;
info.si_addr = (void *) regs->pc;
force_sig_info(SIGSEGV, &info, current);
return;
--
2.14.1
While reviewing the signal sending on openrisc the do_unaligned_access
function stood out because it is obviously wrong. A comment about an
si_code set above when actually si_code is never set. Leading to a
random si_code being sent to userspace in the event of an unaligned
access.
Looking further SIGBUS BUS_ADRALN is the proper pair of signal and
si_code to send for an unaligned access. That is what other
architectures do and what is required by posix.
Given that do_unaligned_access is broken in a way that no one can be
relying on it on openrisc fix the code to just do the right thing.
Cc: stable(a)vger.kernel.org
Fixes: 769a8a96229e ("OpenRISC: Traps")
Cc: Jonas Bonn <jonas(a)southpole.se>
Cc: Stefan Kristiansson <stefan.kristiansson(a)saunalahti.fi>
Cc: Stafford Horne <shorne(a)gmail.com>
Cc: Arnd Bergmann <arnd(a)arndb.de>
Cc: openrisc(a)lists.librecores.org
Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com>
---
arch/openrisc/kernel/traps.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/openrisc/kernel/traps.c b/arch/openrisc/kernel/traps.c
index 4085d72fa5ae..9e38dc66c9e4 100644
--- a/arch/openrisc/kernel/traps.c
+++ b/arch/openrisc/kernel/traps.c
@@ -266,12 +266,12 @@ asmlinkage void do_unaligned_access(struct pt_regs *regs, unsigned long address)
siginfo_t info;
if (user_mode(regs)) {
- /* Send a SIGSEGV */
- info.si_signo = SIGSEGV;
+ /* Send a SIGBUS */
+ info.si_signo = SIGBUS;
info.si_errno = 0;
- /* info.si_code has been set above */
- info.si_addr = (void *)address;
- force_sig_info(SIGSEGV, &info, current);
+ info.si_code = BUS_ADRALN;
+ info.si_addr = (void __user *)address;
+ force_sig_info(SIGBUS, &info, current);
} else {
printk("KERNEL: Unaligned Access 0x%.8lx\n", address);
show_registers(regs);
--
2.14.1
Starting from commit 041e4575f034 ("mtd: nand: handle ECC errors in
OOB"), nand_do_read_oob() (from the NAND core) did return 0 or a
negative error, and the MTD layer expected it.
However, the trend for the NAND layer is now to return an error or a
positive number of bitflips. Deciding which status to return to the user
belongs to the MTD layer.
Commit e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()")
brought this logic to the mtd_read_oob() function while the return value
coming from nand_do_read_oob() (called by the ->_read_oob() hook) was
left unchanged.
Fixes: e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()")
Cc: stable(a)vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal(a)free-electrons.com>
---
Changes since v2:
- Correctly return the maximum number of bitflips, not the number of
bitflips of the last chunk only.
Changes since v1:
- s/->ecc.read_oob() hook/->_read_oob() hook/ in the commit message
- Fixed the compilation issue
drivers/mtd/nand/nand_base.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 469220065b8b..e4e39890a975 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3794,6 +3794,7 @@ EXPORT_SYMBOL(nand_write_oob_syndrome);
static int nand_do_read_oob(struct mtd_info *mtd, loff_t from,
struct mtd_oob_ops *ops)
{
+ unsigned int max_bitflips = 0;
int page, realpage, chipnr;
struct nand_chip *chip = mtd_to_nand(mtd);
struct mtd_ecc_stats stats;
@@ -3855,6 +3856,8 @@ static int nand_do_read_oob(struct mtd_info *mtd, loff_t from,
if (!readlen)
break;
+ max_bitflips = max_t(unsigned int, max_bitflips, ret);
+
/* Increment page address */
realpage++;
@@ -3876,7 +3879,7 @@ static int nand_do_read_oob(struct mtd_info *mtd, loff_t from,
if (mtd->ecc_stats.failed - stats.failed)
return -EBADMSG;
- return mtd->ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0;
+ return max_bitflips;
}
/**
--
2.11.0
The bounce buffer is gone from the MMC core, and now we found out
that there are some (crippled) i.MX boards out there that have broken
ADMA (cannot do scatter-gather), and broken PIO so they must use
SDMA. Closer examination shows a less significant slowdown also on
SDMA-only capable Laptop hosts.
SDMA sets down the number of segments to one, so that each segment
gets turned into a singular request that ping-pongs to the block
layer before the next request/segment is issued.
Apparently it happens a lot that the block layer send requests
that include a lot of physically discontigous segments. My guess
is that this phenomenon is coming from the file system.
These devices that cannot handle scatterlists in hardware can see
major benefits from a DMA-contigous bounce buffer.
This patch accumulates those fragmented scatterlists in a physically
contigous bounce buffer so that we can issue bigger DMA data chunks
to/from the card.
When tested with thise PCI-integrated host (1217:8221) that
only supports SDMA:
0b:00.0 SD Host controller: O2 Micro, Inc. OZ600FJ0/OZ900FJ0/OZ600FJS
SD/MMC Card Reader Controller (rev 05)
This patch gave ~1Mbyte/s improved throughput on large reads and
writes when testing using iozone than without the patch.
On the i.MX SDHCI controllers on the crippled i.MX 25 and i.MX 35
the patch restores the performance to what it was before we removed
the bounce buffers, and then some: performance is better than ever
because we now allocate a bounce buffer the size of the maximum
single request the SDMA engine can handle. On the PCI laptop this
is 256K, whereas with the old bounce buffer code it was 64K max.
Cc: Benjamin Beckmeyer <beckmeyer.b(a)rittal.de>
Cc: Pierre Ossman <pierre(a)ossman.eu>
Cc: Benoît Thébaudeau <benoit(a)wsystem.com>
Cc: Fabio Estevam <fabio.estevam(a)nxp.com>
Cc: stable(a)vger.kernel.org
Fixes: de3ee99b097d ("mmc: Delete bounce buffer handling")
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
---
---
ChangeLog v3->v4:
- Cap the bounce buffer to 64KB instead of the biggest segment
as we experience diminishing returns with buffers > 64KB.
- Instead of using dma_alloc_coherent(), use good old devm_kmalloc()
and issue dma_sync_single_for*() to explicitly switch
ownership between CPU and the device. This way we exercise the
cache better and may consume less CPU.
- Bail out with single segments if we cannot allocate a bounce
buffer.
- Tested on the PCI SDHCI on my laptop: requesting a new test
on i.MX from Benjamin. (Please!)
ChangeLog v2->v3:
- Rewrite the commit message a bit
- Add Benjamin's Tested-by
- Add Fixes and stable tags
ChangeLog v1->v2:
- Skip the remapping and fiddling with the buffer, instead use
dma_alloc_coherent() and use a simple, coherent bounce buffer.
- Couple kernel messages to ->parent of the mmc_host as it relates
to the hardware characteristics.
---
drivers/mmc/host/sdhci.c | 125 ++++++++++++++++++++++++++++++++++++++++++++---
drivers/mmc/host/sdhci.h | 3 ++
2 files changed, 120 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index e9290a3439d5..694a320d9444 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -21,6 +21,7 @@
#include <linux/dma-mapping.h>
#include <linux/slab.h>
#include <linux/scatterlist.h>
+#include <linux/sizes.h>
#include <linux/swiotlb.h>
#include <linux/regulator/consumer.h>
#include <linux/pm_runtime.h>
@@ -502,8 +503,27 @@ static int sdhci_pre_dma_transfer(struct sdhci_host *host,
if (data->host_cookie == COOKIE_PRE_MAPPED)
return data->sg_count;
- sg_count = dma_map_sg(mmc_dev(host->mmc), data->sg, data->sg_len,
- mmc_get_dma_dir(data));
+ /* Bounce write requests to the bounce buffer */
+ if (host->bounce_buffer) {
+ if (mmc_get_dma_dir(data) == DMA_TO_DEVICE) {
+ /* Copy the data to the bounce buffer */
+ sg_copy_to_buffer(data->sg, data->sg_len,
+ host->bounce_buffer,
+ host->bounce_buffer_size);
+ }
+ /* Switch ownership to the DMA */
+ dma_sync_single_for_device(host->mmc->parent,
+ host->bounce_addr,
+ host->bounce_buffer_size,
+ DMA_TO_DEVICE);
+ /* Just a dummy value */
+ sg_count = 1;
+ } else {
+ /* Just access the data directly from memory */
+ sg_count = dma_map_sg(mmc_dev(host->mmc),
+ data->sg, data->sg_len,
+ mmc_get_dma_dir(data));
+ }
if (sg_count == 0)
return -ENOSPC;
@@ -858,8 +878,13 @@ static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_command *cmd)
SDHCI_ADMA_ADDRESS_HI);
} else {
WARN_ON(sg_cnt != 1);
- sdhci_writel(host, sg_dma_address(data->sg),
- SDHCI_DMA_ADDRESS);
+ /* Bounce buffer goes to work */
+ if (host->bounce_buffer)
+ sdhci_writel(host, host->bounce_addr,
+ SDHCI_DMA_ADDRESS);
+ else
+ sdhci_writel(host, sg_dma_address(data->sg),
+ SDHCI_DMA_ADDRESS);
}
}
@@ -2248,7 +2273,12 @@ static void sdhci_pre_req(struct mmc_host *mmc, struct mmc_request *mrq)
mrq->data->host_cookie = COOKIE_UNMAPPED;
- if (host->flags & SDHCI_REQ_USE_DMA)
+ /*
+ * No pre-mapping in the pre hook if we're using the bounce buffer,
+ * for that we would need two bounce buffers since one buffer is
+ * in flight when this is getting called.
+ */
+ if (host->flags & SDHCI_REQ_USE_DMA && !host->bounce_buffer)
sdhci_pre_dma_transfer(host, mrq->data, COOKIE_PRE_MAPPED);
}
@@ -2352,8 +2382,28 @@ static bool sdhci_request_done(struct sdhci_host *host)
struct mmc_data *data = mrq->data;
if (data && data->host_cookie == COOKIE_MAPPED) {
- dma_unmap_sg(mmc_dev(host->mmc), data->sg, data->sg_len,
- mmc_get_dma_dir(data));
+ if (host->bounce_buffer) {
+ /*
+ * On reads, copy the bounced data into the
+ * sglist
+ */
+ if (mmc_get_dma_dir(data) == DMA_FROM_DEVICE) {
+ dma_sync_single_for_cpu(
+ host->mmc->parent,
+ host->bounce_addr,
+ host->bounce_buffer_size,
+ DMA_FROM_DEVICE);
+ sg_copy_from_buffer(data->sg,
+ data->sg_len,
+ host->bounce_buffer,
+ host->bounce_buffer_size);
+ }
+ } else {
+ /* Unmap the raw data */
+ dma_unmap_sg(mmc_dev(host->mmc), data->sg,
+ data->sg_len,
+ mmc_get_dma_dir(data));
+ }
data->host_cookie = COOKIE_UNMAPPED;
}
}
@@ -2636,7 +2686,12 @@ static void sdhci_data_irq(struct sdhci_host *host, u32 intmask)
*/
if (intmask & SDHCI_INT_DMA_END) {
u32 dmastart, dmanow;
- dmastart = sg_dma_address(host->data->sg);
+
+ if (host->bounce_buffer)
+ dmastart = host->bounce_addr;
+ else
+ dmastart = sg_dma_address(host->data->sg);
+
dmanow = dmastart + host->data->bytes_xfered;
/*
* Force update to the next DMA block boundary.
@@ -3713,6 +3768,60 @@ int sdhci_setup_host(struct sdhci_host *host)
*/
mmc->max_blk_count = (host->quirks & SDHCI_QUIRK_NO_MULTIBLOCK) ? 1 : 65535;
+ if (mmc->max_segs == 1) {
+ unsigned int max_blocks;
+ unsigned int max_seg_size;
+
+ /*
+ * Cap the bounce buffer at 64KB. Using a bigger bounce buffer
+ * has diminishing returns, this is probably because SD/MMC
+ * cards are usually optimized to handle this size of requests.
+ */
+ max_seg_size = SZ_64K;
+ if (mmc->max_req_size < max_seg_size)
+ max_seg_size = mmc->max_req_size;
+ max_blocks = max_seg_size / 512;
+ dev_info(mmc->parent,
+ "host only supports SDMA, activate bounce buffer\n");
+
+ /*
+ * When we just support one segment, we can get significant
+ * speedups by the help of a bounce buffer to group scattered
+ * reads/writes together.
+ */
+ host->bounce_buffer = devm_kmalloc(mmc->parent,
+ max_seg_size,
+ GFP_KERNEL);
+ if (!host->bounce_buffer) {
+ dev_err(mmc->parent,
+ "failed to allocate %u bytes for bounce buffer, falling back to single segments\n",
+ max_seg_size);
+ /*
+ * Exiting with zero here makes sure we proceed with
+ * mmc->max_segs == 1.
+ */
+ return 0;
+ }
+
+ host->bounce_buffer_size = max_seg_size;
+ host->bounce_addr = dma_map_single(mmc->parent,
+ host->bounce_buffer,
+ host->bounce_buffer_size,
+ DMA_BIDIRECTIONAL);
+ ret = dma_mapping_error(mmc->parent, host->bounce_addr);
+ if (ret)
+ /* Again fall back to max_segs == 1 */
+ return 0;
+
+ /* Lie about this since we're bouncing */
+ mmc->max_segs = max_blocks;
+ mmc->max_seg_size = max_seg_size;
+
+ dev_info(mmc->parent,
+ "bounce buffer: bounce up to %u segments into one, max segment size %u bytes\n",
+ max_blocks, max_seg_size);
+ }
+
return 0;
unreg:
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 54bc444c317f..865e09618d22 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -440,6 +440,9 @@ struct sdhci_host {
int irq; /* Device IRQ */
void __iomem *ioaddr; /* Mapped address */
+ char *bounce_buffer; /* For packing SDMA reads/writes */
+ dma_addr_t bounce_addr;
+ size_t bounce_buffer_size;
const struct sdhci_ops *ops; /* Low level hw interface */
--
2.14.3
From: Punit Agrawal <punit.agrawal(a)arm.com>
KVM only supports PMD hugepages at stage 2 but doesn't actually check
that the provided hugepage memory pagesize is PMD_SIZE before populating
stage 2 entries.
In cases where the backing hugepage size is smaller than PMD_SIZE (such
as when using contiguous hugepages), KVM can end up creating stage 2
mappings that extend beyond the supplied memory.
Fix this by checking for the pagesize of userspace vma before creating
PMD hugepage at stage 2.
Fixes: 66b3923a1a0f77a ("arm64: hugetlb: add support for PTE contiguous bit")
Signed-off-by: Punit Agrawal <punit.agrawal(a)arm.com>
Cc: Marc Zyngier <marc.zyngier(a)arm.com>
Cc: <stable(a)vger.kernel.org> # v4.5+
Reviewed-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
---
virt/kvm/arm/mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index b4b69c2d1012..9dea96380339 100644
--- a/virt/kvm/arm/mmu.c
+++ b/virt/kvm/arm/mmu.c
@@ -1310,7 +1310,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
return -EFAULT;
}
- if (is_vm_hugetlb_page(vma) && !logging_active) {
+ if (vma_kernel_pagesize(vma) == PMD_SIZE && !logging_active) {
hugetlb = true;
gfn = (fault_ipa & PMD_MASK) >> PAGE_SHIFT;
} else {
--
2.14.2
Starting from commit 041e4575f034 ("mtd: nand: handle ECC errors in
OOB"), nand_do_read_oob() (from the NAND core) did return 0 or a
negative error, and the MTD layer expected it.
However, the trend for the NAND layer is now to return an error or a
positive number of bitflips. Deciding which status to return to the user
belongs to the MTD layer.
Commit e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()")
brought this logic to the mtd_read_oob() function while the return value
coming from nand_do_read_oob() (called by the ->_read_oob() hook) was
left unchanged.
Fixes: e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()")
Cc: stable(a)vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal(a)free-electrons.com>
---
Changes since v1:
- s/->ecc.read_oob() hook/->_read_oob() hook/ in the commit message
- Fixed the compilation issue
drivers/mtd/nand/nand_base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 469220065b8b..440d9f5d5b17 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3876,7 +3876,7 @@ static int nand_do_read_oob(struct mtd_info *mtd, loff_t from,
if (mtd->ecc_stats.failed - stats.failed)
return -EBADMSG;
- return mtd->ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0;
+ return ret;
}
/**
--
2.11.0
On Fri, 2018-01-12 at 08:23 +0200, Leon Romanovsky wrote:
> On Thu, Jan 11, 2018 at 07:07:06PM +0000, Bart Van Assche wrote:
> > On Thu, 2018-01-11 at 21:00 +0200, Leon Romanovsky wrote:
> > > On Thu, Jan 11, 2018 at 04:02:33PM +0000, Bart Van Assche wrote:
> > > > On Thu, 2018-01-11 at 08:22 +0200, Leon Romanovsky wrote:
> > > > > The proposed patch definitely decreases the chance of races, but it is not fixing them.
> > > > > There is a chance to have change in qp state immediately after your "if ..." check.
> > > >
> > > > Hello Leon,
> > > >
> > > > Please have a look at rxe_qp_error() and you will see that the patch I posted
> > > > is a proper fix. In the scenario you described rxe_qp_error() will trigger a
> > > > run of rxe_completer().
> > >
> > > Bart,
> > >
> > > What am I missing?
> > >
> > > CPU1 CPU2
> > > if (unlikely....
> > > <---
> > > /* move the qp to the error state */
> > > void rxe_qp_error(struct rxe_qp *qp)
> > > {
> > > qp->req.state = QP_STATE_ERROR;
> > > qp->resp.state = QP_STATE_ERROR;
> > > qp->attr.qp_state = IB_QPS_ERR;
> > > --->
> > > rxe_run_task(&qp->req.task, must_sched);
> > >
> > >
> > >
> > > It is more or less the same as without "if (unlikely..."
> >
> > Hello Leon,
> >
> > In the above the part of rxe_qp_error() that I was referring to in my e-mail
> > is missing:
> >
> > if (qp_type(qp) == IB_QPT_RC)
> > rxe_run_task(&qp->comp.task, 1);
>
>
> But it is exactly where race exists, as long QP isn't protected, it can
> switch CPUs and create race.
Hello Leon,
Can you clarify which race you are referring to? rxe_run_task() uses the
tasklet mechanism and tasklets are guaranteed to run on at most one CPU at a
time. See also the "Top and Bottom Halves" chapter in Linux Device Drivers,
3rd edition. See also the tasklet_schedule() implementation in
<linux/interrupt.h> and in kernel/softirq.c.
Thanks,
Bart.
Hi Arnd,
On Thursday 11 January 2018 11:46 PM, Eric Anholt wrote:
> Arnd Bergmann <arnd(a)arndb.de> writes:
>
>> On Thu, Jan 11, 2018 at 2:30 PM, Kishon Vijay Abraham I <kishon(a)ti.com> wrote:
>>> On Thursday 11 January 2018 02:27 AM, Arnd Bergmann wrote:
>>>> On Mon, Jan 8, 2018 at 7:32 PM, Kishon Vijay Abraham I <kishon(a)ti.com> wrote:
>>>>> On Monday 08 January 2018 06:31 PM, Arnd Bergmann wrote:
>>>>>> Stefan Wahren reports a problem with a warning fix that was merged
>>>>>> ---
>>>>>> This obviously needs to be tested, I wrote this up as a reply to
>>>>>> Stefan's bug report. I'm fairly sure that I covered all usb-phy
>>>>>> driver strings here. My goal is to have a fix merged into 4.15
>>>>>> rather than reverting all the DT fixes.
>>>>>
>>>>> Shouldn't the fix be in phy consumer drivers to not return error if it's able
>>>>> to find the phy either using usb-phy or generic phy?
>>>>
>>>> Stefan has posted a patch to that effect now, but I fear that might be
>>>> a little fragile, in particular this short before the release with the
>>>> regression
>>>> in place.
>>>>
>>>> The main problem is that we'd have to change the generic
>>>> usb_add_hcd() function in addition to dwc2 and dwc3 to ignore
>>>> -EPROBE_DEFER from phy_get() whenever usb_get_phy_dev()
>>>> has already succeeded.
>>>>
>>>> If there is any HCD that relies on usb_add_hcd() to get both the
>>>> usb_phy and the phy structures, and it may need to defer probing
>>>> when the latter one isn't ready yet, that fix would break another
>>>> driver.
>>>
>>> hmm.. IMO the better thing right now would be to revert the dt patch which adds
>>> #phy-cells.
>>> We have to see if there are better fixes in order to add #phy-cells warning fix
>>> in stable tree.
>>
>> Let's see which patches that would be, I think this is the full list of
>> nodes that got an extra #phy-cells:
>>
>> c22fe696157d ARM: dts: Fix dm814x missing phy-cells property
>> f0e11ff8ff65 ARM: dts: am33xx: Add missing #phy-cells to ti,am335x-usb-phy
>> c5bbf358b790 arm: dts: nspire: Add missing #phy-cells to usb-nop-xceiv
>> 44e5dced2ef6 arm: dts: marvell: Add missing #phy-cells to usb-nop-xceiv
>> 014d6da6cb25 ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells
>> f568f6f554b8 ARM: dts: omap: Add missing #phy-cells to usb-nop-xceiv
>>
>> plus a couple in linux-next:
>>
>> d745d5f277bf ARM: dts: imx51-zii-rdu1: Add missing #phy-cells to usb-nop-xceiv
>> 915fbe59cbf2 ARM: dts: imx: Add missing #phy-cells to usb-nop-xceiv
>>
>> It's a lot of patches to revert, and I guess it would get us back to hundreds
>> of warnings in an allmodconfig build, so I'd first try to come up with
>> ways to prove that at least some of them can stay.
>>
>> Almost all the warnings are about "usb-nop-xceiv" phys, the only exceptions
>> I could find are the OMAP ones (the first two patches), which use
>> "ti,am335x-usb-phy" and are referenced from a "ti,musb-am33xx". That
>> particular driver is not affected by the bug, so we can leave that in.
>>
>> To deal with all the "usb-nop-xceiv" references including the one that
>> Stefan reported, we could use a much simpler version of my earlier
>> patch, do you think this is any better?
yeah, this looks simpler.
>>
>> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
In case you want to take this patch yourself
Acked-by: Kishon Vijay Abraham I <kishon(a)ti.com>
(or let me know if I have to create a separate pull request for Greg)
Thanks
Kishon
>>
>> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
>> index b4964b067aec..f056d8fb3921 100644
>> --- a/drivers/phy/phy-core.c
>> +++ b/drivers/phy/phy-core.c
>> @@ -410,6 +410,10 @@ static struct phy *_of_phy_get(struct device_node
>> *np, int index)
>> if (ret)
>> return ERR_PTR(-ENODEV);
>>
>> + /* This phy type handled by the usb-phy subsystem for now */
>> + if (of_device_is_compatible("usb-nop-xceiv"))
>> + return ERR_PTR(-ENODEV);
>> +
>> mutex_lock(&phy_provider_mutex);
>> phy_provider = of_phy_provider_lookup(args.np);
>> if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) {
>
> This seems like a nice workaround!
>
The patch titled
Subject: pipe: fix off-by-one error when checking buffer limits
has been added to the -mm tree. Its filename is
pipe-fix-off-by-one-error-when-checking-buffer-limits.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/pipe-fix-off-by-one-error-when-che…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/pipe-fix-off-by-one-error-when-che…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Eric Biggers <ebiggers(a)google.com>
Subject: pipe: fix off-by-one error when checking buffer limits
With pipe-user-pages-hard set to 'N', users were actually only allowed up
to 'N - 1' buffers; and likewise for pipe-user-pages-soft.
Fix this to allow up to 'N' buffers, as would be expected.
Link: http://lkml.kernel.org/r/20180111052902.14409-5-ebiggers3@gmail.com
Fixes: b0b91d18e2e9 ("pipe: fix limit checking in pipe_set_size()")
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Acked-by: Willy Tarreau <w(a)1wt.eu>
Acked-by: Kees Cook <keescook(a)chromium.org>
Acked-by: Joe Lawrence <joe.lawrence(a)redhat.com>
Cc: Alexander Viro <viro(a)zeniv.linux.org.uk>
Cc: "Luis R . Rodriguez" <mcgrof(a)kernel.org>
Cc: Michael Kerrisk <mtk.manpages(a)gmail.com>
Cc: Mikulas Patocka <mpatocka(a)redhat.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/pipe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN fs/pipe.c~pipe-fix-off-by-one-error-when-checking-buffer-limits fs/pipe.c
--- a/fs/pipe.c~pipe-fix-off-by-one-error-when-checking-buffer-limits
+++ a/fs/pipe.c
@@ -605,12 +605,12 @@ static unsigned long account_pipe_buffer
static bool too_many_pipe_buffers_soft(unsigned long user_bufs)
{
- return pipe_user_pages_soft && user_bufs >= pipe_user_pages_soft;
+ return pipe_user_pages_soft && user_bufs > pipe_user_pages_soft;
}
static bool too_many_pipe_buffers_hard(unsigned long user_bufs)
{
- return pipe_user_pages_hard && user_bufs >= pipe_user_pages_hard;
+ return pipe_user_pages_hard && user_bufs > pipe_user_pages_hard;
}
static bool is_unprivileged_user(void)
_
Patches currently in -mm which might be from ebiggers(a)google.com are
userfaultfd-convert-to-use-anon_inode_getfd.patch
pipe-sysctl-drop-min-parameter-from-pipe-max-size-converter.patch
pipe-sysctl-remove-pipe_proc_fn.patch
pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch
pipe-fix-off-by-one-error-when-checking-buffer-limits.patch
pipe-reject-f_setpipe_sz-with-size-over-uint_max.patch
pipe-simplify-round_pipe_size.patch
pipe-read-buffer-limits-atomically.patch
The patch titled
Subject: pipe: actually allow root to exceed the pipe buffer limits
has been added to the -mm tree. Its filename is
pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/pipe-actually-allow-root-to-exceed…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/pipe-actually-allow-root-to-exceed…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Eric Biggers <ebiggers(a)google.com>
Subject: pipe: actually allow root to exceed the pipe buffer limits
pipe-user-pages-hard and pipe-user-pages-soft are only supposed to apply
to unprivileged users, as documented in both Documentation/sysctl/fs.txt
and the pipe(7) man page.
However, the capabilities are actually only checked when increasing a
pipe's size using F_SETPIPE_SZ, not when creating a new pipe. Therefore,
if pipe-user-pages-hard has been set, the root user can run into it and be
unable to create pipes. Similarly, if pipe-user-pages-soft has been set,
the root user can run into it and have their pipes limited to 1 page each.
Fix this by allowing the privileged override in both cases.
Link: http://lkml.kernel.org/r/20180111052902.14409-4-ebiggers3@gmail.com
Fixes: 759c01142a5d ("pipe: limit the per-user amount of pages allocated in pipes")
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Acked-by: Kees Cook <keescook(a)chromium.org>
Acked-by: Joe Lawrence <joe.lawrence(a)redhat.com>
Cc: Alexander Viro <viro(a)zeniv.linux.org.uk>
Cc: "Luis R . Rodriguez" <mcgrof(a)kernel.org>
Cc: Michael Kerrisk <mtk.manpages(a)gmail.com>
Cc: Mikulas Patocka <mpatocka(a)redhat.com>
Cc: Willy Tarreau <w(a)1wt.eu>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/pipe.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff -puN fs/pipe.c~pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits fs/pipe.c
--- a/fs/pipe.c~pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits
+++ a/fs/pipe.c
@@ -613,6 +613,11 @@ static bool too_many_pipe_buffers_hard(u
return pipe_user_pages_hard && user_bufs >= pipe_user_pages_hard;
}
+static bool is_unprivileged_user(void)
+{
+ return !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN);
+}
+
struct pipe_inode_info *alloc_pipe_info(void)
{
struct pipe_inode_info *pipe;
@@ -629,12 +634,12 @@ struct pipe_inode_info *alloc_pipe_info(
user_bufs = account_pipe_buffers(user, 0, pipe_bufs);
- if (too_many_pipe_buffers_soft(user_bufs)) {
+ if (too_many_pipe_buffers_soft(user_bufs) && is_unprivileged_user()) {
user_bufs = account_pipe_buffers(user, pipe_bufs, 1);
pipe_bufs = 1;
}
- if (too_many_pipe_buffers_hard(user_bufs))
+ if (too_many_pipe_buffers_hard(user_bufs) && is_unprivileged_user())
goto out_revert_acct;
pipe->bufs = kcalloc(pipe_bufs, sizeof(struct pipe_buffer),
@@ -1065,7 +1070,7 @@ static long pipe_set_size(struct pipe_in
if (nr_pages > pipe->buffers &&
(too_many_pipe_buffers_hard(user_bufs) ||
too_many_pipe_buffers_soft(user_bufs)) &&
- !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN)) {
+ is_unprivileged_user()) {
ret = -EPERM;
goto out_revert_acct;
}
_
Patches currently in -mm which might be from ebiggers(a)google.com are
userfaultfd-convert-to-use-anon_inode_getfd.patch
pipe-sysctl-drop-min-parameter-from-pipe-max-size-converter.patch
pipe-sysctl-remove-pipe_proc_fn.patch
pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch
pipe-fix-off-by-one-error-when-checking-buffer-limits.patch
pipe-reject-f_setpipe_sz-with-size-over-uint_max.patch
pipe-simplify-round_pipe_size.patch
pipe-read-buffer-limits-atomically.patch
Starting from commit 041e4575f034 ("mtd: nand: handle ECC errors in
OOB"), nand_do_read_oob() (from the NAND core) did return 0 or a
negative error, and the MTD layer expected it.
However, the trend for the NAND layer is now to return an error or a
positive number of bitflips. Deciding which status to return to the user
belongs to the MTD layer.
Commit e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()")
brought this logic to the mtd_read_oob() function while the status
coming from nand_do_read_oob() (called by the ->ecc.read_oob() hook) was
left unchanged.
Fixes: e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()")
Cc: stable(a)vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal(a)free-electrons.com>
---
drivers/mtd/nand/nand_base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 469220065b8b..88256b656072 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3876,7 +3876,7 @@ static int nand_do_read_oob(struct mtd_info *mtd, loff_t from,
if (mtd->ecc_stats.failed - stats.failed)
return -EBADMSG;
- return mtd->ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0;
+ return max_bitflips;
}
/**
--
2.11.0
Hi,
On 1/11/2018 12:16 AM, Felipe Balbi wrote:
>
> Hi,
>
> Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> writes:
>> In control read transfer completion handler, the driver needs to reset
>> the TRB enqueue counter. Since there is one control endpoint structure
>> for each direction, we must also track the TRB enqueue counter for each
>> direction. Currently the driver only resets the TRB counter for control
>> OUT endpoint only. Check for the data direction and properly reset the
>> TRB counter from correct control endpoint.
>>
>> Cc: stable(a)vger.kernel.org
>> Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com>
>
> missing Fixes tag
Same with this patch. There's no particular commit that it fixes.
BR,
Thinh
Hi,
On 1/11/2018 12:16 AM, Felipe Balbi wrote:
>
> Hi,
>
> Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> writes:
>> There are 2 control endpoint structures for DWC3. However, the driver
>> only updates the OUT direction control endpoint structure during
>> ConnectDone event. DWC3 driver needs to update the endpoint max packet
>> size for control IN endpoint as well. If the max packet size is not
>> properly set, then the driver will incorrectly calculate the data
>> transfer size and fail to send ZLP for HS/FS 3-stage control read
>> transfer.
>>
>> The fix is simply to update the max packet size for the ep0 IN direction
>> during ConnectDone event.
>>
>> Cc: stable(a)vger.kernel.org
>> Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com>
>
> missing Fixes tag
This bug has been there since the beginning. There's no particular
commit that it fixes.
BR,
Thinh
The patch below was submitted to be applied to the 4.14-stable tree.
I fail to see how this patch meets the stable kernel rules as found at
Documentation/process/stable-kernel-rules.rst.
I could be totally wrong, and if so, please respond to
<stable(a)vger.kernel.org> and let me know why this patch should be
applied. Otherwise, it is now dropped from my patch queues, never to be
seen again.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 3572f04c69ed4369da5d3c65d84fb18774aa60b6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com>
Date: Thu, 16 Nov 2017 18:02:15 +0200
Subject: [PATCH] drm/i915: Fix init_clock_gating for resume
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Moving the init_clock_gating() call from intel_modeset_init_hw() to
intel_modeset_gem_init() had an unintended effect of not applying
some workarounds on resume. This, for example, cause some kind of
corruption to appear at the top of my IVB Thinkpad X1 Carbon LVDS
screen after hibernation. Fix the problem by explicitly calling
init_clock_gating() from the resume path.
I really hope this doesn't break something else again. At least
the problems reported at https://bugs.freedesktop.org/show_bug.cgi?id=103549
didn't make a comeback, even after a hibernate cycle.
v2: Reorder the init_clock_gating vs. modeset_init_hw to match
the display reset path (Rodrigo)
Cc: stable(a)vger.kernel.org
Cc: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
Fixes: 6ac43272768c ("drm/i915: Move init_clock_gating() back to where it was")
Reviewed-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20171116160215.25715-1-ville.…
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
(cherry picked from commit 675f7ff35bd256e65d3d0f52718d8babf5d1002a)
Signed-off-by: Jani Nikula <jani.nikula(a)intel.com>
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 34191028bbad..7d9b07df32fa 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1714,6 +1714,7 @@ static int i915_drm_resume(struct drm_device *dev)
intel_guc_resume(dev_priv);
intel_modeset_init_hw(dev);
+ intel_init_clock_gating(dev_priv);
spin_lock_irq(&dev_priv->irq_lock);
if (dev_priv->display.hpd_irq_setup)
On Thu, 2018-01-11 at 21:00 +0200, Leon Romanovsky wrote:
> On Thu, Jan 11, 2018 at 04:02:33PM +0000, Bart Van Assche wrote:
> > On Thu, 2018-01-11 at 08:22 +0200, Leon Romanovsky wrote:
> > > The proposed patch definitely decreases the chance of races, but it is not fixing them.
> > > There is a chance to have change in qp state immediately after your "if ..." check.
> >
> > Hello Leon,
> >
> > Please have a look at rxe_qp_error() and you will see that the patch I posted
> > is a proper fix. In the scenario you described rxe_qp_error() will trigger a
> > run of rxe_completer().
>
> Bart,
>
> What am I missing?
>
> CPU1 CPU2
> if (unlikely....
> <---
> /* move the qp to the error state */
> void rxe_qp_error(struct rxe_qp *qp)
> {
> qp->req.state = QP_STATE_ERROR;
> qp->resp.state = QP_STATE_ERROR;
> qp->attr.qp_state = IB_QPS_ERR;
> --->
> rxe_run_task(&qp->req.task, must_sched);
>
>
>
> It is more or less the same as without "if (unlikely..."
Hello Leon,
In the above the part of rxe_qp_error() that I was referring to in my e-mail
is missing:
if (qp_type(qp) == IB_QPT_RC)
rxe_run_task(&qp->comp.task, 1);
Bart.
This is a note to let you know that I've just added the patch titled
usb: misc: usb3503: make sure reset is low for at least 100us
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 b8626f1dc29d3eee444bfaa92146ec7b291ef41c Mon Sep 17 00:00:00 2001
From: Stefan Agner <stefan(a)agner.ch>
Date: Thu, 11 Jan 2018 14:47:40 +0100
Subject: usb: misc: usb3503: make sure reset is low for at least 100us
When using a GPIO which is high by default, and initialize the
driver in USB Hub mode, initialization fails with:
[ 111.757794] usb3503 0-0008: SP_ILOCK failed (-5)
The reason seems to be that the chip is not properly reset.
Probe does initialize reset low, however some lines later the
code already set it back high, which is not long enouth.
Make sure reset is asserted for at least 100us by inserting a
delay after initializing the reset pin during probe.
Signed-off-by: Stefan Agner <stefan(a)agner.ch>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/misc/usb3503.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index 465dbf68b463..f723f7b8c9ac 100644
--- a/drivers/usb/misc/usb3503.c
+++ b/drivers/usb/misc/usb3503.c
@@ -279,6 +279,8 @@ static int usb3503_probe(struct usb3503 *hub)
if (gpio_is_valid(hub->gpio_reset)) {
err = devm_gpio_request_one(dev, hub->gpio_reset,
GPIOF_OUT_INIT_LOW, "usb3503 reset");
+ /* Datasheet defines a hardware reset to be at least 100us */
+ usleep_range(100, 10000);
if (err) {
dev_err(dev,
"unable to request GPIO %d as reset pin (%d)\n",
--
2.15.1
This is a stable-only fix for the backport of commit 5d9b70f7d52e
("xhci: Don't add a virt_dev to the devs array before it's fully
allocated").
In branches that predate commit c5628a2af83a ("xhci: remove endpoint
ring cache") there is an additional failure path in
xhci_alloc_virt_device() where ring cache allocation fails, in
which case we need to free the ring allocated for endpoint 0.
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
---
This is build-tested only.
Ben.
drivers/usb/host/xhci-mem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index f7481c4e2bc9..d9363713b7f1 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1071,7 +1071,8 @@ int xhci_alloc_virt_device(struct xhci_hcd *xhci, int slot_id,
return 1;
fail:
-
+ if (dev->eps[0].ring)
+ xhci_ring_free(xhci, dev->eps[0].ring);
if (dev->in_ctx)
xhci_free_container_ctx(xhci, dev->in_ctx);
if (dev->out_ctx)
--
2.15.0.rc0
This is a note to let you know that I've just added the patch titled
USB: serial: cp210x: add new device ID ELV ALC 8xxx
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 d14ac576d10f865970bb1324d337e5e24d79aaf4 Mon Sep 17 00:00:00 2001
From: Christian Holl <cyborgx1(a)gmail.com>
Date: Wed, 3 Jan 2018 19:53:02 +0100
Subject: USB: serial: cp210x: add new device ID ELV ALC 8xxx
This adds the ELV ALC 8xxx Battery Charging device
to the list of USB IDs of drivers/usb/serial/cp210x.c
Signed-off-by: Christian Holl <cyborgx1(a)gmail.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
---
drivers/usb/serial/cp210x.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 38814225a816..06d502b3e913 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -175,6 +175,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x1843, 0x0200) }, /* Vaisala USB Instrument Cable */
{ USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */
{ USB_DEVICE(0x18EF, 0xE025) }, /* ELV Marble Sound Board 1 */
+ { USB_DEVICE(0x18EF, 0xE030) }, /* ELV ALC 8xxx Battery Charger */
{ USB_DEVICE(0x18EF, 0xE032) }, /* ELV TFD500 Data Logger */
{ USB_DEVICE(0x1901, 0x0190) }, /* GE B850 CP2105 Recorder interface */
{ USB_DEVICE(0x1901, 0x0193) }, /* GE B650 CP2104 PMC interface */
--
2.15.1
This is a note to let you know that I've just added the patch titled
USB: serial: cp210x: add IDs for LifeScan OneTouch Verio IQ
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 4307413256ac1e09b8f53e8715af3df9e49beec3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Diego=20Elio=20Petten=C3=B2?= <flameeyes(a)flameeyes.eu>
Date: Fri, 29 Dec 2017 09:54:25 +0000
Subject: USB: serial: cp210x: add IDs for LifeScan OneTouch Verio IQ
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Add IDs for the OneTouch Verio IQ that comes with an embedded
USB-to-serial converter.
Signed-off-by: Diego Elio Pettenò <flameeyes(a)flameeyes.eu>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
---
drivers/usb/serial/cp210x.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 7c6273bf5beb..38814225a816 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -124,6 +124,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x10C4, 0x8470) }, /* Juniper Networks BX Series System Console */
{ USB_DEVICE(0x10C4, 0x8477) }, /* Balluff RFID */
{ USB_DEVICE(0x10C4, 0x84B6) }, /* Starizona Hyperion */
+ { USB_DEVICE(0x10C4, 0x85A7) }, /* LifeScan OneTouch Verio IQ */
{ USB_DEVICE(0x10C4, 0x85EA) }, /* AC-Services IBUS-IF */
{ USB_DEVICE(0x10C4, 0x85EB) }, /* AC-Services CIS-IBUS */
{ USB_DEVICE(0x10C4, 0x85F8) }, /* Virtenio Preon32 */
--
2.15.1
The following sequence:
* Change queue pair state into IB_QPS_ERR.
* Post a work request on the queue pair.
Triggers the following race condition in the rdma_rxe driver:
* rxe_qp_error() triggers an asynchronous call of rxe_completer(), the function
that examines the QP send queue.
* rxe_post_send() posts a work request on the QP send queue.
Avoid that this race causes a work request to be ignored by scheduling
an rxe_completer() call from rxe_post_send() for queues that are in the
error state.
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: Moni Shoua <monis(a)mellanox.com>
Cc: <stable(a)vger.kernel.org> # v4.8
---
drivers/infiniband/sw/rxe/rxe_verbs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.c b/drivers/infiniband/sw/rxe/rxe_verbs.c
index a6fbed48db8a..8f631d64c192 100644
--- a/drivers/infiniband/sw/rxe/rxe_verbs.c
+++ b/drivers/infiniband/sw/rxe/rxe_verbs.c
@@ -814,6 +814,8 @@ static int rxe_post_send_kernel(struct rxe_qp *qp, struct ib_send_wr *wr,
(queue_count(qp->sq.queue) > 1);
rxe_run_task(&qp->req.task, must_sched);
+ if (unlikely(qp->req.state == QP_STATE_ERROR))
+ rxe_run_task(&qp->comp.task, 1);
return err;
}
--
2.15.1
On Thu, 2018-01-11 at 08:22 +0200, Leon Romanovsky wrote:
> The proposed patch definitely decreases the chance of races, but it is not fixing them.
> There is a chance to have change in qp state immediately after your "if ..." check.
Hello Leon,
Please have a look at rxe_qp_error() and you will see that the patch I posted
is a proper fix. In the scenario you described rxe_qp_error() will trigger a
run of rxe_completer().
Bart.
Stefan Wahren reports a problem with a warning fix that was merged
for v4.15: we had lots of device nodes with a 'phys' property pointing
to a device node that is not compliant with the binding documented in
Documentation/devicetree/bindings/phy/phy-bindings.txt
This generally works because USB HCD drivers that support both the generic
phy subsystem and the older usb-phy subsystem ignore most errors from
phy_get() and related calls and then use the usb-phy driver instead.
However, usb_add_hcd() (along with the respective functions in dwc2 and
dwc3) propagate the EPROBE_DEFER return code so we can try again whenever
the driver gets loaded. In case the driver is written for the usb-phy
subsystem (like usb-generic-phy aka usb-nop-xceiv), we will never load
a generic-phy driver for it, and keep failing here.
There is only a small number of remaining usb-phy drivers that support
device tree, so this adds a workaround by providing a full list of the
potentially affected drivers, and always failing the probe with -ENODEV
here, which is the same behavior that we used to get with incorrect
device tree files. Since we generally want older kernels to also want
to work with the fixed devicetree files, it would be good to backport
the patch into stable kernels as well (3.13+ are possibly affected).
Reverting back to the DTS sources that work would in theory fix USB
support for now, but in the long run we'd run into the same problem
again when the drivers get ported from usb-phy to generic-phy.
Fixes: 014d6da6cb25 ("ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells")
Link: https://marc.info/?l=linux-usb&m=151518314314753&w=2
Cc: stable(a)vger.kernel.org
Cc: Stefan Wahren <stefan.wahren(a)i2se.com>
Cc: Felipe Balbi <balbi(a)kernel.org>
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
This obviously needs to be tested, I wrote this up as a reply to
Stefan's bug report. I'm fairly sure that I covered all usb-phy
driver strings here. My goal is to have a fix merged into 4.15
rather than reverting all the DT fixes.
---
drivers/phy/phy-core.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index b4964b067aec..bb4dd2a2de2d 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -387,6 +387,24 @@ int phy_calibrate(struct phy *phy)
}
EXPORT_SYMBOL_GPL(phy_calibrate);
+static struct of_device_id __maybe_unused legacy_usbphy[] = {
+ { .compatible = "fsl,imx23-usbphy" },
+ { .compatible = "fsl,imx6q-usbphy" },
+ { .compatible = "fsl,imx6sl-usbphy" },
+ { .compatible = "fsl,imx6sx-usbphy" },
+ { .compatible = "fsl,imx6ul-usbphy" },
+ { .compatible = "fsl,vf610-usbphy" },
+ { .compatible = "nvidia,tegra20-usb-phy" },
+ { .compatible = "nvidia,tegra30-usb-phy" },
+ { .compatible = "nxp,isp1301" },
+ { .compatible = "ti,am335x-usb-ctrl-module" },
+ { .compatible = "ti,am335x-usb-phy" },
+ { .compatible = "ti,keystone-usbphy" },
+ { .compatible = "ti,twl6030-usb" },
+ { .compatible = "usb-nop-xceiv" },
+ {},
+};
+
/**
* _of_phy_get() - lookup and obtain a reference to a phy by phandle
* @np: device_node for which to get the phy
@@ -410,6 +428,15 @@ static struct phy *_of_phy_get(struct device_node *np, int index)
if (ret)
return ERR_PTR(-ENODEV);
+ /*
+ * Some USB host controllers use a "phys" property to refer to
+ * a device that does not have a generic phy driver but that
+ * has a driver for the older usb-phy framework.
+ * We must not return -EPROBE_DEFER for those, so bail out early.
+ */
+ if (of_match_node(legacy_usbphy, args.np))
+ return ERR_PTR(-ENODEV);
+
mutex_lock(&phy_provider_mutex);
phy_provider = of_phy_provider_lookup(args.np);
if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) {
--
2.9.0
This is a note to let you know that I've just added the patch titled
lan78xx: use skb_cow_head() to deal with cloned skbs
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:
lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.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 d4ca73591916b760478d2b04334d5dcadc028e9c Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet(a)google.com>
Date: Wed, 19 Apr 2017 09:59:24 -0700
Subject: lan78xx: use skb_cow_head() to deal with cloned skbs
From: Eric Dumazet <edumazet(a)google.com>
commit d4ca73591916b760478d2b04334d5dcadc028e9c upstream.
We need to ensure there is enough headroom to push extra header,
but we also need to check if we are allowed to change headers.
skb_cow_head() is the proper helper to deal with this.
Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Cc: James Hughes <james.hughes(a)raspberrypi.org>
Cc: Woojung Huh <woojung.huh(a)microchip.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/usb/lan78xx.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -2419,14 +2419,9 @@ static struct sk_buff *lan78xx_tx_prep(s
{
u32 tx_cmd_a, tx_cmd_b;
- if (skb_headroom(skb) < TX_OVERHEAD) {
- struct sk_buff *skb2;
-
- skb2 = skb_copy_expand(skb, TX_OVERHEAD, 0, flags);
+ if (skb_cow_head(skb, TX_OVERHEAD)) {
dev_kfree_skb_any(skb);
- skb = skb2;
- if (!skb)
- return NULL;
+ return NULL;
}
if (lan78xx_linearize(skb) < 0)
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.9/lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.9/cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.9/sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.9/smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch
This is a note to let you know that I've just added the patch titled
smsc75xx: use skb_cow_head() to deal with cloned skbs
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:
smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.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 b7c6d2675899cfff0180412c63fc9cbd5bacdb4d Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet(a)google.com>
Date: Wed, 19 Apr 2017 09:59:21 -0700
Subject: smsc75xx: use skb_cow_head() to deal with cloned skbs
From: Eric Dumazet <edumazet(a)google.com>
commit b7c6d2675899cfff0180412c63fc9cbd5bacdb4d upstream.
We need to ensure there is enough headroom to push extra header,
but we also need to check if we are allowed to change headers.
skb_cow_head() is the proper helper to deal with this.
Fixes: d0cad871703b ("smsc75xx: SMSC LAN75xx USB gigabit ethernet adapter driver")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Cc: James Hughes <james.hughes(a)raspberrypi.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/usb/smsc75xx.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -2205,13 +2205,9 @@ static struct sk_buff *smsc75xx_tx_fixup
{
u32 tx_cmd_a, tx_cmd_b;
- if (skb_headroom(skb) < SMSC75XX_TX_OVERHEAD) {
- struct sk_buff *skb2 =
- skb_copy_expand(skb, SMSC75XX_TX_OVERHEAD, 0, flags);
+ if (skb_cow_head(skb, SMSC75XX_TX_OVERHEAD)) {
dev_kfree_skb_any(skb);
- skb = skb2;
- if (!skb)
- return NULL;
+ return NULL;
}
tx_cmd_a = (u32)(skb->len & TX_CMD_A_LEN) | TX_CMD_A_FCS;
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.9/lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.9/cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.9/sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.9/smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch
This is a note to let you know that I've just added the patch titled
sr9700: use skb_cow_head() to deal with cloned skbs
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:
sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.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 d532c1082f68176363ed766d09bf187616e282fe Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet(a)google.com>
Date: Wed, 19 Apr 2017 09:59:23 -0700
Subject: sr9700: use skb_cow_head() to deal with cloned skbs
From: Eric Dumazet <edumazet(a)google.com>
commit d532c1082f68176363ed766d09bf187616e282fe upstream.
We need to ensure there is enough headroom to push extra header,
but we also need to check if we are allowed to change headers.
skb_cow_head() is the proper helper to deal with this.
Fixes: c9b37458e956 ("USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700Device Driver Support")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Cc: James Hughes <james.hughes(a)raspberrypi.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/usb/sr9700.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
--- a/drivers/net/usb/sr9700.c
+++ b/drivers/net/usb/sr9700.c
@@ -456,14 +456,9 @@ static struct sk_buff *sr9700_tx_fixup(s
len = skb->len;
- if (skb_headroom(skb) < SR_TX_OVERHEAD) {
- struct sk_buff *skb2;
-
- skb2 = skb_copy_expand(skb, SR_TX_OVERHEAD, 0, flags);
+ if (skb_cow_head(skb, SR_TX_OVERHEAD)) {
dev_kfree_skb_any(skb);
- skb = skb2;
- if (!skb)
- return NULL;
+ return NULL;
}
__skb_push(skb, SR_TX_OVERHEAD);
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.9/lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.9/cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.9/sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.9/smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch
This is a note to let you know that I've just added the patch titled
cx82310_eth: use skb_cow_head() to deal with cloned skbs
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:
cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.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 a9e840a2081ed28c2b7caa6a9a0041c950b3c37d Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet(a)google.com>
Date: Wed, 19 Apr 2017 09:59:22 -0700
Subject: cx82310_eth: use skb_cow_head() to deal with cloned skbs
From: Eric Dumazet <edumazet(a)google.com>
commit a9e840a2081ed28c2b7caa6a9a0041c950b3c37d upstream.
We need to ensure there is enough headroom to push extra header,
but we also need to check if we are allowed to change headers.
skb_cow_head() is the proper helper to deal with this.
Fixes: cc28a20e77b2 ("introduce cx82310_eth: Conexant CX82310-based ADSL router USB ethernet driver")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Cc: James Hughes <james.hughes(a)raspberrypi.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/usb/cx82310_eth.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
--- a/drivers/net/usb/cx82310_eth.c
+++ b/drivers/net/usb/cx82310_eth.c
@@ -293,12 +293,9 @@ static struct sk_buff *cx82310_tx_fixup(
{
int len = skb->len;
- if (skb_headroom(skb) < 2) {
- struct sk_buff *skb2 = skb_copy_expand(skb, 2, 0, flags);
+ if (skb_cow_head(skb, 2)) {
dev_kfree_skb_any(skb);
- skb = skb2;
- if (!skb)
- return NULL;
+ return NULL;
}
skb_push(skb, 2);
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.9/lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.9/cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.9/sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.9/smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch
This is a note to let you know that I've just added the patch titled
x86/mm/pat, /dev/mem: Remove superfluous error message
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:
x86-mm-pat-dev-mem-remove-superfluous-error-message.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 39380b80d72723282f0ea1d1bbf2294eae45013e Mon Sep 17 00:00:00 2001
From: Jiri Kosina <jkosina(a)suse.cz>
Date: Fri, 8 Jul 2016 11:38:28 +0200
Subject: x86/mm/pat, /dev/mem: Remove superfluous error message
From: Jiri Kosina <jkosina(a)suse.cz>
commit 39380b80d72723282f0ea1d1bbf2294eae45013e upstream.
Currently it's possible for broken (or malicious) userspace to flood a
kernel log indefinitely with messages a-la
Program dmidecode tried to access /dev/mem between f0000->100000
because range_is_allowed() is case of CONFIG_STRICT_DEVMEM being turned on
dumps this information each and every time devmem_is_allowed() fails.
Reportedly userspace that is able to trigger contignuous flow of these
messages exists.
It would be possible to rate limit this message, but that'd have a
questionable value; the administrator wouldn't get information about all
the failing accessess, so then the information would be both superfluous
and incomplete at the same time :)
Returning EPERM (which is what is actually happening) is enough indication
for userspace what has happened; no need to log this particular error as
some sort of special condition.
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Brian Gerst <brgerst(a)gmail.com>
Cc: Denys Vlasenko <dvlasenk(a)redhat.com>
Cc: H. Peter Anvin <hpa(a)zytor.com>
Cc: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Luis R. Rodriguez <mcgrof(a)suse.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Toshi Kani <toshi.kani(a)hp.com>
Link: http://lkml.kernel.org/r/alpine.LNX.2.00.1607081137020.24757@cbobk.fhfr.pm
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/mm/pat.c | 5 +----
drivers/char/mem.c | 6 +-----
2 files changed, 2 insertions(+), 9 deletions(-)
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -750,11 +750,8 @@ static inline int range_is_allowed(unsig
return 1;
while (cursor < to) {
- if (!devmem_is_allowed(pfn)) {
- pr_info("x86/PAT: Program %s tried to access /dev/mem between [mem %#010Lx-%#010Lx], PAT prevents it\n",
- current->comm, from, to - 1);
+ if (!devmem_is_allowed(pfn))
return 0;
- }
cursor += PAGE_SIZE;
pfn++;
}
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -70,12 +70,8 @@ static inline int range_is_allowed(unsig
u64 cursor = from;
while (cursor < to) {
- if (!devmem_is_allowed(pfn)) {
- printk(KERN_INFO
- "Program %s tried to access /dev/mem between %Lx->%Lx.\n",
- current->comm, from, to);
+ if (!devmem_is_allowed(pfn))
return 0;
- }
cursor += PAGE_SIZE;
pfn++;
}
Patches currently in stable-queue which might be from jkosina(a)suse.cz are
queue-4.4/x86-mm-pat-dev-mem-remove-superfluous-error-message.patch
This is a note to let you know that I've just added the patch titled
[media] usbvision fix overflow of interfaces array
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:
usbvision-fix-overflow-of-interfaces-array.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 588afcc1c0e45358159090d95bf7b246fb67565f Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum(a)suse.com>
Date: Tue, 27 Oct 2015 09:51:34 -0200
Subject: [media] usbvision fix overflow of interfaces array
From: Oliver Neukum <oneukum(a)suse.com>
commit 588afcc1c0e45358159090d95bf7b246fb67565f upstream.
This fixes the crash reported in:
http://seclists.org/bugtraq/2015/Oct/35
The interface number needs a sanity check.
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
Cc: Vladis Dronov <vdronov(a)redhat.com>
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/usb/usbvision/usbvision-video.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/media/usb/usbvision/usbvision-video.c
+++ b/drivers/media/usb/usbvision/usbvision-video.c
@@ -1461,6 +1461,13 @@ static int usbvision_probe(struct usb_in
printk(KERN_INFO "%s: %s found\n", __func__,
usbvision_device_data[model].model_string);
+ /*
+ * this is a security check.
+ * an exploit using an incorrect bInterfaceNumber is known
+ */
+ if (ifnum >= USB_MAXINTERFACES || !dev->actconfig->interface[ifnum])
+ return -ENODEV;
+
if (usbvision_device_data[model].interface >= 0)
interface = &dev->actconfig->interface[usbvision_device_data[model].interface]->altsetting[0];
else if (ifnum < dev->actconfig->desc.bNumInterfaces)
Patches currently in stable-queue which might be from oneukum(a)suse.com are
queue-4.4/lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.4/cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.4/r8152-fix-the-wake-event.patch
queue-4.4/sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.4/r8152-adjust-aldps-function.patch
queue-4.4/smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.4/usbvision-fix-overflow-of-interfaces-array.patch
queue-4.4/r8152-use-test_and_clear_bit.patch
queue-4.4/usb-musb-ux500-fix-null-pointer-dereference-at-system-pm.patch
This is a note to let you know that I've just added the patch titled
sysrq: Fix warning in sysrq generated crash.
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:
sysrq-fix-warning-in-sysrq-generated-crash.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 984cf355aeaa8f2eda3861b50d0e8d3e3f77e83b Mon Sep 17 00:00:00 2001
From: Ani Sinha <ani(a)arista.com>
Date: Thu, 17 Dec 2015 17:15:10 -0800
Subject: sysrq: Fix warning in sysrq generated crash.
From: Ani Sinha <ani(a)arista.com>
commit 984cf355aeaa8f2eda3861b50d0e8d3e3f77e83b upstream.
Commit 984d74a72076a1 ("sysrq: rcu-ify __handle_sysrq") replaced
spin_lock_irqsave() calls with rcu_read_lock() calls in sysrq. Since
rcu_read_lock() does not disable preemption, faulthandler_disabled() in
__do_page_fault() in x86/fault.c returns false. When the code later calls
might_sleep() in the pagefault handler, we get the following warning:
BUG: sleeping function called from invalid context at ../arch/x86/mm/fault.c:1187
in_atomic(): 0, irqs_disabled(): 0, pid: 4706, name: bash
Preemption disabled at:[<ffffffff81484339>] printk+0x48/0x4a
To fix this, we release the RCU read lock before we crash.
Tested this patch on linux 3.18 by booting off one of our boards.
Fixes: 984d74a72076a1 ("sysrq: rcu-ify __handle_sysrq")
Signed-off-by: Ani Sinha <ani(a)arista.com>
Reviewed-by: Rik van Riel <riel(a)redhat.com>
Signed-off-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
Signed-off-by: Davidlohr Bueso <dbueso(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/sysrq.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -133,6 +133,12 @@ static void sysrq_handle_crash(int key)
{
char *killer = NULL;
+ /* we need to release the RCU read lock here,
+ * otherwise we get an annoying
+ * 'BUG: sleeping function called from invalid context'
+ * complaint from the kernel before the panic.
+ */
+ rcu_read_unlock();
panic_on_oops = 1; /* force panic */
wmb();
*killer = 1;
Patches currently in stable-queue which might be from ani(a)arista.com are
queue-4.4/sysrq-fix-warning-in-sysrq-generated-crash.patch
This is a note to let you know that I've just added the patch titled
usb: musb: ux500: Fix NULL pointer dereference at system PM
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-ux500-fix-null-pointer-dereference-at-system-pm.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 79c5623f1cb85f33403eb9f1e45124e9f56181f8 Mon Sep 17 00:00:00 2001
From: Ulf Hansson <ulf.hansson(a)linaro.org>
Date: Mon, 25 Jan 2016 13:01:29 +0100
Subject: usb: musb: ux500: Fix NULL pointer dereference at system PM
From: Ulf Hansson <ulf.hansson(a)linaro.org>
commit 79c5623f1cb85f33403eb9f1e45124e9f56181f8 upstream.
The commit 7d32cdef5356 ("usb: musb: fail with error when no DMA
controller set"), caused the core platform driver to correctly return an
error code when fail probing.
Unfurtante it also caused bug for a NULL pointer dereference, during
system suspend for the ux500 driver. The reason is a lacking validation
of the corresponding ->driver_data pointer, which won't be set when the
musb core driver fails to probe (or haven't yet been probed).
Fixes: 7d32cdef5356 ("usb: musb: fail with error when no DMA...")
Acked-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Signed-off-by: Felipe Balbi <balbi(a)kernel.org>
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/musb/ux500.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/usb/musb/ux500.c
+++ b/drivers/usb/musb/ux500.c
@@ -348,7 +348,9 @@ static int ux500_suspend(struct device *
struct ux500_glue *glue = dev_get_drvdata(dev);
struct musb *musb = glue_to_musb(glue);
- usb_phy_set_suspend(musb->xceiv, 1);
+ if (musb)
+ usb_phy_set_suspend(musb->xceiv, 1);
+
clk_disable_unprepare(glue->clk);
return 0;
@@ -366,7 +368,8 @@ static int ux500_resume(struct device *d
return ret;
}
- usb_phy_set_suspend(musb->xceiv, 0);
+ if (musb)
+ usb_phy_set_suspend(musb->xceiv, 0);
return 0;
}
Patches currently in stable-queue which might be from ulf.hansson(a)linaro.org are
queue-4.4/usb-musb-ux500-fix-null-pointer-dereference-at-system-pm.patch
This is a note to let you know that I've just added the patch titled
smsc75xx: use skb_cow_head() to deal with cloned skbs
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:
smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.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 b7c6d2675899cfff0180412c63fc9cbd5bacdb4d Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet(a)google.com>
Date: Wed, 19 Apr 2017 09:59:21 -0700
Subject: smsc75xx: use skb_cow_head() to deal with cloned skbs
From: Eric Dumazet <edumazet(a)google.com>
commit b7c6d2675899cfff0180412c63fc9cbd5bacdb4d upstream.
We need to ensure there is enough headroom to push extra header,
but we also need to check if we are allowed to change headers.
skb_cow_head() is the proper helper to deal with this.
Fixes: d0cad871703b ("smsc75xx: SMSC LAN75xx USB gigabit ethernet adapter driver")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Cc: James Hughes <james.hughes(a)raspberrypi.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/usb/smsc75xx.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -2193,13 +2193,9 @@ static struct sk_buff *smsc75xx_tx_fixup
{
u32 tx_cmd_a, tx_cmd_b;
- if (skb_headroom(skb) < SMSC75XX_TX_OVERHEAD) {
- struct sk_buff *skb2 =
- skb_copy_expand(skb, SMSC75XX_TX_OVERHEAD, 0, flags);
+ if (skb_cow_head(skb, SMSC75XX_TX_OVERHEAD)) {
dev_kfree_skb_any(skb);
- skb = skb2;
- if (!skb)
- return NULL;
+ return NULL;
}
tx_cmd_a = (u32)(skb->len & TX_CMD_A_LEN) | TX_CMD_A_FCS;
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.4/lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.4/cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.4/sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.4/smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch
This is a note to let you know that I've just added the patch titled
sr9700: use skb_cow_head() to deal with cloned skbs
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:
sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.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 d532c1082f68176363ed766d09bf187616e282fe Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet(a)google.com>
Date: Wed, 19 Apr 2017 09:59:23 -0700
Subject: sr9700: use skb_cow_head() to deal with cloned skbs
From: Eric Dumazet <edumazet(a)google.com>
commit d532c1082f68176363ed766d09bf187616e282fe upstream.
We need to ensure there is enough headroom to push extra header,
but we also need to check if we are allowed to change headers.
skb_cow_head() is the proper helper to deal with this.
Fixes: c9b37458e956 ("USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700Device Driver Support")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Cc: James Hughes <james.hughes(a)raspberrypi.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/usb/sr9700.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
--- a/drivers/net/usb/sr9700.c
+++ b/drivers/net/usb/sr9700.c
@@ -456,14 +456,9 @@ static struct sk_buff *sr9700_tx_fixup(s
len = skb->len;
- if (skb_headroom(skb) < SR_TX_OVERHEAD) {
- struct sk_buff *skb2;
-
- skb2 = skb_copy_expand(skb, SR_TX_OVERHEAD, 0, flags);
+ if (skb_cow_head(skb, SR_TX_OVERHEAD)) {
dev_kfree_skb_any(skb);
- skb = skb2;
- if (!skb)
- return NULL;
+ return NULL;
}
__skb_push(skb, SR_TX_OVERHEAD);
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.4/lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.4/cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.4/sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.4/smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch
This is a note to let you know that I've just added the patch titled
r8152: fix the wake event
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:
r8152-fix-the-wake-event.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 5ee3c60c8d3b88cab6496c9b7d49a01576dd9cf9 Mon Sep 17 00:00:00 2001
From: hayeswang <hayeswang(a)realtek.com>
Date: Thu, 7 Jan 2016 17:12:17 +0800
Subject: r8152: fix the wake event
From: hayeswang <hayeswang(a)realtek.com>
commit 5ee3c60c8d3b88cab6496c9b7d49a01576dd9cf9 upstream.
When the autosuspend is enabled and occurs before system suspend, we should
wake the device before running system syspend. Then, we could change the wake
event for system suspend. Otherwise, the device would resume the system when
receiving any packet.
Signed-off-by: Hayes Wang <hayeswang(a)realtek.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/usb/r8152.c | 40 +++++++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -25,12 +25,13 @@
#include <uapi/linux/mdio.h>
#include <linux/mdio.h>
#include <linux/usb/cdc.h>
+#include <linux/suspend.h>
/* Information for net-next */
#define NETNEXT_VERSION "08"
/* Information for net */
-#define NET_VERSION "2"
+#define NET_VERSION "3"
#define DRIVER_VERSION "v1." NETNEXT_VERSION "." NET_VERSION
#define DRIVER_AUTHOR "Realtek linux nic maintainers <nic_swsd(a)realtek.com>"
@@ -604,6 +605,9 @@ struct r8152 {
struct delayed_work schedule;
struct mii_if_info mii;
struct mutex control; /* use for hw setting */
+#ifdef CONFIG_PM_SLEEP
+ struct notifier_block pm_notifier;
+#endif
struct rtl_ops {
void (*init)(struct r8152 *);
@@ -3060,6 +3064,33 @@ out1:
usb_autopm_put_interface(tp->intf);
}
+#ifdef CONFIG_PM_SLEEP
+static int rtl_notifier(struct notifier_block *nb, unsigned long action,
+ void *data)
+{
+ struct r8152 *tp = container_of(nb, struct r8152, pm_notifier);
+
+ switch (action) {
+ case PM_HIBERNATION_PREPARE:
+ case PM_SUSPEND_PREPARE:
+ usb_autopm_get_interface(tp->intf);
+ break;
+
+ case PM_POST_HIBERNATION:
+ case PM_POST_SUSPEND:
+ usb_autopm_put_interface(tp->intf);
+ break;
+
+ case PM_POST_RESTORE:
+ case PM_RESTORE_PREPARE:
+ default:
+ break;
+ }
+
+ return NOTIFY_DONE;
+}
+#endif
+
static int rtl8152_open(struct net_device *netdev)
{
struct r8152 *tp = netdev_priv(netdev);
@@ -3102,6 +3133,10 @@ static int rtl8152_open(struct net_devic
mutex_unlock(&tp->control);
usb_autopm_put_interface(tp->intf);
+#ifdef CONFIG_PM_SLEEP
+ tp->pm_notifier.notifier_call = rtl_notifier;
+ register_pm_notifier(&tp->pm_notifier);
+#endif
out:
return res;
@@ -3112,6 +3147,9 @@ static int rtl8152_close(struct net_devi
struct r8152 *tp = netdev_priv(netdev);
int res = 0;
+#ifdef CONFIG_PM_SLEEP
+ unregister_pm_notifier(&tp->pm_notifier);
+#endif
napi_disable(&tp->napi);
clear_bit(WORK_ENABLE, &tp->flags);
usb_kill_urb(tp->intr_urb);
Patches currently in stable-queue which might be from hayeswang(a)realtek.com are
queue-4.4/r8152-fix-the-wake-event.patch
queue-4.4/r8152-adjust-aldps-function.patch
queue-4.4/r8152-use-test_and_clear_bit.patch
This is a note to let you know that I've just added the patch titled
r8152: use test_and_clear_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:
r8152-use-test_and_clear_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 216a8349d3a0dd1bc2afbcc821e374c8f929bd62 Mon Sep 17 00:00:00 2001
From: hayeswang <hayeswang(a)realtek.com>
Date: Thu, 7 Jan 2016 17:51:11 +0800
Subject: r8152: use test_and_clear_bit
From: hayeswang <hayeswang(a)realtek.com>
commit 216a8349d3a0dd1bc2afbcc821e374c8f929bd62 upstream.
Replace test_bit() followed by clear_bit() with test_and_clear_bit().
Signed-off-by: Hayes Wang <hayeswang(a)realtek.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/usb/r8152.c | 20 ++++++--------------
1 file changed, 6 insertions(+), 14 deletions(-)
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1947,7 +1947,6 @@ static void _rtl8152_set_rx_mode(struct
__le32 tmp[2];
u32 ocp_data;
- clear_bit(RTL8152_SET_RX_MODE, &tp->flags);
netif_stop_queue(netdev);
ocp_data = ocp_read_dword(tp, MCU_TYPE_PLA, PLA_RCR);
ocp_data &= ~RCR_ACPT_ALL;
@@ -2433,8 +2432,6 @@ static void rtl_phy_reset(struct r8152 *
u16 data;
int i;
- clear_bit(PHY_RESET, &tp->flags);
-
data = r8152_mdio_read(tp, MII_BMCR);
/* don't reset again before the previous one complete */
@@ -2893,10 +2890,9 @@ static int rtl8152_set_speed(struct r815
r8152_mdio_write(tp, MII_ADVERTISE, anar);
r8152_mdio_write(tp, MII_BMCR, bmcr);
- if (test_bit(PHY_RESET, &tp->flags)) {
+ if (test_and_clear_bit(PHY_RESET, &tp->flags)) {
int i;
- clear_bit(PHY_RESET, &tp->flags);
for (i = 0; i < 50; i++) {
msleep(20);
if ((r8152_mdio_read(tp, MII_BMCR) & BMCR_RESET) == 0)
@@ -2905,7 +2901,6 @@ static int rtl8152_set_speed(struct r815
}
out:
-
return ret;
}
@@ -2992,7 +2987,6 @@ static void set_carrier(struct r8152 *tp
struct net_device *netdev = tp->netdev;
u8 speed;
- clear_bit(RTL8152_LINK_CHG, &tp->flags);
speed = rtl8152_get_speed(tp);
if (speed & LINK_STATUS) {
@@ -3042,20 +3036,18 @@ static void rtl_work_func_t(struct work_
goto out1;
}
- if (test_bit(RTL8152_LINK_CHG, &tp->flags))
+ if (test_and_clear_bit(RTL8152_LINK_CHG, &tp->flags))
set_carrier(tp);
- if (test_bit(RTL8152_SET_RX_MODE, &tp->flags))
+ if (test_and_clear_bit(RTL8152_SET_RX_MODE, &tp->flags))
_rtl8152_set_rx_mode(tp->netdev);
/* don't schedule napi before linking */
- if (test_bit(SCHEDULE_NAPI, &tp->flags) &&
- netif_carrier_ok(tp->netdev)) {
- clear_bit(SCHEDULE_NAPI, &tp->flags);
+ if (test_and_clear_bit(SCHEDULE_NAPI, &tp->flags) &&
+ netif_carrier_ok(tp->netdev))
napi_schedule(&tp->napi);
- }
- if (test_bit(PHY_RESET, &tp->flags))
+ if (test_and_clear_bit(PHY_RESET, &tp->flags))
rtl_phy_reset(tp);
mutex_unlock(&tp->control);
Patches currently in stable-queue which might be from hayeswang(a)realtek.com are
queue-4.4/r8152-fix-the-wake-event.patch
queue-4.4/r8152-adjust-aldps-function.patch
queue-4.4/r8152-use-test_and_clear_bit.patch
This is a note to let you know that I've just added the patch titled
lan78xx: use skb_cow_head() to deal with cloned skbs
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:
lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.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 d4ca73591916b760478d2b04334d5dcadc028e9c Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet(a)google.com>
Date: Wed, 19 Apr 2017 09:59:24 -0700
Subject: lan78xx: use skb_cow_head() to deal with cloned skbs
From: Eric Dumazet <edumazet(a)google.com>
commit d4ca73591916b760478d2b04334d5dcadc028e9c upstream.
We need to ensure there is enough headroom to push extra header,
but we also need to check if we are allowed to change headers.
skb_cow_head() is the proper helper to deal with this.
Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Cc: James Hughes <james.hughes(a)raspberrypi.org>
Cc: Woojung Huh <woojung.huh(a)microchip.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/usb/lan78xx.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -2050,14 +2050,9 @@ static struct sk_buff *lan78xx_tx_prep(s
{
u32 tx_cmd_a, tx_cmd_b;
- if (skb_headroom(skb) < TX_OVERHEAD) {
- struct sk_buff *skb2;
-
- skb2 = skb_copy_expand(skb, TX_OVERHEAD, 0, flags);
+ if (skb_cow_head(skb, TX_OVERHEAD)) {
dev_kfree_skb_any(skb);
- skb = skb2;
- if (!skb)
- return NULL;
+ return NULL;
}
if (lan78xx_linearize(skb) < 0)
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.4/lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.4/cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.4/sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.4/smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch
This is a note to let you know that I've just added the patch titled
hwrng: core - sleep interruptible in read
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:
hwrng-core-sleep-interruptible-in-read.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 1ab87298cb59b649d8d648d25dc15b36ab865f5a Mon Sep 17 00:00:00 2001
From: Jiri Slaby <jslaby(a)suse.cz>
Date: Fri, 27 Nov 2015 16:50:43 +0100
Subject: hwrng: core - sleep interruptible in read
From: Jiri Slaby <jslaby(a)suse.cz>
commit 1ab87298cb59b649d8d648d25dc15b36ab865f5a upstream.
hwrng kthread can be waiting via hwrng_fillfn for some data from a rng
like virtio-rng:
hwrng D ffff880093e17798 0 382 2 0x00000000
...
Call Trace:
[<ffffffff817339c6>] wait_for_completion_killable+0x96/0x210
[<ffffffffa00aa1b7>] virtio_read+0x57/0xf0 [virtio_rng]
[<ffffffff814f4a35>] hwrng_fillfn+0x75/0x130
[<ffffffff810aa243>] kthread+0xf3/0x110
And when some user program tries to read the /dev node in this state,
we get:
rngd D ffff880093e17798 0 762 1 0x00000004
...
Call Trace:
[<ffffffff817351ac>] mutex_lock_nested+0x15c/0x3e0
[<ffffffff814f478e>] rng_dev_read+0x6e/0x240
[<ffffffff81231958>] __vfs_read+0x28/0xe0
[<ffffffff81232393>] vfs_read+0x83/0x130
And this is indeed unkillable. So use mutex_lock_interruptible
instead of mutex_lock in rng_dev_read and exit immediatelly when
interrupted. And possibly return already read data, if any (as POSIX
allows).
v2: use ERESTARTSYS instead of EINTR
Signed-off-by: Jiri Slaby <jslaby(a)suse.cz>
Cc: Matt Mackall <mpm(a)selenic.com>
Cc: Herbert Xu <herbert(a)gondor.apana.org.au>
Cc: <linux-crypto(a)vger.kernel.org>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/char/hw_random/core.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -238,7 +238,10 @@ static ssize_t rng_dev_read(struct file
goto out;
}
- mutex_lock(&reading_mutex);
+ if (mutex_lock_interruptible(&reading_mutex)) {
+ err = -ERESTARTSYS;
+ goto out_put;
+ }
if (!data_avail) {
bytes_read = rng_get_data(rng, rng_buffer,
rng_buffer_size(),
@@ -288,6 +291,7 @@ out:
out_unlock_reading:
mutex_unlock(&reading_mutex);
+out_put:
put_rng(rng);
goto out;
}
Patches currently in stable-queue which might be from jslaby(a)suse.cz are
queue-4.4/hwrng-core-sleep-interruptible-in-read.patch
This is a note to let you know that I've just added the patch titled
cx82310_eth: use skb_cow_head() to deal with cloned skbs
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:
cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.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 a9e840a2081ed28c2b7caa6a9a0041c950b3c37d Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet(a)google.com>
Date: Wed, 19 Apr 2017 09:59:22 -0700
Subject: cx82310_eth: use skb_cow_head() to deal with cloned skbs
From: Eric Dumazet <edumazet(a)google.com>
commit a9e840a2081ed28c2b7caa6a9a0041c950b3c37d upstream.
We need to ensure there is enough headroom to push extra header,
but we also need to check if we are allowed to change headers.
skb_cow_head() is the proper helper to deal with this.
Fixes: cc28a20e77b2 ("introduce cx82310_eth: Conexant CX82310-based ADSL router USB ethernet driver")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Cc: James Hughes <james.hughes(a)raspberrypi.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/usb/cx82310_eth.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
--- a/drivers/net/usb/cx82310_eth.c
+++ b/drivers/net/usb/cx82310_eth.c
@@ -293,12 +293,9 @@ static struct sk_buff *cx82310_tx_fixup(
{
int len = skb->len;
- if (skb_headroom(skb) < 2) {
- struct sk_buff *skb2 = skb_copy_expand(skb, 2, 0, flags);
+ if (skb_cow_head(skb, 2)) {
dev_kfree_skb_any(skb);
- skb = skb2;
- if (!skb)
- return NULL;
+ return NULL;
}
skb_push(skb, 2);
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.4/lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.4/cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.4/sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.4/smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch
This is a note to let you know that I've just added the patch titled
zswap: don't param_set_charp while holding spinlock
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:
zswap-don-t-param_set_charp-while-holding-spinlock.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 fd5bb66cd934987e49557455b6497fc006521940 Mon Sep 17 00:00:00 2001
From: Dan Streetman <ddstreet(a)ieee.org>
Date: Mon, 27 Feb 2017 14:26:53 -0800
Subject: zswap: don't param_set_charp while holding spinlock
From: Dan Streetman <ddstreet(a)ieee.org>
commit fd5bb66cd934987e49557455b6497fc006521940 upstream.
Change the zpool/compressor param callback function to release the
zswap_pools_lock spinlock before calling param_set_charp, since that
function may sleep when it calls kmalloc with GFP_KERNEL.
While this problem has existed for a while, I wasn't able to trigger it
using a tight loop changing either/both the zpool and compressor params; I
think it's very unlikely to be an issue on the stable kernels, especially
since most zswap users will change the compressor and/or zpool from sysfs
only one time each boot - or zero times, if they add the params to the
kernel boot.
Fixes: c99b42c3529e ("zswap: use charp for zswap param strings")
Link: http://lkml.kernel.org/r/20170126155821.4545-1-ddstreet@ieee.org
Signed-off-by: Dan Streetman <dan.streetman(a)canonical.com>
Reported-by: Sergey Senozhatsky <sergey.senozhatsky.work(a)gmail.com>
Cc: Michal Hocko <mhocko(a)kernel.org>
Cc: Minchan Kim <minchan(a)kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
mm/zswap.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -752,18 +752,22 @@ static int __zswap_param_set(const char
pool = zswap_pool_find_get(type, compressor);
if (pool) {
zswap_pool_debug("using existing", pool);
+ WARN_ON(pool == zswap_pool_current());
list_del_rcu(&pool->list);
- } else {
- spin_unlock(&zswap_pools_lock);
- pool = zswap_pool_create(type, compressor);
- spin_lock(&zswap_pools_lock);
}
+ spin_unlock(&zswap_pools_lock);
+
+ if (!pool)
+ pool = zswap_pool_create(type, compressor);
+
if (pool)
ret = param_set_charp(s, kp);
else
ret = -EINVAL;
+ spin_lock(&zswap_pools_lock);
+
if (!ret) {
put_pool = zswap_pool_current();
list_add_rcu(&pool->list, &zswap_pools);
Patches currently in stable-queue which might be from ddstreet(a)ieee.org are
queue-4.9/zswap-don-t-param_set_charp-while-holding-spinlock.patch
This is a note to let you know that I've just added the patch titled
mm/zswap: use workqueue to destroy 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:
mm-zswap-use-workqueue-to-destroy-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 200867af4dedfe7cb707f96773684de1d1fd21e6 Mon Sep 17 00:00:00 2001
From: Dan Streetman <ddstreet(a)ieee.org>
Date: Fri, 20 May 2016 16:59:54 -0700
Subject: mm/zswap: use workqueue to destroy pool
From: Dan Streetman <ddstreet(a)ieee.org>
commit 200867af4dedfe7cb707f96773684de1d1fd21e6 upstream.
Add a work_struct to struct zswap_pool, and change __zswap_pool_empty to
use the workqueue instead of using call_rcu().
When zswap destroys a pool no longer in use, it uses call_rcu() to
perform the destruction/freeing. Since that executes in softirq
context, it must not sleep. However, actually destroying the pool
involves freeing the per-cpu compressors (which requires locking the
cpu_add_remove_lock mutex) and freeing the zpool, for which the
implementation may sleep (e.g. zsmalloc calls kmem_cache_destroy, which
locks the slab_mutex). So if either mutex is currently taken, or any
other part of the compressor or zpool implementation sleeps, it will
result in a BUG().
It's not easy to reproduce this when changing zswap's params normally.
In testing with a loaded system, this does not fail:
$ cd /sys/module/zswap/parameters
$ echo lz4 > compressor ; echo zsmalloc > zpool
nor does this:
$ while true ; do
> echo lzo > compressor ; echo zbud > zpool
> sleep 1
> echo lz4 > compressor ; echo zsmalloc > zpool
> sleep 1
> done
although it's still possible either of those might fail, depending on
whether anything else besides zswap has locked the mutexes.
However, changing a parameter with no delay immediately causes the
schedule while atomic BUG:
$ while true ; do
> echo lzo > compressor ; echo lz4 > compressor
> done
This is essentially the same as Yu Zhao's proposed patch to zsmalloc,
but moved to zswap, to cover compressor and zpool freeing.
Fixes: f1c54846ee45 ("zswap: dynamic pool creation")
Signed-off-by: Dan Streetman <ddstreet(a)ieee.org>
Reported-by: Yu Zhao <yuzhao(a)google.com>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
Cc: Minchan Kim <minchan(a)kernel.org>
Cc: Dan Streetman <dan.streetman(a)canonical.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
mm/zswap.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -123,7 +123,7 @@ struct zswap_pool {
struct crypto_comp * __percpu *tfm;
struct kref kref;
struct list_head list;
- struct rcu_head rcu_head;
+ struct work_struct work;
struct notifier_block notifier;
char tfm_name[CRYPTO_MAX_ALG_NAME];
};
@@ -667,9 +667,11 @@ static int __must_check zswap_pool_get(s
return kref_get_unless_zero(&pool->kref);
}
-static void __zswap_pool_release(struct rcu_head *head)
+static void __zswap_pool_release(struct work_struct *work)
{
- struct zswap_pool *pool = container_of(head, typeof(*pool), rcu_head);
+ struct zswap_pool *pool = container_of(work, typeof(*pool), work);
+
+ synchronize_rcu();
/* nobody should have been able to get a kref... */
WARN_ON(kref_get_unless_zero(&pool->kref));
@@ -689,7 +691,9 @@ static void __zswap_pool_empty(struct kr
WARN_ON(pool == zswap_pool_current());
list_del_rcu(&pool->list);
- call_rcu(&pool->rcu_head, __zswap_pool_release);
+
+ INIT_WORK(&pool->work, __zswap_pool_release);
+ schedule_work(&pool->work);
spin_unlock(&zswap_pools_lock);
}
Patches currently in stable-queue which might be from ddstreet(a)ieee.org are
queue-4.4/mm-zswap-use-workqueue-to-destroy-pool.patch
queue-4.4/zswap-don-t-param_set_charp-while-holding-spinlock.patch
This is a note to let you know that I've just added the patch titled
zswap: don't param_set_charp while holding spinlock
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:
zswap-don-t-param_set_charp-while-holding-spinlock.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 fd5bb66cd934987e49557455b6497fc006521940 Mon Sep 17 00:00:00 2001
From: Dan Streetman <ddstreet(a)ieee.org>
Date: Mon, 27 Feb 2017 14:26:53 -0800
Subject: zswap: don't param_set_charp while holding spinlock
From: Dan Streetman <ddstreet(a)ieee.org>
commit fd5bb66cd934987e49557455b6497fc006521940 upstream.
Change the zpool/compressor param callback function to release the
zswap_pools_lock spinlock before calling param_set_charp, since that
function may sleep when it calls kmalloc with GFP_KERNEL.
While this problem has existed for a while, I wasn't able to trigger it
using a tight loop changing either/both the zpool and compressor params; I
think it's very unlikely to be an issue on the stable kernels, especially
since most zswap users will change the compressor and/or zpool from sysfs
only one time each boot - or zero times, if they add the params to the
kernel boot.
Fixes: c99b42c3529e ("zswap: use charp for zswap param strings")
Link: http://lkml.kernel.org/r/20170126155821.4545-1-ddstreet@ieee.org
Signed-off-by: Dan Streetman <dan.streetman(a)canonical.com>
Reported-by: Sergey Senozhatsky <sergey.senozhatsky.work(a)gmail.com>
Cc: Michal Hocko <mhocko(a)kernel.org>
Cc: Minchan Kim <minchan(a)kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
mm/zswap.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -752,18 +752,22 @@ static int __zswap_param_set(const char
pool = zswap_pool_find_get(type, compressor);
if (pool) {
zswap_pool_debug("using existing", pool);
+ WARN_ON(pool == zswap_pool_current());
list_del_rcu(&pool->list);
- } else {
- spin_unlock(&zswap_pools_lock);
- pool = zswap_pool_create(type, compressor);
- spin_lock(&zswap_pools_lock);
}
+ spin_unlock(&zswap_pools_lock);
+
+ if (!pool)
+ pool = zswap_pool_create(type, compressor);
+
if (pool)
ret = param_set_charp(s, kp);
else
ret = -EINVAL;
+ spin_lock(&zswap_pools_lock);
+
if (!ret) {
put_pool = zswap_pool_current();
list_add_rcu(&pool->list, &zswap_pools);
Patches currently in stable-queue which might be from ddstreet(a)ieee.org are
queue-4.4/mm-zswap-use-workqueue-to-destroy-pool.patch
queue-4.4/zswap-don-t-param_set_charp-while-holding-spinlock.patch
This is a note to let you know that I've just added the patch titled
mm/page-writeback: fix dirty_ratelimit calculation
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-page-writeback-fix-dirty_ratelimit-calculation.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 d59b1087a98e402ed9a7cc577f4da435f9a555f5 Mon Sep 17 00:00:00 2001
From: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Date: Tue, 15 Mar 2016 14:55:27 -0700
Subject: mm/page-writeback: fix dirty_ratelimit calculation
From: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
commit d59b1087a98e402ed9a7cc577f4da435f9a555f5 upstream.
Calculation of dirty_ratelimit sometimes is not correct. E.g. initial
values of dirty_ratelimit == INIT_BW and step == 0, lead to the
following result:
UBSAN: Undefined behaviour in ../mm/page-writeback.c:1286:7
shift exponent 25600 is too large for 64-bit type 'long unsigned int'
The fix is straightforward - make step 0 if the shift exponent is too
big.
Signed-off-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Cc: Wu Fengguang <fengguang.wu(a)intel.com>
Cc: Tejun Heo <tj(a)kernel.org>
Cc: Andy Shevchenko <andy.shevchenko(a)gmail.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Mel Gorman <mgorman(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
mm/page-writeback.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -1162,6 +1162,7 @@ static void wb_update_dirty_ratelimit(st
unsigned long balanced_dirty_ratelimit;
unsigned long step;
unsigned long x;
+ unsigned long shift;
/*
* The dirty rate will match the writeout rate in long term, except
@@ -1286,11 +1287,11 @@ static void wb_update_dirty_ratelimit(st
* rate itself is constantly fluctuating. So decrease the track speed
* when it gets close to the target. Helps eliminate pointless tremors.
*/
- step >>= dirty_ratelimit / (2 * step + 1);
- /*
- * Limit the tracking speed to avoid overshooting.
- */
- step = (step + 7) / 8;
+ shift = dirty_ratelimit / (2 * step + 1);
+ if (shift < BITS_PER_LONG)
+ step = DIV_ROUND_UP(step >> shift, 8);
+ else
+ step = 0;
if (dirty_ratelimit < balanced_dirty_ratelimit)
dirty_ratelimit += step;
Patches currently in stable-queue which might be from aryabinin(a)virtuozzo.com are
queue-4.4/net-mac80211-debugfs.c-prevent-build-failure-with-config_ubsan-y.patch
queue-4.4/mm-page-writeback-fix-dirty_ratelimit-calculation.patch
This is a note to let you know that I've just added the patch titled
mm/compaction: pass only pageblock aligned range to pageblock_pfn_to_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:
mm-compaction-pass-only-pageblock-aligned-range-to-pageblock_pfn_to_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 e1409c325fdc1fef7b3d8025c51892355f065d15 Mon Sep 17 00:00:00 2001
From: Joonsoo Kim <iamjoonsoo.kim(a)lge.com>
Date: Tue, 15 Mar 2016 14:57:48 -0700
Subject: mm/compaction: pass only pageblock aligned range to pageblock_pfn_to_page
From: Joonsoo Kim <iamjoonsoo.kim(a)lge.com>
commit e1409c325fdc1fef7b3d8025c51892355f065d15 upstream.
pageblock_pfn_to_page() is used to check there is valid pfn and all
pages in the pageblock is in a single zone. If there is a hole in the
pageblock, passing arbitrary position to pageblock_pfn_to_page() could
cause to skip whole pageblock scanning, instead of just skipping the
hole page. For deterministic behaviour, it's better to always pass
pageblock aligned range to pageblock_pfn_to_page(). It will also help
further optimization on pageblock_pfn_to_page() in the following patch.
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim(a)lge.com>
Cc: Aaron Lu <aaron.lu(a)intel.com>
Cc: David Rientjes <rientjes(a)google.com>
Cc: Mel Gorman <mgorman(a)suse.de>
Cc: Rik van Riel <riel(a)redhat.com>
Acked-by: Vlastimil Babka <vbabka(a)suse.cz>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Mel Gorman <mgorman(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
mm/compaction.c | 41 ++++++++++++++++++++++++++++++-----------
1 file changed, 30 insertions(+), 11 deletions(-)
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -553,13 +553,17 @@ unsigned long
isolate_freepages_range(struct compact_control *cc,
unsigned long start_pfn, unsigned long end_pfn)
{
- unsigned long isolated, pfn, block_end_pfn;
+ unsigned long isolated, pfn, block_start_pfn, block_end_pfn;
LIST_HEAD(freelist);
pfn = start_pfn;
+ block_start_pfn = pfn & ~(pageblock_nr_pages - 1);
+ if (block_start_pfn < cc->zone->zone_start_pfn)
+ block_start_pfn = cc->zone->zone_start_pfn;
block_end_pfn = ALIGN(pfn + 1, pageblock_nr_pages);
for (; pfn < end_pfn; pfn += isolated,
+ block_start_pfn = block_end_pfn,
block_end_pfn += pageblock_nr_pages) {
/* Protect pfn from changing by isolate_freepages_block */
unsigned long isolate_start_pfn = pfn;
@@ -572,11 +576,13 @@ isolate_freepages_range(struct compact_c
* scanning range to right one.
*/
if (pfn >= block_end_pfn) {
+ block_start_pfn = pfn & ~(pageblock_nr_pages - 1);
block_end_pfn = ALIGN(pfn + 1, pageblock_nr_pages);
block_end_pfn = min(block_end_pfn, end_pfn);
}
- if (!pageblock_pfn_to_page(pfn, block_end_pfn, cc->zone))
+ if (!pageblock_pfn_to_page(block_start_pfn,
+ block_end_pfn, cc->zone))
break;
isolated = isolate_freepages_block(cc, &isolate_start_pfn,
@@ -862,18 +868,23 @@ unsigned long
isolate_migratepages_range(struct compact_control *cc, unsigned long start_pfn,
unsigned long end_pfn)
{
- unsigned long pfn, block_end_pfn;
+ unsigned long pfn, block_start_pfn, block_end_pfn;
/* Scan block by block. First and last block may be incomplete */
pfn = start_pfn;
+ block_start_pfn = pfn & ~(pageblock_nr_pages - 1);
+ if (block_start_pfn < cc->zone->zone_start_pfn)
+ block_start_pfn = cc->zone->zone_start_pfn;
block_end_pfn = ALIGN(pfn + 1, pageblock_nr_pages);
for (; pfn < end_pfn; pfn = block_end_pfn,
+ block_start_pfn = block_end_pfn,
block_end_pfn += pageblock_nr_pages) {
block_end_pfn = min(block_end_pfn, end_pfn);
- if (!pageblock_pfn_to_page(pfn, block_end_pfn, cc->zone))
+ if (!pageblock_pfn_to_page(block_start_pfn,
+ block_end_pfn, cc->zone))
continue;
pfn = isolate_migratepages_block(cc, pfn, block_end_pfn,
@@ -1091,7 +1102,9 @@ int sysctl_compact_unevictable_allowed _
static isolate_migrate_t isolate_migratepages(struct zone *zone,
struct compact_control *cc)
{
- unsigned long low_pfn, end_pfn;
+ unsigned long block_start_pfn;
+ unsigned long block_end_pfn;
+ unsigned long low_pfn;
unsigned long isolate_start_pfn;
struct page *page;
const isolate_mode_t isolate_mode =
@@ -1103,16 +1116,21 @@ static isolate_migrate_t isolate_migrate
* initialized by compact_zone()
*/
low_pfn = cc->migrate_pfn;
+ block_start_pfn = cc->migrate_pfn & ~(pageblock_nr_pages - 1);
+ if (block_start_pfn < zone->zone_start_pfn)
+ block_start_pfn = zone->zone_start_pfn;
/* Only scan within a pageblock boundary */
- end_pfn = ALIGN(low_pfn + 1, pageblock_nr_pages);
+ block_end_pfn = ALIGN(low_pfn + 1, pageblock_nr_pages);
/*
* Iterate over whole pageblocks until we find the first suitable.
* Do not cross the free scanner.
*/
- for (; end_pfn <= cc->free_pfn;
- low_pfn = end_pfn, end_pfn += pageblock_nr_pages) {
+ for (; block_end_pfn <= cc->free_pfn;
+ low_pfn = block_end_pfn,
+ block_start_pfn = block_end_pfn,
+ block_end_pfn += pageblock_nr_pages) {
/*
* This can potentially iterate a massively long zone with
@@ -1123,7 +1141,8 @@ static isolate_migrate_t isolate_migrate
&& compact_should_abort(cc))
break;
- page = pageblock_pfn_to_page(low_pfn, end_pfn, zone);
+ page = pageblock_pfn_to_page(block_start_pfn, block_end_pfn,
+ zone);
if (!page)
continue;
@@ -1142,8 +1161,8 @@ static isolate_migrate_t isolate_migrate
/* Perform the isolation */
isolate_start_pfn = low_pfn;
- low_pfn = isolate_migratepages_block(cc, low_pfn, end_pfn,
- isolate_mode);
+ low_pfn = isolate_migratepages_block(cc, low_pfn,
+ block_end_pfn, isolate_mode);
if (!low_pfn || cc->contended) {
acct_isolated(zone, cc);
Patches currently in stable-queue which might be from iamjoonsoo.kim(a)lge.com are
queue-4.4/mm-compaction-pass-only-pageblock-aligned-range-to-pageblock_pfn_to_page.patch
queue-4.4/mm-compaction-fix-invalid-free_pfn-and-compact_cached_free_pfn.patch
This is a note to let you know that I've just added the patch titled
locks: don't check for race with close when setting OFD lock
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:
locks-don-t-check-for-race-with-close-when-setting-ofd-lock.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 0752ba807b04ccd69cb4bc8bbf829a80ee208a3c Mon Sep 17 00:00:00 2001
From: Jeff Layton <jeff.layton(a)primarydata.com>
Date: Fri, 8 Jan 2016 07:30:43 -0500
Subject: locks: don't check for race with close when setting OFD lock
From: Jeff Layton <jeff.layton(a)primarydata.com>
commit 0752ba807b04ccd69cb4bc8bbf829a80ee208a3c upstream.
We don't clean out OFD locks on close(), so there's no need to check
for a race with them here. They'll get cleaned out at the same time
that flock locks are.
Signed-off-by: Jeff Layton <jeff.layton(a)primarydata.com>
Acked-by: "J. Bruce Fields" <bfields(a)fieldses.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Mel Gorman <mgorman(a)suse.de>
---
fs/locks.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -2220,10 +2220,12 @@ int fcntl_setlk(unsigned int fd, struct
error = do_lock_file_wait(filp, cmd, file_lock);
/*
- * Attempt to detect a close/fcntl race and recover by
- * releasing the lock that was just acquired.
+ * Attempt to detect a close/fcntl race and recover by releasing the
+ * lock that was just acquired. There is no need to do that when we're
+ * unlocking though, or for OFD locks.
*/
- if (!error && file_lock->fl_type != F_UNLCK) {
+ if (!error && file_lock->fl_type != F_UNLCK &&
+ !(file_lock->fl_flags & FL_OFDLCK)) {
/*
* We need that spin_lock here - it prevents reordering between
* update of i_flctx->flc_posix and check for it done in
@@ -2362,10 +2364,12 @@ int fcntl_setlk64(unsigned int fd, struc
error = do_lock_file_wait(filp, cmd, file_lock);
/*
- * Attempt to detect a close/fcntl race and recover by
- * releasing the lock that was just acquired.
+ * Attempt to detect a close/fcntl race and recover by releasing the
+ * lock that was just acquired. There is no need to do that when we're
+ * unlocking though, or for OFD locks.
*/
- if (!error && file_lock->fl_type != F_UNLCK) {
+ if (!error && file_lock->fl_type != F_UNLCK &&
+ !(file_lock->fl_flags & FL_OFDLCK)) {
/*
* We need that spin_lock here - it prevents reordering between
* update of i_flctx->flc_posix and check for it done in
Patches currently in stable-queue which might be from jeff.layton(a)primarydata.com are
queue-4.4/locks-don-t-check-for-race-with-close-when-setting-ofd-lock.patch
This is a note to let you know that I've just added the patch titled
mm/compaction: fix invalid free_pfn and compact_cached_free_pfn
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-compaction-fix-invalid-free_pfn-and-compact_cached_free_pfn.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 623446e4dc45b37740268165107cc63abb3022f0 Mon Sep 17 00:00:00 2001
From: Joonsoo Kim <iamjoonsoo.kim(a)lge.com>
Date: Tue, 15 Mar 2016 14:57:45 -0700
Subject: mm/compaction: fix invalid free_pfn and compact_cached_free_pfn
From: Joonsoo Kim <iamjoonsoo.kim(a)lge.com>
commit 623446e4dc45b37740268165107cc63abb3022f0 upstream.
free_pfn and compact_cached_free_pfn are the pointer that remember
restart position of freepage scanner. When they are reset or invalid,
we set them to zone_end_pfn because freepage scanner works in reverse
direction. But, because zone range is defined as [zone_start_pfn,
zone_end_pfn), zone_end_pfn is invalid to access. Therefore, we should
not store it to free_pfn and compact_cached_free_pfn. Instead, we need
to store zone_end_pfn - 1 to them. There is one more thing we should
consider. Freepage scanner scan reversely by pageblock unit. If
free_pfn and compact_cached_free_pfn are set to middle of pageblock, it
regards that sitiation as that it already scans front part of pageblock
so we lose opportunity to scan there. To fix-up, this patch do
round_down() to guarantee that reset position will be pageblock aligned.
Note that thanks to the current pageblock_pfn_to_page() implementation,
actual access to zone_end_pfn doesn't happen until now. But, following
patch will change pageblock_pfn_to_page() so this patch is needed from
now on.
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim(a)lge.com>
Acked-by: David Rientjes <rientjes(a)google.com>
Acked-by: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Aaron Lu <aaron.lu(a)intel.com>
Cc: Mel Gorman <mgorman(a)suse.de>
Cc: Rik van Riel <riel(a)redhat.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Mel Gorman <mgorman(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
mm/compaction.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -200,7 +200,8 @@ static void reset_cached_positions(struc
{
zone->compact_cached_migrate_pfn[0] = zone->zone_start_pfn;
zone->compact_cached_migrate_pfn[1] = zone->zone_start_pfn;
- zone->compact_cached_free_pfn = zone_end_pfn(zone);
+ zone->compact_cached_free_pfn =
+ round_down(zone_end_pfn(zone) - 1, pageblock_nr_pages);
}
/*
@@ -1358,11 +1359,11 @@ static int compact_zone(struct zone *zon
*/
cc->migrate_pfn = zone->compact_cached_migrate_pfn[sync];
cc->free_pfn = zone->compact_cached_free_pfn;
- if (cc->free_pfn < start_pfn || cc->free_pfn > end_pfn) {
- cc->free_pfn = end_pfn & ~(pageblock_nr_pages-1);
+ if (cc->free_pfn < start_pfn || cc->free_pfn >= end_pfn) {
+ cc->free_pfn = round_down(end_pfn - 1, pageblock_nr_pages);
zone->compact_cached_free_pfn = cc->free_pfn;
}
- if (cc->migrate_pfn < start_pfn || cc->migrate_pfn > end_pfn) {
+ if (cc->migrate_pfn < start_pfn || cc->migrate_pfn >= end_pfn) {
cc->migrate_pfn = start_pfn;
zone->compact_cached_migrate_pfn[0] = cc->migrate_pfn;
zone->compact_cached_migrate_pfn[1] = cc->migrate_pfn;
Patches currently in stable-queue which might be from iamjoonsoo.kim(a)lge.com are
queue-4.4/mm-compaction-pass-only-pageblock-aligned-range-to-pageblock_pfn_to_page.patch
queue-4.4/mm-compaction-fix-invalid-free_pfn-and-compact_cached_free_pfn.patch
This is a note to let you know that I've just added the patch titled
locking/mutex: Allow next waiter lockless wakeup
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:
locking-mutex-allow-next-waiter-lockless-wakeup.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 1329ce6fbbe4536592dfcfc8d64d61bfeb598fe6 Mon Sep 17 00:00:00 2001
From: Davidlohr Bueso <dave(a)stgolabs.net>
Date: Sun, 24 Jan 2016 18:23:43 -0800
Subject: locking/mutex: Allow next waiter lockless wakeup
From: Davidlohr Bueso <dave(a)stgolabs.net>
commit 1329ce6fbbe4536592dfcfc8d64d61bfeb598fe6 upstream.
Make use of wake-queues and enable the wakeup to occur after releasing the
wait_lock. This is similar to what we do with rtmutex top waiter,
slightly shortening the critical region and allow other waiters to
acquire the wait_lock sooner. In low contention cases it can also help
the recently woken waiter to find the wait_lock available (fastpath)
when it continues execution.
Reviewed-by: Waiman Long <Waiman.Long(a)hpe.com>
Signed-off-by: Davidlohr Bueso <dbueso(a)suse.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Ding Tianhong <dingtianhong(a)huawei.com>
Cc: Jason Low <jason.low2(a)hp.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
Cc: Paul E. McKenney <paulmck(a)us.ibm.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Tim Chen <tim.c.chen(a)linux.intel.com>
Cc: Waiman Long <waiman.long(a)hpe.com>
Cc: Will Deacon <Will.Deacon(a)arm.com>
Link: http://lkml.kernel.org/r/20160125022343.GA3322@linux-uzut.site
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/locking/mutex.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -719,6 +719,7 @@ static inline void
__mutex_unlock_common_slowpath(struct mutex *lock, int nested)
{
unsigned long flags;
+ WAKE_Q(wake_q);
/*
* As a performance measurement, release the lock before doing other
@@ -746,11 +747,11 @@ __mutex_unlock_common_slowpath(struct mu
struct mutex_waiter, list);
debug_mutex_wake_waiter(lock, waiter);
-
- wake_up_process(waiter->task);
+ wake_q_add(&wake_q, waiter->task);
}
spin_unlock_mutex(&lock->wait_lock, flags);
+ wake_up_q(&wake_q);
}
/*
Patches currently in stable-queue which might be from dave(a)stgolabs.net are
queue-4.4/locking-mutex-allow-next-waiter-lockless-wakeup.patch
queue-4.4/futex-replace-barrier-in-unqueue_me-with-read_once.patch
This is a note to let you know that I've just added the patch titled
futex: Replace barrier() in unqueue_me() with READ_ONCE()
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:
futex-replace-barrier-in-unqueue_me-with-read_once.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 29b75eb2d56a714190a93d7be4525e617591077a Mon Sep 17 00:00:00 2001
From: Jianyu Zhan <nasa4836(a)gmail.com>
Date: Mon, 7 Mar 2016 09:32:24 +0800
Subject: futex: Replace barrier() in unqueue_me() with READ_ONCE()
From: Jianyu Zhan <nasa4836(a)gmail.com>
commit 29b75eb2d56a714190a93d7be4525e617591077a upstream.
Commit e91467ecd1ef ("bug in futex unqueue_me") introduced a barrier() in
unqueue_me() to prevent the compiler from rereading the lock pointer which
might change after a check for NULL.
Replace the barrier() with a READ_ONCE() for the following reasons:
1) READ_ONCE() is a weaker form of barrier() that affects only the specific
load operation, while barrier() is a general compiler level memory barrier.
READ_ONCE() was not available at the time when the barrier was added.
2) Aside of that READ_ONCE() is descriptive and self explainatory while a
barrier without comment is not clear to the casual reader.
No functional change.
[ tglx: Massaged changelog ]
Signed-off-by: Jianyu Zhan <nasa4836(a)gmail.com>
Acked-by: Christian Borntraeger <borntraeger(a)de.ibm.com>
Acked-by: Darren Hart <dvhart(a)linux.intel.com>
Cc: dave(a)stgolabs.net
Cc: peterz(a)infradead.org
Cc: linux(a)rasmusvillemoes.dk
Cc: akpm(a)linux-foundation.org
Cc: fengguang.wu(a)intel.com
Cc: bigeasy(a)linutronix.de
Link: http://lkml.kernel.org/r/1457314344-5685-1-git-send-email-nasa4836@gmail.com
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Davidlohr Bueso <dbueso(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/futex.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1939,8 +1939,12 @@ static int unqueue_me(struct futex_q *q)
/* In the common case we don't take the spinlock, which is nice. */
retry:
- lock_ptr = q->lock_ptr;
- barrier();
+ /*
+ * q->lock_ptr can change between this read and the following spin_lock.
+ * Use READ_ONCE to forbid the compiler from reloading q->lock_ptr and
+ * optimizing lock_ptr out of the logic below.
+ */
+ lock_ptr = READ_ONCE(q->lock_ptr);
if (lock_ptr != NULL) {
spin_lock(lock_ptr);
/*
Patches currently in stable-queue which might be from nasa4836(a)gmail.com are
queue-4.4/futex-replace-barrier-in-unqueue_me-with-read_once.patch
CFL was missing from intel_early_ids[]. The PCI ID needs to be there to
allow the memory region to be stolen, otherwise we could have RAM being
arbitrarily overwritten if for example we keep using the UEFI framebuffer,
depending on how BIOS has set up the e820 map.
Fixes: b056f8f3d6b9 ("drm/i915/cfl: Add Coffee Lake PCI IDs for S Skus.")
Signed-off-by: Lucas De Marchi <lucas.demarchi(a)intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa(a)intel.com>
Cc: Jani Nikula <jani.nikula(a)linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
Cc: David Airlie <airlied(a)linux.ie>
Cc: intel-gfx(a)lists.freedesktop.org
Cc: dri-devel(a)lists.freedesktop.org
Cc: Ingo Molnar <mingo(a)kernel.org>
Cc: H. Peter Anvin <hpa(a)zytor.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: x86(a)kernel.org
Cc: <stable(a)vger.kernel.org> # v4.13+ 0890540e21cf drm/i915: add GT number to intel_device_info
Cc: <stable(a)vger.kernel.org> # v4.13+ 41693fd52373 drm/i915/kbl: Change a KBL pci id to GT2 from GT1.5
Cc: <stable(a)vger.kernel.org> # v4.13+
Reviewed-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
---
v2: improve commit message, add Fixes tag and CC stable
arch/x86/kernel/early-quirks.c | 1 +
include/drm/i915_pciids.h | 6 ++++++
2 files changed, 7 insertions(+)
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 3cbb2c78a9df..bae0d32e327b 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -528,6 +528,7 @@ static const struct pci_device_id intel_early_ids[] __initconst = {
INTEL_SKL_IDS(&gen9_early_ops),
INTEL_BXT_IDS(&gen9_early_ops),
INTEL_KBL_IDS(&gen9_early_ops),
+ INTEL_CFL_IDS(&gen9_early_ops),
INTEL_GLK_IDS(&gen9_early_ops),
INTEL_CNL_IDS(&gen9_early_ops),
};
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 972a25633525..c65e4489006d 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -392,6 +392,12 @@
INTEL_VGA_DEVICE(0x3EA8, info), /* ULT GT3 */ \
INTEL_VGA_DEVICE(0x3EA5, info) /* ULT GT3 */
+#define INTEL_CFL_IDS(info) \
+ INTEL_CFL_S_GT1_IDS(info), \
+ INTEL_CFL_S_GT2_IDS(info), \
+ INTEL_CFL_H_GT2_IDS(info), \
+ INTEL_CFL_U_GT3_IDS(info)
+
/* CNL U 2+2 */
#define INTEL_CNL_U_GT2_IDS(info) \
INTEL_VGA_DEVICE(0x5A52, info), \
--
2.14.3
Quoting Hans:
If we return 1 from our post_reset handler, then our disconnect handler
will be called immediately afterwards. Since pre_reset blocks all scsi
requests our disconnect handler will then hang in the scsi_remove_host
call.
This is esp. bad because our disconnect handler hanging for ever also
stops the USB subsys from enumerating any new USB devices, causes commands
like lsusb to hang, etc.
In practice this happens when unplugging some uas devices because the hub
code may see the device as needing a warm-reset and calls usb_reset_device
before seeing the disconnect. In this case uas_configure_endpoints fails
with -ENODEV. We do not want to print an error for this, so this commit
also silences the shost_printk for -ENODEV.
ENDQUOTE
However, if we do that we better drop any unconditional execution
and report to the SCSI subsystem that we have undergone a reset
but we are not operational now.
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
Reported-by: Hans de Goede <hdegoede(a)redhat.com>
CC: stable(a)vger.kernel.org
---
drivers/usb/storage/uas.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 5d04c40ee40a..3b1b9695177a 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -1076,20 +1076,19 @@ static int uas_post_reset(struct usb_interface *intf)
return 0;
err = uas_configure_endpoints(devinfo);
- if (err) {
+ if (err && err != ENODEV)
shost_printk(KERN_ERR, shost,
"%s: alloc streams error %d after reset",
__func__, err);
- return 1;
- }
+ /* we must unblock the host in every case lest we deadlock */
spin_lock_irqsave(shost->host_lock, flags);
scsi_report_bus_reset(shost, 0);
spin_unlock_irqrestore(shost->host_lock, flags);
scsi_unblock_requests(shost);
- return 0;
+ return err ? 1 : 0;
}
static int uas_suspend(struct usb_interface *intf, pm_message_t message)
--
2.13.6
Quoting Hans:
If we return 1 from our post_reset handler, then our disconnect handler
will be called immediately afterwards. Since pre_reset blocks all scsi
requests our disconnect handler will then hang in the scsi_remove_host
call.
This is esp. bad because our disconnect handler hanging for ever also
stops the USB subsys from enumerating any new USB devices, causes commands
like lsusb to hang, etc.
In practice this happens when unplugging some uas devices because the hub
code may see the device as needing a warm-reset and calls usb_reset_device
before seeing the disconnect. In this case uas_configure_endpoints fails
with -ENODEV. We do not want to print an error for this, so this commit
also silences the shost_printk for -ENODEV.
ENDQUOTE
However, if we do that we better drop any unconditional execution
and report to the SCSI subsystem that we have undergone a reset
but we are not operational now.
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
Reported-by: Hans de Goede <hdegoede(a)redhat.com>
CC: stable(a)vger.kernel.org
---
Makefile | 2 +-
drivers/usb/storage/uas.c | 7 +++----
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index 7e02f951b284..5025bac05cdb 100644
--- a/Makefile
+++ b/Makefile
@@ -2,7 +2,7 @@
VERSION = 4
PATCHLEVEL = 15
SUBLEVEL = 0
-EXTRAVERSION = -rc4
+EXTRAVERSION = -rc4bs0108a
NAME = Fearless Coyote
# *DOCUMENTATION*
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 5d04c40ee40a..3b1b9695177a 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -1076,20 +1076,19 @@ static int uas_post_reset(struct usb_interface *intf)
return 0;
err = uas_configure_endpoints(devinfo);
- if (err) {
+ if (err && err != ENODEV)
shost_printk(KERN_ERR, shost,
"%s: alloc streams error %d after reset",
__func__, err);
- return 1;
- }
+ /* we must unblock the host in every case lest we deadlock */
spin_lock_irqsave(shost->host_lock, flags);
scsi_report_bus_reset(shost, 0);
spin_unlock_irqrestore(shost->host_lock, flags);
scsi_unblock_requests(shost);
- return 0;
+ return err ? 1 : 0;
}
static int uas_suspend(struct usb_interface *intf, pm_message_t message)
--
2.13.6
On 11/01/18 11:31, Felipe Balbi wrote:
>
> Hi,
>
> Roger Quadros <rogerq(a)ti.com> writes:
>>> Roger Quadros <rogerq(a)ti.com> writes:
>>>>>>> - ret = dwc3_core_soft_reset(dwc);
>>>>>>> + ret = dwc3_core_get_phy(dwc);
>>>>>>
>>>>>> we can get_phy in dwc3_core_init() as it will get called on resume().
>>>>>> This was the $subject of this patch.
>>>>>
>>>>> indeed. thanks :-)
>>>>>
>>>>
>>>> oops sorry. I meant we can't call dwc3_core_get_phy() in dwc3_core_init(). :P
>>>
>>> bit of a chicken-and-egg problem. We need to setup the PHY interface
>>> before getting the PHYs, but can't get PHY during resume. Maybe the best
>>> way here would be to check for the pointers being valid. Something like:
>>>
>>> if (!phy)
>>> get_phy();
>>>
>>
>> OK that should take care of not calling get_phy() on suspend.
>> However there is one more issue with the approach
>>
>>> @@ -754,15 +754,15 @@ static int dwc3_core_init(struct dwc3 *dwc)
>>> dwc->maximum_speed = USB_SPEED_HIGH;
>>> }
>>>
>>> - ret = dwc3_core_get_phy(dwc);
>>> + ret = dwc3_phy_setup(dwc);
>>> if (ret)
>>> goto err0;
>>
>> here we configure PHY related bits and register the ulpi interface.
>>
>>>
>>> - ret = dwc3_core_soft_reset(dwc);
>>> + ret = dwc3_core_get_phy(dwc);
>>> if (ret)
>>> goto err0;
>>>
>>
>> we got the PHYs. all OK here.
>>
>>> - ret = dwc3_phy_setup(dwc);
>>> + ret = dwc3_core_soft_reset(dwc);
>>> if (ret)
>>> goto err0;
>>
>> Now we do a soft reset. This means we loose the PHY configuration bits that we did
>> in dwc3_phy_setup. So we need to call dwc3_phy_setup again but not re-register the ulpi interface.
>> I can use a flag there so that dwc3_ulpi_init() is done only once.
>
> sounds like it's better to extract out a smaller function that just
> checks if we need ULPI bus and registers it, something akin to:
>
> @@ -482,6 +482,21 @@ static void dwc3_cache_hwparams(struct dwc3 *dwc)
> parms->hwparams8 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS8);
> }
>
> +static int dwc3_ulpi_init(struct dwc3 *dwc)
> +{
> + int intf;
> +
> + intf = DWC3_GHWPARAMS3_HSPHY_IFC(dwc->hwparams.hwparams3);
> +
> + if (intf == DWC3_GHWPARAMS3_HSPHY_IFC_ULPI ||
> + (intf == DWC3_GHWPARAMS3_HSPHY_IFC_UTMI_ULPI &&
> + dwc->hsphy_interface &&
> + !strncmp(dwc->hsphy_interface, "ulpi", 4)))
> + return dwc3_ulpi_init(dwc);
> +
> + return 0;
> +}
> +
> /**
> * dwc3_phy_setup - Configure USB PHY Interface of DWC3 Core
> * @dwc: Pointer to our controller context structure
> @@ -563,11 +578,6 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
> break;
> }
> /* FALLTHROUGH */
> - case DWC3_GHWPARAMS3_HSPHY_IFC_ULPI:
> - ret = dwc3_ulpi_init(dwc);
> - if (ret)
> - return ret;
> - /* FALLTHROUGH */
> default:
> break;
> }
>
> Then we just call that outside of any functions that get called during PM.
>
Right. Seems like we've covered everything. I'll send a patch in a while.
--
cheers,
-roger
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
+Heikki
On 11/01/18 10:25, Felipe Balbi wrote:
>
> Hi,
>
> Roger Quadros <rogerq(a)ti.com> writes:
>>>>> - ret = dwc3_core_soft_reset(dwc);
>>>>> + ret = dwc3_core_get_phy(dwc);
>>>>
>>>> we can get_phy in dwc3_core_init() as it will get called on resume().
>>>> This was the $subject of this patch.
>>>
>>> indeed. thanks :-)
>>>
>>
>> oops sorry. I meant we can't call dwc3_core_get_phy() in dwc3_core_init(). :P
>
> bit of a chicken-and-egg problem. We need to setup the PHY interface
> before getting the PHYs, but can't get PHY during resume. Maybe the best
> way here would be to check for the pointers being valid. Something like:
>
> if (!phy)
> get_phy();
>
OK that should take care of not calling get_phy() on suspend.
However there is one more issue with the approach
> @@ -754,15 +754,15 @@ static int dwc3_core_init(struct dwc3 *dwc)
> dwc->maximum_speed = USB_SPEED_HIGH;
> }
>
> - ret = dwc3_core_get_phy(dwc);
> + ret = dwc3_phy_setup(dwc);
> if (ret)
> goto err0;
here we configure PHY related bits and register the ulpi interface.
>
> - ret = dwc3_core_soft_reset(dwc);
> + ret = dwc3_core_get_phy(dwc);
> if (ret)
> goto err0;
>
we got the PHYs. all OK here.
> - ret = dwc3_phy_setup(dwc);
> + ret = dwc3_core_soft_reset(dwc);
> if (ret)
> goto err0;
Now we do a soft reset. This means we loose the PHY configuration bits that we did
in dwc3_phy_setup. So we need to call dwc3_phy_setup again but not re-register the ulpi interface.
I can use a flag there so that dwc3_ulpi_init() is done only once.
--
cheers,
-roger
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
This is a note to let you know that I've just added the patch titled
[PATCH] nvmem: add i.MX7 support to snvs-lpgpr
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:
nvmem-add-i.mx7-support-to-snvs-lpgpr.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 yurovsky(a)gmail.com Thu Jan 11 07:36:10 2018
From: Andrey Yurovsky <yurovsky(a)gmail.com>
Date: Wed, 10 Jan 2018 15:47:34 -0800
Subject: [PATCH] nvmem: add i.MX7 support to snvs-lpgpr
To: srinivas.kandagatla(a)linaro.org
Cc: Andrey Yurovsky <yurovsky(a)gmail.com>, o.rempel(a)pengutronix.de, gregkh(a)linuxfoundation.org
Message-ID: <20180110234734.26213-1-yurovsky(a)gmail.com>
The i.MX7 family has similar SNVS hardware so make the snvs-lpgpr
support it along with the i.MX6 family. The register interface is the
same except for the number and offset of the general purpose registers.
Signed-off-by: Andrey Yurovsky <yurovsky(a)gmail.com>
---
.../devicetree/bindings/nvmem/snvs-lpgpr.txt | 3 ++-
drivers/nvmem/Kconfig | 4 ++--
drivers/nvmem/snvs_lpgpr.c | 27 +++++++++++++++++-----
3 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
index 20bc49b49799..3cb170896658 100644
--- a/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
+++ b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
@@ -1,5 +1,5 @@
Device tree bindings for Low Power General Purpose Register found in i.MX6Q/D
-Secure Non-Volatile Storage.
+and i.MX7 Secure Non-Volatile Storage.
This DT node should be represented as a sub-node of a "syscon",
"simple-mfd" node.
@@ -8,6 +8,7 @@ Required properties:
- compatible: should be one of the fallowing variants:
"fsl,imx6q-snvs-lpgpr" for Freescale i.MX6Q/D/DL/S
"fsl,imx6ul-snvs-lpgpr" for Freescale i.MX6UL
+ "fsl,imx7d-snvs-lpgpr" for Freescale i.MX7D/S
Example:
snvs: snvs@020cc000 {
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index ff505af064ba..5f9bc787d634 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -167,10 +167,10 @@ config MESON_MX_EFUSE
config NVMEM_SNVS_LPGPR
tristate "Support for Low Power General Purpose Register"
- depends on SOC_IMX6 || COMPILE_TEST
+ depends on SOC_IMX6 || SOC_IMX7D || COMPILE_TEST
help
This is a driver for Low Power General Purpose Register (LPGPR) available on
- i.MX6 SoCs in Secure Non-Volatile Storage (SNVS) of this chip.
+ i.MX6 and i.MX7 SoCs in Secure Non-Volatile Storage (SNVS) of this chip.
This driver can also be built as a module. If so, the module
will be called nvmem-snvs-lpgpr.
diff --git a/drivers/nvmem/snvs_lpgpr.c b/drivers/nvmem/snvs_lpgpr.c
index e5c2a4a17f03..3ed617a16db0 100644
--- a/drivers/nvmem/snvs_lpgpr.c
+++ b/drivers/nvmem/snvs_lpgpr.c
@@ -14,15 +14,21 @@
#include <linux/regmap.h>
#define IMX6Q_SNVS_HPLR 0x00
-#define IMX6Q_GPR_SL BIT(5)
#define IMX6Q_SNVS_LPLR 0x34
-#define IMX6Q_GPR_HL BIT(5)
#define IMX6Q_SNVS_LPGPR 0x68
+#define IMX7D_SNVS_HPLR 0x00
+#define IMX7D_SNVS_LPLR 0x34
+#define IMX7D_SNVS_LPGPR 0x90
+
+#define IMX_GPR_SL BIT(5)
+#define IMX_GPR_HL BIT(5)
+
struct snvs_lpgpr_cfg {
int offset;
int offset_hplr;
int offset_lplr;
+ int size;
};
struct snvs_lpgpr_priv {
@@ -36,6 +42,14 @@ static const struct snvs_lpgpr_cfg snvs_lpgpr_cfg_imx6q = {
.offset = IMX6Q_SNVS_LPGPR,
.offset_hplr = IMX6Q_SNVS_HPLR,
.offset_lplr = IMX6Q_SNVS_LPLR,
+ .size = 4,
+};
+
+static const struct snvs_lpgpr_cfg snvs_lpgpr_cfg_imx7d = {
+ .offset = IMX7D_SNVS_LPGPR,
+ .offset_hplr = IMX7D_SNVS_HPLR,
+ .offset_lplr = IMX7D_SNVS_LPLR,
+ .size = 16,
};
static int snvs_lpgpr_write(void *context, unsigned int offset, void *val,
@@ -50,14 +64,14 @@ static int snvs_lpgpr_write(void *context, unsigned int offset, void *val,
if (ret < 0)
return ret;
- if (lock_reg & IMX6Q_GPR_SL)
+ if (lock_reg & IMX_GPR_SL)
return -EPERM;
ret = regmap_read(priv->regmap, dcfg->offset_lplr, &lock_reg);
if (ret < 0)
return ret;
- if (lock_reg & IMX6Q_GPR_HL)
+ if (lock_reg & IMX_GPR_HL)
return -EPERM;
return regmap_bulk_write(priv->regmap, dcfg->offset + offset, val,
@@ -112,7 +126,7 @@ static int snvs_lpgpr_probe(struct platform_device *pdev)
cfg->dev = dev;
cfg->stride = 4,
cfg->word_size = 4,
- cfg->size = 4,
+ cfg->size = dcfg->size,
cfg->owner = THIS_MODULE,
cfg->reg_read = snvs_lpgpr_read,
cfg->reg_write = snvs_lpgpr_write,
@@ -137,6 +151,7 @@ static const struct of_device_id snvs_lpgpr_dt_ids[] = {
{ .compatible = "fsl,imx6q-snvs-lpgpr", .data = &snvs_lpgpr_cfg_imx6q },
{ .compatible = "fsl,imx6ul-snvs-lpgpr",
.data = &snvs_lpgpr_cfg_imx6q },
+ { .compatible = "fsl,imx7d-snvs-lpgpr", .data = &snvs_lpgpr_cfg_imx7d },
{ },
};
MODULE_DEVICE_TABLE(of, snvs_lpgpr_dt_ids);
@@ -152,5 +167,5 @@ static struct platform_driver snvs_lpgpr_driver = {
module_platform_driver(snvs_lpgpr_driver);
MODULE_AUTHOR("Oleksij Rempel <o.rempel(a)pengutronix.de>");
-MODULE_DESCRIPTION("Low Power General Purpose Register in i.MX6 Secure Non-Volatile Storage");
+MODULE_DESCRIPTION("Low Power General Purpose Register in i.MX6 and i.MX7 Secure Non-Volatile Storage");
MODULE_LICENSE("GPL v2");
--
2.14.3
Patches currently in stable-queue which might be from yurovsky(a)gmail.com are
queue-4.4/nvmem-add-i.mx7-support-to-snvs-lpgpr.patch
This is a note to let you know that I've just added the patch titled
x86/acpi: Reduce code duplication in mp_override_legacy_irq()
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:
x86-acpi-reduce-code-duplication-in-mp_override_legacy_irq.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 4ee2ec1b122599f7b10c849fa7915cebb37b7edb Mon Sep 17 00:00:00 2001
From: Vikas C Sajjan <vikas.cha.sajjan(a)hpe.com>
Date: Thu, 16 Nov 2017 21:43:45 +0530
Subject: x86/acpi: Reduce code duplication in mp_override_legacy_irq()
From: Vikas C Sajjan <vikas.cha.sajjan(a)hpe.com>
commit 4ee2ec1b122599f7b10c849fa7915cebb37b7edb upstream.
The new function mp_register_ioapic_irq() is a subset of the code in
mp_override_legacy_irq().
Replace the code duplication by invoking mp_register_ioapic_irq() from
mp_override_legacy_irq().
Signed-off-by: Vikas C Sajjan <vikas.cha.sajjan(a)hpe.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Reviewed-by: Thomas Gleixner <tglx(a)linutronix.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Cc: linux-pm(a)vger.kernel.org
Cc: kkamagui(a)gmail.com
Cc: linux-acpi(a)vger.kernel.org
Link: https://lkml.kernel.org/r/1510848825-21965-3-git-send-email-vikas.cha.sajja…
Cc: Jean Delvare <jdelvare(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/acpi/boot.c | 27 +++++----------------------
1 file changed, 5 insertions(+), 22 deletions(-)
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -321,13 +321,12 @@ acpi_parse_lapic_nmi(struct acpi_subtabl
#ifdef CONFIG_X86_IO_APIC
#define MP_ISA_BUS 0
+static int __init mp_register_ioapic_irq(u8 bus_irq, u8 polarity,
+ u8 trigger, u32 gsi);
+
static void __init mp_override_legacy_irq(u8 bus_irq, u8 polarity, u8 trigger,
u32 gsi)
{
- int ioapic;
- int pin;
- struct mpc_intsrc mp_irq;
-
/*
* Check bus_irq boundary.
*/
@@ -337,14 +336,6 @@ static void __init mp_override_legacy_ir
}
/*
- * Convert 'gsi' to 'ioapic.pin'.
- */
- ioapic = mp_find_ioapic(gsi);
- if (ioapic < 0)
- return;
- pin = mp_find_ioapic_pin(ioapic, gsi);
-
- /*
* TBD: This check is for faulty timer entries, where the override
* erroneously sets the trigger to level, resulting in a HUGE
* increase of timer interrupts!
@@ -352,16 +343,8 @@ static void __init mp_override_legacy_ir
if ((bus_irq == 0) && (trigger == 3))
trigger = 1;
- mp_irq.type = MP_INTSRC;
- mp_irq.irqtype = mp_INT;
- mp_irq.irqflag = (trigger << 2) | polarity;
- mp_irq.srcbus = MP_ISA_BUS;
- mp_irq.srcbusirq = bus_irq; /* IRQ */
- mp_irq.dstapic = mpc_ioapic_id(ioapic); /* APIC ID */
- mp_irq.dstirq = pin; /* INTIN# */
-
- mp_save_irq(&mp_irq);
-
+ if (mp_register_ioapic_irq(bus_irq, polarity, trigger, gsi) < 0)
+ return;
/*
* Reset default identity mapping if gsi is also an legacy IRQ,
* otherwise there will be more than one entry with the same GSI
Patches currently in stable-queue which might be from vikas.cha.sajjan(a)hpe.com are
queue-4.4/x86-acpi-handle-sci-interrupts-above-legacy-space-gracefully.patch
queue-4.4/x86-acpi-reduce-code-duplication-in-mp_override_legacy_irq.patch
This is a note to let you know that I've just added the patch titled
x86/acpi: Reduce code duplication in mp_override_legacy_irq()
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-acpi-reduce-code-duplication-in-mp_override_legacy_irq.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 4ee2ec1b122599f7b10c849fa7915cebb37b7edb Mon Sep 17 00:00:00 2001
From: Vikas C Sajjan <vikas.cha.sajjan(a)hpe.com>
Date: Thu, 16 Nov 2017 21:43:45 +0530
Subject: x86/acpi: Reduce code duplication in mp_override_legacy_irq()
From: Vikas C Sajjan <vikas.cha.sajjan(a)hpe.com>
commit 4ee2ec1b122599f7b10c849fa7915cebb37b7edb upstream.
The new function mp_register_ioapic_irq() is a subset of the code in
mp_override_legacy_irq().
Replace the code duplication by invoking mp_register_ioapic_irq() from
mp_override_legacy_irq().
Signed-off-by: Vikas C Sajjan <vikas.cha.sajjan(a)hpe.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Reviewed-by: Thomas Gleixner <tglx(a)linutronix.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Cc: linux-pm(a)vger.kernel.org
Cc: kkamagui(a)gmail.com
Cc: linux-acpi(a)vger.kernel.org
Link: https://lkml.kernel.org/r/1510848825-21965-3-git-send-email-vikas.cha.sajja…
Cc: Jean Delvare <jdelvare(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/acpi/boot.c | 27 +++++----------------------
1 file changed, 5 insertions(+), 22 deletions(-)
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -342,13 +342,12 @@ acpi_parse_lapic_nmi(struct acpi_subtabl
#ifdef CONFIG_X86_IO_APIC
#define MP_ISA_BUS 0
+static int __init mp_register_ioapic_irq(u8 bus_irq, u8 polarity,
+ u8 trigger, u32 gsi);
+
static void __init mp_override_legacy_irq(u8 bus_irq, u8 polarity, u8 trigger,
u32 gsi)
{
- int ioapic;
- int pin;
- struct mpc_intsrc mp_irq;
-
/*
* Check bus_irq boundary.
*/
@@ -358,14 +357,6 @@ static void __init mp_override_legacy_ir
}
/*
- * Convert 'gsi' to 'ioapic.pin'.
- */
- ioapic = mp_find_ioapic(gsi);
- if (ioapic < 0)
- return;
- pin = mp_find_ioapic_pin(ioapic, gsi);
-
- /*
* TBD: This check is for faulty timer entries, where the override
* erroneously sets the trigger to level, resulting in a HUGE
* increase of timer interrupts!
@@ -373,16 +364,8 @@ static void __init mp_override_legacy_ir
if ((bus_irq == 0) && (trigger == 3))
trigger = 1;
- mp_irq.type = MP_INTSRC;
- mp_irq.irqtype = mp_INT;
- mp_irq.irqflag = (trigger << 2) | polarity;
- mp_irq.srcbus = MP_ISA_BUS;
- mp_irq.srcbusirq = bus_irq; /* IRQ */
- mp_irq.dstapic = mpc_ioapic_id(ioapic); /* APIC ID */
- mp_irq.dstirq = pin; /* INTIN# */
-
- mp_save_irq(&mp_irq);
-
+ if (mp_register_ioapic_irq(bus_irq, polarity, trigger, gsi) < 0)
+ return;
/*
* Reset default identity mapping if gsi is also an legacy IRQ,
* otherwise there will be more than one entry with the same GSI
Patches currently in stable-queue which might be from vikas.cha.sajjan(a)hpe.com are
queue-4.14/x86-acpi-handle-sci-interrupts-above-legacy-space-gracefully.patch
queue-4.14/x86-acpi-reduce-code-duplication-in-mp_override_legacy_irq.patch
This is a note to let you know that I've just added the patch titled
x86/acpi: Reduce code duplication in mp_override_legacy_irq()
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:
x86-acpi-reduce-code-duplication-in-mp_override_legacy_irq.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 4ee2ec1b122599f7b10c849fa7915cebb37b7edb Mon Sep 17 00:00:00 2001
From: Vikas C Sajjan <vikas.cha.sajjan(a)hpe.com>
Date: Thu, 16 Nov 2017 21:43:45 +0530
Subject: x86/acpi: Reduce code duplication in mp_override_legacy_irq()
From: Vikas C Sajjan <vikas.cha.sajjan(a)hpe.com>
commit 4ee2ec1b122599f7b10c849fa7915cebb37b7edb upstream.
The new function mp_register_ioapic_irq() is a subset of the code in
mp_override_legacy_irq().
Replace the code duplication by invoking mp_register_ioapic_irq() from
mp_override_legacy_irq().
Signed-off-by: Vikas C Sajjan <vikas.cha.sajjan(a)hpe.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Reviewed-by: Thomas Gleixner <tglx(a)linutronix.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Cc: linux-pm(a)vger.kernel.org
Cc: kkamagui(a)gmail.com
Cc: linux-acpi(a)vger.kernel.org
Link: https://lkml.kernel.org/r/1510848825-21965-3-git-send-email-vikas.cha.sajja…
Cc: Jean Delvare <jdelvare(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/acpi/boot.c | 27 +++++----------------------
1 file changed, 5 insertions(+), 22 deletions(-)
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -308,13 +308,12 @@ acpi_parse_lapic_nmi(struct acpi_subtabl
#ifdef CONFIG_X86_IO_APIC
#define MP_ISA_BUS 0
+static int __init mp_register_ioapic_irq(u8 bus_irq, u8 polarity,
+ u8 trigger, u32 gsi);
+
static void __init mp_override_legacy_irq(u8 bus_irq, u8 polarity, u8 trigger,
u32 gsi)
{
- int ioapic;
- int pin;
- struct mpc_intsrc mp_irq;
-
/*
* Check bus_irq boundary.
*/
@@ -324,14 +323,6 @@ static void __init mp_override_legacy_ir
}
/*
- * Convert 'gsi' to 'ioapic.pin'.
- */
- ioapic = mp_find_ioapic(gsi);
- if (ioapic < 0)
- return;
- pin = mp_find_ioapic_pin(ioapic, gsi);
-
- /*
* TBD: This check is for faulty timer entries, where the override
* erroneously sets the trigger to level, resulting in a HUGE
* increase of timer interrupts!
@@ -339,16 +330,8 @@ static void __init mp_override_legacy_ir
if ((bus_irq == 0) && (trigger == 3))
trigger = 1;
- mp_irq.type = MP_INTSRC;
- mp_irq.irqtype = mp_INT;
- mp_irq.irqflag = (trigger << 2) | polarity;
- mp_irq.srcbus = MP_ISA_BUS;
- mp_irq.srcbusirq = bus_irq; /* IRQ */
- mp_irq.dstapic = mpc_ioapic_id(ioapic); /* APIC ID */
- mp_irq.dstirq = pin; /* INTIN# */
-
- mp_save_irq(&mp_irq);
-
+ if (mp_register_ioapic_irq(bus_irq, polarity, trigger, gsi) < 0)
+ return;
/*
* Reset default identity mapping if gsi is also an legacy IRQ,
* otherwise there will be more than one entry with the same GSI
Patches currently in stable-queue which might be from vikas.cha.sajjan(a)hpe.com are
queue-3.18/x86-acpi-handle-sci-interrupts-above-legacy-space-gracefully.patch
queue-3.18/x86-acpi-reduce-code-duplication-in-mp_override_legacy_irq.patch
Hi all,
Commit dad5ab0db8de ("x86/acpi: Prevent out of bound access caused by
broken ACPI tables") was tagged for stable and merged in various stable
kernel trees (at least 3.2, 3.16, 3.18, 4.1, 4.4, 4.9 and 4.12.)
However it turns out that this commit introduced a regression on some
systems (in particular HPE Superdome 2, but possibly others.) The fix
for this breakage is:
commit 252714155f04c5d16989cb3aadb85fd1b5772f99
Author: Vikas C Sajjan
Date: Thu Nov 16 21:43:44 2017 +0530
x86/acpi: Handle SCI interrupts above legacy space gracefully
(and follow-up cleanup 4ee2ec1b1225 "x86/acpi: Reduce code duplication
in mp_override_legacy_irq()".) Unfortunately the fix-up patch was NOT
tagged for stable and also lacks a Fixes tag referring to the faulty
commit. As a consequence nobody realized they fix a regression, and this
regression is still present in all the aforementioned stable branches.
So I invite the maintainers of these stable kernel branches to backport
commits 252714155f04 and possibly 4ee2ec1b1225 to solve this issue.
Thanks,
--
Jean Delvare
SUSE L3 Support
This is a note to let you know that I've just added the patch titled
x86/acpi: Reduce code duplication in mp_override_legacy_irq()
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:
x86-acpi-reduce-code-duplication-in-mp_override_legacy_irq.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 4ee2ec1b122599f7b10c849fa7915cebb37b7edb Mon Sep 17 00:00:00 2001
From: Vikas C Sajjan <vikas.cha.sajjan(a)hpe.com>
Date: Thu, 16 Nov 2017 21:43:45 +0530
Subject: x86/acpi: Reduce code duplication in mp_override_legacy_irq()
From: Vikas C Sajjan <vikas.cha.sajjan(a)hpe.com>
commit 4ee2ec1b122599f7b10c849fa7915cebb37b7edb upstream.
The new function mp_register_ioapic_irq() is a subset of the code in
mp_override_legacy_irq().
Replace the code duplication by invoking mp_register_ioapic_irq() from
mp_override_legacy_irq().
Signed-off-by: Vikas C Sajjan <vikas.cha.sajjan(a)hpe.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Reviewed-by: Thomas Gleixner <tglx(a)linutronix.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Cc: linux-pm(a)vger.kernel.org
Cc: kkamagui(a)gmail.com
Cc: linux-acpi(a)vger.kernel.org
Link: https://lkml.kernel.org/r/1510848825-21965-3-git-send-email-vikas.cha.sajja…
Cc: Jean Delvare <jdelvare(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/acpi/boot.c | 27 +++++----------------------
1 file changed, 5 insertions(+), 22 deletions(-)
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -335,13 +335,12 @@ acpi_parse_lapic_nmi(struct acpi_subtabl
#ifdef CONFIG_X86_IO_APIC
#define MP_ISA_BUS 0
+static int __init mp_register_ioapic_irq(u8 bus_irq, u8 polarity,
+ u8 trigger, u32 gsi);
+
static void __init mp_override_legacy_irq(u8 bus_irq, u8 polarity, u8 trigger,
u32 gsi)
{
- int ioapic;
- int pin;
- struct mpc_intsrc mp_irq;
-
/*
* Check bus_irq boundary.
*/
@@ -351,14 +350,6 @@ static void __init mp_override_legacy_ir
}
/*
- * Convert 'gsi' to 'ioapic.pin'.
- */
- ioapic = mp_find_ioapic(gsi);
- if (ioapic < 0)
- return;
- pin = mp_find_ioapic_pin(ioapic, gsi);
-
- /*
* TBD: This check is for faulty timer entries, where the override
* erroneously sets the trigger to level, resulting in a HUGE
* increase of timer interrupts!
@@ -366,16 +357,8 @@ static void __init mp_override_legacy_ir
if ((bus_irq == 0) && (trigger == 3))
trigger = 1;
- mp_irq.type = MP_INTSRC;
- mp_irq.irqtype = mp_INT;
- mp_irq.irqflag = (trigger << 2) | polarity;
- mp_irq.srcbus = MP_ISA_BUS;
- mp_irq.srcbusirq = bus_irq; /* IRQ */
- mp_irq.dstapic = mpc_ioapic_id(ioapic); /* APIC ID */
- mp_irq.dstirq = pin; /* INTIN# */
-
- mp_save_irq(&mp_irq);
-
+ if (mp_register_ioapic_irq(bus_irq, polarity, trigger, gsi) < 0)
+ return;
/*
* Reset default identity mapping if gsi is also an legacy IRQ,
* otherwise there will be more than one entry with the same GSI
Patches currently in stable-queue which might be from vikas.cha.sajjan(a)hpe.com are
queue-4.9/x86-acpi-handle-sci-interrupts-above-legacy-space-gracefully.patch
queue-4.9/x86-acpi-reduce-code-duplication-in-mp_override_legacy_irq.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Remove incorrect snd_BUG_ON() usages
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:
alsa-pcm-remove-incorrect-snd_bug_on-usages.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 fe08f34d066f4404934a509b6806db1a4f700c86 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Mon, 1 Jan 2018 09:50:50 +0100
Subject: ALSA: pcm: Remove incorrect snd_BUG_ON() usages
From: Takashi Iwai <tiwai(a)suse.de>
commit fe08f34d066f4404934a509b6806db1a4f700c86 upstream.
syzkaller triggered kernel warnings through PCM OSS emulation at
closing a stream:
WARNING: CPU: 0 PID: 3502 at sound/core/pcm_lib.c:1635
snd_pcm_hw_param_first+0x289/0x690 sound/core/pcm_lib.c:1635
Call Trace:
....
snd_pcm_hw_param_near.constprop.27+0x78d/0x9a0 sound/core/oss/pcm_oss.c:457
snd_pcm_oss_change_params+0x17d3/0x3720 sound/core/oss/pcm_oss.c:969
snd_pcm_oss_make_ready+0xaa/0x130 sound/core/oss/pcm_oss.c:1128
snd_pcm_oss_sync+0x257/0x830 sound/core/oss/pcm_oss.c:1638
snd_pcm_oss_release+0x20b/0x280 sound/core/oss/pcm_oss.c:2431
__fput+0x327/0x7e0 fs/file_table.c:210
....
This happens while it tries to open and set up the aloop device
concurrently. The warning above (invoked from snd_BUG_ON() macro) is
to detect the unexpected logical error where snd_pcm_hw_refine() call
shouldn't fail. The theory is true for the case where the hw_params
config rules are static. But for an aloop device, the hw_params rule
condition does vary dynamically depending on the connected target;
when another device is opened and changes the parameters, the device
connected in another side is also affected, and it caused the error
from snd_pcm_hw_refine().
That is, the simplest "solution" for this is to remove the incorrect
assumption of static rules, and treat such an error as a normal error
path. As there are a couple of other places using snd_BUG_ON()
incorrectly, this patch removes these spurious snd_BUG_ON() calls.
Reported-by: syzbot+6f11c7e2a1b91d466432(a)syzkaller.appspotmail.com
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/oss/pcm_oss.c | 1 -
sound/core/pcm_lib.c | 4 ++--
2 files changed, 2 insertions(+), 3 deletions(-)
--- a/sound/core/oss/pcm_oss.c
+++ b/sound/core/oss/pcm_oss.c
@@ -466,7 +466,6 @@ static int snd_pcm_hw_param_near(struct
v = snd_pcm_hw_param_last(pcm, params, var, dir);
else
v = snd_pcm_hw_param_first(pcm, params, var, dir);
- snd_BUG_ON(v < 0);
return v;
}
--- a/sound/core/pcm_lib.c
+++ b/sound/core/pcm_lib.c
@@ -1664,7 +1664,7 @@ int snd_pcm_hw_param_first(struct snd_pc
return changed;
if (params->rmask) {
int err = snd_pcm_hw_refine(pcm, params);
- if (snd_BUG_ON(err < 0))
+ if (err < 0)
return err;
}
return snd_pcm_hw_param_value(params, var, dir);
@@ -1711,7 +1711,7 @@ int snd_pcm_hw_param_last(struct snd_pcm
return changed;
if (params->rmask) {
int err = snd_pcm_hw_refine(pcm, params);
- if (snd_BUG_ON(err < 0))
+ if (err < 0)
return err;
}
return snd_pcm_hw_param_value(params, var, dir);
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.9/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-4.9/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-4.9/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-4.9/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-4.9/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-4.9/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-4.9/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Allow aborting mutex lock at OSS read/write loops
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:
alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.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 900498a34a3ac9c611e9b425094c8106bdd7dc1c Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Mon, 8 Jan 2018 14:03:53 +0100
Subject: ALSA: pcm: Allow aborting mutex lock at OSS read/write loops
From: Takashi Iwai <tiwai(a)suse.de>
commit 900498a34a3ac9c611e9b425094c8106bdd7dc1c upstream.
PCM OSS read/write loops keep taking the mutex lock for the whole
read/write, and this might take very long when the exceptionally high
amount of data is given. Also, since it invokes with mutex_lock(),
the concurrent read/write becomes unbreakable.
This patch tries to address these issues by replacing mutex_lock()
with mutex_lock_interruptible(), and also splits / re-takes the lock
at each read/write period chunk, so that it can switch the context
more finely if requested.
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/oss/pcm_oss.c | 36 +++++++++++++++++++++---------------
1 file changed, 21 insertions(+), 15 deletions(-)
--- a/sound/core/oss/pcm_oss.c
+++ b/sound/core/oss/pcm_oss.c
@@ -1369,8 +1369,11 @@ static ssize_t snd_pcm_oss_write1(struct
if ((tmp = snd_pcm_oss_make_ready(substream)) < 0)
return tmp;
- mutex_lock(&runtime->oss.params_lock);
while (bytes > 0) {
+ if (mutex_lock_interruptible(&runtime->oss.params_lock)) {
+ tmp = -ERESTARTSYS;
+ break;
+ }
if (bytes < runtime->oss.period_bytes || runtime->oss.buffer_used > 0) {
tmp = bytes;
if (tmp + runtime->oss.buffer_used > runtime->oss.period_bytes)
@@ -1414,18 +1417,18 @@ static ssize_t snd_pcm_oss_write1(struct
xfer += tmp;
if ((substream->f_flags & O_NONBLOCK) != 0 &&
tmp != runtime->oss.period_bytes)
- break;
+ tmp = -EAGAIN;
}
+ err:
+ mutex_unlock(&runtime->oss.params_lock);
+ if (tmp < 0)
+ break;
if (signal_pending(current)) {
tmp = -ERESTARTSYS;
- goto err;
+ break;
}
+ tmp = 0;
}
- mutex_unlock(&runtime->oss.params_lock);
- return xfer;
-
- err:
- mutex_unlock(&runtime->oss.params_lock);
return xfer > 0 ? (snd_pcm_sframes_t)xfer : tmp;
}
@@ -1473,8 +1476,11 @@ static ssize_t snd_pcm_oss_read1(struct
if ((tmp = snd_pcm_oss_make_ready(substream)) < 0)
return tmp;
- mutex_lock(&runtime->oss.params_lock);
while (bytes > 0) {
+ if (mutex_lock_interruptible(&runtime->oss.params_lock)) {
+ tmp = -ERESTARTSYS;
+ break;
+ }
if (bytes < runtime->oss.period_bytes || runtime->oss.buffer_used > 0) {
if (runtime->oss.buffer_used == 0) {
tmp = snd_pcm_oss_read2(substream, runtime->oss.buffer, runtime->oss.period_bytes, 1);
@@ -1505,16 +1511,16 @@ static ssize_t snd_pcm_oss_read1(struct
bytes -= tmp;
xfer += tmp;
}
+ err:
+ mutex_unlock(&runtime->oss.params_lock);
+ if (tmp < 0)
+ break;
if (signal_pending(current)) {
tmp = -ERESTARTSYS;
- goto err;
+ break;
}
+ tmp = 0;
}
- mutex_unlock(&runtime->oss.params_lock);
- return xfer;
-
- err:
- mutex_unlock(&runtime->oss.params_lock);
return xfer > 0 ? (snd_pcm_sframes_t)xfer : tmp;
}
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.9/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-4.9/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-4.9/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-4.9/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-4.9/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-4.9/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-4.9/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Add missing error checks in OSS emulation plugin builder
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:
alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.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 6708913750344a900f2e73bfe4a4d6dbbce4fe8d Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Thu, 4 Jan 2018 16:39:27 +0100
Subject: ALSA: pcm: Add missing error checks in OSS emulation plugin builder
From: Takashi Iwai <tiwai(a)suse.de>
commit 6708913750344a900f2e73bfe4a4d6dbbce4fe8d upstream.
In the OSS emulation plugin builder where the frame size is parsed in
the plugin chain, some places miss the possible errors returned from
the plugin src_ or dst_frames callback.
This patch papers over such places.
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/oss/pcm_plugin.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
--- a/sound/core/oss/pcm_plugin.c
+++ b/sound/core/oss/pcm_plugin.c
@@ -591,18 +591,26 @@ snd_pcm_sframes_t snd_pcm_plug_write_tra
snd_pcm_sframes_t frames = size;
plugin = snd_pcm_plug_first(plug);
- while (plugin && frames > 0) {
+ while (plugin) {
+ if (frames <= 0)
+ return frames;
if ((next = plugin->next) != NULL) {
snd_pcm_sframes_t frames1 = frames;
- if (plugin->dst_frames)
+ if (plugin->dst_frames) {
frames1 = plugin->dst_frames(plugin, frames);
+ if (frames1 <= 0)
+ return frames1;
+ }
if ((err = next->client_channels(next, frames1, &dst_channels)) < 0) {
return err;
}
if (err != frames1) {
frames = err;
- if (plugin->src_frames)
+ if (plugin->src_frames) {
frames = plugin->src_frames(plugin, frames1);
+ if (frames <= 0)
+ return frames;
+ }
}
} else
dst_channels = NULL;
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.9/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-4.9/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-4.9/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-4.9/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-4.9/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-4.9/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-4.9/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Abort properly at pending signal in OSS read/write loops
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:
alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.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 29159a4ed7044c52e3e2cf1a9fb55cec4745c60b Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Mon, 8 Jan 2018 13:58:31 +0100
Subject: ALSA: pcm: Abort properly at pending signal in OSS read/write loops
From: Takashi Iwai <tiwai(a)suse.de>
commit 29159a4ed7044c52e3e2cf1a9fb55cec4745c60b upstream.
The loops for read and write in PCM OSS emulation have no proper check
of pending signals, and they keep processing even after user tries to
break. This results in a very long delay, often seen as RCU stall
when a huge unprocessed bytes remain queued. The bug could be easily
triggered by syzkaller.
As a simple workaround, this patch adds the proper check of pending
signals and aborts the loop appropriately.
Reported-by: syzbot+993cb4cfcbbff3947c21(a)syzkaller.appspotmail.com
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/oss/pcm_oss.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/sound/core/oss/pcm_oss.c
+++ b/sound/core/oss/pcm_oss.c
@@ -1416,6 +1416,10 @@ static ssize_t snd_pcm_oss_write1(struct
tmp != runtime->oss.period_bytes)
break;
}
+ if (signal_pending(current)) {
+ tmp = -ERESTARTSYS;
+ goto err;
+ }
}
mutex_unlock(&runtime->oss.params_lock);
return xfer;
@@ -1501,6 +1505,10 @@ static ssize_t snd_pcm_oss_read1(struct
bytes -= tmp;
xfer += tmp;
}
+ if (signal_pending(current)) {
+ tmp = -ERESTARTSYS;
+ goto err;
+ }
}
mutex_unlock(&runtime->oss.params_lock);
return xfer;
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.9/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-4.9/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-4.9/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-4.9/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-4.9/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-4.9/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-4.9/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: aloop: Release cable upon open error path
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:
alsa-aloop-release-cable-upon-open-error-path.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 9685347aa0a5c2869058ca6ab79fd8e93084a67f Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Fri, 5 Jan 2018 16:09:47 +0100
Subject: ALSA: aloop: Release cable upon open error path
From: Takashi Iwai <tiwai(a)suse.de>
commit 9685347aa0a5c2869058ca6ab79fd8e93084a67f upstream.
The aloop runtime object and its assignment in the cable are left even
when opening a substream fails. This doesn't mean any memory leak,
but it still keeps the invalid pointer that may be referred by the
another side of the cable spontaneously, which is a potential Oops
cause.
Clean up the cable assignment and the empty cable upon the error path
properly.
Fixes: 597603d615d2 ("ALSA: introduce the snd-aloop module for the PCM loopback")
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/drivers/aloop.c | 38 +++++++++++++++++++++++++-------------
1 file changed, 25 insertions(+), 13 deletions(-)
--- a/sound/drivers/aloop.c
+++ b/sound/drivers/aloop.c
@@ -658,12 +658,31 @@ static int rule_channels(struct snd_pcm_
return snd_interval_refine(hw_param_interval(params, rule->var), &t);
}
+static void free_cable(struct snd_pcm_substream *substream)
+{
+ struct loopback *loopback = substream->private_data;
+ int dev = get_cable_index(substream);
+ struct loopback_cable *cable;
+
+ cable = loopback->cables[substream->number][dev];
+ if (!cable)
+ return;
+ if (cable->streams[!substream->stream]) {
+ /* other stream is still alive */
+ cable->streams[substream->stream] = NULL;
+ } else {
+ /* free the cable */
+ loopback->cables[substream->number][dev] = NULL;
+ kfree(cable);
+ }
+}
+
static int loopback_open(struct snd_pcm_substream *substream)
{
struct snd_pcm_runtime *runtime = substream->runtime;
struct loopback *loopback = substream->private_data;
struct loopback_pcm *dpcm;
- struct loopback_cable *cable;
+ struct loopback_cable *cable = NULL;
int err = 0;
int dev = get_cable_index(substream);
@@ -682,7 +701,6 @@ static int loopback_open(struct snd_pcm_
if (!cable) {
cable = kzalloc(sizeof(*cable), GFP_KERNEL);
if (!cable) {
- kfree(dpcm);
err = -ENOMEM;
goto unlock;
}
@@ -724,6 +742,10 @@ static int loopback_open(struct snd_pcm_
else
runtime->hw = cable->hw;
unlock:
+ if (err < 0) {
+ free_cable(substream);
+ kfree(dpcm);
+ }
mutex_unlock(&loopback->cable_lock);
return err;
}
@@ -732,20 +754,10 @@ static int loopback_close(struct snd_pcm
{
struct loopback *loopback = substream->private_data;
struct loopback_pcm *dpcm = substream->runtime->private_data;
- struct loopback_cable *cable;
- int dev = get_cable_index(substream);
loopback_timer_stop(dpcm);
mutex_lock(&loopback->cable_lock);
- cable = loopback->cables[substream->number][dev];
- if (cable->streams[!substream->stream]) {
- /* other stream is still alive */
- cable->streams[substream->stream] = NULL;
- } else {
- /* free the cable */
- loopback->cables[substream->number][dev] = NULL;
- kfree(cable);
- }
+ free_cable(substream);
mutex_unlock(&loopback->cable_lock);
return 0;
}
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.9/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-4.9/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-4.9/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-4.9/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-4.9/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-4.9/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-4.9/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: aloop: Fix racy hw constraints adjustment
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:
alsa-aloop-fix-racy-hw-constraints-adjustment.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 898dfe4687f460ba337a01c11549f87269a13fa2 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Thu, 4 Jan 2018 17:38:54 +0100
Subject: ALSA: aloop: Fix racy hw constraints adjustment
From: Takashi Iwai <tiwai(a)suse.de>
commit 898dfe4687f460ba337a01c11549f87269a13fa2 upstream.
The aloop driver tries to update the hw constraints of the connected
target on the cable of the opened PCM substream. This is done by
adding the extra hw constraints rules referring to the substream
runtime->hw fields, while the other substream may update the runtime
hw of another side on the fly.
This is, however, racy and may result in the inconsistent values when
both PCM streams perform the prepare concurrently. One of the reason
is that it overwrites the other's runtime->hw field; which is not only
racy but also broken when it's called before the open of another side
finishes. And, since the reference to runtime->hw isn't protected,
the concurrent write may give the partial value update and become
inconsistent.
This patch is an attempt to fix and clean up:
- The prepare doesn't change the runtime->hw of other side any longer,
but only update the cable->hw that is referred commonly.
- The extra rules refer to the loopback_pcm object instead of the
runtime->hw. The actual hw is deduced from cable->hw.
- The extra rules take the cable_lock to protect against the race.
Fixes: b1c73fc8e697 ("ALSA: snd-aloop: Fix hw_params restrictions and checking")
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/drivers/aloop.c | 51 ++++++++++++++++++++------------------------------
1 file changed, 21 insertions(+), 30 deletions(-)
--- a/sound/drivers/aloop.c
+++ b/sound/drivers/aloop.c
@@ -306,19 +306,6 @@ static int loopback_trigger(struct snd_p
return 0;
}
-static void params_change_substream(struct loopback_pcm *dpcm,
- struct snd_pcm_runtime *runtime)
-{
- struct snd_pcm_runtime *dst_runtime;
-
- if (dpcm == NULL || dpcm->substream == NULL)
- return;
- dst_runtime = dpcm->substream->runtime;
- if (dst_runtime == NULL)
- return;
- dst_runtime->hw = dpcm->cable->hw;
-}
-
static void params_change(struct snd_pcm_substream *substream)
{
struct snd_pcm_runtime *runtime = substream->runtime;
@@ -330,10 +317,6 @@ static void params_change(struct snd_pcm
cable->hw.rate_max = runtime->rate;
cable->hw.channels_min = runtime->channels;
cable->hw.channels_max = runtime->channels;
- params_change_substream(cable->streams[SNDRV_PCM_STREAM_PLAYBACK],
- runtime);
- params_change_substream(cable->streams[SNDRV_PCM_STREAM_CAPTURE],
- runtime);
}
static int loopback_prepare(struct snd_pcm_substream *substream)
@@ -621,24 +604,29 @@ static unsigned int get_cable_index(stru
static int rule_format(struct snd_pcm_hw_params *params,
struct snd_pcm_hw_rule *rule)
{
-
- struct snd_pcm_hardware *hw = rule->private;
+ struct loopback_pcm *dpcm = rule->private;
+ struct loopback_cable *cable = dpcm->cable;
struct snd_mask m;
snd_mask_none(&m);
- m.bits[0] = (u_int32_t)hw->formats;
- m.bits[1] = (u_int32_t)(hw->formats >> 32);
+ mutex_lock(&dpcm->loopback->cable_lock);
+ m.bits[0] = (u_int32_t)cable->hw.formats;
+ m.bits[1] = (u_int32_t)(cable->hw.formats >> 32);
+ mutex_unlock(&dpcm->loopback->cable_lock);
return snd_mask_refine(hw_param_mask(params, rule->var), &m);
}
static int rule_rate(struct snd_pcm_hw_params *params,
struct snd_pcm_hw_rule *rule)
{
- struct snd_pcm_hardware *hw = rule->private;
+ struct loopback_pcm *dpcm = rule->private;
+ struct loopback_cable *cable = dpcm->cable;
struct snd_interval t;
- t.min = hw->rate_min;
- t.max = hw->rate_max;
+ mutex_lock(&dpcm->loopback->cable_lock);
+ t.min = cable->hw.rate_min;
+ t.max = cable->hw.rate_max;
+ mutex_unlock(&dpcm->loopback->cable_lock);
t.openmin = t.openmax = 0;
t.integer = 0;
return snd_interval_refine(hw_param_interval(params, rule->var), &t);
@@ -647,11 +635,14 @@ static int rule_rate(struct snd_pcm_hw_p
static int rule_channels(struct snd_pcm_hw_params *params,
struct snd_pcm_hw_rule *rule)
{
- struct snd_pcm_hardware *hw = rule->private;
+ struct loopback_pcm *dpcm = rule->private;
+ struct loopback_cable *cable = dpcm->cable;
struct snd_interval t;
- t.min = hw->channels_min;
- t.max = hw->channels_max;
+ mutex_lock(&dpcm->loopback->cable_lock);
+ t.min = cable->hw.channels_min;
+ t.max = cable->hw.channels_max;
+ mutex_unlock(&dpcm->loopback->cable_lock);
t.openmin = t.openmax = 0;
t.integer = 0;
return snd_interval_refine(hw_param_interval(params, rule->var), &t);
@@ -717,19 +708,19 @@ static int loopback_open(struct snd_pcm_
/* are cached -> they do not reflect the actual state */
err = snd_pcm_hw_rule_add(runtime, 0,
SNDRV_PCM_HW_PARAM_FORMAT,
- rule_format, &runtime->hw,
+ rule_format, dpcm,
SNDRV_PCM_HW_PARAM_FORMAT, -1);
if (err < 0)
goto unlock;
err = snd_pcm_hw_rule_add(runtime, 0,
SNDRV_PCM_HW_PARAM_RATE,
- rule_rate, &runtime->hw,
+ rule_rate, dpcm,
SNDRV_PCM_HW_PARAM_RATE, -1);
if (err < 0)
goto unlock;
err = snd_pcm_hw_rule_add(runtime, 0,
SNDRV_PCM_HW_PARAM_CHANNELS,
- rule_channels, &runtime->hw,
+ rule_channels, dpcm,
SNDRV_PCM_HW_PARAM_CHANNELS, -1);
if (err < 0)
goto unlock;
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.9/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-4.9/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-4.9/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-4.9/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-4.9/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-4.9/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-4.9/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: aloop: Fix inconsistent format due to incomplete rule
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:
alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.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 b088b53e20c7d09b5ab84c5688e609f478e5c417 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Fri, 5 Jan 2018 16:15:33 +0100
Subject: ALSA: aloop: Fix inconsistent format due to incomplete rule
From: Takashi Iwai <tiwai(a)suse.de>
commit b088b53e20c7d09b5ab84c5688e609f478e5c417 upstream.
The extra hw constraint rule for the formats the aloop driver
introduced has a slight flaw, where it doesn't return a positive value
when the mask got changed. It came from the fact that it's basically
a copy&paste from snd_hw_constraint_mask64(). The original code is
supposed to be a single-shot and it modifies the mask bits only once
and never after, while what we need for aloop is the dynamic hw rule
that limits the mask bits.
This difference results in the inconsistent state, as the hw_refine
doesn't apply the dependencies fully. The worse and surprisingly
result is that it causes a crash in OSS emulation when multiple
full-duplex reads/writes are performed concurrently (I leave why it
triggers Oops to readers as a homework).
For fixing this, replace a few open-codes with the standard
snd_mask_*() macros.
Reported-by: syzbot+3902b5220e8ca27889ca(a)syzkaller.appspotmail.com
Fixes: b1c73fc8e697 ("ALSA: snd-aloop: Fix hw_params restrictions and checking")
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/drivers/aloop.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
--- a/sound/drivers/aloop.c
+++ b/sound/drivers/aloop.c
@@ -39,6 +39,7 @@
#include <sound/core.h>
#include <sound/control.h>
#include <sound/pcm.h>
+#include <sound/pcm_params.h>
#include <sound/info.h>
#include <sound/initval.h>
@@ -622,14 +623,12 @@ static int rule_format(struct snd_pcm_hw
{
struct snd_pcm_hardware *hw = rule->private;
- struct snd_mask *maskp = hw_param_mask(params, rule->var);
+ struct snd_mask m;
- maskp->bits[0] &= (u_int32_t)hw->formats;
- maskp->bits[1] &= (u_int32_t)(hw->formats >> 32);
- memset(maskp->bits + 2, 0, (SNDRV_MASK_MAX-64) / 8); /* clear rest */
- if (! maskp->bits[0] && ! maskp->bits[1])
- return -EINVAL;
- return 0;
+ snd_mask_none(&m);
+ m.bits[0] = (u_int32_t)hw->formats;
+ m.bits[1] = (u_int32_t)(hw->formats >> 32);
+ return snd_mask_refine(hw_param_mask(params, rule->var), &m);
}
static int rule_rate(struct snd_pcm_hw_params *params,
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.9/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-4.9/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-4.9/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-4.9/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-4.9/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-4.9/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-4.9/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Remove incorrect snd_BUG_ON() usages
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:
alsa-pcm-remove-incorrect-snd_bug_on-usages.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 fe08f34d066f4404934a509b6806db1a4f700c86 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Mon, 1 Jan 2018 09:50:50 +0100
Subject: ALSA: pcm: Remove incorrect snd_BUG_ON() usages
From: Takashi Iwai <tiwai(a)suse.de>
commit fe08f34d066f4404934a509b6806db1a4f700c86 upstream.
syzkaller triggered kernel warnings through PCM OSS emulation at
closing a stream:
WARNING: CPU: 0 PID: 3502 at sound/core/pcm_lib.c:1635
snd_pcm_hw_param_first+0x289/0x690 sound/core/pcm_lib.c:1635
Call Trace:
....
snd_pcm_hw_param_near.constprop.27+0x78d/0x9a0 sound/core/oss/pcm_oss.c:457
snd_pcm_oss_change_params+0x17d3/0x3720 sound/core/oss/pcm_oss.c:969
snd_pcm_oss_make_ready+0xaa/0x130 sound/core/oss/pcm_oss.c:1128
snd_pcm_oss_sync+0x257/0x830 sound/core/oss/pcm_oss.c:1638
snd_pcm_oss_release+0x20b/0x280 sound/core/oss/pcm_oss.c:2431
__fput+0x327/0x7e0 fs/file_table.c:210
....
This happens while it tries to open and set up the aloop device
concurrently. The warning above (invoked from snd_BUG_ON() macro) is
to detect the unexpected logical error where snd_pcm_hw_refine() call
shouldn't fail. The theory is true for the case where the hw_params
config rules are static. But for an aloop device, the hw_params rule
condition does vary dynamically depending on the connected target;
when another device is opened and changes the parameters, the device
connected in another side is also affected, and it caused the error
from snd_pcm_hw_refine().
That is, the simplest "solution" for this is to remove the incorrect
assumption of static rules, and treat such an error as a normal error
path. As there are a couple of other places using snd_BUG_ON()
incorrectly, this patch removes these spurious snd_BUG_ON() calls.
Reported-by: syzbot+6f11c7e2a1b91d466432(a)syzkaller.appspotmail.com
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/oss/pcm_oss.c | 1 -
sound/core/pcm_lib.c | 4 ++--
2 files changed, 2 insertions(+), 3 deletions(-)
--- a/sound/core/oss/pcm_oss.c
+++ b/sound/core/oss/pcm_oss.c
@@ -465,7 +465,6 @@ static int snd_pcm_hw_param_near(struct
v = snd_pcm_hw_param_last(pcm, params, var, dir);
else
v = snd_pcm_hw_param_first(pcm, params, var, dir);
- snd_BUG_ON(v < 0);
return v;
}
--- a/sound/core/pcm_lib.c
+++ b/sound/core/pcm_lib.c
@@ -1664,7 +1664,7 @@ int snd_pcm_hw_param_first(struct snd_pc
return changed;
if (params->rmask) {
int err = snd_pcm_hw_refine(pcm, params);
- if (snd_BUG_ON(err < 0))
+ if (err < 0)
return err;
}
return snd_pcm_hw_param_value(params, var, dir);
@@ -1711,7 +1711,7 @@ int snd_pcm_hw_param_last(struct snd_pcm
return changed;
if (params->rmask) {
int err = snd_pcm_hw_refine(pcm, params);
- if (snd_BUG_ON(err < 0))
+ if (err < 0)
return err;
}
return snd_pcm_hw_param_value(params, var, dir);
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.4/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-4.4/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-4.4/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-4.4/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-4.4/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-4.4/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-4.4/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Allow aborting mutex lock at OSS read/write loops
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:
alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.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 900498a34a3ac9c611e9b425094c8106bdd7dc1c Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Mon, 8 Jan 2018 14:03:53 +0100
Subject: ALSA: pcm: Allow aborting mutex lock at OSS read/write loops
From: Takashi Iwai <tiwai(a)suse.de>
commit 900498a34a3ac9c611e9b425094c8106bdd7dc1c upstream.
PCM OSS read/write loops keep taking the mutex lock for the whole
read/write, and this might take very long when the exceptionally high
amount of data is given. Also, since it invokes with mutex_lock(),
the concurrent read/write becomes unbreakable.
This patch tries to address these issues by replacing mutex_lock()
with mutex_lock_interruptible(), and also splits / re-takes the lock
at each read/write period chunk, so that it can switch the context
more finely if requested.
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/oss/pcm_oss.c | 36 +++++++++++++++++++++---------------
1 file changed, 21 insertions(+), 15 deletions(-)
--- a/sound/core/oss/pcm_oss.c
+++ b/sound/core/oss/pcm_oss.c
@@ -1369,8 +1369,11 @@ static ssize_t snd_pcm_oss_write1(struct
if ((tmp = snd_pcm_oss_make_ready(substream)) < 0)
return tmp;
- mutex_lock(&runtime->oss.params_lock);
while (bytes > 0) {
+ if (mutex_lock_interruptible(&runtime->oss.params_lock)) {
+ tmp = -ERESTARTSYS;
+ break;
+ }
if (bytes < runtime->oss.period_bytes || runtime->oss.buffer_used > 0) {
tmp = bytes;
if (tmp + runtime->oss.buffer_used > runtime->oss.period_bytes)
@@ -1414,18 +1417,18 @@ static ssize_t snd_pcm_oss_write1(struct
xfer += tmp;
if ((substream->f_flags & O_NONBLOCK) != 0 &&
tmp != runtime->oss.period_bytes)
- break;
+ tmp = -EAGAIN;
}
+ err:
+ mutex_unlock(&runtime->oss.params_lock);
+ if (tmp < 0)
+ break;
if (signal_pending(current)) {
tmp = -ERESTARTSYS;
- goto err;
+ break;
}
+ tmp = 0;
}
- mutex_unlock(&runtime->oss.params_lock);
- return xfer;
-
- err:
- mutex_unlock(&runtime->oss.params_lock);
return xfer > 0 ? (snd_pcm_sframes_t)xfer : tmp;
}
@@ -1473,8 +1476,11 @@ static ssize_t snd_pcm_oss_read1(struct
if ((tmp = snd_pcm_oss_make_ready(substream)) < 0)
return tmp;
- mutex_lock(&runtime->oss.params_lock);
while (bytes > 0) {
+ if (mutex_lock_interruptible(&runtime->oss.params_lock)) {
+ tmp = -ERESTARTSYS;
+ break;
+ }
if (bytes < runtime->oss.period_bytes || runtime->oss.buffer_used > 0) {
if (runtime->oss.buffer_used == 0) {
tmp = snd_pcm_oss_read2(substream, runtime->oss.buffer, runtime->oss.period_bytes, 1);
@@ -1505,16 +1511,16 @@ static ssize_t snd_pcm_oss_read1(struct
bytes -= tmp;
xfer += tmp;
}
+ err:
+ mutex_unlock(&runtime->oss.params_lock);
+ if (tmp < 0)
+ break;
if (signal_pending(current)) {
tmp = -ERESTARTSYS;
- goto err;
+ break;
}
+ tmp = 0;
}
- mutex_unlock(&runtime->oss.params_lock);
- return xfer;
-
- err:
- mutex_unlock(&runtime->oss.params_lock);
return xfer > 0 ? (snd_pcm_sframes_t)xfer : tmp;
}
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.4/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-4.4/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-4.4/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-4.4/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-4.4/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-4.4/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-4.4/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: aloop: Release cable upon open error path
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:
alsa-aloop-release-cable-upon-open-error-path.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 9685347aa0a5c2869058ca6ab79fd8e93084a67f Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Fri, 5 Jan 2018 16:09:47 +0100
Subject: ALSA: aloop: Release cable upon open error path
From: Takashi Iwai <tiwai(a)suse.de>
commit 9685347aa0a5c2869058ca6ab79fd8e93084a67f upstream.
The aloop runtime object and its assignment in the cable are left even
when opening a substream fails. This doesn't mean any memory leak,
but it still keeps the invalid pointer that may be referred by the
another side of the cable spontaneously, which is a potential Oops
cause.
Clean up the cable assignment and the empty cable upon the error path
properly.
Fixes: 597603d615d2 ("ALSA: introduce the snd-aloop module for the PCM loopback")
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/drivers/aloop.c | 38 +++++++++++++++++++++++++-------------
1 file changed, 25 insertions(+), 13 deletions(-)
--- a/sound/drivers/aloop.c
+++ b/sound/drivers/aloop.c
@@ -658,12 +658,31 @@ static int rule_channels(struct snd_pcm_
return snd_interval_refine(hw_param_interval(params, rule->var), &t);
}
+static void free_cable(struct snd_pcm_substream *substream)
+{
+ struct loopback *loopback = substream->private_data;
+ int dev = get_cable_index(substream);
+ struct loopback_cable *cable;
+
+ cable = loopback->cables[substream->number][dev];
+ if (!cable)
+ return;
+ if (cable->streams[!substream->stream]) {
+ /* other stream is still alive */
+ cable->streams[substream->stream] = NULL;
+ } else {
+ /* free the cable */
+ loopback->cables[substream->number][dev] = NULL;
+ kfree(cable);
+ }
+}
+
static int loopback_open(struct snd_pcm_substream *substream)
{
struct snd_pcm_runtime *runtime = substream->runtime;
struct loopback *loopback = substream->private_data;
struct loopback_pcm *dpcm;
- struct loopback_cable *cable;
+ struct loopback_cable *cable = NULL;
int err = 0;
int dev = get_cable_index(substream);
@@ -682,7 +701,6 @@ static int loopback_open(struct snd_pcm_
if (!cable) {
cable = kzalloc(sizeof(*cable), GFP_KERNEL);
if (!cable) {
- kfree(dpcm);
err = -ENOMEM;
goto unlock;
}
@@ -724,6 +742,10 @@ static int loopback_open(struct snd_pcm_
else
runtime->hw = cable->hw;
unlock:
+ if (err < 0) {
+ free_cable(substream);
+ kfree(dpcm);
+ }
mutex_unlock(&loopback->cable_lock);
return err;
}
@@ -732,20 +754,10 @@ static int loopback_close(struct snd_pcm
{
struct loopback *loopback = substream->private_data;
struct loopback_pcm *dpcm = substream->runtime->private_data;
- struct loopback_cable *cable;
- int dev = get_cable_index(substream);
loopback_timer_stop(dpcm);
mutex_lock(&loopback->cable_lock);
- cable = loopback->cables[substream->number][dev];
- if (cable->streams[!substream->stream]) {
- /* other stream is still alive */
- cable->streams[substream->stream] = NULL;
- } else {
- /* free the cable */
- loopback->cables[substream->number][dev] = NULL;
- kfree(cable);
- }
+ free_cable(substream);
mutex_unlock(&loopback->cable_lock);
return 0;
}
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.4/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-4.4/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-4.4/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-4.4/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-4.4/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-4.4/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-4.4/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Add missing error checks in OSS emulation plugin builder
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:
alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.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 6708913750344a900f2e73bfe4a4d6dbbce4fe8d Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Thu, 4 Jan 2018 16:39:27 +0100
Subject: ALSA: pcm: Add missing error checks in OSS emulation plugin builder
From: Takashi Iwai <tiwai(a)suse.de>
commit 6708913750344a900f2e73bfe4a4d6dbbce4fe8d upstream.
In the OSS emulation plugin builder where the frame size is parsed in
the plugin chain, some places miss the possible errors returned from
the plugin src_ or dst_frames callback.
This patch papers over such places.
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/oss/pcm_plugin.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
--- a/sound/core/oss/pcm_plugin.c
+++ b/sound/core/oss/pcm_plugin.c
@@ -591,18 +591,26 @@ snd_pcm_sframes_t snd_pcm_plug_write_tra
snd_pcm_sframes_t frames = size;
plugin = snd_pcm_plug_first(plug);
- while (plugin && frames > 0) {
+ while (plugin) {
+ if (frames <= 0)
+ return frames;
if ((next = plugin->next) != NULL) {
snd_pcm_sframes_t frames1 = frames;
- if (plugin->dst_frames)
+ if (plugin->dst_frames) {
frames1 = plugin->dst_frames(plugin, frames);
+ if (frames1 <= 0)
+ return frames1;
+ }
if ((err = next->client_channels(next, frames1, &dst_channels)) < 0) {
return err;
}
if (err != frames1) {
frames = err;
- if (plugin->src_frames)
+ if (plugin->src_frames) {
frames = plugin->src_frames(plugin, frames1);
+ if (frames <= 0)
+ return frames;
+ }
}
} else
dst_channels = NULL;
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.4/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-4.4/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-4.4/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-4.4/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-4.4/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-4.4/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-4.4/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Abort properly at pending signal in OSS read/write loops
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:
alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.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 29159a4ed7044c52e3e2cf1a9fb55cec4745c60b Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Mon, 8 Jan 2018 13:58:31 +0100
Subject: ALSA: pcm: Abort properly at pending signal in OSS read/write loops
From: Takashi Iwai <tiwai(a)suse.de>
commit 29159a4ed7044c52e3e2cf1a9fb55cec4745c60b upstream.
The loops for read and write in PCM OSS emulation have no proper check
of pending signals, and they keep processing even after user tries to
break. This results in a very long delay, often seen as RCU stall
when a huge unprocessed bytes remain queued. The bug could be easily
triggered by syzkaller.
As a simple workaround, this patch adds the proper check of pending
signals and aborts the loop appropriately.
Reported-by: syzbot+993cb4cfcbbff3947c21(a)syzkaller.appspotmail.com
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/oss/pcm_oss.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/sound/core/oss/pcm_oss.c
+++ b/sound/core/oss/pcm_oss.c
@@ -1416,6 +1416,10 @@ static ssize_t snd_pcm_oss_write1(struct
tmp != runtime->oss.period_bytes)
break;
}
+ if (signal_pending(current)) {
+ tmp = -ERESTARTSYS;
+ goto err;
+ }
}
mutex_unlock(&runtime->oss.params_lock);
return xfer;
@@ -1501,6 +1505,10 @@ static ssize_t snd_pcm_oss_read1(struct
bytes -= tmp;
xfer += tmp;
}
+ if (signal_pending(current)) {
+ tmp = -ERESTARTSYS;
+ goto err;
+ }
}
mutex_unlock(&runtime->oss.params_lock);
return xfer;
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.4/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-4.4/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-4.4/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-4.4/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-4.4/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-4.4/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-4.4/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: aloop: Fix racy hw constraints adjustment
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:
alsa-aloop-fix-racy-hw-constraints-adjustment.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 898dfe4687f460ba337a01c11549f87269a13fa2 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Thu, 4 Jan 2018 17:38:54 +0100
Subject: ALSA: aloop: Fix racy hw constraints adjustment
From: Takashi Iwai <tiwai(a)suse.de>
commit 898dfe4687f460ba337a01c11549f87269a13fa2 upstream.
The aloop driver tries to update the hw constraints of the connected
target on the cable of the opened PCM substream. This is done by
adding the extra hw constraints rules referring to the substream
runtime->hw fields, while the other substream may update the runtime
hw of another side on the fly.
This is, however, racy and may result in the inconsistent values when
both PCM streams perform the prepare concurrently. One of the reason
is that it overwrites the other's runtime->hw field; which is not only
racy but also broken when it's called before the open of another side
finishes. And, since the reference to runtime->hw isn't protected,
the concurrent write may give the partial value update and become
inconsistent.
This patch is an attempt to fix and clean up:
- The prepare doesn't change the runtime->hw of other side any longer,
but only update the cable->hw that is referred commonly.
- The extra rules refer to the loopback_pcm object instead of the
runtime->hw. The actual hw is deduced from cable->hw.
- The extra rules take the cable_lock to protect against the race.
Fixes: b1c73fc8e697 ("ALSA: snd-aloop: Fix hw_params restrictions and checking")
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/drivers/aloop.c | 51 ++++++++++++++++++++------------------------------
1 file changed, 21 insertions(+), 30 deletions(-)
--- a/sound/drivers/aloop.c
+++ b/sound/drivers/aloop.c
@@ -306,19 +306,6 @@ static int loopback_trigger(struct snd_p
return 0;
}
-static void params_change_substream(struct loopback_pcm *dpcm,
- struct snd_pcm_runtime *runtime)
-{
- struct snd_pcm_runtime *dst_runtime;
-
- if (dpcm == NULL || dpcm->substream == NULL)
- return;
- dst_runtime = dpcm->substream->runtime;
- if (dst_runtime == NULL)
- return;
- dst_runtime->hw = dpcm->cable->hw;
-}
-
static void params_change(struct snd_pcm_substream *substream)
{
struct snd_pcm_runtime *runtime = substream->runtime;
@@ -330,10 +317,6 @@ static void params_change(struct snd_pcm
cable->hw.rate_max = runtime->rate;
cable->hw.channels_min = runtime->channels;
cable->hw.channels_max = runtime->channels;
- params_change_substream(cable->streams[SNDRV_PCM_STREAM_PLAYBACK],
- runtime);
- params_change_substream(cable->streams[SNDRV_PCM_STREAM_CAPTURE],
- runtime);
}
static int loopback_prepare(struct snd_pcm_substream *substream)
@@ -621,24 +604,29 @@ static unsigned int get_cable_index(stru
static int rule_format(struct snd_pcm_hw_params *params,
struct snd_pcm_hw_rule *rule)
{
-
- struct snd_pcm_hardware *hw = rule->private;
+ struct loopback_pcm *dpcm = rule->private;
+ struct loopback_cable *cable = dpcm->cable;
struct snd_mask m;
snd_mask_none(&m);
- m.bits[0] = (u_int32_t)hw->formats;
- m.bits[1] = (u_int32_t)(hw->formats >> 32);
+ mutex_lock(&dpcm->loopback->cable_lock);
+ m.bits[0] = (u_int32_t)cable->hw.formats;
+ m.bits[1] = (u_int32_t)(cable->hw.formats >> 32);
+ mutex_unlock(&dpcm->loopback->cable_lock);
return snd_mask_refine(hw_param_mask(params, rule->var), &m);
}
static int rule_rate(struct snd_pcm_hw_params *params,
struct snd_pcm_hw_rule *rule)
{
- struct snd_pcm_hardware *hw = rule->private;
+ struct loopback_pcm *dpcm = rule->private;
+ struct loopback_cable *cable = dpcm->cable;
struct snd_interval t;
- t.min = hw->rate_min;
- t.max = hw->rate_max;
+ mutex_lock(&dpcm->loopback->cable_lock);
+ t.min = cable->hw.rate_min;
+ t.max = cable->hw.rate_max;
+ mutex_unlock(&dpcm->loopback->cable_lock);
t.openmin = t.openmax = 0;
t.integer = 0;
return snd_interval_refine(hw_param_interval(params, rule->var), &t);
@@ -647,11 +635,14 @@ static int rule_rate(struct snd_pcm_hw_p
static int rule_channels(struct snd_pcm_hw_params *params,
struct snd_pcm_hw_rule *rule)
{
- struct snd_pcm_hardware *hw = rule->private;
+ struct loopback_pcm *dpcm = rule->private;
+ struct loopback_cable *cable = dpcm->cable;
struct snd_interval t;
- t.min = hw->channels_min;
- t.max = hw->channels_max;
+ mutex_lock(&dpcm->loopback->cable_lock);
+ t.min = cable->hw.channels_min;
+ t.max = cable->hw.channels_max;
+ mutex_unlock(&dpcm->loopback->cable_lock);
t.openmin = t.openmax = 0;
t.integer = 0;
return snd_interval_refine(hw_param_interval(params, rule->var), &t);
@@ -717,19 +708,19 @@ static int loopback_open(struct snd_pcm_
/* are cached -> they do not reflect the actual state */
err = snd_pcm_hw_rule_add(runtime, 0,
SNDRV_PCM_HW_PARAM_FORMAT,
- rule_format, &runtime->hw,
+ rule_format, dpcm,
SNDRV_PCM_HW_PARAM_FORMAT, -1);
if (err < 0)
goto unlock;
err = snd_pcm_hw_rule_add(runtime, 0,
SNDRV_PCM_HW_PARAM_RATE,
- rule_rate, &runtime->hw,
+ rule_rate, dpcm,
SNDRV_PCM_HW_PARAM_RATE, -1);
if (err < 0)
goto unlock;
err = snd_pcm_hw_rule_add(runtime, 0,
SNDRV_PCM_HW_PARAM_CHANNELS,
- rule_channels, &runtime->hw,
+ rule_channels, dpcm,
SNDRV_PCM_HW_PARAM_CHANNELS, -1);
if (err < 0)
goto unlock;
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.4/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-4.4/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-4.4/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-4.4/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-4.4/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-4.4/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-4.4/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: aloop: Fix inconsistent format due to incomplete rule
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:
alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.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 b088b53e20c7d09b5ab84c5688e609f478e5c417 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Fri, 5 Jan 2018 16:15:33 +0100
Subject: ALSA: aloop: Fix inconsistent format due to incomplete rule
From: Takashi Iwai <tiwai(a)suse.de>
commit b088b53e20c7d09b5ab84c5688e609f478e5c417 upstream.
The extra hw constraint rule for the formats the aloop driver
introduced has a slight flaw, where it doesn't return a positive value
when the mask got changed. It came from the fact that it's basically
a copy&paste from snd_hw_constraint_mask64(). The original code is
supposed to be a single-shot and it modifies the mask bits only once
and never after, while what we need for aloop is the dynamic hw rule
that limits the mask bits.
This difference results in the inconsistent state, as the hw_refine
doesn't apply the dependencies fully. The worse and surprisingly
result is that it causes a crash in OSS emulation when multiple
full-duplex reads/writes are performed concurrently (I leave why it
triggers Oops to readers as a homework).
For fixing this, replace a few open-codes with the standard
snd_mask_*() macros.
Reported-by: syzbot+3902b5220e8ca27889ca(a)syzkaller.appspotmail.com
Fixes: b1c73fc8e697 ("ALSA: snd-aloop: Fix hw_params restrictions and checking")
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/drivers/aloop.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
--- a/sound/drivers/aloop.c
+++ b/sound/drivers/aloop.c
@@ -39,6 +39,7 @@
#include <sound/core.h>
#include <sound/control.h>
#include <sound/pcm.h>
+#include <sound/pcm_params.h>
#include <sound/info.h>
#include <sound/initval.h>
@@ -622,14 +623,12 @@ static int rule_format(struct snd_pcm_hw
{
struct snd_pcm_hardware *hw = rule->private;
- struct snd_mask *maskp = hw_param_mask(params, rule->var);
+ struct snd_mask m;
- maskp->bits[0] &= (u_int32_t)hw->formats;
- maskp->bits[1] &= (u_int32_t)(hw->formats >> 32);
- memset(maskp->bits + 2, 0, (SNDRV_MASK_MAX-64) / 8); /* clear rest */
- if (! maskp->bits[0] && ! maskp->bits[1])
- return -EINVAL;
- return 0;
+ snd_mask_none(&m);
+ m.bits[0] = (u_int32_t)hw->formats;
+ m.bits[1] = (u_int32_t)(hw->formats >> 32);
+ return snd_mask_refine(hw_param_mask(params, rule->var), &m);
}
static int rule_rate(struct snd_pcm_hw_params *params,
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.4/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-4.4/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-4.4/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-4.4/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-4.4/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-4.4/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-4.4/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Workaround for weird PulseAudio behavior on rewind error
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-pcm-workaround-for-weird-pulseaudio-behavior-on-rewind-error.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From fb51f1cd06f9ced7b7085a2a4636375d520431ca Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Wed, 3 Jan 2018 15:16:30 +0100
Subject: ALSA: pcm: Workaround for weird PulseAudio behavior on rewind error
From: Takashi Iwai <tiwai(a)suse.de>
commit fb51f1cd06f9ced7b7085a2a4636375d520431ca upstream.
The commit 9027c4639ef1 ("ALSA: pcm: Call ack() whenever appl_ptr is
updated") introduced the possible error code returned from the PCM
rewind ioctl. Basically the change was for handling the indirect PCM
more correctly, but ironically, it caused rather a side-effect:
PulseAudio gets pissed off when receiving an error from rewind, throws
everything away and stops processing further, resulting in the
silence.
It's clearly a failure in the application side, so the best would be
to fix that bug in PA. OTOH, PA is mostly the only user of the rewind
feature, so it's not good to slap the sole customer.
This patch tries to mitigate the situation: instead of returning an
error, now the rewind ioctl returns zero when the driver can't rewind.
It indicates that no rewind was performed, so the behavior is
consistent, at least.
Fixes: 9027c4639ef1 ("ALSA: pcm: Call ack() whenever appl_ptr is updated")
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/pcm_native.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -2582,7 +2582,7 @@ static snd_pcm_sframes_t forward_appl_pt
return ret < 0 ? ret : frames;
}
-/* decrease the appl_ptr; returns the processed frames or a negative error */
+/* decrease the appl_ptr; returns the processed frames or zero for error */
static snd_pcm_sframes_t rewind_appl_ptr(struct snd_pcm_substream *substream,
snd_pcm_uframes_t frames,
snd_pcm_sframes_t avail)
@@ -2599,7 +2599,12 @@ static snd_pcm_sframes_t rewind_appl_ptr
if (appl_ptr < 0)
appl_ptr += runtime->boundary;
ret = pcm_lib_apply_appl_ptr(substream, appl_ptr);
- return ret < 0 ? ret : frames;
+ /* NOTE: we return zero for errors because PulseAudio gets depressed
+ * upon receiving an error from rewind ioctl and stops processing
+ * any longer. Returning zero means that no rewind is done, so
+ * it's not absolutely wrong to answer like that.
+ */
+ return ret < 0 ? 0 : frames;
}
static snd_pcm_sframes_t snd_pcm_playback_rewind(struct snd_pcm_substream *substream,
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.14/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-4.14/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-4.14/alsa-pcm-workaround-for-weird-pulseaudio-behavior-on-rewind-error.patch
queue-4.14/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-4.14/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-4.14/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-4.14/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-4.14/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Remove incorrect snd_BUG_ON() usages
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:
alsa-pcm-remove-incorrect-snd_bug_on-usages.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 fe08f34d066f4404934a509b6806db1a4f700c86 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Mon, 1 Jan 2018 09:50:50 +0100
Subject: ALSA: pcm: Remove incorrect snd_BUG_ON() usages
From: Takashi Iwai <tiwai(a)suse.de>
commit fe08f34d066f4404934a509b6806db1a4f700c86 upstream.
syzkaller triggered kernel warnings through PCM OSS emulation at
closing a stream:
WARNING: CPU: 0 PID: 3502 at sound/core/pcm_lib.c:1635
snd_pcm_hw_param_first+0x289/0x690 sound/core/pcm_lib.c:1635
Call Trace:
....
snd_pcm_hw_param_near.constprop.27+0x78d/0x9a0 sound/core/oss/pcm_oss.c:457
snd_pcm_oss_change_params+0x17d3/0x3720 sound/core/oss/pcm_oss.c:969
snd_pcm_oss_make_ready+0xaa/0x130 sound/core/oss/pcm_oss.c:1128
snd_pcm_oss_sync+0x257/0x830 sound/core/oss/pcm_oss.c:1638
snd_pcm_oss_release+0x20b/0x280 sound/core/oss/pcm_oss.c:2431
__fput+0x327/0x7e0 fs/file_table.c:210
....
This happens while it tries to open and set up the aloop device
concurrently. The warning above (invoked from snd_BUG_ON() macro) is
to detect the unexpected logical error where snd_pcm_hw_refine() call
shouldn't fail. The theory is true for the case where the hw_params
config rules are static. But for an aloop device, the hw_params rule
condition does vary dynamically depending on the connected target;
when another device is opened and changes the parameters, the device
connected in another side is also affected, and it caused the error
from snd_pcm_hw_refine().
That is, the simplest "solution" for this is to remove the incorrect
assumption of static rules, and treat such an error as a normal error
path. As there are a couple of other places using snd_BUG_ON()
incorrectly, this patch removes these spurious snd_BUG_ON() calls.
Reported-by: syzbot+6f11c7e2a1b91d466432(a)syzkaller.appspotmail.com
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/oss/pcm_oss.c | 1 -
sound/core/pcm_lib.c | 4 ++--
2 files changed, 2 insertions(+), 3 deletions(-)
--- a/sound/core/oss/pcm_oss.c
+++ b/sound/core/oss/pcm_oss.c
@@ -455,7 +455,6 @@ static int snd_pcm_hw_param_near(struct
v = snd_pcm_hw_param_last(pcm, params, var, dir);
else
v = snd_pcm_hw_param_first(pcm, params, var, dir);
- snd_BUG_ON(v < 0);
return v;
}
--- a/sound/core/pcm_lib.c
+++ b/sound/core/pcm_lib.c
@@ -1632,7 +1632,7 @@ int snd_pcm_hw_param_first(struct snd_pc
return changed;
if (params->rmask) {
int err = snd_pcm_hw_refine(pcm, params);
- if (snd_BUG_ON(err < 0))
+ if (err < 0)
return err;
}
return snd_pcm_hw_param_value(params, var, dir);
@@ -1678,7 +1678,7 @@ int snd_pcm_hw_param_last(struct snd_pcm
return changed;
if (params->rmask) {
int err = snd_pcm_hw_refine(pcm, params);
- if (snd_BUG_ON(err < 0))
+ if (err < 0)
return err;
}
return snd_pcm_hw_param_value(params, var, dir);
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.14/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-4.14/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-4.14/alsa-pcm-workaround-for-weird-pulseaudio-behavior-on-rewind-error.patch
queue-4.14/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-4.14/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-4.14/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-4.14/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-4.14/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Allow aborting mutex lock at OSS read/write loops
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:
alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.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 900498a34a3ac9c611e9b425094c8106bdd7dc1c Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Mon, 8 Jan 2018 14:03:53 +0100
Subject: ALSA: pcm: Allow aborting mutex lock at OSS read/write loops
From: Takashi Iwai <tiwai(a)suse.de>
commit 900498a34a3ac9c611e9b425094c8106bdd7dc1c upstream.
PCM OSS read/write loops keep taking the mutex lock for the whole
read/write, and this might take very long when the exceptionally high
amount of data is given. Also, since it invokes with mutex_lock(),
the concurrent read/write becomes unbreakable.
This patch tries to address these issues by replacing mutex_lock()
with mutex_lock_interruptible(), and also splits / re-takes the lock
at each read/write period chunk, so that it can switch the context
more finely if requested.
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/oss/pcm_oss.c | 36 +++++++++++++++++++++---------------
1 file changed, 21 insertions(+), 15 deletions(-)
--- a/sound/core/oss/pcm_oss.c
+++ b/sound/core/oss/pcm_oss.c
@@ -1334,8 +1334,11 @@ static ssize_t snd_pcm_oss_write1(struct
if ((tmp = snd_pcm_oss_make_ready(substream)) < 0)
return tmp;
- mutex_lock(&runtime->oss.params_lock);
while (bytes > 0) {
+ if (mutex_lock_interruptible(&runtime->oss.params_lock)) {
+ tmp = -ERESTARTSYS;
+ break;
+ }
if (bytes < runtime->oss.period_bytes || runtime->oss.buffer_used > 0) {
tmp = bytes;
if (tmp + runtime->oss.buffer_used > runtime->oss.period_bytes)
@@ -1379,18 +1382,18 @@ static ssize_t snd_pcm_oss_write1(struct
xfer += tmp;
if ((substream->f_flags & O_NONBLOCK) != 0 &&
tmp != runtime->oss.period_bytes)
- break;
+ tmp = -EAGAIN;
}
+ err:
+ mutex_unlock(&runtime->oss.params_lock);
+ if (tmp < 0)
+ break;
if (signal_pending(current)) {
tmp = -ERESTARTSYS;
- goto err;
+ break;
}
+ tmp = 0;
}
- mutex_unlock(&runtime->oss.params_lock);
- return xfer;
-
- err:
- mutex_unlock(&runtime->oss.params_lock);
return xfer > 0 ? (snd_pcm_sframes_t)xfer : tmp;
}
@@ -1438,8 +1441,11 @@ static ssize_t snd_pcm_oss_read1(struct
if ((tmp = snd_pcm_oss_make_ready(substream)) < 0)
return tmp;
- mutex_lock(&runtime->oss.params_lock);
while (bytes > 0) {
+ if (mutex_lock_interruptible(&runtime->oss.params_lock)) {
+ tmp = -ERESTARTSYS;
+ break;
+ }
if (bytes < runtime->oss.period_bytes || runtime->oss.buffer_used > 0) {
if (runtime->oss.buffer_used == 0) {
tmp = snd_pcm_oss_read2(substream, runtime->oss.buffer, runtime->oss.period_bytes, 1);
@@ -1470,16 +1476,16 @@ static ssize_t snd_pcm_oss_read1(struct
bytes -= tmp;
xfer += tmp;
}
+ err:
+ mutex_unlock(&runtime->oss.params_lock);
+ if (tmp < 0)
+ break;
if (signal_pending(current)) {
tmp = -ERESTARTSYS;
- goto err;
+ break;
}
+ tmp = 0;
}
- mutex_unlock(&runtime->oss.params_lock);
- return xfer;
-
- err:
- mutex_unlock(&runtime->oss.params_lock);
return xfer > 0 ? (snd_pcm_sframes_t)xfer : tmp;
}
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.14/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-4.14/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-4.14/alsa-pcm-workaround-for-weird-pulseaudio-behavior-on-rewind-error.patch
queue-4.14/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-4.14/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-4.14/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-4.14/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-4.14/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: aloop: Release cable upon open error path
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-aloop-release-cable-upon-open-error-path.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 9685347aa0a5c2869058ca6ab79fd8e93084a67f Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Fri, 5 Jan 2018 16:09:47 +0100
Subject: ALSA: aloop: Release cable upon open error path
From: Takashi Iwai <tiwai(a)suse.de>
commit 9685347aa0a5c2869058ca6ab79fd8e93084a67f upstream.
The aloop runtime object and its assignment in the cable are left even
when opening a substream fails. This doesn't mean any memory leak,
but it still keeps the invalid pointer that may be referred by the
another side of the cable spontaneously, which is a potential Oops
cause.
Clean up the cable assignment and the empty cable upon the error path
properly.
Fixes: 597603d615d2 ("ALSA: introduce the snd-aloop module for the PCM loopback")
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/drivers/aloop.c | 38 +++++++++++++++++++++++++-------------
1 file changed, 25 insertions(+), 13 deletions(-)
--- a/sound/drivers/aloop.c
+++ b/sound/drivers/aloop.c
@@ -658,12 +658,31 @@ static int rule_channels(struct snd_pcm_
return snd_interval_refine(hw_param_interval(params, rule->var), &t);
}
+static void free_cable(struct snd_pcm_substream *substream)
+{
+ struct loopback *loopback = substream->private_data;
+ int dev = get_cable_index(substream);
+ struct loopback_cable *cable;
+
+ cable = loopback->cables[substream->number][dev];
+ if (!cable)
+ return;
+ if (cable->streams[!substream->stream]) {
+ /* other stream is still alive */
+ cable->streams[substream->stream] = NULL;
+ } else {
+ /* free the cable */
+ loopback->cables[substream->number][dev] = NULL;
+ kfree(cable);
+ }
+}
+
static int loopback_open(struct snd_pcm_substream *substream)
{
struct snd_pcm_runtime *runtime = substream->runtime;
struct loopback *loopback = substream->private_data;
struct loopback_pcm *dpcm;
- struct loopback_cable *cable;
+ struct loopback_cable *cable = NULL;
int err = 0;
int dev = get_cable_index(substream);
@@ -682,7 +701,6 @@ static int loopback_open(struct snd_pcm_
if (!cable) {
cable = kzalloc(sizeof(*cable), GFP_KERNEL);
if (!cable) {
- kfree(dpcm);
err = -ENOMEM;
goto unlock;
}
@@ -724,6 +742,10 @@ static int loopback_open(struct snd_pcm_
else
runtime->hw = cable->hw;
unlock:
+ if (err < 0) {
+ free_cable(substream);
+ kfree(dpcm);
+ }
mutex_unlock(&loopback->cable_lock);
return err;
}
@@ -732,20 +754,10 @@ static int loopback_close(struct snd_pcm
{
struct loopback *loopback = substream->private_data;
struct loopback_pcm *dpcm = substream->runtime->private_data;
- struct loopback_cable *cable;
- int dev = get_cable_index(substream);
loopback_timer_stop(dpcm);
mutex_lock(&loopback->cable_lock);
- cable = loopback->cables[substream->number][dev];
- if (cable->streams[!substream->stream]) {
- /* other stream is still alive */
- cable->streams[substream->stream] = NULL;
- } else {
- /* free the cable */
- loopback->cables[substream->number][dev] = NULL;
- kfree(cable);
- }
+ free_cable(substream);
mutex_unlock(&loopback->cable_lock);
return 0;
}
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.14/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-4.14/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-4.14/alsa-pcm-workaround-for-weird-pulseaudio-behavior-on-rewind-error.patch
queue-4.14/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-4.14/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-4.14/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-4.14/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-4.14/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Add missing error checks in OSS emulation plugin builder
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:
alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.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 6708913750344a900f2e73bfe4a4d6dbbce4fe8d Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Thu, 4 Jan 2018 16:39:27 +0100
Subject: ALSA: pcm: Add missing error checks in OSS emulation plugin builder
From: Takashi Iwai <tiwai(a)suse.de>
commit 6708913750344a900f2e73bfe4a4d6dbbce4fe8d upstream.
In the OSS emulation plugin builder where the frame size is parsed in
the plugin chain, some places miss the possible errors returned from
the plugin src_ or dst_frames callback.
This patch papers over such places.
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/oss/pcm_plugin.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
--- a/sound/core/oss/pcm_plugin.c
+++ b/sound/core/oss/pcm_plugin.c
@@ -592,18 +592,26 @@ snd_pcm_sframes_t snd_pcm_plug_write_tra
snd_pcm_sframes_t frames = size;
plugin = snd_pcm_plug_first(plug);
- while (plugin && frames > 0) {
+ while (plugin) {
+ if (frames <= 0)
+ return frames;
if ((next = plugin->next) != NULL) {
snd_pcm_sframes_t frames1 = frames;
- if (plugin->dst_frames)
+ if (plugin->dst_frames) {
frames1 = plugin->dst_frames(plugin, frames);
+ if (frames1 <= 0)
+ return frames1;
+ }
if ((err = next->client_channels(next, frames1, &dst_channels)) < 0) {
return err;
}
if (err != frames1) {
frames = err;
- if (plugin->src_frames)
+ if (plugin->src_frames) {
frames = plugin->src_frames(plugin, frames1);
+ if (frames <= 0)
+ return frames;
+ }
}
} else
dst_channels = NULL;
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.14/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-4.14/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-4.14/alsa-pcm-workaround-for-weird-pulseaudio-behavior-on-rewind-error.patch
queue-4.14/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-4.14/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-4.14/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-4.14/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-4.14/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Abort properly at pending signal in OSS read/write loops
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:
alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.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 29159a4ed7044c52e3e2cf1a9fb55cec4745c60b Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Mon, 8 Jan 2018 13:58:31 +0100
Subject: ALSA: pcm: Abort properly at pending signal in OSS read/write loops
From: Takashi Iwai <tiwai(a)suse.de>
commit 29159a4ed7044c52e3e2cf1a9fb55cec4745c60b upstream.
The loops for read and write in PCM OSS emulation have no proper check
of pending signals, and they keep processing even after user tries to
break. This results in a very long delay, often seen as RCU stall
when a huge unprocessed bytes remain queued. The bug could be easily
triggered by syzkaller.
As a simple workaround, this patch adds the proper check of pending
signals and aborts the loop appropriately.
Reported-by: syzbot+993cb4cfcbbff3947c21(a)syzkaller.appspotmail.com
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/oss/pcm_oss.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/sound/core/oss/pcm_oss.c
+++ b/sound/core/oss/pcm_oss.c
@@ -1381,6 +1381,10 @@ static ssize_t snd_pcm_oss_write1(struct
tmp != runtime->oss.period_bytes)
break;
}
+ if (signal_pending(current)) {
+ tmp = -ERESTARTSYS;
+ goto err;
+ }
}
mutex_unlock(&runtime->oss.params_lock);
return xfer;
@@ -1466,6 +1470,10 @@ static ssize_t snd_pcm_oss_read1(struct
bytes -= tmp;
xfer += tmp;
}
+ if (signal_pending(current)) {
+ tmp = -ERESTARTSYS;
+ goto err;
+ }
}
mutex_unlock(&runtime->oss.params_lock);
return xfer;
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.14/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-4.14/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-4.14/alsa-pcm-workaround-for-weird-pulseaudio-behavior-on-rewind-error.patch
queue-4.14/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-4.14/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-4.14/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-4.14/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-4.14/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: aloop: Fix racy hw constraints adjustment
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:
alsa-aloop-fix-racy-hw-constraints-adjustment.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 898dfe4687f460ba337a01c11549f87269a13fa2 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Thu, 4 Jan 2018 17:38:54 +0100
Subject: ALSA: aloop: Fix racy hw constraints adjustment
From: Takashi Iwai <tiwai(a)suse.de>
commit 898dfe4687f460ba337a01c11549f87269a13fa2 upstream.
The aloop driver tries to update the hw constraints of the connected
target on the cable of the opened PCM substream. This is done by
adding the extra hw constraints rules referring to the substream
runtime->hw fields, while the other substream may update the runtime
hw of another side on the fly.
This is, however, racy and may result in the inconsistent values when
both PCM streams perform the prepare concurrently. One of the reason
is that it overwrites the other's runtime->hw field; which is not only
racy but also broken when it's called before the open of another side
finishes. And, since the reference to runtime->hw isn't protected,
the concurrent write may give the partial value update and become
inconsistent.
This patch is an attempt to fix and clean up:
- The prepare doesn't change the runtime->hw of other side any longer,
but only update the cable->hw that is referred commonly.
- The extra rules refer to the loopback_pcm object instead of the
runtime->hw. The actual hw is deduced from cable->hw.
- The extra rules take the cable_lock to protect against the race.
Fixes: b1c73fc8e697 ("ALSA: snd-aloop: Fix hw_params restrictions and checking")
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/drivers/aloop.c | 51 ++++++++++++++++++++------------------------------
1 file changed, 21 insertions(+), 30 deletions(-)
--- a/sound/drivers/aloop.c
+++ b/sound/drivers/aloop.c
@@ -306,19 +306,6 @@ static int loopback_trigger(struct snd_p
return 0;
}
-static void params_change_substream(struct loopback_pcm *dpcm,
- struct snd_pcm_runtime *runtime)
-{
- struct snd_pcm_runtime *dst_runtime;
-
- if (dpcm == NULL || dpcm->substream == NULL)
- return;
- dst_runtime = dpcm->substream->runtime;
- if (dst_runtime == NULL)
- return;
- dst_runtime->hw = dpcm->cable->hw;
-}
-
static void params_change(struct snd_pcm_substream *substream)
{
struct snd_pcm_runtime *runtime = substream->runtime;
@@ -330,10 +317,6 @@ static void params_change(struct snd_pcm
cable->hw.rate_max = runtime->rate;
cable->hw.channels_min = runtime->channels;
cable->hw.channels_max = runtime->channels;
- params_change_substream(cable->streams[SNDRV_PCM_STREAM_PLAYBACK],
- runtime);
- params_change_substream(cable->streams[SNDRV_PCM_STREAM_CAPTURE],
- runtime);
}
static int loopback_prepare(struct snd_pcm_substream *substream)
@@ -621,24 +604,29 @@ static unsigned int get_cable_index(stru
static int rule_format(struct snd_pcm_hw_params *params,
struct snd_pcm_hw_rule *rule)
{
-
- struct snd_pcm_hardware *hw = rule->private;
+ struct loopback_pcm *dpcm = rule->private;
+ struct loopback_cable *cable = dpcm->cable;
struct snd_mask m;
snd_mask_none(&m);
- m.bits[0] = (u_int32_t)hw->formats;
- m.bits[1] = (u_int32_t)(hw->formats >> 32);
+ mutex_lock(&dpcm->loopback->cable_lock);
+ m.bits[0] = (u_int32_t)cable->hw.formats;
+ m.bits[1] = (u_int32_t)(cable->hw.formats >> 32);
+ mutex_unlock(&dpcm->loopback->cable_lock);
return snd_mask_refine(hw_param_mask(params, rule->var), &m);
}
static int rule_rate(struct snd_pcm_hw_params *params,
struct snd_pcm_hw_rule *rule)
{
- struct snd_pcm_hardware *hw = rule->private;
+ struct loopback_pcm *dpcm = rule->private;
+ struct loopback_cable *cable = dpcm->cable;
struct snd_interval t;
- t.min = hw->rate_min;
- t.max = hw->rate_max;
+ mutex_lock(&dpcm->loopback->cable_lock);
+ t.min = cable->hw.rate_min;
+ t.max = cable->hw.rate_max;
+ mutex_unlock(&dpcm->loopback->cable_lock);
t.openmin = t.openmax = 0;
t.integer = 0;
return snd_interval_refine(hw_param_interval(params, rule->var), &t);
@@ -647,11 +635,14 @@ static int rule_rate(struct snd_pcm_hw_p
static int rule_channels(struct snd_pcm_hw_params *params,
struct snd_pcm_hw_rule *rule)
{
- struct snd_pcm_hardware *hw = rule->private;
+ struct loopback_pcm *dpcm = rule->private;
+ struct loopback_cable *cable = dpcm->cable;
struct snd_interval t;
- t.min = hw->channels_min;
- t.max = hw->channels_max;
+ mutex_lock(&dpcm->loopback->cable_lock);
+ t.min = cable->hw.channels_min;
+ t.max = cable->hw.channels_max;
+ mutex_unlock(&dpcm->loopback->cable_lock);
t.openmin = t.openmax = 0;
t.integer = 0;
return snd_interval_refine(hw_param_interval(params, rule->var), &t);
@@ -717,19 +708,19 @@ static int loopback_open(struct snd_pcm_
/* are cached -> they do not reflect the actual state */
err = snd_pcm_hw_rule_add(runtime, 0,
SNDRV_PCM_HW_PARAM_FORMAT,
- rule_format, &runtime->hw,
+ rule_format, dpcm,
SNDRV_PCM_HW_PARAM_FORMAT, -1);
if (err < 0)
goto unlock;
err = snd_pcm_hw_rule_add(runtime, 0,
SNDRV_PCM_HW_PARAM_RATE,
- rule_rate, &runtime->hw,
+ rule_rate, dpcm,
SNDRV_PCM_HW_PARAM_RATE, -1);
if (err < 0)
goto unlock;
err = snd_pcm_hw_rule_add(runtime, 0,
SNDRV_PCM_HW_PARAM_CHANNELS,
- rule_channels, &runtime->hw,
+ rule_channels, dpcm,
SNDRV_PCM_HW_PARAM_CHANNELS, -1);
if (err < 0)
goto unlock;
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.14/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-4.14/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-4.14/alsa-pcm-workaround-for-weird-pulseaudio-behavior-on-rewind-error.patch
queue-4.14/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-4.14/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-4.14/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-4.14/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-4.14/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: aloop: Fix inconsistent format due to incomplete rule
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:
alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.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 b088b53e20c7d09b5ab84c5688e609f478e5c417 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Fri, 5 Jan 2018 16:15:33 +0100
Subject: ALSA: aloop: Fix inconsistent format due to incomplete rule
From: Takashi Iwai <tiwai(a)suse.de>
commit b088b53e20c7d09b5ab84c5688e609f478e5c417 upstream.
The extra hw constraint rule for the formats the aloop driver
introduced has a slight flaw, where it doesn't return a positive value
when the mask got changed. It came from the fact that it's basically
a copy&paste from snd_hw_constraint_mask64(). The original code is
supposed to be a single-shot and it modifies the mask bits only once
and never after, while what we need for aloop is the dynamic hw rule
that limits the mask bits.
This difference results in the inconsistent state, as the hw_refine
doesn't apply the dependencies fully. The worse and surprisingly
result is that it causes a crash in OSS emulation when multiple
full-duplex reads/writes are performed concurrently (I leave why it
triggers Oops to readers as a homework).
For fixing this, replace a few open-codes with the standard
snd_mask_*() macros.
Reported-by: syzbot+3902b5220e8ca27889ca(a)syzkaller.appspotmail.com
Fixes: b1c73fc8e697 ("ALSA: snd-aloop: Fix hw_params restrictions and checking")
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/drivers/aloop.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
--- a/sound/drivers/aloop.c
+++ b/sound/drivers/aloop.c
@@ -39,6 +39,7 @@
#include <sound/core.h>
#include <sound/control.h>
#include <sound/pcm.h>
+#include <sound/pcm_params.h>
#include <sound/info.h>
#include <sound/initval.h>
@@ -622,14 +623,12 @@ static int rule_format(struct snd_pcm_hw
{
struct snd_pcm_hardware *hw = rule->private;
- struct snd_mask *maskp = hw_param_mask(params, rule->var);
+ struct snd_mask m;
- maskp->bits[0] &= (u_int32_t)hw->formats;
- maskp->bits[1] &= (u_int32_t)(hw->formats >> 32);
- memset(maskp->bits + 2, 0, (SNDRV_MASK_MAX-64) / 8); /* clear rest */
- if (! maskp->bits[0] && ! maskp->bits[1])
- return -EINVAL;
- return 0;
+ snd_mask_none(&m);
+ m.bits[0] = (u_int32_t)hw->formats;
+ m.bits[1] = (u_int32_t)(hw->formats >> 32);
+ return snd_mask_refine(hw_param_mask(params, rule->var), &m);
}
static int rule_rate(struct snd_pcm_hw_params *params,
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.14/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-4.14/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-4.14/alsa-pcm-workaround-for-weird-pulseaudio-behavior-on-rewind-error.patch
queue-4.14/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-4.14/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-4.14/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-4.14/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-4.14/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Remove incorrect snd_BUG_ON() usages
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:
alsa-pcm-remove-incorrect-snd_bug_on-usages.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 fe08f34d066f4404934a509b6806db1a4f700c86 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Mon, 1 Jan 2018 09:50:50 +0100
Subject: ALSA: pcm: Remove incorrect snd_BUG_ON() usages
From: Takashi Iwai <tiwai(a)suse.de>
commit fe08f34d066f4404934a509b6806db1a4f700c86 upstream.
syzkaller triggered kernel warnings through PCM OSS emulation at
closing a stream:
WARNING: CPU: 0 PID: 3502 at sound/core/pcm_lib.c:1635
snd_pcm_hw_param_first+0x289/0x690 sound/core/pcm_lib.c:1635
Call Trace:
....
snd_pcm_hw_param_near.constprop.27+0x78d/0x9a0 sound/core/oss/pcm_oss.c:457
snd_pcm_oss_change_params+0x17d3/0x3720 sound/core/oss/pcm_oss.c:969
snd_pcm_oss_make_ready+0xaa/0x130 sound/core/oss/pcm_oss.c:1128
snd_pcm_oss_sync+0x257/0x830 sound/core/oss/pcm_oss.c:1638
snd_pcm_oss_release+0x20b/0x280 sound/core/oss/pcm_oss.c:2431
__fput+0x327/0x7e0 fs/file_table.c:210
....
This happens while it tries to open and set up the aloop device
concurrently. The warning above (invoked from snd_BUG_ON() macro) is
to detect the unexpected logical error where snd_pcm_hw_refine() call
shouldn't fail. The theory is true for the case where the hw_params
config rules are static. But for an aloop device, the hw_params rule
condition does vary dynamically depending on the connected target;
when another device is opened and changes the parameters, the device
connected in another side is also affected, and it caused the error
from snd_pcm_hw_refine().
That is, the simplest "solution" for this is to remove the incorrect
assumption of static rules, and treat such an error as a normal error
path. As there are a couple of other places using snd_BUG_ON()
incorrectly, this patch removes these spurious snd_BUG_ON() calls.
Reported-by: syzbot+6f11c7e2a1b91d466432(a)syzkaller.appspotmail.com
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/oss/pcm_oss.c | 1 -
sound/core/pcm_lib.c | 4 ++--
2 files changed, 2 insertions(+), 3 deletions(-)
--- a/sound/core/oss/pcm_oss.c
+++ b/sound/core/oss/pcm_oss.c
@@ -465,7 +465,6 @@ static int snd_pcm_hw_param_near(struct
v = snd_pcm_hw_param_last(pcm, params, var, dir);
else
v = snd_pcm_hw_param_first(pcm, params, var, dir);
- snd_BUG_ON(v < 0);
return v;
}
--- a/sound/core/pcm_lib.c
+++ b/sound/core/pcm_lib.c
@@ -1633,7 +1633,7 @@ int snd_pcm_hw_param_first(struct snd_pc
return changed;
if (params->rmask) {
int err = snd_pcm_hw_refine(pcm, params);
- if (snd_BUG_ON(err < 0))
+ if (err < 0)
return err;
}
return snd_pcm_hw_param_value(params, var, dir);
@@ -1680,7 +1680,7 @@ int snd_pcm_hw_param_last(struct snd_pcm
return changed;
if (params->rmask) {
int err = snd_pcm_hw_refine(pcm, params);
- if (snd_BUG_ON(err < 0))
+ if (err < 0)
return err;
}
return snd_pcm_hw_param_value(params, var, dir);
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-3.18/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-3.18/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-3.18/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-3.18/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-3.18/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-3.18/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-3.18/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Add missing error checks in OSS emulation plugin builder
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:
alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.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 6708913750344a900f2e73bfe4a4d6dbbce4fe8d Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Thu, 4 Jan 2018 16:39:27 +0100
Subject: ALSA: pcm: Add missing error checks in OSS emulation plugin builder
From: Takashi Iwai <tiwai(a)suse.de>
commit 6708913750344a900f2e73bfe4a4d6dbbce4fe8d upstream.
In the OSS emulation plugin builder where the frame size is parsed in
the plugin chain, some places miss the possible errors returned from
the plugin src_ or dst_frames callback.
This patch papers over such places.
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/oss/pcm_plugin.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
--- a/sound/core/oss/pcm_plugin.c
+++ b/sound/core/oss/pcm_plugin.c
@@ -591,18 +591,26 @@ snd_pcm_sframes_t snd_pcm_plug_write_tra
snd_pcm_sframes_t frames = size;
plugin = snd_pcm_plug_first(plug);
- while (plugin && frames > 0) {
+ while (plugin) {
+ if (frames <= 0)
+ return frames;
if ((next = plugin->next) != NULL) {
snd_pcm_sframes_t frames1 = frames;
- if (plugin->dst_frames)
+ if (plugin->dst_frames) {
frames1 = plugin->dst_frames(plugin, frames);
+ if (frames1 <= 0)
+ return frames1;
+ }
if ((err = next->client_channels(next, frames1, &dst_channels)) < 0) {
return err;
}
if (err != frames1) {
frames = err;
- if (plugin->src_frames)
+ if (plugin->src_frames) {
frames = plugin->src_frames(plugin, frames1);
+ if (frames <= 0)
+ return frames;
+ }
}
} else
dst_channels = NULL;
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-3.18/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-3.18/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-3.18/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-3.18/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-3.18/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-3.18/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-3.18/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Allow aborting mutex lock at OSS read/write loops
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:
alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.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 900498a34a3ac9c611e9b425094c8106bdd7dc1c Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Mon, 8 Jan 2018 14:03:53 +0100
Subject: ALSA: pcm: Allow aborting mutex lock at OSS read/write loops
From: Takashi Iwai <tiwai(a)suse.de>
commit 900498a34a3ac9c611e9b425094c8106bdd7dc1c upstream.
PCM OSS read/write loops keep taking the mutex lock for the whole
read/write, and this might take very long when the exceptionally high
amount of data is given. Also, since it invokes with mutex_lock(),
the concurrent read/write becomes unbreakable.
This patch tries to address these issues by replacing mutex_lock()
with mutex_lock_interruptible(), and also splits / re-takes the lock
at each read/write period chunk, so that it can switch the context
more finely if requested.
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/oss/pcm_oss.c | 36 +++++++++++++++++++++---------------
1 file changed, 21 insertions(+), 15 deletions(-)
--- a/sound/core/oss/pcm_oss.c
+++ b/sound/core/oss/pcm_oss.c
@@ -1370,8 +1370,11 @@ static ssize_t snd_pcm_oss_write1(struct
if ((tmp = snd_pcm_oss_make_ready(substream)) < 0)
return tmp;
- mutex_lock(&runtime->oss.params_lock);
while (bytes > 0) {
+ if (mutex_lock_interruptible(&runtime->oss.params_lock)) {
+ tmp = -ERESTARTSYS;
+ break;
+ }
if (bytes < runtime->oss.period_bytes || runtime->oss.buffer_used > 0) {
tmp = bytes;
if (tmp + runtime->oss.buffer_used > runtime->oss.period_bytes)
@@ -1415,18 +1418,18 @@ static ssize_t snd_pcm_oss_write1(struct
xfer += tmp;
if ((substream->f_flags & O_NONBLOCK) != 0 &&
tmp != runtime->oss.period_bytes)
- break;
+ tmp = -EAGAIN;
}
+ err:
+ mutex_unlock(&runtime->oss.params_lock);
+ if (tmp < 0)
+ break;
if (signal_pending(current)) {
tmp = -ERESTARTSYS;
- goto err;
+ break;
}
+ tmp = 0;
}
- mutex_unlock(&runtime->oss.params_lock);
- return xfer;
-
- err:
- mutex_unlock(&runtime->oss.params_lock);
return xfer > 0 ? (snd_pcm_sframes_t)xfer : tmp;
}
@@ -1474,8 +1477,11 @@ static ssize_t snd_pcm_oss_read1(struct
if ((tmp = snd_pcm_oss_make_ready(substream)) < 0)
return tmp;
- mutex_lock(&runtime->oss.params_lock);
while (bytes > 0) {
+ if (mutex_lock_interruptible(&runtime->oss.params_lock)) {
+ tmp = -ERESTARTSYS;
+ break;
+ }
if (bytes < runtime->oss.period_bytes || runtime->oss.buffer_used > 0) {
if (runtime->oss.buffer_used == 0) {
tmp = snd_pcm_oss_read2(substream, runtime->oss.buffer, runtime->oss.period_bytes, 1);
@@ -1506,16 +1512,16 @@ static ssize_t snd_pcm_oss_read1(struct
bytes -= tmp;
xfer += tmp;
}
+ err:
+ mutex_unlock(&runtime->oss.params_lock);
+ if (tmp < 0)
+ break;
if (signal_pending(current)) {
tmp = -ERESTARTSYS;
- goto err;
+ break;
}
+ tmp = 0;
}
- mutex_unlock(&runtime->oss.params_lock);
- return xfer;
-
- err:
- mutex_unlock(&runtime->oss.params_lock);
return xfer > 0 ? (snd_pcm_sframes_t)xfer : tmp;
}
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-3.18/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-3.18/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-3.18/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-3.18/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-3.18/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-3.18/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-3.18/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: aloop: Release cable upon open error path
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:
alsa-aloop-release-cable-upon-open-error-path.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 9685347aa0a5c2869058ca6ab79fd8e93084a67f Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Fri, 5 Jan 2018 16:09:47 +0100
Subject: ALSA: aloop: Release cable upon open error path
From: Takashi Iwai <tiwai(a)suse.de>
commit 9685347aa0a5c2869058ca6ab79fd8e93084a67f upstream.
The aloop runtime object and its assignment in the cable are left even
when opening a substream fails. This doesn't mean any memory leak,
but it still keeps the invalid pointer that may be referred by the
another side of the cable spontaneously, which is a potential Oops
cause.
Clean up the cable assignment and the empty cable upon the error path
properly.
Fixes: 597603d615d2 ("ALSA: introduce the snd-aloop module for the PCM loopback")
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/drivers/aloop.c | 38 +++++++++++++++++++++++++-------------
1 file changed, 25 insertions(+), 13 deletions(-)
--- a/sound/drivers/aloop.c
+++ b/sound/drivers/aloop.c
@@ -659,12 +659,31 @@ static int rule_channels(struct snd_pcm_
return snd_interval_refine(hw_param_interval(params, rule->var), &t);
}
+static void free_cable(struct snd_pcm_substream *substream)
+{
+ struct loopback *loopback = substream->private_data;
+ int dev = get_cable_index(substream);
+ struct loopback_cable *cable;
+
+ cable = loopback->cables[substream->number][dev];
+ if (!cable)
+ return;
+ if (cable->streams[!substream->stream]) {
+ /* other stream is still alive */
+ cable->streams[substream->stream] = NULL;
+ } else {
+ /* free the cable */
+ loopback->cables[substream->number][dev] = NULL;
+ kfree(cable);
+ }
+}
+
static int loopback_open(struct snd_pcm_substream *substream)
{
struct snd_pcm_runtime *runtime = substream->runtime;
struct loopback *loopback = substream->private_data;
struct loopback_pcm *dpcm;
- struct loopback_cable *cable;
+ struct loopback_cable *cable = NULL;
int err = 0;
int dev = get_cable_index(substream);
@@ -683,7 +702,6 @@ static int loopback_open(struct snd_pcm_
if (!cable) {
cable = kzalloc(sizeof(*cable), GFP_KERNEL);
if (!cable) {
- kfree(dpcm);
err = -ENOMEM;
goto unlock;
}
@@ -725,6 +743,10 @@ static int loopback_open(struct snd_pcm_
else
runtime->hw = cable->hw;
unlock:
+ if (err < 0) {
+ free_cable(substream);
+ kfree(dpcm);
+ }
mutex_unlock(&loopback->cable_lock);
return err;
}
@@ -733,20 +755,10 @@ static int loopback_close(struct snd_pcm
{
struct loopback *loopback = substream->private_data;
struct loopback_pcm *dpcm = substream->runtime->private_data;
- struct loopback_cable *cable;
- int dev = get_cable_index(substream);
loopback_timer_stop(dpcm);
mutex_lock(&loopback->cable_lock);
- cable = loopback->cables[substream->number][dev];
- if (cable->streams[!substream->stream]) {
- /* other stream is still alive */
- cable->streams[substream->stream] = NULL;
- } else {
- /* free the cable */
- loopback->cables[substream->number][dev] = NULL;
- kfree(cable);
- }
+ free_cable(substream);
mutex_unlock(&loopback->cable_lock);
return 0;
}
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-3.18/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-3.18/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-3.18/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-3.18/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-3.18/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-3.18/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-3.18/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Abort properly at pending signal in OSS read/write loops
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:
alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.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 29159a4ed7044c52e3e2cf1a9fb55cec4745c60b Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Mon, 8 Jan 2018 13:58:31 +0100
Subject: ALSA: pcm: Abort properly at pending signal in OSS read/write loops
From: Takashi Iwai <tiwai(a)suse.de>
commit 29159a4ed7044c52e3e2cf1a9fb55cec4745c60b upstream.
The loops for read and write in PCM OSS emulation have no proper check
of pending signals, and they keep processing even after user tries to
break. This results in a very long delay, often seen as RCU stall
when a huge unprocessed bytes remain queued. The bug could be easily
triggered by syzkaller.
As a simple workaround, this patch adds the proper check of pending
signals and aborts the loop appropriately.
Reported-by: syzbot+993cb4cfcbbff3947c21(a)syzkaller.appspotmail.com
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/oss/pcm_oss.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/sound/core/oss/pcm_oss.c
+++ b/sound/core/oss/pcm_oss.c
@@ -1417,6 +1417,10 @@ static ssize_t snd_pcm_oss_write1(struct
tmp != runtime->oss.period_bytes)
break;
}
+ if (signal_pending(current)) {
+ tmp = -ERESTARTSYS;
+ goto err;
+ }
}
mutex_unlock(&runtime->oss.params_lock);
return xfer;
@@ -1502,6 +1506,10 @@ static ssize_t snd_pcm_oss_read1(struct
bytes -= tmp;
xfer += tmp;
}
+ if (signal_pending(current)) {
+ tmp = -ERESTARTSYS;
+ goto err;
+ }
}
mutex_unlock(&runtime->oss.params_lock);
return xfer;
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-3.18/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-3.18/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-3.18/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-3.18/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-3.18/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-3.18/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-3.18/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: aloop: Fix racy hw constraints adjustment
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:
alsa-aloop-fix-racy-hw-constraints-adjustment.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 898dfe4687f460ba337a01c11549f87269a13fa2 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Thu, 4 Jan 2018 17:38:54 +0100
Subject: ALSA: aloop: Fix racy hw constraints adjustment
From: Takashi Iwai <tiwai(a)suse.de>
commit 898dfe4687f460ba337a01c11549f87269a13fa2 upstream.
The aloop driver tries to update the hw constraints of the connected
target on the cable of the opened PCM substream. This is done by
adding the extra hw constraints rules referring to the substream
runtime->hw fields, while the other substream may update the runtime
hw of another side on the fly.
This is, however, racy and may result in the inconsistent values when
both PCM streams perform the prepare concurrently. One of the reason
is that it overwrites the other's runtime->hw field; which is not only
racy but also broken when it's called before the open of another side
finishes. And, since the reference to runtime->hw isn't protected,
the concurrent write may give the partial value update and become
inconsistent.
This patch is an attempt to fix and clean up:
- The prepare doesn't change the runtime->hw of other side any longer,
but only update the cable->hw that is referred commonly.
- The extra rules refer to the loopback_pcm object instead of the
runtime->hw. The actual hw is deduced from cable->hw.
- The extra rules take the cable_lock to protect against the race.
Fixes: b1c73fc8e697 ("ALSA: snd-aloop: Fix hw_params restrictions and checking")
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/drivers/aloop.c | 51 ++++++++++++++++++++------------------------------
1 file changed, 21 insertions(+), 30 deletions(-)
--- a/sound/drivers/aloop.c
+++ b/sound/drivers/aloop.c
@@ -307,19 +307,6 @@ static int loopback_trigger(struct snd_p
return 0;
}
-static void params_change_substream(struct loopback_pcm *dpcm,
- struct snd_pcm_runtime *runtime)
-{
- struct snd_pcm_runtime *dst_runtime;
-
- if (dpcm == NULL || dpcm->substream == NULL)
- return;
- dst_runtime = dpcm->substream->runtime;
- if (dst_runtime == NULL)
- return;
- dst_runtime->hw = dpcm->cable->hw;
-}
-
static void params_change(struct snd_pcm_substream *substream)
{
struct snd_pcm_runtime *runtime = substream->runtime;
@@ -331,10 +318,6 @@ static void params_change(struct snd_pcm
cable->hw.rate_max = runtime->rate;
cable->hw.channels_min = runtime->channels;
cable->hw.channels_max = runtime->channels;
- params_change_substream(cable->streams[SNDRV_PCM_STREAM_PLAYBACK],
- runtime);
- params_change_substream(cable->streams[SNDRV_PCM_STREAM_CAPTURE],
- runtime);
}
static int loopback_prepare(struct snd_pcm_substream *substream)
@@ -622,24 +605,29 @@ static unsigned int get_cable_index(stru
static int rule_format(struct snd_pcm_hw_params *params,
struct snd_pcm_hw_rule *rule)
{
-
- struct snd_pcm_hardware *hw = rule->private;
+ struct loopback_pcm *dpcm = rule->private;
+ struct loopback_cable *cable = dpcm->cable;
struct snd_mask m;
snd_mask_none(&m);
- m.bits[0] = (u_int32_t)hw->formats;
- m.bits[1] = (u_int32_t)(hw->formats >> 32);
+ mutex_lock(&dpcm->loopback->cable_lock);
+ m.bits[0] = (u_int32_t)cable->hw.formats;
+ m.bits[1] = (u_int32_t)(cable->hw.formats >> 32);
+ mutex_unlock(&dpcm->loopback->cable_lock);
return snd_mask_refine(hw_param_mask(params, rule->var), &m);
}
static int rule_rate(struct snd_pcm_hw_params *params,
struct snd_pcm_hw_rule *rule)
{
- struct snd_pcm_hardware *hw = rule->private;
+ struct loopback_pcm *dpcm = rule->private;
+ struct loopback_cable *cable = dpcm->cable;
struct snd_interval t;
- t.min = hw->rate_min;
- t.max = hw->rate_max;
+ mutex_lock(&dpcm->loopback->cable_lock);
+ t.min = cable->hw.rate_min;
+ t.max = cable->hw.rate_max;
+ mutex_unlock(&dpcm->loopback->cable_lock);
t.openmin = t.openmax = 0;
t.integer = 0;
return snd_interval_refine(hw_param_interval(params, rule->var), &t);
@@ -648,11 +636,14 @@ static int rule_rate(struct snd_pcm_hw_p
static int rule_channels(struct snd_pcm_hw_params *params,
struct snd_pcm_hw_rule *rule)
{
- struct snd_pcm_hardware *hw = rule->private;
+ struct loopback_pcm *dpcm = rule->private;
+ struct loopback_cable *cable = dpcm->cable;
struct snd_interval t;
- t.min = hw->channels_min;
- t.max = hw->channels_max;
+ mutex_lock(&dpcm->loopback->cable_lock);
+ t.min = cable->hw.channels_min;
+ t.max = cable->hw.channels_max;
+ mutex_unlock(&dpcm->loopback->cable_lock);
t.openmin = t.openmax = 0;
t.integer = 0;
return snd_interval_refine(hw_param_interval(params, rule->var), &t);
@@ -718,19 +709,19 @@ static int loopback_open(struct snd_pcm_
/* are cached -> they do not reflect the actual state */
err = snd_pcm_hw_rule_add(runtime, 0,
SNDRV_PCM_HW_PARAM_FORMAT,
- rule_format, &runtime->hw,
+ rule_format, dpcm,
SNDRV_PCM_HW_PARAM_FORMAT, -1);
if (err < 0)
goto unlock;
err = snd_pcm_hw_rule_add(runtime, 0,
SNDRV_PCM_HW_PARAM_RATE,
- rule_rate, &runtime->hw,
+ rule_rate, dpcm,
SNDRV_PCM_HW_PARAM_RATE, -1);
if (err < 0)
goto unlock;
err = snd_pcm_hw_rule_add(runtime, 0,
SNDRV_PCM_HW_PARAM_CHANNELS,
- rule_channels, &runtime->hw,
+ rule_channels, dpcm,
SNDRV_PCM_HW_PARAM_CHANNELS, -1);
if (err < 0)
goto unlock;
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-3.18/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-3.18/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-3.18/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-3.18/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-3.18/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-3.18/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-3.18/alsa-aloop-release-cable-upon-open-error-path.patch
This is a note to let you know that I've just added the patch titled
ALSA: aloop: Fix inconsistent format due to incomplete rule
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:
alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.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 b088b53e20c7d09b5ab84c5688e609f478e5c417 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Fri, 5 Jan 2018 16:15:33 +0100
Subject: ALSA: aloop: Fix inconsistent format due to incomplete rule
From: Takashi Iwai <tiwai(a)suse.de>
commit b088b53e20c7d09b5ab84c5688e609f478e5c417 upstream.
The extra hw constraint rule for the formats the aloop driver
introduced has a slight flaw, where it doesn't return a positive value
when the mask got changed. It came from the fact that it's basically
a copy&paste from snd_hw_constraint_mask64(). The original code is
supposed to be a single-shot and it modifies the mask bits only once
and never after, while what we need for aloop is the dynamic hw rule
that limits the mask bits.
This difference results in the inconsistent state, as the hw_refine
doesn't apply the dependencies fully. The worse and surprisingly
result is that it causes a crash in OSS emulation when multiple
full-duplex reads/writes are performed concurrently (I leave why it
triggers Oops to readers as a homework).
For fixing this, replace a few open-codes with the standard
snd_mask_*() macros.
Reported-by: syzbot+3902b5220e8ca27889ca(a)syzkaller.appspotmail.com
Fixes: b1c73fc8e697 ("ALSA: snd-aloop: Fix hw_params restrictions and checking")
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/drivers/aloop.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
--- a/sound/drivers/aloop.c
+++ b/sound/drivers/aloop.c
@@ -39,6 +39,7 @@
#include <sound/core.h>
#include <sound/control.h>
#include <sound/pcm.h>
+#include <sound/pcm_params.h>
#include <sound/info.h>
#include <sound/initval.h>
@@ -623,14 +624,12 @@ static int rule_format(struct snd_pcm_hw
{
struct snd_pcm_hardware *hw = rule->private;
- struct snd_mask *maskp = hw_param_mask(params, rule->var);
+ struct snd_mask m;
- maskp->bits[0] &= (u_int32_t)hw->formats;
- maskp->bits[1] &= (u_int32_t)(hw->formats >> 32);
- memset(maskp->bits + 2, 0, (SNDRV_MASK_MAX-64) / 8); /* clear rest */
- if (! maskp->bits[0] && ! maskp->bits[1])
- return -EINVAL;
- return 0;
+ snd_mask_none(&m);
+ m.bits[0] = (u_int32_t)hw->formats;
+ m.bits[1] = (u_int32_t)(hw->formats >> 32);
+ return snd_mask_refine(hw_param_mask(params, rule->var), &m);
}
static int rule_rate(struct snd_pcm_hw_params *params,
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-3.18/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch
queue-3.18/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
queue-3.18/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch
queue-3.18/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch
queue-3.18/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch
queue-3.18/alsa-aloop-fix-racy-hw-constraints-adjustment.patch
queue-3.18/alsa-aloop-release-cable-upon-open-error-path.patch
From: Eric Biggers <ebiggers(a)google.com>
pipe-user-pages-hard and pipe-user-pages-soft are only supposed to apply
to unprivileged users, as documented in both Documentation/sysctl/fs.txt
and the pipe(7) man page.
However, the capabilities are actually only checked when increasing a
pipe's size using F_SETPIPE_SZ, not when creating a new pipe.
Therefore, if pipe-user-pages-hard has been set, the root user can run
into it and be unable to create pipes. Similarly, if
pipe-user-pages-soft has been set, the root user can run into it and
have their pipes limited to 1 page each.
Fix this by allowing the privileged override in both cases.
Fixes: 759c01142a5d ("pipe: limit the per-user amount of pages allocated in pipes")
Cc: stable(a)vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
---
fs/pipe.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/fs/pipe.c b/fs/pipe.c
index d0dec5e7ef33..847ecc388820 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -613,6 +613,11 @@ static bool too_many_pipe_buffers_hard(unsigned long user_bufs)
return pipe_user_pages_hard && user_bufs >= pipe_user_pages_hard;
}
+static bool is_unprivileged_user(void)
+{
+ return !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN);
+}
+
struct pipe_inode_info *alloc_pipe_info(void)
{
struct pipe_inode_info *pipe;
@@ -629,12 +634,12 @@ struct pipe_inode_info *alloc_pipe_info(void)
user_bufs = account_pipe_buffers(user, 0, pipe_bufs);
- if (too_many_pipe_buffers_soft(user_bufs)) {
+ if (too_many_pipe_buffers_soft(user_bufs) && is_unprivileged_user()) {
user_bufs = account_pipe_buffers(user, pipe_bufs, 1);
pipe_bufs = 1;
}
- if (too_many_pipe_buffers_hard(user_bufs))
+ if (too_many_pipe_buffers_hard(user_bufs) && is_unprivileged_user())
goto out_revert_acct;
pipe->bufs = kcalloc(pipe_bufs, sizeof(struct pipe_buffer),
@@ -1065,7 +1070,7 @@ static long pipe_set_size(struct pipe_inode_info *pipe, unsigned long arg)
if (nr_pages > pipe->buffers &&
(too_many_pipe_buffers_hard(user_bufs) ||
too_many_pipe_buffers_soft(user_bufs)) &&
- !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN)) {
+ is_unprivileged_user()) {
ret = -EPERM;
goto out_revert_acct;
}
--
2.15.1
Complement commit c23b3d1a5311 ("MIPS: ptrace: Change GP regset to use
correct core dump register layout") and also reject outsized
PTRACE_SETREGSET requests to the NT_PRFPREG regset, like with the
NT_PRSTATUS regset.
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: c23b3d1a5311 ("MIPS: ptrace: Change GP regset to use correct core dump register layout")
Cc: James Hogan <james.hogan(a)mips.com>
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Alex Smith <alex(a)alex-smith.me.uk>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Cc: stable(a)vger.kernel.org # v3.17+
Patchwork: https://patchwork.linux-mips.org/patch/17930/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
---
Hi,
This is a (mechanically regenerated) version of commit c8c5a3a24d39 for
3.18-stable and before. No functional changes. Please apply.
Maciej
---
arch/mips/kernel/ptrace.c | 3 +++
1 file changed, 3 insertions(+)
linux-mips-nt-prfpreg-size.diff
Index: linux-stable-el/arch/mips/kernel/ptrace.c
===================================================================
--- linux-stable-el.orig/arch/mips/kernel/ptrace.c 2018-01-10 20:11:52.000000000 +0000
+++ linux-stable-el/arch/mips/kernel/ptrace.c 2018-01-10 20:13:16.212944000 +0000
@@ -530,6 +530,9 @@ static int fpr_set(struct task_struct *t
BUG_ON(count % sizeof(elf_fpreg_t));
+ if (pos + count > sizeof(elf_fpregset_t))
+ return -EIO;
+
if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t))
err = fpr_set_fpa(target, &pos, &count, &kbuf, &ubuf);
else
Fix a commit 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for
FP regset") public API regression, then activated by commit 1db1af84d6df
("MIPS: Basic MSA context switching support"), that caused the FCSR
register not to be read or written for CONFIG_CPU_HAS_MSA kernel
configurations (regardless of actual presence or absence of the MSA
feature in a given processor) with ptrace(2) PTRACE_GETREGSET and
PTRACE_SETREGSET requests nor recorded in core dumps.
This is because with !CONFIG_CPU_HAS_MSA configurations the whole of
`elf_fpregset_t' array is bulk-copied as it is, which includes the FCSR
in one half of the last, 33rd slot, whereas with CONFIG_CPU_HAS_MSA
configurations array elements are copied individually, and then only the
leading 32 FGR slots while the remaining slot is ignored.
Correct the code then such that only FGR slots are copied in the
respective !MSA and MSA helpers an then the FCSR slot is handled
separately in common code. Use `ptrace_setfcr31' to update the FCSR
too, so that the read-only mask is respected.
Retrieving a correct value of FCSR is important in debugging not only
for the human to be able to get the right interpretation of the
situation, but for correct operation of GDB as well. This is because
the condition code bits in FSCR are used by GDB to determine the
location to place a breakpoint at when single-stepping through an FPU
branch instruction. If such a breakpoint is placed incorrectly (i.e.
with the condition reversed), then it will be missed, likely causing the
debuggee to run away from the control of GDB and consequently breaking
the process of investigation.
Fortunately GDB continues using the older PTRACE_GETFPREGS ptrace(2)
request which is unaffected, so the regression only really hits with
post-mortem debug sessions using a core dump file, in which case
execution, and consequently single-stepping through branches is not
possible. Of course core files created by buggy kernels out there will
have the value of FCSR recorded clobbered, but such core files cannot be
corrected and the person using them simply will have to be aware that
the value of FCSR retrieved is not reliable.
Which also means we can likely get away without defining a replacement
API which would ensure a correct value of FSCR to be retrieved, or none
at all.
This is based on previous work by Alex Smith, extensively rewritten.
Signed-off-by: Alex Smith <alex(a)alex-smith.me.uk>
Signed-off-by: James Hogan <james.hogan(a)mips.com>
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset")
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Cc: stable(a)vger.kernel.org # v3.15+
Patchwork: https://patchwork.linux-mips.org/patch/17928/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
---
Hi,
This is a version of commit be07a6a11883 for 3.18-stable and before. It
updates code added like this:
- ptrace_setfcr31(target, fcr31);
+ target->thread.fpu.fcr31 = fcr31 & ~FPU_CSR_ALL_X;
because there is no `ptrace_setfcr31' helper in 3.18. This is equivalent
to the original commit in terms of functionality as at version 3.18.
Please apply.
Maciej
---
arch/mips/kernel/ptrace.c | 47 +++++++++++++++++++++++++++++++++++-----------
1 file changed, 36 insertions(+), 11 deletions(-)
linux-mips-nt-prfpreg-fcsr.diff
Index: linux-stable-el/arch/mips/kernel/ptrace.c
===================================================================
--- linux-stable-el.orig/arch/mips/kernel/ptrace.c 2018-01-10 20:03:43.000000000 +0000
+++ linux-stable-el/arch/mips/kernel/ptrace.c 2018-01-10 20:11:52.407204000 +0000
@@ -403,7 +403,7 @@ static int gpr64_set(struct task_struct
/*
* Copy the floating-point context to the supplied NT_PRFPREG buffer,
* !CONFIG_CPU_HAS_MSA variant. FP context's general register slots
- * correspond 1:1 to buffer slots.
+ * correspond 1:1 to buffer slots. Only general registers are copied.
*/
static int fpr_get_fpa(struct task_struct *target,
unsigned int *pos, unsigned int *count,
@@ -411,13 +411,14 @@ static int fpr_get_fpa(struct task_struc
{
return user_regset_copyout(pos, count, kbuf, ubuf,
&target->thread.fpu,
- 0, sizeof(elf_fpregset_t));
+ 0, NUM_FPU_REGS * sizeof(elf_fpreg_t));
}
/*
* Copy the floating-point context to the supplied NT_PRFPREG buffer,
* CONFIG_CPU_HAS_MSA variant. Only lower 64 bits of FP context's
- * general register slots are copied to buffer slots.
+ * general register slots are copied to buffer slots. Only general
+ * registers are copied.
*/
static int fpr_get_msa(struct task_struct *target,
unsigned int *pos, unsigned int *count,
@@ -439,20 +440,29 @@ static int fpr_get_msa(struct task_struc
return 0;
}
-/* Copy the floating-point context to the supplied NT_PRFPREG buffer. */
+/*
+ * Copy the floating-point context to the supplied NT_PRFPREG buffer.
+ * Choose the appropriate helper for general registers, and then copy
+ * the FCSR register separately.
+ */
static int fpr_get(struct task_struct *target,
const struct user_regset *regset,
unsigned int pos, unsigned int count,
void *kbuf, void __user *ubuf)
{
+ const int fcr31_pos = NUM_FPU_REGS * sizeof(elf_fpreg_t);
int err;
- /* XXX fcr31 */
-
if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t))
err = fpr_get_fpa(target, &pos, &count, &kbuf, &ubuf);
else
err = fpr_get_msa(target, &pos, &count, &kbuf, &ubuf);
+ if (err)
+ return err;
+
+ err = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.fpu.fcr31,
+ fcr31_pos, fcr31_pos + sizeof(u32));
return err;
}
@@ -460,7 +470,7 @@ static int fpr_get(struct task_struct *t
/*
* Copy the supplied NT_PRFPREG buffer to the floating-point context,
* !CONFIG_CPU_HAS_MSA variant. Buffer slots correspond 1:1 to FP
- * context's general register slots.
+ * context's general register slots. Only general registers are copied.
*/
static int fpr_set_fpa(struct task_struct *target,
unsigned int *pos, unsigned int *count,
@@ -468,13 +478,14 @@ static int fpr_set_fpa(struct task_struc
{
return user_regset_copyin(pos, count, kbuf, ubuf,
&target->thread.fpu,
- 0, sizeof(elf_fpregset_t));
+ 0, NUM_FPU_REGS * sizeof(elf_fpreg_t));
}
/*
* Copy the supplied NT_PRFPREG buffer to the floating-point context,
* CONFIG_CPU_HAS_MSA variant. Buffer slots are copied to lower 64
- * bits only of FP context's general register slots.
+ * bits only of FP context's general register slots. Only general
+ * registers are copied.
*/
static int fpr_set_msa(struct task_struct *target,
unsigned int *pos, unsigned int *count,
@@ -499,6 +510,8 @@ static int fpr_set_msa(struct task_struc
/*
* Copy the supplied NT_PRFPREG buffer to the floating-point context.
+ * Choose the appropriate helper for general registers, and then copy
+ * the FCSR register separately.
*
* We optimize for the case where `count % sizeof(elf_fpreg_t) == 0',
* which is supposed to have been guaranteed by the kernel before
@@ -511,16 +524,28 @@ static int fpr_set(struct task_struct *t
unsigned int pos, unsigned int count,
const void *kbuf, const void __user *ubuf)
{
+ const int fcr31_pos = NUM_FPU_REGS * sizeof(elf_fpreg_t);
+ u32 fcr31;
int err;
BUG_ON(count % sizeof(elf_fpreg_t));
- /* XXX fcr31 */
-
if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t))
err = fpr_set_fpa(target, &pos, &count, &kbuf, &ubuf);
else
err = fpr_set_msa(target, &pos, &count, &kbuf, &ubuf);
+ if (err)
+ return err;
+
+ if (count > 0) {
+ err = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &fcr31,
+ fcr31_pos, fcr31_pos + sizeof(u32));
+ if (err)
+ return err;
+
+ target->thread.fpu.fcr31 = fcr31 & ~FPU_CSR_ALL_X;
+ }
return err;
}
Update commit d614fd58a283 ("mips/ptrace: Preserve previous registers
for short regset write") bug and consistently consume all data supplied
to `fpr_set_msa' with the ptrace(2) PTRACE_SETREGSET request, such that
a zero data buffer counter is returned where insufficient data has been
given to fill a whole number of FP general registers.
In reality this is not going to happen, as the caller is supposed to
only supply data covering a whole number of registers and it is verified
in `ptrace_regset' and again asserted in `fpr_set', however structuring
code such that the presence of trailing partial FP general register data
causes `fpr_set_msa' to return with a non-zero data buffer counter makes
it appear that this trailing data will be used if there are subsequent
writes made to FP registers, which is going to be the case with the FCSR
once the missing write to that register has been fixed.
Fixes: d614fd58a283 ("mips/ptrace: Preserve previous registers for short regset write")
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Cc: James Hogan <james.hogan(a)mips.com>
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Alex Smith <alex(a)alex-smith.me.uk>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Cc: stable(a)vger.kernel.org # v4.11+
Patchwork: https://patchwork.linux-mips.org/patch/17927/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
---
Hi,
This is a (mechanically regenerated) version of commit 80b3ffce0196 for
3.18-stable and before. No functional changes. Please apply.
Maciej
---
arch/mips/kernel/ptrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
linux-mips-nt-prfpreg-count.diff
Index: linux-stable-el/arch/mips/kernel/ptrace.c
===================================================================
--- linux-stable-el.orig/arch/mips/kernel/ptrace.c 2018-01-10 20:27:12.485956000 +0000
+++ linux-stable-el/arch/mips/kernel/ptrace.c 2018-01-10 20:27:13.744971000 +0000
@@ -485,7 +485,7 @@ static int fpr_set_msa(struct task_struc
int err;
BUILD_BUG_ON(sizeof(fpr_val) != sizeof(elf_fpreg_t));
- for (i = 0; i < NUM_FPU_REGS && *count >= sizeof(elf_fpreg_t); i++) {
+ for (i = 0; i < NUM_FPU_REGS && *count > 0; i++) {
err = user_regset_copyin(pos, count, kbuf, ubuf,
&fpr_val, i * sizeof(elf_fpreg_t),
(i + 1) * sizeof(elf_fpreg_t));
Complement commit d614fd58a283 ("mips/ptrace: Preserve previous
registers for short regset write") and ensure that no partial register
write attempt is made with PTRACE_SETREGSET, as we do not preinitialize
any temporaries used to hold incoming register data and consequently
random data could be written.
It is the responsibility of the caller, such as `ptrace_regset', to
arrange for writes to span whole registers only, so here we only assert
that it has indeed happened.
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset")
Cc: James Hogan <james.hogan(a)mips.com>
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Alex Smith <alex(a)alex-smith.me.uk>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Cc: stable(a)vger.kernel.org # v3.15+
Patchwork: https://patchwork.linux-mips.org/patch/17926/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
---
Hi,
This is a (mechanically regenerated) version of commit dc24d0edf33c for
3.18-stable and before. No functional changes. Please apply.
Maciej
---
arch/mips/kernel/ptrace.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
linux-mips-nt-prfpreg-size-bug.diff
Index: linux-stable-el/arch/mips/kernel/ptrace.c
===================================================================
--- linux-stable-el.orig/arch/mips/kernel/ptrace.c 2018-01-10 20:13:31.900045000 +0000
+++ linux-stable-el/arch/mips/kernel/ptrace.c 2018-01-10 20:13:33.337064000 +0000
@@ -497,7 +497,15 @@ static int fpr_set_msa(struct task_struc
return 0;
}
-/* Copy the supplied NT_PRFPREG buffer to the floating-point context. */
+/*
+ * Copy the supplied NT_PRFPREG buffer to the floating-point context.
+ *
+ * We optimize for the case where `count % sizeof(elf_fpreg_t) == 0',
+ * which is supposed to have been guaranteed by the kernel before
+ * calling us, e.g. in `ptrace_regset'. We enforce that requirement,
+ * so that we can safely avoid preinitializing temporaries for
+ * partial register writes.
+ */
static int fpr_set(struct task_struct *target,
const struct user_regset *regset,
unsigned int pos, unsigned int count,
@@ -505,6 +513,8 @@ static int fpr_set(struct task_struct *t
{
int err;
+ BUG_ON(count % sizeof(elf_fpreg_t));
+
/* XXX fcr31 */
if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t))
This patch series fixes an issue with HS/FS 3-stage control read transfer where
DWC3 incorrectly check when to send ZLP.
Changes in v2:
- Separate from "usb: dwc3: Add new updates for DWC_usb31" patch series
- Add 'Cc' to stable mailing list
Thinh Nguyen (2):
usb: dwc3: gadget: Set maxpacket size for ep0 IN
usb: dwc3: ep0: Reset TRB counter for ep0 IN
drivers/usb/dwc3/ep0.c | 7 ++++++-
drivers/usb/dwc3/gadget.c | 2 ++
2 files changed, 8 insertions(+), 1 deletion(-)
--
2.11.0
From: "Leo (Sunpeng) Li" <sunpeng.li(a)amd.com>
During a non-blocking commit, it is possible to return before the
commit_tail work is queued (-ERESTARTSYS, for example).
Since a reference on the crtc commit object is obtained for the pending
vblank event when preparing the commit, the above situation will leave
us with an extra reference.
Therefore, if the commit_tail worker has not consumed the event at the
end of a commit, release it's reference.
Changes since v1:
- Also check for state->event->base.completion being set, to
handle the case where stall_checks() fails in setup_crtc_commit().
Fixes: 24835e442f28 ("drm: reference count event->completion")
Cc: <stable(a)vger.kernel.org> # v4.11+
Signed-off-by: Leo (Sunpeng) Li <sunpeng.li(a)amd.com>
Acked-by: Harry Wentland <harry.wentland(a)amd.com> #v1
Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com>
---
drivers/gpu/drm/drm_atomic_helper.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index b16f1d69a0bb..1d43f3e85a7d 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3327,6 +3327,15 @@ EXPORT_SYMBOL(drm_atomic_helper_crtc_duplicate_state);
void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc_state *state)
{
if (state->commit) {
+ /*
+ * In the event that a non-blocking commit returns
+ * -ERESTARTSYS before the commit_tail work is queued, we will
+ * have an extra reference to the commit object. Release it, if
+ * the event has not been consumed by the worker.
+ */
+ if (state->event && state->event->base.completion)
+ drm_crtc_commit_put(state->commit);
+
kfree(state->commit->event);
state->commit->event = NULL;
drm_crtc_commit_put(state->commit);
--
2.15.1
From: Long Li <longli(a)microsoft.com>
The original patch was made for stable 4.1 and was Acked on 08/22/2017, but for
some reason it never made it to the stable tree.
Change from v1:
Changed comment that this patch is for linux-stable 4.1 and all prior stable
kernels.
storvsc checks the SG list for gaps before passing them to Hyper-v device.
If there are gaps, data is copied to a bounce buffer and a continuous data
buffer is passed to Hyper-V.
The check on gaps assumes SG list is continuous, and not chained. This is
not always true. Failing the check may result in incorrect I/O data
passed to the Hyper-v device.
This code path is not used post Linux 4.1.
Signed-off-by: Long Li <longli(a)microsoft.com>
Acked-by: Martin K. Petersen <martin.petersen(a)oracle.com>
---
drivers/scsi/storvsc_drv.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 6c52d14..14dc5c6 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -584,17 +584,18 @@ static int do_bounce_buffer(struct scatterlist *sgl, unsigned int sg_count)
for (i = 0; i < sg_count; i++) {
if (i == 0) {
/* make sure 1st one does not have hole */
- if (sgl[i].offset + sgl[i].length != PAGE_SIZE)
+ if (sgl->offset + sgl->length != PAGE_SIZE)
return i;
} else if (i == sg_count - 1) {
/* make sure last one does not have hole */
- if (sgl[i].offset != 0)
+ if (sgl->offset != 0)
return i;
} else {
/* make sure no hole in the middle */
- if (sgl[i].length != PAGE_SIZE || sgl[i].offset != 0)
+ if (sgl->length != PAGE_SIZE || sgl->offset != 0)
return i;
}
+ sgl = sg_next(sgl);
}
return -1;
}
--
2.7.4
The patch below does not apply to the 4.4-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 57d72e159b60456c8bb281736c02ddd3164037aa Mon Sep 17 00:00:00 2001
From: Jean-Philippe Brucker <jean-philippe.brucker(a)arm.com>
Date: Thu, 14 Dec 2017 11:03:01 +0000
Subject: [PATCH] iommu/arm-smmu-v3: Don't free page table ops twice
Kasan reports a double free when finalise_stage_fn fails: the io_pgtable
ops are freed by arm_smmu_domain_finalise and then again by
arm_smmu_domain_free. Prevent this by leaving pgtbl_ops empty on failure.
Cc: <stable(a)vger.kernel.org>
Fixes: 48ec83bcbcf5 ("iommu/arm-smmu: Add initial driver support for ARM SMMUv3 devices")
Reviewed-by: Robin Murphy <robin.murphy(a)arm.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index f122071688fd..db4281d0e269 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -1698,13 +1698,15 @@ static int arm_smmu_domain_finalise(struct iommu_domain *domain)
domain->pgsize_bitmap = pgtbl_cfg.pgsize_bitmap;
domain->geometry.aperture_end = (1UL << ias) - 1;
domain->geometry.force_aperture = true;
- smmu_domain->pgtbl_ops = pgtbl_ops;
ret = finalise_stage_fn(smmu_domain, &pgtbl_cfg);
- if (ret < 0)
+ if (ret < 0) {
free_io_pgtable_ops(pgtbl_ops);
+ return ret;
+ }
- return ret;
+ smmu_domain->pgtbl_ops = pgtbl_ops;
+ return 0;
}
static __le64 *arm_smmu_get_step_for_sid(struct arm_smmu_device *smmu, u32 sid)
This is a note to let you know that I've just added the patch titled
iommu/arm-smmu-v3: Don't free page table ops twice
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:
iommu-arm-smmu-v3-don-t-free-page-table-ops-twice.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 57d72e159b60456c8bb281736c02ddd3164037aa Mon Sep 17 00:00:00 2001
From: Jean-Philippe Brucker <jean-philippe.brucker(a)arm.com>
Date: Thu, 14 Dec 2017 11:03:01 +0000
Subject: iommu/arm-smmu-v3: Don't free page table ops twice
From: Jean-Philippe Brucker <jean-philippe.brucker(a)arm.com>
commit 57d72e159b60456c8bb281736c02ddd3164037aa upstream.
Kasan reports a double free when finalise_stage_fn fails: the io_pgtable
ops are freed by arm_smmu_domain_finalise and then again by
arm_smmu_domain_free. Prevent this by leaving pgtbl_ops empty on failure.
Fixes: 48ec83bcbcf5 ("iommu/arm-smmu: Add initial driver support for ARM SMMUv3 devices")
Reviewed-by: Robin Murphy <robin.murphy(a)arm.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iommu/arm-smmu-v3.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -1541,13 +1541,15 @@ static int arm_smmu_domain_finalise(stru
return -ENOMEM;
arm_smmu_ops.pgsize_bitmap = pgtbl_cfg.pgsize_bitmap;
- smmu_domain->pgtbl_ops = pgtbl_ops;
ret = finalise_stage_fn(smmu_domain, &pgtbl_cfg);
- if (IS_ERR_VALUE(ret))
+ if (IS_ERR_VALUE(ret)) {
free_io_pgtable_ops(pgtbl_ops);
+ return ret;
+ }
- return ret;
+ smmu_domain->pgtbl_ops = pgtbl_ops;
+ return 0;
}
static struct arm_smmu_group *arm_smmu_group_get(struct device *dev)
Patches currently in stable-queue which might be from jean-philippe.brucker(a)arm.com are
queue-4.4/iommu-arm-smmu-v3-don-t-free-page-table-ops-twice.patch
If we return 1 from our post_reset handler, then our disconnect handler
will be called immediately afterwards. Since pre_reset blocks all scsi
requests our disconnect handler will then hang in the scsi_remove_host
call.
This is esp. bad because our disconnect handler hanging for ever also
stops the USB subsys from enumerating any new USB devices, causes commands
like lsusb to hang, etc.
In practice this happens when unplugging some uas devices because the hub
code may see the device as needing a warm-reset and calls usb_reset_device
before seeing the disconnect. In this case uas_configure_endpoints fails
with -ENODEV. We do not want to print an error for this, so this commit
also silences the shost_printk for -ENODEV.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1531966
Cc: stable(a)vger.kernel.org
Fixes: 8d51444cdd06 ("uas: Not being able to alloc streams ... is an error")
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
drivers/usb/storage/uas.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 5d04c40ee40a..5471422aa1ab 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -1077,9 +1077,13 @@ static int uas_post_reset(struct usb_interface *intf)
err = uas_configure_endpoints(devinfo);
if (err) {
- shost_printk(KERN_ERR, shost,
- "%s: alloc streams error %d after reset",
- __func__, err);
+ if (err != -ENODEV) {
+ shost_printk(KERN_ERR, shost,
+ "%s: alloc streams error %d after reset",
+ __func__, err);
+ }
+ /* So that scsi_remove_host in uas_disconnect does not hang */
+ scsi_unblock_requests(shost);
return 1;
}
--
2.14.3
This is a note to let you know that I've just added the patch titled
x86/acpi: Handle SCI interrupts above legacy space gracefully
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:
x86-acpi-handle-sci-interrupts-above-legacy-space-gracefully.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 252714155f04c5d16989cb3aadb85fd1b5772f99 Mon Sep 17 00:00:00 2001
From: Vikas C Sajjan <vikas.cha.sajjan(a)hpe.com>
Date: Thu, 16 Nov 2017 21:43:44 +0530
Subject: x86/acpi: Handle SCI interrupts above legacy space gracefully
From: Vikas C Sajjan <vikas.cha.sajjan(a)hpe.com>
commit 252714155f04c5d16989cb3aadb85fd1b5772f99 upstream.
Platforms which support only IOAPIC mode, pass the SCI information above
the legacy space (0-15) via the FADT mechanism and not via MADT.
In such cases mp_override_legacy_irq() which is invoked from
acpi_sci_ioapic_setup() to register SCI interrupts fails for interrupts
greater equal 16, since it is meant to handle only the legacy space and
emits error "Invalid bus_irq %u for legacy override".
Add a new function to handle SCI interrupts >= 16 and invoke it
conditionally in acpi_sci_ioapic_setup().
The code duplication due to this new function will be cleaned up in a
separate patch.
Co-developed-by: Sunil V L <sunil.vl(a)hpe.com>
Signed-off-by: Vikas C Sajjan <vikas.cha.sajjan(a)hpe.com>
Signed-off-by: Sunil V L <sunil.vl(a)hpe.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Tested-by: Abdul Lateef Attar <abdul-lateef.attar(a)hpe.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Cc: linux-pm(a)vger.kernel.org
Cc: kkamagui(a)gmail.com
Cc: linux-acpi(a)vger.kernel.org
Link: https://lkml.kernel.org/r/1510848825-21965-2-git-send-email-vikas.cha.sajja…
Cc: Jean Delvare <jdelvare(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/acpi/boot.c | 34 +++++++++++++++++++++++++++++++++-
1 file changed, 33 insertions(+), 1 deletion(-)
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -422,6 +422,34 @@ static int mp_config_acpi_gsi(struct dev
return 0;
}
+static int __init mp_register_ioapic_irq(u8 bus_irq, u8 polarity,
+ u8 trigger, u32 gsi)
+{
+ struct mpc_intsrc mp_irq;
+ int ioapic, pin;
+
+ /* Convert 'gsi' to 'ioapic.pin'(INTIN#) */
+ ioapic = mp_find_ioapic(gsi);
+ if (ioapic < 0) {
+ pr_warn("Failed to find ioapic for gsi : %u\n", gsi);
+ return ioapic;
+ }
+
+ pin = mp_find_ioapic_pin(ioapic, gsi);
+
+ mp_irq.type = MP_INTSRC;
+ mp_irq.irqtype = mp_INT;
+ mp_irq.irqflag = (trigger << 2) | polarity;
+ mp_irq.srcbus = MP_ISA_BUS;
+ mp_irq.srcbusirq = bus_irq;
+ mp_irq.dstapic = mpc_ioapic_id(ioapic);
+ mp_irq.dstirq = pin;
+
+ mp_save_irq(&mp_irq);
+
+ return 0;
+}
+
static int __init
acpi_parse_ioapic(struct acpi_subtable_header * header, const unsigned long end)
{
@@ -466,7 +494,11 @@ static void __init acpi_sci_ioapic_setup
if (acpi_sci_flags & ACPI_MADT_POLARITY_MASK)
polarity = acpi_sci_flags & ACPI_MADT_POLARITY_MASK;
- mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
+ if (bus_irq < NR_IRQS_LEGACY)
+ mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
+ else
+ mp_register_ioapic_irq(bus_irq, polarity, trigger, gsi);
+
acpi_penalize_sci_irq(bus_irq, trigger, polarity);
/*
Patches currently in stable-queue which might be from vikas.cha.sajjan(a)hpe.com are
queue-4.9/x86-acpi-handle-sci-interrupts-above-legacy-space-gracefully.patch
This is a note to let you know that I've just added the patch titled
x86/acpi: Handle SCI interrupts above legacy space gracefully
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:
x86-acpi-handle-sci-interrupts-above-legacy-space-gracefully.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 252714155f04c5d16989cb3aadb85fd1b5772f99 Mon Sep 17 00:00:00 2001
From: Vikas C Sajjan <vikas.cha.sajjan(a)hpe.com>
Date: Thu, 16 Nov 2017 21:43:44 +0530
Subject: x86/acpi: Handle SCI interrupts above legacy space gracefully
From: Vikas C Sajjan <vikas.cha.sajjan(a)hpe.com>
commit 252714155f04c5d16989cb3aadb85fd1b5772f99 upstream.
Platforms which support only IOAPIC mode, pass the SCI information above
the legacy space (0-15) via the FADT mechanism and not via MADT.
In such cases mp_override_legacy_irq() which is invoked from
acpi_sci_ioapic_setup() to register SCI interrupts fails for interrupts
greater equal 16, since it is meant to handle only the legacy space and
emits error "Invalid bus_irq %u for legacy override".
Add a new function to handle SCI interrupts >= 16 and invoke it
conditionally in acpi_sci_ioapic_setup().
The code duplication due to this new function will be cleaned up in a
separate patch.
Co-developed-by: Sunil V L <sunil.vl(a)hpe.com>
Signed-off-by: Vikas C Sajjan <vikas.cha.sajjan(a)hpe.com>
Signed-off-by: Sunil V L <sunil.vl(a)hpe.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Tested-by: Abdul Lateef Attar <abdul-lateef.attar(a)hpe.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Cc: linux-pm(a)vger.kernel.org
Cc: kkamagui(a)gmail.com
Cc: linux-acpi(a)vger.kernel.org
Link: https://lkml.kernel.org/r/1510848825-21965-2-git-send-email-vikas.cha.sajja…
Cc: Jean Delvare <jdelvare(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/acpi/boot.c | 34 +++++++++++++++++++++++++++++++++-
1 file changed, 33 insertions(+), 1 deletion(-)
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -408,6 +408,34 @@ static int mp_config_acpi_gsi(struct dev
return 0;
}
+static int __init mp_register_ioapic_irq(u8 bus_irq, u8 polarity,
+ u8 trigger, u32 gsi)
+{
+ struct mpc_intsrc mp_irq;
+ int ioapic, pin;
+
+ /* Convert 'gsi' to 'ioapic.pin'(INTIN#) */
+ ioapic = mp_find_ioapic(gsi);
+ if (ioapic < 0) {
+ pr_warn("Failed to find ioapic for gsi : %u\n", gsi);
+ return ioapic;
+ }
+
+ pin = mp_find_ioapic_pin(ioapic, gsi);
+
+ mp_irq.type = MP_INTSRC;
+ mp_irq.irqtype = mp_INT;
+ mp_irq.irqflag = (trigger << 2) | polarity;
+ mp_irq.srcbus = MP_ISA_BUS;
+ mp_irq.srcbusirq = bus_irq;
+ mp_irq.dstapic = mpc_ioapic_id(ioapic);
+ mp_irq.dstirq = pin;
+
+ mp_save_irq(&mp_irq);
+
+ return 0;
+}
+
static int __init
acpi_parse_ioapic(struct acpi_subtable_header * header, const unsigned long end)
{
@@ -452,7 +480,11 @@ static void __init acpi_sci_ioapic_setup
if (acpi_sci_flags & ACPI_MADT_POLARITY_MASK)
polarity = acpi_sci_flags & ACPI_MADT_POLARITY_MASK;
- mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
+ if (bus_irq < NR_IRQS_LEGACY)
+ mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
+ else
+ mp_register_ioapic_irq(bus_irq, polarity, trigger, gsi);
+
acpi_penalize_sci_irq(bus_irq, trigger, polarity);
/*
Patches currently in stable-queue which might be from vikas.cha.sajjan(a)hpe.com are
queue-4.4/x86-acpi-handle-sci-interrupts-above-legacy-space-gracefully.patch
This is a note to let you know that I've just added the patch titled
x86/acpi: Handle SCI interrupts above legacy space gracefully
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-acpi-handle-sci-interrupts-above-legacy-space-gracefully.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 252714155f04c5d16989cb3aadb85fd1b5772f99 Mon Sep 17 00:00:00 2001
From: Vikas C Sajjan <vikas.cha.sajjan(a)hpe.com>
Date: Thu, 16 Nov 2017 21:43:44 +0530
Subject: x86/acpi: Handle SCI interrupts above legacy space gracefully
From: Vikas C Sajjan <vikas.cha.sajjan(a)hpe.com>
commit 252714155f04c5d16989cb3aadb85fd1b5772f99 upstream.
Platforms which support only IOAPIC mode, pass the SCI information above
the legacy space (0-15) via the FADT mechanism and not via MADT.
In such cases mp_override_legacy_irq() which is invoked from
acpi_sci_ioapic_setup() to register SCI interrupts fails for interrupts
greater equal 16, since it is meant to handle only the legacy space and
emits error "Invalid bus_irq %u for legacy override".
Add a new function to handle SCI interrupts >= 16 and invoke it
conditionally in acpi_sci_ioapic_setup().
The code duplication due to this new function will be cleaned up in a
separate patch.
Co-developed-by: Sunil V L <sunil.vl(a)hpe.com>
Signed-off-by: Vikas C Sajjan <vikas.cha.sajjan(a)hpe.com>
Signed-off-by: Sunil V L <sunil.vl(a)hpe.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Tested-by: Abdul Lateef Attar <abdul-lateef.attar(a)hpe.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Cc: linux-pm(a)vger.kernel.org
Cc: kkamagui(a)gmail.com
Cc: linux-acpi(a)vger.kernel.org
Link: https://lkml.kernel.org/r/1510848825-21965-2-git-send-email-vikas.cha.sajja…
Cc: Jean Delvare <jdelvare(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/acpi/boot.c | 34 +++++++++++++++++++++++++++++++++-
1 file changed, 33 insertions(+), 1 deletion(-)
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -429,6 +429,34 @@ static int mp_config_acpi_gsi(struct dev
return 0;
}
+static int __init mp_register_ioapic_irq(u8 bus_irq, u8 polarity,
+ u8 trigger, u32 gsi)
+{
+ struct mpc_intsrc mp_irq;
+ int ioapic, pin;
+
+ /* Convert 'gsi' to 'ioapic.pin'(INTIN#) */
+ ioapic = mp_find_ioapic(gsi);
+ if (ioapic < 0) {
+ pr_warn("Failed to find ioapic for gsi : %u\n", gsi);
+ return ioapic;
+ }
+
+ pin = mp_find_ioapic_pin(ioapic, gsi);
+
+ mp_irq.type = MP_INTSRC;
+ mp_irq.irqtype = mp_INT;
+ mp_irq.irqflag = (trigger << 2) | polarity;
+ mp_irq.srcbus = MP_ISA_BUS;
+ mp_irq.srcbusirq = bus_irq;
+ mp_irq.dstapic = mpc_ioapic_id(ioapic);
+ mp_irq.dstirq = pin;
+
+ mp_save_irq(&mp_irq);
+
+ return 0;
+}
+
static int __init
acpi_parse_ioapic(struct acpi_subtable_header * header, const unsigned long end)
{
@@ -473,7 +501,11 @@ static void __init acpi_sci_ioapic_setup
if (acpi_sci_flags & ACPI_MADT_POLARITY_MASK)
polarity = acpi_sci_flags & ACPI_MADT_POLARITY_MASK;
- mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
+ if (bus_irq < NR_IRQS_LEGACY)
+ mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
+ else
+ mp_register_ioapic_irq(bus_irq, polarity, trigger, gsi);
+
acpi_penalize_sci_irq(bus_irq, trigger, polarity);
/*
Patches currently in stable-queue which might be from vikas.cha.sajjan(a)hpe.com are
queue-4.14/x86-acpi-handle-sci-interrupts-above-legacy-space-gracefully.patch
This is a note to let you know that I've just added the patch titled
x86/acpi: Handle SCI interrupts above legacy space gracefully
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:
x86-acpi-handle-sci-interrupts-above-legacy-space-gracefully.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 252714155f04c5d16989cb3aadb85fd1b5772f99 Mon Sep 17 00:00:00 2001
From: Vikas C Sajjan <vikas.cha.sajjan(a)hpe.com>
Date: Thu, 16 Nov 2017 21:43:44 +0530
Subject: x86/acpi: Handle SCI interrupts above legacy space gracefully
From: Vikas C Sajjan <vikas.cha.sajjan(a)hpe.com>
commit 252714155f04c5d16989cb3aadb85fd1b5772f99 upstream.
Platforms which support only IOAPIC mode, pass the SCI information above
the legacy space (0-15) via the FADT mechanism and not via MADT.
In such cases mp_override_legacy_irq() which is invoked from
acpi_sci_ioapic_setup() to register SCI interrupts fails for interrupts
greater equal 16, since it is meant to handle only the legacy space and
emits error "Invalid bus_irq %u for legacy override".
Add a new function to handle SCI interrupts >= 16 and invoke it
conditionally in acpi_sci_ioapic_setup().
The code duplication due to this new function will be cleaned up in a
separate patch.
Co-developed-by: Sunil V L <sunil.vl(a)hpe.com>
Signed-off-by: Vikas C Sajjan <vikas.cha.sajjan(a)hpe.com>
Signed-off-by: Sunil V L <sunil.vl(a)hpe.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Tested-by: Abdul Lateef Attar <abdul-lateef.attar(a)hpe.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Cc: linux-pm(a)vger.kernel.org
Cc: kkamagui(a)gmail.com
Cc: linux-acpi(a)vger.kernel.org
Link: https://lkml.kernel.org/r/1510848825-21965-2-git-send-email-vikas.cha.sajja…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/acpi/boot.c | 33 ++++++++++++++++++++++++++++++++-
1 file changed, 32 insertions(+), 1 deletion(-)
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -445,6 +445,34 @@ static struct irq_domain_ops acpi_irqdom
.unmap = mp_irqdomain_unmap,
};
+static int __init mp_register_ioapic_irq(u8 bus_irq, u8 polarity,
+ u8 trigger, u32 gsi)
+{
+ struct mpc_intsrc mp_irq;
+ int ioapic, pin;
+
+ /* Convert 'gsi' to 'ioapic.pin'(INTIN#) */
+ ioapic = mp_find_ioapic(gsi);
+ if (ioapic < 0) {
+ pr_warn("Failed to find ioapic for gsi : %u\n", gsi);
+ return ioapic;
+ }
+
+ pin = mp_find_ioapic_pin(ioapic, gsi);
+
+ mp_irq.type = MP_INTSRC;
+ mp_irq.irqtype = mp_INT;
+ mp_irq.irqflag = (trigger << 2) | polarity;
+ mp_irq.srcbus = MP_ISA_BUS;
+ mp_irq.srcbusirq = bus_irq;
+ mp_irq.dstapic = mpc_ioapic_id(ioapic);
+ mp_irq.dstirq = pin;
+
+ mp_save_irq(&mp_irq);
+
+ return 0;
+}
+
static int __init
acpi_parse_ioapic(struct acpi_subtable_header * header, const unsigned long end)
{
@@ -489,7 +517,10 @@ static void __init acpi_sci_ioapic_setup
if (acpi_sci_flags & ACPI_MADT_POLARITY_MASK)
polarity = acpi_sci_flags & ACPI_MADT_POLARITY_MASK;
- mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
+ if (bus_irq < NR_IRQS_LEGACY)
+ mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
+ else
+ mp_register_ioapic_irq(bus_irq, polarity, trigger, gsi);
/*
* stash over-ride to indicate we've been here
Patches currently in stable-queue which might be from vikas.cha.sajjan(a)hpe.com are
queue-3.18/x86-acpi-handle-sci-interrupts-above-legacy-space-gracefully.patch
Running the compaction_test sometimes results in out-of-memory
failures. When I debugged this, it turned out that the code to
reset the number of hugepages to the initial value is simply
broken since we write into an open sysctl file descriptor
multiple times without seeking back to the start.
Adding the lseek here fixes the problem.
Cc: stable(a)vger.kernel.org
Reported-by: Naresh Kamboju <naresh.kamboju(a)linaro.org>
Link: https://bugs.linaro.org/show_bug.cgi?id=3145
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
tools/testing/selftests/vm/compaction_test.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/testing/selftests/vm/compaction_test.c b/tools/testing/selftests/vm/compaction_test.c
index a65b016d4c13..1097f04e4d80 100644
--- a/tools/testing/selftests/vm/compaction_test.c
+++ b/tools/testing/selftests/vm/compaction_test.c
@@ -137,6 +137,8 @@ int check_compaction(unsigned long mem_free, unsigned int hugepage_size)
printf("No of huge pages allocated = %d\n",
(atoi(nr_hugepages)));
+ lseek(fd, 0, SEEK_SET);
+
if (write(fd, initial_nr_hugepages, strlen(initial_nr_hugepages))
!= strlen(initial_nr_hugepages)) {
perror("Failed to write value to /proc/sys/vm/nr_hugepages\n");
--
2.9.0
This is a note to let you know that I've just added the patch titled
iw_cxgb4: when flushing, complete all wrs in a chain
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:
iw_cxgb4-when-flushing-complete-all-wrs-in-a-chain.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 d14587334580bc94d3ee11e8320e0c157f91ae8f Mon Sep 17 00:00:00 2001
From: Steve Wise <swise(a)opengridcomputing.com>
Date: Tue, 19 Dec 2017 14:02:10 -0800
Subject: iw_cxgb4: when flushing, complete all wrs in a chain
From: Steve Wise <swise(a)opengridcomputing.com>
commit d14587334580bc94d3ee11e8320e0c157f91ae8f upstream.
If a wr chain was posted and needed to be flushed, only the first
wr in the chain was completed with FLUSHED status. The rest were
never completed. This caused isert to hang on shutdown due to the
missing completions which left iscsi IO commands referenced, stalling
the shutdown.
Fixes: 4fe7c2962e11 ("iw_cxgb4: refactor sq/rq drain logic")
Signed-off-by: Steve Wise <swise(a)opengridcomputing.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/cxgb4/qp.c | 28 ++++++++++++++++++++++++++--
1 file changed, 26 insertions(+), 2 deletions(-)
--- a/drivers/infiniband/hw/cxgb4/qp.c
+++ b/drivers/infiniband/hw/cxgb4/qp.c
@@ -862,6 +862,22 @@ static int complete_sq_drain_wr(struct c
return 0;
}
+static int complete_sq_drain_wrs(struct c4iw_qp *qhp, struct ib_send_wr *wr,
+ struct ib_send_wr **bad_wr)
+{
+ int ret = 0;
+
+ while (wr) {
+ ret = complete_sq_drain_wr(qhp, wr);
+ if (ret) {
+ *bad_wr = wr;
+ break;
+ }
+ wr = wr->next;
+ }
+ return ret;
+}
+
static void complete_rq_drain_wr(struct c4iw_qp *qhp, struct ib_recv_wr *wr)
{
struct t4_cqe cqe = {};
@@ -894,6 +910,14 @@ static void complete_rq_drain_wr(struct
}
}
+static void complete_rq_drain_wrs(struct c4iw_qp *qhp, struct ib_recv_wr *wr)
+{
+ while (wr) {
+ complete_rq_drain_wr(qhp, wr);
+ wr = wr->next;
+ }
+}
+
int c4iw_post_send(struct ib_qp *ibqp, struct ib_send_wr *wr,
struct ib_send_wr **bad_wr)
{
@@ -917,7 +941,7 @@ int c4iw_post_send(struct ib_qp *ibqp, s
*/
if (qhp->wq.flushed) {
spin_unlock_irqrestore(&qhp->lock, flag);
- err = complete_sq_drain_wr(qhp, wr);
+ err = complete_sq_drain_wrs(qhp, wr, bad_wr);
return err;
}
num_wrs = t4_sq_avail(&qhp->wq);
@@ -1066,7 +1090,7 @@ int c4iw_post_receive(struct ib_qp *ibqp
*/
if (qhp->wq.flushed) {
spin_unlock_irqrestore(&qhp->lock, flag);
- complete_rq_drain_wr(qhp, wr);
+ complete_rq_drain_wrs(qhp, wr);
return err;
}
num_wrs = t4_rq_avail(&qhp->wq);
Patches currently in stable-queue which might be from swise(a)opengridcomputing.com are
queue-4.14/iw_cxgb4-only-clear-the-armed-bit-if-a-notification-is-needed.patch
queue-4.14/iw_cxgb4-atomically-flush-the-qp.patch
queue-4.14/iw_cxgb4-when-flushing-complete-all-wrs-in-a-chain.patch
queue-4.14/iw_cxgb4-reflect-the-original-wr-opcode-in-drain-cqes.patch
queue-4.14/iw_cxgb4-only-call-the-cq-comp_handler-when-the-cq-is-armed.patch
This is a note to let you know that I've just added the patch titled
iw_cxgb4: only clear the ARMED bit if a notification is needed
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:
iw_cxgb4-only-clear-the-armed-bit-if-a-notification-is-needed.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 335ebf6fa35ca1c59b73f76fad19b249d3550e86 Mon Sep 17 00:00:00 2001
From: Steve Wise <swise(a)opengridcomputing.com>
Date: Thu, 30 Nov 2017 09:41:56 -0800
Subject: iw_cxgb4: only clear the ARMED bit if a notification is needed
From: Steve Wise <swise(a)opengridcomputing.com>
commit 335ebf6fa35ca1c59b73f76fad19b249d3550e86 upstream.
In __flush_qp(), the CQ ARMED bit was being cleared regardless of
whether any notification is actually needed. This resulted in the iser
termination logic getting stuck in ib_drain_sq() because the CQ was not
marked ARMED and thus the drain CQE notification wasn't triggered.
This new bug was exposed when this commit was merged:
commit cbb40fadd31c ("iw_cxgb4: only call the cq comp_handler when the
cq is armed")
Signed-off-by: Steve Wise <swise(a)opengridcomputing.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/cxgb4/qp.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/infiniband/hw/cxgb4/qp.c
+++ b/drivers/infiniband/hw/cxgb4/qp.c
@@ -1301,21 +1301,21 @@ static void __flush_qp(struct c4iw_qp *q
spin_unlock_irqrestore(&rchp->lock, flag);
if (schp == rchp) {
- if (t4_clear_cq_armed(&rchp->cq) &&
- (rq_flushed || sq_flushed)) {
+ if ((rq_flushed || sq_flushed) &&
+ t4_clear_cq_armed(&rchp->cq)) {
spin_lock_irqsave(&rchp->comp_handler_lock, flag);
(*rchp->ibcq.comp_handler)(&rchp->ibcq,
rchp->ibcq.cq_context);
spin_unlock_irqrestore(&rchp->comp_handler_lock, flag);
}
} else {
- if (t4_clear_cq_armed(&rchp->cq) && rq_flushed) {
+ if (rq_flushed && t4_clear_cq_armed(&rchp->cq)) {
spin_lock_irqsave(&rchp->comp_handler_lock, flag);
(*rchp->ibcq.comp_handler)(&rchp->ibcq,
rchp->ibcq.cq_context);
spin_unlock_irqrestore(&rchp->comp_handler_lock, flag);
}
- if (t4_clear_cq_armed(&schp->cq) && sq_flushed) {
+ if (sq_flushed && t4_clear_cq_armed(&schp->cq)) {
spin_lock_irqsave(&schp->comp_handler_lock, flag);
(*schp->ibcq.comp_handler)(&schp->ibcq,
schp->ibcq.cq_context);
Patches currently in stable-queue which might be from swise(a)opengridcomputing.com are
queue-4.14/iw_cxgb4-only-clear-the-armed-bit-if-a-notification-is-needed.patch
queue-4.14/iw_cxgb4-atomically-flush-the-qp.patch
queue-4.14/iw_cxgb4-when-flushing-complete-all-wrs-in-a-chain.patch
queue-4.14/iw_cxgb4-reflect-the-original-wr-opcode-in-drain-cqes.patch
queue-4.14/iw_cxgb4-only-call-the-cq-comp_handler-when-the-cq-is-armed.patch
This is a note to let you know that I've just added the patch titled
iw_cxgb4: atomically flush the qp
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:
iw_cxgb4-atomically-flush-the-qp.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 bc52e9ca74b9a395897bb640c6671b2cbf716032 Mon Sep 17 00:00:00 2001
From: Steve Wise <swise(a)opengridcomputing.com>
Date: Thu, 9 Nov 2017 07:21:26 -0800
Subject: iw_cxgb4: atomically flush the qp
From: Steve Wise <swise(a)opengridcomputing.com>
commit bc52e9ca74b9a395897bb640c6671b2cbf716032 upstream.
__flush_qp() has a race condition where during the flush operation,
the qp lock is released allowing another thread to possibly post a WR,
which corrupts the queue state, possibly causing crashes. The lock was
released to preserve the cq/qp locking hierarchy of cq first, then qp.
However releasing the qp lock is not necessary; both RQ and SQ CQ locks
can be acquired first, followed by the qp lock, and then the RQ and SQ
flushing can be done w/o unlocking.
Signed-off-by: Steve Wise <swise(a)opengridcomputing.com>
Signed-off-by: Doug Ledford <dledford(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/cxgb4/qp.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
--- a/drivers/infiniband/hw/cxgb4/qp.c
+++ b/drivers/infiniband/hw/cxgb4/qp.c
@@ -1271,31 +1271,34 @@ static void __flush_qp(struct c4iw_qp *q
pr_debug("%s qhp %p rchp %p schp %p\n", __func__, qhp, rchp, schp);
- /* locking hierarchy: cq lock first, then qp lock. */
+ /* locking hierarchy: cqs lock first, then qp lock. */
spin_lock_irqsave(&rchp->lock, flag);
+ if (schp != rchp)
+ spin_lock(&schp->lock);
spin_lock(&qhp->lock);
if (qhp->wq.flushed) {
spin_unlock(&qhp->lock);
+ if (schp != rchp)
+ spin_unlock(&schp->lock);
spin_unlock_irqrestore(&rchp->lock, flag);
return;
}
qhp->wq.flushed = 1;
+ t4_set_wq_in_error(&qhp->wq);
c4iw_flush_hw_cq(rchp);
c4iw_count_rcqes(&rchp->cq, &qhp->wq, &count);
rq_flushed = c4iw_flush_rq(&qhp->wq, &rchp->cq, count);
- spin_unlock(&qhp->lock);
- spin_unlock_irqrestore(&rchp->lock, flag);
- /* locking hierarchy: cq lock first, then qp lock. */
- spin_lock_irqsave(&schp->lock, flag);
- spin_lock(&qhp->lock);
if (schp != rchp)
c4iw_flush_hw_cq(schp);
sq_flushed = c4iw_flush_sq(qhp);
+
spin_unlock(&qhp->lock);
- spin_unlock_irqrestore(&schp->lock, flag);
+ if (schp != rchp)
+ spin_unlock(&schp->lock);
+ spin_unlock_irqrestore(&rchp->lock, flag);
if (schp == rchp) {
if (t4_clear_cq_armed(&rchp->cq) &&
@@ -1329,8 +1332,8 @@ static void flush_qp(struct c4iw_qp *qhp
rchp = to_c4iw_cq(qhp->ibqp.recv_cq);
schp = to_c4iw_cq(qhp->ibqp.send_cq);
- t4_set_wq_in_error(&qhp->wq);
if (qhp->ibqp.uobject) {
+ t4_set_wq_in_error(&qhp->wq);
t4_set_cq_in_error(&rchp->cq);
spin_lock_irqsave(&rchp->comp_handler_lock, flag);
(*rchp->ibcq.comp_handler)(&rchp->ibcq, rchp->ibcq.cq_context);
Patches currently in stable-queue which might be from swise(a)opengridcomputing.com are
queue-4.14/iw_cxgb4-only-clear-the-armed-bit-if-a-notification-is-needed.patch
queue-4.14/iw_cxgb4-atomically-flush-the-qp.patch
queue-4.14/iw_cxgb4-when-flushing-complete-all-wrs-in-a-chain.patch
queue-4.14/iw_cxgb4-reflect-the-original-wr-opcode-in-drain-cqes.patch
queue-4.14/iw_cxgb4-only-call-the-cq-comp_handler-when-the-cq-is-armed.patch
This is a note to let you know that I've just added the patch titled
iw_cxgb4: only call the cq comp_handler when the cq is armed
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:
iw_cxgb4-only-call-the-cq-comp_handler-when-the-cq-is-armed.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 cbb40fadd31c6bbc59104e58ac95c6ef492d038b Mon Sep 17 00:00:00 2001
From: Steve Wise <swise(a)opengridcomputing.com>
Date: Thu, 9 Nov 2017 07:14:43 -0800
Subject: iw_cxgb4: only call the cq comp_handler when the cq is armed
From: Steve Wise <swise(a)opengridcomputing.com>
commit cbb40fadd31c6bbc59104e58ac95c6ef492d038b upstream.
The ULPs completion handler should only be called if the CQ is
armed for notification.
Signed-off-by: Steve Wise <swise(a)opengridcomputing.com>
Signed-off-by: Doug Ledford <dledford(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/cxgb4/ev.c | 8 +++++---
drivers/infiniband/hw/cxgb4/qp.c | 20 ++++++++++++--------
2 files changed, 17 insertions(+), 11 deletions(-)
--- a/drivers/infiniband/hw/cxgb4/ev.c
+++ b/drivers/infiniband/hw/cxgb4/ev.c
@@ -109,9 +109,11 @@ static void post_qp_event(struct c4iw_de
if (qhp->ibqp.event_handler)
(*qhp->ibqp.event_handler)(&event, qhp->ibqp.qp_context);
- spin_lock_irqsave(&chp->comp_handler_lock, flag);
- (*chp->ibcq.comp_handler)(&chp->ibcq, chp->ibcq.cq_context);
- spin_unlock_irqrestore(&chp->comp_handler_lock, flag);
+ if (t4_clear_cq_armed(&chp->cq)) {
+ spin_lock_irqsave(&chp->comp_handler_lock, flag);
+ (*chp->ibcq.comp_handler)(&chp->ibcq, chp->ibcq.cq_context);
+ spin_unlock_irqrestore(&chp->comp_handler_lock, flag);
+ }
}
void c4iw_ev_dispatch(struct c4iw_dev *dev, struct t4_cqe *err_cqe)
--- a/drivers/infiniband/hw/cxgb4/qp.c
+++ b/drivers/infiniband/hw/cxgb4/qp.c
@@ -817,10 +817,12 @@ static void complete_sq_drain_wr(struct
t4_swcq_produce(cq);
spin_unlock_irqrestore(&schp->lock, flag);
- spin_lock_irqsave(&schp->comp_handler_lock, flag);
- (*schp->ibcq.comp_handler)(&schp->ibcq,
- schp->ibcq.cq_context);
- spin_unlock_irqrestore(&schp->comp_handler_lock, flag);
+ if (t4_clear_cq_armed(&schp->cq)) {
+ spin_lock_irqsave(&schp->comp_handler_lock, flag);
+ (*schp->ibcq.comp_handler)(&schp->ibcq,
+ schp->ibcq.cq_context);
+ spin_unlock_irqrestore(&schp->comp_handler_lock, flag);
+ }
}
static void complete_rq_drain_wr(struct c4iw_qp *qhp, struct ib_recv_wr *wr)
@@ -846,10 +848,12 @@ static void complete_rq_drain_wr(struct
t4_swcq_produce(cq);
spin_unlock_irqrestore(&rchp->lock, flag);
- spin_lock_irqsave(&rchp->comp_handler_lock, flag);
- (*rchp->ibcq.comp_handler)(&rchp->ibcq,
- rchp->ibcq.cq_context);
- spin_unlock_irqrestore(&rchp->comp_handler_lock, flag);
+ if (t4_clear_cq_armed(&rchp->cq)) {
+ spin_lock_irqsave(&rchp->comp_handler_lock, flag);
+ (*rchp->ibcq.comp_handler)(&rchp->ibcq,
+ rchp->ibcq.cq_context);
+ spin_unlock_irqrestore(&rchp->comp_handler_lock, flag);
+ }
}
int c4iw_post_send(struct ib_qp *ibqp, struct ib_send_wr *wr,
Patches currently in stable-queue which might be from swise(a)opengridcomputing.com are
queue-4.14/iw_cxgb4-only-clear-the-armed-bit-if-a-notification-is-needed.patch
queue-4.14/iw_cxgb4-atomically-flush-the-qp.patch
queue-4.14/iw_cxgb4-when-flushing-complete-all-wrs-in-a-chain.patch
queue-4.14/iw_cxgb4-reflect-the-original-wr-opcode-in-drain-cqes.patch
queue-4.14/iw_cxgb4-only-call-the-cq-comp_handler-when-the-cq-is-armed.patch
I'm resending with a cover letter as I realize I didn't provide
enough info.
This series fixes critical qp flush bugs in iw_cxgb4. Pleaes apply
to 4.14-stable.
Thanks,
Steve
----
Steve Wise (5):
iw_cxgb4: only call the cq comp_handler when the cq is armed
iw_cxgb4: atomically flush the qp
iw_cxgb4: only clear the ARMED bit if a notification is needed
iw_cxgb4: reflect the original WR opcode in drain cqes
iw_cxgb4: when flushing, complete all wrs in a chain
drivers/infiniband/hw/cxgb4/cq.c | 7 +-
drivers/infiniband/hw/cxgb4/ev.c | 8 ++-
drivers/infiniband/hw/cxgb4/iw_cxgb4.h | 2 -
drivers/infiniband/hw/cxgb4/qp.c | 119 ++++++++++++++++++++++++++-------
drivers/infiniband/hw/cxgb4/t4.h | 6 ++
5 files changed, 107 insertions(+), 35 deletions(-)
--
1.8.3.1
When saving BOs in the hang state we skip one entry of the
kernel_state->bo[] array, thus leaving it to NULL. This leads to a NULL
pointer dereference when, later in this function, we iterate over all
BOs to check their ->madv state.
Fixes: ca26d28bbaa3 ("drm/vc4: improve throughput by pipelining binning and rendering jobs")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
---
drivers/gpu/drm/vc4/vc4_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 6c32c89a83a9..19ac7fe0e5db 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -208,7 +208,7 @@ vc4_save_hang_state(struct drm_device *dev)
kernel_state->bo[j + prev_idx] = &bo->base.base;
j++;
}
- prev_idx = j + 1;
+ prev_idx = j;
}
if (exec[0])
--
2.11.0
This is a note to let you know that I've just added the patch titled
x86/vsdo: Fix build on PARAVIRT_CLOCK=y, KVM_GUEST=n
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:
x86-vsdo-fix-build-on-paravirt_clock-y-kvm_guest-n.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 8705d603edd49f1cff165cd3b7998f4c7f098d27 Mon Sep 17 00:00:00 2001
From: Andy Lutomirski <luto(a)kernel.org>
Date: Tue, 29 Dec 2015 20:12:18 -0800
Subject: x86/vsdo: Fix build on PARAVIRT_CLOCK=y, KVM_GUEST=n
From: Andy Lutomirski <luto(a)kernel.org>
commit 8705d603edd49f1cff165cd3b7998f4c7f098d27 upstream.
arch/x86/built-in.o: In function `arch_setup_additional_pages':
(.text+0x587): undefined reference to `pvclock_pvti_cpu0_va'
KVM_GUEST selects PARAVIRT_CLOCK, so we can make pvclock_pvti_cpu0_va depend
on KVM_GUEST.
Signed-off-by: Andy Lutomirski <luto(a)kernel.org>
Tested-by: Borislav Petkov <bp(a)alien8.de>
Cc: Oleg Nesterov <oleg(a)redhat.com>
Cc: Kees Cook <keescook(a)chromium.org>
Link: http://lkml.kernel.org/r/444d38a9bcba832685740ea1401b569861d09a72.145144656…
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: James Dingwall <james(a)dingwall.me.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/pvclock.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/include/asm/pvclock.h
+++ b/arch/x86/include/asm/pvclock.h
@@ -4,7 +4,7 @@
#include <linux/clocksource.h>
#include <asm/pvclock-abi.h>
-#ifdef CONFIG_PARAVIRT_CLOCK
+#ifdef CONFIG_KVM_GUEST
extern struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void);
#else
static inline struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
Patches currently in stable-queue which might be from luto(a)kernel.org are
queue-4.4/x86-vsdo-fix-build-on-paravirt_clock-y-kvm_guest-n.patch
On 10/01/18 16:04, Felipe Balbi wrote:
>
> Hi,
>
> Roger Quadros <rogerq(a)ti.com> writes:
>>> Roger Quadros <rogerq(a)ti.com> writes:
>>>> Felipe,
>>>>
>>>> On 10/01/18 15:11, Roger Quadros wrote:
>>>>> The USB PHYs should be requested only once during the life cycle of
>>>>> this driver.
>>>>>
>>>>> As dwc3_core_init() is called during system suspend/resume
>>>>> it will result in multiple calls to dwc3_core_get_phy() which is wrong.
>>>>>
>>>>> To prevent that let's move dwc3_core_get_phy() call
>>>>> outside dwc3_core_init().
>>>>>
>>>>> Fixes: 541768b08a4 ("usb: dwc3: core: Call dwc3_core_get_phy() before initializing phys")
>>>>> Cc: linux-stable <stable(a)vger.kernel.org> # >= v4.13
>>>>> Signed-off-by: Roger Quadros <rogerq(a)ti.com>
>>>>
>>>> FYI. this patch brings the code back to
>>>> revert 541768b08a40 ("usb: dwc3: core: Call dwc3_core_get_phy() before initializing phys")
>>>> revert f54edb539c11 ("usb: dwc3: core: initialize ULPI before trying to get the PHY")
>>>>
>>>> So looks like this will break ULPI PHY case?
>>>>
>>>> Where do we initialize ULPI PHY, in dwc3_phy_setup()?
>>>>
>>>> if so then 541768b08a40 breaks the ULPI PHY case as well, right?
>>>
>>> indeed, that commit regressed ULPI PHYs :-(
>>>
>>> Seems like it should be more like below:
>>>
>>> @@ -754,15 +754,15 @@ static int dwc3_core_init(struct dwc3 *dwc)
>>> dwc->maximum_speed = USB_SPEED_HIGH;
>>> }
>>>
>>> - ret = dwc3_core_get_phy(dwc);
>>> + ret = dwc3_phy_setup(dwc);
>>
>> But can we do a dwc3_phy_setup() without doing the soft reset of the controller first?
>
> as long as clocks are running, we can do that, yes.
>
>>> - ret = dwc3_core_soft_reset(dwc);
>>> + ret = dwc3_core_get_phy(dwc);
>>
>> we can get_phy in dwc3_core_init() as it will get called on resume().
>> This was the $subject of this patch.
>
> indeed. thanks :-)
>
oops sorry. I meant we can't call dwc3_core_get_phy() in dwc3_core_init(). :P
--
cheers,
-roger
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 10/01/18 15:33, Felipe Balbi wrote:
>
> Hi,
>
> Roger Quadros <rogerq(a)ti.com> writes:
>> Felipe,
>>
>> On 10/01/18 15:11, Roger Quadros wrote:
>>> The USB PHYs should be requested only once during the life cycle of
>>> this driver.
>>>
>>> As dwc3_core_init() is called during system suspend/resume
>>> it will result in multiple calls to dwc3_core_get_phy() which is wrong.
>>>
>>> To prevent that let's move dwc3_core_get_phy() call
>>> outside dwc3_core_init().
>>>
>>> Fixes: 541768b08a4 ("usb: dwc3: core: Call dwc3_core_get_phy() before initializing phys")
>>> Cc: linux-stable <stable(a)vger.kernel.org> # >= v4.13
>>> Signed-off-by: Roger Quadros <rogerq(a)ti.com>
>>
>> FYI. this patch brings the code back to
>> revert 541768b08a40 ("usb: dwc3: core: Call dwc3_core_get_phy() before initializing phys")
>> revert f54edb539c11 ("usb: dwc3: core: initialize ULPI before trying to get the PHY")
>>
>> So looks like this will break ULPI PHY case?
>>
>> Where do we initialize ULPI PHY, in dwc3_phy_setup()?
>>
>> if so then 541768b08a40 breaks the ULPI PHY case as well, right?
>
> indeed, that commit regressed ULPI PHYs :-(
>
> Seems like it should be more like below:
>
> @@ -754,15 +754,15 @@ static int dwc3_core_init(struct dwc3 *dwc)
> dwc->maximum_speed = USB_SPEED_HIGH;
> }
>
> - ret = dwc3_core_get_phy(dwc);
> + ret = dwc3_phy_setup(dwc);
But can we do a dwc3_phy_setup() without doing the soft reset of the controller first?
> if (ret)
> goto err0;
>
> - ret = dwc3_core_soft_reset(dwc);
> + ret = dwc3_core_get_phy(dwc);
we can get_phy in dwc3_core_init() as it will get called on resume().
This was the $subject of this patch.
> if (ret)
> goto err0;
>
> - ret = dwc3_phy_setup(dwc);
> + ret = dwc3_core_soft_reset(dwc);
> if (ret)
> goto err0;
>
> And maybe we rename dwc3_phy_setup() to dwc3_phy_intf_config() just to
> make the name match what the function actually does. Can you check that
> it won't regress the case reported by Carlos? If that works, then we
> would have to move BOTH dwc3_phy_setup() (dwc3_phy_intf_config()) and
> dwc3_core_get_phy() outside of dwc3_core_init(), which would mean
> duplicated code in suspend/resume handlers.
>
> I'm sure we can sort that out in another way; but the proper order is:
>
> -> initialize ULPI (if necessary)
> -> get phy
> -> soft reset
>
--
cheers,
-roger
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
The USB PHYs should be requested only once during the life cycle of
this driver.
As dwc3_core_init() is called during system suspend/resume
it will result in multiple calls to dwc3_core_get_phy() which is wrong.
To prevent that let's move dwc3_core_get_phy() call
outside dwc3_core_init().
Fixes: 541768b08a4 ("usb: dwc3: core: Call dwc3_core_get_phy() before initializing phys")
Cc: linux-stable <stable(a)vger.kernel.org> # >= v4.13
Signed-off-by: Roger Quadros <rogerq(a)ti.com>
---
drivers/usb/dwc3/core.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 0783250..1274251 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -722,8 +722,6 @@ static void dwc3_core_setup_global_control(struct dwc3 *dwc)
dwc3_writel(dwc->regs, DWC3_GCTL, reg);
}
-static int dwc3_core_get_phy(struct dwc3 *dwc);
-
/**
* dwc3_core_init - Low-level initialization of DWC3 Core
* @dwc: Pointer to our controller context structure
@@ -754,10 +752,6 @@ static int dwc3_core_init(struct dwc3 *dwc)
dwc->maximum_speed = USB_SPEED_HIGH;
}
- ret = dwc3_core_get_phy(dwc);
- if (ret)
- goto err0;
-
ret = dwc3_core_soft_reset(dwc);
if (ret)
goto err0;
@@ -1177,6 +1171,10 @@ static int dwc3_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, dwc);
dwc3_cache_hwparams(dwc);
+ ret = dwc3_core_get_phy(dwc);
+ if (ret)
+ goto err0;
+
spin_lock_init(&dwc->lock);
pm_runtime_set_active(dev);
--
cheers,
-roger
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
This is a note to let you know that I've just added the patch titled
module: Issue warnings when tainting kernel
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:
module-issue-warnings-when-tainting-kernel.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 3205c36cf7d96024626f92d65f560035df1abcb2 Mon Sep 17 00:00:00 2001
From: Libor Pechacek <lpechacek(a)suse.com>
Date: Wed, 13 Apr 2016 11:06:12 +0930
Subject: module: Issue warnings when tainting kernel
From: Libor Pechacek <lpechacek(a)suse.com>
commit 3205c36cf7d96024626f92d65f560035df1abcb2 upstream.
While most of the locations where a kernel taint bit is set are accompanied
with a warning message, there are two which set their bits silently. If
the tainting module gets unloaded later on, it is almost impossible to tell
what was the reason for setting the flag.
Signed-off-by: Libor Pechacek <lpechacek(a)suse.com>
Signed-off-by: Rusty Russell <rusty(a)rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/module.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2888,8 +2888,12 @@ static int check_modinfo(struct module *
return -ENOEXEC;
}
- if (!get_modinfo(info, "intree"))
+ if (!get_modinfo(info, "intree")) {
+ if (!test_taint(TAINT_OOT_MODULE))
+ pr_warn("%s: loading out-of-tree module taints kernel.\n",
+ mod->name);
add_taint_module(mod, TAINT_OOT_MODULE, LOCKDEP_STILL_OK);
+ }
if (get_modinfo(info, "staging")) {
add_taint_module(mod, TAINT_CRAP, LOCKDEP_STILL_OK);
@@ -3054,6 +3058,8 @@ static int move_module(struct module *mo
static int check_module_license_and_versions(struct module *mod)
{
+ int prev_taint = test_taint(TAINT_PROPRIETARY_MODULE);
+
/*
* ndiswrapper is under GPL by itself, but loads proprietary modules.
* Don't use add_taint_module(), as it would prevent ndiswrapper from
@@ -3072,6 +3078,9 @@ static int check_module_license_and_vers
add_taint_module(mod, TAINT_PROPRIETARY_MODULE,
LOCKDEP_NOW_UNRELIABLE);
+ if (!prev_taint && test_taint(TAINT_PROPRIETARY_MODULE))
+ pr_warn("%s: module license taints kernel.\n", mod->name);
+
#ifdef CONFIG_MODVERSIONS
if ((mod->num_syms && !mod->crcs)
|| (mod->num_gpl_syms && !mod->gpl_crcs)
Patches currently in stable-queue which might be from lpechacek(a)suse.com are
queue-4.4/module-issue-warnings-when-tainting-kernel.patch
This is a note to let you know that I've just added the patch titled
platform/x86: wmi: Call acpi_wmi_init() later
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:
platform-x86-wmi-call-acpi_wmi_init-later.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 98b8e4e5c17bf87c1b18ed929472051dab39878c Mon Sep 17 00:00:00 2001
From: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com>
Date: Wed, 3 Jan 2018 12:49:29 +0100
Subject: platform/x86: wmi: Call acpi_wmi_init() later
From: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
commit 98b8e4e5c17bf87c1b18ed929472051dab39878c upstream.
Calling acpi_wmi_init() at the subsys_initcall() level causes ordering
issues to appear on some systems and they are difficult to reproduce,
because there is no guaranteed ordering between subsys_initcall()
calls, so they may occur in different orders on different systems.
In particular, commit 86d9f48534e8 (mm/slab: fix kmemcg cache
creation delayed issue) exposed one of these issues where genl_init()
and acpi_wmi_init() are both called at the same initcall level, but
the former must run before the latter so as to avoid a NULL pointer
dereference.
For this reason, move the acpi_wmi_init() invocation to the
initcall_sync level which should still be early enough for things
to work correctly in the WMI land.
Link: https://marc.info/?t=151274596700002&r=1&w=2
Reported-by: Jonathan McDowell <noodles(a)earth.li>
Reported-by: Joonsoo Kim <iamjoonsoo.kim(a)lge.com>
Tested-by: Jonathan McDowell <noodles(a)earth.li>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Darren Hart (VMware) <dvhart(a)infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/platform/x86/wmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/platform/x86/wmi.c
+++ b/drivers/platform/x86/wmi.c
@@ -848,5 +848,5 @@ static void __exit acpi_wmi_exit(void)
pr_info("Mapper unloaded\n");
}
-subsys_initcall(acpi_wmi_init);
+subsys_initcall_sync(acpi_wmi_init);
module_exit(acpi_wmi_exit);
Patches currently in stable-queue which might be from rafael.j.wysocki(a)intel.com are
queue-4.9/platform-x86-wmi-call-acpi_wmi_init-later.patch
This is a note to let you know that I've just added the patch titled
MIPS: Validate PR_SET_FP_MODE prctl(2) requests against the ABI of the task
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:
mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.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 b67336eee3fcb8ecedc6c13e2bf88aacfa3151e2 Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 27 Nov 2017 09:33:03 +0000
Subject: MIPS: Validate PR_SET_FP_MODE prctl(2) requests against the ABI of the task
From: Maciej W. Rozycki <macro(a)mips.com>
commit b67336eee3fcb8ecedc6c13e2bf88aacfa3151e2 upstream.
Fix an API loophole introduced with commit 9791554b45a2 ("MIPS,prctl:
add PR_[GS]ET_FP_MODE prctl options for MIPS"), where the caller of
prctl(2) is incorrectly allowed to make a change to CP0.Status.FR or
CP0.Config5.FRE register bits even if CONFIG_MIPS_O32_FP64_SUPPORT has
not been enabled, despite that an executable requesting the mode
requested via ELF file annotation would not be allowed to run in the
first place, or for n64 and n64 ABI tasks which do not have non-default
modes defined at all. Add suitable checks to `mips_set_process_fp_mode'
and bail out if an invalid mode change has been requested for the ABI in
effect, even if the FPU hardware or emulation would otherwise allow it.
Always succeed however without taking any further action if the mode
requested is the same as one already in effect, regardless of whether
any mode change, should it be requested, would actually be allowed for
the task concerned.
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS")
Reviewed-by: Paul Burton <paul.burton(a)mips.com>
Cc: James Hogan <james.hogan(a)mips.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17800/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/process.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/arch/mips/kernel/process.c
+++ b/arch/mips/kernel/process.c
@@ -683,6 +683,18 @@ int mips_set_process_fp_mode(struct task
struct task_struct *t;
int max_users;
+ /* If nothing to change, return right away, successfully. */
+ if (value == mips_get_process_fp_mode(task))
+ return 0;
+
+ /* Only accept a mode change if 64-bit FP enabled for o32. */
+ if (!IS_ENABLED(CONFIG_MIPS_O32_FP64_SUPPORT))
+ return -EOPNOTSUPP;
+
+ /* And only for o32 tasks. */
+ if (IS_ENABLED(CONFIG_64BIT) && !test_thread_flag(TIF_32BIT_REGS))
+ return -EOPNOTSUPP;
+
/* Check the value is valid */
if (value & ~known_bits)
return -EOPNOTSUPP;
Patches currently in stable-queue which might be from macro(a)mips.com are
queue-4.9/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch
queue-4.9/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch
queue-4.9/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch
queue-4.9/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch
queue-4.9/mips-factor-out-nt_prfpreg-regset-access-helpers.patch
queue-4.9/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch
queue-4.9/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch
This is a note to let you know that I've just added the patch titled
MIPS: Guard against any partial write attempt with PTRACE_SETREGSET
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:
mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.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 dc24d0edf33c3e15099688b6bbdf7bdc24bf6e91 Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 11 Dec 2017 22:52:15 +0000
Subject: MIPS: Guard against any partial write attempt with PTRACE_SETREGSET
From: Maciej W. Rozycki <macro(a)mips.com>
commit dc24d0edf33c3e15099688b6bbdf7bdc24bf6e91 upstream.
Complement commit d614fd58a283 ("mips/ptrace: Preserve previous
registers for short regset write") and ensure that no partial register
write attempt is made with PTRACE_SETREGSET, as we do not preinitialize
any temporaries used to hold incoming register data and consequently
random data could be written.
It is the responsibility of the caller, such as `ptrace_regset', to
arrange for writes to span whole registers only, so here we only assert
that it has indeed happened.
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset")
Cc: James Hogan <james.hogan(a)mips.com>
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Alex Smith <alex(a)alex-smith.me.uk>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17926/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/ptrace.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -536,7 +536,15 @@ static int fpr_set_msa(struct task_struc
return 0;
}
-/* Copy the supplied NT_PRFPREG buffer to the floating-point context. */
+/*
+ * Copy the supplied NT_PRFPREG buffer to the floating-point context.
+ *
+ * We optimize for the case where `count % sizeof(elf_fpreg_t) == 0',
+ * which is supposed to have been guaranteed by the kernel before
+ * calling us, e.g. in `ptrace_regset'. We enforce that requirement,
+ * so that we can safely avoid preinitializing temporaries for
+ * partial register writes.
+ */
static int fpr_set(struct task_struct *target,
const struct user_regset *regset,
unsigned int pos, unsigned int count,
@@ -544,6 +552,8 @@ static int fpr_set(struct task_struct *t
{
int err;
+ BUG_ON(count % sizeof(elf_fpreg_t));
+
/* XXX fcr31 */
init_fp_ctx(target);
Patches currently in stable-queue which might be from macro(a)mips.com are
queue-4.9/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch
queue-4.9/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch
queue-4.9/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch
queue-4.9/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch
queue-4.9/mips-factor-out-nt_prfpreg-regset-access-helpers.patch
queue-4.9/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch
queue-4.9/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch
This is a note to let you know that I've just added the patch titled
MIPS: Fix an FCSR access API regression with NT_PRFPREG and MSA
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:
mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.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 be07a6a1188372b6d19a3307ec33211fc9c9439d Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 11 Dec 2017 22:54:33 +0000
Subject: MIPS: Fix an FCSR access API regression with NT_PRFPREG and MSA
From: Maciej W. Rozycki <macro(a)mips.com>
commit be07a6a1188372b6d19a3307ec33211fc9c9439d upstream.
Fix a commit 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for
FP regset") public API regression, then activated by commit 1db1af84d6df
("MIPS: Basic MSA context switching support"), that caused the FCSR
register not to be read or written for CONFIG_CPU_HAS_MSA kernel
configurations (regardless of actual presence or absence of the MSA
feature in a given processor) with ptrace(2) PTRACE_GETREGSET and
PTRACE_SETREGSET requests nor recorded in core dumps.
This is because with !CONFIG_CPU_HAS_MSA configurations the whole of
`elf_fpregset_t' array is bulk-copied as it is, which includes the FCSR
in one half of the last, 33rd slot, whereas with CONFIG_CPU_HAS_MSA
configurations array elements are copied individually, and then only the
leading 32 FGR slots while the remaining slot is ignored.
Correct the code then such that only FGR slots are copied in the
respective !MSA and MSA helpers an then the FCSR slot is handled
separately in common code. Use `ptrace_setfcr31' to update the FCSR
too, so that the read-only mask is respected.
Retrieving a correct value of FCSR is important in debugging not only
for the human to be able to get the right interpretation of the
situation, but for correct operation of GDB as well. This is because
the condition code bits in FSCR are used by GDB to determine the
location to place a breakpoint at when single-stepping through an FPU
branch instruction. If such a breakpoint is placed incorrectly (i.e.
with the condition reversed), then it will be missed, likely causing the
debuggee to run away from the control of GDB and consequently breaking
the process of investigation.
Fortunately GDB continues using the older PTRACE_GETFPREGS ptrace(2)
request which is unaffected, so the regression only really hits with
post-mortem debug sessions using a core dump file, in which case
execution, and consequently single-stepping through branches is not
possible. Of course core files created by buggy kernels out there will
have the value of FCSR recorded clobbered, but such core files cannot be
corrected and the person using them simply will have to be aware that
the value of FCSR retrieved is not reliable.
Which also means we can likely get away without defining a replacement
API which would ensure a correct value of FSCR to be retrieved, or none
at all.
This is based on previous work by Alex Smith, extensively rewritten.
Signed-off-by: Alex Smith <alex(a)alex-smith.me.uk>
Signed-off-by: James Hogan <james.hogan(a)mips.com>
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset")
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17928/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/ptrace.c | 47 +++++++++++++++++++++++++++++++++++-----------
1 file changed, 36 insertions(+), 11 deletions(-)
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -442,7 +442,7 @@ static int gpr64_set(struct task_struct
/*
* Copy the floating-point context to the supplied NT_PRFPREG buffer,
* !CONFIG_CPU_HAS_MSA variant. FP context's general register slots
- * correspond 1:1 to buffer slots.
+ * correspond 1:1 to buffer slots. Only general registers are copied.
*/
static int fpr_get_fpa(struct task_struct *target,
unsigned int *pos, unsigned int *count,
@@ -450,13 +450,14 @@ static int fpr_get_fpa(struct task_struc
{
return user_regset_copyout(pos, count, kbuf, ubuf,
&target->thread.fpu,
- 0, sizeof(elf_fpregset_t));
+ 0, NUM_FPU_REGS * sizeof(elf_fpreg_t));
}
/*
* Copy the floating-point context to the supplied NT_PRFPREG buffer,
* CONFIG_CPU_HAS_MSA variant. Only lower 64 bits of FP context's
- * general register slots are copied to buffer slots.
+ * general register slots are copied to buffer slots. Only general
+ * registers are copied.
*/
static int fpr_get_msa(struct task_struct *target,
unsigned int *pos, unsigned int *count,
@@ -478,20 +479,29 @@ static int fpr_get_msa(struct task_struc
return 0;
}
-/* Copy the floating-point context to the supplied NT_PRFPREG buffer. */
+/*
+ * Copy the floating-point context to the supplied NT_PRFPREG buffer.
+ * Choose the appropriate helper for general registers, and then copy
+ * the FCSR register separately.
+ */
static int fpr_get(struct task_struct *target,
const struct user_regset *regset,
unsigned int pos, unsigned int count,
void *kbuf, void __user *ubuf)
{
+ const int fcr31_pos = NUM_FPU_REGS * sizeof(elf_fpreg_t);
int err;
- /* XXX fcr31 */
-
if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t))
err = fpr_get_fpa(target, &pos, &count, &kbuf, &ubuf);
else
err = fpr_get_msa(target, &pos, &count, &kbuf, &ubuf);
+ if (err)
+ return err;
+
+ err = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.fpu.fcr31,
+ fcr31_pos, fcr31_pos + sizeof(u32));
return err;
}
@@ -499,7 +509,7 @@ static int fpr_get(struct task_struct *t
/*
* Copy the supplied NT_PRFPREG buffer to the floating-point context,
* !CONFIG_CPU_HAS_MSA variant. Buffer slots correspond 1:1 to FP
- * context's general register slots.
+ * context's general register slots. Only general registers are copied.
*/
static int fpr_set_fpa(struct task_struct *target,
unsigned int *pos, unsigned int *count,
@@ -507,13 +517,14 @@ static int fpr_set_fpa(struct task_struc
{
return user_regset_copyin(pos, count, kbuf, ubuf,
&target->thread.fpu,
- 0, sizeof(elf_fpregset_t));
+ 0, NUM_FPU_REGS * sizeof(elf_fpreg_t));
}
/*
* Copy the supplied NT_PRFPREG buffer to the floating-point context,
* CONFIG_CPU_HAS_MSA variant. Buffer slots are copied to lower 64
- * bits only of FP context's general register slots.
+ * bits only of FP context's general register slots. Only general
+ * registers are copied.
*/
static int fpr_set_msa(struct task_struct *target,
unsigned int *pos, unsigned int *count,
@@ -538,6 +549,8 @@ static int fpr_set_msa(struct task_struc
/*
* Copy the supplied NT_PRFPREG buffer to the floating-point context.
+ * Choose the appropriate helper for general registers, and then copy
+ * the FCSR register separately.
*
* We optimize for the case where `count % sizeof(elf_fpreg_t) == 0',
* which is supposed to have been guaranteed by the kernel before
@@ -550,18 +563,30 @@ static int fpr_set(struct task_struct *t
unsigned int pos, unsigned int count,
const void *kbuf, const void __user *ubuf)
{
+ const int fcr31_pos = NUM_FPU_REGS * sizeof(elf_fpreg_t);
+ u32 fcr31;
int err;
BUG_ON(count % sizeof(elf_fpreg_t));
- /* XXX fcr31 */
-
init_fp_ctx(target);
if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t))
err = fpr_set_fpa(target, &pos, &count, &kbuf, &ubuf);
else
err = fpr_set_msa(target, &pos, &count, &kbuf, &ubuf);
+ if (err)
+ return err;
+
+ if (count > 0) {
+ err = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &fcr31,
+ fcr31_pos, fcr31_pos + sizeof(u32));
+ if (err)
+ return err;
+
+ ptrace_setfcr31(target, fcr31);
+ }
return err;
}
Patches currently in stable-queue which might be from macro(a)mips.com are
queue-4.9/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch
queue-4.9/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch
queue-4.9/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch
queue-4.9/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch
queue-4.9/mips-factor-out-nt_prfpreg-regset-access-helpers.patch
queue-4.9/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch
queue-4.9/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch
This is a note to let you know that I've just added the patch titled
MIPS: Factor out NT_PRFPREG regset access helpers
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:
mips-factor-out-nt_prfpreg-regset-access-helpers.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 a03fe72572c12e98f4173f8a535f32468e48b6ec Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 11 Dec 2017 22:51:35 +0000
Subject: MIPS: Factor out NT_PRFPREG regset access helpers
From: Maciej W. Rozycki <macro(a)mips.com>
commit a03fe72572c12e98f4173f8a535f32468e48b6ec upstream.
In preparation to fix a commit 72b22bbad1e7 ("MIPS: Don't assume 64-bit
FP registers for FP regset") FCSR access regression factor out
NT_PRFPREG regset access helpers for the non-MSA and the MSA variants
respectively, to avoid having to deal with excessive indentation in the
actual fix.
No functional change, however use `target->thread.fpu.fpr[0]' rather
than `target->thread.fpu.fpr[i]' for FGR holding type size determination
as there's no `i' variable to refer to anymore, and for the factored out
`i' variable declaration use `unsigned int' rather than `unsigned' as
its type, following the common style.
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset")
Cc: James Hogan <james.hogan(a)mips.com>
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Alex Smith <alex(a)alex-smith.me.uk>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17925/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/ptrace.c | 108 +++++++++++++++++++++++++++++++++++-----------
1 file changed, 83 insertions(+), 25 deletions(-)
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -439,25 +439,36 @@ static int gpr64_set(struct task_struct
#endif /* CONFIG_64BIT */
-static int fpr_get(struct task_struct *target,
- const struct user_regset *regset,
- unsigned int pos, unsigned int count,
- void *kbuf, void __user *ubuf)
+/*
+ * Copy the floating-point context to the supplied NT_PRFPREG buffer,
+ * !CONFIG_CPU_HAS_MSA variant. FP context's general register slots
+ * correspond 1:1 to buffer slots.
+ */
+static int fpr_get_fpa(struct task_struct *target,
+ unsigned int *pos, unsigned int *count,
+ void **kbuf, void __user **ubuf)
{
- unsigned i;
- int err;
- u64 fpr_val;
-
- /* XXX fcr31 */
+ return user_regset_copyout(pos, count, kbuf, ubuf,
+ &target->thread.fpu,
+ 0, sizeof(elf_fpregset_t));
+}
- if (sizeof(target->thread.fpu.fpr[i]) == sizeof(elf_fpreg_t))
- return user_regset_copyout(&pos, &count, &kbuf, &ubuf,
- &target->thread.fpu,
- 0, sizeof(elf_fpregset_t));
+/*
+ * Copy the floating-point context to the supplied NT_PRFPREG buffer,
+ * CONFIG_CPU_HAS_MSA variant. Only lower 64 bits of FP context's
+ * general register slots are copied to buffer slots.
+ */
+static int fpr_get_msa(struct task_struct *target,
+ unsigned int *pos, unsigned int *count,
+ void **kbuf, void __user **ubuf)
+{
+ unsigned int i;
+ u64 fpr_val;
+ int err;
for (i = 0; i < NUM_FPU_REGS; i++) {
fpr_val = get_fpr64(&target->thread.fpu.fpr[i], 0);
- err = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ err = user_regset_copyout(pos, count, kbuf, ubuf,
&fpr_val, i * sizeof(elf_fpreg_t),
(i + 1) * sizeof(elf_fpreg_t));
if (err)
@@ -467,27 +478,54 @@ static int fpr_get(struct task_struct *t
return 0;
}
-static int fpr_set(struct task_struct *target,
+/* Copy the floating-point context to the supplied NT_PRFPREG buffer. */
+static int fpr_get(struct task_struct *target,
const struct user_regset *regset,
unsigned int pos, unsigned int count,
- const void *kbuf, const void __user *ubuf)
+ void *kbuf, void __user *ubuf)
{
- unsigned i;
int err;
- u64 fpr_val;
/* XXX fcr31 */
- init_fp_ctx(target);
+ if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t))
+ err = fpr_get_fpa(target, &pos, &count, &kbuf, &ubuf);
+ else
+ err = fpr_get_msa(target, &pos, &count, &kbuf, &ubuf);
+
+ return err;
+}
- if (sizeof(target->thread.fpu.fpr[i]) == sizeof(elf_fpreg_t))
- return user_regset_copyin(&pos, &count, &kbuf, &ubuf,
- &target->thread.fpu,
- 0, sizeof(elf_fpregset_t));
+/*
+ * Copy the supplied NT_PRFPREG buffer to the floating-point context,
+ * !CONFIG_CPU_HAS_MSA variant. Buffer slots correspond 1:1 to FP
+ * context's general register slots.
+ */
+static int fpr_set_fpa(struct task_struct *target,
+ unsigned int *pos, unsigned int *count,
+ const void **kbuf, const void __user **ubuf)
+{
+ return user_regset_copyin(pos, count, kbuf, ubuf,
+ &target->thread.fpu,
+ 0, sizeof(elf_fpregset_t));
+}
+
+/*
+ * Copy the supplied NT_PRFPREG buffer to the floating-point context,
+ * CONFIG_CPU_HAS_MSA variant. Buffer slots are copied to lower 64
+ * bits only of FP context's general register slots.
+ */
+static int fpr_set_msa(struct task_struct *target,
+ unsigned int *pos, unsigned int *count,
+ const void **kbuf, const void __user **ubuf)
+{
+ unsigned int i;
+ u64 fpr_val;
+ int err;
BUILD_BUG_ON(sizeof(fpr_val) != sizeof(elf_fpreg_t));
- for (i = 0; i < NUM_FPU_REGS && count >= sizeof(elf_fpreg_t); i++) {
- err = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ for (i = 0; i < NUM_FPU_REGS && *count >= sizeof(elf_fpreg_t); i++) {
+ err = user_regset_copyin(pos, count, kbuf, ubuf,
&fpr_val, i * sizeof(elf_fpreg_t),
(i + 1) * sizeof(elf_fpreg_t));
if (err)
@@ -498,6 +536,26 @@ static int fpr_set(struct task_struct *t
return 0;
}
+/* Copy the supplied NT_PRFPREG buffer to the floating-point context. */
+static int fpr_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf)
+{
+ int err;
+
+ /* XXX fcr31 */
+
+ init_fp_ctx(target);
+
+ if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t))
+ err = fpr_set_fpa(target, &pos, &count, &kbuf, &ubuf);
+ else
+ err = fpr_set_msa(target, &pos, &count, &kbuf, &ubuf);
+
+ return err;
+}
+
enum mips_regset {
REGSET_GPR,
REGSET_FPR,
Patches currently in stable-queue which might be from macro(a)mips.com are
queue-4.9/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch
queue-4.9/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch
queue-4.9/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch
queue-4.9/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch
queue-4.9/mips-factor-out-nt_prfpreg-regset-access-helpers.patch
queue-4.9/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch
queue-4.9/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch
This is a note to let you know that I've just added the patch titled
MIPS: Disallow outsized PTRACE_SETREGSET NT_PRFPREG regset accesses
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:
mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.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 c8c5a3a24d395b14447a9a89d61586a913840a3b Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 11 Dec 2017 22:56:54 +0000
Subject: MIPS: Disallow outsized PTRACE_SETREGSET NT_PRFPREG regset accesses
From: Maciej W. Rozycki <macro(a)mips.com>
commit c8c5a3a24d395b14447a9a89d61586a913840a3b upstream.
Complement commit c23b3d1a5311 ("MIPS: ptrace: Change GP regset to use
correct core dump register layout") and also reject outsized
PTRACE_SETREGSET requests to the NT_PRFPREG regset, like with the
NT_PRSTATUS regset.
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: c23b3d1a5311 ("MIPS: ptrace: Change GP regset to use correct core dump register layout")
Cc: James Hogan <james.hogan(a)mips.com>
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Alex Smith <alex(a)alex-smith.me.uk>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17930/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/ptrace.c | 3 +++
1 file changed, 3 insertions(+)
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -570,6 +570,9 @@ static int fpr_set(struct task_struct *t
BUG_ON(count % sizeof(elf_fpreg_t));
+ if (pos + count > sizeof(elf_fpregset_t))
+ return -EIO;
+
init_fp_ctx(target);
if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t))
Patches currently in stable-queue which might be from macro(a)mips.com are
queue-4.9/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch
queue-4.9/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch
queue-4.9/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch
queue-4.9/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch
queue-4.9/mips-factor-out-nt_prfpreg-regset-access-helpers.patch
queue-4.9/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch
queue-4.9/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch
This is a note to let you know that I've just added the patch titled
MIPS: Consistently handle buffer counter with PTRACE_SETREGSET
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:
mips-consistently-handle-buffer-counter-with-ptrace_setregset.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 80b3ffce0196ea50068885d085ff981e4b8396f4 Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 11 Dec 2017 22:53:14 +0000
Subject: MIPS: Consistently handle buffer counter with PTRACE_SETREGSET
From: Maciej W. Rozycki <macro(a)mips.com>
commit 80b3ffce0196ea50068885d085ff981e4b8396f4 upstream.
Update commit d614fd58a283 ("mips/ptrace: Preserve previous registers
for short regset write") bug and consistently consume all data supplied
to `fpr_set_msa' with the ptrace(2) PTRACE_SETREGSET request, such that
a zero data buffer counter is returned where insufficient data has been
given to fill a whole number of FP general registers.
In reality this is not going to happen, as the caller is supposed to
only supply data covering a whole number of registers and it is verified
in `ptrace_regset' and again asserted in `fpr_set', however structuring
code such that the presence of trailing partial FP general register data
causes `fpr_set_msa' to return with a non-zero data buffer counter makes
it appear that this trailing data will be used if there are subsequent
writes made to FP registers, which is going to be the case with the FCSR
once the missing write to that register has been fixed.
Fixes: d614fd58a283 ("mips/ptrace: Preserve previous registers for short regset write")
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Cc: James Hogan <james.hogan(a)mips.com>
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Alex Smith <alex(a)alex-smith.me.uk>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17927/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/ptrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -524,7 +524,7 @@ static int fpr_set_msa(struct task_struc
int err;
BUILD_BUG_ON(sizeof(fpr_val) != sizeof(elf_fpreg_t));
- for (i = 0; i < NUM_FPU_REGS && *count >= sizeof(elf_fpreg_t); i++) {
+ for (i = 0; i < NUM_FPU_REGS && *count > 0; i++) {
err = user_regset_copyin(pos, count, kbuf, ubuf,
&fpr_val, i * sizeof(elf_fpreg_t),
(i + 1) * sizeof(elf_fpreg_t));
Patches currently in stable-queue which might be from macro(a)mips.com are
queue-4.9/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch
queue-4.9/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch
queue-4.9/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch
queue-4.9/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch
queue-4.9/mips-factor-out-nt_prfpreg-regset-access-helpers.patch
queue-4.9/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch
queue-4.9/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch
This is a note to let you know that I've just added the patch titled
MIPS: Also verify sizeof `elf_fpreg_t' with PTRACE_SETREGSET
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:
mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.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 006501e039eec411842bb3150c41358867d320c2 Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 11 Dec 2017 22:55:40 +0000
Subject: MIPS: Also verify sizeof `elf_fpreg_t' with PTRACE_SETREGSET
From: Maciej W. Rozycki <macro(a)mips.com>
commit 006501e039eec411842bb3150c41358867d320c2 upstream.
Complement commit d614fd58a283 ("mips/ptrace: Preserve previous
registers for short regset write") and like with the PTRACE_GETREGSET
ptrace(2) request also apply a BUILD_BUG_ON check for the size of the
`elf_fpreg_t' type in the PTRACE_SETREGSET request handler.
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: d614fd58a283 ("mips/ptrace: Preserve previous registers for short regset write")
Cc: James Hogan <james.hogan(a)mips.com>
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Alex Smith <alex(a)alex-smith.me.uk>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17929/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/ptrace.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -467,6 +467,7 @@ static int fpr_get_msa(struct task_struc
u64 fpr_val;
int err;
+ BUILD_BUG_ON(sizeof(fpr_val) != sizeof(elf_fpreg_t));
for (i = 0; i < NUM_FPU_REGS; i++) {
fpr_val = get_fpr64(&target->thread.fpu.fpr[i], 0);
err = user_regset_copyout(pos, count, kbuf, ubuf,
Patches currently in stable-queue which might be from macro(a)mips.com are
queue-4.9/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch
queue-4.9/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch
queue-4.9/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch
queue-4.9/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch
queue-4.9/mips-factor-out-nt_prfpreg-regset-access-helpers.patch
queue-4.9/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch
queue-4.9/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch
This is a note to let you know that I've just added the patch titled
IB/srpt: Disable RDMA access by the initiator
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ib-srpt-disable-rdma-access-by-the-initiator.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 bec40c26041de61162f7be9d2ce548c756ce0f65 Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Wed, 3 Jan 2018 13:39:15 -0800
Subject: IB/srpt: Disable RDMA access by the initiator
From: Bart Van Assche <bart.vanassche(a)wdc.com>
commit bec40c26041de61162f7be9d2ce548c756ce0f65 upstream.
With the SRP protocol all RDMA operations are initiated by the target.
Since no RDMA operations are initiated by the initiator, do not grant
the initiator permission to submit RDMA reads or writes to the target.
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/ulp/srpt/ib_srpt.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
@@ -992,8 +992,7 @@ static int srpt_init_ch_qp(struct srpt_r
return -ENOMEM;
attr->qp_state = IB_QPS_INIT;
- attr->qp_access_flags = IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_READ |
- IB_ACCESS_REMOTE_WRITE;
+ attr->qp_access_flags = IB_ACCESS_LOCAL_WRITE;
attr->port_num = ch->sport->port;
attr->pkey_index = 0;
Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are
queue-4.9/ib-srpt-disable-rdma-access-by-the-initiator.patch
This is a note to let you know that I've just added the patch titled
can: gs_usb: fix return value of the "set_bittiming" callback
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:
can-gs_usb-fix-return-value-of-the-set_bittiming-callback.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 d5b42e6607661b198d8b26a0c30969605b1bf5c7 Mon Sep 17 00:00:00 2001
From: Wolfgang Grandegger <wg(a)grandegger.com>
Date: Wed, 13 Dec 2017 19:52:23 +0100
Subject: can: gs_usb: fix return value of the "set_bittiming" callback
From: Wolfgang Grandegger <wg(a)grandegger.com>
commit d5b42e6607661b198d8b26a0c30969605b1bf5c7 upstream.
The "set_bittiming" callback treats a positive return value as error!
For that reason "can_changelink()" will quit silently after setting
the bittiming values without processing ctrlmode, restart-ms, etc.
Signed-off-by: Wolfgang Grandegger <wg(a)grandegger.com>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/usb/gs_usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/can/usb/gs_usb.c
+++ b/drivers/net/can/usb/gs_usb.c
@@ -449,7 +449,7 @@ static int gs_usb_set_bittiming(struct n
dev_err(netdev->dev.parent, "Couldn't set bittimings (err=%d)",
rc);
- return rc;
+ return (rc > 0) ? 0 : rc;
}
static void gs_usb_xmit_callback(struct urb *urb)
Patches currently in stable-queue which might be from wg(a)grandegger.com are
queue-4.9/can-gs_usb-fix-return-value-of-the-set_bittiming-callback.patch
This is a note to let you know that I've just added the patch titled
MIPS: Validate PR_SET_FP_MODE prctl(2) requests against the ABI of the task
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:
mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.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 b67336eee3fcb8ecedc6c13e2bf88aacfa3151e2 Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 27 Nov 2017 09:33:03 +0000
Subject: MIPS: Validate PR_SET_FP_MODE prctl(2) requests against the ABI of the task
From: Maciej W. Rozycki <macro(a)mips.com>
commit b67336eee3fcb8ecedc6c13e2bf88aacfa3151e2 upstream.
Fix an API loophole introduced with commit 9791554b45a2 ("MIPS,prctl:
add PR_[GS]ET_FP_MODE prctl options for MIPS"), where the caller of
prctl(2) is incorrectly allowed to make a change to CP0.Status.FR or
CP0.Config5.FRE register bits even if CONFIG_MIPS_O32_FP64_SUPPORT has
not been enabled, despite that an executable requesting the mode
requested via ELF file annotation would not be allowed to run in the
first place, or for n64 and n64 ABI tasks which do not have non-default
modes defined at all. Add suitable checks to `mips_set_process_fp_mode'
and bail out if an invalid mode change has been requested for the ABI in
effect, even if the FPU hardware or emulation would otherwise allow it.
Always succeed however without taking any further action if the mode
requested is the same as one already in effect, regardless of whether
any mode change, should it be requested, would actually be allowed for
the task concerned.
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS")
Reviewed-by: Paul Burton <paul.burton(a)mips.com>
Cc: James Hogan <james.hogan(a)mips.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17800/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/process.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/arch/mips/kernel/process.c
+++ b/arch/mips/kernel/process.c
@@ -664,6 +664,18 @@ int mips_set_process_fp_mode(struct task
unsigned long switch_count;
struct task_struct *t;
+ /* If nothing to change, return right away, successfully. */
+ if (value == mips_get_process_fp_mode(task))
+ return 0;
+
+ /* Only accept a mode change if 64-bit FP enabled for o32. */
+ if (!IS_ENABLED(CONFIG_MIPS_O32_FP64_SUPPORT))
+ return -EOPNOTSUPP;
+
+ /* And only for o32 tasks. */
+ if (IS_ENABLED(CONFIG_64BIT) && !test_thread_flag(TIF_32BIT_REGS))
+ return -EOPNOTSUPP;
+
/* Check the value is valid */
if (value & ~known_bits)
return -EOPNOTSUPP;
Patches currently in stable-queue which might be from macro(a)mips.com are
queue-4.4/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch
queue-4.4/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch
queue-4.4/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch
queue-4.4/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch
queue-4.4/mips-factor-out-nt_prfpreg-regset-access-helpers.patch
queue-4.4/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch
queue-4.4/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch
This is a note to let you know that I've just added the patch titled
net/mac80211/debugfs.c: prevent build failure with CONFIG_UBSAN=y
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-mac80211-debugfs.c-prevent-build-failure-with-config_ubsan-y.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 68920c973254c5b71a684645c5f6f82d6732c5d6 Mon Sep 17 00:00:00 2001
From: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Date: Wed, 20 Jan 2016 15:00:51 -0800
Subject: net/mac80211/debugfs.c: prevent build failure with CONFIG_UBSAN=y
From: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
commit 68920c973254c5b71a684645c5f6f82d6732c5d6 upstream.
With upcoming CONFIG_UBSAN the following BUILD_BUG_ON in
net/mac80211/debugfs.c starts to trigger:
BUILD_BUG_ON(hw_flag_names[NUM_IEEE80211_HW_FLAGS] != (void *)0x1);
It seems, that compiler instrumentation causes some code
deoptimizations. Because of that GCC is not being able to resolve
condition in BUILD_BUG_ON() at compile time.
We could make size of hw_flag_names array unspecified and replace the
condition in BUILD_BUG_ON() with following:
ARRAY_SIZE(hw_flag_names) != NUM_IEEE80211_HW_FLAGS
That will have the same effect as before (adding new flag without
updating array will trigger build failure) except it doesn't fail with
CONFIG_UBSAN. As a bonus this patch slightly decreases size of
hw_flag_names array.
Signed-off-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Cc: Johannes Berg <johannes(a)sipsolutions.net>
Cc: "David S. Miller" <davem(a)davemloft.net>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
[Daniel: backport to 4.4.]
Signed-off-by: Daniel Wagner <daniel.wagner(a)siemens.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
Hi,
The only stable tree which is missing this fix is 4.4. 4.1 doesn't
have 30686bf7f5b3 ("mac80211: convert HW flags to unsigned long
bitmap") which makes gcc unhappy with allmodconfig. 4.9 contains the
fix.
Thanks,
Daniel
net/mac80211/debugfs.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -91,7 +91,7 @@ static const struct file_operations rese
};
#endif
-static const char *hw_flag_names[NUM_IEEE80211_HW_FLAGS + 1] = {
+static const char *hw_flag_names[] = {
#define FLAG(F) [IEEE80211_HW_##F] = #F
FLAG(HAS_RATE_CONTROL),
FLAG(RX_INCLUDES_FCS),
@@ -125,9 +125,6 @@ static const char *hw_flag_names[NUM_IEE
FLAG(TDLS_WIDER_BW),
FLAG(SUPPORTS_AMSDU_IN_AMPDU),
FLAG(BEACON_TX_STATUS),
-
- /* keep last for the build bug below */
- (void *)0x1
#undef FLAG
};
@@ -147,7 +144,7 @@ static ssize_t hwflags_read(struct file
/* fail compilation if somebody adds or removes
* a flag without updating the name array above
*/
- BUILD_BUG_ON(hw_flag_names[NUM_IEEE80211_HW_FLAGS] != (void *)0x1);
+ BUILD_BUG_ON(ARRAY_SIZE(hw_flag_names) != NUM_IEEE80211_HW_FLAGS);
for (i = 0; i < NUM_IEEE80211_HW_FLAGS; i++) {
if (test_bit(i, local->hw.flags))
Patches currently in stable-queue which might be from aryabinin(a)virtuozzo.com are
queue-4.4/net-mac80211-debugfs.c-prevent-build-failure-with-config_ubsan-y.patch
This is a note to let you know that I've just added the patch titled
MIPS: Guard against any partial write attempt with PTRACE_SETREGSET
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:
mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.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 dc24d0edf33c3e15099688b6bbdf7bdc24bf6e91 Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 11 Dec 2017 22:52:15 +0000
Subject: MIPS: Guard against any partial write attempt with PTRACE_SETREGSET
From: Maciej W. Rozycki <macro(a)mips.com>
commit dc24d0edf33c3e15099688b6bbdf7bdc24bf6e91 upstream.
Complement commit d614fd58a283 ("mips/ptrace: Preserve previous
registers for short regset write") and ensure that no partial register
write attempt is made with PTRACE_SETREGSET, as we do not preinitialize
any temporaries used to hold incoming register data and consequently
random data could be written.
It is the responsibility of the caller, such as `ptrace_regset', to
arrange for writes to span whole registers only, so here we only assert
that it has indeed happened.
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset")
Cc: James Hogan <james.hogan(a)mips.com>
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Alex Smith <alex(a)alex-smith.me.uk>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17926/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/ptrace.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -536,7 +536,15 @@ static int fpr_set_msa(struct task_struc
return 0;
}
-/* Copy the supplied NT_PRFPREG buffer to the floating-point context. */
+/*
+ * Copy the supplied NT_PRFPREG buffer to the floating-point context.
+ *
+ * We optimize for the case where `count % sizeof(elf_fpreg_t) == 0',
+ * which is supposed to have been guaranteed by the kernel before
+ * calling us, e.g. in `ptrace_regset'. We enforce that requirement,
+ * so that we can safely avoid preinitializing temporaries for
+ * partial register writes.
+ */
static int fpr_set(struct task_struct *target,
const struct user_regset *regset,
unsigned int pos, unsigned int count,
@@ -544,6 +552,8 @@ static int fpr_set(struct task_struct *t
{
int err;
+ BUG_ON(count % sizeof(elf_fpreg_t));
+
/* XXX fcr31 */
init_fp_ctx(target);
Patches currently in stable-queue which might be from macro(a)mips.com are
queue-4.4/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch
queue-4.4/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch
queue-4.4/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch
queue-4.4/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch
queue-4.4/mips-factor-out-nt_prfpreg-regset-access-helpers.patch
queue-4.4/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch
queue-4.4/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch
This is a note to let you know that I've just added the patch titled
MIPS: Fix an FCSR access API regression with NT_PRFPREG and MSA
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:
mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.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 be07a6a1188372b6d19a3307ec33211fc9c9439d Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 11 Dec 2017 22:54:33 +0000
Subject: MIPS: Fix an FCSR access API regression with NT_PRFPREG and MSA
From: Maciej W. Rozycki <macro(a)mips.com>
commit be07a6a1188372b6d19a3307ec33211fc9c9439d upstream.
Fix a commit 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for
FP regset") public API regression, then activated by commit 1db1af84d6df
("MIPS: Basic MSA context switching support"), that caused the FCSR
register not to be read or written for CONFIG_CPU_HAS_MSA kernel
configurations (regardless of actual presence or absence of the MSA
feature in a given processor) with ptrace(2) PTRACE_GETREGSET and
PTRACE_SETREGSET requests nor recorded in core dumps.
This is because with !CONFIG_CPU_HAS_MSA configurations the whole of
`elf_fpregset_t' array is bulk-copied as it is, which includes the FCSR
in one half of the last, 33rd slot, whereas with CONFIG_CPU_HAS_MSA
configurations array elements are copied individually, and then only the
leading 32 FGR slots while the remaining slot is ignored.
Correct the code then such that only FGR slots are copied in the
respective !MSA and MSA helpers an then the FCSR slot is handled
separately in common code. Use `ptrace_setfcr31' to update the FCSR
too, so that the read-only mask is respected.
Retrieving a correct value of FCSR is important in debugging not only
for the human to be able to get the right interpretation of the
situation, but for correct operation of GDB as well. This is because
the condition code bits in FSCR are used by GDB to determine the
location to place a breakpoint at when single-stepping through an FPU
branch instruction. If such a breakpoint is placed incorrectly (i.e.
with the condition reversed), then it will be missed, likely causing the
debuggee to run away from the control of GDB and consequently breaking
the process of investigation.
Fortunately GDB continues using the older PTRACE_GETFPREGS ptrace(2)
request which is unaffected, so the regression only really hits with
post-mortem debug sessions using a core dump file, in which case
execution, and consequently single-stepping through branches is not
possible. Of course core files created by buggy kernels out there will
have the value of FCSR recorded clobbered, but such core files cannot be
corrected and the person using them simply will have to be aware that
the value of FCSR retrieved is not reliable.
Which also means we can likely get away without defining a replacement
API which would ensure a correct value of FSCR to be retrieved, or none
at all.
This is based on previous work by Alex Smith, extensively rewritten.
Signed-off-by: Alex Smith <alex(a)alex-smith.me.uk>
Signed-off-by: James Hogan <james.hogan(a)mips.com>
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset")
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17928/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/ptrace.c | 47 +++++++++++++++++++++++++++++++++++-----------
1 file changed, 36 insertions(+), 11 deletions(-)
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -442,7 +442,7 @@ static int gpr64_set(struct task_struct
/*
* Copy the floating-point context to the supplied NT_PRFPREG buffer,
* !CONFIG_CPU_HAS_MSA variant. FP context's general register slots
- * correspond 1:1 to buffer slots.
+ * correspond 1:1 to buffer slots. Only general registers are copied.
*/
static int fpr_get_fpa(struct task_struct *target,
unsigned int *pos, unsigned int *count,
@@ -450,13 +450,14 @@ static int fpr_get_fpa(struct task_struc
{
return user_regset_copyout(pos, count, kbuf, ubuf,
&target->thread.fpu,
- 0, sizeof(elf_fpregset_t));
+ 0, NUM_FPU_REGS * sizeof(elf_fpreg_t));
}
/*
* Copy the floating-point context to the supplied NT_PRFPREG buffer,
* CONFIG_CPU_HAS_MSA variant. Only lower 64 bits of FP context's
- * general register slots are copied to buffer slots.
+ * general register slots are copied to buffer slots. Only general
+ * registers are copied.
*/
static int fpr_get_msa(struct task_struct *target,
unsigned int *pos, unsigned int *count,
@@ -478,20 +479,29 @@ static int fpr_get_msa(struct task_struc
return 0;
}
-/* Copy the floating-point context to the supplied NT_PRFPREG buffer. */
+/*
+ * Copy the floating-point context to the supplied NT_PRFPREG buffer.
+ * Choose the appropriate helper for general registers, and then copy
+ * the FCSR register separately.
+ */
static int fpr_get(struct task_struct *target,
const struct user_regset *regset,
unsigned int pos, unsigned int count,
void *kbuf, void __user *ubuf)
{
+ const int fcr31_pos = NUM_FPU_REGS * sizeof(elf_fpreg_t);
int err;
- /* XXX fcr31 */
-
if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t))
err = fpr_get_fpa(target, &pos, &count, &kbuf, &ubuf);
else
err = fpr_get_msa(target, &pos, &count, &kbuf, &ubuf);
+ if (err)
+ return err;
+
+ err = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.fpu.fcr31,
+ fcr31_pos, fcr31_pos + sizeof(u32));
return err;
}
@@ -499,7 +509,7 @@ static int fpr_get(struct task_struct *t
/*
* Copy the supplied NT_PRFPREG buffer to the floating-point context,
* !CONFIG_CPU_HAS_MSA variant. Buffer slots correspond 1:1 to FP
- * context's general register slots.
+ * context's general register slots. Only general registers are copied.
*/
static int fpr_set_fpa(struct task_struct *target,
unsigned int *pos, unsigned int *count,
@@ -507,13 +517,14 @@ static int fpr_set_fpa(struct task_struc
{
return user_regset_copyin(pos, count, kbuf, ubuf,
&target->thread.fpu,
- 0, sizeof(elf_fpregset_t));
+ 0, NUM_FPU_REGS * sizeof(elf_fpreg_t));
}
/*
* Copy the supplied NT_PRFPREG buffer to the floating-point context,
* CONFIG_CPU_HAS_MSA variant. Buffer slots are copied to lower 64
- * bits only of FP context's general register slots.
+ * bits only of FP context's general register slots. Only general
+ * registers are copied.
*/
static int fpr_set_msa(struct task_struct *target,
unsigned int *pos, unsigned int *count,
@@ -538,6 +549,8 @@ static int fpr_set_msa(struct task_struc
/*
* Copy the supplied NT_PRFPREG buffer to the floating-point context.
+ * Choose the appropriate helper for general registers, and then copy
+ * the FCSR register separately.
*
* We optimize for the case where `count % sizeof(elf_fpreg_t) == 0',
* which is supposed to have been guaranteed by the kernel before
@@ -550,18 +563,30 @@ static int fpr_set(struct task_struct *t
unsigned int pos, unsigned int count,
const void *kbuf, const void __user *ubuf)
{
+ const int fcr31_pos = NUM_FPU_REGS * sizeof(elf_fpreg_t);
+ u32 fcr31;
int err;
BUG_ON(count % sizeof(elf_fpreg_t));
- /* XXX fcr31 */
-
init_fp_ctx(target);
if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t))
err = fpr_set_fpa(target, &pos, &count, &kbuf, &ubuf);
else
err = fpr_set_msa(target, &pos, &count, &kbuf, &ubuf);
+ if (err)
+ return err;
+
+ if (count > 0) {
+ err = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &fcr31,
+ fcr31_pos, fcr31_pos + sizeof(u32));
+ if (err)
+ return err;
+
+ ptrace_setfcr31(target, fcr31);
+ }
return err;
}
Patches currently in stable-queue which might be from macro(a)mips.com are
queue-4.4/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch
queue-4.4/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch
queue-4.4/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch
queue-4.4/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch
queue-4.4/mips-factor-out-nt_prfpreg-regset-access-helpers.patch
queue-4.4/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch
queue-4.4/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch
This is a note to let you know that I've just added the patch titled
MIPS: Factor out NT_PRFPREG regset access helpers
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:
mips-factor-out-nt_prfpreg-regset-access-helpers.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 a03fe72572c12e98f4173f8a535f32468e48b6ec Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 11 Dec 2017 22:51:35 +0000
Subject: MIPS: Factor out NT_PRFPREG regset access helpers
From: Maciej W. Rozycki <macro(a)mips.com>
commit a03fe72572c12e98f4173f8a535f32468e48b6ec upstream.
In preparation to fix a commit 72b22bbad1e7 ("MIPS: Don't assume 64-bit
FP registers for FP regset") FCSR access regression factor out
NT_PRFPREG regset access helpers for the non-MSA and the MSA variants
respectively, to avoid having to deal with excessive indentation in the
actual fix.
No functional change, however use `target->thread.fpu.fpr[0]' rather
than `target->thread.fpu.fpr[i]' for FGR holding type size determination
as there's no `i' variable to refer to anymore, and for the factored out
`i' variable declaration use `unsigned int' rather than `unsigned' as
its type, following the common style.
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset")
Cc: James Hogan <james.hogan(a)mips.com>
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Alex Smith <alex(a)alex-smith.me.uk>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17925/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/ptrace.c | 108 +++++++++++++++++++++++++++++++++++-----------
1 file changed, 83 insertions(+), 25 deletions(-)
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -439,25 +439,36 @@ static int gpr64_set(struct task_struct
#endif /* CONFIG_64BIT */
-static int fpr_get(struct task_struct *target,
- const struct user_regset *regset,
- unsigned int pos, unsigned int count,
- void *kbuf, void __user *ubuf)
+/*
+ * Copy the floating-point context to the supplied NT_PRFPREG buffer,
+ * !CONFIG_CPU_HAS_MSA variant. FP context's general register slots
+ * correspond 1:1 to buffer slots.
+ */
+static int fpr_get_fpa(struct task_struct *target,
+ unsigned int *pos, unsigned int *count,
+ void **kbuf, void __user **ubuf)
{
- unsigned i;
- int err;
- u64 fpr_val;
-
- /* XXX fcr31 */
+ return user_regset_copyout(pos, count, kbuf, ubuf,
+ &target->thread.fpu,
+ 0, sizeof(elf_fpregset_t));
+}
- if (sizeof(target->thread.fpu.fpr[i]) == sizeof(elf_fpreg_t))
- return user_regset_copyout(&pos, &count, &kbuf, &ubuf,
- &target->thread.fpu,
- 0, sizeof(elf_fpregset_t));
+/*
+ * Copy the floating-point context to the supplied NT_PRFPREG buffer,
+ * CONFIG_CPU_HAS_MSA variant. Only lower 64 bits of FP context's
+ * general register slots are copied to buffer slots.
+ */
+static int fpr_get_msa(struct task_struct *target,
+ unsigned int *pos, unsigned int *count,
+ void **kbuf, void __user **ubuf)
+{
+ unsigned int i;
+ u64 fpr_val;
+ int err;
for (i = 0; i < NUM_FPU_REGS; i++) {
fpr_val = get_fpr64(&target->thread.fpu.fpr[i], 0);
- err = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ err = user_regset_copyout(pos, count, kbuf, ubuf,
&fpr_val, i * sizeof(elf_fpreg_t),
(i + 1) * sizeof(elf_fpreg_t));
if (err)
@@ -467,27 +478,54 @@ static int fpr_get(struct task_struct *t
return 0;
}
-static int fpr_set(struct task_struct *target,
+/* Copy the floating-point context to the supplied NT_PRFPREG buffer. */
+static int fpr_get(struct task_struct *target,
const struct user_regset *regset,
unsigned int pos, unsigned int count,
- const void *kbuf, const void __user *ubuf)
+ void *kbuf, void __user *ubuf)
{
- unsigned i;
int err;
- u64 fpr_val;
/* XXX fcr31 */
- init_fp_ctx(target);
+ if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t))
+ err = fpr_get_fpa(target, &pos, &count, &kbuf, &ubuf);
+ else
+ err = fpr_get_msa(target, &pos, &count, &kbuf, &ubuf);
+
+ return err;
+}
- if (sizeof(target->thread.fpu.fpr[i]) == sizeof(elf_fpreg_t))
- return user_regset_copyin(&pos, &count, &kbuf, &ubuf,
- &target->thread.fpu,
- 0, sizeof(elf_fpregset_t));
+/*
+ * Copy the supplied NT_PRFPREG buffer to the floating-point context,
+ * !CONFIG_CPU_HAS_MSA variant. Buffer slots correspond 1:1 to FP
+ * context's general register slots.
+ */
+static int fpr_set_fpa(struct task_struct *target,
+ unsigned int *pos, unsigned int *count,
+ const void **kbuf, const void __user **ubuf)
+{
+ return user_regset_copyin(pos, count, kbuf, ubuf,
+ &target->thread.fpu,
+ 0, sizeof(elf_fpregset_t));
+}
+
+/*
+ * Copy the supplied NT_PRFPREG buffer to the floating-point context,
+ * CONFIG_CPU_HAS_MSA variant. Buffer slots are copied to lower 64
+ * bits only of FP context's general register slots.
+ */
+static int fpr_set_msa(struct task_struct *target,
+ unsigned int *pos, unsigned int *count,
+ const void **kbuf, const void __user **ubuf)
+{
+ unsigned int i;
+ u64 fpr_val;
+ int err;
BUILD_BUG_ON(sizeof(fpr_val) != sizeof(elf_fpreg_t));
- for (i = 0; i < NUM_FPU_REGS && count >= sizeof(elf_fpreg_t); i++) {
- err = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ for (i = 0; i < NUM_FPU_REGS && *count >= sizeof(elf_fpreg_t); i++) {
+ err = user_regset_copyin(pos, count, kbuf, ubuf,
&fpr_val, i * sizeof(elf_fpreg_t),
(i + 1) * sizeof(elf_fpreg_t));
if (err)
@@ -498,6 +536,26 @@ static int fpr_set(struct task_struct *t
return 0;
}
+/* Copy the supplied NT_PRFPREG buffer to the floating-point context. */
+static int fpr_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf)
+{
+ int err;
+
+ /* XXX fcr31 */
+
+ init_fp_ctx(target);
+
+ if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t))
+ err = fpr_set_fpa(target, &pos, &count, &kbuf, &ubuf);
+ else
+ err = fpr_set_msa(target, &pos, &count, &kbuf, &ubuf);
+
+ return err;
+}
+
enum mips_regset {
REGSET_GPR,
REGSET_FPR,
Patches currently in stable-queue which might be from macro(a)mips.com are
queue-4.4/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch
queue-4.4/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch
queue-4.4/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch
queue-4.4/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch
queue-4.4/mips-factor-out-nt_prfpreg-regset-access-helpers.patch
queue-4.4/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch
queue-4.4/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch
This is a note to let you know that I've just added the patch titled
MIPS: Disallow outsized PTRACE_SETREGSET NT_PRFPREG regset accesses
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:
mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.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 c8c5a3a24d395b14447a9a89d61586a913840a3b Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 11 Dec 2017 22:56:54 +0000
Subject: MIPS: Disallow outsized PTRACE_SETREGSET NT_PRFPREG regset accesses
From: Maciej W. Rozycki <macro(a)mips.com>
commit c8c5a3a24d395b14447a9a89d61586a913840a3b upstream.
Complement commit c23b3d1a5311 ("MIPS: ptrace: Change GP regset to use
correct core dump register layout") and also reject outsized
PTRACE_SETREGSET requests to the NT_PRFPREG regset, like with the
NT_PRSTATUS regset.
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: c23b3d1a5311 ("MIPS: ptrace: Change GP regset to use correct core dump register layout")
Cc: James Hogan <james.hogan(a)mips.com>
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Alex Smith <alex(a)alex-smith.me.uk>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17930/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/ptrace.c | 3 +++
1 file changed, 3 insertions(+)
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -570,6 +570,9 @@ static int fpr_set(struct task_struct *t
BUG_ON(count % sizeof(elf_fpreg_t));
+ if (pos + count > sizeof(elf_fpregset_t))
+ return -EIO;
+
init_fp_ctx(target);
if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t))
Patches currently in stable-queue which might be from macro(a)mips.com are
queue-4.4/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch
queue-4.4/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch
queue-4.4/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch
queue-4.4/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch
queue-4.4/mips-factor-out-nt_prfpreg-regset-access-helpers.patch
queue-4.4/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch
queue-4.4/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch
This is a note to let you know that I've just added the patch titled
MIPS: Consistently handle buffer counter with PTRACE_SETREGSET
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:
mips-consistently-handle-buffer-counter-with-ptrace_setregset.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 80b3ffce0196ea50068885d085ff981e4b8396f4 Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 11 Dec 2017 22:53:14 +0000
Subject: MIPS: Consistently handle buffer counter with PTRACE_SETREGSET
From: Maciej W. Rozycki <macro(a)mips.com>
commit 80b3ffce0196ea50068885d085ff981e4b8396f4 upstream.
Update commit d614fd58a283 ("mips/ptrace: Preserve previous registers
for short regset write") bug and consistently consume all data supplied
to `fpr_set_msa' with the ptrace(2) PTRACE_SETREGSET request, such that
a zero data buffer counter is returned where insufficient data has been
given to fill a whole number of FP general registers.
In reality this is not going to happen, as the caller is supposed to
only supply data covering a whole number of registers and it is verified
in `ptrace_regset' and again asserted in `fpr_set', however structuring
code such that the presence of trailing partial FP general register data
causes `fpr_set_msa' to return with a non-zero data buffer counter makes
it appear that this trailing data will be used if there are subsequent
writes made to FP registers, which is going to be the case with the FCSR
once the missing write to that register has been fixed.
Fixes: d614fd58a283 ("mips/ptrace: Preserve previous registers for short regset write")
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Cc: James Hogan <james.hogan(a)mips.com>
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Alex Smith <alex(a)alex-smith.me.uk>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17927/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/ptrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -524,7 +524,7 @@ static int fpr_set_msa(struct task_struc
int err;
BUILD_BUG_ON(sizeof(fpr_val) != sizeof(elf_fpreg_t));
- for (i = 0; i < NUM_FPU_REGS && *count >= sizeof(elf_fpreg_t); i++) {
+ for (i = 0; i < NUM_FPU_REGS && *count > 0; i++) {
err = user_regset_copyin(pos, count, kbuf, ubuf,
&fpr_val, i * sizeof(elf_fpreg_t),
(i + 1) * sizeof(elf_fpreg_t));
Patches currently in stable-queue which might be from macro(a)mips.com are
queue-4.4/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch
queue-4.4/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch
queue-4.4/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch
queue-4.4/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch
queue-4.4/mips-factor-out-nt_prfpreg-regset-access-helpers.patch
queue-4.4/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch
queue-4.4/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch
This is a note to let you know that I've just added the patch titled
MIPS: Also verify sizeof `elf_fpreg_t' with PTRACE_SETREGSET
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:
mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.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 006501e039eec411842bb3150c41358867d320c2 Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 11 Dec 2017 22:55:40 +0000
Subject: MIPS: Also verify sizeof `elf_fpreg_t' with PTRACE_SETREGSET
From: Maciej W. Rozycki <macro(a)mips.com>
commit 006501e039eec411842bb3150c41358867d320c2 upstream.
Complement commit d614fd58a283 ("mips/ptrace: Preserve previous
registers for short regset write") and like with the PTRACE_GETREGSET
ptrace(2) request also apply a BUILD_BUG_ON check for the size of the
`elf_fpreg_t' type in the PTRACE_SETREGSET request handler.
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: d614fd58a283 ("mips/ptrace: Preserve previous registers for short regset write")
Cc: James Hogan <james.hogan(a)mips.com>
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Alex Smith <alex(a)alex-smith.me.uk>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17929/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/ptrace.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -467,6 +467,7 @@ static int fpr_get_msa(struct task_struc
u64 fpr_val;
int err;
+ BUILD_BUG_ON(sizeof(fpr_val) != sizeof(elf_fpreg_t));
for (i = 0; i < NUM_FPU_REGS; i++) {
fpr_val = get_fpr64(&target->thread.fpu.fpr[i], 0);
err = user_regset_copyout(pos, count, kbuf, ubuf,
Patches currently in stable-queue which might be from macro(a)mips.com are
queue-4.4/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch
queue-4.4/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch
queue-4.4/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch
queue-4.4/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch
queue-4.4/mips-factor-out-nt_prfpreg-regset-access-helpers.patch
queue-4.4/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch
queue-4.4/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch
This is a note to let you know that I've just added the patch titled
IB/srpt: Disable RDMA access by the initiator
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-srpt-disable-rdma-access-by-the-initiator.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 bec40c26041de61162f7be9d2ce548c756ce0f65 Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Wed, 3 Jan 2018 13:39:15 -0800
Subject: IB/srpt: Disable RDMA access by the initiator
From: Bart Van Assche <bart.vanassche(a)wdc.com>
commit bec40c26041de61162f7be9d2ce548c756ce0f65 upstream.
With the SRP protocol all RDMA operations are initiated by the target.
Since no RDMA operations are initiated by the initiator, do not grant
the initiator permission to submit RDMA reads or writes to the target.
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/ulp/srpt/ib_srpt.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
@@ -957,8 +957,7 @@ static int srpt_init_ch_qp(struct srpt_r
return -ENOMEM;
attr->qp_state = IB_QPS_INIT;
- attr->qp_access_flags = IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_READ |
- IB_ACCESS_REMOTE_WRITE;
+ attr->qp_access_flags = IB_ACCESS_LOCAL_WRITE;
attr->port_num = ch->sport->port;
attr->pkey_index = 0;
Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are
queue-4.4/ib-srpt-disable-rdma-access-by-the-initiator.patch
This is a note to let you know that I've just added the patch titled
can: gs_usb: fix return value of the "set_bittiming" callback
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:
can-gs_usb-fix-return-value-of-the-set_bittiming-callback.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 d5b42e6607661b198d8b26a0c30969605b1bf5c7 Mon Sep 17 00:00:00 2001
From: Wolfgang Grandegger <wg(a)grandegger.com>
Date: Wed, 13 Dec 2017 19:52:23 +0100
Subject: can: gs_usb: fix return value of the "set_bittiming" callback
From: Wolfgang Grandegger <wg(a)grandegger.com>
commit d5b42e6607661b198d8b26a0c30969605b1bf5c7 upstream.
The "set_bittiming" callback treats a positive return value as error!
For that reason "can_changelink()" will quit silently after setting
the bittiming values without processing ctrlmode, restart-ms, etc.
Signed-off-by: Wolfgang Grandegger <wg(a)grandegger.com>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/usb/gs_usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/can/usb/gs_usb.c
+++ b/drivers/net/can/usb/gs_usb.c
@@ -430,7 +430,7 @@ static int gs_usb_set_bittiming(struct n
dev_err(netdev->dev.parent, "Couldn't set bittimings (err=%d)",
rc);
- return rc;
+ return (rc > 0) ? 0 : rc;
}
static void gs_usb_xmit_callback(struct urb *urb)
Patches currently in stable-queue which might be from wg(a)grandegger.com are
queue-4.4/can-gs_usb-fix-return-value-of-the-set_bittiming-callback.patch
This is a note to let you know that I've just added the patch titled
platform/x86: wmi: Call acpi_wmi_init() later
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:
platform-x86-wmi-call-acpi_wmi_init-later.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 98b8e4e5c17bf87c1b18ed929472051dab39878c Mon Sep 17 00:00:00 2001
From: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com>
Date: Wed, 3 Jan 2018 12:49:29 +0100
Subject: platform/x86: wmi: Call acpi_wmi_init() later
From: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
commit 98b8e4e5c17bf87c1b18ed929472051dab39878c upstream.
Calling acpi_wmi_init() at the subsys_initcall() level causes ordering
issues to appear on some systems and they are difficult to reproduce,
because there is no guaranteed ordering between subsys_initcall()
calls, so they may occur in different orders on different systems.
In particular, commit 86d9f48534e8 (mm/slab: fix kmemcg cache
creation delayed issue) exposed one of these issues where genl_init()
and acpi_wmi_init() are both called at the same initcall level, but
the former must run before the latter so as to avoid a NULL pointer
dereference.
For this reason, move the acpi_wmi_init() invocation to the
initcall_sync level which should still be early enough for things
to work correctly in the WMI land.
Link: https://marc.info/?t=151274596700002&r=1&w=2
Reported-by: Jonathan McDowell <noodles(a)earth.li>
Reported-by: Joonsoo Kim <iamjoonsoo.kim(a)lge.com>
Tested-by: Jonathan McDowell <noodles(a)earth.li>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Darren Hart (VMware) <dvhart(a)infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/platform/x86/wmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/platform/x86/wmi.c
+++ b/drivers/platform/x86/wmi.c
@@ -1268,5 +1268,5 @@ static void __exit acpi_wmi_exit(void)
bus_unregister(&wmi_bus_type);
}
-subsys_initcall(acpi_wmi_init);
+subsys_initcall_sync(acpi_wmi_init);
module_exit(acpi_wmi_exit);
Patches currently in stable-queue which might be from rafael.j.wysocki(a)intel.com are
queue-4.14/platform-x86-wmi-call-acpi_wmi_init-later.patch
This is a note to let you know that I've just added the patch titled
MIPS: Validate PR_SET_FP_MODE prctl(2) requests against the ABI of the task
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:
mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.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 b67336eee3fcb8ecedc6c13e2bf88aacfa3151e2 Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 27 Nov 2017 09:33:03 +0000
Subject: MIPS: Validate PR_SET_FP_MODE prctl(2) requests against the ABI of the task
From: Maciej W. Rozycki <macro(a)mips.com>
commit b67336eee3fcb8ecedc6c13e2bf88aacfa3151e2 upstream.
Fix an API loophole introduced with commit 9791554b45a2 ("MIPS,prctl:
add PR_[GS]ET_FP_MODE prctl options for MIPS"), where the caller of
prctl(2) is incorrectly allowed to make a change to CP0.Status.FR or
CP0.Config5.FRE register bits even if CONFIG_MIPS_O32_FP64_SUPPORT has
not been enabled, despite that an executable requesting the mode
requested via ELF file annotation would not be allowed to run in the
first place, or for n64 and n64 ABI tasks which do not have non-default
modes defined at all. Add suitable checks to `mips_set_process_fp_mode'
and bail out if an invalid mode change has been requested for the ABI in
effect, even if the FPU hardware or emulation would otherwise allow it.
Always succeed however without taking any further action if the mode
requested is the same as one already in effect, regardless of whether
any mode change, should it be requested, would actually be allowed for
the task concerned.
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS")
Reviewed-by: Paul Burton <paul.burton(a)mips.com>
Cc: James Hogan <james.hogan(a)mips.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17800/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/process.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/arch/mips/kernel/process.c
+++ b/arch/mips/kernel/process.c
@@ -705,6 +705,18 @@ int mips_set_process_fp_mode(struct task
struct task_struct *t;
int max_users;
+ /* If nothing to change, return right away, successfully. */
+ if (value == mips_get_process_fp_mode(task))
+ return 0;
+
+ /* Only accept a mode change if 64-bit FP enabled for o32. */
+ if (!IS_ENABLED(CONFIG_MIPS_O32_FP64_SUPPORT))
+ return -EOPNOTSUPP;
+
+ /* And only for o32 tasks. */
+ if (IS_ENABLED(CONFIG_64BIT) && !test_thread_flag(TIF_32BIT_REGS))
+ return -EOPNOTSUPP;
+
/* Check the value is valid */
if (value & ~known_bits)
return -EOPNOTSUPP;
Patches currently in stable-queue which might be from macro(a)mips.com are
queue-4.14/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch
queue-4.14/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch
queue-4.14/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch
queue-4.14/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch
queue-4.14/mips-factor-out-nt_prfpreg-regset-access-helpers.patch
queue-4.14/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch
queue-4.14/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch
This is a note to let you know that I've just added the patch titled
MIPS: Guard against any partial write attempt with PTRACE_SETREGSET
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:
mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.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 dc24d0edf33c3e15099688b6bbdf7bdc24bf6e91 Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 11 Dec 2017 22:52:15 +0000
Subject: MIPS: Guard against any partial write attempt with PTRACE_SETREGSET
From: Maciej W. Rozycki <macro(a)mips.com>
commit dc24d0edf33c3e15099688b6bbdf7bdc24bf6e91 upstream.
Complement commit d614fd58a283 ("mips/ptrace: Preserve previous
registers for short regset write") and ensure that no partial register
write attempt is made with PTRACE_SETREGSET, as we do not preinitialize
any temporaries used to hold incoming register data and consequently
random data could be written.
It is the responsibility of the caller, such as `ptrace_regset', to
arrange for writes to span whole registers only, so here we only assert
that it has indeed happened.
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset")
Cc: James Hogan <james.hogan(a)mips.com>
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Alex Smith <alex(a)alex-smith.me.uk>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17926/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/ptrace.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -507,7 +507,15 @@ static int fpr_set_msa(struct task_struc
return 0;
}
-/* Copy the supplied NT_PRFPREG buffer to the floating-point context. */
+/*
+ * Copy the supplied NT_PRFPREG buffer to the floating-point context.
+ *
+ * We optimize for the case where `count % sizeof(elf_fpreg_t) == 0',
+ * which is supposed to have been guaranteed by the kernel before
+ * calling us, e.g. in `ptrace_regset'. We enforce that requirement,
+ * so that we can safely avoid preinitializing temporaries for
+ * partial register writes.
+ */
static int fpr_set(struct task_struct *target,
const struct user_regset *regset,
unsigned int pos, unsigned int count,
@@ -515,6 +523,8 @@ static int fpr_set(struct task_struct *t
{
int err;
+ BUG_ON(count % sizeof(elf_fpreg_t));
+
/* XXX fcr31 */
init_fp_ctx(target);
Patches currently in stable-queue which might be from macro(a)mips.com are
queue-4.14/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch
queue-4.14/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch
queue-4.14/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch
queue-4.14/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch
queue-4.14/mips-factor-out-nt_prfpreg-regset-access-helpers.patch
queue-4.14/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch
queue-4.14/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch
This is a note to let you know that I've just added the patch titled
MIPS: Fix an FCSR access API regression with NT_PRFPREG and MSA
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:
mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.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 be07a6a1188372b6d19a3307ec33211fc9c9439d Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 11 Dec 2017 22:54:33 +0000
Subject: MIPS: Fix an FCSR access API regression with NT_PRFPREG and MSA
From: Maciej W. Rozycki <macro(a)mips.com>
commit be07a6a1188372b6d19a3307ec33211fc9c9439d upstream.
Fix a commit 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for
FP regset") public API regression, then activated by commit 1db1af84d6df
("MIPS: Basic MSA context switching support"), that caused the FCSR
register not to be read or written for CONFIG_CPU_HAS_MSA kernel
configurations (regardless of actual presence or absence of the MSA
feature in a given processor) with ptrace(2) PTRACE_GETREGSET and
PTRACE_SETREGSET requests nor recorded in core dumps.
This is because with !CONFIG_CPU_HAS_MSA configurations the whole of
`elf_fpregset_t' array is bulk-copied as it is, which includes the FCSR
in one half of the last, 33rd slot, whereas with CONFIG_CPU_HAS_MSA
configurations array elements are copied individually, and then only the
leading 32 FGR slots while the remaining slot is ignored.
Correct the code then such that only FGR slots are copied in the
respective !MSA and MSA helpers an then the FCSR slot is handled
separately in common code. Use `ptrace_setfcr31' to update the FCSR
too, so that the read-only mask is respected.
Retrieving a correct value of FCSR is important in debugging not only
for the human to be able to get the right interpretation of the
situation, but for correct operation of GDB as well. This is because
the condition code bits in FSCR are used by GDB to determine the
location to place a breakpoint at when single-stepping through an FPU
branch instruction. If such a breakpoint is placed incorrectly (i.e.
with the condition reversed), then it will be missed, likely causing the
debuggee to run away from the control of GDB and consequently breaking
the process of investigation.
Fortunately GDB continues using the older PTRACE_GETFPREGS ptrace(2)
request which is unaffected, so the regression only really hits with
post-mortem debug sessions using a core dump file, in which case
execution, and consequently single-stepping through branches is not
possible. Of course core files created by buggy kernels out there will
have the value of FCSR recorded clobbered, but such core files cannot be
corrected and the person using them simply will have to be aware that
the value of FCSR retrieved is not reliable.
Which also means we can likely get away without defining a replacement
API which would ensure a correct value of FSCR to be retrieved, or none
at all.
This is based on previous work by Alex Smith, extensively rewritten.
Signed-off-by: Alex Smith <alex(a)alex-smith.me.uk>
Signed-off-by: James Hogan <james.hogan(a)mips.com>
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset")
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17928/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/ptrace.c | 47 +++++++++++++++++++++++++++++++++++-----------
1 file changed, 36 insertions(+), 11 deletions(-)
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -413,7 +413,7 @@ static int gpr64_set(struct task_struct
/*
* Copy the floating-point context to the supplied NT_PRFPREG buffer,
* !CONFIG_CPU_HAS_MSA variant. FP context's general register slots
- * correspond 1:1 to buffer slots.
+ * correspond 1:1 to buffer slots. Only general registers are copied.
*/
static int fpr_get_fpa(struct task_struct *target,
unsigned int *pos, unsigned int *count,
@@ -421,13 +421,14 @@ static int fpr_get_fpa(struct task_struc
{
return user_regset_copyout(pos, count, kbuf, ubuf,
&target->thread.fpu,
- 0, sizeof(elf_fpregset_t));
+ 0, NUM_FPU_REGS * sizeof(elf_fpreg_t));
}
/*
* Copy the floating-point context to the supplied NT_PRFPREG buffer,
* CONFIG_CPU_HAS_MSA variant. Only lower 64 bits of FP context's
- * general register slots are copied to buffer slots.
+ * general register slots are copied to buffer slots. Only general
+ * registers are copied.
*/
static int fpr_get_msa(struct task_struct *target,
unsigned int *pos, unsigned int *count,
@@ -449,20 +450,29 @@ static int fpr_get_msa(struct task_struc
return 0;
}
-/* Copy the floating-point context to the supplied NT_PRFPREG buffer. */
+/*
+ * Copy the floating-point context to the supplied NT_PRFPREG buffer.
+ * Choose the appropriate helper for general registers, and then copy
+ * the FCSR register separately.
+ */
static int fpr_get(struct task_struct *target,
const struct user_regset *regset,
unsigned int pos, unsigned int count,
void *kbuf, void __user *ubuf)
{
+ const int fcr31_pos = NUM_FPU_REGS * sizeof(elf_fpreg_t);
int err;
- /* XXX fcr31 */
-
if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t))
err = fpr_get_fpa(target, &pos, &count, &kbuf, &ubuf);
else
err = fpr_get_msa(target, &pos, &count, &kbuf, &ubuf);
+ if (err)
+ return err;
+
+ err = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.fpu.fcr31,
+ fcr31_pos, fcr31_pos + sizeof(u32));
return err;
}
@@ -470,7 +480,7 @@ static int fpr_get(struct task_struct *t
/*
* Copy the supplied NT_PRFPREG buffer to the floating-point context,
* !CONFIG_CPU_HAS_MSA variant. Buffer slots correspond 1:1 to FP
- * context's general register slots.
+ * context's general register slots. Only general registers are copied.
*/
static int fpr_set_fpa(struct task_struct *target,
unsigned int *pos, unsigned int *count,
@@ -478,13 +488,14 @@ static int fpr_set_fpa(struct task_struc
{
return user_regset_copyin(pos, count, kbuf, ubuf,
&target->thread.fpu,
- 0, sizeof(elf_fpregset_t));
+ 0, NUM_FPU_REGS * sizeof(elf_fpreg_t));
}
/*
* Copy the supplied NT_PRFPREG buffer to the floating-point context,
* CONFIG_CPU_HAS_MSA variant. Buffer slots are copied to lower 64
- * bits only of FP context's general register slots.
+ * bits only of FP context's general register slots. Only general
+ * registers are copied.
*/
static int fpr_set_msa(struct task_struct *target,
unsigned int *pos, unsigned int *count,
@@ -509,6 +520,8 @@ static int fpr_set_msa(struct task_struc
/*
* Copy the supplied NT_PRFPREG buffer to the floating-point context.
+ * Choose the appropriate helper for general registers, and then copy
+ * the FCSR register separately.
*
* We optimize for the case where `count % sizeof(elf_fpreg_t) == 0',
* which is supposed to have been guaranteed by the kernel before
@@ -521,18 +534,30 @@ static int fpr_set(struct task_struct *t
unsigned int pos, unsigned int count,
const void *kbuf, const void __user *ubuf)
{
+ const int fcr31_pos = NUM_FPU_REGS * sizeof(elf_fpreg_t);
+ u32 fcr31;
int err;
BUG_ON(count % sizeof(elf_fpreg_t));
- /* XXX fcr31 */
-
init_fp_ctx(target);
if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t))
err = fpr_set_fpa(target, &pos, &count, &kbuf, &ubuf);
else
err = fpr_set_msa(target, &pos, &count, &kbuf, &ubuf);
+ if (err)
+ return err;
+
+ if (count > 0) {
+ err = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &fcr31,
+ fcr31_pos, fcr31_pos + sizeof(u32));
+ if (err)
+ return err;
+
+ ptrace_setfcr31(target, fcr31);
+ }
return err;
}
Patches currently in stable-queue which might be from macro(a)mips.com are
queue-4.14/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch
queue-4.14/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch
queue-4.14/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch
queue-4.14/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch
queue-4.14/mips-factor-out-nt_prfpreg-regset-access-helpers.patch
queue-4.14/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch
queue-4.14/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch
This is a note to let you know that I've just added the patch titled
MIPS: Factor out NT_PRFPREG regset access helpers
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:
mips-factor-out-nt_prfpreg-regset-access-helpers.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 a03fe72572c12e98f4173f8a535f32468e48b6ec Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 11 Dec 2017 22:51:35 +0000
Subject: MIPS: Factor out NT_PRFPREG regset access helpers
From: Maciej W. Rozycki <macro(a)mips.com>
commit a03fe72572c12e98f4173f8a535f32468e48b6ec upstream.
In preparation to fix a commit 72b22bbad1e7 ("MIPS: Don't assume 64-bit
FP registers for FP regset") FCSR access regression factor out
NT_PRFPREG regset access helpers for the non-MSA and the MSA variants
respectively, to avoid having to deal with excessive indentation in the
actual fix.
No functional change, however use `target->thread.fpu.fpr[0]' rather
than `target->thread.fpu.fpr[i]' for FGR holding type size determination
as there's no `i' variable to refer to anymore, and for the factored out
`i' variable declaration use `unsigned int' rather than `unsigned' as
its type, following the common style.
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset")
Cc: James Hogan <james.hogan(a)mips.com>
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Alex Smith <alex(a)alex-smith.me.uk>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17925/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/ptrace.c | 108 +++++++++++++++++++++++++++++++++++-----------
1 file changed, 83 insertions(+), 25 deletions(-)
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -410,25 +410,36 @@ static int gpr64_set(struct task_struct
#endif /* CONFIG_64BIT */
-static int fpr_get(struct task_struct *target,
- const struct user_regset *regset,
- unsigned int pos, unsigned int count,
- void *kbuf, void __user *ubuf)
+/*
+ * Copy the floating-point context to the supplied NT_PRFPREG buffer,
+ * !CONFIG_CPU_HAS_MSA variant. FP context's general register slots
+ * correspond 1:1 to buffer slots.
+ */
+static int fpr_get_fpa(struct task_struct *target,
+ unsigned int *pos, unsigned int *count,
+ void **kbuf, void __user **ubuf)
{
- unsigned i;
- int err;
- u64 fpr_val;
-
- /* XXX fcr31 */
+ return user_regset_copyout(pos, count, kbuf, ubuf,
+ &target->thread.fpu,
+ 0, sizeof(elf_fpregset_t));
+}
- if (sizeof(target->thread.fpu.fpr[i]) == sizeof(elf_fpreg_t))
- return user_regset_copyout(&pos, &count, &kbuf, &ubuf,
- &target->thread.fpu,
- 0, sizeof(elf_fpregset_t));
+/*
+ * Copy the floating-point context to the supplied NT_PRFPREG buffer,
+ * CONFIG_CPU_HAS_MSA variant. Only lower 64 bits of FP context's
+ * general register slots are copied to buffer slots.
+ */
+static int fpr_get_msa(struct task_struct *target,
+ unsigned int *pos, unsigned int *count,
+ void **kbuf, void __user **ubuf)
+{
+ unsigned int i;
+ u64 fpr_val;
+ int err;
for (i = 0; i < NUM_FPU_REGS; i++) {
fpr_val = get_fpr64(&target->thread.fpu.fpr[i], 0);
- err = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ err = user_regset_copyout(pos, count, kbuf, ubuf,
&fpr_val, i * sizeof(elf_fpreg_t),
(i + 1) * sizeof(elf_fpreg_t));
if (err)
@@ -438,27 +449,54 @@ static int fpr_get(struct task_struct *t
return 0;
}
-static int fpr_set(struct task_struct *target,
+/* Copy the floating-point context to the supplied NT_PRFPREG buffer. */
+static int fpr_get(struct task_struct *target,
const struct user_regset *regset,
unsigned int pos, unsigned int count,
- const void *kbuf, const void __user *ubuf)
+ void *kbuf, void __user *ubuf)
{
- unsigned i;
int err;
- u64 fpr_val;
/* XXX fcr31 */
- init_fp_ctx(target);
+ if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t))
+ err = fpr_get_fpa(target, &pos, &count, &kbuf, &ubuf);
+ else
+ err = fpr_get_msa(target, &pos, &count, &kbuf, &ubuf);
+
+ return err;
+}
- if (sizeof(target->thread.fpu.fpr[i]) == sizeof(elf_fpreg_t))
- return user_regset_copyin(&pos, &count, &kbuf, &ubuf,
- &target->thread.fpu,
- 0, sizeof(elf_fpregset_t));
+/*
+ * Copy the supplied NT_PRFPREG buffer to the floating-point context,
+ * !CONFIG_CPU_HAS_MSA variant. Buffer slots correspond 1:1 to FP
+ * context's general register slots.
+ */
+static int fpr_set_fpa(struct task_struct *target,
+ unsigned int *pos, unsigned int *count,
+ const void **kbuf, const void __user **ubuf)
+{
+ return user_regset_copyin(pos, count, kbuf, ubuf,
+ &target->thread.fpu,
+ 0, sizeof(elf_fpregset_t));
+}
+
+/*
+ * Copy the supplied NT_PRFPREG buffer to the floating-point context,
+ * CONFIG_CPU_HAS_MSA variant. Buffer slots are copied to lower 64
+ * bits only of FP context's general register slots.
+ */
+static int fpr_set_msa(struct task_struct *target,
+ unsigned int *pos, unsigned int *count,
+ const void **kbuf, const void __user **ubuf)
+{
+ unsigned int i;
+ u64 fpr_val;
+ int err;
BUILD_BUG_ON(sizeof(fpr_val) != sizeof(elf_fpreg_t));
- for (i = 0; i < NUM_FPU_REGS && count >= sizeof(elf_fpreg_t); i++) {
- err = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ for (i = 0; i < NUM_FPU_REGS && *count >= sizeof(elf_fpreg_t); i++) {
+ err = user_regset_copyin(pos, count, kbuf, ubuf,
&fpr_val, i * sizeof(elf_fpreg_t),
(i + 1) * sizeof(elf_fpreg_t));
if (err)
@@ -469,6 +507,26 @@ static int fpr_set(struct task_struct *t
return 0;
}
+/* Copy the supplied NT_PRFPREG buffer to the floating-point context. */
+static int fpr_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf)
+{
+ int err;
+
+ /* XXX fcr31 */
+
+ init_fp_ctx(target);
+
+ if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t))
+ err = fpr_set_fpa(target, &pos, &count, &kbuf, &ubuf);
+ else
+ err = fpr_set_msa(target, &pos, &count, &kbuf, &ubuf);
+
+ return err;
+}
+
enum mips_regset {
REGSET_GPR,
REGSET_FPR,
Patches currently in stable-queue which might be from macro(a)mips.com are
queue-4.14/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch
queue-4.14/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch
queue-4.14/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch
queue-4.14/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch
queue-4.14/mips-factor-out-nt_prfpreg-regset-access-helpers.patch
queue-4.14/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch
queue-4.14/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch
This is a note to let you know that I've just added the patch titled
MIPS: Disallow outsized PTRACE_SETREGSET NT_PRFPREG regset accesses
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:
mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.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 c8c5a3a24d395b14447a9a89d61586a913840a3b Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 11 Dec 2017 22:56:54 +0000
Subject: MIPS: Disallow outsized PTRACE_SETREGSET NT_PRFPREG regset accesses
From: Maciej W. Rozycki <macro(a)mips.com>
commit c8c5a3a24d395b14447a9a89d61586a913840a3b upstream.
Complement commit c23b3d1a5311 ("MIPS: ptrace: Change GP regset to use
correct core dump register layout") and also reject outsized
PTRACE_SETREGSET requests to the NT_PRFPREG regset, like with the
NT_PRSTATUS regset.
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: c23b3d1a5311 ("MIPS: ptrace: Change GP regset to use correct core dump register layout")
Cc: James Hogan <james.hogan(a)mips.com>
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Alex Smith <alex(a)alex-smith.me.uk>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17930/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/ptrace.c | 3 +++
1 file changed, 3 insertions(+)
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -541,6 +541,9 @@ static int fpr_set(struct task_struct *t
BUG_ON(count % sizeof(elf_fpreg_t));
+ if (pos + count > sizeof(elf_fpregset_t))
+ return -EIO;
+
init_fp_ctx(target);
if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t))
Patches currently in stable-queue which might be from macro(a)mips.com are
queue-4.14/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch
queue-4.14/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch
queue-4.14/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch
queue-4.14/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch
queue-4.14/mips-factor-out-nt_prfpreg-regset-access-helpers.patch
queue-4.14/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch
queue-4.14/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch
This is a note to let you know that I've just added the patch titled
MIPS: Consistently handle buffer counter with PTRACE_SETREGSET
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:
mips-consistently-handle-buffer-counter-with-ptrace_setregset.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 80b3ffce0196ea50068885d085ff981e4b8396f4 Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 11 Dec 2017 22:53:14 +0000
Subject: MIPS: Consistently handle buffer counter with PTRACE_SETREGSET
From: Maciej W. Rozycki <macro(a)mips.com>
commit 80b3ffce0196ea50068885d085ff981e4b8396f4 upstream.
Update commit d614fd58a283 ("mips/ptrace: Preserve previous registers
for short regset write") bug and consistently consume all data supplied
to `fpr_set_msa' with the ptrace(2) PTRACE_SETREGSET request, such that
a zero data buffer counter is returned where insufficient data has been
given to fill a whole number of FP general registers.
In reality this is not going to happen, as the caller is supposed to
only supply data covering a whole number of registers and it is verified
in `ptrace_regset' and again asserted in `fpr_set', however structuring
code such that the presence of trailing partial FP general register data
causes `fpr_set_msa' to return with a non-zero data buffer counter makes
it appear that this trailing data will be used if there are subsequent
writes made to FP registers, which is going to be the case with the FCSR
once the missing write to that register has been fixed.
Fixes: d614fd58a283 ("mips/ptrace: Preserve previous registers for short regset write")
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Cc: James Hogan <james.hogan(a)mips.com>
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Alex Smith <alex(a)alex-smith.me.uk>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17927/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/ptrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -495,7 +495,7 @@ static int fpr_set_msa(struct task_struc
int err;
BUILD_BUG_ON(sizeof(fpr_val) != sizeof(elf_fpreg_t));
- for (i = 0; i < NUM_FPU_REGS && *count >= sizeof(elf_fpreg_t); i++) {
+ for (i = 0; i < NUM_FPU_REGS && *count > 0; i++) {
err = user_regset_copyin(pos, count, kbuf, ubuf,
&fpr_val, i * sizeof(elf_fpreg_t),
(i + 1) * sizeof(elf_fpreg_t));
Patches currently in stable-queue which might be from macro(a)mips.com are
queue-4.14/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch
queue-4.14/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch
queue-4.14/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch
queue-4.14/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch
queue-4.14/mips-factor-out-nt_prfpreg-regset-access-helpers.patch
queue-4.14/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch
queue-4.14/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch
This is a note to let you know that I've just added the patch titled
MIPS: Also verify sizeof `elf_fpreg_t' with PTRACE_SETREGSET
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:
mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.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 006501e039eec411842bb3150c41358867d320c2 Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 11 Dec 2017 22:55:40 +0000
Subject: MIPS: Also verify sizeof `elf_fpreg_t' with PTRACE_SETREGSET
From: Maciej W. Rozycki <macro(a)mips.com>
commit 006501e039eec411842bb3150c41358867d320c2 upstream.
Complement commit d614fd58a283 ("mips/ptrace: Preserve previous
registers for short regset write") and like with the PTRACE_GETREGSET
ptrace(2) request also apply a BUILD_BUG_ON check for the size of the
`elf_fpreg_t' type in the PTRACE_SETREGSET request handler.
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: d614fd58a283 ("mips/ptrace: Preserve previous registers for short regset write")
Cc: James Hogan <james.hogan(a)mips.com>
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Alex Smith <alex(a)alex-smith.me.uk>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17929/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/ptrace.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -438,6 +438,7 @@ static int fpr_get_msa(struct task_struc
u64 fpr_val;
int err;
+ BUILD_BUG_ON(sizeof(fpr_val) != sizeof(elf_fpreg_t));
for (i = 0; i < NUM_FPU_REGS; i++) {
fpr_val = get_fpr64(&target->thread.fpu.fpr[i], 0);
err = user_regset_copyout(pos, count, kbuf, ubuf,
Patches currently in stable-queue which might be from macro(a)mips.com are
queue-4.14/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch
queue-4.14/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch
queue-4.14/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch
queue-4.14/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch
queue-4.14/mips-factor-out-nt_prfpreg-regset-access-helpers.patch
queue-4.14/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch
queue-4.14/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch
This is a note to let you know that I've just added the patch titled
IB/srpt: Fix ACL lookup during login
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ib-srpt-fix-acl-lookup-during-login.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 a1ffa4670cb97ae3a4b3e8535d88be5f643f7c3b Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Wed, 3 Jan 2018 13:39:16 -0800
Subject: IB/srpt: Fix ACL lookup during login
From: Bart Van Assche <bart.vanassche(a)wdc.com>
commit a1ffa4670cb97ae3a4b3e8535d88be5f643f7c3b upstream.
Make sure that the initiator port GUID is stored in ch->ini_guid.
Note: when initiating a connection sgid and dgid members in struct
sa_path_rec represent the source and destination GIDs. When accepting
a connection however sgid represents the destination GID and dgid the
source GID.
Fixes: commit 2bce1a6d2209 ("IB/srpt: Accept GUIDs as port names")
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/ulp/srpt/ib_srpt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
@@ -1991,7 +1991,7 @@ static int srpt_cm_req_recv(struct ib_cm
goto destroy_ib;
}
- guid = (__be16 *)¶m->primary_path->sgid.global.interface_id;
+ guid = (__be16 *)¶m->primary_path->dgid.global.interface_id;
snprintf(ch->ini_guid, sizeof(ch->ini_guid), "%04x:%04x:%04x:%04x",
be16_to_cpu(guid[0]), be16_to_cpu(guid[1]),
be16_to_cpu(guid[2]), be16_to_cpu(guid[3]));
Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are
queue-4.14/ib-srpt-disable-rdma-access-by-the-initiator.patch
queue-4.14/ib-srpt-fix-acl-lookup-during-login.patch
This is a note to let you know that I've just added the patch titled
IB/srpt: Disable RDMA access by the initiator
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ib-srpt-disable-rdma-access-by-the-initiator.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 bec40c26041de61162f7be9d2ce548c756ce0f65 Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Wed, 3 Jan 2018 13:39:15 -0800
Subject: IB/srpt: Disable RDMA access by the initiator
From: Bart Van Assche <bart.vanassche(a)wdc.com>
commit bec40c26041de61162f7be9d2ce548c756ce0f65 upstream.
With the SRP protocol all RDMA operations are initiated by the target.
Since no RDMA operations are initiated by the initiator, do not grant
the initiator permission to submit RDMA reads or writes to the target.
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/ulp/srpt/ib_srpt.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
@@ -1000,8 +1000,7 @@ static int srpt_init_ch_qp(struct srpt_r
return -ENOMEM;
attr->qp_state = IB_QPS_INIT;
- attr->qp_access_flags = IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_READ |
- IB_ACCESS_REMOTE_WRITE;
+ attr->qp_access_flags = IB_ACCESS_LOCAL_WRITE;
attr->port_num = ch->sport->port;
attr->pkey_index = 0;
Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are
queue-4.14/ib-srpt-disable-rdma-access-by-the-initiator.patch
queue-4.14/ib-srpt-fix-acl-lookup-during-login.patch
This is a note to let you know that I've just added the patch titled
cgroup: fix css_task_iter crash on CSS_TASK_ITER_PROC
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:
cgroup-fix-css_task_iter-crash-on-css_task_iter_proc.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 74d0833c659a8a54735e5efdd44f4b225af68586 Mon Sep 17 00:00:00 2001
From: Tejun Heo <tj(a)kernel.org>
Date: Wed, 20 Dec 2017 07:09:19 -0800
Subject: cgroup: fix css_task_iter crash on CSS_TASK_ITER_PROC
From: Tejun Heo <tj(a)kernel.org>
commit 74d0833c659a8a54735e5efdd44f4b225af68586 upstream.
While teaching css_task_iter to handle skipping over tasks which
aren't group leaders, bc2fb7ed089f ("cgroup: add @flags to
css_task_iter_start() and implement CSS_TASK_ITER_PROCS") introduced a
silly bug.
CSS_TASK_ITER_PROCS is implemented by repeating
css_task_iter_advance() while the advanced cursor is pointing to a
non-leader thread. However, the cursor variable, @l, wasn't updated
when the iteration has to advance to the next css_set and the
following repetition would operate on the terminal @l from the
previous iteration which isn't pointing to a valid task leading to
oopses like the following or infinite looping.
BUG: unable to handle kernel NULL pointer dereference at 0000000000000254
IP: __task_pid_nr_ns+0xc7/0xf0
PGD 0 P4D 0
Oops: 0000 [#1] SMP
...
CPU: 2 PID: 1 Comm: systemd Not tainted 4.14.4-200.fc26.x86_64 #1
Hardware name: System manufacturer System Product Name/PRIME B350M-A, BIOS 3203 11/09/2017
task: ffff88c4baee8000 task.stack: ffff96d5c3158000
RIP: 0010:__task_pid_nr_ns+0xc7/0xf0
RSP: 0018:ffff96d5c315bd50 EFLAGS: 00010206
RAX: 0000000000000000 RBX: ffff88c4b68c6000 RCX: 0000000000000250
RDX: ffffffffa5e47960 RSI: 0000000000000000 RDI: ffff88c490f6ab00
RBP: ffff96d5c315bd50 R08: 0000000000001000 R09: 0000000000000005
R10: ffff88c4be006b80 R11: ffff88c42f1b8004 R12: ffff96d5c315bf18
R13: ffff88c42d7dd200 R14: ffff88c490f6a510 R15: ffff88c4b68c6000
FS: 00007f9446f8ea00(0000) GS:ffff88c4be680000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000254 CR3: 00000007f956f000 CR4: 00000000003406e0
Call Trace:
cgroup_procs_show+0x19/0x30
cgroup_seqfile_show+0x4c/0xb0
kernfs_seq_show+0x21/0x30
seq_read+0x2ec/0x3f0
kernfs_fop_read+0x134/0x180
__vfs_read+0x37/0x160
? security_file_permission+0x9b/0xc0
vfs_read+0x8e/0x130
SyS_read+0x55/0xc0
entry_SYSCALL_64_fastpath+0x1a/0xa5
RIP: 0033:0x7f94455f942d
RSP: 002b:00007ffe81ba2d00 EFLAGS: 00000293 ORIG_RAX: 0000000000000000
RAX: ffffffffffffffda RBX: 00005574e2233f00 RCX: 00007f94455f942d
RDX: 0000000000001000 RSI: 00005574e2321a90 RDI: 000000000000002b
RBP: 0000000000000000 R08: 00005574e2321a90 R09: 00005574e231de60
R10: 00007f94458c8b38 R11: 0000000000000293 R12: 00007f94458c8ae0
R13: 00007ffe81ba3800 R14: 0000000000000000 R15: 00005574e2116560
Code: 04 74 0e 89 f6 48 8d 04 76 48 8d 04 c5 f0 05 00 00 48 8b bf b8 05 00 00 48 01 c7 31 c0 48 8b 0f 48 85 c9 74 18 8b b2 30 08 00 00 <3b> 71 04 77 0d 48 c1 e6 05 48 01 f1 48 3b 51 38 74 09 5d c3 8b
RIP: __task_pid_nr_ns+0xc7/0xf0 RSP: ffff96d5c315bd50
Fix it by moving the initialization of the cursor below the repeat
label. While at it, rename it to @next for readability.
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Fixes: bc2fb7ed089f ("cgroup: add @flags to css_task_iter_start() and implement CSS_TASK_ITER_PROCS")
Reported-by: Laura Abbott <labbott(a)redhat.com>
Reported-by: Bronek Kozicki <brok(a)incorrekt.com>
Reported-by: George Amanakis <gamanakis(a)gmail.com>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/cgroup/cgroup.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -4059,26 +4059,24 @@ static void css_task_iter_advance_css_se
static void css_task_iter_advance(struct css_task_iter *it)
{
- struct list_head *l = it->task_pos;
+ struct list_head *next;
lockdep_assert_held(&css_set_lock);
- WARN_ON_ONCE(!l);
-
repeat:
/*
* Advance iterator to find next entry. cset->tasks is consumed
* first and then ->mg_tasks. After ->mg_tasks, we move onto the
* next cset.
*/
- l = l->next;
+ next = it->task_pos->next;
- if (l == it->tasks_head)
- l = it->mg_tasks_head->next;
+ if (next == it->tasks_head)
+ next = it->mg_tasks_head->next;
- if (l == it->mg_tasks_head)
+ if (next == it->mg_tasks_head)
css_task_iter_advance_css_set(it);
else
- it->task_pos = l;
+ it->task_pos = next;
/* if PROCS, skip over tasks which aren't group leaders */
if ((it->flags & CSS_TASK_ITER_PROCS) && it->task_pos &&
Patches currently in stable-queue which might be from tj(a)kernel.org are
queue-4.14/cgroup-fix-css_task_iter-crash-on-css_task_iter_proc.patch
This is a note to let you know that I've just added the patch titled
can: vxcan: improve handling of missing peer name attribute
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:
can-vxcan-improve-handling-of-missing-peer-name-attribute.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 b4c2951a4833e66f1bbfe65ddcd4fdcdfafe5e8f Mon Sep 17 00:00:00 2001
From: Oliver Hartkopp <socketcan(a)hartkopp.net>
Date: Sat, 2 Dec 2017 18:48:52 +0100
Subject: can: vxcan: improve handling of missing peer name attribute
From: Oliver Hartkopp <socketcan(a)hartkopp.net>
commit b4c2951a4833e66f1bbfe65ddcd4fdcdfafe5e8f upstream.
Picking up the patch from Serhey Popovych (commit 191cdb3822e5df6b3c8,
"veth: Be more robust on network device creation when no attributes").
When the peer name attribute is not provided the former implementation tries
to register the given device name twice ... which leads to -EEXIST.
If only one device name is given apply an automatic generated and valid name
for the peer.
Cc: Serhey Popovych <serhe.popovych(a)gmail.com>
Signed-off-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/vxcan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/can/vxcan.c
+++ b/drivers/net/can/vxcan.c
@@ -194,7 +194,7 @@ static int vxcan_newlink(struct net *net
tbp = peer_tb;
}
- if (tbp[IFLA_IFNAME]) {
+ if (ifmp && tbp[IFLA_IFNAME]) {
nla_strlcpy(ifname, tbp[IFLA_IFNAME], IFNAMSIZ);
name_assign_type = NET_NAME_USER;
} else {
Patches currently in stable-queue which might be from socketcan(a)hartkopp.net are
queue-4.14/can-vxcan-improve-handling-of-missing-peer-name-attribute.patch
This is a note to let you know that I've just added the patch titled
can: gs_usb: fix return value of the "set_bittiming" callback
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:
can-gs_usb-fix-return-value-of-the-set_bittiming-callback.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 d5b42e6607661b198d8b26a0c30969605b1bf5c7 Mon Sep 17 00:00:00 2001
From: Wolfgang Grandegger <wg(a)grandegger.com>
Date: Wed, 13 Dec 2017 19:52:23 +0100
Subject: can: gs_usb: fix return value of the "set_bittiming" callback
From: Wolfgang Grandegger <wg(a)grandegger.com>
commit d5b42e6607661b198d8b26a0c30969605b1bf5c7 upstream.
The "set_bittiming" callback treats a positive return value as error!
For that reason "can_changelink()" will quit silently after setting
the bittiming values without processing ctrlmode, restart-ms, etc.
Signed-off-by: Wolfgang Grandegger <wg(a)grandegger.com>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/usb/gs_usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/can/usb/gs_usb.c
+++ b/drivers/net/can/usb/gs_usb.c
@@ -449,7 +449,7 @@ static int gs_usb_set_bittiming(struct n
dev_err(netdev->dev.parent, "Couldn't set bittimings (err=%d)",
rc);
- return rc;
+ return (rc > 0) ? 0 : rc;
}
static void gs_usb_xmit_callback(struct urb *urb)
Patches currently in stable-queue which might be from wg(a)grandegger.com are
queue-4.14/can-gs_usb-fix-return-value-of-the-set_bittiming-callback.patch
This is a note to let you know that I've just added the patch titled
perf/core: Fix concurrent sys_perf_event_open() vs. 'move_group' race
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-core-fix-concurrent-sys_perf_event_open-vs.-move_group-race.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 321027c1fe77f892f4ea07846aeae08cefbbb290 Mon Sep 17 00:00:00 2001
From: Peter Zijlstra <peterz(a)infradead.org>
Date: Wed, 11 Jan 2017 21:09:50 +0100
Subject: perf/core: Fix concurrent sys_perf_event_open() vs. 'move_group' race
From: Peter Zijlstra <peterz(a)infradead.org>
commit 321027c1fe77f892f4ea07846aeae08cefbbb290 upstream.
Di Shen reported a race between two concurrent sys_perf_event_open()
calls where both try and move the same pre-existing software group
into a hardware context.
The problem is exactly that described in commit:
f63a8daa5812 ("perf: Fix event->ctx locking")
... where, while we wait for a ctx->mutex acquisition, the event->ctx
relation can have changed under us.
That very same commit failed to recognise sys_perf_event_context() as an
external access vector to the events and thereby didn't apply the
established locking rules correctly.
So while one sys_perf_event_open() call is stuck waiting on
mutex_lock_double(), the other (which owns said locks) moves the group
about. So by the time the former sys_perf_event_open() acquires the
locks, the context we've acquired is stale (and possibly dead).
Apply the established locking rules as per perf_event_ctx_lock_nested()
to the mutex_lock_double() for the 'move_group' case. This obviously means
we need to validate state after we acquire the locks.
Reported-by: Di Shen (Keen Lab)
Tested-by: John Dias <joaodias(a)google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme(a)kernel.org>
Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Min Chong <mchong(a)google.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Stephane Eranian <eranian(a)google.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Vince Weaver <vincent.weaver(a)maine.edu>
Fixes: f63a8daa5812 ("perf: Fix event->ctx locking")
Link: http://lkml.kernel.org/r/20170106131444.GZ3174@twins.programming.kicks-ass.…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
[bwh: Backported to 3.16:
- Use ACCESS_ONCE() instead of READ_ONCE()
- Test perf_event::group_flags instead of group_caps
- Add the err_locked cleanup block, which we didn't need before
- Adjust context]
Signed-off-by: Ben Hutchings <ben(a)decadent.org.uk>
Signed-off-by: Suren Baghdasaryan <surenb(a)google.com>
Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
This upstream patch is featured in recent Android Security bulletin.
Picked up this backported patch from android-3.18. Build tested on 3.18.91
kernel/events/core.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 57 insertions(+), 4 deletions(-)
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7414,6 +7414,37 @@ static void mutex_lock_double(struct mut
mutex_lock_nested(b, SINGLE_DEPTH_NESTING);
}
+/*
+ * Variation on perf_event_ctx_lock_nested(), except we take two context
+ * mutexes.
+ */
+static struct perf_event_context *
+__perf_event_ctx_lock_double(struct perf_event *group_leader,
+ struct perf_event_context *ctx)
+{
+ struct perf_event_context *gctx;
+
+again:
+ rcu_read_lock();
+ gctx = ACCESS_ONCE(group_leader->ctx);
+ if (!atomic_inc_not_zero(&gctx->refcount)) {
+ rcu_read_unlock();
+ goto again;
+ }
+ rcu_read_unlock();
+
+ mutex_lock_double(&gctx->mutex, &ctx->mutex);
+
+ if (group_leader->ctx != gctx) {
+ mutex_unlock(&ctx->mutex);
+ mutex_unlock(&gctx->mutex);
+ put_ctx(gctx);
+ goto again;
+ }
+
+ return gctx;
+}
+
/**
* sys_perf_event_open - open a performance event, associate it to a task/cpu
*
@@ -7626,14 +7657,31 @@ SYSCALL_DEFINE5(perf_event_open,
}
if (move_group) {
- gctx = group_leader->ctx;
+ gctx = __perf_event_ctx_lock_double(group_leader, ctx);
+
+ /*
+ * Check if we raced against another sys_perf_event_open() call
+ * moving the software group underneath us.
+ */
+ if (!(group_leader->group_flags & PERF_GROUP_SOFTWARE)) {
+ /*
+ * If someone moved the group out from under us, check
+ * if this new event wound up on the same ctx, if so
+ * its the regular !move_group case, otherwise fail.
+ */
+ if (gctx != ctx) {
+ err = -EINVAL;
+ goto err_locked;
+ } else {
+ perf_event_ctx_unlock(group_leader, gctx);
+ move_group = 0;
+ }
+ }
/*
* See perf_event_ctx_lock() for comments on the details
* of swizzling perf_event::ctx.
*/
- mutex_lock_double(&gctx->mutex, &ctx->mutex);
-
perf_remove_from_context(group_leader, false);
/*
@@ -7674,7 +7722,7 @@ SYSCALL_DEFINE5(perf_event_open,
perf_unpin_context(ctx);
if (move_group) {
- mutex_unlock(&gctx->mutex);
+ perf_event_ctx_unlock(group_leader, gctx);
put_ctx(gctx);
}
mutex_unlock(&ctx->mutex);
@@ -7703,6 +7751,11 @@ SYSCALL_DEFINE5(perf_event_open,
fd_install(event_fd, event_file);
return event_fd;
+err_locked:
+ if (move_group)
+ perf_event_ctx_unlock(group_leader, gctx);
+ mutex_unlock(&ctx->mutex);
+ fput(event_file);
err_context:
perf_unpin_context(ctx);
put_ctx(ctx);
Patches currently in stable-queue which might be from peterz(a)infradead.org are
queue-3.18/perf-core-fix-concurrent-sys_perf_event_open-vs.-move_group-race.patch
This is a note to let you know that I've just added the patch titled
MIPS: Also verify sizeof `elf_fpreg_t' with PTRACE_SETREGSET
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:
mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.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 006501e039eec411842bb3150c41358867d320c2 Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 11 Dec 2017 22:55:40 +0000
Subject: MIPS: Also verify sizeof `elf_fpreg_t' with PTRACE_SETREGSET
From: Maciej W. Rozycki <macro(a)mips.com>
commit 006501e039eec411842bb3150c41358867d320c2 upstream.
Complement commit d614fd58a283 ("mips/ptrace: Preserve previous
registers for short regset write") and like with the PTRACE_GETREGSET
ptrace(2) request also apply a BUILD_BUG_ON check for the size of the
`elf_fpreg_t' type in the PTRACE_SETREGSET request handler.
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: d614fd58a283 ("mips/ptrace: Preserve previous registers for short regset write")
Cc: James Hogan <james.hogan(a)mips.com>
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Alex Smith <alex(a)alex-smith.me.uk>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17929/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/ptrace.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -416,6 +416,7 @@ static int fpr_get(struct task_struct *t
&target->thread.fpu,
0, sizeof(elf_fpregset_t));
+ BUILD_BUG_ON(sizeof(fpr_val) != sizeof(elf_fpreg_t));
for (i = 0; i < NUM_FPU_REGS; i++) {
fpr_val = get_fpr64(&target->thread.fpu.fpr[i], 0);
err = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
Patches currently in stable-queue which might be from macro(a)mips.com are
queue-3.18/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch
This is a note to let you know that I've just added the patch titled
IB/srpt: Disable RDMA access by the initiator
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:
ib-srpt-disable-rdma-access-by-the-initiator.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 bec40c26041de61162f7be9d2ce548c756ce0f65 Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Wed, 3 Jan 2018 13:39:15 -0800
Subject: IB/srpt: Disable RDMA access by the initiator
From: Bart Van Assche <bart.vanassche(a)wdc.com>
commit bec40c26041de61162f7be9d2ce548c756ce0f65 upstream.
With the SRP protocol all RDMA operations are initiated by the target.
Since no RDMA operations are initiated by the initiator, do not grant
the initiator permission to submit RDMA reads or writes to the target.
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/ulp/srpt/ib_srpt.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
@@ -959,8 +959,7 @@ static int srpt_init_ch_qp(struct srpt_r
return -ENOMEM;
attr->qp_state = IB_QPS_INIT;
- attr->qp_access_flags = IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_READ |
- IB_ACCESS_REMOTE_WRITE;
+ attr->qp_access_flags = IB_ACCESS_LOCAL_WRITE;
attr->port_num = ch->sport->port;
attr->pkey_index = 0;
Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are
queue-3.18/ib-srpt-disable-rdma-access-by-the-initiator.patch
This is a note to let you know that I've just added the patch titled
can: gs_usb: fix return value of the "set_bittiming" callback
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:
can-gs_usb-fix-return-value-of-the-set_bittiming-callback.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 d5b42e6607661b198d8b26a0c30969605b1bf5c7 Mon Sep 17 00:00:00 2001
From: Wolfgang Grandegger <wg(a)grandegger.com>
Date: Wed, 13 Dec 2017 19:52:23 +0100
Subject: can: gs_usb: fix return value of the "set_bittiming" callback
From: Wolfgang Grandegger <wg(a)grandegger.com>
commit d5b42e6607661b198d8b26a0c30969605b1bf5c7 upstream.
The "set_bittiming" callback treats a positive return value as error!
For that reason "can_changelink()" will quit silently after setting
the bittiming values without processing ctrlmode, restart-ms, etc.
Signed-off-by: Wolfgang Grandegger <wg(a)grandegger.com>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/usb/gs_usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/can/usb/gs_usb.c
+++ b/drivers/net/can/usb/gs_usb.c
@@ -430,7 +430,7 @@ static int gs_usb_set_bittiming(struct n
dev_err(netdev->dev.parent, "Couldn't set bittimings (err=%d)",
rc);
- return rc;
+ return (rc > 0) ? 0 : rc;
}
static void gs_usb_xmit_callback(struct urb *urb)
Patches currently in stable-queue which might be from wg(a)grandegger.com are
queue-3.18/can-gs_usb-fix-return-value-of-the-set_bittiming-callback.patch
commit 98b8e4e5c17bf87c1b18ed929472051dab39878c upstream
Please apply to 4.9.x and later stable kernel trees (this is as far back
as 86d9f48534e8 was applied).
This submission should have followed Option 1, but I failed to Cc:
stable in the original commit.
Calling acpi_wmi_init() at the subsys_initcall() level causes ordering
issues to appear on some systems and they are difficult to reproduce,
because there is no guaranteed ordering between subsys_initcall()
calls, so they may occur in different orders on different systems.
In particular, commit 86d9f48534e8 (mm/slab: fix kmemcg cache
creation delayed issue) exposed one of these issues where genl_init()
and acpi_wmi_init() are both called at the same initcall level, but
the former must run before the latter so as to avoid a NULL pointer
dereference.
For this reason, move the acpi_wmi_init() invocation to the
initcall_sync level which should still be early enough for things
to work correctly in the WMI land.
Link: https://marc.info/?t=151274596700002&r=1&w=2
Reported-by: Jonathan McDowell <noodles(a)earth.li>
Reported-by: Joonsoo Kim <iamjoonsoo.kim(a)lge.com>
Tested-by: Jonathan McDowell <noodles(a)earth.li>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Darren Hart (VMware) <dvhart(a)infradead.org>
---
drivers/platform/x86/wmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
index 791449a..daa68ac 100644
--- a/drivers/platform/x86/wmi.c
+++ b/drivers/platform/x86/wmi.c
@@ -1458,5 +1458,5 @@ static void __exit acpi_wmi_exit(void)
class_unregister(&wmi_bus_class);
}
-subsys_initcall(acpi_wmi_init);
+subsys_initcall_sync(acpi_wmi_init);
module_exit(acpi_wmi_exit);
--
2.9.4
--
Darren Hart
VMware Open Source Technology Center
From: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
commit 68920c973254c5b71a684645c5f6f82d6732c5d6 upstream.
With upcoming CONFIG_UBSAN the following BUILD_BUG_ON in
net/mac80211/debugfs.c starts to trigger:
BUILD_BUG_ON(hw_flag_names[NUM_IEEE80211_HW_FLAGS] != (void *)0x1);
It seems, that compiler instrumentation causes some code
deoptimizations. Because of that GCC is not being able to resolve
condition in BUILD_BUG_ON() at compile time.
We could make size of hw_flag_names array unspecified and replace the
condition in BUILD_BUG_ON() with following:
ARRAY_SIZE(hw_flag_names) != NUM_IEEE80211_HW_FLAGS
That will have the same effect as before (adding new flag without
updating array will trigger build failure) except it doesn't fail with
CONFIG_UBSAN. As a bonus this patch slightly decreases size of
hw_flag_names array.
Signed-off-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Cc: Johannes Berg <johannes(a)sipsolutions.net>
Cc: "David S. Miller" <davem(a)davemloft.net>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
[Daniel: backport to 4.4.]
Signed-off-by: Daniel Wagner <daniel.wagner(a)siemens.com>
---
Hi,
The only stable tree which is missing this fix is 4.4. 4.1 doesn't
have 30686bf7f5b3 ("mac80211: convert HW flags to unsigned long
bitmap") which makes gcc unhappy with allmodconfig. 4.9 contains the
fix.
Thanks,
Daniel
net/mac80211/debugfs.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index 4d2aaebd4f97..e546a987a9d3 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -91,7 +91,7 @@ static const struct file_operations reset_ops = {
};
#endif
-static const char *hw_flag_names[NUM_IEEE80211_HW_FLAGS + 1] = {
+static const char *hw_flag_names[] = {
#define FLAG(F) [IEEE80211_HW_##F] = #F
FLAG(HAS_RATE_CONTROL),
FLAG(RX_INCLUDES_FCS),
@@ -125,9 +125,6 @@ static const char *hw_flag_names[NUM_IEEE80211_HW_FLAGS + 1] = {
FLAG(TDLS_WIDER_BW),
FLAG(SUPPORTS_AMSDU_IN_AMPDU),
FLAG(BEACON_TX_STATUS),
-
- /* keep last for the build bug below */
- (void *)0x1
#undef FLAG
};
@@ -147,7 +144,7 @@ static ssize_t hwflags_read(struct file *file, char __user *user_buf,
/* fail compilation if somebody adds or removes
* a flag without updating the name array above
*/
- BUILD_BUG_ON(hw_flag_names[NUM_IEEE80211_HW_FLAGS] != (void *)0x1);
+ BUILD_BUG_ON(ARRAY_SIZE(hw_flag_names) != NUM_IEEE80211_HW_FLAGS);
for (i = 0; i < NUM_IEEE80211_HW_FLAGS; i++) {
if (test_bit(i, local->hw.flags))
--
2.14.3
From: Peter Zijlstra <peterz(a)infradead.org>
commit 321027c1fe77f892f4ea07846aeae08cefbbb290 upstream.
Di Shen reported a race between two concurrent sys_perf_event_open()
calls where both try and move the same pre-existing software group
into a hardware context.
The problem is exactly that described in commit:
f63a8daa5812 ("perf: Fix event->ctx locking")
... where, while we wait for a ctx->mutex acquisition, the event->ctx
relation can have changed under us.
That very same commit failed to recognise sys_perf_event_context() as an
external access vector to the events and thereby didn't apply the
established locking rules correctly.
So while one sys_perf_event_open() call is stuck waiting on
mutex_lock_double(), the other (which owns said locks) moves the group
about. So by the time the former sys_perf_event_open() acquires the
locks, the context we've acquired is stale (and possibly dead).
Apply the established locking rules as per perf_event_ctx_lock_nested()
to the mutex_lock_double() for the 'move_group' case. This obviously means
we need to validate state after we acquire the locks.
Reported-by: Di Shen (Keen Lab)
Tested-by: John Dias <joaodias(a)google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme(a)kernel.org>
Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Min Chong <mchong(a)google.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Stephane Eranian <eranian(a)google.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Vince Weaver <vincent.weaver(a)maine.edu>
Fixes: f63a8daa5812 ("perf: Fix event->ctx locking")
Link: http://lkml.kernel.org/r/20170106131444.GZ3174@twins.programming.kicks-ass.…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
[bwh: Backported to 3.16:
- Use ACCESS_ONCE() instead of READ_ONCE()
- Test perf_event::group_flags instead of group_caps
- Add the err_locked cleanup block, which we didn't need before
- Adjust context]
Signed-off-by: Ben Hutchings <ben(a)decadent.org.uk>
Signed-off-by: Suren Baghdasaryan <surenb(a)google.com>
Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org>
---
This upstream patch is featured in recent Android Security bulletin.
Picked up this backported patch from android-3.18. Build tested on 3.18.91
kernel/events/core.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 57 insertions(+), 4 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 9b12efcefdf7..de3303aab7d6 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7414,6 +7414,37 @@ static void mutex_lock_double(struct mutex *a, struct mutex *b)
mutex_lock_nested(b, SINGLE_DEPTH_NESTING);
}
+/*
+ * Variation on perf_event_ctx_lock_nested(), except we take two context
+ * mutexes.
+ */
+static struct perf_event_context *
+__perf_event_ctx_lock_double(struct perf_event *group_leader,
+ struct perf_event_context *ctx)
+{
+ struct perf_event_context *gctx;
+
+again:
+ rcu_read_lock();
+ gctx = ACCESS_ONCE(group_leader->ctx);
+ if (!atomic_inc_not_zero(&gctx->refcount)) {
+ rcu_read_unlock();
+ goto again;
+ }
+ rcu_read_unlock();
+
+ mutex_lock_double(&gctx->mutex, &ctx->mutex);
+
+ if (group_leader->ctx != gctx) {
+ mutex_unlock(&ctx->mutex);
+ mutex_unlock(&gctx->mutex);
+ put_ctx(gctx);
+ goto again;
+ }
+
+ return gctx;
+}
+
/**
* sys_perf_event_open - open a performance event, associate it to a task/cpu
*
@@ -7626,14 +7657,31 @@ SYSCALL_DEFINE5(perf_event_open,
}
if (move_group) {
- gctx = group_leader->ctx;
+ gctx = __perf_event_ctx_lock_double(group_leader, ctx);
+
+ /*
+ * Check if we raced against another sys_perf_event_open() call
+ * moving the software group underneath us.
+ */
+ if (!(group_leader->group_flags & PERF_GROUP_SOFTWARE)) {
+ /*
+ * If someone moved the group out from under us, check
+ * if this new event wound up on the same ctx, if so
+ * its the regular !move_group case, otherwise fail.
+ */
+ if (gctx != ctx) {
+ err = -EINVAL;
+ goto err_locked;
+ } else {
+ perf_event_ctx_unlock(group_leader, gctx);
+ move_group = 0;
+ }
+ }
/*
* See perf_event_ctx_lock() for comments on the details
* of swizzling perf_event::ctx.
*/
- mutex_lock_double(&gctx->mutex, &ctx->mutex);
-
perf_remove_from_context(group_leader, false);
/*
@@ -7674,7 +7722,7 @@ SYSCALL_DEFINE5(perf_event_open,
perf_unpin_context(ctx);
if (move_group) {
- mutex_unlock(&gctx->mutex);
+ perf_event_ctx_unlock(group_leader, gctx);
put_ctx(gctx);
}
mutex_unlock(&ctx->mutex);
@@ -7703,6 +7751,11 @@ SYSCALL_DEFINE5(perf_event_open,
fd_install(event_fd, event_file);
return event_fd;
+err_locked:
+ if (move_group)
+ perf_event_ctx_unlock(group_leader, gctx);
+ mutex_unlock(&ctx->mutex);
+ fput(event_file);
err_context:
perf_unpin_context(ctx);
put_ctx(ctx);
--
2.7.4
The patch below does not apply to the 3.18-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 c8c5a3a24d395b14447a9a89d61586a913840a3b Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 11 Dec 2017 22:56:54 +0000
Subject: [PATCH] MIPS: Disallow outsized PTRACE_SETREGSET NT_PRFPREG regset
accesses
Complement commit c23b3d1a5311 ("MIPS: ptrace: Change GP regset to use
correct core dump register layout") and also reject outsized
PTRACE_SETREGSET requests to the NT_PRFPREG regset, like with the
NT_PRSTATUS regset.
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: c23b3d1a5311 ("MIPS: ptrace: Change GP regset to use correct core dump register layout")
Cc: James Hogan <james.hogan(a)mips.com>
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Alex Smith <alex(a)alex-smith.me.uk>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Cc: stable(a)vger.kernel.org # v3.17+
Patchwork: https://patchwork.linux-mips.org/patch/17930/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
diff --git a/arch/mips/kernel/ptrace.c b/arch/mips/kernel/ptrace.c
index 256908951a7c..0b23b1ad99e6 100644
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -550,6 +550,9 @@ static int fpr_set(struct task_struct *target,
BUG_ON(count % sizeof(elf_fpreg_t));
+ if (pos + count > sizeof(elf_fpregset_t))
+ return -EIO;
+
init_fp_ctx(target);
if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t))
The patch below does not apply to the 3.18-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 be07a6a1188372b6d19a3307ec33211fc9c9439d Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 11 Dec 2017 22:54:33 +0000
Subject: [PATCH] MIPS: Fix an FCSR access API regression with NT_PRFPREG and
MSA
Fix a commit 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for
FP regset") public API regression, then activated by commit 1db1af84d6df
("MIPS: Basic MSA context switching support"), that caused the FCSR
register not to be read or written for CONFIG_CPU_HAS_MSA kernel
configurations (regardless of actual presence or absence of the MSA
feature in a given processor) with ptrace(2) PTRACE_GETREGSET and
PTRACE_SETREGSET requests nor recorded in core dumps.
This is because with !CONFIG_CPU_HAS_MSA configurations the whole of
`elf_fpregset_t' array is bulk-copied as it is, which includes the FCSR
in one half of the last, 33rd slot, whereas with CONFIG_CPU_HAS_MSA
configurations array elements are copied individually, and then only the
leading 32 FGR slots while the remaining slot is ignored.
Correct the code then such that only FGR slots are copied in the
respective !MSA and MSA helpers an then the FCSR slot is handled
separately in common code. Use `ptrace_setfcr31' to update the FCSR
too, so that the read-only mask is respected.
Retrieving a correct value of FCSR is important in debugging not only
for the human to be able to get the right interpretation of the
situation, but for correct operation of GDB as well. This is because
the condition code bits in FSCR are used by GDB to determine the
location to place a breakpoint at when single-stepping through an FPU
branch instruction. If such a breakpoint is placed incorrectly (i.e.
with the condition reversed), then it will be missed, likely causing the
debuggee to run away from the control of GDB and consequently breaking
the process of investigation.
Fortunately GDB continues using the older PTRACE_GETFPREGS ptrace(2)
request which is unaffected, so the regression only really hits with
post-mortem debug sessions using a core dump file, in which case
execution, and consequently single-stepping through branches is not
possible. Of course core files created by buggy kernels out there will
have the value of FCSR recorded clobbered, but such core files cannot be
corrected and the person using them simply will have to be aware that
the value of FCSR retrieved is not reliable.
Which also means we can likely get away without defining a replacement
API which would ensure a correct value of FSCR to be retrieved, or none
at all.
This is based on previous work by Alex Smith, extensively rewritten.
Signed-off-by: Alex Smith <alex(a)alex-smith.me.uk>
Signed-off-by: James Hogan <james.hogan(a)mips.com>
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset")
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Cc: stable(a)vger.kernel.org # v3.15+
Patchwork: https://patchwork.linux-mips.org/patch/17928/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
diff --git a/arch/mips/kernel/ptrace.c b/arch/mips/kernel/ptrace.c
index 47a01d5f26ea..0a939593ccb7 100644
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -422,7 +422,7 @@ static int gpr64_set(struct task_struct *target,
/*
* Copy the floating-point context to the supplied NT_PRFPREG buffer,
* !CONFIG_CPU_HAS_MSA variant. FP context's general register slots
- * correspond 1:1 to buffer slots.
+ * correspond 1:1 to buffer slots. Only general registers are copied.
*/
static int fpr_get_fpa(struct task_struct *target,
unsigned int *pos, unsigned int *count,
@@ -430,13 +430,14 @@ static int fpr_get_fpa(struct task_struct *target,
{
return user_regset_copyout(pos, count, kbuf, ubuf,
&target->thread.fpu,
- 0, sizeof(elf_fpregset_t));
+ 0, NUM_FPU_REGS * sizeof(elf_fpreg_t));
}
/*
* Copy the floating-point context to the supplied NT_PRFPREG buffer,
* CONFIG_CPU_HAS_MSA variant. Only lower 64 bits of FP context's
- * general register slots are copied to buffer slots.
+ * general register slots are copied to buffer slots. Only general
+ * registers are copied.
*/
static int fpr_get_msa(struct task_struct *target,
unsigned int *pos, unsigned int *count,
@@ -458,20 +459,29 @@ static int fpr_get_msa(struct task_struct *target,
return 0;
}
-/* Copy the floating-point context to the supplied NT_PRFPREG buffer. */
+/*
+ * Copy the floating-point context to the supplied NT_PRFPREG buffer.
+ * Choose the appropriate helper for general registers, and then copy
+ * the FCSR register separately.
+ */
static int fpr_get(struct task_struct *target,
const struct user_regset *regset,
unsigned int pos, unsigned int count,
void *kbuf, void __user *ubuf)
{
+ const int fcr31_pos = NUM_FPU_REGS * sizeof(elf_fpreg_t);
int err;
- /* XXX fcr31 */
-
if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t))
err = fpr_get_fpa(target, &pos, &count, &kbuf, &ubuf);
else
err = fpr_get_msa(target, &pos, &count, &kbuf, &ubuf);
+ if (err)
+ return err;
+
+ err = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.fpu.fcr31,
+ fcr31_pos, fcr31_pos + sizeof(u32));
return err;
}
@@ -479,7 +489,7 @@ static int fpr_get(struct task_struct *target,
/*
* Copy the supplied NT_PRFPREG buffer to the floating-point context,
* !CONFIG_CPU_HAS_MSA variant. Buffer slots correspond 1:1 to FP
- * context's general register slots.
+ * context's general register slots. Only general registers are copied.
*/
static int fpr_set_fpa(struct task_struct *target,
unsigned int *pos, unsigned int *count,
@@ -487,13 +497,14 @@ static int fpr_set_fpa(struct task_struct *target,
{
return user_regset_copyin(pos, count, kbuf, ubuf,
&target->thread.fpu,
- 0, sizeof(elf_fpregset_t));
+ 0, NUM_FPU_REGS * sizeof(elf_fpreg_t));
}
/*
* Copy the supplied NT_PRFPREG buffer to the floating-point context,
* CONFIG_CPU_HAS_MSA variant. Buffer slots are copied to lower 64
- * bits only of FP context's general register slots.
+ * bits only of FP context's general register slots. Only general
+ * registers are copied.
*/
static int fpr_set_msa(struct task_struct *target,
unsigned int *pos, unsigned int *count,
@@ -518,6 +529,8 @@ static int fpr_set_msa(struct task_struct *target,
/*
* Copy the supplied NT_PRFPREG buffer to the floating-point context.
+ * Choose the appropriate helper for general registers, and then copy
+ * the FCSR register separately.
*
* We optimize for the case where `count % sizeof(elf_fpreg_t) == 0',
* which is supposed to have been guaranteed by the kernel before
@@ -530,18 +543,30 @@ static int fpr_set(struct task_struct *target,
unsigned int pos, unsigned int count,
const void *kbuf, const void __user *ubuf)
{
+ const int fcr31_pos = NUM_FPU_REGS * sizeof(elf_fpreg_t);
+ u32 fcr31;
int err;
BUG_ON(count % sizeof(elf_fpreg_t));
- /* XXX fcr31 */
-
init_fp_ctx(target);
if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t))
err = fpr_set_fpa(target, &pos, &count, &kbuf, &ubuf);
else
err = fpr_set_msa(target, &pos, &count, &kbuf, &ubuf);
+ if (err)
+ return err;
+
+ if (count > 0) {
+ err = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &fcr31,
+ fcr31_pos, fcr31_pos + sizeof(u32));
+ if (err)
+ return err;
+
+ ptrace_setfcr31(target, fcr31);
+ }
return err;
}
The patch below does not apply to the 3.18-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 80b3ffce0196ea50068885d085ff981e4b8396f4 Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 11 Dec 2017 22:53:14 +0000
Subject: [PATCH] MIPS: Consistently handle buffer counter with
PTRACE_SETREGSET
Update commit d614fd58a283 ("mips/ptrace: Preserve previous registers
for short regset write") bug and consistently consume all data supplied
to `fpr_set_msa' with the ptrace(2) PTRACE_SETREGSET request, such that
a zero data buffer counter is returned where insufficient data has been
given to fill a whole number of FP general registers.
In reality this is not going to happen, as the caller is supposed to
only supply data covering a whole number of registers and it is verified
in `ptrace_regset' and again asserted in `fpr_set', however structuring
code such that the presence of trailing partial FP general register data
causes `fpr_set_msa' to return with a non-zero data buffer counter makes
it appear that this trailing data will be used if there are subsequent
writes made to FP registers, which is going to be the case with the FCSR
once the missing write to that register has been fixed.
Fixes: d614fd58a283 ("mips/ptrace: Preserve previous registers for short regset write")
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Cc: James Hogan <james.hogan(a)mips.com>
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Alex Smith <alex(a)alex-smith.me.uk>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Cc: stable(a)vger.kernel.org # v4.11+
Patchwork: https://patchwork.linux-mips.org/patch/17927/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
diff --git a/arch/mips/kernel/ptrace.c b/arch/mips/kernel/ptrace.c
index 7fcadaaf330f..47a01d5f26ea 100644
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -504,7 +504,7 @@ static int fpr_set_msa(struct task_struct *target,
int err;
BUILD_BUG_ON(sizeof(fpr_val) != sizeof(elf_fpreg_t));
- for (i = 0; i < NUM_FPU_REGS && *count >= sizeof(elf_fpreg_t); i++) {
+ for (i = 0; i < NUM_FPU_REGS && *count > 0; i++) {
err = user_regset_copyin(pos, count, kbuf, ubuf,
&fpr_val, i * sizeof(elf_fpreg_t),
(i + 1) * sizeof(elf_fpreg_t));
The patch below does not apply to the 3.18-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 dc24d0edf33c3e15099688b6bbdf7bdc24bf6e91 Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Mon, 11 Dec 2017 22:52:15 +0000
Subject: [PATCH] MIPS: Guard against any partial write attempt with
PTRACE_SETREGSET
Complement commit d614fd58a283 ("mips/ptrace: Preserve previous
registers for short regset write") and ensure that no partial register
write attempt is made with PTRACE_SETREGSET, as we do not preinitialize
any temporaries used to hold incoming register data and consequently
random data could be written.
It is the responsibility of the caller, such as `ptrace_regset', to
arrange for writes to span whole registers only, so here we only assert
that it has indeed happened.
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset")
Cc: James Hogan <james.hogan(a)mips.com>
Cc: Paul Burton <Paul.Burton(a)mips.com>
Cc: Alex Smith <alex(a)alex-smith.me.uk>
Cc: Dave Martin <Dave.Martin(a)arm.com>
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Cc: stable(a)vger.kernel.org # v3.15+
Patchwork: https://patchwork.linux-mips.org/patch/17926/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
diff --git a/arch/mips/kernel/ptrace.c b/arch/mips/kernel/ptrace.c
index 62e8ffd9370a..7fcadaaf330f 100644
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -516,7 +516,15 @@ static int fpr_set_msa(struct task_struct *target,
return 0;
}
-/* Copy the supplied NT_PRFPREG buffer to the floating-point context. */
+/*
+ * Copy the supplied NT_PRFPREG buffer to the floating-point context.
+ *
+ * We optimize for the case where `count % sizeof(elf_fpreg_t) == 0',
+ * which is supposed to have been guaranteed by the kernel before
+ * calling us, e.g. in `ptrace_regset'. We enforce that requirement,
+ * so that we can safely avoid preinitializing temporaries for
+ * partial register writes.
+ */
static int fpr_set(struct task_struct *target,
const struct user_regset *regset,
unsigned int pos, unsigned int count,
@@ -524,6 +532,8 @@ static int fpr_set(struct task_struct *target,
{
int err;
+ BUG_ON(count % sizeof(elf_fpreg_t));
+
/* XXX fcr31 */
init_fp_ctx(target);