3.18.60-stable review
Subsystems (2)
Greg Kroah-Hartman
maintainercover 3.18.60-stable review
This is the start of the stable review cycle for the 3.18.60 release. There are 36 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 Wed Jul 5 13:32:35 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.60-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.60-rc1
Wanpeng Li <[email protected]>
KVM: nVMX: Fix exception injection
Radim Krčmář <[email protected]>
KVM: x86: zero base3 of unusable segments
Dan Carpenter <[email protected]>
cpufreq: s3c2416: double free on driver init error path
Pan Bian <[email protected]>
iommu/amd: Fix incorrect error handling in amd_iommu_bind_pasid()
David Dillow <[email protected]>
iommu/vt-d: Don't over-free page table directories
Doug Berger <[email protected]>
ARM: 8685/1: ensure memblock-limit is pmd-aligned
Eric Anholt <[email protected]>
watchdog: bcm281xx: Fix use of uninitialized spinlock.
Dan Carpenter <[email protected]>
xfrm: Oops on error in pfkey_msg2xfrm_state()
Dan Carpenter <[email protected]>
xfrm: NULL dereference on allocation failure
Sabrina Dubroca <[email protected]>
xfrm: fix stack access out of bounds with CONFIG_XFRM_SUB_POLICY
Rafał Miłecki <[email protected]>
mtd: bcm47xxpart: limit scanned flash area on BCM47XX (MIPS) only
Florian Fainelli <[email protected]>
net: korina: Fix NAPI versus resources freeing
Jon Mason <[email protected]>
ARM: dts: BCM5301X: Correct GIC_PPI interrupt flags
Mark Rutland <[email protected]>
mm: numa: avoid waiting on freed migrated pages
Kees Cook <[email protected]>
sysctl: enable strict writes
Baolin Wang <[email protected]>
usb: gadget: f_fs: Fix possibe deadlock
Deepak Rawat <[email protected]>
drm/vmwgfx: Free hash table allocated by cmdbuf managed res mgr
Hui Wang <[email protected]>
ALSA: hda - set input_path bitmap to zero after moving it to new place
Paul Burton <[email protected]>
MIPS: Fix IRQ tracing & lockdep when rescheduling
Paul Burton <[email protected]>
MIPS: pm-cps: Drop manual cache-line alignment of ready_count
James Hogan <[email protected]>
MIPS: Avoid accidental raw backtrace
Julien Grall <[email protected]>
arm64: cpuinfo: Missing NULL terminator in compat_hwcap_str
Kinglong Mee <[email protected]>
NFSv4: fix a reference leak caused WARNING messages
Gao Feng <[email protected]>
net: 8021q: Fix one possible panic caused by BUG_ON in free_netdev
Wei Wang <[email protected]>
decnet: always not take dst->__refcnt when inserting dst into hash table
Xin Long <[email protected]>
ipv6: fix calling in6_ifa_hold incorrectly for dad work
WANG Cong <[email protected]>
igmp: add a missing spin_lock_init()
WANG Cong <[email protected]>
igmp: acquire pmc lock for ip_mc_clear_src()
Jia-Ju Bai <[email protected]>
net: caif: Fix a sleep-in-atomic bug in cfpkt_create_pfx
Krister Johansen <[email protected]>
Fix an intermittent pr_emerg warning about lo becoming free.
Mateusz Jurczyk <[email protected]>
decnet: dn_rtmsg: Improve input length sanitization in dnrmg_receive_user_skb
Alexander Potapenko <[email protected]>
net: don't call strlen on non-terminated string in dev_set_alias()
Eric Leblond <[email protected]>
netfilter: synproxy: fix conntrackd interaction
Eric Dumazet <[email protected]>
netfilter: xt_TCPMSS: add more sanity tests on tcph->doff
Willem de Bruijn <[email protected]>
ipv6: release dst on error in ip6_dst_lookup_tail
Mathias Nyman <[email protected]>
xhci: fix deadlock at host remove by running watchdog correctly
-------------
Diffstat:
Documentation/sysctl/kernel.txt | 15 +++++----- Makefile | 4 +-- arch/arm/boot/dts/bcm5301x.dtsi | 4 +-- arch/arm/mm/mmu.c | 8 ++--- arch/arm64/kernel/setup.c | 3 +- arch/mips/kernel/entry.S | 3 ++ arch/mips/kernel/pm-cps.c | 9 +----- arch/mips/kernel/traps.c | 2 ++ arch/x86/kvm/vmx.c | 2 +- arch/x86/kvm/x86.c | 2 ++ drivers/cpufreq/s3c2416-cpufreq.c | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c | 1 + drivers/iommu/amd_iommu_v2.c | 2 +- drivers/iommu/intel-iommu.c | 2 +- drivers/mtd/bcm47xxpart.c | 4 +-- drivers/net/ethernet/korina.c | 8 ++--- drivers/usb/gadget/function/f_fs.c | 8 +++-- drivers/usb/host/xhci-ring.c | 11 ------- drivers/usb/host/xhci.c | 13 --------- drivers/watchdog/bcm_kona_wdt.c | 3 +- fs/nfs/nfs4proc.c | 2 -- include/net/xfrm.h | 10 ------- kernel/sysctl.c | 2 +- mm/huge_memory.c | 7 +++++ net/8021q/vlan.c | 3 +- net/caif/cfpkt_skbuff.c | 6 +--- net/core/dev.c | 3 +- net/core/dst.c | 14 +++++++++ net/decnet/dn_route.c | 14 +++------ net/decnet/netfilter/dn_rtmsg.c | 4 ++- net/ipv4/igmp.c | 22 +++++++++----- net/ipv6/addrconf.c | 6 ++-- net/ipv6/ip6_output.c | 6 ++-- net/key/af_key.c | 17 ++++++++--- net/netfilter/nf_conntrack_netlink.c | 4 +++ net/netfilter/xt_TCPMSS.c | 6 +++- net/xfrm/xfrm_policy.c | 47 ------------------------------ sound/pci/hda/hda_generic.c | 1 + 38 files changed, 121 insertions(+), 158 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/36 xhci: fix deadlock at host remove by running watchdog correctly
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathias Nyman <[email protected]>
commit d6169d04097fd9ddf811e63eae4e5cd71e6666e2 upstream.
If a URB is killed while the host is removed we can end up in a situation where the hub thread takes the roothub device lock, and waits for the URB to be given back by xhci-hcd, blocking the host remove code.
xhci-hcd tries to stop the endpoint and give back the urb, but can't as the host is removed from PCI bus at the same time, preventing the normal way of giving back urb.
Instead we need to rely on the stop command timeout function to give back the urb. This xhci_stop_endpoint_command_watchdog() timeout function used a XHCI_STATE_DYING flag to indicate if the timeout function is already running, but later this flag has been taking into use in other places to mark that xhci is dying.
Remove checks for XHCI_STATE_DYING in xhci_urb_dequeue. We are still checking that reading from pci state does not return 0xffffffff or that host is not halted before trying to stop the endpoint.
This whole area of stopping endpoints, giving back URBs, and the wathdog timeout need rework, this fix focuses on solving a specific deadlock issue that we can then send to stable before any major rework.
--- drivers/usb/host/xhci-ring.c | 11 ----------- drivers/usb/host/xhci.c | 13 ------------- 2 files changed, 24 deletions(-)
drivers/usb/host/xhci-ring.c +0 -11
@@ -839,17 +839,6 @@ void xhci_stop_endpoint_command_watchdogspin_lock_irqsave (&xhci->lock, flags); ep->stop_cmds_pending--; -if (xhci->xhc_state &XHCI_STATE_REMOVING ) { -spin_unlock_irqrestore (&xhci->lock, flags); -return ; - } -if (xhci->xhc_state &XHCI_STATE_DYING ) { -xhci_dbg_trace (xhci, trace_xhci_dbg_cancel_urb, -"Stop EP timer ran, but another timer marked " -"xHCI as DYING, exiting." ); -spin_unlock_irqrestore (&xhci->lock, flags); -return ; - }if (!(ep->stop_cmds_pending ==0 && (ep->ep_state &EP_HALT_PENDING ))) {xhci_dbg_trace (xhci, trace_xhci_dbg_cancel_urb, "Stop EP timer ran, but no command pending, "
drivers/usb/host/xhci.c +0 -13
@@ -1565,19 +1565,6 @@ int xhci_urb_dequeue(struct usb_hcd *hcdxhci_urb_free_priv (xhci, urb_priv);return ret; } -if ((xhci->xhc_state &XHCI_STATE_DYING ) || - (xhci->xhc_state &XHCI_STATE_HALTED )) { -xhci_dbg_trace (xhci, trace_xhci_dbg_cancel_urb, -"Ep 0x%x: URB %p to be canceled on " -"non-responsive xHCI host." , - urb->ep->desc.bEndpointAddress, urb); -/* Let the stop endpoint command watchdog timer (which set this -* state) finish cleaning up the endpoint TD lists. We must -* have caught it in the middle of dropping a lock and giving -* back an URB. -*/ - goto done; - } ep_index =xhci_get_endpoint_index (&urb->ep->desc); ep = &xhci->devs[urb->dev->slot_id]->eps[ep_index];
Greg Kroah-Hartman
maintainerPATCH 2/36 ipv6: release dst on error in ip6_dst_lookup_tail
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Willem de Bruijn <[email protected]>
commit 00ea1ceebe0d9f2dc1cc2b7bd575a00100c27869 upstream.
If ip6_dst_lookup_tail has acquired a dst and fails the IPv4-mapped check, release the dst before returning an error.
--- net/ipv6/ip6_output.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
net/ipv6/ip6_output.c +4 -2
@@ -961,8 +961,10 @@ static int ip6_dst_lookup_tail(struct so }#endif if (ipv6_addr_v4mapped (&fl6->saddr) && - !(ipv6_addr_v4mapped (&fl6->daddr) ||ipv6_addr_any (&fl6->daddr))) -return -EAFNOSUPPORT ; + !(ipv6_addr_v4mapped (&fl6->daddr) ||ipv6_addr_any (&fl6->daddr))) { + err = -EAFNOSUPPORT ; + goto out_err_release; + }return 0 ;
Greg Kroah-Hartman
maintainerPATCH 3/36 netfilter: xt_TCPMSS: add more sanity tests on tcph->doff
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
commit 2638fd0f92d4397884fd991d8f4925cb3f081901 upstream.
Denys provided an awesome KASAN report pointing to an use after free in xt_TCPMSS
I have provided three patches to fix this issue, either in xt_TCPMSS or in xt_tcpudp.c. It seems xt_TCPMSS patch has the smallest possible impact.
--- net/netfilter/xt_TCPMSS.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
net/netfilter/xt_TCPMSS.c +5 -1
@@ -104,7 +104,7 @@ tcpmss_mangle_packet(struct sk_buff *skb tcph = (struct tcphdr *)(skb_network_header (skb) + tcphoff); tcp_hdrlen = tcph->doff *4 ; -if (len < tcp_hdrlen) +if (len < tcp_hdrlen || tcp_hdrlen <sizeof (struct tcphdr ))return -1 ;if (info->mss ==XT_TCPMSS_CLAMP_PMTU ) {
@@ -156,6 +156,10 @@ tcpmss_mangle_packet(struct sk_buff *skbif (len > tcp_hdrlen)return 0 ; +/* tcph->doff has 4 bits, do not wrap it to 0 */ +if (tcp_hdrlen >=15 *4 ) +return 0 ; +/* * MSS Option not found ?! add it.. */
Greg Kroah-Hartman
maintainerPATCH 4/36 netfilter: synproxy: fix conntrackd interaction
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Leblond <[email protected]>
commit 87e94dbc210a720a34be5c1174faee5c84be963e upstream.
This patch fixes the creation of connection tracking entry from netlink when synproxy is used. It was missing the addition of the synproxy extension.
This was causing kernel crashes when a conntrack entry created by conntrackd was used after the switch of traffic from active node to the passive node.
--- net/netfilter/nf_conntrack_netlink.c | 4 ++++ 1 file changed, 4 insertions(+)
net/netfilter/nf_conntrack_netlink.c +4 -0
@@ -45,6 +45,8 @@#include <net/netfilter/nf_conntrack_zones.h> #include <net/netfilter/nf_conntrack_timestamp.h> #include <net/netfilter/nf_conntrack_labels.h> +#include <net/netfilter/nf_conntrack_seqadj.h> +#include <net/netfilter/nf_conntrack_synproxy.h> #ifdef CONFIG_NF_NAT_NEEDED #include <net/netfilter/nf_nat_core.h> #include <net/netfilter/nf_nat_l4proto.h>
@@ -1688,6 +1690,8 @@ ctnetlink_create_conntrack(struct net *nnf_ct_tstamp_ext_add (ct,GFP_ATOMIC );nf_ct_ecache_ext_add (ct,0 ,0 ,GFP_ATOMIC );nf_ct_labels_ext_add (ct); +nfct_seqadj_ext_add (ct); +nfct_synproxy_ext_add (ct);/* we must add conntrack extensions before confirmation. */ ct->status |=IPS_CONFIRMED ;
Greg Kroah-Hartman
maintainerPATCH 5/36 net: dont call strlen on non-terminated string in dev_set_alias()
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Potapenko <[email protected]>
[ Upstream commit c28294b941232931fbd714099798eb7aa7e865d7 ]
KMSAN reported a use of uninitialized memory in dev_set_alias(), which was caused by calling strlcpy() (which in turn called strlen()) on the user-supplied non-terminated string.
--- net/core/dev.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/core/dev.c +2 -1
@@ -1194,8 +1194,9 @@ int dev_set_alias(struct net_device *devif (!new_ifalias)return -ENOMEM ; dev->ifalias = new_ifalias; +memcpy (dev->ifalias, alias, len); + dev->ifalias[len] =0 ; -strlcpy (dev->ifalias, alias, len+1 );return len; }
Greg Kroah-Hartman
maintainerPATCH 6/36 decnet: dn_rtmsg: Improve input length sanitization in dnrmg_receive_user_skb
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mateusz Jurczyk <[email protected]>
[ Upstream commit dd0da17b209ed91f39872766634ca967c170ada1 ]
Verify that the length of the socket buffer is sufficient to cover the nlmsghdr structure before accessing the nlh->nlmsg_len field for further input sanitization. If the client only supplies 1-3 bytes of data in sk_buff, then nlh->nlmsg_len remains partially uninitialized and contains leftover memory from the corresponding kernel allocation. Operating on such data may result in indeterminate evaluation of the nlmsg_len < sizeof(*nlh) expression.
The bug was discovered by a runtime instrumentation designed to detect use of uninitialized memory in the kernel. The patch prevents this and other similar tools (e.g. KMSAN) from flagging this behavior in the future.
--- net/decnet/netfilter/dn_rtmsg.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
net/decnet/netfilter/dn_rtmsg.c +3 -1
@@ -104,7 +104,9 @@ static inline void dnrmg_receive_user_sk {struct nlmsghdr *nlh =nlmsg_hdr (skb); -if (nlh->nlmsg_len <sizeof (*nlh) || skb->len < nlh->nlmsg_len) +if (skb->len <sizeof (*nlh) || + nlh->nlmsg_len <sizeof (*nlh) || + skb->len < nlh->nlmsg_len)return ;if (!netlink_capable (skb,CAP_NET_ADMIN ))
Greg Kroah-Hartman
maintainerPATCH 7/36 Fix an intermittent pr_emerg warning about lo becoming free.
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krister Johansen <[email protected]>
[ Upstream commit f186ce61bb8235d80068c390dc2aad7ca427a4c2 ]
It looks like this:
Message from syslogd@flamingo at Apr 26 00:45:00 ...
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 4
They seem to coincide with net namespace teardown.
The message is emitted by netdev_wait_allrefs().
Forced a kdump in netdev_run_todo, but found that the refcount on the lo device was already 0 at the time we got to the panic.
Used bcc to check the blocking in netdev_run_todo. The only places where we're off cpu there are in the rcu_barrier() and msleep() calls. That behavior is expected. The msleep time coincides with the amount of time we spend waiting for the refcount to reach zero; the rcu_barrier() wait times are not excessive.
After looking through the list of callbacks that the netdevice notifiers invoke in this path, it appears that the dst_dev_event is the most interesting. The dst_ifdown path places a hold on the loopback_dev as part of releasing the dev associated with the original dst cache entry. Most of our notifier callbacks are straight-forward, but this one a) looks complex, and b) places a hold on the network interface in question.
I constructed a new bcc script that watches various events in the liftime of a dst cache entry. Note that dst_ifdown will take a hold on the loopback device until the invalidated dst entry gets freed.
[ __dst_free] on DST: ffff883ccabb7900 IF tap1008300eth0 invoked at 1282115677036183
__dst_free
rcu_nocb_kthread
kthread
ret_from_fork--- net/core/dst.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
net/core/dst.c +14 -0
@@ -397,6 +397,20 @@ static int dst_dev_event(struct notifierspin_lock_bh (&dst_garbage.lock); dst = dst_garbage.list; dst_garbage.list =NULL ; +/* The code in dst_ifdown places a hold on the loopback device. +* If the gc entry processing is set to expire after a lengthy +* interval, this hold can cause netdev_wait_allrefs() to hang +* out and wait for a long time -- until the the loopback +* interface is released. If we're really unlucky, it'll emit +* pr_emerg messages to console too. Reset the interval here, +* so dst cleanups occur in a more timely fashion. +*/ +if (dst_garbage.timer_inc >DST_GC_INC ) { + dst_garbage.timer_inc =DST_GC_INC ; + dst_garbage.timer_expires =DST_GC_MIN ; +mod_delayed_work (system_wq, &dst_gc_work, + dst_garbage.timer_expires); + }spin_unlock_bh (&dst_garbage.lock);if (last)
Greg Kroah-Hartman
maintainerPATCH 8/36 net: caif: Fix a sleep-in-atomic bug in cfpkt_create_pfx
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jia-Ju Bai <[email protected]>
[ Upstream commit f146e872eb12ebbe92d8e583b2637e0741440db3 ]
The kernel may sleep under a rcu read lock in cfpkt_create_pfx, and the function call path is:cfcnfg_linkup_rsp (acquire the lock by rcu_read_lock)
cfctrl_linkdown_req
cfpkt_create
cfpkt_create_pfx
alloc_skb(GFP_KERNEL) --> may sleep
cfserl_receive (acquire the lock by rcu_read_lock)
cfpkt_split
cfpkt_create_pfx
alloc_skb(GFP_KERNEL) --> may sleepThere is "in_interrupt" in cfpkt_create_pfx to decide use "GFP_KERNEL" or "GFP_ATOMIC". In this situation, "GFP_KERNEL" is used because the function is called under a rcu read lock, instead in interrupt.
To fix it, only "GFP_ATOMIC" is used in cfpkt_create_pfx.
--- net/caif/cfpkt_skbuff.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-)
net/caif/cfpkt_skbuff.c +1 -5
@@ -81,11 +81,7 @@ static struct cfpkt *cfpkt_create_pfx(u1 {struct sk_buff *skb; -if (likely (in_interrupt ())) - skb =alloc_skb (len + pfx,GFP_ATOMIC ); -else - skb =alloc_skb (len + pfx,GFP_KERNEL ); - + skb =alloc_skb (len + pfx,GFP_ATOMIC );if (unlikely (skb ==NULL ))return NULL ;
Greg Kroah-Hartman
maintainerPATCH 9/36 igmp: acquire pmc lock for ip_mc_clear_src()
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: WANG Cong <[email protected]>
[ Upstream commit c38b7d327aafd1e3ad7ff53eefac990673b65667 ]
Andrey reported a use-after-free in add_grec():
for (psf = *psf_list; psf; psf = psf_next) {
...
psf_next = psf->sf_next;where the struct ip_sf_list's were already freed by:
kfree+0xe8/0x2b0 mm/slub.c:3882 ip_mc_clear_src+0x69/0x1c0 net/ipv4/igmp.c:2078 ip_mc_dec_group+0x19a/0x470 net/ipv4/igmp.c:1618 ip_mc_drop_socket+0x145/0x230 net/ipv4/igmp.c:2609 inet_release+0x4e/0x1c0 net/ipv4/af_inet.c:411 sock_release+0x8d/0x1e0 net/socket.c:597 sock_close+0x16/0x20 net/socket.c:1072
This happens because we don't hold pmc->lock in ip_mc_clear_src() and a parallel mr_ifc_timer timer could jump in and access them.
The RCU lock is there but it is merely for pmc itself, this spinlock could actually ensure we don't access them in parallel.
Thanks to Eric and Long for discussion on this bug.
--- net/ipv4/igmp.c | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-)
net/ipv4/igmp.c +13 -8
@@ -1832,21 +1832,26 @@ static int ip_mc_add_src(struct in_devicstatic void ip_mc_clear_src (struct ip_mc_list *pmc) { -struct ip_sf_list *psf, *nextpsf; +struct ip_sf_list *psf, *nextpsf, *tomb, *sources; -for (psf = pmc->tomb; psf; psf = nextpsf) { +spin_lock_bh (&pmc->lock); + tomb = pmc->tomb; + pmc->tomb =NULL ; + sources = pmc->sources; + pmc->sources =NULL ; + pmc->sfmode =MCAST_EXCLUDE ; + pmc->sfcount[MCAST_INCLUDE ] =0 ; + pmc->sfcount[MCAST_EXCLUDE ] =1 ; +spin_unlock_bh (&pmc->lock); + +for (psf = tomb; psf; psf = nextpsf) { nextpsf = psf->sf_next;kfree (psf); } - pmc->tomb =NULL ; -for (psf = pmc->sources; psf; psf = nextpsf) { +for (psf = sources; psf; psf = nextpsf) { nextpsf = psf->sf_next;kfree (psf); } - pmc->sources =NULL ; - pmc->sfmode =MCAST_EXCLUDE ; - pmc->sfcount[MCAST_INCLUDE ] =0 ; - pmc->sfcount[MCAST_EXCLUDE ] =1 ; }
Greg Kroah-Hartman
maintainerPATCH 10/36 igmp: add a missing spin_lock_init()
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: WANG Cong <[email protected]>
[ Upstream commit b4846fc3c8559649277e3e4e6b5cec5348a8d208 ]
Andrey reported a lockdep warning on non-initialized spinlock:
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 1 PID: 4099 Comm: a.out Not tainted 4.12.0-rc6+ #9 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:16 dump_stack+0x292/0x395 lib/dump_stack.c:52 register_lock_class+0x717/0x1aa0 kernel/locking/lockdep.c:755 ? 0xffffffffa0000000 __lock_acquire+0x269/0x3690 kernel/locking/lockdep.c:3255 lock_acquire+0x22d/0x560 kernel/locking/lockdep.c:3855 __raw_spin_lock_bh ./include/linux/spinlock_api_smp.h:135 _raw_spin_lock_bh+0x36/0x50 kernel/locking/spinlock.c:175 spin_lock_bh ./include/linux/spinlock.h:304 ip_mc_clear_src+0x27/0x1e0 net/ipv4/igmp.c:2076 igmpv3_clear_delrec+0xee/0x4f0 net/ipv4/igmp.c:1194 ip_mc_destroy_dev+0x4e/0x190 net/ipv4/igmp.c:1736
We miss a spin_lock_init() in igmpv3_add_delrec(), probably because previously we never use it on this code path. Since we already unlink it from the global mc_tomb list, it is probably safe not to acquire this spinlock here. It does not harm to have it although, to avoid conditional locking.
--- net/ipv4/igmp.c | 1 + 1 file changed, 1 insertion(+)
net/ipv4/igmp.c +1 -0
@@ -1080,6 +1080,7 @@ static void igmpv3_add_delrec(struct in_ pmc =kzalloc (sizeof (*pmc),GFP_KERNEL );if (!pmc)return ; +spin_lock_init (&pmc->lock);spin_lock_bh (&im->lock); pmc->interface = im->interface;in_dev_hold (in_dev);
Greg Kroah-Hartman
maintainerPATCH 11/36 ipv6: fix calling in6_ifa_hold incorrectly for dad work
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xin Long <[email protected]>
[ Upstream commit f8a894b218138888542a5058d0e902378fd0d4ec ]
Now when starting the dad work in addrconf_mod_dad_work, if the dad work is idle and queued, it needs to hold ifa.
The problem is there's one gap in [1], during which if the pending dad work is removed elsewhere. It will miss to hold ifa, but the dad word is still idea and queue.
if (!delayed_work_pending(&ifp->dad_work))
in6_ifa_hold(ifp);
<--------------[1]
mod_delayed_work(addrconf_wq, &ifp->dad_work, delay);An use-after-free issue can be caused by this.
Chen Wei found this issue when WARN_ON(!hlist_unhashed(&ifp->addr_lst)) in net6_ifa_finish_destroy was hit because of it.
As Hannes' suggestion, this patch is to fix it by holding ifa first in addrconf_mod_dad_work, then calling mod_delayed_work and putting ifa if the dad_work is already in queue.
Note that this patch did not choose to fix it with:
if (!mod_delayed_work(delay))
in6_ifa_hold(ifp);As with it, when delay == 0, dad_work would be scheduled immediately, all addrconf_mod_dad_work(0) callings had to be moved under ifp->lock.
--- net/ipv6/addrconf.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
net/ipv6/addrconf.c +3 -3
@@ -269,9 +269,9 @@ static void addrconf_mod_rs_timer(structstatic void addrconf_mod_dad_work (struct inet6_ifaddr *ifp,unsigned long delay) { -if (!delayed_work_pending (&ifp->dad_work)) -in6_ifa_hold (ifp); -mod_delayed_work (addrconf_wq, &ifp->dad_work, delay); +in6_ifa_hold (ifp); +if (mod_delayed_work (addrconf_wq, &ifp->dad_work, delay)) +in6_ifa_put (ifp); }static int snmp6_alloc_dev (struct inet6_dev *idev)
Greg Kroah-Hartman
maintainerPATCH 12/36 decnet: always not take dst->__refcnt when inserting dst into hash table
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Wang <[email protected]>
[ Upstream commit 76371d2e3ad1f84426a30ebcd8c3b9b98f4c724f ]
In the existing dn_route.c code, dn_route_output_slow() takes dst->__refcnt before calling dn_insert_route() while dn_route_input_slow() does not take dst->__refcnt before calling dn_insert_route(). This makes the whole routing code very buggy.
In dn_dst_check_expire(), dnrt_free() is called when rt expires. This makes the routes inserted by dn_route_output_slow() not able to be freed as the refcnt is not released.
In dn_dst_gc(), dnrt_drop() is called to release rt which could potentially cause the dst->__refcnt to be dropped to -1.
In dn_run_flush(), dst_free() is called to release all the dst. Again, it makes the dst inserted by dn_route_output_slow() not able to be released and also, it does not wait on the rcu and could potentially cause crash in the path where other users still refer to this dst.
This patch makes sure both input and output path do not take dst->__refcnt before calling dn_insert_route() and also makes sure dnrt_free()/dst_free() is called when removing dst from the hash table. The only difference between those 2 calls is that dnrt_free() waits on the rcu while dst_free() does not.
--- net/decnet/dn_route.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-)
net/decnet/dn_route.c +4 -10
@@ -189,12 +189,6 @@ static inline void dnrt_free(struct dn_rcall_rcu_bh (&rt->dst.rcu_head, dst_rcu_free); } -static inline void dnrt_drop (struct dn_route *rt) -{ -dst_release (&rt->dst); -call_rcu_bh (&rt->dst.rcu_head, dst_rcu_free); -} -static void dn_dst_check_expire (unsigned long dummy) {int i;
@@ -249,7 +243,7 @@ static int dn_dst_gc(struct dst_ops *ops } *rtp = rt->dst.dn_next; rt->dst.dn_next =NULL ; -dnrt_drop (rt); +dnrt_free (rt);break ; }spin_unlock_bh (&dn_rt_hash_table[i].lock);
@@ -351,7 +345,7 @@ static int dn_insert_route(struct dn_roudst_use (&rth->dst, now);spin_unlock_bh (&dn_rt_hash_table[hash].lock); -dnrt_drop (rt); +dst_free (&rt->dst); *rp = rth;return 0 ; }
@@ -381,7 +375,7 @@ static void dn_run_flush(unsigned long dfor (; rt; rt = next) { next =rcu_dereference_raw (rt->dst.dn_next);RCU_INIT_POINTER (rt->dst.dn_next,NULL ); -dst_free ((struct dst_entry *)rt); +dnrt_free (rt); } nothing_to_declare:
@@ -1195,7 +1189,7 @@ make_route:if (dev_out->flags &IFF_LOOPBACK ) flags |=RTCF_LOCAL ; - rt =dst_alloc (&dn_dst_ops, dev_out,1 ,DST_OBSOLETE_NONE ,DST_HOST ); + rt =dst_alloc (&dn_dst_ops, dev_out,0 ,DST_OBSOLETE_NONE ,DST_HOST );if (rt ==NULL ) goto e_nobufs;
Greg Kroah-Hartman
maintainerPATCH 13/36 net: 8021q: Fix one possible panic caused by BUG_ON in free_netdev
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gao Feng <[email protected]>
[ Upstream commit 9745e362add89432d2c951272a99b0a5fe4348a9 ]
The register_vlan_device would invoke free_netdev directly, when register_vlan_dev failed. It would trigger the BUG_ON in free_netdev if the dev was already registered. In this case, the netdev would be freed in netdev_run_todo later.
So add one condition check now. Only when dev is not registered, then free it directly.
The following is the part coredump when netdev_upper_dev_link failed in register_vlan_dev. I removed the lines which are too long.
[ 411.237457] ------------[ cut here ]------------ [ 411.237458] kernel BUG at net/core/dev.c:7998! [ 411.237484] invalid opcode: 0000 [#1] SMP [ 411.237705] [last unloaded: 8021q] [ 411.237718] CPU: 1 PID: 12845 Comm: vconfig Tainted: G E 4.12.0-rc5+ #6 [ 411.237737] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015 [ 411.237764] task: ffff9cbeb6685580 task.stack: ffffa7d2807d8000 [ 411.237782] RIP: 0010:free_netdev+0x116/0x120 [ 411.237794] RSP: 0018:ffffa7d2807dbdb0 EFLAGS: 00010297 [ 411.237808] RAX: 0000000000000002 RBX: ffff9cbeb6ba8fd8 RCX: 0000000000001878 [ 411.237826] RDX: 0000000000000001 RSI: 0000000000000282 RDI: 0000000000000000 [ 411.237844] RBP: ffffa7d2807dbdc8 R08: 0002986100029841 R09: 0002982100029801 [ 411.237861] R10: 0004000100029980 R11: 0004000100029980 R12: ffff9cbeb6ba9000 [ 411.238761] R13: ffff9cbeb6ba9060 R14: ffff9cbe60f1a000 R15: ffff9cbeb6ba9000 [ 411.239518] FS: 00007fb690d81700(0000) GS:ffff9cbebb640000(0000) knlGS:0000000000000000 [ 411.239949] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 411.240454] CR2: 00007f7115624000 CR3: 0000000077cdf000 CR4: 00000000003406e0 [ 411.240936] Call Trace: [ 411.241462] vlan_ioctl_handler+0x3f1/0x400 [8021q] [ 411.241910] sock_ioctl+0x18b/0x2c0 [ 411.242394] do_vfs_ioctl+0xa1/0x5d0 [ 411.242853] ? sock_alloc_file+0xa6/0x130 [ 411.243465] SyS_ioctl+0x79/0x90 [ 411.243900] entry_SYSCALL_64_fastpath+0x1e/0xa9 [ 411.244425] RIP: 0033:0x7fb69089a357 [ 411.244863] RSP: 002b:00007ffcd04e0fc8 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 [ 411.245445] RAX: ffffffffffffffda RBX: 00007ffcd04e2884 RCX: 00007fb69089a357 [ 411.245903] RDX: 00007ffcd04e0fd0 RSI: 0000000000008983 RDI: 0000000000000003 [ 411.246527] RBP: 00007ffcd04e0fd0 R08: 0000000000000000 R09: 1999999999999999 [ 411.246976] R10: 000000000000053f R11: 0000000000000202 R12: 0000000000000004 [ 411.247414] R13: 00007ffcd04e1128 R14: 00007ffcd04e2888 R15: 0000000000000001 [ 411.249129] RIP: free_netdev+0x116/0x120 RSP: ffffa7d2807dbdb0
--- net/8021q/vlan.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/8021q/vlan.c +2 -1
@@ -278,7 +278,8 @@ static int register_vlan_device(struct nreturn 0 ; out_free_newdev: -free_netdev (new_dev); +if (new_dev->reg_state ==NETREG_UNINITIALIZED ) +free_netdev (new_dev);return err; }
Greg Kroah-Hartman
maintainerPATCH 14/36 NFSv4: fix a reference leak caused WARNING messages
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kinglong Mee <[email protected]>
commit 366a1569bff3fe14abfdf9285e31e05e091745f5 upstream.
Because nfs4_opendata_access() has close the state when access is denied, so the state isn't leak.
Rather than revert the commit a974deee47, I'd like clean the strange state close.
[ 1615.094218] ------------[ cut here ]------------ [ 1615.094607] WARNING: CPU: 0 PID: 23702 at lib/list_debug.c:31 __list_add_valid+0x8e/0xa0 [ 1615.094913] list_add double add: new=ffff9d7901d9f608, prev=ffff9d7901d9f608, next=ffff9d7901ee8dd0. [ 1615.095458] Modules linked in: nfsv4(E) nfs(E) nfsd(E) tun bridge stp llc fuse ip_set nfnetlink vmw_vsock_vmci_transport vsock f2fs snd_seq_midi snd_seq_midi_event fscrypto coretemp ppdev crct10dif_pclmul crc32_pclmul ghash_clmulni_intel intel_rapl_perf vmw_balloon snd_ens1371 joydev gameport snd_ac97_codec ac97_bus snd_seq snd_pcm snd_rawmidi snd_timer snd_seq_device snd soundcore nfit parport_pc parport acpi_cpufreq tpm_tis tpm_tis_core tpm i2c_piix4 vmw_vmci shpchp auth_rpcgss nfs_acl lockd(E) grace sunrpc(E) xfs libcrc32c vmwgfx drm_kms_helper ttm drm crc32c_intel mptspi e1000 serio_raw scsi_transport_spi mptscsih mptbase ata_generic pata_acpi fjes [last unloaded: nfs] [ 1615.097663] CPU: 0 PID: 23702 Comm: fstest Tainted: G W E 4.11.0-rc1+ #517 [ 1615.098015] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015 [ 1615.098807] Call Trace: [ 1615.099183] dump_stack+0x63/0x86 [ 1615.099578] __warn+0xcb/0xf0 [ 1615.099967] warn_slowpath_fmt+0x5f/0x80 [ 1615.100370] __list_add_valid+0x8e/0xa0 [ 1615.100760] nfs4_put_state_owner+0x75/0xc0 [nfsv4] [ 1615.101136] __nfs4_close+0x109/0x140 [nfsv4] [ 1615.101524] nfs4_close_state+0x15/0x20 [nfsv4] [ 1615.101949] nfs4_close_context+0x21/0x30 [nfsv4] [ 1615.102691] __put_nfs_open_context+0xb8/0x110 [nfs] [ 1615.103155] put_nfs_open_context+0x10/0x20 [nfs] [ 1615.103586] nfs4_file_open+0x13b/0x260 [nfsv4] [ 1615.103978] do_dentry_open+0x20a/0x2f0 [ 1615.104369] ? nfs4_copy_file_range+0x30/0x30 [nfsv4] [ 1615.104739] vfs_open+0x4c/0x70 [ 1615.105106] ? may_open+0x5a/0x100 [ 1615.105469] path_openat+0x623/0x1420 [ 1615.105823] do_filp_open+0x91/0x100 [ 1615.106174] ? __alloc_fd+0x3f/0x170 [ 1615.106568] do_sys_open+0x130/0x220 [ 1615.106920] ? __put_cred+0x3d/0x50 [ 1615.107256] SyS_open+0x1e/0x20 [ 1615.107588] entry_SYSCALL_64_fastpath+0x1a/0xa9 [ 1615.107922] RIP: 0033:0x7fab599069b0 [ 1615.108247] RSP: 002b:00007ffcf0600d78 EFLAGS: 00000246 ORIG_RAX: 0000000000000002 [ 1615.108575] RAX: ffffffffffffffda RBX: 00007fab59bcfae0 RCX: 00007fab599069b0 [ 1615.108896] RDX: 0000000000000200 RSI: 0000000000000200 RDI: 00007ffcf060255e [ 1615.109211] RBP: 0000000000040010 R08: 0000000000000000 R09: 0000000000000016 [ 1615.109515] R10: 00000000000006a1 R11: 0000000000000246 R12: 0000000000041000 [ 1615.109806] R13: 0000000000040010 R14: 0000000000001000 R15: 0000000000002710 [ 1615.110152] ---[ end trace 96ed63b1306bf2f3 ]---
--- fs/nfs/nfs4proc.c | 2 -- 1 file changed, 2 deletions(-)
fs/nfs/nfs4proc.c +0 -2
@@ -1995,8 +1995,6 @@ static int nfs4_opendata_access(struct rif ((mask & ~cache.mask & (MAY_READ |MAY_EXEC )) ==0 )return 0 ; -/* even though OPEN succeeded, access is denied. Close the file */ -nfs4_close_state (state, fmode);return -EACCES ; }
Re: [PATCH 3.18 14/36] NFSv4: fix a reference leak caused WARNING messages
Hi Greg,
Quoted 2 lines · Greg Kroah-Hartman
3.18-stable review patch. If anyone has any objections, please let me know.
I cannot find commit a974deee477af89411e0f80456bfb344ac433c98 in v3.18.59, so I think we should probably drop this patch instance. Thanks for applying it to the newer stable kernels!
Cheers
Trond
Quoted 95 lines
------------------
From: Kinglong Mee <[email protected]>
commit
366a1569bff3fe14abfdf9285e31e05e091745f5upstream.Because
nfs4_opendata_access()has close the state when access is denied,
so the state isn't leak.
Rather than revert the commita974deee47, I'd like clean the strange state close.[ 1615.094218] ------------[ cut here ]------------ [ 1615.094607] WARNING: CPU: 0 PID: 23702 at lib/list_debug.c:31 __list_add_valid+0x8e/0xa0 [ 1615.094913] list_add double add: new=ffff9d7901d9f608, prev=ffff9d7901d9f608, next=ffff9d7901ee8dd0. [ 1615.095458] Modules linked in: nfsv4(E) nfs(E) nfsd(E) tun bridgestp llc fuse
ip_setnfnetlinkvmw_vsock_vmci_transportvsock f2fssnd_seq_midisnd_seq_midi_eventfscrypto coretemp ppdevcrct10dif_pclmulcrc32_pclmulghash_clmulni_intelintel_rapl_perfvmw_balloonsnd_ens1371joydev gameportsnd_ac97_codecac97_bussnd_seqsnd_pcmsnd_rawmidisnd_timersnd_seq_devicesnd soundcore nfitparport_pcparportacpi_cpufreqtpm_tistpm_tis_coretpmi2c_piix4vmw_vmcishpchpauth_rpcgssnfs_acllockd(E) grace sunrpc(E) xfs libcrc32c vmwgfxdrm_kms_helperttm drmcrc32c_intelmptspi e1000serio_rawscsi_transport_spimptscsih mptbaseata_genericpata_acpifjes [last unloaded: nfs][ 1615.097663] CPU: 0 PID: 23702 Comm: fstest Tainted: G W E 4.11.0-rc1+ #517 [ 1615.098015] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015 [ 1615.098807] Call Trace: [ 1615.099183] dump_stack+0x63/0x86 [ 1615.099578] __warn+0xcb/0xf0 [ 1615.099967] warn_slowpath_fmt+0x5f/0x80 [ 1615.100370] __list_add_valid+0x8e/0xa0 [ 1615.100760] nfs4_put_state_owner+0x75/0xc0 [nfsv4] [ 1615.101136] __nfs4_close+0x109/0x140 [nfsv4] [ 1615.101524] nfs4_close_state+0x15/0x20 [nfsv4] [ 1615.101949] nfs4_close_context+0x21/0x30 [nfsv4] [ 1615.102691] __put_nfs_open_context+0xb8/0x110 [nfs] [ 1615.103155] put_nfs_open_context+0x10/0x20 [nfs] [ 1615.103586] nfs4_file_open+0x13b/0x260 [nfsv4] [ 1615.103978] do_dentry_open+0x20a/0x2f0 [ 1615.104369] ? nfs4_copy_file_range+0x30/0x30 [nfsv4] [ 1615.104739] vfs_open+0x4c/0x70 [ 1615.105106] ? may_open+0x5a/0x100 [ 1615.105469] path_openat+0x623/0x1420 [ 1615.105823] do_filp_open+0x91/0x100 [ 1615.106174] ? __alloc_fd+0x3f/0x170 [ 1615.106568] do_sys_open+0x130/0x220 [ 1615.106920] ? __put_cred+0x3d/0x50 [ 1615.107256] SyS_open+0x1e/0x20 [ 1615.107588] entry_SYSCALL_64_fastpath+0x1a/0xa9 [ 1615.107922] RIP: 0033:0x7fab599069b0 [ 1615.108247] RSP: 002b:00007ffcf0600d78 EFLAGS: 00000246 ORIG_RAX: 0000000000000002 [ 1615.108575] RAX: ffffffffffffffda RBX: 00007fab59bcfae0 RCX: 00007fab599069b0 [ 1615.108896] RDX: 0000000000000200 RSI: 0000000000000200 RDI: 00007ffcf060255e [ 1615.109211] RBP: 0000000000040010 R08: 0000000000000000 R09: 0000000000000016 [ 1615.109515] R10: 00000000000006a1 R11: 0000000000000246 R12: 0000000000041000 [ 1615.109806] R13: 0000000000040010 R14: 0000000000001000 R15: 0000000000002710 [ 1615.110152] ---[ end trace 96ed63b1306bf2f3 ]---Fixes a974deee47 ("NFSv4: Fix memory and state leak in...")Signed-off-by Kinglong Mee <[email protected]>Signed-off-by Anna Schumaker <[email protected]>Cc Trond Myklebust <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
fs/nfs/nfs4proc.c | 2 --1 file changed, 2 deletions(-)fs/nfs/nfs4proc.c +0
-0@@ -1995,8 +1995,6 @@ static int nfs4_opendata_access(struct r if ((mask & ~cache.mask & (MAY_READ | MAY_EXEC)) == 0) return 0;fs/nfs/nfs4proc.c +0
-1-/* even though OPEN succeeded, access is denied. Close the file */
fs/nfs/nfs4proc.c +0
-1-nfs4_close_state (state, fmode);return
-EACCES;
}
Signature · 3 lines
Trond Myklebust Linux NFS client maintainer, PrimaryData [email protected]
[email protected]
maintainerRe: [PATCH 3.18 14/36] NFSv4: fix a reference leak caused WARNING messages
Quoted 9 lines · Trond Myklebust
Hi Greg,
Quoted 2 lines · Greg Kroah-Hartman
3.18-stable review patch.��If anyone has any objections, please let me know.
I cannot find commit
a974deee477af89411e0f80456bfb344ac433c98in v3.18.59, so I think we should probably drop this patch instance. Thanks for applying it to the newer stable kernels!
Ah, good catch, sorry about that, now dropped from this patch queue.
greg k-h
Greg Kroah-Hartman
maintainerPATCH 15/36 arm64: cpuinfo: Missing NULL terminator in compat_hwcap_str
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Julien Grall <[email protected]>
commit f228b494e56d949be8d8ea09d4f973d1979201bf upstream.
The loop that browses the array compat_hwcap_str will stop when a NULL is encountered, however NULL is missing at the end of array. This will lead to overrun until a NULL is found somewhere in the following memory. In reality, this works out because the compat_hwcap2_str array tends to follow immediately in memory, and that *is* terminated correctly. Furthermore, the unsigned int compat_elf_hwcap is checked before printing each capability, so we end up doing the right thing because the size of the two arrays is less than 32. Still, this is an obvious mistake and should be fixed.
Note for backporting: commit 12d11817eaafa414 ("arm64: Move /proc/cpuinfo handling code") moved this code in v4.4. Prior to that commit, the same change should be made in arch/arm64/kernel/setup.c.
--- arch/arm64/kernel/setup.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
arch/arm64/kernel/setup.c +2 -1
@@ -473,7 +473,8 @@ static const char *compat_hwcap_str[] ="idivt" ,"vfpd32" ,"lpae" , -"evtstrm" +"evtstrm" , +NULL }; static const char *compat_hwcap2_str[] = {
Greg Kroah-Hartman
maintainerPATCH 16/36 MIPS: Avoid accidental raw backtrace
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Hogan <[email protected]>
commit 854236363370995a609a10b03e35fd3dc5e9e4a1 upstream.
Since commit 81a76d7119f6 ("MIPS: Avoid using unwind_stack() with usermode") show_backtrace() invokes the raw backtracer when cp0_status & ST0_KSU indicates user mode to fix issues on EVA kernels where user and kernel address spaces overlap.
However this is used by show_stack() which creates its own pt_regs on the stack and leaves cp0_status uninitialised in most of the code paths. This results in the non deterministic use of the raw back tracer depending on the previous stack content.
show_stack() deals exclusively with kernel mode stacks anyway, so explicitly initialise regs.cp0_status to KSU_KERNEL (i.e. 0) to ensure we get a useful backtrace.
Patchwork: https://patchwork.linux-mips.org/patch/16656/
--- arch/mips/kernel/traps.c | 2 ++ 1 file changed, 2 insertions(+)
arch/mips/kernel/traps.c +2 -0
@@ -191,6 +191,8 @@ void show_stack(struct task_struct *task {struct pt_regs regs;mm_segment_t old_fs =get_fs (); + + regs.cp0_status =KSU_KERNEL ;if (sp) { regs.regs[29 ] = (unsigned long )sp; regs.regs[31 ] =0 ;
Greg Kroah-Hartman
maintainerPATCH 17/36 MIPS: pm-cps: Drop manual cache-line alignment of ready_count
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Burton <[email protected]>
commit 161c51ccb7a6faf45ffe09aa5cf1ad85ccdad503 upstream.
We allocate memory for a ready_count variable per-CPU, which is accessed via a cached non-coherent TLB mapping to perform synchronisation between threads within the core using LL/SC instructions. In order to ensure that the variable is contained within its own data cache line we allocate 2 lines worth of memory & align the resulting pointer to a line boundary. This is however unnecessary, since kmalloc is guaranteed to return memory which is at least cache-line aligned (see ARCH_DMA_MINALIGN). Stop the redundant manual alignment.
Besides cleaning up the code & avoiding needless work, this has the side effect of avoiding an arithmetic error found by Bryan on 64 bit systems due to the 32 bit size of the former dlinesz. This led the ready_count variable to have its upper 32b cleared erroneously for MIPS64 kernels, causing problems when ready_count was later used on MIPS64 via cpuidle.
Patchwork: https://patchwork.linux-mips.org/patch/15383/
--- arch/mips/kernel/pm-cps.c | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-)
arch/mips/kernel/pm-cps.c +1 -8
@@ -55,7 +55,6 @@ DECLARE_BITMAP(state_support, CPS_PM_STA* state. Actually per-core rather than per-CPU. */ static DEFINE_PER_CPU_ALIGNED(u32*, ready_count); -static DEFINE_PER_CPU_ALIGNED(void*, ready_count_alloc);/* Indicates online CPUs coupled with the current CPU */ static DEFINE_PER_CPU_ALIGNED(cpumask_t, online_coupled);
@@ -624,7 +623,6 @@ static int __init cps_gen_core_entries(u {enum cps_pm_state state;unsigned core = cpu_data[cpu].core; -unsigned dlinesz = cpu_data[cpu].dcache.linesz;void *entry_fn, *core_rc;for (state =CPS_PM_NC_WAIT ; state <CPS_PM_STATE_COUNT ; state++) {
@@ -644,16 +642,11 @@ static int __init cps_gen_core_entries(u }if (!per_cpu (ready_count, core)) { - core_rc =kmalloc (dlinesz *2 ,GFP_KERNEL ); + core_rc =kmalloc (sizeof (u32),GFP_KERNEL );if (!core_rc) {pr_err ("Failed allocate core %u ready_count\n" , core);return -ENOMEM ; } -per_cpu (ready_count_alloc, core) = core_rc; - -/* Ensure ready_count is aligned to a cacheline boundary */ - core_rc += dlinesz -1 ; - core_rc = (void *)((unsigned long )core_rc & ~(dlinesz -1 ));per_cpu (ready_count, core) = core_rc; }
Greg Kroah-Hartman
maintainerPATCH 18/36 MIPS: Fix IRQ tracing & lockdep when rescheduling
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Burton <[email protected]>
commit d8550860d910c6b7b70f830f59003b33daaa52c9 upstream.
When the scheduler sets TIF_NEED_RESCHED & we call into the scheduler from arch/mips/kernel/entry.S we disable interrupts. This is true regardless of whether we reach work_resched from syscall_exit_work, resume_userspace or by looping after calling schedule(). Although we disable interrupts in these paths we don't call trace_hardirqs_off() before calling into C code which may acquire locks, and we therefore leave lockdep with an inconsistent view of whether interrupts are disabled or not when CONFIG_PROVE_LOCKING & CONFIG_DEBUG_LOCKDEP are both enabled.
Without tracing this interrupt state lockdep will print warnings such as the following once a task returns from a syscall via syscall_exit_partial with TIF_NEED_RESCHED set:
[ 49.927678] ------------[ cut here ]------------ [ 49.934445] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:3687 check_flags.part.41+0x1dc/0x1e8 [ 49.946031] DEBUG_LOCKS_WARN_ON(current->hardirqs_enabled) [ 49.946355] CPU: 0 PID: 1 Comm: init Not tainted 4.10.0-00439-gc9fd5d362289-dirty #197 [ 49.963505] Stack : 0000000000000000 ffffffff81bb5d6a 0000000000000006 ffffffff801ce9c4 [ 49.974431] 0000000000000000 0000000000000000 0000000000000000 000000000000004a [ 49.985300] ffffffff80b7e487 ffffffff80a24498 a8000000ff160000 ffffffff80ede8b8 [ 49.996194] 0000000000000001 0000000000000000 0000000000000000 0000000077c8030c [ 50.007063] 000000007fd8a510 ffffffff801cd45c 0000000000000000 a8000000ff127c88 [ 50.017945] 0000000000000000 ffffffff801cf928 0000000000000001 ffffffff80a24498 [ 50.028827] 0000000000000000 0000000000000001 0000000000000000 0000000000000000 [ 50.039688] 0000000000000000 a8000000ff127bd0 0000000000000000 ffffffff805509bc [ 50.050575] 00000000140084e0 0000000000000000 0000000000000000 0000000000040a00 [ 50.061448] 0000000000000000 ffffffff8010e1b0 0000000000000000 ffffffff805509bc [ 50.072327] ... [ 50.076087] Call Trace: [ 50.079869] [<ffffffff8010e1b0>] show_stack+0x80/0xa8 [ 50.086577] [<ffffffff805509bc>] dump_stack+0x10c/0x190 [ 50.093498] [<ffffffff8015dde0>] __warn+0xf0/0x108 [ 50.099889] [<ffffffff8015de34>] warn_slowpath_fmt+0x3c/0x48 [ 50.107241] [<ffffffff801c15b4>] check_flags.part.41+0x1dc/0x1e8 [ 50.114961] [<ffffffff801c239c>] lock_is_held_type+0x8c/0xb0 [ 50.122291] [<ffffffff809461b8>] __schedule+0x8c0/0x10f8 [ 50.129221] [<ffffffff80946a60>] schedule+0x30/0x98 [ 50.135659] [<ffffffff80106278>] work_resched+0x8/0x34 [ 50.142397] ---[ end trace 0cb4f6ef5b99fe21 ]--- [ 50.148405] possible reason: unannotated irqs-off. [ 50.154600] irq event stamp: 400463 [ 50.159566] hardirqs last enabled at (400463): [<ffffffff8094edc8>] _raw_spin_unlock_irqrestore+0x40/0xa8 [ 50.171981] hardirqs last disabled at (400462): [<ffffffff8094eb98>] _raw_spin_lock_irqsave+0x30/0xb0 [ 50.183897] softirqs last enabled at (400450): [<ffffffff8016580c>] __do_softirq+0x4ac/0x6a8 [ 50.195015] softirqs last disabled at (400425): [<ffffffff80165e78>] irq_exit+0x110/0x128
Fix this by using the TRACE_IRQS_OFF macro to call trace_hardirqs_off() when CONFIG_TRACE_IRQFLAGS is enabled. This is done before invoking schedule() following the work_resched label because:
1) Interrupts are disabled regardless of the path we take to reach work_resched() & schedule().
2) Performing the tracing here avoids the need to do it in paths which disable interrupts but don't call out to C code before hitting a path which uses the RESTORE_SOME macro that will call trace_hardirqs_on() or trace_hardirqs_off() as appropriate.
We call trace_hardirqs_on() using the TRACE_IRQS_ON macro before calling syscall_trace_leave() for similar reasons, ensuring that lockdep has a consistent view of state after we re-enable interrupts.
Patchwork: https://patchwork.linux-mips.org/patch/15385/
--- arch/mips/kernel/entry.S | 3 +++ 1 file changed, 3 insertions(+)
arch/mips/kernel/entry.S +3 -0
@@ -11,6 +11,7 @@ #include <asm/asm.h> #include <asm/asmmacro.h> #include <asm/compiler.h> +#include <asm/irqflags.h> #include <asm/regdef.h> #include <asm/mipsregs.h> #include <asm/stackframe.h>
@@ -119,6 +120,7 @@ work_pending: andi t0, a2, _TIF_NEED_RESCHED # a2 is preloaded with TI_FLAGS beqz t0, work_notifysig work_resched: + TRACE_IRQS_OFF jal schedule local_irq_disable # make sure need_resched and
@@ -155,6 +157,7 @@ syscall_exit_work: beqz t0, work_pending # trace bit set? local_irq_enable # could let syscall_trace_leave() # call schedule() instead + TRACE_IRQS_ON move a0, sp jal syscall_trace_leave b resume_userspace
Greg Kroah-Hartman
maintainerPATCH 19/36 ALSA: hda - set input_path bitmap to zero after moving it to new place
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hui Wang <[email protected]>
commit a8f20fd25bdce81a8e41767c39f456d346b63427 upstream.
Recently we met a problem, the codec has valid adcs and input pins, and they can form valid input paths, but the driver does not build valid controls for them like "Mic boost", "Capture Volume" and "Capture Switch".
Through debugging, I found the driver needs to shrink the invalid adcs and input paths for this machine, so it will move the whole column bitmap value to the previous column, after moving it, the driver forgets to set the original column bitmap value to zero, as a result, the driver will invalidate the path whose index value is the original colume bitmap value. After executing this function, all valid input paths are invalidated by a mistake, there are no any valid input paths, so the driver won't build controls for them.
--- sound/pci/hda/hda_generic.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/hda_generic.c +1 -0
@@ -3079,6 +3079,7 @@ static int check_dyn_adc_switch(struct h spec->input_paths[i][nums]); spec->input_paths[i][nums] = spec->input_paths[i][n]; + spec->input_paths[i][n] =0 ; } } nums++;
Greg Kroah-Hartman
maintainerPATCH 20/36 drm/vmwgfx: Free hash table allocated by cmdbuf managed res mgr
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Deepak Rawat <[email protected]>
commit 82fcee526ba8ca2c5d378bdf51b21b7eb058fe3a upstream.
The hash table created during vmw_cmdbuf_res_man_create was never freed. This causes memory leak in context creation. Added the corresponding drm_ht_remove in vmw_cmdbuf_res_man_destroy.
Tested for memory leak by running piglit overnight and kernel memory is not inflated which earlier was.
--- drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c +1 -0
@@ -317,6 +317,7 @@ void vmw_cmdbuf_res_man_destroy(struct vlist_for_each_entry_safe (entry, next, &man->list, head)vmw_cmdbuf_res_free (man, entry); +drm_ht_remove (&man->resources);kfree (man); }
Greg Kroah-Hartman
maintainerPATCH 21/36 usb: gadget: f_fs: Fix possibe deadlock
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Baolin Wang <[email protected]>
commit b3ce3ce02d146841af012d08506b4071db8ffde3 upstream.
When system try to close /dev/usb-ffs/adb/ep0 on one core, at the same time another core try to attach new UDC, which will cause deadlock as below scenario. Thus we should release ffs lock before issuing unregister_gadget_item().
[ 52.642225] c1 ======================================================
[ 52.642228] c1 [ INFO: possible circular locking dependency detected ]
[ 52.642236] c1 4.4.6+ #1 Tainted: G W O
[ 52.642241] c1 -------------------------------------------------------
[ 52.642245] c1 usb ffs open/2808 is trying to acquire lock:
[ 52.642270] c0 (udc_lock){+.+.+.}, at: [<ffffffc00065aeec>]
usb_gadget_unregister_driver+0x3c/0xc8
[ 52.642272] c1 but task is already holding lock:
[ 52.642283] c0 (ffs_lock){+.+.+.}, at: [<ffffffc00066b244>]
ffs_data_clear+0x30/0x140
[ 52.642285] c1 which lock already depends on the new lock.
[ 52.642287] c1
the existing dependency chain (in reverse order) is:
[ 52.642295] c0
-> #1 (ffs_lock){+.+.+.}:
[ 52.642307] c0 [<ffffffc00012340c>] __lock_acquire+0x20f0/0x2238
[ 52.642314] c0 [<ffffffc000123b54>] lock_acquire+0xe4/0x298
[ 52.642322] c0 [<ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc
[ 52.642328] c0 [<ffffffc00066f7bc>] ffs_func_bind+0x504/0x6e8
[ 52.642334] c0 [<ffffffc000654004>] usb_add_function+0x84/0x184
[ 52.642340] c0 [<ffffffc000658ca4>] configfs_composite_bind+0x264/0x39c
[ 52.642346] c0 [<ffffffc00065b348>] udc_bind_to_driver+0x58/0x11c
[ 52.642352] c0 [<ffffffc00065b49c>] usb_udc_attach_driver+0x90/0xc8
[ 52.642358] c0 [<ffffffc0006598e0>] gadget_dev_desc_UDC_store+0xd4/0x128
[ 52.642369] c0 [<ffffffc0002c14e8>] configfs_write_file+0xd0/0x13c
[ 52.642376] c0 [<ffffffc00023c054>] vfs_write+0xb8/0x214
[ 52.642381] c0 [<ffffffc00023cad4>] SyS_write+0x54/0xb0
[ 52.642388] c0 [<ffffffc000085ff0>] el0_svc_naked+0x24/0x28
[ 52.642395] c0
-> #0 (udc_lock){+.+.+.}:
[ 52.642401] c0 [<ffffffc00011e3d0>] print_circular_bug+0x84/0x2e4
[ 52.642407] c0 [<ffffffc000123454>] __lock_acquire+0x2138/0x2238
[ 52.642412] c0 [<ffffffc000123b54>] lock_acquire+0xe4/0x298
[ 52.642420] c0 [<ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc
[ 52.642427] c0 [<ffffffc00065aeec>] usb_gadget_unregister_driver+0x3c/0xc8
[ 52.642432] c0 [<ffffffc00065995c>] unregister_gadget_item+0x28/0x44
[ 52.642439] c0 [<ffffffc00066b34c>] ffs_data_clear+0x138/0x140
[ 52.642444] c0 [<ffffffc00066b374>] ffs_data_reset+0x20/0x6c
[ 52.642450] c0 [<ffffffc00066efd0>] ffs_data_closed+0xac/0x12c
[ 52.642454] c0 [<ffffffc00066f070>] ffs_ep0_release+0x20/0x2c
[ 52.642460] c0 [<ffffffc00023dbe4>] __fput+0xb0/0x1f4
[ 52.642466] c0 [<ffffffc00023dd9c>] ____fput+0x20/0x2c
[ 52.642473] c0 [<ffffffc0000ee944>] task_work_run+0xb4/0xe8
[ 52.642482] c0 [<ffffffc0000cd45c>] do_exit+0x360/0xb9c
[ 52.642487] c0 [<ffffffc0000cf228>] do_group_exit+0x4c/0xb0
[ 52.642494] c0 [<ffffffc0000dd3c8>] get_signal+0x380/0x89c
[ 52.642501] c0 [<ffffffc00008a8f0>] do_signal+0x154/0x518
[ 52.642507] c0 [<ffffffc00008af00>] do_notify_resume+0x70/0x78
[ 52.642512] c0 [<ffffffc000085ee8>] work_pending+0x1c/0x20
[ 52.642514] c1
other info that might help us debug this:
[ 52.642517] c1 Possible unsafe locking scenario:
[ 52.642518] c1 CPU0 CPU1
[ 52.642520] c1 ---- ----
[ 52.642525] c0 lock(ffs_lock);
[ 52.642529] c0 lock(udc_lock);
[ 52.642533] c0 lock(ffs_lock);
[ 52.642537] c0 lock(udc_lock);
[ 52.642539] c1
*** DEADLOCK ***
[ 52.642543] c1 1 lock held by usb ffs open/2808:
[ 52.642555] c0 #0: (ffs_lock){+.+.+.}, at: [<ffffffc00066b244>]
ffs_data_clear+0x30/0x140
[ 52.642557] c1 stack backtrace:
[ 52.642563] c1 CPU: 1 PID: 2808 Comm: usb ffs open Tainted: G
[ 52.642565] c1 Hardware name: Spreadtrum SP9860g Board (DT)
[ 52.642568] c1 Call trace:
[ 52.642573] c1 [<ffffffc00008b430>] dump_backtrace+0x0/0x170
[ 52.642577] c1 [<ffffffc00008b5c0>] show_stack+0x20/0x28
[ 52.642583] c1 [<ffffffc000422694>] dump_stack+0xa8/0xe0
[ 52.642587] c1 [<ffffffc00011e548>] print_circular_bug+0x1fc/0x2e4
[ 52.642591] c1 [<ffffffc000123454>] __lock_acquire+0x2138/0x2238
[ 52.642595] c1 [<ffffffc000123b54>] lock_acquire+0xe4/0x298
[ 52.642599] c1 [<ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc
[ 52.642604] c1 [<ffffffc00065aeec>] usb_gadget_unregister_driver+0x3c/0xc8
[ 52.642608] c1 [<ffffffc00065995c>] unregister_gadget_item+0x28/0x44
[ 52.642613] c1 [<ffffffc00066b34c>] ffs_data_clear+0x138/0x140
[ 52.642618] c1 [<ffffffc00066b374>] ffs_data_reset+0x20/0x6c
[ 52.642621] c1 [<ffffffc00066efd0>] ffs_data_closed+0xac/0x12c
[ 52.642625] c1 [<ffffffc00066f070>] ffs_ep0_release+0x20/0x2c
[ 52.642629] c1 [<ffffffc00023dbe4>] __fput+0xb0/0x1f4
[ 52.642633] c1 [<ffffffc00023dd9c>] ____fput+0x20/0x2c
[ 52.642636] c1 [<ffffffc0000ee944>] task_work_run+0xb4/0xe8
[ 52.642640] c1 [<ffffffc0000cd45c>] do_exit+0x360/0xb9c
[ 52.642644] c1 [<ffffffc0000cf228>] do_group_exit+0x4c/0xb0
[ 52.642647] c1 [<ffffffc0000dd3c8>] get_signal+0x380/0x89c
[ 52.642651] c1 [<ffffffc00008a8f0>] do_signal+0x154/0x518
[ 52.642656] c1 [<ffffffc00008af00>] do_notify_resume+0x70/0x78
[ 52.642659] c1 [<ffffffc000085ee8>] work_pending+0x1c/0x20--- drivers/usb/gadget/function/f_fs.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/usb/gadget/function/f_fs.c +6 -2
@@ -3412,6 +3412,7 @@ static void ffs_closed(struct ffs_data * {struct ffs_dev *ffs_obj;struct f_fs_opts *opts; +struct config_item *ci;ENTER ();ffs_dev_lock ();
@@ -3434,8 +3435,11 @@ static void ffs_closed(struct ffs_data * || !atomic_read(&opts->func_inst.group.cg_item.ci_kref.refcount)) goto done; -unregister_gadget_item (ffs_obj->opts-> - func_inst.group.cg_item.ci_parent->ci_parent); + ci = opts->func_inst.group.cg_item.ci_parent->ci_parent; +ffs_dev_unlock (); + +unregister_gadget_item (ci); +return ; done:ffs_dev_unlock (); }
Greg Kroah-Hartman
maintainerPATCH 22/36 sysctl: enable strict writes
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <[email protected]>
commit 41662f5cc55335807d39404371cfcbb1909304c4 upstream.
SYSCTL_WRITES_WARN was added in commit f4aacea2f5d1 ("sysctl: allow for strict write position handling"), and released in v3.16 in August of 2014. Since then I can find only 1 instance of non-zero offset writing[1], and it was fixed immediately in CRIU[2]. As such, it appears safe to flip this to the strict state now.
[1] https://www.google.com/search?q="when%20file%20position%20was%20not%200"
[2] http://lists.openvz.org/pipermail/criu/2015-April/019819.html
--- Documentation/sysctl/kernel.txt | 15 +++++++-------- kernel/sysctl.c | 2 +- 2 files changed, 8 insertions(+), 9 deletions(-)
Documentation/sysctl/kernel.txt +7 -8
@@ -775,14 +775,13 @@ via the /proc/sys interface: Each write syscall must fully contain the sysctl value to be written, and multiple writes on the same sysctl file descriptor will rewrite the sysctl value, regardless of file position. - 0 - (default) Same behavior as above, but warn about processes that - perform writes to a sysctl file descriptor when the file position - is not 0. - 1 - Respect file position when writing sysctl strings. Multiple writes - will append to the sysctl value buffer. Anything past the max length - of the sysctl value buffer will be ignored. Writes to numeric sysctl - entries must always be at file position 0 and the value must be - fully contained in the buffer sent in the write syscall. + 0 - Same behavior as above, but warn about processes that perform writes + to a sysctl file descriptor when the file position is not 0. + 1 - (default) Respect file position when writing sysctl strings. Multiple + writes will append to the sysctl value buffer. Anything past the max + length of the sysctl value buffer will be ignored. Writes to numeric + sysctl entries must always be at file position 0 and the value must + be fully contained in the buffer sent in the write syscall. ==============================================================
kernel/sysctl.c +1 -1
@@ -173,7 +173,7 @@ extern int no_unaligned_warning;#define SYSCTL_WRITES_WARN 0#define SYSCTL_WRITES_STRICT 1 -static int sysctl_writes_strict =SYSCTL_WRITES_WARN ; +static int sysctl_writes_strict =SYSCTL_WRITES_STRICT ;static int proc_do_cad_pid (struct ctl_table *table,int write,void __user *buffer,size_t *lenp,loff_t *ppos);
Greg Kroah-Hartman
maintainerPATCH 23/36 mm: numa: avoid waiting on freed migrated pages
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <[email protected]>
commit 3c226c637b69104f6b9f1c6ec5b08d7b741b3229 upstream.
In do_huge_pmd_numa_page(), we attempt to handle a migrating thp pmd by waiting until the pmd is unlocked before we return and retry. However, we can race with migrate_misplaced_transhuge_page():
// do_huge_pmd_numa_page // migrate_misplaced_transhuge_page()
// Holds 0 refs on page // Holds 2 refs on page
vmf->ptl = pmd_lock(vma->vm_mm, vmf->pmd);
/* ... */
if (pmd_trans_migrating(*vmf->pmd)) {
page = pmd_page(*vmf->pmd);
spin_unlock(vmf->ptl);
ptl = pmd_lock(mm, pmd);
if (page_count(page) != 2)) {
/* roll back */
}
/* ... */
mlock_migrate_page(new_page, page);
/* ... */
spin_unlock(ptl);
put_page(page);
put_page(page); // page freed here
wait_on_page_locked(page);
goto out;
}This can result in the freed page having its waiters flag set unexpectedly, which trips the PAGE_FLAGS_CHECK_AT_PREP checks in the page alloc/free functions. This has been observed on arm64 KVM guests.
We can avoid this by having do_huge_pmd_numa_page() take a reference on the page before dropping the pmd lock, mirroring what we do in __migration_entry_wait().
When we hit the race, migrate_misplaced_transhuge_page() will see the reference and abort the migration, as it may do today in other cases.
--- mm/huge_memory.c | 7 +++++++ 1 file changed, 7 insertions(+)
mm/huge_memory.c +7 -0
@@ -1294,8 +1294,12 @@ int do_huge_pmd_numa_page(struct mm_stru* check_same as the page may no longer be mapped. */ if (unlikely (pmd_trans_migrating (*pmdp))) { + page =pmd_page (*pmdp); +if (!get_page_unless_zero (page)) + goto out_unlock;spin_unlock (ptl);wait_migrate_huge_page (vma->anon_vma, pmdp); +put_page (page); goto out; }
@@ -1331,8 +1335,11 @@ int do_huge_pmd_numa_page(struct mm_stru/* Migration could have started since the pmd_trans_migrating check */ if (!page_locked) { +if (!get_page_unless_zero (page)) + goto out_unlock;spin_unlock (ptl);wait_on_page_locked (page); +put_page (page); page_nid =-1 ; goto out; }
Greg Kroah-Hartman
maintainerPATCH 25/36 net: korina: Fix NAPI versus resources freeing
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Fainelli <[email protected]>
commit e6afb1ad88feddf2347ea779cfaf4d03d3cd40b6 upstream.
Commit beb0babfb77e ("korina: disable napi on close and restart") introduced calls to napi_disable() that were missing before, unfortunately this leaves a small window during which NAPI has a chance to run, yet we just freed resources since korina_free_ring() has been called:
Fix this by disabling NAPI first then freeing resource, and make sure that we also cancel the restart task before doing the resource freeing.
--- drivers/net/ethernet/korina.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/net/ethernet/korina.c +4 -4
@@ -900,10 +900,10 @@ static void korina_restart_task(struct wDMA_STAT_DONE |DMA_STAT_HALT |DMA_STAT_ERR , &lp->rx_dma_regs->dmasm); -korina_free_ring (dev); -napi_disable (&lp->napi); +korina_free_ring (dev); +if (korina_init (dev) <0 ) {printk (KERN_ERR "%s: cannot restart device\n" , dev->name);return ;
@@ -1064,12 +1064,12 @@ static int korina_close(struct net_devic tmp = tmp |DMA_STAT_DONE |DMA_STAT_HALT |DMA_STAT_ERR ;writel (tmp, &lp->rx_dma_regs->dmasm); -korina_free_ring (dev); -napi_disable (&lp->napi);cancel_work_sync (&lp->restart_task); +korina_free_ring (dev); +free_irq (lp->rx_irq, dev);free_irq (lp->tx_irq, dev);free_irq (lp->ovr_irq, dev);
Greg Kroah-Hartman
maintainerPATCH 27/36 xfrm: fix stack access out of bounds with CONFIG_XFRM_SUB_POLICY
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sabrina Dubroca <[email protected]>
commit 9b3eb54106cf6acd03f07cf0ab01c13676a226c2 upstream.
When CONFIG_XFRM_SUB_POLICY=y, xfrm_dst stores a copy of the flowi for that dst. Unfortunately, the code that allocates and fills this copy doesn't care about what type of flowi (flowi, flowi4, flowi6) gets passed. In multiple code paths (from raw_sendmsg, from TCP when replying to a FIN, in vxlan, geneve, and gre), the flowi that gets passed to xfrm is actually an on-stack flowi4, so we end up reading stuff from the stack past the end of the flowi4 struct.
Since xfrm_dst->origin isn't used anywhere following commit ca116922afa8 ("xfrm: Eliminate "fl" and "pol" args to xfrm_bundle_ok()."), just get rid of it. xfrm_dst->partner isn't used either, so get rid of that too.
--- include/net/xfrm.h | 10 ---------- net/xfrm/xfrm_policy.c | 47 ----------------------------------------------- 2 files changed, 57 deletions(-)
include/net/xfrm.h +0 -10
@@ -949,10 +949,6 @@ struct xfrm_dst {struct flow_cache_object flo;struct xfrm_policy *pols[XFRM_POLICY_TYPE_MAX ];int num_pols, num_xfrms; -#ifdef CONFIG_XFRM_SUB_POLICY -struct flowi *origin; -struct xfrm_selector *partner; -#endif u32 xfrm_genid;u32 policy_genid;u32 route_mtu_cached;
@@ -968,12 +964,6 @@ static inline void xfrm_dst_destroy(strudst_release (xdst->route);if (likely (xdst->u.dst.xfrm)) xfrm_state_put(xdst->u.dst.xfrm); -#ifdef CONFIG_XFRM_SUB_POLICY -kfree (xdst->origin); - xdst->origin =NULL ; -kfree (xdst->partner); - xdst->partner =NULL ; -#endif }#endif
net/xfrm/xfrm_policy.c +0 -47
59 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 28/36 xfrm: NULL dereference on allocation failure
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
commit e747f64336fc15e1c823344942923195b800aa1e upstream.
The default error code in pfkey_msg2xfrm_state() is -ENOBUFS. We added a new call to security_xfrm_state_alloc() which sets "err" to zero so there several places where we can return ERR_PTR(0) if kmalloc() fails. The caller is expecting error pointers so it leads to a NULL dereference.
--- net/key/af_key.c | 1 + 1 file changed, 1 insertion(+)
net/key/af_key.c +1 -0
@@ -1135,6 +1135,7 @@ static struct xfrm_state * pfkey_msg2xfr goto out; } + err = -ENOBUFS ; key = ext_hdrs[SADB_EXT_KEY_AUTH -1 ];if (sa->sadb_sa_auth) {int keysize =0 ;
Greg Kroah-Hartman
maintainerPATCH 29/36 xfrm: Oops on error in pfkey_msg2xfrm_state()
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
commit 1e3d0c2c70cd3edb5deed186c5f5c75f2b84a633 upstream.
There are some missing error codes here so we accidentally return NULL instead of an error pointer. It results in a NULL pointer dereference.
--- net/key/af_key.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-)
net/key/af_key.c +12 -4
@@ -1147,8 +1147,10 @@ static struct xfrm_state * pfkey_msg2xfrif (key) keysize = (key->sadb_key_bits +7 ) /8 ; x->aalg =kmalloc (sizeof (*x->aalg) + keysize,GFP_KERNEL ); -if (!x->aalg) +if (!x->aalg) { + err = -ENOMEM ; goto out; + }strcpy (x->aalg->alg_name, a->name); x->aalg->alg_key_len =0 ;if (key) {
@@ -1167,8 +1169,10 @@ static struct xfrm_state * pfkey_msg2xfr goto out; } x->calg =kmalloc (sizeof (*x->calg),GFP_KERNEL ); -if (!x->calg) +if (!x->calg) { + err = -ENOMEM ; goto out; + }strcpy (x->calg->alg_name, a->name); x->props.calgo = sa->sadb_sa_encrypt; }else {
@@ -1182,8 +1186,10 @@ static struct xfrm_state * pfkey_msg2xfrif (key) keysize = (key->sadb_key_bits +7 ) /8 ; x->ealg =kmalloc (sizeof (*x->ealg) + keysize,GFP_KERNEL ); -if (!x->ealg) +if (!x->ealg) { + err = -ENOMEM ; goto out; + }strcpy (x->ealg->alg_name, a->name); x->ealg->alg_key_len =0 ;if (key) {
@@ -1227,8 +1233,10 @@ static struct xfrm_state * pfkey_msg2xfrstruct xfrm_encap_tmpl *natt; x->encap =kmalloc (sizeof (*x->encap),GFP_KERNEL ); -if (!x->encap) +if (!x->encap) { + err = -ENOMEM ; goto out; + } natt = x->encap; n_type = ext_hdrs[SADB_X_EXT_NAT_T_TYPE -1 ];
Greg Kroah-Hartman
maintainerPATCH 30/36 watchdog: bcm281xx: Fix use of uninitialized spinlock.
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Anholt <[email protected]>
commit fedf266f9955d9a019643cde199a2fd9a0259f6f upstream.
The bcm_kona_wdt_set_resolution_reg() call takes the spinlock, so initialize it earlier. Fixes a warning at boot with lock debugging enabled.
--- drivers/watchdog/bcm_kona_wdt.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/watchdog/bcm_kona_wdt.c +2 -1
@@ -299,6 +299,8 @@ static int bcm_kona_wdt_probe(struct plaif (!wdt)return -ENOMEM ; +spin_lock_init (&wdt->lock); + res =platform_get_resource (pdev,IORESOURCE_MEM ,0 ); wdt->base =devm_ioremap_resource (dev, res);if (IS_ERR (wdt->base))
@@ -311,7 +313,6 @@ static int bcm_kona_wdt_probe(struct plareturn ret; } -spin_lock_init (&wdt->lock);platform_set_drvdata (pdev, wdt);watchdog_set_drvdata (&bcm_kona_wdt_wdd, wdt);
Greg Kroah-Hartman
maintainerPATCH 31/36 ARM: 8685/1: ensure memblock-limit is pmd-aligned
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Doug Berger <[email protected]>
commit 9e25ebfe56ece7541cd10a20d715cbdd148a2e06 upstream.
The pmd containing memblock_limit is cleared by prepare_page_table() which creates the opportunity for early_alloc() to allocate unmapped memory if memblock_limit is not pmd aligned causing a boot-time hang.
Commit 965278dcb8ab ("ARM: 8356/1: mm: handle non-pmd-aligned end of RAM") attempted to resolve this problem, but there is a path through the adjust_lowmem_bounds() routine where if all memory regions start and end on pmd-aligned addresses the memblock_limit will be set to arm_lowmem_limit.
Since arm_lowmem_limit can be affected by the vmalloc early parameter, the value of arm_lowmem_limit may not be pmd-aligned. This commit corrects this oversight such that memblock_limit is always rounded down to pmd-alignment.
--- arch/arm/mm/mmu.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
arch/arm/mm/mmu.c +4 -4
@@ -1142,15 +1142,15 @@ void __init sanity_check_meminfo(void) high_memory =__va (arm_lowmem_limit -1 ) +1 ; +if (!memblock_limit) + memblock_limit = arm_lowmem_limit; +/* * Round the memblock limit down to a pmd size. This * helps to ensure that we will allocate memory from the * last full pmd, which should be mapped. */ -if (memblock_limit) - memblock_limit =round_down (memblock_limit,PMD_SIZE ); -if (!memblock_limit) - memblock_limit = arm_lowmem_limit; + memblock_limit =round_down (memblock_limit,PMD_SIZE );memblock_set_current_limit (memblock_limit); }
Greg Kroah-Hartman
maintainerPATCH 32/36 iommu/vt-d: Dont over-free page table directories
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Dillow <[email protected]>
commit f7116e115acdd74bc75a4daf6492b11d43505125 upstream.
dma_pte_free_level() recurses down the IOMMU page tables and frees directory pages that are entirely contained in the given PFN range. Unfortunately, it incorrectly calculates the starting address covered by the PTE under consideration, which can lead to it clearing an entry that is still in use.
This occurs if we have a scatterlist with an entry that has a length greater than 1026 MB and is aligned to 2 MB for both the IOMMU and physical addresses. For example, if __domain_mapping() is asked to map a two-entry scatterlist with 2 MB and 1028 MB segments to PFN 0xffff80000, it will ask if dma_pte_free_pagetable() is asked to PFNs from 0xffff80200 to 0xffffc05ff, it will also incorrectly clear the PFNs from 0xffff80000 to 0xffff801ff because of this issue. The current code will set level_pfn to 0xffff80200, and 0xffff80200-0xffffc01ff fits inside the range being cleared. Properly setting the level_pfn for the current level under consideration catches that this PTE is outside of the range being cleared.
This patch also changes the value passed into dma_pte_free_level() when it recurses. This only affects the first PTE of the range being cleared, and is handled by the existing code that ensures we start our cursor no lower than start_pfn.
This was found when using dma_map_sg() to map large chunks of contiguous memory, which immediatedly led to faults on the first access of the erroneously-deleted mappings.
--- drivers/iommu/intel-iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iommu/intel-iommu.c +1 -1
@@ -980,7 +980,7 @@ static void dma_pte_free_level(struct dmif (!dma_pte_present (pte) ||dma_pte_superpage (pte)) goto next; - level_pfn = pfn &level_mask (level -1 ); + level_pfn = pfn &level_mask (level); level_pte =phys_to_virt (dma_pte_addr (pte));if (level >2 )
Greg Kroah-Hartman
maintainerPATCH 33/36 iommu/amd: Fix incorrect error handling in amd_iommu_bind_pasid()
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pan Bian <[email protected]>
commit 73dbd4a4230216b6a5540a362edceae0c9b4876b upstream.
In function amd_iommu_bind_pasid(), the control flow jumps to label out_free when pasid_state->mm and mm is NULL. And mmput(mm) is called. In function mmput(mm), mm is referenced without validation. This will result in a NULL dereference bug. This patch fixes the bug.
--- drivers/iommu/amd_iommu_v2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iommu/amd_iommu_v2.c +1 -1
@@ -701,9 +701,9 @@ out_clear_state: out_unregister:mmu_notifier_unregister (&pasid_state->mn, mm); +mmput (mm); out_free: -mmput (mm);free_pasid_state (pasid_state); out:
Greg Kroah-Hartman
maintainerPATCH 34/36 cpufreq: s3c2416: double free on driver init error path
In reply to Greg Kroah-Hartman3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
commit a69261e4470d680185a15f748d9cdafb37c57a33 upstream.
The "goto err_armclk;" error path already does a clk_put(s3c_freq->hclk); so this is a double free.
--- drivers/cpufreq/s3c2416-cpufreq.c | 1 - 1 file changed, 1 deletion(-)
drivers/cpufreq/s3c2416-cpufreq.c +0 -1
@@ -400,7 +400,6 @@ static int s3c2416_cpufreq_driver_init(s rate =clk_get_rate (s3c_freq->hclk);if (rate <133 *1000 *1000 ) {pr_err ("cpufreq: HCLK not at 133MHz\n" ); -clk_put (s3c_freq->hclk); ret = -EINVAL ; goto err_armclk; }
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.18.60 release. There are 36 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 Wed Jul 5 13:32:35 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