Skip to contentSkip to conversation

3.18.62-stable review

PATCH In review Greg Kroah-Hartman 3 participants 28 messages Jul 19, 2017 – Jul 20, 2017 Stable branch

lore
Share & tools
lore

Greg Kroah-Hartman

author maintainer
#0 lore raw

cover 3.18.62-stable review

This is the start of the stable review cycle for the 3.18.62 release. There are 28 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Fri Jul 21 11:13:09 UTC 2017. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.62-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-3.18.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>

    Linux 3.18.62-rc1

Pavankumar Kondeti <[email protected]>
tracing: Use SOFTIRQ_OFFSET for softirq dectection for more accurate results

Dan Carpenter <[email protected]>
PM / QoS: return -EINVAL for bogus strings

Peter Zijlstra <[email protected]>
sched/topology: Fix overlapping sched_group_mask

Lauro Ramos Venancio <[email protected]>
sched/topology: Optimize build_group_mask()

Horia Geantă <[email protected]>
crypto: caam - fix signals handling

Herbert Xu <[email protected]>
crypto: sha1-ssse3 - Disable avx2

Gilad Ben-Yossef <[email protected]>
crypto: atmel - only treat EBUSY as transient if backlog

Martin Hicks <[email protected]>
crypto: talitos - Extend max key length for SHA384/512-HMAC and AEAD

Helge Deller <[email protected]>
mm: fix overflow check in expand_upwards()

Adam Borowski <[email protected]>
vt: fix unchecked __put_user() in tioclinux ioctls

Kees Cook <[email protected]>
exec: Limit arg stack to at most 75% of _STK_LIM

Cyril Bur <[email protected]>
checkpatch: silence perl 5.26.0 unescaped left brace warnings

Sahitya Tummala <[email protected]>

    fs/dcache.c: fix spin lockup issue on nlru->lock

Marcin Nowakowski <[email protected]>
kernel/extable.c: mark core_kernel_text notrace

Ben Hutchings <[email protected]>
tools/lib/lockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain/: Depth

Helge Deller <[email protected]>
parisc/mm: Ensure IRQs are off in switch_mm()

Thomas Bogendoerfer <[email protected]>
parisc: DMA API: return error instead of BUG_ON for dma ops on non dma devs

Eric Biggers <[email protected]>
parisc: use compat_sys_keyctl()

Helge Deller <[email protected]>
parisc: Report SIGSEGV instead of SIGBUS when running out of stack

Suzuki K Poulose <[email protected]>
irqchip/gic-v3: Fix out-of-bound access in gic_set_affinity

Srinivas Dasari <[email protected]>
cfg80211: Check if PMKID attribute is of expected size

Srinivas Dasari <[email protected]>
cfg80211: Validate frequencies nested in NL80211_ATTR_SCAN_FREQUENCIES

Srinivas Dasari <[email protected]>

    cfg80211: Define nla_policy for NL80211_ATTR_LOCAL_MESH_POWER_MODE

Arend van Spriel <[email protected]>
brcmfmac: fix possible buffer overflow in brcmf_cfg80211_mgmt_tx()

Sabrina Dubroca <[email protected]>
ipv6: dad: don't remove dynamic addresses if link is down

Eric Dumazet <[email protected]>
net: prevent sign extension in dev_get_stats()

WANG Cong <[email protected]>
tcp: reset sk_rx_dst in tcp_disconnect()

WANG Cong <[email protected]>
ipv6: avoid unregistering inet6_dev for loopback

-------------

Diffstat:

 Makefile                                           |  4 ++--
 arch/parisc/include/asm/dma-mapping.h              | 11 ++++++----
 arch/parisc/include/asm/mmu_context.h              | 15 +++++++++++--
 arch/parisc/kernel/syscall_table.S                 |  2 +-
 arch/parisc/mm/fault.c                             |  2 +-
 arch/x86/crypto/sha1_ssse3_glue.c                  |  2 +-
 drivers/base/power/sysfs.c                         |  2 ++
 drivers/crypto/atmel-sha.c                         |  4 +++-
 drivers/crypto/caam/caamhash.c                     |  2 +-
 drivers/crypto/caam/key_gen.c                      |  2 +-
 drivers/crypto/talitos.c                           |  7 +++++-
 drivers/irqchip/irq-gic-v3.c                       |  3 +++
 .../net/wireless/brcm80211/brcmfmac/wl_cfg80211.c  |  5 +++++
 drivers/parisc/ccio-dma.c                          | 12 +++++++++++
 drivers/parisc/dino.c                              |  5 ++++-
 drivers/parisc/lba_pci.c                           |  6 ++++--
 drivers/parisc/sba_iommu.c                         | 14 ++++++++++++
 drivers/tty/vt/vt.c                                |  6 +++---
 fs/dcache.c                                        |  5 +++--
 fs/exec.c                                          | 11 +++++-----
 kernel/extable.c                                   |  2 +-
 kernel/sched/core.c                                | 22 ++++++++++++++++---
 kernel/trace/trace.c                               |  2 +-
 mm/mmap.c                                          |  2 +-
 net/core/dev.c                                     |  4 ++--
 net/ipv4/tcp.c                                     |  2 ++
 net/ipv6/addrconf.c                                | 25 +++++++++++-----------
 net/wireless/nl80211.c                             |  8 +++++--
 scripts/checkpatch.pl                              |  6 +++---
 tools/lib/lockdep/uinclude/linux/lockdep.h         |  2 +-
 30 files changed, 141 insertions(+), 54 deletions(-)
author maintainer
#1 lore raw

PATCH 1/28 ipv6: avoid unregistering inet6_dev for loopback

3.18-stable review patch. If anyone has any objections, please let me know.

------------------

From: WANG Cong <[email protected]>

commit 60abc0be96e00ca71bac083215ac91ad2e575096 upstream.

The per netns loopback_dev->ip6_ptr is unregistered and set to NULL when its mtu is set to smaller than IPV6_MIN_MTU, this leads to that we could set rt->rt6i_idev NULL after a rt6_uncached_list_flush_dev() and then crash after another call.

In this case we should just bring its inet6_dev down, rather than unregistering it, at least prior to commit 176c39af29bc ("netns: fix addrconf_ifdown kernel panic") we always override the case for loopback.

Thanks a lot to Andrey for finding a reliable reproducer.

Fixes 176c39af29bc ("netns: fix addrconf_ifdown kernel panic")
Cc Andrey Konovalov <[email protected]>
Cc Daniel Lezcano <[email protected]>
Cc David Ahern <[email protected]>
---
 net/ipv6/addrconf.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
net/ipv6/addrconf.c +2 -1
@@ -2829,6 +2829,7 @@ static int addrconf_notify(struct notifi
 {
 	struct net_device *dev = netdev_notifier_info_to_dev(ptr);
 	struct inet6_dev *idev = __in6_dev_get(dev);
+	struct net *net = dev_net(dev);
 	int run_pending = 0;
 	int err;
 
@@ -2925,7 +2926,7 @@ static int addrconf_notify(struct notifi
 			 * IPV6_MIN_MTU stop IPv6 on this interface.
 			 */
 			if (dev->mtu < IPV6_MIN_MTU)
-				addrconf_ifdown(dev, 1);
+				addrconf_ifdown(dev, dev != net->loopback_dev);
 		}
 		break;
 
author maintainer
#2 lore raw

PATCH 2/28 tcp: reset sk_rx_dst in tcp_disconnect()

In reply to Greg Kroah-Hartman

3.18-stable review patch. If anyone has any objections, please let me know.

------------------

From: WANG Cong <[email protected]>

commit d747a7a51b00984127a88113cdbbc26f91e9d815 upstream.

We have to reset the sk->sk_rx_dst when we disconnect a TCP connection, because otherwise when we re-connect it this dst reference is simply overridden in tcp_finish_connect().

This fixes a dst leak which leads to a loopback dev refcnt leak. It is a long-standing bug, Kevin reported a very similar (if not same) bug before. Thanks to Andrei for providing such a reliable reproducer which greatly narrows down the problem.

Fixes 41063e9dd119 ("ipv4: Early TCP socket demux.")
---
 net/ipv4/tcp.c |    2 ++
 1 file changed, 2 insertions(+)
net/ipv4/tcp.c +2 -0
@@ -2268,6 +2268,8 @@ int tcp_disconnect(struct sock *sk, int
 	tcp_init_send_head(sk);
 	memset(&tp->rx_opt, 0, sizeof(tp->rx_opt));
 	__sk_dst_reset(sk);
+	dst_release(sk->sk_rx_dst);
+	sk->sk_rx_dst = NULL;
 
 	WARN_ON(inet->inet_num && !icsk->icsk_bind_hash);
 
author maintainer
#3 lore raw

PATCH 3/28 net: prevent sign extension in dev_get_stats()

In reply to Greg Kroah-Hartman

3.18-stable review patch. If anyone has any objections, please let me know.

------------------

From: Eric Dumazet <[email protected]>

commit 6f64ec74515925cced6df4571638b5a099a49aae upstream.

Similar to the fix provided by Dominik Heidler in commit 9b3dc0a17d73 ("l2tp: cast l2tp traffic counter to unsigned") we need to take care of 32bit kernels in dev_get_stats().

When using atomic_long_read(), we add a 'long' to u64 and might misinterpret high order bit, unless we cast to unsigned.

Fixes caf586e5f23ce ("net: add a core netdev->rx_dropped counter")
Fixes 015f0688f57ca ("net: net: add a core netdev->tx_dropped counter")
Fixes 6e7333d315a76 ("net: add rx_nohandler stat counter")
Cc Jarod Wilson <[email protected]>
---
 net/core/dev.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
net/core/dev.c +2 -2
@@ -6561,8 +6561,8 @@ struct rtnl_link_stats64 *dev_get_stats(
 	} else {
 		netdev_stats_to_stats64(storage, &dev->stats);
 	}
-	storage->rx_dropped += atomic_long_read(&dev->rx_dropped);
-	storage->tx_dropped += atomic_long_read(&dev->tx_dropped);
+	storage->rx_dropped += (unsigned long)atomic_long_read(&dev->rx_dropped);
+	storage->tx_dropped += (unsigned long)atomic_long_read(&dev->tx_dropped);
 	return storage;
 }
 EXPORT_SYMBOL(dev_get_stats);
author maintainer
#4 lore raw

PATCH 4/28 ipv6: dad: dont remove dynamic addresses if link is down

In reply to Greg Kroah-Hartman

3.18-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sabrina Dubroca <[email protected]>

commit ec8add2a4c9df723c94a863b8fcd6d93c472deed upstream.

Currently, when the link for $DEV is down, this command succeeds but the address is removed immediately by DAD (1):

    ip addr add 1111::12/64 dev $DEV valid_lft 3600 preferred_lft 1800

In the same situation, this will succeed and not remove the address (2):

    ip addr add 1111::12/64 dev $DEV
    ip addr change 1111::12/64 dev $DEV valid_lft 3600 preferred_lft 1800

The comment in addrconf_dad_begin() when !IF_READY makes it look like this is the intended behavior, but doesn't explain why:

* If the device is not ready:
* - keep it tentative if it is a permanent address.
* - otherwise, kill it.

We clearly cannot prevent userspace from doing (2), but we can make (1) work consistently with (2).

addrconf_dad_stop() is only called in two cases: if DAD failed, or to skip DAD when the link is down. In that second case, the fix is to avoid deleting the address, like we already do for permanent addresses.

Fixes 3c21edbd1137 ("[IPV6]: Defer IPv6 device initialization until the link becomes ready.")
---
 net/ipv6/addrconf.c |   22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)
net/ipv6/addrconf.c +11 -11
@@ -1613,17 +1613,7 @@ struct inet6_ifaddr *ipv6_get_ifaddr(str
 
 static void addrconf_dad_stop(struct inet6_ifaddr *ifp, int dad_failed)
 {
-	if (ifp->flags&IFA_F_PERMANENT) {
-		spin_lock_bh(&ifp->lock);
-		addrconf_del_dad_work(ifp);
-		ifp->flags |= IFA_F_TENTATIVE;
-		if (dad_failed)
-			ifp->flags |= IFA_F_DADFAILED;
-		spin_unlock_bh(&ifp->lock);
-		if (dad_failed)
-			ipv6_ifa_notify(0, ifp);
-		in6_ifa_put(ifp);
-	} else if (ifp->flags&IFA_F_TEMPORARY) {
+	if (ifp->flags&IFA_F_TEMPORARY) {
 		struct inet6_ifaddr *ifpub;
 		spin_lock_bh(&ifp->lock);
 		ifpub = ifp->ifpub;
@@ -1636,6 +1626,16 @@ static void addrconf_dad_stop(struct ine
 			spin_unlock_bh(&ifp->lock);
 		}
 		ipv6_del_addr(ifp);
+	} else if (ifp->flags&IFA_F_PERMANENT || !dad_failed) {
+		spin_lock_bh(&ifp->lock);
+		addrconf_del_dad_work(ifp);
+		ifp->flags |= IFA_F_TENTATIVE;
+		if (dad_failed)
+			ifp->flags |= IFA_F_DADFAILED;
+		spin_unlock_bh(&ifp->lock);
+		if (dad_failed)
+			ipv6_ifa_notify(0, ifp);
+		in6_ifa_put(ifp);
 	} else {
 		ipv6_del_addr(ifp);
 	}
author maintainer
#5 lore raw

PATCH 6/28 cfg80211: Define nla_policy for NL80211_ATTR_LOCAL_MESH_POWER_MODE

In reply to Greg Kroah-Hartman

3.18-stable review patch. If anyone has any objections, please let me know.

------------------

From: Srinivas Dasari <[email protected]>

commit 8feb69c7bd89513be80eb19198d48f154b254021 upstream.

Buffer overread may happen as nl80211_set_station() reads 4 bytes from the attribute NL80211_ATTR_LOCAL_MESH_POWER_MODE without validating the size of data received when userspace sends less than 4 bytes of data with NL80211_ATTR_LOCAL_MESH_POWER_MODE. Define nla_policy for NL80211_ATTR_LOCAL_MESH_POWER_MODE to avoid the buffer overread.

Fixes 3b1c5a5307f ("{cfg,nl}80211: mesh power mode primitives and userspace access")
---
 net/wireless/nl80211.c |    1 +
 1 file changed, 1 insertion(+)
net/wireless/nl80211.c +1 -0
@@ -358,6 +358,7 @@ static const struct nla_policy nl80211_p
 	[NL80211_ATTR_SCAN_FLAGS] = { .type = NLA_U32 },
 	[NL80211_ATTR_P2P_CTWINDOW] = { .type = NLA_U8 },
 	[NL80211_ATTR_P2P_OPPPS] = { .type = NLA_U8 },
+	[NL80211_ATTR_LOCAL_MESH_POWER_MODE] = {. type = NLA_U32 },
 	[NL80211_ATTR_ACL_POLICY] = {. type = NLA_U32 },
 	[NL80211_ATTR_MAC_ADDRS] = { .type = NLA_NESTED },
 	[NL80211_ATTR_STA_CAPABILITY] = { .type = NLA_U16 },
author maintainer
#6 lore raw

PATCH 7/28 cfg80211: Validate frequencies nested in NL80211_ATTR_SCAN_FREQUENCIES

In reply to Greg Kroah-Hartman

3.18-stable review patch. If anyone has any objections, please let me know.

------------------

From: Srinivas Dasari <[email protected]>

commit d7f13f7450369281a5d0ea463cc69890a15923ae upstream.

validate_scan_freqs() retrieves frequencies from attributes nested in the attribute NL80211_ATTR_SCAN_FREQUENCIES with nla_get_u32(), which reads 4 bytes from each attribute without validating the size of data received. Attributes nested in NL80211_ATTR_SCAN_FREQUENCIES don't have an nla policy.

Validate size of each attribute before parsing to avoid potential buffer overread.

Fixes 2a519311926 ("cfg80211/nl80211: scanning (and mac80211 update to use it)")
---
 net/wireless/nl80211.c |    4 ++++
 1 file changed, 4 insertions(+)
net/wireless/nl80211.c +4 -0
@@ -5348,6 +5348,10 @@ static int validate_scan_freqs(struct nl
 	struct nlattr *attr1, *attr2;
 	int n_channels = 0, tmp1, tmp2;
 
+	nla_for_each_nested(attr1, freqs, tmp1)
+		if (nla_len(attr1) != sizeof(u32))
+			return 0;
+
 	nla_for_each_nested(attr1, freqs, tmp1) {
 		n_channels++;
 		/*
author maintainer
#7 lore raw

PATCH 8/28 cfg80211: Check if PMKID attribute is of expected size

In reply to Greg Kroah-Hartman

3.18-stable review patch. If anyone has any objections, please let me know.

------------------

From: Srinivas Dasari <[email protected]>

commit 9361df14d1cbf966409d5d6f48bb334384fbe138 upstream.

nla policy checks for only maximum length of the attribute data when the attribute type is NLA_BINARY. If userspace sends less data than specified, the wireless drivers may access illegal memory. When type is NLA_UNSPEC, nla policy check ensures that userspace sends minimum specified length number of bytes.

Remove type assignment to NLA_BINARY from nla_policy of NL80211_ATTR_PMKID to make this NLA_UNSPEC and to make sure minimum WLAN_PMKID_LEN bytes are received from userspace with NL80211_ATTR_PMKID.

Fixes 67fbb16be69d ("nl80211: PMKSA caching support")
---
 net/wireless/nl80211.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
net/wireless/nl80211.c +1 -2
@@ -301,8 +301,7 @@ static const struct nla_policy nl80211_p
 	[NL80211_ATTR_WPA_VERSIONS] = { .type = NLA_U32 },
 	[NL80211_ATTR_PID] = { .type = NLA_U32 },
 	[NL80211_ATTR_4ADDR] = { .type = NLA_U8 },
-	[NL80211_ATTR_PMKID] = { .type = NLA_BINARY,
-				 .len = WLAN_PMKID_LEN },
+	[NL80211_ATTR_PMKID] = { .len = WLAN_PMKID_LEN },
 	[NL80211_ATTR_DURATION] = { .type = NLA_U32 },
 	[NL80211_ATTR_COOKIE] = { .type = NLA_U64 },
 	[NL80211_ATTR_TX_RATES] = { .type = NLA_NESTED },
author maintainer
#8 lore raw

PATCH 9/28 irqchip/gic-v3: Fix out-of-bound access in gic_set_affinity

In reply to Greg Kroah-Hartman

3.18-stable review patch. If anyone has any objections, please let me know.

------------------

From: Suzuki K Poulose <[email protected]>

commit 866d7c1b0a3c70387646c4e455e727a58c5d465a upstream.

The GICv3 driver doesn't check if the target CPU for gic_set_affinity is valid before going ahead and making the changes. This triggers the following splat with KASAN:

[  141.189434] BUG: KASAN: global-out-of-bounds in gic_set_affinity+0x8c/0x140
[  141.189704] Read of size 8 at addr ffff200009741d20 by task swapper/1/0
[  141.189958]
[  141.190158] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.12.0-rc7
[  141.190458] Hardware name: Foundation-v8A (DT)
[  141.190658] Call trace:
[  141.190908] [<ffff200008089d70>] dump_backtrace+0x0/0x328
[  141.191224] [<ffff20000808a1b4>] show_stack+0x14/0x20
[  141.191507] [<ffff200008504c3c>] dump_stack+0xa4/0xc8
[  141.191858] [<ffff20000826c19c>] print_address_description+0x13c/0x250
[  141.192219] [<ffff20000826c5c8>] kasan_report+0x210/0x300
[  141.192547] [<ffff20000826ad54>] __asan_load8+0x84/0x98
[  141.192874] [<ffff20000854eeec>] gic_set_affinity+0x8c/0x140
[  141.193158] [<ffff200008148b14>] irq_do_set_affinity+0x54/0xb8
[  141.193473] [<ffff200008148d2c>] irq_set_affinity_locked+0x64/0xf0
[  141.193828] [<ffff200008148e00>] __irq_set_affinity+0x48/0x78
[  141.194158] [<ffff200008bc48a4>] arm_perf_starting_cpu+0x104/0x150
[  141.194513] [<ffff2000080d73bc>] cpuhp_invoke_callback+0x17c/0x1f8
[  141.194783] [<ffff2000080d94ec>] notify_cpu_starting+0x8c/0xb8
[  141.195130] [<ffff2000080911ec>] secondary_start_kernel+0x15c/0x200
[  141.195390] [<0000000080db81b4>] 0x80db81b4
[  141.195603]
[  141.195685] The buggy address belongs to the variable:
[  141.196012]  __cpu_logical_map+0x200/0x220
[  141.196176]
[  141.196315] Memory state around the buggy address:
[  141.196586]  ffff200009741c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  141.196913]  ffff200009741c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  141.197158] >ffff200009741d00: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 00 00
[  141.197487]                                ^
[  141.197758]  ffff200009741d80: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00
[  141.198060]  ffff200009741e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  141.198358] ==================================================================
[  141.198609] Disabling lock debugging due to kernel taint
[  141.198961] CPU1: Booted secondary processor [410fd051]

This patch adds the check to make sure the cpu is valid.

Fixes commit 021f653791ad17e03f98 ("irqchip: gic-v3: Initial support for GICv3")
---
 drivers/irqchip/irq-gic-v3.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/irqchip/irq-gic-v3.c +3 -0
@@ -531,6 +531,9 @@ static int gic_set_affinity(struct irq_d
 	int enabled;
 	u64 val;
 
+	if (cpu >= nr_cpu_ids)
+		return -EINVAL;
+
 	if (gic_irq_in_rdist(d))
 		return -EINVAL;
 
author maintainer
#9 lore raw

PATCH 10/28 parisc: Report SIGSEGV instead of SIGBUS when running out of stack

In reply to Greg Kroah-Hartman

3.18-stable review patch. If anyone has any objections, please let me know.

------------------

From: Helge Deller <[email protected]>

commit 247462316f85a9e0479445c1a4223950b68ffac1 upstream.

When a process runs out of stack the parisc kernel wrongly faults with SIGBUS instead of the expected SIGSEGV signal.

This example shows how the kernel faults:
do_page_fault() command='a.out' type=15 address=0xfaac2000 in libc-2.24.so[f8308000+16c000] trap #15: Data TLB miss fault, vm_start = 0xfa2c2000, vm_end = 0xfaac2000

The vma->vm_end value is the first address which does not belong to the vma, so adjust the check to include vma->vm_end to the range for which to send the SIGSEGV signal.

This patch unbreaks building the debian libsigsegv package.

---
 arch/parisc/mm/fault.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/parisc/mm/fault.c +1 -1
@@ -303,7 +303,7 @@ bad_area:
 		case 15:	/* Data TLB miss fault/Data page fault */
 			/* send SIGSEGV when outside of vma */
 			if (!vma ||
-			    address < vma->vm_start || address > vma->vm_end) {
+			    address < vma->vm_start || address >= vma->vm_end) {
 				si.si_signo = SIGSEGV;
 				si.si_code = SEGV_MAPERR;
 				break;
author maintainer
#10 lore raw

PATCH 11/28 parisc: use compat_sys_keyctl()

In reply to Greg Kroah-Hartman

3.18-stable review patch. If anyone has any objections, please let me know.

------------------

From: Eric Biggers <[email protected]>

commit b0f94efd5aa8daa8a07d7601714c2573266cd4c9 upstream.

Architectures with a compat syscall table must put compat_sys_keyctl() in it, not sys_keyctl(). The parisc architecture was not doing this; fix it.

---
 arch/parisc/kernel/syscall_table.S |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/parisc/kernel/syscall_table.S +1 -1
@@ -361,7 +361,7 @@
 	ENTRY_SAME(ni_syscall)	/* 263: reserved for vserver */
 	ENTRY_SAME(add_key)
 	ENTRY_SAME(request_key)		/* 265 */
-	ENTRY_SAME(keyctl)
+	ENTRY_COMP(keyctl)
 	ENTRY_SAME(ioprio_set)
 	ENTRY_SAME(ioprio_get)
 	ENTRY_SAME(inotify_init)
author maintainer
#11 lore raw

PATCH 12/28 parisc: DMA API: return error instead of BUG_ON for dma ops on non dma devs

In reply to Greg Kroah-Hartman

3.18-stable review patch. If anyone has any objections, please let me know.

------------------

From: Thomas Bogendoerfer <[email protected]>

commit 33f9e02495d15a061f0c94ef46f5103a2d0c20f3 upstream.

Enabling parport pc driver on a B2600 (and probably other 64bit PARISC systems) produced following BUG:

CPU: 0 PID: 1 Comm: swapper Not tainted 4.12.0-rc5-30198-g1132d5e #156

task: 000000009e050000 task.stack: 000000009e04c000

YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00001000000001101111111100001111 Not tainted

r00-03  000000ff0806ff0f 000000009e04c990 0000000040871b78 000000009e04cac0
r04-07  0000000040c14de0 ffffffffffffffff 000000009e07f098 000000009d82d200
r08-11  000000009d82d210 0000000000000378 0000000000000000 0000000040c345e0
r12-15  0000000000000005 0000000040c345e0 0000000000000000 0000000040c9d5e0
r16-19  0000000040c345e0 00000000f00001c4 00000000f00001bc 0000000000000061
r20-23  000000009e04ce28 0000000000000010 0000000000000010 0000000040b89e40
r24-27  0000000000000003 0000000000ffffff 000000009d82d210 0000000040c14de0
r28-31  0000000000000000 000000009e04ca90 000000009e04cb40 0000000000000000

sr00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 sr04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000

IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000404aece0 00000000404aece4
IIR: 03ffe01f ISR: 0000000010340000 IOR: 000001781304cac8
CPU: 0 CR30: 000000009e04c000 CR31: 00000000e2976de2
ORIG_R28: 0000000000000200
IAOQ[0]: sba_dma_supported+0x80/0xd0
IAOQ[1]: sba_dma_supported+0x84/0xd0
RP(r2): parport_pc_probe_port+0x178/0x1200

Cause is a call to dma_coerce_mask_and_coherenet in parport_pc_probe_port, which PARISC DMA API doesn't handle very nicely. This commit gives back DMA_ERROR_CODE for DMA API calls, if device isn't capable of DMA transaction.

---
 arch/parisc/include/asm/dma-mapping.h |   11 +++++++----
 drivers/parisc/ccio-dma.c             |   12 ++++++++++++
 drivers/parisc/dino.c                 |    5 ++++-
 drivers/parisc/lba_pci.c              |    6 ++++--
 drivers/parisc/sba_iommu.c            |   14 ++++++++++++++
 5 files changed, 41 insertions(+), 7 deletions(-)
arch/parisc/include/asm/dma-mapping.h +7 -4
@@ -39,6 +39,8 @@ struct hppa_dma_ops {
 ** flush/purge and allocate "regular" cacheable pages for everything.
 */
 
+#define DMA_ERROR_CODE	(~(dma_addr_t)0)
+
 #ifdef CONFIG_PA11
 extern struct hppa_dma_ops pcxl_dma_ops;
 extern struct hppa_dma_ops pcx_dma_ops;
@@ -209,12 +211,13 @@ parisc_walk_tree(struct device *dev)
 			break;
 		}
 	}
-	BUG_ON(!dev->platform_data);
 	return dev->platform_data;
 }
-		
-#define GET_IOC(dev) (HBA_DATA(parisc_walk_tree(dev))->iommu)
-	
+
+#define GET_IOC(dev) ({					\
+	void *__pdata = parisc_walk_tree(dev);		\
+	__pdata ? HBA_DATA(__pdata)->iommu : NULL;	\
+})
 
 #ifdef CONFIG_IOMMU_CCIO
 struct parisc_device;
drivers/parisc/ccio-dma.c +12 -0
@@ -743,6 +743,8 @@ ccio_map_single(struct device *dev, void
 
 	BUG_ON(!dev);
 	ioc = GET_IOC(dev);
+	if (!ioc)
+		return DMA_ERROR_CODE;
 
 	BUG_ON(size <= 0);
 
@@ -807,6 +809,10 @@ ccio_unmap_single(struct device *dev, dm
 	
 	BUG_ON(!dev);
 	ioc = GET_IOC(dev);
+	if (!ioc) {
+		WARN_ON(!ioc);
+		return;
+	}
 
 	DBG_RUN("%s() iovp 0x%lx/%x\n",
 		__func__, (long)iova, size);
@@ -910,6 +916,8 @@ ccio_map_sg(struct device *dev, struct s
 	
 	BUG_ON(!dev);
 	ioc = GET_IOC(dev);
+	if (!ioc)
+		return 0;
 	
 	DBG_RUN_SG("%s() START %d entries\n", __func__, nents);
 
@@ -982,6 +990,10 @@ ccio_unmap_sg(struct device *dev, struct
 
 	BUG_ON(!dev);
 	ioc = GET_IOC(dev);
+	if (!ioc) {
+		WARN_ON(!ioc);
+		return;
+	}
 
 	DBG_RUN_SG("%s() START %d entries,  %08lx,%x\n",
 		__func__, nents, sg_virt_addr(sglist), sglist->length);
drivers/parisc/dino.c +4 -1
@@ -154,7 +154,10 @@ struct dino_device
 };
 
 /* Looks nice and keeps the compiler happy */
-#define DINO_DEV(d) ((struct dino_device *) d)
+#define DINO_DEV(d) ({				\
+	void *__pdata = d;			\
+	BUG_ON(!__pdata);			\
+	(struct dino_device *)__pdata; })
 
 
 /*
drivers/parisc/lba_pci.c +4 -2
@@ -111,8 +111,10 @@ static u32 lba_t32;
 
 
 /* Looks nice and keeps the compiler happy */
-#define LBA_DEV(d) ((struct lba_device *) (d))
-
+#define LBA_DEV(d) ({				\
+	void *__pdata = d;			\
+	BUG_ON(!__pdata);			\
+	(struct lba_device *)__pdata; })
 
 /*
 ** Only allow 8 subsidiary busses per LBA
drivers/parisc/sba_iommu.c +14 -0
@@ -691,6 +691,8 @@ static int sba_dma_supported( struct dev
 		return 0;
 
 	ioc = GET_IOC(dev);
+	if (!ioc)
+		return 0;
 
 	/*
 	 * check if mask is >= than the current max IO Virt Address
@@ -722,6 +724,8 @@ sba_map_single(struct device *dev, void
 	int pide;
 
 	ioc = GET_IOC(dev);
+	if (!ioc)
+		return DMA_ERROR_CODE;
 
 	/* save offset bits */
 	offset = ((dma_addr_t) (long) addr) & ~IOVP_MASK;
@@ -803,6 +807,10 @@ sba_unmap_single(struct device *dev, dma
 	DBG_RUN("%s() iovp 0x%lx/%x\n", __func__, (long) iova, size);
 
 	ioc = GET_IOC(dev);
+	if (!ioc) {
+		WARN_ON(!ioc);
+		return;
+	}
 	offset = iova & ~IOVP_MASK;
 	iova ^= offset;        /* clear offset bits */
 	size += offset;
@@ -942,6 +950,8 @@ sba_map_sg(struct device *dev, struct sc
 	DBG_RUN_SG("%s() START %d entries\n", __func__, nents);
 
 	ioc = GET_IOC(dev);
+	if (!ioc)
+		return 0;
 
 	/* Fast path single entry scatterlists. */
 	if (nents == 1) {
@@ -1028,6 +1038,10 @@ sba_unmap_sg(struct device *dev, struct
 		__func__, nents, sg_virt_addr(sglist), sglist->length);
 
 	ioc = GET_IOC(dev);
+	if (!ioc) {
+		WARN_ON(!ioc);
+		return;
+	}
 
 #ifdef SBA_COLLECT_STATS
 	ioc->usg_calls++;
author maintainer
#12 lore raw

PATCH 13/28 parisc/mm: Ensure IRQs are off in switch_mm()

In reply to Greg Kroah-Hartman

3.18-stable review patch. If anyone has any objections, please let me know.

------------------

From: Helge Deller <[email protected]>

commit 649aa24254e85bf6bd7807dd372d083707852b1f upstream.

This is because of commit f98db6013c55 ("sched/core: Add switch_mm_irqs_off() and use it in the scheduler") in which switch_mm_irqs_off() is called by the scheduler, vs switch_mm() which is used by use_mm().

This patch lets the parisc code mirror the x86 and powerpc code, ie. it disables interrupts in switch_mm(), and optimises the scheduler case by defining switch_mm_irqs_off().

---
 arch/parisc/include/asm/mmu_context.h |   15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)
arch/parisc/include/asm/mmu_context.h +13 -2
@@ -49,15 +49,26 @@ static inline void load_context(mm_conte
 	mtctl(__space_to_prot(context), 8);
 }
 
-static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next, struct task_struct *tsk)
+static inline void switch_mm_irqs_off(struct mm_struct *prev,
+		struct mm_struct *next, struct task_struct *tsk)
 {
-
 	if (prev != next) {
 		mtctl(__pa(next->pgd), 25);
 		load_context(next->context);
 	}
 }
 
+static inline void switch_mm(struct mm_struct *prev,
+		struct mm_struct *next, struct task_struct *tsk)
+{
+	unsigned long flags;
+
+	local_irq_save(flags);
+	switch_mm_irqs_off(prev, next, tsk);
+	local_irq_restore(flags);
+}
+#define switch_mm_irqs_off switch_mm_irqs_off
+
 #define deactivate_mm(tsk,mm)	do { } while (0)
 
 static inline void activate_mm(struct mm_struct *prev, struct mm_struct *next)
author maintainer
#13 lore raw

PATCH 14/28 tools/lib/lockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain/: Depth

In reply to Greg Kroah-Hartman

3.18-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ben Hutchings <[email protected]>

commit 98dcea0cfd04e083ac74137ceb9a632604740e2d upstream.

liblockdep has been broken since commit 75dd602a5198 ("lockdep: Fix lock_chain::base size"), as that adds a check that MAX_LOCK_DEPTH is within the range of lock_chain::depth and in liblockdep it is much too large.

That should have resulted in a compiler error, but didn't because:

- the check uses ARRAY_SIZE(), which isn't yet defined in liblockdep so is assumed to be an (undeclared) function
- putting a function call inside a BUILD_BUG_ON() expression quietly turns it into some nonsense involving a variable-length array

It did produce a compiler warning, but I didn't notice because liblockdep already produces too many warnings if -Wall is enabled (which I'll fix shortly).

Even before that commit, which reduced lock_chain::depth from 8 bits to 6, MAX_LOCK_DEPTH was too large.

---
 tools/lib/lockdep/uinclude/linux/lockdep.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
tools/lib/lockdep/uinclude/linux/lockdep.h +1 -1
@@ -8,7 +8,7 @@
 #include <linux/utsname.h>
 
 
-#define MAX_LOCK_DEPTH 2000UL
+#define MAX_LOCK_DEPTH 255UL
 
 #define asmlinkage
 #define __visible
author maintainer
#14 lore raw

PATCH 15/28 kernel/extable.c: mark core_kernel_text notrace

In reply to Greg Kroah-Hartman

3.18-stable review patch. If anyone has any objections, please let me know.

------------------

From: Marcin Nowakowski <[email protected]>

commit c0d80ddab89916273cb97114889d3f337bc370ae upstream.

core_kernel_text is used by MIPS in its function graph trace processing, so having this method traced leads to an infinite set of recursive calls such as:

  Call Trace:
     ftrace_return_to_handler+0x50/0x128
     core_kernel_text+0x10/0x1b8
     prepare_ftrace_return+0x6c/0x114
     ftrace_graph_caller+0x20/0x44
     return_to_handler+0x10/0x30
     return_to_handler+0x0/0x30
     return_to_handler+0x0/0x30
     ftrace_ops_no_ops+0x114/0x1bc
     core_kernel_text+0x10/0x1b8
     core_kernel_text+0x10/0x1b8
     core_kernel_text+0x10/0x1b8
     ftrace_ops_no_ops+0x114/0x1bc
     core_kernel_text+0x10/0x1b8
     prepare_ftrace_return+0x6c/0x114
     ftrace_graph_caller+0x20/0x44
     (...)

Mark the function notrace to avoid it being traced.

---
 kernel/extable.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/extable.c +1 -1
@@ -66,7 +66,7 @@ static inline int init_kernel_text(unsig
 	return 0;
 }
 
-int core_kernel_text(unsigned long addr)
+int notrace core_kernel_text(unsigned long addr)
 {
 	if (addr >= (unsigned long)_stext &&
 	    addr < (unsigned long)_etext)
author maintainer
#15 lore raw

PATCH 16/28 fs/dcache.c: fix spin lockup issue on nlru->lock

In reply to Greg Kroah-Hartman

3.18-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sahitya Tummala <[email protected]>

commit b17c070fb624cf10162cf92ea5e1ec25cd8ac176 upstream.

__list_lru_walk_one() acquires nlru spin lock (nlru->lock) for longer duration if there are more number of items in the lru list. As per the current code, it can hold the spin lock for upto maximum UINT_MAX entries at a time. So if there are more number of items in the lru list, then "BUG: spinlock lockup suspected" is observed in the below path:

spin_bug+0x90
do_raw_spin_lock+0xfc
_raw_spin_lock+0x28
list_lru_add+0x28
dput+0x1c8
path_put+0x20
terminate_walk+0x3c
path_lookupat+0x100
filename_lookup+0x6c
user_path_at_empty+0x54
SyS_faccessat+0xd0
el0_svc_naked+0x24

This nlru->lock is acquired by another CPU in this path -

d_lru_shrink_move+0x34
dentry_lru_isolate_shrink+0x48
__list_lru_walk_one.isra.10+0x94
list_lru_walk_node+0x40
shrink_dcache_sb+0x60
do_remount_sb+0xbc
do_emergency_remount+0xb0
process_one_work+0x228
worker_thread+0x2e0
kthread+0xf4
ret_from_fork+0x10

Fix this lockup by reducing the number of entries to be shrinked from the lru list to 1024 at once. Also, add cond_resched() before processing the lru list again.

---
 fs/dcache.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
fs/dcache.c +3 -2
@@ -1104,11 +1104,12 @@ void shrink_dcache_sb(struct super_block
 		LIST_HEAD(dispose);
 
 		freed = list_lru_walk(&sb->s_dentry_lru,
-			dentry_lru_isolate_shrink, &dispose, UINT_MAX);
+			dentry_lru_isolate_shrink, &dispose, 1024);
 
 		this_cpu_sub(nr_dentry_unused, freed);
 		shrink_dentry_list(&dispose);
-	} while (freed > 0);
+		cond_resched();
+	} while (list_lru_count(&sb->s_dentry_lru) > 0);
 }
 EXPORT_SYMBOL(shrink_dcache_sb);
 
author maintainer
#16 lore raw

PATCH 17/28 checkpatch: silence perl 5.26.0 unescaped left brace warnings

In reply to Greg Kroah-Hartman

3.18-stable review patch. If anyone has any objections, please let me know.

------------------

From: Cyril Bur <[email protected]>

commit 8d81ae05d0176da1c54aeaed697fa34be5c5575e upstream.

As of perl 5, version 26, subversion 0 (v5.26.0) some new warnings have occurred when running checkpatch.

Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/^(.\s*){ <-- HERE \s*/ at scripts/checkpatch.pl line 3544.

Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/^(.\s*){ <-- HERE \s*/ at scripts/checkpatch.pl line 3885.

Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/^(\+.*(?:do|\))){ <-- HERE / at scripts/checkpatch.pl line 4374.

It seems perfectly reasonable to do as the warning suggests and simply escape the left brace in these three locations.

---
 scripts/checkpatch.pl |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
scripts/checkpatch.pl +3 -3
@@ -2985,7 +2985,7 @@ sub process {
 				$fixedline =~ s/\s*=\s*$/ = {/;
 				fix_insert_line($fixlinenr, $fixedline);
 				$fixedline = $line;
-				$fixedline =~ s/^(.\s*){\s*/$1/;
+				$fixedline =~ s/^(.\s*)\{\s*/$1/;
 				fix_insert_line($fixlinenr, $fixedline);
 			}
 		}
@@ -3301,7 +3301,7 @@ sub process {
 				my $fixedline = rtrim($prevrawline) . " {";
 				fix_insert_line($fixlinenr, $fixedline);
 				$fixedline = $rawline;
-				$fixedline =~ s/^(.\s*){\s*/$1\t/;
+				$fixedline =~ s/^(.\s*)\{\s*/$1\t/;
 				if ($fixedline !~ /^\+\s*$/) {
 					fix_insert_line($fixlinenr, $fixedline);
 				}
@@ -3748,7 +3748,7 @@ sub process {
 			if (ERROR("SPACING",
 				  "space required before the open brace '{'\n" . $herecurr) &&
 			    $fix) {
-				$fixed[$fixlinenr] =~ s/^(\+.*(?:do|\))){/$1 {/;
+				$fixed[$fixlinenr] =~ s/^(\+.*(?:do|\)))\{/$1 {/;
 			}
 		}
 
author maintainer
#17 lore raw

PATCH 18/28 exec: Limit arg stack to at most 75% of _STK_LIM

In reply to Greg Kroah-Hartman

3.18-stable review patch. If anyone has any objections, please let me know.

------------------

From: Kees Cook <[email protected]>

commit da029c11e6b12f321f36dac8771e833b65cec962 upstream.

To avoid pathological stack usage or the need to special-case setuid execs, just limit all arg stack usage to at most 75% of _STK_LIM (6MB).

---
 fs/exec.c |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)
fs/exec.c +6 -5
@@ -199,8 +199,7 @@ static struct page *get_arg_page(struct
 
 	if (write) {
 		unsigned long size = bprm->vma->vm_end - bprm->vma->vm_start;
-		unsigned long ptr_size;
-		struct rlimit *rlim;
+		unsigned long ptr_size, limit;
 
 		/*
 		 * Since the stack will hold pointers to the strings, we
@@ -229,14 +228,16 @@ static struct page *get_arg_page(struct
 			return page;
 
 		/*
-		 * Limit to 1/4-th the stack size for the argv+env strings.
+		 * Limit to 1/4 of the max stack size or 3/4 of _STK_LIM
+		 * (whichever is smaller) for the argv+env strings.
 		 * This ensures that:
 		 *  - the remaining binfmt code will not run out of stack space,
 		 *  - the program will have a reasonable amount of stack left
 		 *    to work from.
 		 */
-		rlim = current->signal->rlim;
-		if (size > READ_ONCE(rlim[RLIMIT_STACK].rlim_cur) / 4)
+		limit = _STK_LIM / 4 * 3;
+		limit = min(limit, rlimit(RLIMIT_STACK) / 4);
+		if (size > limit)
 			goto fail;
 	}
 
author maintainer
#18 lore raw

PATCH 19/28 vt: fix unchecked __put_user() in tioclinux ioctls

In reply to Greg Kroah-Hartman

3.18-stable review patch. If anyone has any objections, please let me know.

------------------

From: Adam Borowski <[email protected]>

commit 6987dc8a70976561d22450b5858fc9767788cc1c upstream.

Only read access is checked before this call.

Actually, at the moment this is not an issue, as every in-tree arch does the same manual checks for VERIFY_READ vs VERIFY_WRITE, relying on the MMU to tell them apart, but this wasn't the case in the past and may happen again on some odd arch in the future.

If anyone cares about 3.7 and earlier, this is a security hole (untested) on real 80386 CPUs.

---
 drivers/tty/vt/vt.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/tty/vt/vt.c +3 -3
@@ -2687,13 +2687,13 @@ int tioclinux(struct tty_struct *tty, un
 	 * related to the kernel should not use this.
 	 */
 			data = vt_get_shift_state();
-			ret = __put_user(data, p);
+			ret = put_user(data, p);
 			break;
 		case TIOCL_GETMOUSEREPORTING:
 			console_lock();	/* May be overkill */
 			data = mouse_reporting();
 			console_unlock();
-			ret = __put_user(data, p);
+			ret = put_user(data, p);
 			break;
 		case TIOCL_SETVESABLANK:
 			console_lock();
@@ -2702,7 +2702,7 @@ int tioclinux(struct tty_struct *tty, un
 			break;
 		case TIOCL_GETKMSGREDIRECT:
 			data = vt_get_kmsg_redirect();
-			ret = __put_user(data, p);
+			ret = put_user(data, p);
 			break;
 		case TIOCL_SETKMSGREDIRECT:
 			if (!capable(CAP_SYS_ADMIN)) {
author maintainer
#19 lore raw

PATCH 22/28 crypto: atmel - only treat EBUSY as transient if backlog

In reply to Greg Kroah-Hartman

3.18-stable review patch. If anyone has any objections, please let me know.

------------------

From: Gilad Ben-Yossef <[email protected]>

commit 1606043f214f912a52195293614935811a6e3e53 upstream.

The Atmel SHA driver was treating -EBUSY as indication of queueing to backlog without checking that backlog is enabled for the request.

Fix it by checking request flags.

---
 drivers/crypto/atmel-sha.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/crypto/atmel-sha.c +3 -1
@@ -957,7 +957,9 @@ static int atmel_sha_finup(struct ahash_
 	ctx->flags |= SHA_FLAGS_FINUP;
 
 	err1 = atmel_sha_update(req);
-	if (err1 == -EINPROGRESS || err1 == -EBUSY)
+	if (err1 == -EINPROGRESS ||
+	    (err1 == -EBUSY && (ahash_request_flags(req) &
+				CRYPTO_TFM_REQ_MAY_BACKLOG)))
 		return err1;
 
 	/*
author maintainer
#20 lore raw

PATCH 23/28 crypto: sha1-ssse3 - Disable avx2

In reply to Greg Kroah-Hartman

3.18-stable review patch. If anyone has any objections, please let me know.

------------------

From: Herbert Xu <[email protected]>

commit b82ce24426a4071da9529d726057e4e642948667 upstream.

It has been reported that sha1-avx2 can cause page faults by reading beyond the end of the input. This patch disables it until it can be fixed.

Fixes 7c1da8d0d046 ("crypto: sha - SHA1 transform x86_64 AVX2")
---
 arch/x86/crypto/sha1_ssse3_glue.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/crypto/sha1_ssse3_glue.c +1 -1
@@ -224,7 +224,7 @@ static bool __init avx_usable(void)
 #ifdef CONFIG_AS_AVX2
 static bool __init avx2_usable(void)
 {
-	if (avx_usable() && cpu_has_avx2 && boot_cpu_has(X86_FEATURE_BMI1) &&
+	if (false && avx_usable() && cpu_has_avx2 && boot_cpu_has(X86_FEATURE_BMI1) &&
 	    boot_cpu_has(X86_FEATURE_BMI2))
 		return true;
 
author maintainer
#21 lore raw

PATCH 25/28 sched/topology: Optimize build_group_mask()

In reply to Greg Kroah-Hartman

3.18-stable review patch. If anyone has any objections, please let me know.

------------------

From: Lauro Ramos Venancio <[email protected]>

commit f32d782e31bf079f600dcec126ed117b0577e85c upstream.

The group mask is always used in intersection with the group CPUs. So, when building the group mask, we don't have to care about CPUs that are not part of the group.

---
 kernel/sched/core.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/sched/core.c +2 -2
@@ -5863,12 +5863,12 @@ enum s_alloc {
  */
 static void build_group_mask(struct sched_domain *sd, struct sched_group *sg)
 {
-	const struct cpumask *span = sched_domain_span(sd);
+	const struct cpumask *sg_span = sched_group_cpus(sg);
 	struct sd_data *sdd = sd->private;
 	struct sched_domain *sibling;
 	int i;
 
-	for_each_cpu(i, span) {
+	for_each_cpu(i, sg_span) {
 		sibling = *per_cpu_ptr(sdd->sd, i);
 		if (!cpumask_test_cpu(i, sched_domain_span(sibling)))
 			continue;
author maintainer
#22 lore raw

PATCH 26/28 sched/topology: Fix overlapping sched_group_mask

In reply to Greg Kroah-Hartman

3.18-stable review patch. If anyone has any objections, please let me know.

------------------

From: Peter Zijlstra <[email protected]>

commit 73bb059f9b8a00c5e1bf2f7ca83138c05d05e600 upstream.

The point of sched_group_mask is to select those CPUs from sched_group_cpus that can actually arrive at this balance domain.

The current code gets it wrong, as can be readily demonstrated with a topology like:

node 0 1 2 3

    0:  10  20  30  20
    1:  20  10  20  30
    2:  30  20  10  20
    3:  20  30  20  10

Where (for example) domain 1 on CPU1 ends up with a mask that includes CPU0:

[] CPU1 attaching sched-domain:
[] domain 0: span 0-2 level NUMA
[] groups: 1 (mask: 1), 2, 0
[] domain 1: span 0-3 level NUMA
[] groups: 0-2 (mask: 0-2) (cpu_capacity: 3072), 0,2-3 (cpu_capacity: 3072)

This causes sched_balance_cpu() to compute the wrong CPU and consequently should_we_balance() will terminate early resulting in missed load-balance opportunities.

The fixed topology looks like:

[] CPU1 attaching sched-domain:
[] domain 0: span 0-2 level NUMA
[] groups: 1 (mask: 1), 2, 0
[] domain 1: span 0-3 level NUMA
[] groups: 0-2 (mask: 1) (cpu_capacity: 3072), 0,2-3 (cpu_capacity: 3072)

(note: this relies on OVERLAP domains to always have children, this is
true because the regular topology domains are still here -- this is before degenerate trimming)

Cc Linus Torvalds <[email protected]>
Cc Mike Galbraith <[email protected]>
Cc Peter Zijlstra <[email protected]>
Cc Thomas Gleixner <[email protected]>
Fixes e3589f6c81e4 ("sched: Allow for overlapping sched_domain spans")
---
 kernel/sched/core.c |   18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)
kernel/sched/core.c +17 -1
@@ -5852,6 +5852,9 @@ enum s_alloc {
  * Build an iteration mask that can exclude certain CPUs from the upwards
  * domain traversal.
  *
+ * Only CPUs that can arrive at this group should be considered to continue
+ * balancing.
+ *
  * Asymmetric node setups can result in situations where the domain tree is of
  * unequal depth, make sure to skip domains that already cover the entire
  * range.
@@ -5870,11 +5873,24 @@ static void build_group_mask(struct sche
 
 	for_each_cpu(i, sg_span) {
 		sibling = *per_cpu_ptr(sdd->sd, i);
-		if (!cpumask_test_cpu(i, sched_domain_span(sibling)))
+
+		/*
+		 * Can happen in the asymmetric case, where these siblings are
+		 * unused. The mask will not be empty because those CPUs that
+		 * do have the top domain _should_ span the domain.
+		 */
+		if (!sibling->child)
+			continue;
+
+		/* If we would not end up here, we can't continue from here */
+		if (!cpumask_equal(sg_span, sched_domain_span(sibling->child)))
 			continue;
 
 		cpumask_set_cpu(i, sched_group_mask(sg));
 	}
+
+	/* We must not have empty masks here */
+	WARN_ON_ONCE(cpumask_empty(sched_group_mask(sg)));
 }
 
 /*
author maintainer
#23 lore raw

PATCH 27/28 PM / QoS: return -EINVAL for bogus strings

In reply to Greg Kroah-Hartman

3.18-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dan Carpenter <[email protected]>

commit 2ca30331c156ca9e97643ad05dd8930b8fe78b01 upstream.

In the current code, if the user accidentally writes a bogus command to this sysfs file, then we set the latency tolerance to an uninitialized variable.

Fixes 2d984ad132a8 (PM / QoS: Introcuce latency tolerance device PM QoS type)
---
 drivers/base/power/sysfs.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/base/power/sysfs.c +2 -0
@@ -269,6 +269,8 @@ static ssize_t pm_qos_latency_tolerance_
 			value = PM_QOS_LATENCY_TOLERANCE_NO_CONSTRAINT;
 		else if (!strcmp(buf, "any") || !strcmp(buf, "any\n"))
 			value = PM_QOS_LATENCY_ANY;
+		else
+			return -EINVAL;
 	}
 	ret = dev_pm_qos_update_user_latency_tolerance(dev, value);
 	return ret < 0 ? ret : n;
author maintainer
#24 lore raw

PATCH 28/28 tracing: Use SOFTIRQ_OFFSET for softirq dectection for more accurate results

In reply to Greg Kroah-Hartman

3.18-stable review patch. If anyone has any objections, please let me know.

------------------

From: Pavankumar Kondeti <[email protected]>

commit c59f29cb144a6a0dfac16ede9dc8eafc02dc56ca upstream.

The 's' flag is supposed to indicate that a softirq is running. This can be detected by testing the preempt_count with SOFTIRQ_OFFSET.

The current code tests the preempt_count with SOFTIRQ_MASK, which would be true even when softirqs are disabled but not serving a softirq.

---
 kernel/trace/trace.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/trace/trace.c +1 -1
@@ -1587,7 +1587,7 @@ tracing_generic_entry_update(struct trac
 		TRACE_FLAG_IRQS_NOSUPPORT |
 #endif
 		((pc & HARDIRQ_MASK) ? TRACE_FLAG_HARDIRQ : 0) |
-		((pc & SOFTIRQ_MASK) ? TRACE_FLAG_SOFTIRQ : 0) |
+		((pc & SOFTIRQ_OFFSET) ? TRACE_FLAG_SOFTIRQ : 0) |
 		(tif_need_resched() ? TRACE_FLAG_NEED_RESCHED : 0) |
 		(test_preempt_need_resched() ? TRACE_FLAG_PREEMPT_RESCHED : 0);
 }
#25 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.18.62 release. There are 28 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Fri Jul 21 11:13:09 UTC 2017. Anything received after that time might be too late.

Build results:

	total: 136 pass: 136 fail: 0
Qemu test results:
	total: 111 pass: 111 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

#26 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.18.62 release. There are 28 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Fri Jul 21 11:13:09 UTC 2017. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 9 lines
	kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.62-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-3.18.y
and the diffstat can be found below.

thanks,

greg k-h

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

author maintainer
#27 lore raw
Quoted 15 lines · Shuah Khan
Quoted 14 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.18.62 release. There are 28 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Fri Jul 21 11:13:09 UTC 2017. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.62-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-3.18.y
and the diffstat can be found below.

Quoted 6 lines
Quoted 4 lines

thanks,

greg k-h

Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h