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

[Linux-stable-mirror] Patch "flow_dissector: properly cap thoff field" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled flow_dissector: properly cap thoff field to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: flow_dissector-properly-cap-thoff-field.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Jan 29 10:14:57 CET 2018 From: Eric Dumazet <edumazet(a)google.com> Date: Wed, 17 Jan 2018 14:21:13 -0800 Subject: flow_dissector: properly cap thoff field From: Eric Dumazet <edumazet(a)google.com> [ Upstream commit d0c081b49137cd3200f2023c0875723be66e7ce5 ] syzbot reported yet another crash [1] that is caused by insufficient validation of DODGY packets. Two bugs are happening here to trigger the crash. 1) Flow dissection leaves with incorrect thoff field. 2) skb_probe_transport_header() sets transport header to this invalid thoff, even if pointing after skb valid data. 3) qdisc_pkt_len_init() reads out-of-bound data because it trusts tcp_hdrlen(skb) Possible fixes : - Full flow dissector validation before injecting bad DODGY packets in the stack. This approach was attempted here : https://patchwork.ozlabs.org/patch/ 861874/ - Have more robust functions in the core. This might be needed anyway for stable versions. This patch fixes the flow dissection issue. [1] CPU: 1 PID: 3144 Comm: syzkaller271204 Not tainted 4.15.0-rc4-mm1+ #49 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:53 print_address_description+0x73/0x250 mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:355 [inline] kasan_report+0x23b/0x360 mm/kasan/report.c:413 __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:432 __tcp_hdrlen include/linux/tcp.h:35 [inline] tcp_hdrlen include/linux/tcp.h:40 [inline] qdisc_pkt_len_init net/core/dev.c:3160 [inline] __dev_queue_xmit+0x20d3/0x2200 net/core/dev.c:3465 dev_queue_xmit+0x17/0x20 net/core/dev.c:3554 packet_snd net/packet/af_packet.c:2943 [inline] packet_sendmsg+0x3ad5/0x60a0 net/packet/af_packet.c:2968 sock_sendmsg_nosec net/socket.c:628 [inline] sock_sendmsg+0xca/0x110 net/socket.c:638 sock_write_iter+0x31a/0x5d0 net/socket.c:907 call_write_iter include/linux/fs.h:1776 [inline] new_sync_write fs/read_write.c:469 [inline] __vfs_write+0x684/0x970 fs/read_write.c:482 vfs_write+0x189/0x510 fs/read_write.c:544 SYSC_write fs/read_write.c:589 [inline] SyS_write+0xef/0x220 fs/read_write.c:581 entry_SYSCALL_64_fastpath+0x1f/0x96 Fixes: 34fad54c2537 ("net: __skb_flow_dissect() must cap its return value") Fixes: a6e544b0a88b ("flow_dissector: Jump to exit code in __skb_flow_dissect") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: Willem de Bruijn <willemb(a)google.com> Reported-by: syzbot <syzkaller(a)googlegroups.com> Acked-by: Jason Wang <jasowang(a)redhat.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/core/flow_dissector.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/net/core/flow_dissector.c +++ b/net/core/flow_dissector.c @@ -492,8 +492,8 @@ ip_proto_again: out_good: ret = true; - key_control->thoff = (u16)nhoff; out: + key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen); key_basic->n_proto = proto; key_basic->ip_proto = ip_proto; @@ -501,7 +501,6 @@ out: out_bad: ret = false; - key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen); goto out; } EXPORT_SYMBOL(__skb_flow_dissect); Patches currently in stable-queue which might be from edumazet(a)google.com are queue-4.4/ipv6-fix-udpv6-sendmsg-crash-caused-by-too-small-mtu.patch queue-4.4/flow_dissector-properly-cap-thoff-field.patch queue-4.4/ipv6-ip6_make_skb-needs-to-clear-cork.base.dst.patch queue-4.4/dccp-don-t-restart-ccid2_hc_tx_rto_expire-if-sk-in-closed-state.patch queue-4.4/netfilter-restart-search-if-moved-to-other-chain.patch queue-4.4/net-qdisc_pkt_len_init-should-be-more-robust.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "dccp: don't restart ccid2_hc_tx_rto_expire() if sk in closed state" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dccp: don't restart ccid2_hc_tx_rto_expire() if sk in closed state to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dccp-don-t-restart-ccid2_hc_tx_rto_expire-if-sk-in-closed-state.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Jan 29 10:14:57 CET 2018 From: Alexey Kodanev <alexey.kodanev(a)oracle.com> Date: Fri, 26 Jan 2018 15:14:16 +0300 Subject: dccp: don't restart ccid2_hc_tx_rto_expire() if sk in closed state From: Alexey Kodanev <alexey.kodanev(a)oracle.com> [ Upstream commit dd5684ecae3bd8e44b644f50e2c12c7e57fdfef5 ] ccid2_hc_tx_rto_expire() timer callback always restarts the timer again and can run indefinitely (unless it is stopped outside), and after commit 120e9dabaf55 ("dccp: defer ccid_hc_tx_delete() at dismantle time"), which moved ccid_hc_tx_delete() (also includes sk_stop_timer()) from dccp_destroy_sock() to sk_destruct(), this started to happen quite often. The timer prevents releasing the socket, as a result, sk_destruct() won't be called. Found with LTP/dccp_ipsec tests running on the bonding device, which later couldn't be unloaded after the tests were completed: unregister_netdevice: waiting for bond0 to become free. Usage count = 148 Fixes: 2a91aa396739 ("[DCCP] CCID2: Initial CCID2 (TCP-Like) implementation") Signed-off-by: Alexey Kodanev <alexey.kodanev(a)oracle.com> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/dccp/ccids/ccid2.c | 3 +++ 1 file changed, 3 insertions(+) --- a/net/dccp/ccids/ccid2.c +++ b/net/dccp/ccids/ccid2.c @@ -140,6 +140,9 @@ static void ccid2_hc_tx_rto_expire(unsig ccid2_pr_debug("RTO_EXPIRE\n"); + if (sk->sk_state == DCCP_CLOSED) + goto out; + /* back-off timer */ hc->tx_rto <<= 1; if (hc->tx_rto > DCCP_RTO_MAX) Patches currently in stable-queue which might be from alexey.kodanev(a)oracle.com are queue-4.4/dccp-don-t-restart-ccid2_hc_tx_rto_expire-if-sk-in-closed-state.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/microcode/intel: Extend BDW late-loading further with LLC size check" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/microcode/intel: Extend BDW late-loading further with LLC size check to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-microcode-intel-extend-bdw-late-loading-further-with-llc-size-check.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 7e702d17ed138cf4ae7c00e8c00681ed464587c7 Mon Sep 17 00:00:00 2001 From: Jia Zhang <zhang.jia(a)linux.alibaba.com> Date: Tue, 23 Jan 2018 11:41:32 +0100 Subject: x86/microcode/intel: Extend BDW late-loading further with LLC size check From: Jia Zhang <zhang.jia(a)linux.alibaba.com> commit 7e702d17ed138cf4ae7c00e8c00681ed464587c7 upstream. Commit b94b73733171 ("x86/microcode/intel: Extend BDW late-loading with a revision check") reduced the impact of erratum BDF90 for Broadwell model 79. The impact can be reduced further by checking the size of the last level cache portion per core. Tony: "The erratum says the problem only occurs on the large-cache SKUs. So we only need to avoid the update if we are on a big cache SKU that is also running old microcode." For more details, see erratum BDF90 in document #334165 (Intel Xeon Processor E7-8800/4800 v4 Product Family Specification Update) from September 2017. Fixes: b94b73733171 ("x86/microcode/intel: Extend BDW late-loading with a revision check") Signed-off-by: Jia Zhang <zhang.jia(a)linux.alibaba.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Acked-by: Tony Luck <tony.luck(a)intel.com> Link: https://lkml.kernel.org/r/1516321542-31161-1-git-send-email-zhang.jia@linux… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/cpu/microcode/intel.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) --- a/arch/x86/kernel/cpu/microcode/intel.c +++ b/arch/x86/kernel/cpu/microcode/intel.c @@ -40,6 +40,9 @@ #include <asm/setup.h> #include <asm/msr.h> +/* last level cache size per core */ +static int llc_size_per_core; + /* * Temporary microcode blobs pointers storage. We note here during early load * the pointers to microcode blobs we've got from whatever storage (detached @@ -1053,12 +1056,14 @@ static bool is_blacklisted(unsigned int /* * Late loading on model 79 with microcode revision less than 0x0b000021 - * may result in a system hang. This behavior is documented in item - * BDF90, #334165 (Intel Xeon Processor E7-8800/4800 v4 Product Family). + * and LLC size per core bigger than 2.5MB may result in a system hang. + * This behavior is documented in item BDF90, #334165 (Intel Xeon + * Processor E7-8800/4800 v4 Product Family). */ if (c->x86 == 6 && c->x86_model == INTEL_FAM6_BROADWELL_X && c->x86_mask == 0x01 && + llc_size_per_core > 2621440 && c->microcode < 0x0b000021) { pr_err_once("Erratum BDF90: late loading with revision < 0x0b000021 (0x%x) disabled.\n", c->microcode); pr_err_once("Please consider either early loading through initrd/built-in or a potential BIOS update.\n"); @@ -1125,6 +1130,15 @@ static struct microcode_ops microcode_in .microcode_fini_cpu = microcode_fini_cpu, }; +static int __init calc_llc_size_per_core(struct cpuinfo_x86 *c) +{ + u64 llc_size = c->x86_cache_size * 1024; + + do_div(llc_size, c->x86_max_cores); + + return (int)llc_size; +} + struct microcode_ops * __init init_intel_microcode(void) { struct cpuinfo_x86 *c = &boot_cpu_data; @@ -1135,6 +1149,8 @@ struct microcode_ops * __init init_intel return NULL; } + llc_size_per_core = calc_llc_size_per_core(c); + return &microcode_intel_ops; } Patches currently in stable-queue which might be from zhang.jia(a)linux.alibaba.com are queue-4.9/x86-microcode-intel-extend-bdw-late-loading-further-with-llc-size-check.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "perf/x86/amd/power: Do not load AMD power module on !AMD platforms" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf/x86/amd/power: Do not load AMD power module on !AMD platforms to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: perf-x86-amd-power-do-not-load-amd-power-module-on-amd-platforms.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 40d4071ce2d20840d224b4a77b5dc6f752c9ab15 Mon Sep 17 00:00:00 2001 From: Xiao Liang <xiliang(a)redhat.com> Date: Mon, 22 Jan 2018 14:12:52 +0800 Subject: perf/x86/amd/power: Do not load AMD power module on !AMD platforms From: Xiao Liang <xiliang(a)redhat.com> commit 40d4071ce2d20840d224b4a77b5dc6f752c9ab15 upstream. The AMD power module can be loaded on non AMD platforms, but unload fails with the following Oops: BUG: unable to handle kernel NULL pointer dereference at (null) IP: __list_del_entry_valid+0x29/0x90 Call Trace: perf_pmu_unregister+0x25/0xf0 amd_power_pmu_exit+0x1c/0xd23 [power] SyS_delete_module+0x1a8/0x2b0 ? exit_to_usermode_loop+0x8f/0xb0 entry_SYSCALL_64_fastpath+0x20/0x83 Return -ENODEV instead of 0 from the module init function if the CPU does not match. Fixes: c7ab62bfbe0e ("perf/x86/amd/power: Add AMD accumulated power reporting mechanism") Signed-off-by: Xiao Liang <xiliang(a)redhat.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Link: https://lkml.kernel.org/r/20180122061252.6394-1-xiliang@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/events/amd/power.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/events/amd/power.c +++ b/arch/x86/events/amd/power.c @@ -277,7 +277,7 @@ static int __init amd_power_pmu_init(voi int ret; if (!x86_match_cpu(cpu_match)) - return 0; + return -ENODEV; if (!boot_cpu_has(X86_FEATURE_ACC_POWER)) return -ENODEV; Patches currently in stable-queue which might be from xiliang(a)redhat.com are queue-4.9/perf-x86-amd-power-do-not-load-amd-power-module-on-amd-platforms.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "hrtimer: Reset hrtimer cpu base proper on CPU hotplug" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled hrtimer: Reset hrtimer cpu base proper on CPU hotplug to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: hrtimer-reset-hrtimer-cpu-base-proper-on-cpu-hotplug.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d5421ea43d30701e03cadc56a38854c36a8b4433 Mon Sep 17 00:00:00 2001 From: Thomas Gleixner <tglx(a)linutronix.de> Date: Fri, 26 Jan 2018 14:54:32 +0100 Subject: hrtimer: Reset hrtimer cpu base proper on CPU hotplug From: Thomas Gleixner <tglx(a)linutronix.de> commit d5421ea43d30701e03cadc56a38854c36a8b4433 upstream. The hrtimer interrupt code contains a hang detection and mitigation mechanism, which prevents that a long delayed hrtimer interrupt causes a continous retriggering of interrupts which prevent the system from making progress. If a hang is detected then the timer hardware is programmed with a certain delay into the future and a flag is set in the hrtimer cpu base which prevents newly enqueued timers from reprogramming the timer hardware prior to the chosen delay. The subsequent hrtimer interrupt after the delay clears the flag and resumes normal operation. If such a hang happens in the last hrtimer interrupt before a CPU is unplugged then the hang_detected flag is set and stays that way when the CPU is plugged in again. At that point the timer hardware is not armed and it cannot be armed because the hang_detected flag is still active, so nothing clears that flag. As a consequence the CPU does not receive hrtimer interrupts and no timers expire on that CPU which results in RCU stalls and other malfunctions. Clear the flag along with some other less critical members of the hrtimer cpu base to ensure starting from a clean state when a CPU is plugged in. Thanks to Paul, Sebastian and Anna-Maria for their help to get down to the root cause of that hard to reproduce heisenbug. Once understood it's trivial and certainly justifies a brown paperbag. Fixes: 41d2e4949377 ("hrtimer: Tune hrtimer_interrupt hang logic") Reported-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Sebastian Sewior <bigeasy(a)linutronix.de> Cc: Anna-Maria Gleixner <anna-maria(a)linutronix.de> Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801261447590.2067@nanos Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/time/hrtimer.c | 3 +++ 1 file changed, 3 insertions(+) --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -652,7 +652,9 @@ static void hrtimer_reprogram(struct hrt static inline void hrtimer_init_hres(struct hrtimer_cpu_base *base) { base->expires_next.tv64 = KTIME_MAX; + base->hang_detected = 0; base->hres_active = 0; + base->next_timer = NULL; } /* @@ -1610,6 +1612,7 @@ int hrtimers_prepare_cpu(unsigned int cp timerqueue_init_head(&cpu_base->clock_base[i].active); } + cpu_base->active_bases = 0; cpu_base->cpu = cpu; hrtimer_init_hres(cpu_base); return 0; Patches currently in stable-queue which might be from tglx(a)linutronix.de are queue-4.9/prevent-timer-value-0-for-mwaitx.patch queue-4.9/perf-x86-amd-power-do-not-load-amd-power-module-on-amd-platforms.patch queue-4.9/x86-asm-32-make-sync_core-handle-missing-cpuid-on-all-32-bit-kernels.patch queue-4.9/revert-module-add-retpoline-tag-to-vermagic.patch queue-4.9/x86-microcode-intel-extend-bdw-late-loading-further-with-llc-size-check.patch queue-4.9/hrtimer-reset-hrtimer-cpu-base-proper-on-cpu-hotplug.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/microcode/intel: Extend BDW late-loading further with LLC size check" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/microcode/intel: Extend BDW late-loading further with LLC size check to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-microcode-intel-extend-bdw-late-loading-further-with-llc-size-check.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 7e702d17ed138cf4ae7c00e8c00681ed464587c7 Mon Sep 17 00:00:00 2001 From: Jia Zhang <zhang.jia(a)linux.alibaba.com> Date: Tue, 23 Jan 2018 11:41:32 +0100 Subject: x86/microcode/intel: Extend BDW late-loading further with LLC size check From: Jia Zhang <zhang.jia(a)linux.alibaba.com> commit 7e702d17ed138cf4ae7c00e8c00681ed464587c7 upstream. Commit b94b73733171 ("x86/microcode/intel: Extend BDW late-loading with a revision check") reduced the impact of erratum BDF90 for Broadwell model 79. The impact can be reduced further by checking the size of the last level cache portion per core. Tony: "The erratum says the problem only occurs on the large-cache SKUs. So we only need to avoid the update if we are on a big cache SKU that is also running old microcode." For more details, see erratum BDF90 in document #334165 (Intel Xeon Processor E7-8800/4800 v4 Product Family Specification Update) from September 2017. Fixes: b94b73733171 ("x86/microcode/intel: Extend BDW late-loading with a revision check") Signed-off-by: Jia Zhang <zhang.jia(a)linux.alibaba.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Acked-by: Tony Luck <tony.luck(a)intel.com> Link: https://lkml.kernel.org/r/1516321542-31161-1-git-send-email-zhang.jia@linux… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/cpu/microcode/intel.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) --- a/arch/x86/kernel/cpu/microcode/intel.c +++ b/arch/x86/kernel/cpu/microcode/intel.c @@ -39,6 +39,9 @@ #include <asm/setup.h> #include <asm/msr.h> +/* last level cache size per core */ +static int llc_size_per_core; + static unsigned long mc_saved_in_initrd[MAX_UCODE_COUNT]; static struct mc_saved_data { unsigned int mc_saved_count; @@ -996,12 +999,14 @@ static bool is_blacklisted(unsigned int /* * Late loading on model 79 with microcode revision less than 0x0b000021 - * may result in a system hang. This behavior is documented in item - * BDF90, #334165 (Intel Xeon Processor E7-8800/4800 v4 Product Family). + * and LLC size per core bigger than 2.5MB may result in a system hang. + * This behavior is documented in item BDF90, #334165 (Intel Xeon + * Processor E7-8800/4800 v4 Product Family). */ if (c->x86 == 6 && c->x86_model == 79 && c->x86_mask == 0x01 && + llc_size_per_core > 2621440 && c->microcode < 0x0b000021) { pr_err_once("Erratum BDF90: late loading with revision < 0x0b000021 (0x%x) disabled.\n", c->microcode); pr_err_once("Please consider either early loading through initrd/built-in or a potential BIOS update.\n"); @@ -1068,6 +1073,15 @@ static struct microcode_ops microcode_in .microcode_fini_cpu = microcode_fini_cpu, }; +static int __init calc_llc_size_per_core(struct cpuinfo_x86 *c) +{ + u64 llc_size = c->x86_cache_size * 1024; + + do_div(llc_size, c->x86_max_cores); + + return (int)llc_size; +} + struct microcode_ops * __init init_intel_microcode(void) { struct cpuinfo_x86 *c = &boot_cpu_data; @@ -1078,6 +1092,8 @@ struct microcode_ops * __init init_intel return NULL; } + llc_size_per_core = calc_llc_size_per_core(c); + return &microcode_intel_ops; } Patches currently in stable-queue which might be from zhang.jia(a)linux.alibaba.com are queue-4.4/x86-microcode-intel-extend-bdw-late-loading-further-with-llc-size-check.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "hrtimer: Reset hrtimer cpu base proper on CPU hotplug" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled hrtimer: Reset hrtimer cpu base proper on CPU hotplug to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: hrtimer-reset-hrtimer-cpu-base-proper-on-cpu-hotplug.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d5421ea43d30701e03cadc56a38854c36a8b4433 Mon Sep 17 00:00:00 2001 From: Thomas Gleixner <tglx(a)linutronix.de> Date: Fri, 26 Jan 2018 14:54:32 +0100 Subject: hrtimer: Reset hrtimer cpu base proper on CPU hotplug From: Thomas Gleixner <tglx(a)linutronix.de> commit d5421ea43d30701e03cadc56a38854c36a8b4433 upstream. The hrtimer interrupt code contains a hang detection and mitigation mechanism, which prevents that a long delayed hrtimer interrupt causes a continous retriggering of interrupts which prevent the system from making progress. If a hang is detected then the timer hardware is programmed with a certain delay into the future and a flag is set in the hrtimer cpu base which prevents newly enqueued timers from reprogramming the timer hardware prior to the chosen delay. The subsequent hrtimer interrupt after the delay clears the flag and resumes normal operation. If such a hang happens in the last hrtimer interrupt before a CPU is unplugged then the hang_detected flag is set and stays that way when the CPU is plugged in again. At that point the timer hardware is not armed and it cannot be armed because the hang_detected flag is still active, so nothing clears that flag. As a consequence the CPU does not receive hrtimer interrupts and no timers expire on that CPU which results in RCU stalls and other malfunctions. Clear the flag along with some other less critical members of the hrtimer cpu base to ensure starting from a clean state when a CPU is plugged in. Thanks to Paul, Sebastian and Anna-Maria for their help to get down to the root cause of that hard to reproduce heisenbug. Once understood it's trivial and certainly justifies a brown paperbag. Fixes: 41d2e4949377 ("hrtimer: Tune hrtimer_interrupt hang logic") Reported-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Sebastian Sewior <bigeasy(a)linutronix.de> Cc: Anna-Maria Gleixner <anna-maria(a)linutronix.de> Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801261447590.2067@nanos Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/time/hrtimer.c | 3 +++ 1 file changed, 3 insertions(+) --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -669,7 +669,9 @@ static void hrtimer_reprogram(struct hrt static inline void hrtimer_init_hres(struct hrtimer_cpu_base *base) { base->expires_next.tv64 = KTIME_MAX; + base->hang_detected = 0; base->hres_active = 0; + base->next_timer = NULL; } /* @@ -1615,6 +1617,7 @@ static void init_hrtimers_cpu(int cpu) timerqueue_init_head(&cpu_base->clock_base[i].active); } + cpu_base->active_bases = 0; cpu_base->cpu = cpu; hrtimer_init_hres(cpu_base); } Patches currently in stable-queue which might be from tglx(a)linutronix.de are queue-4.4/prevent-timer-value-0-for-mwaitx.patch queue-4.4/x86-ioapic-fix-incorrect-pointers-in-ioapic_setup_resources.patch queue-4.4/x86-asm-32-make-sync_core-handle-missing-cpuid-on-all-32-bit-kernels.patch queue-4.4/timers-plug-locking-race-vs.-timer-migration.patch queue-4.4/x86-cpu-intel-introduce-macros-for-intel-family-numbers.patch queue-4.4/x86-retpoline-fill-rsb-on-context-switch-for-affected-cpus.patch queue-4.4/revert-module-add-retpoline-tag-to-vermagic.patch queue-4.4/x86-microcode-intel-extend-bdw-late-loading-further-with-llc-size-check.patch queue-4.4/time-avoid-undefined-behaviour-in-ktime_add_safe.patch queue-4.4/sched-deadline-use-the-revised-wakeup-rule-for-suspending-constrained-dl-tasks.patch queue-4.4/hrtimer-reset-hrtimer-cpu-base-proper-on-cpu-hotplug.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/mm/64: Fix vmapped stack syncing on very-large-memory 4-level systems" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/mm/64: Fix vmapped stack syncing on very-large-memory 4-level systems to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-mm-64-fix-vmapped-stack-syncing-on-very-large-memory-4-level-systems.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5beda7d54eafece4c974cfa9fbb9f60fb18fd20a Mon Sep 17 00:00:00 2001 From: Andy Lutomirski <luto(a)kernel.org> Date: Thu, 25 Jan 2018 13:12:14 -0800 Subject: x86/mm/64: Fix vmapped stack syncing on very-large-memory 4-level systems From: Andy Lutomirski <luto(a)kernel.org> commit 5beda7d54eafece4c974cfa9fbb9f60fb18fd20a upstream. Neil Berrington reported a double-fault on a VM with 768GB of RAM that uses large amounts of vmalloc space with PTI enabled. The cause is that load_new_mm_cr3() was never fixed to take the 5-level pgd folding code into account, so, on a 4-level kernel, the pgd synchronization logic compiles away to exactly nothing. Interestingly, the problem doesn't trigger with nopti. I assume this is because the kernel is mapped with global pages if we boot with nopti. The sequence of operations when we create a new task is that we first load its mm while still running on the old stack (which crashes if the old stack is unmapped in the new mm unless the TLB saves us), then we call prepare_switch_to(), and then we switch to the new stack. prepare_switch_to() pokes the new stack directly, which will populate the mapping through vmalloc_fault(). I assume that we're getting lucky on non-PTI systems -- the old stack's TLB entry stays alive long enough to make it all the way through prepare_switch_to() and switch_to() so that we make it to a valid stack. Fixes: b50858ce3e2a ("x86/mm/vmalloc: Add 5-level paging support") Reported-and-tested-by: Neil Berrington <neil.berrington(a)datacore.com> Signed-off-by: Andy Lutomirski <luto(a)kernel.org> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Konstantin Khlebnikov <khlebnikov(a)yandex-team.ru> Cc: Dave Hansen <dave.hansen(a)intel.com> Cc: Borislav Petkov <bp(a)alien8.de> Link: https://lkml.kernel.org/r/346541c56caed61abbe693d7d2742b4a380c5001.15169145… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/mm/tlb.c | 34 +++++++++++++++++++++++++++++----- 1 file changed, 29 insertions(+), 5 deletions(-) --- a/arch/x86/mm/tlb.c +++ b/arch/x86/mm/tlb.c @@ -151,6 +151,34 @@ void switch_mm(struct mm_struct *prev, s local_irq_restore(flags); } +static void sync_current_stack_to_mm(struct mm_struct *mm) +{ + unsigned long sp = current_stack_pointer; + pgd_t *pgd = pgd_offset(mm, sp); + + if (CONFIG_PGTABLE_LEVELS > 4) { + if (unlikely(pgd_none(*pgd))) { + pgd_t *pgd_ref = pgd_offset_k(sp); + + set_pgd(pgd, *pgd_ref); + } + } else { + /* + * "pgd" is faked. The top level entries are "p4d"s, so sync + * the p4d. This compiles to approximately the same code as + * the 5-level case. + */ + p4d_t *p4d = p4d_offset(pgd, sp); + + if (unlikely(p4d_none(*p4d))) { + pgd_t *pgd_ref = pgd_offset_k(sp); + p4d_t *p4d_ref = p4d_offset(pgd_ref, sp); + + set_p4d(p4d, *p4d_ref); + } + } +} + void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next, struct task_struct *tsk) { @@ -226,11 +254,7 @@ void switch_mm_irqs_off(struct mm_struct * mapped in the new pgd, we'll double-fault. Forcibly * map it. */ - unsigned int index = pgd_index(current_stack_pointer); - pgd_t *pgd = next->pgd + index; - - if (unlikely(pgd_none(*pgd))) - set_pgd(pgd, init_mm.pgd[index]); + sync_current_stack_to_mm(next); } /* Stop remote flushes for the previous mm */ Patches currently in stable-queue which might be from luto(a)kernel.org are queue-4.14/x86-mm-64-fix-vmapped-stack-syncing-on-very-large-memory-4-level-systems.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/microcode/intel: Extend BDW late-loading further with LLC size check" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/microcode/intel: Extend BDW late-loading further with LLC size check to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-microcode-intel-extend-bdw-late-loading-further-with-llc-size-check.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 7e702d17ed138cf4ae7c00e8c00681ed464587c7 Mon Sep 17 00:00:00 2001 From: Jia Zhang <zhang.jia(a)linux.alibaba.com> Date: Tue, 23 Jan 2018 11:41:32 +0100 Subject: x86/microcode/intel: Extend BDW late-loading further with LLC size check From: Jia Zhang <zhang.jia(a)linux.alibaba.com> commit 7e702d17ed138cf4ae7c00e8c00681ed464587c7 upstream. Commit b94b73733171 ("x86/microcode/intel: Extend BDW late-loading with a revision check") reduced the impact of erratum BDF90 for Broadwell model 79. The impact can be reduced further by checking the size of the last level cache portion per core. Tony: "The erratum says the problem only occurs on the large-cache SKUs. So we only need to avoid the update if we are on a big cache SKU that is also running old microcode." For more details, see erratum BDF90 in document #334165 (Intel Xeon Processor E7-8800/4800 v4 Product Family Specification Update) from September 2017. Fixes: b94b73733171 ("x86/microcode/intel: Extend BDW late-loading with a revision check") Signed-off-by: Jia Zhang <zhang.jia(a)linux.alibaba.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Acked-by: Tony Luck <tony.luck(a)intel.com> Link: https://lkml.kernel.org/r/1516321542-31161-1-git-send-email-zhang.jia@linux… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/cpu/microcode/intel.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) --- a/arch/x86/kernel/cpu/microcode/intel.c +++ b/arch/x86/kernel/cpu/microcode/intel.c @@ -45,6 +45,9 @@ static const char ucode_path[] = "kernel /* Current microcode patch used in early patching on the APs. */ static struct microcode_intel *intel_ucode_patch; +/* last level cache size per core */ +static int llc_size_per_core; + static inline bool cpu_signatures_match(unsigned int s1, unsigned int p1, unsigned int s2, unsigned int p2) { @@ -912,12 +915,14 @@ static bool is_blacklisted(unsigned int /* * Late loading on model 79 with microcode revision less than 0x0b000021 - * may result in a system hang. This behavior is documented in item - * BDF90, #334165 (Intel Xeon Processor E7-8800/4800 v4 Product Family). + * and LLC size per core bigger than 2.5MB may result in a system hang. + * This behavior is documented in item BDF90, #334165 (Intel Xeon + * Processor E7-8800/4800 v4 Product Family). */ if (c->x86 == 6 && c->x86_model == INTEL_FAM6_BROADWELL_X && c->x86_mask == 0x01 && + llc_size_per_core > 2621440 && c->microcode < 0x0b000021) { pr_err_once("Erratum BDF90: late loading with revision < 0x0b000021 (0x%x) disabled.\n", c->microcode); pr_err_once("Please consider either early loading through initrd/built-in or a potential BIOS update.\n"); @@ -975,6 +980,15 @@ static struct microcode_ops microcode_in .apply_microcode = apply_microcode_intel, }; +static int __init calc_llc_size_per_core(struct cpuinfo_x86 *c) +{ + u64 llc_size = c->x86_cache_size * 1024; + + do_div(llc_size, c->x86_max_cores); + + return (int)llc_size; +} + struct microcode_ops * __init init_intel_microcode(void) { struct cpuinfo_x86 *c = &boot_cpu_data; @@ -985,5 +999,7 @@ struct microcode_ops * __init init_intel return NULL; } + llc_size_per_core = calc_llc_size_per_core(c); + return &microcode_intel_ops; } Patches currently in stable-queue which might be from zhang.jia(a)linux.alibaba.com are queue-4.14/x86-microcode-intel-extend-bdw-late-loading-further-with-llc-size-check.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/microcode: Fix again accessing initrd after having been freed" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/microcode: Fix again accessing initrd after having been freed to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-microcode-fix-again-accessing-initrd-after-having-been-freed.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 1d080f096fe33f031d26e19b3ef0146f66b8b0f1 Mon Sep 17 00:00:00 2001 From: Borislav Petkov <bp(a)suse.de> Date: Tue, 23 Jan 2018 11:41:33 +0100 Subject: x86/microcode: Fix again accessing initrd after having been freed From: Borislav Petkov <bp(a)suse.de> commit 1d080f096fe33f031d26e19b3ef0146f66b8b0f1 upstream. Commit 24c2503255d3 ("x86/microcode: Do not access the initrd after it has been freed") fixed attempts to access initrd from the microcode loader after it has been freed. However, a similar KASAN warning was reported (stack trace edited): smpboot: Booting Node 0 Processor 1 APIC 0x11 ================================================================== BUG: KASAN: use-after-free in find_cpio_data+0x9b5/0xa50 Read of size 1 at addr ffff880035ffd000 by task swapper/1/0 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.14.8-slack #7 Hardware name: System manufacturer System Product Name/A88X-PLUS, BIOS 3003 03/10/2016 Call Trace: dump_stack print_address_description kasan_report ? find_cpio_data __asan_report_load1_noabort find_cpio_data find_microcode_in_initrd __load_ucode_amd load_ucode_amd_ap load_ucode_ap After some investigation, it turned out that a merge was done using the wrong side to resolve, leading to picking up the previous state, before the 24c2503255d3 fix. Therefore the Fixes tag below contains a merge commit. Revert the mismerge by catching the save_microcode_in_initrd_amd() retval and thus letting the function exit with the last return statement so that initrd_gone can be set to true. Fixes: f26483eaedec ("Merge branch 'x86/urgent' into x86/microcode, to resolve conflicts") Reported-by: <higuita(a)gmx.net> Signed-off-by: Borislav Petkov <bp(a)suse.de> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Link: https://bugzilla.kernel.org/show_bug.cgi?id=198295 Link: https://lkml.kernel.org/r/20180123104133.918-2-bp@alien8.de Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/cpu/microcode/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kernel/cpu/microcode/core.c +++ b/arch/x86/kernel/cpu/microcode/core.c @@ -239,7 +239,7 @@ static int __init save_microcode_in_init break; case X86_VENDOR_AMD: if (c->x86 >= 0x10) - return save_microcode_in_initrd_amd(cpuid_eax(1)); + ret = save_microcode_in_initrd_amd(cpuid_eax(1)); break; default: break; Patches currently in stable-queue which might be from bp(a)suse.de are queue-4.14/x86-microcode-intel-extend-bdw-late-loading-further-with-llc-size-check.patch queue-4.14/x86-microcode-fix-again-accessing-initrd-after-having-been-freed.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "perf/x86/amd/power: Do not load AMD power module on !AMD platforms" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf/x86/amd/power: Do not load AMD power module on !AMD platforms to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: perf-x86-amd-power-do-not-load-amd-power-module-on-amd-platforms.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 40d4071ce2d20840d224b4a77b5dc6f752c9ab15 Mon Sep 17 00:00:00 2001 From: Xiao Liang <xiliang(a)redhat.com> Date: Mon, 22 Jan 2018 14:12:52 +0800 Subject: perf/x86/amd/power: Do not load AMD power module on !AMD platforms From: Xiao Liang <xiliang(a)redhat.com> commit 40d4071ce2d20840d224b4a77b5dc6f752c9ab15 upstream. The AMD power module can be loaded on non AMD platforms, but unload fails with the following Oops: BUG: unable to handle kernel NULL pointer dereference at (null) IP: __list_del_entry_valid+0x29/0x90 Call Trace: perf_pmu_unregister+0x25/0xf0 amd_power_pmu_exit+0x1c/0xd23 [power] SyS_delete_module+0x1a8/0x2b0 ? exit_to_usermode_loop+0x8f/0xb0 entry_SYSCALL_64_fastpath+0x20/0x83 Return -ENODEV instead of 0 from the module init function if the CPU does not match. Fixes: c7ab62bfbe0e ("perf/x86/amd/power: Add AMD accumulated power reporting mechanism") Signed-off-by: Xiao Liang <xiliang(a)redhat.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Link: https://lkml.kernel.org/r/20180122061252.6394-1-xiliang@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/events/amd/power.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/events/amd/power.c +++ b/arch/x86/events/amd/power.c @@ -277,7 +277,7 @@ static int __init amd_power_pmu_init(voi int ret; if (!x86_match_cpu(cpu_match)) - return 0; + return -ENODEV; if (!boot_cpu_has(X86_FEATURE_ACC_POWER)) return -ENODEV; Patches currently in stable-queue which might be from xiliang(a)redhat.com are queue-4.14/perf-x86-amd-power-do-not-load-amd-power-module-on-amd-platforms.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "hrtimer: Reset hrtimer cpu base proper on CPU hotplug" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled hrtimer: Reset hrtimer cpu base proper on CPU hotplug to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: hrtimer-reset-hrtimer-cpu-base-proper-on-cpu-hotplug.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d5421ea43d30701e03cadc56a38854c36a8b4433 Mon Sep 17 00:00:00 2001 From: Thomas Gleixner <tglx(a)linutronix.de> Date: Fri, 26 Jan 2018 14:54:32 +0100 Subject: hrtimer: Reset hrtimer cpu base proper on CPU hotplug From: Thomas Gleixner <tglx(a)linutronix.de> commit d5421ea43d30701e03cadc56a38854c36a8b4433 upstream. The hrtimer interrupt code contains a hang detection and mitigation mechanism, which prevents that a long delayed hrtimer interrupt causes a continous retriggering of interrupts which prevent the system from making progress. If a hang is detected then the timer hardware is programmed with a certain delay into the future and a flag is set in the hrtimer cpu base which prevents newly enqueued timers from reprogramming the timer hardware prior to the chosen delay. The subsequent hrtimer interrupt after the delay clears the flag and resumes normal operation. If such a hang happens in the last hrtimer interrupt before a CPU is unplugged then the hang_detected flag is set and stays that way when the CPU is plugged in again. At that point the timer hardware is not armed and it cannot be armed because the hang_detected flag is still active, so nothing clears that flag. As a consequence the CPU does not receive hrtimer interrupts and no timers expire on that CPU which results in RCU stalls and other malfunctions. Clear the flag along with some other less critical members of the hrtimer cpu base to ensure starting from a clean state when a CPU is plugged in. Thanks to Paul, Sebastian and Anna-Maria for their help to get down to the root cause of that hard to reproduce heisenbug. Once understood it's trivial and certainly justifies a brown paperbag. Fixes: 41d2e4949377 ("hrtimer: Tune hrtimer_interrupt hang logic") Reported-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Sebastian Sewior <bigeasy(a)linutronix.de> Cc: Anna-Maria Gleixner <anna-maria(a)linutronix.de> Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801261447590.2067@nanos Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/time/hrtimer.c | 3 +++ 1 file changed, 3 insertions(+) --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -655,7 +655,9 @@ static void hrtimer_reprogram(struct hrt static inline void hrtimer_init_hres(struct hrtimer_cpu_base *base) { base->expires_next = KTIME_MAX; + base->hang_detected = 0; base->hres_active = 0; + base->next_timer = NULL; } /* @@ -1591,6 +1593,7 @@ int hrtimers_prepare_cpu(unsigned int cp timerqueue_init_head(&cpu_base->clock_base[i].active); } + cpu_base->active_bases = 0; cpu_base->cpu = cpu; hrtimer_init_hres(cpu_base); return 0; Patches currently in stable-queue which might be from tglx(a)linutronix.de are queue-4.14/perf-x86-amd-power-do-not-load-amd-power-module-on-amd-platforms.patch queue-4.14/x86-mm-64-fix-vmapped-stack-syncing-on-very-large-memory-4-level-systems.patch queue-4.14/revert-module-add-retpoline-tag-to-vermagic.patch queue-4.14/x86-microcode-intel-extend-bdw-late-loading-further-with-llc-size-check.patch queue-4.14/hrtimer-reset-hrtimer-cpu-base-proper-on-cpu-hotplug.patch queue-4.14/x86-microcode-fix-again-accessing-initrd-after-having-been-freed.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/microcode/intel: Extend BDW late-loading further with LLC size check" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/microcode/intel: Extend BDW late-loading further with LLC size check to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-microcode-intel-extend-bdw-late-loading-further-with-llc-size-check.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 7e702d17ed138cf4ae7c00e8c00681ed464587c7 Mon Sep 17 00:00:00 2001 From: Jia Zhang <zhang.jia(a)linux.alibaba.com> Date: Tue, 23 Jan 2018 11:41:32 +0100 Subject: x86/microcode/intel: Extend BDW late-loading further with LLC size check From: Jia Zhang <zhang.jia(a)linux.alibaba.com> commit 7e702d17ed138cf4ae7c00e8c00681ed464587c7 upstream. Commit b94b73733171 ("x86/microcode/intel: Extend BDW late-loading with a revision check") reduced the impact of erratum BDF90 for Broadwell model 79. The impact can be reduced further by checking the size of the last level cache portion per core. Tony: "The erratum says the problem only occurs on the large-cache SKUs. So we only need to avoid the update if we are on a big cache SKU that is also running old microcode." For more details, see erratum BDF90 in document #334165 (Intel Xeon Processor E7-8800/4800 v4 Product Family Specification Update) from September 2017. Fixes: b94b73733171 ("x86/microcode/intel: Extend BDW late-loading with a revision check") Signed-off-by: Jia Zhang <zhang.jia(a)linux.alibaba.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Acked-by: Tony Luck <tony.luck(a)intel.com> Link: https://lkml.kernel.org/r/1516321542-31161-1-git-send-email-zhang.jia@linux… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/cpu/microcode/intel.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) --- a/arch/x86/kernel/cpu/microcode/intel.c +++ b/arch/x86/kernel/cpu/microcode/intel.c @@ -87,6 +87,9 @@ MODULE_DESCRIPTION("Microcode Update Dri MODULE_AUTHOR("Tigran Aivazian <tigran(a)aivazian.fsnet.co.uk>"); MODULE_LICENSE("GPL"); +/* last level cache size per core */ +static int llc_size_per_core; + static int collect_cpu_info(int cpu_num, struct cpu_signature *csig) { struct cpuinfo_x86 *c = &cpu_data(cpu_num); @@ -273,12 +276,14 @@ static bool is_blacklisted(unsigned int /* * Late loading on model 79 with microcode revision less than 0x0b000021 - * may result in a system hang. This behavior is documented in item - * BDF90, #334165 (Intel Xeon Processor E7-8800/4800 v4 Product Family). + * and LLC size per core bigger than 2.5MB may result in a system hang. + * This behavior is documented in item BDF90, #334165 (Intel Xeon + * Processor E7-8800/4800 v4 Product Family). */ if (c->x86 == 6 && c->x86_model == 79 && c->x86_mask == 0x01 && + llc_size_per_core > 2621440 && c->microcode < 0x0b000021) { pr_err_once("Erratum BDF90: late loading with revision < 0x0b000021 (0x%x) disabled.\n", c->microcode); pr_err_once("Please consider either early loading through initrd/built-in or a potential BIOS update.\n"); @@ -345,6 +350,15 @@ static struct microcode_ops microcode_in .microcode_fini_cpu = microcode_fini_cpu, }; +static int __init calc_llc_size_per_core(struct cpuinfo_x86 *c) +{ + u64 llc_size = c->x86_cache_size * 1024; + + do_div(llc_size, c->x86_max_cores); + + return (int)llc_size; +} + struct microcode_ops * __init init_intel_microcode(void) { struct cpuinfo_x86 *c = &cpu_data(0); @@ -355,6 +369,8 @@ struct microcode_ops * __init init_intel return NULL; } + llc_size_per_core = calc_llc_size_per_core(c); + return &microcode_intel_ops; } Patches currently in stable-queue which might be from zhang.jia(a)linux.alibaba.com are queue-3.18/x86-microcode-intel-extend-bdw-late-loading-further-with-llc-size-check.patch

7 years, 9 months

1
0
0 0

Re: [Linux-stable-mirror] rtc-opal: Fix handling of firmware error codes, prevent busy loops

by Michael Ellerman

On Tue, 2016-08-02 at 01:50:16 UTC, Stewart Smith wrote: > According to the OPAL docs: > https://github.com/open-power/skiboot/blob/skiboot-5.2.5/doc/opal-api/opal-… > https://github.com/open-power/skiboot/blob/skiboot-5.2.5/doc/opal-api/opal-… > OPAL_HARDWARE may be returned from OPAL_RTC_READ or OPAL_RTC_WRITE and this > indicates either a transient or permanent error. > > Prior to this patch, Linux was not dealing with OPAL_HARDWARE being a > permanent error particularly well, in that you could end up in a busy > loop. > > This was not too hard to trigger on an AMI BMC based OpenPOWER machine > doing a continuous "ipmitool mc reset cold" to the BMC, the result of > that being that we'd get stuck in an infinite loop in opal_get_rtc_time. > > We now retry a few times before returning the error higher up the stack. > > Cc: stable(a)vger.kernel.org > Signed-off-by: Stewart Smith <stewart(a)linux.vnet.ibm.com> Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/5b8b58063029f02da573120ef4dc90 cheers

7 years, 9 months

1
0
0 0

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

by Sasha Levin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Greg, Pleae pull commits for Linux 3.18 . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== The following changes since commit a5d35deca214e095bf9d1745aa6c00dd7ced0517: Linux 3.18.92 (2018-01-17 09:29:32 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git tags/for-greg-3.18-28012018 for you to fetch changes up to df300edb5fa24f11a40cd7278fd03befa197595c: staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID (2018-01-20 20:06:55 -0500) - ---------------------------------------------------------------- for-greg-3.18-28012018 - ---------------------------------------------------------------- Andrew Elble (1): nfsd: check for use of the closed special stateid Chun-Yeow Yeoh (1): mac80211: fix the update of path metric for RANN frame Colin Ian King (1): usb: gadget: don't dereference g until after it has been null checked Eduardo Otubo (1): xen-netfront: remove warning when unloading module Geert Uytterhoeven (1): net: ethernet: xilinx: Mark XILINX_LL_TEMAC broken on 64-bit Gustavo A. R. Silva (1): scsi: ufs: ufshcd: fix potential NULL pointer dereference in ufshcd_config_vreg Icenowy Zheng (1): media: usbtv: add a new usbid Larry Finger (1): staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID Liran Alon (2): KVM: x86: emulator: Return to user-mode on L1 CPL=0 emulation failure KVM: x86: Don't re-execute instruction when not passing CR2 value Michael Lyle (1): bcache: check return value of register_shrinker Robert Lippert (1): hwmon: (pmbus) Use 64bit math for DIRECT format values Tetsuo Handa (1): quota: Check for register_shrinker() failure. Trond Myklebust (1): nfsd: CLOSE SHOULD return the invalid special stateid for NFSv4.x (x>0) Wanpeng Li (2): KVM: X86: Fix operand/address-size during instruction decoding KVM: VMX: Fix rflags cache during vCPU reset arch/x86/include/asm/kvm_host.h | 3 ++- arch/x86/kvm/emulate.c | 7 +++++++ arch/x86/kvm/vmx.c | 4 ++-- arch/x86/kvm/x86.c | 2 +- drivers/hwmon/pmbus/pmbus_core.c | 21 ++++++++++++--------- drivers/md/bcache/btree.c | 5 ++++- drivers/media/usb/usbtv/usbtv-core.c | 1 + drivers/net/ethernet/xilinx/Kconfig | 1 + drivers/net/xen-netfront.c | 18 ++++++++++++++++++ drivers/scsi/ufs/ufshcd.c | 7 +++++-- drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 14 ++++---------- drivers/usb/gadget/composite.c | 7 +++++-- fs/nfsd/nfs4state.c | 15 +++++++++++++-- fs/quota/dquot.c | 3 ++- net/mac80211/mesh_hwmp.c | 15 +++++++++------ 15 files changed, 86 insertions(+), 37 deletions(-) -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJabk+JAAoJEN6mb/eXdyzcsM4P/jdYg7OMJOze9ufNRFj2GyPM Exw5hdnLFQXd6UTuM2qL08mTHmM4R8c7FGic9AQL/2hJHQE1k62BJL5HcHOd9uqg IKWdzP1tDFenSsOpdhbUiI0lqIDRUbNBPLw/8nfQpWKPeaXkiqK7cExgEzMHY+bk eQgWNTttm+1U8h6UgXjMf86XR7+CLO7X1ph+Nh6rticfEVLnVeUUKTZ+im2J59YU dQHyav2C0d8QI2FOs6P3uh9y5KcdYP85ro1BI1s4Q9M0MaJbwFgTDajOFQPuiAgV WciUCphNbZsDYHBYttvekVOynfHujuQp6HsqhDfxspy/Dwsz1ppxYP20Y9d3sfwv g5mYY3JdxGJiQ9UoijlSMxnsvcu7epg4aBy6S4Hsh6Ojsw2HJyYxHYqBQJFed/oz 1dZDCWhLAHEkNaOrKzxZJU9T14VhAD2QoZSTf3KI0g8KxMpgQVv+KbcvO9nUAJPz wJP5xWObjVHCVLR6xh7E/zKroR1CNRzGmh5XTV0JPjrAQvm6Fs+etVsfTGp19yZ6 B4MGCltIVf96OdLoFvkbod3n058U3ZFI3fqnsxNd37U46vS1k1nZp6BKEG6VU50R AmzRaZUkx/oBdRUP+bHg4Md8zq8yI911q+A+bTkCY+krAcVNmRopGPB24Mg2bBpF bEthrC6b7HCRfHJD+2C5 =2nGa -----END PGP SIGNATURE-----

7 years, 9 months

1
0
0 0

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

by Sasha Levin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Greg, Pleae pull commits for Linux 4.4 . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== The following changes since commit 42375c1120d5c90d7469ba264fb124f728b1a4f7: Linux 4.4.112 (2018-01-17 09:35:33 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git tags/for-greg-4.4-28012018 for you to fetch changes up to cfeb59f68fea0fddcb4b26c839cc098247814c88: staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID (2018-01-28 13:15:38 -0500) - ---------------------------------------------------------------- for-greg-4.4-28012018 - ---------------------------------------------------------------- Andrew Elble (1): nfsd: check for use of the closed special stateid Christophe JAILLET (1): drm/omap: Fix error handling path in 'omap_dmm_probe()' Chun-Yeow Yeoh (1): mac80211: fix the update of path metric for RANN frame Colin Ian King (1): usb: gadget: don't dereference g until after it has been null checked Darrick J. Wong (1): xfs: ubsan fixes Eduardo Otubo (1): xen-netfront: remove warning when unloading module Felix Kuehling (2): drm/amdgpu: Fix SDMA load/unload sequence on HWS disabled mode drm/amdkfd: Fix SDMA oversubsription handling Geert Uytterhoeven (1): net: ethernet: xilinx: Mark XILINX_LL_TEMAC broken on 64-bit Guilherme G. Piccoli (1): scsi: aacraid: Prevent crash in case of free interrupt during scsi EH path Gustavo A. R. Silva (1): scsi: ufs: ufshcd: fix potential NULL pointer dereference in ufshcd_config_vreg Hans de Goede (1): ACPI / bus: Leave modalias empty for devices which are not present Icenowy Zheng (1): media: usbtv: add a new usbid James Hogan (1): cpufreq: Add Loongson machine dependencies Josef Bacik (1): btrfs: fix deadlock when writing out space cache Larry Finger (1): staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID Liran Alon (2): KVM: x86: emulator: Return to user-mode on L1 CPL=0 emulation failure KVM: x86: Don't re-execute instruction when not passing CR2 value Michael Lyle (1): bcache: check return value of register_shrinker Nikita Leshenko (3): KVM: x86: ioapic: Fix level-triggered EOI and IOAPIC reconfigure race KVM: x86: ioapic: Clear Remote IRR when entry is switched to edge-triggered KVM: x86: ioapic: Preserve read-only values in the redirection table Robert Lippert (1): hwmon: (pmbus) Use 64bit math for DIRECT format values Tetsuo Handa (1): quota: Check for register_shrinker() failure. Trond Myklebust (3): nfsd: CLOSE SHOULD return the invalid special stateid for NFSv4.x (x>0) nfsd: Ensure we check stateid validity in the seqid operation checks SUNRPC: Allow connect to return EHOSTUNREACH Vasily Averin (2): grace: replace BUG_ON by WARN_ONCE in exit_net hook lockd: fix "list_add double add" caused by legacy signal interface Wanpeng Li (2): KVM: X86: Fix operand/address-size during instruction decoding KVM: VMX: Fix rflags cache during vCPU reset Yisheng Xie (1): kmemleak: add scheduling point to kmemleak_scan() shaoyunl (1): drm/amdkfd: Fix SDMA ring buffer size calculation zhangliping (1): openvswitch: fix the incorrect flow action alloc size arch/x86/include/asm/kvm_host.h | 3 +- arch/x86/kvm/emulate.c | 7 ++++ arch/x86/kvm/ioapic.c | 20 +++++++-- arch/x86/kvm/vmx.c | 4 +- arch/x86/kvm/x86.c | 2 +- drivers/acpi/device_sysfs.c | 4 ++ drivers/cpufreq/Kconfig | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 47 ++++++++++++++++------ drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c | 4 +- .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 18 +++++++++ drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 3 +- drivers/hwmon/pmbus/pmbus_core.c | 21 +++++----- drivers/md/bcache/btree.c | 5 ++- drivers/media/usb/usbtv/usbtv-core.c | 1 + drivers/net/ethernet/xilinx/Kconfig | 1 + drivers/net/xen-netfront.c | 18 +++++++++ drivers/scsi/aacraid/commsup.c | 2 +- drivers/scsi/ufs/ufshcd.c | 7 +++- drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 14 ++----- drivers/usb/gadget/composite.c | 7 +++- fs/btrfs/free-space-cache.c | 3 +- fs/nfs_common/grace.c | 10 ++++- fs/nfsd/nfs4state.c | 34 +++++++++------- fs/quota/dquot.c | 3 +- fs/xfs/xfs_aops.c | 6 +-- mm/kmemleak.c | 2 + net/mac80211/mesh_hwmp.c | 15 ++++--- net/openvswitch/flow_netlink.c | 16 ++++---- net/sunrpc/xprtsock.c | 1 + 29 files changed, 197 insertions(+), 83 deletions(-) -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJabk9/AAoJEN6mb/eXdyzcVCwQAMG2Lj8HgHf2AYNOmEtJeju6 DspErylBwcoOjpbc4LKgqCY9JVev8KWbSPC4PU3J3XeiAjizrqrkmLW83N7sj9IJ EQ49sc84No6eKLEkxAVagPVuV1XAgZy8ywCxewC9a6l72PFY0IqGHGydxOTbXLhu HLiwXfu7LtziVN8Le7Em0x21L0w9x8+/pFX79SHgarIAdiEwhjjvsSrEIFsNC/nQ VFPpmsGxHjlU+hh6YX7k1UOPhE1PbouDuro1qFTwtsU4eCik38k/NmYXcV5elPBW P3w41ErkeM4+oCD7ArVMjmqQts8+EEyHQELiHcitFhankCXqhiiRu2PETfeNeOiT ym1qKnIqxaK3+moN7ZugAUX8PdB9TmqyNiOAUDnsr+RF4pD8RBGJ5yQaWwoUFat3 0GaZTq/c8B2NMQ7ugNK0nn1firXgPUIfvO22r7io5nDF1mzIUHj0qeYw14Pdiewi Dsss4EzWMfP9tGHyoEFY8Z1Pg+6PKdlzuoBt8H+FUBi38NU/5Fx8t9t+TiPgKQq0 yaoToyMabCcLkFh+D8o22W0e/kTUijcxYu4OY6uvKKFYeTdHvPpF4N/CLrt/IaJz 3rQ5Op1GQnZ6ep9Z/bSkx6wvTu/0lf8PUGsRvAgV2SGQF6THcZMLA5WKhifWmVED /6na9ECM6uGY3pNh1fFQ =z5FJ -----END PGP SIGNATURE-----

7 years, 9 months

1
0
0 0

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

by Sasha Levin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Greg, Pleae pull commits for Linux 4.9 . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== The following changes since commit b8cf9ff79d63a3ac5567bd7cbb9445bfed193f4d: Linux 4.9.77 (2018-01-17 09:39:00 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git tags/for-greg-4.9-28012018 for you to fetch changes up to c9d88981a5409f08a2f401e2c874bb4eccc92395: drm/vc4: Move IRQ enable to PM path (2018-01-28 13:21:47 -0500) - ---------------------------------------------------------------- for-greg-4.9-28012018 - ---------------------------------------------------------------- Abhishek Goel (2): cpupowerutils: bench - Fix cpu online check cpupower : Fix cpupower working when cpu0 is offline Andrew Elble (1): nfsd: check for use of the closed special stateid Andrey Gusakov (6): drm/bridge: tc358767: do no fail on hi-res displays drm/bridge: tc358767: filter out too high modes drm/bridge: tc358767: fix DP0_MISC register set drm/bridge: tc358767: fix timing calculations drm/bridge: tc358767: fix AUXDATAn registers access drm/bridge: tc358767: fix 1-lane behavior Carlos Maiolino (1): xfs: Properly retry failed dquot items in case of error during buffer writeback Christian KÃ¶nig (1): drm/amdgpu: don't try to move pinned BOs Christophe JAILLET (2): bnxt_en: Fix an error handling path in 'bnxt_get_module_eeprom()' drm/omap: Fix error handling path in 'omap_dmm_probe()' Chun-Yeow Yeoh (1): mac80211: fix the update of path metric for RANN frame Colin Ian King (1): usb: gadget: don't dereference g until after it has been null checked Darrick J. Wong (2): xfs: always free inline data before resetting inode fork during ifree xfs: ubsan fixes Eduardo Otubo (1): xen-netfront: remove warning when unloading module Emmanuel Grumbach (1): iwlwifi: mvm: fix the TX queue hang timeout for MONITOR vif type Felix Kuehling (2): drm/amdgpu: Fix SDMA load/unload sequence on HWS disabled mode drm/amdkfd: Fix SDMA oversubsription handling Florian Fainelli (1): ARM: dts: NSP: Fix PPI interrupt types Geert Uytterhoeven (1): net: ethernet: xilinx: Mark XILINX_LL_TEMAC broken on 64-bit Guilherme G. Piccoli (1): scsi: aacraid: Prevent crash in case of free interrupt during scsi EH path Gustavo A. R. Silva (1): scsi: ufs: ufshcd: fix potential NULL pointer dereference in ufshcd_config_vreg Hans de Goede (1): ACPI / bus: Leave modalias empty for devices which are not present Icenowy Zheng (1): media: usbtv: add a new usbid James Hogan (1): cpufreq: Add Loongson machine dependencies Jeff Layton (1): reiserfs: remove unneeded i_version bump Josef Bacik (1): btrfs: fix deadlock when writing out space cache Larry Finger (1): staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID Liran Alon (2): KVM: x86: emulator: Return to user-mode on L1 CPL=0 emulation failure KVM: x86: Don't re-execute instruction when not passing CR2 value Michael Lyle (1): bcache: check return value of register_shrinker Michal Hocko (1): xfs: fortify xfs_alloc_buftarg error handling Nikita Leshenko (3): KVM: x86: ioapic: Fix level-triggered EOI and IOAPIC reconfigure race KVM: x86: ioapic: Clear Remote IRR when entry is switched to edge-triggered KVM: x86: ioapic: Preserve read-only values in the redirection table Robert Lippert (1): hwmon: (pmbus) Use 64bit math for DIRECT format values Stefan Schake (2): drm/vc4: Account for interrupts in flight drm/vc4: Move IRQ enable to PM path Tetsuo Handa (1): quota: Check for register_shrinker() failure. Thomas Meyer (1): auxdisplay: img-ascii-lcd: Only build on archs that have IOMEM Trond Myklebust (3): nfsd: CLOSE SHOULD return the invalid special stateid for NFSv4.x (x>0) nfsd: Ensure we check stateid validity in the seqid operation checks SUNRPC: Allow connect to return EHOSTUNREACH Vasily Averin (2): grace: replace BUG_ON by WARN_ONCE in exit_net hook lockd: fix "list_add double add" caused by legacy signal interface Wanpeng Li (3): KVM: X86: Fix operand/address-size during instruction decoding KVM: X86: Fix softlockup when get the current kvmclock KVM: VMX: Fix rflags cache during vCPU reset Yisheng Xie (1): kmemleak: add scheduling point to kmemleak_scan() shaoyunl (1): drm/amdkfd: Fix SDMA ring buffer size calculation zhangliping (1): openvswitch: fix the incorrect flow action alloc size arch/arm/boot/dts/bcm-nsp.dtsi | 4 +- arch/x86/include/asm/kvm_host.h | 3 +- arch/x86/kvm/emulate.c | 7 +++ arch/x86/kvm/ioapic.c | 20 +++++- arch/x86/kvm/vmx.c | 4 +- arch/x86/kvm/x86.c | 13 ++-- drivers/acpi/device_sysfs.c | 4 ++ drivers/auxdisplay/Kconfig | 1 + drivers/cpufreq/Kconfig | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 47 ++++++++++---- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++ drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c | 4 +- .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 18 ++++++ drivers/gpu/drm/bridge/tc358767.c | 73 ++++++++++++---------- drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 3 +- drivers/gpu/drm/vc4/vc4_irq.c | 3 + drivers/gpu/drm/vc4/vc4_v3d.c | 3 + drivers/hwmon/pmbus/pmbus_core.c | 21 ++++--- drivers/md/bcache/btree.c | 5 +- drivers/media/usb/usbtv/usbtv-core.c | 1 + drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 4 +- drivers/net/ethernet/xilinx/Kconfig | 1 + drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 2 + drivers/net/xen-netfront.c | 18 ++++++ drivers/scsi/aacraid/commsup.c | 2 +- drivers/scsi/ufs/ufshcd.c | 7 ++- drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 14 ++--- drivers/usb/gadget/composite.c | 7 ++- fs/btrfs/free-space-cache.c | 3 +- fs/nfs_common/grace.c | 10 ++- fs/nfsd/nfs4state.c | 34 +++++----- fs/quota/dquot.c | 3 +- fs/reiserfs/super.c | 1 - fs/xfs/xfs_aops.c | 6 +- fs/xfs/xfs_buf.c | 15 +++-- fs/xfs/xfs_dquot.c | 14 ++++- fs/xfs/xfs_dquot_item.c | 40 +++++++++++- fs/xfs/xfs_inode.c | 21 +++++++ mm/kmemleak.c | 2 + net/mac80211/mesh_hwmp.c | 15 +++-- net/openvswitch/flow_netlink.c | 16 ++--- net/sunrpc/xprtsock.c | 1 + tools/power/cpupower/bench/system.c | 2 +- .../cpupower/utils/idle_monitor/cpuidle_sysfs.c | 9 ++- 44 files changed, 348 insertions(+), 139 deletions(-) -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJabk92AAoJEN6mb/eXdyzcnVEQAKIr7sCFqiTHcovJbHfDaIEB igFPmNXnHVBxfk0UijBWOeN8rVaUC6EMZjcp24Ue9cnWu1aIt0QEK7ul81Uh1y47 D6MaZn/NhUx9IyBv8nj1A774+JscJGLwx/BaubBydjkt0U5G7jVqYoBjTfTgh53I Rn7wTqtXyubF/SagK7DUaW20fPDpT592oIF83MGYSYe2H3PsatMFEOMjKnSP7eQL /+ygf1/WxzjC2XMQa4daYwG2/6zZH8X4MH2HhNo425bDt2kIf2WoXVCZIabEqBHS VDHe0Ar1wRo31y35LDQiCZ+N6cZsJxoS1NnC/bsCNDj6cc1Y5TD2KFpyimn35PqE F8LqQiZP6PVhsL/VppbAoMJ8adkeCc9tldqf2YkOVN0Ph+86hiTVOoT1Mk0FbBWy ThfgX590EVwXKMvJ1Xs8mXksxiM7FpE/lNqC8/WQ4crPnFy0vVC3DF0Uvj9JsUeY s7bsYzcXgNNxjxs+neKNElzQmPfcMacCOtoIYssZHfQqsc5qf5BGH7Ifan1ckg6D XL/hYBlwePOs1dVKNsS5ypQEVT+ckTEYXDuoZIk9yDmSkvcYdXJsi6OMiSwX2yAt YHGfhCnqXbO7/EqpGCAvvUNnVD8GCSuKv+XfzuVac0GFhHEC1ass7iZH/6TRu3cM 492x++N5GwEhtnMzdk/m =mil3 -----END PGP SIGNATURE-----

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] [PATCH AUTOSEL for 3.18 01/25] usb: build drivers/usb/common/ when USB_SUPPORT is set

by Sasha Levin

From: Randy Dunlap <rdunlap(a)infradead.org> [ Upstream commit c9d24f78268be444e803fb2bb138a2f598de9c23 ] PHY drivers can use ULPI interfaces when CONFIG_USB (which is host side support) is not enabled, so also build drivers/usb/ when CONFIG_USB_SUPPORT is enabled so that drivers/usb/common/ is built. ERROR: "ulpi_unregister_driver" [drivers/phy/ti/phy-tusb1210.ko] undefined! ERROR: "__ulpi_register_driver" [drivers/phy/ti/phy-tusb1210.ko] undefined! ERROR: "ulpi_read" [drivers/phy/ti/phy-tusb1210.ko] undefined! ERROR: "ulpi_write" [drivers/phy/ti/phy-tusb1210.ko] undefined! ERROR: "ulpi_unregister_driver" [drivers/phy/qualcomm/phy-qcom-usb-hs.ko] undefined! ERROR: "__ulpi_register_driver" [drivers/phy/qualcomm/phy-qcom-usb-hs.ko] undefined! ERROR: "ulpi_write" [drivers/phy/qualcomm/phy-qcom-usb-hs.ko] undefined! Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- drivers/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/Makefile b/drivers/Makefile index ebee55537a05..76304657163b 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -90,6 +90,7 @@ obj-$(CONFIG_TC) += tc/ obj-$(CONFIG_UWB) += uwb/ obj-$(CONFIG_USB_PHY) += usb/ obj-$(CONFIG_USB) += usb/ +obj-$(CONFIG_USB_SUPPORT) += usb/ obj-$(CONFIG_PCI) += usb/ obj-$(CONFIG_USB_GADGET) += usb/ obj-$(CONFIG_SERIO) += input/serio/ -- 2.11.0

7 years, 9 months

1
24
0 0

[Linux-stable-mirror] [PATCH AUTOSEL for 4.4 01/36] usb: build drivers/usb/common/ when USB_SUPPORT is set

by Sasha Levin

From: Randy Dunlap <rdunlap(a)infradead.org> [ Upstream commit c9d24f78268be444e803fb2bb138a2f598de9c23 ] PHY drivers can use ULPI interfaces when CONFIG_USB (which is host side support) is not enabled, so also build drivers/usb/ when CONFIG_USB_SUPPORT is enabled so that drivers/usb/common/ is built. ERROR: "ulpi_unregister_driver" [drivers/phy/ti/phy-tusb1210.ko] undefined! ERROR: "__ulpi_register_driver" [drivers/phy/ti/phy-tusb1210.ko] undefined! ERROR: "ulpi_read" [drivers/phy/ti/phy-tusb1210.ko] undefined! ERROR: "ulpi_write" [drivers/phy/ti/phy-tusb1210.ko] undefined! ERROR: "ulpi_unregister_driver" [drivers/phy/qualcomm/phy-qcom-usb-hs.ko] undefined! ERROR: "__ulpi_register_driver" [drivers/phy/qualcomm/phy-qcom-usb-hs.ko] undefined! ERROR: "ulpi_write" [drivers/phy/qualcomm/phy-qcom-usb-hs.ko] undefined! Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- drivers/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/Makefile b/drivers/Makefile index 098997f2cc3a..f42a74ebc1be 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -96,6 +96,7 @@ obj-$(CONFIG_TC) += tc/ obj-$(CONFIG_UWB) += uwb/ obj-$(CONFIG_USB_PHY) += usb/ obj-$(CONFIG_USB) += usb/ +obj-$(CONFIG_USB_SUPPORT) += usb/ obj-$(CONFIG_PCI) += usb/ obj-$(CONFIG_USB_GADGET) += usb/ obj-$(CONFIG_OF) += usb/ -- 2.11.0

7 years, 9 months

1
35
0 0

[Linux-stable-mirror] [PATCH AUTOSEL for 4.9 01/49] usb: build drivers/usb/common/ when USB_SUPPORT is set

by Sasha Levin

From: Randy Dunlap <rdunlap(a)infradead.org> [ Upstream commit c9d24f78268be444e803fb2bb138a2f598de9c23 ] PHY drivers can use ULPI interfaces when CONFIG_USB (which is host side support) is not enabled, so also build drivers/usb/ when CONFIG_USB_SUPPORT is enabled so that drivers/usb/common/ is built. ERROR: "ulpi_unregister_driver" [drivers/phy/ti/phy-tusb1210.ko] undefined! ERROR: "__ulpi_register_driver" [drivers/phy/ti/phy-tusb1210.ko] undefined! ERROR: "ulpi_read" [drivers/phy/ti/phy-tusb1210.ko] undefined! ERROR: "ulpi_write" [drivers/phy/ti/phy-tusb1210.ko] undefined! ERROR: "ulpi_unregister_driver" [drivers/phy/qualcomm/phy-qcom-usb-hs.ko] undefined! ERROR: "__ulpi_register_driver" [drivers/phy/qualcomm/phy-qcom-usb-hs.ko] undefined! ERROR: "ulpi_write" [drivers/phy/qualcomm/phy-qcom-usb-hs.ko] undefined! Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- drivers/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/Makefile b/drivers/Makefile index 733bf0b2613f..7c3d58dcf6b3 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -99,6 +99,7 @@ obj-$(CONFIG_TC) += tc/ obj-$(CONFIG_UWB) += uwb/ obj-$(CONFIG_USB_PHY) += usb/ obj-$(CONFIG_USB) += usb/ +obj-$(CONFIG_USB_SUPPORT) += usb/ obj-$(CONFIG_PCI) += usb/ obj-$(CONFIG_USB_GADGET) += usb/ obj-$(CONFIG_OF) += usb/ -- 2.11.0

7 years, 9 months

1
48
0 0

[Linux-stable-mirror] [PATCH AUTOSEL for 4.14 001/100] usb: build drivers/usb/common/ when USB_SUPPORT is set

by Sasha Levin

From: Randy Dunlap <rdunlap(a)infradead.org> [ Upstream commit c9d24f78268be444e803fb2bb138a2f598de9c23 ] PHY drivers can use ULPI interfaces when CONFIG_USB (which is host side support) is not enabled, so also build drivers/usb/ when CONFIG_USB_SUPPORT is enabled so that drivers/usb/common/ is built. ERROR: "ulpi_unregister_driver" [drivers/phy/ti/phy-tusb1210.ko] undefined! ERROR: "__ulpi_register_driver" [drivers/phy/ti/phy-tusb1210.ko] undefined! ERROR: "ulpi_read" [drivers/phy/ti/phy-tusb1210.ko] undefined! ERROR: "ulpi_write" [drivers/phy/ti/phy-tusb1210.ko] undefined! ERROR: "ulpi_unregister_driver" [drivers/phy/qualcomm/phy-qcom-usb-hs.ko] undefined! ERROR: "__ulpi_register_driver" [drivers/phy/qualcomm/phy-qcom-usb-hs.ko] undefined! ERROR: "ulpi_write" [drivers/phy/qualcomm/phy-qcom-usb-hs.ko] undefined! Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- drivers/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/Makefile b/drivers/Makefile index d242d3514d30..5f5ccdbad21a 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -105,6 +105,7 @@ obj-$(CONFIG_TC) += tc/ obj-$(CONFIG_UWB) += uwb/ obj-$(CONFIG_USB_PHY) += usb/ obj-$(CONFIG_USB) += usb/ +obj-$(CONFIG_USB_SUPPORT) += usb/ obj-$(CONFIG_PCI) += usb/ obj-$(CONFIG_USB_GADGET) += usb/ obj-$(CONFIG_OF) += usb/ -- 2.11.0

7 years, 9 months

1
99
0 0

[Linux-stable-mirror] [PATCH 4.4] vsyscall: Fix permissions for emulate mode with KAISER/PTI

by Ben Hutchings

The backport of KAISER to 4.4 turned vsyscall emulate mode into native mode. Add a vsyscall_pgprot variable to hold the correct page protections, like Borislav and Hugh did for 3.2 and 3.18. Cc: Borislav Petkov <bp(a)suse.de> Cc: Hugh Dickins <hughd(a)google.com> Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk> --- I think this is also needed for 4.9 but haven't tested there. Ben. arch/x86/entry/vsyscall/vsyscall_64.c | 7 ++++--- arch/x86/include/asm/vsyscall.h | 1 + arch/x86/mm/kaiser.c | 2 +- 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscall/vsyscall_64.c index 112178b401a1..2d359991a273 100644 --- a/arch/x86/entry/vsyscall/vsyscall_64.c +++ b/arch/x86/entry/vsyscall/vsyscall_64.c @@ -46,6 +46,7 @@ static enum { EMULATE, NATIVE, NONE } vsyscall_mode = #else EMULATE; #endif +unsigned long vsyscall_pgprot = __PAGE_KERNEL_VSYSCALL; static int __init vsyscall_setup(char *str) { @@ -336,11 +337,11 @@ void __init map_vsyscall(void) extern char __vsyscall_page; unsigned long physaddr_vsyscall = __pa_symbol(&__vsyscall_page); + if (vsyscall_mode != NATIVE) + vsyscall_pgprot = __PAGE_KERNEL_VVAR; if (vsyscall_mode != NONE) __set_fixmap(VSYSCALL_PAGE, physaddr_vsyscall, - vsyscall_mode == NATIVE - ? PAGE_KERNEL_VSYSCALL - : PAGE_KERNEL_VVAR); + __pgprot(vsyscall_pgprot)); BUILD_BUG_ON((unsigned long)__fix_to_virt(VSYSCALL_PAGE) != (unsigned long)VSYSCALL_ADDR); diff --git a/arch/x86/include/asm/vsyscall.h b/arch/x86/include/asm/vsyscall.h index 4865e10dbb55..9ee85066f407 100644 --- a/arch/x86/include/asm/vsyscall.h +++ b/arch/x86/include/asm/vsyscall.h @@ -13,6 +13,7 @@ extern void map_vsyscall(void); */ extern bool emulate_vsyscall(struct pt_regs *regs, unsigned long address); extern bool vsyscall_enabled(void); +extern unsigned long vsyscall_pgprot; #else static inline void map_vsyscall(void) {} static inline bool emulate_vsyscall(struct pt_regs *regs, unsigned long address) diff --git a/arch/x86/mm/kaiser.c b/arch/x86/mm/kaiser.c index 8af98513d36c..2298434f7bdb 100644 --- a/arch/x86/mm/kaiser.c +++ b/arch/x86/mm/kaiser.c @@ -345,7 +345,7 @@ void __init kaiser_init(void) if (vsyscall_enabled()) kaiser_add_user_map_early((void *)VSYSCALL_ADDR, PAGE_SIZE, - __PAGE_KERNEL_VSYSCALL); + vsyscall_pgprot); for_each_possible_cpu(cpu) { void *percpu_vaddr = __per_cpu_user_mapped_start + -- 2.15.0.rc0

7 years, 9 months

4
6
0 0

[Linux-stable-mirror] Patch "vmxnet3: repair memory leak" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled vmxnet3: repair memory leak to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: vmxnet3-repair-memory-leak.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Jan 28 17:37:09 CET 2018 From: Neil Horman <nhorman(a)tuxdriver.com> Date: Mon, 22 Jan 2018 16:06:37 -0500 Subject: vmxnet3: repair memory leak From: Neil Horman <nhorman(a)tuxdriver.com> [ Upstream commit 848b159835ddef99cc4193083f7e786c3992f580 ] with the introduction of commit b0eb57cb97e7837ebb746404c2c58c6f536f23fa, it appears that rq->buf_info is improperly handled. While it is heap allocated when an rx queue is setup, and freed when torn down, an old line of code in vmxnet3_rq_destroy was not properly removed, leading to rq->buf_info[0] being set to NULL prior to its being freed, causing a memory leak, which eventually exhausts the system on repeated create/destroy operations (for example, when the mtu of a vmxnet3 interface is changed frequently. Fix is pretty straight forward, just move the NULL set to after the free. Tested by myself with successful results Applies to net, and should likely be queued for stable, please Signed-off-by: Neil Horman <nhorman(a)tuxdriver.com> Reported-By: boyang(a)redhat.com CC: boyang(a)redhat.com CC: Shrikrishna Khare <skhare(a)vmware.com> CC: "VMware, Inc." <pv-drivers(a)vmware.com> CC: David S. Miller <davem(a)davemloft.net> Acked-by: Shrikrishna Khare <skhare(a)vmware.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/vmxnet3/vmxnet3_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/vmxnet3/vmxnet3_drv.c +++ b/drivers/net/vmxnet3/vmxnet3_drv.c @@ -1616,7 +1616,6 @@ static void vmxnet3_rq_destroy(struct vm rq->rx_ring[i].basePA); rq->rx_ring[i].base = NULL; } - rq->buf_info[i] = NULL; } if (rq->data_ring.base) { @@ -1638,6 +1637,7 @@ static void vmxnet3_rq_destroy(struct vm (rq->rx_ring[0].size + rq->rx_ring[1].size); dma_free_coherent(&adapter->pdev->dev, sz, rq->buf_info[0], rq->buf_info_pa); + rq->buf_info[0] = rq->buf_info[1] = NULL; } } Patches currently in stable-queue which might be from nhorman(a)tuxdriver.com are queue-4.9/sctp-do-not-allow-the-v4-socket-to-bind-a-v4mapped-v6-address.patch queue-4.9/vmxnet3-repair-memory-leak.patch queue-4.9/sctp-return-error-if-the-asoc-has-been-peeled-off-in-sctp_wait_for_sndbuf.patch

7 years, 9 months

1
0
0 0

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

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tipc: fix a memory leak in tipc_nl_node_get_link() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: tipc-fix-a-memory-leak-in-tipc_nl_node_get_link.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Jan 28 17:37:09 CET 2018 From: Cong Wang <xiyou.wangcong(a)gmail.com> Date: Wed, 10 Jan 2018 12:50:25 -0800 Subject: tipc: fix a memory leak in tipc_nl_node_get_link() From: Cong Wang <xiyou.wangcong(a)gmail.com> [ Upstream commit 59b36613e85fb16ebf9feaf914570879cd5c2a21 ] When tipc_node_find_by_name() fails, the nlmsg is not freed. While on it, switch to a goto label to properly free it. Fixes: be9c086715c ("tipc: narrow down exposure of struct tipc_node") Reported-by: Dmitry Vyukov <dvyukov(a)google.com> Cc: Jon Maloy <jon.maloy(a)ericsson.com> Cc: Ying Xue <ying.xue(a)windriver.com> Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com> Acked-by: Ying Xue <ying.xue(a)windriver.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/tipc/node.c | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-) --- a/net/tipc/node.c +++ b/net/tipc/node.c @@ -1848,36 +1848,38 @@ int tipc_nl_node_get_link(struct sk_buff if (strcmp(name, tipc_bclink_name) == 0) { err = tipc_nl_add_bc_link(net, &msg); - if (err) { - nlmsg_free(msg.skb); - return err; - } + if (err) + goto err_free; } else { int bearer_id; struct tipc_node *node; struct tipc_link *link; node = tipc_node_find_by_name(net, name, &bearer_id); - if (!node) - return -EINVAL; + if (!node) { + err = -EINVAL; + goto err_free; + } tipc_node_read_lock(node); link = node->links[bearer_id].link; if (!link) { tipc_node_read_unlock(node); - nlmsg_free(msg.skb); - return -EINVAL; + err = -EINVAL; + goto err_free; } err = __tipc_nl_add_link(net, &msg, link, 0); tipc_node_read_unlock(node); - if (err) { - nlmsg_free(msg.skb); - return err; - } + if (err) + goto err_free; } return genlmsg_reply(msg.skb, info); + +err_free: + nlmsg_free(msg.skb); + return err; } int tipc_nl_node_reset_link_stats(struct sk_buff *skb, struct genl_info *info) Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are queue-4.9/tipc-fix-a-memory-leak-in-tipc_nl_node_get_link.patch queue-4.9/tun-fix-a-memory-leak-for-tfile-tx_array.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "tun: fix a memory leak for tfile->tx_array" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tun: fix a memory leak for tfile->tx_array to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: tun-fix-a-memory-leak-for-tfile-tx_array.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Jan 28 17:37:09 CET 2018 From: Cong Wang <xiyou.wangcong(a)gmail.com> Date: Mon, 15 Jan 2018 11:37:29 -0800 Subject: tun: fix a memory leak for tfile->tx_array From: Cong Wang <xiyou.wangcong(a)gmail.com> [ Upstream commit 4df0bfc79904b7169dc77dcce44598b1545721f9 ] tfile->tun could be detached before we close the tun fd, via tun_detach_all(), so it should not be used to check for tfile->tx_array. As Jason suggested, we probably have to clean it up unconditionally both in __tun_deatch() and tun_detach_all(), but this requires to check if it is initialized or not. Currently skb_array_cleanup() doesn't have such a check, so I check it in the caller and introduce a helper function, it is a bit ugly but we can always improve it in net-next. Reported-by: Dmitry Vyukov <dvyukov(a)google.com> Fixes: 1576d9860599 ("tun: switch to use skb array for tx") Cc: Jason Wang <jasowang(a)redhat.com> Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/tun.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -525,6 +525,14 @@ static void tun_queue_purge(struct tun_f skb_queue_purge(&tfile->sk.sk_error_queue); } +static void tun_cleanup_tx_array(struct tun_file *tfile) +{ + if (tfile->tx_array.ring.queue) { + skb_array_cleanup(&tfile->tx_array); + memset(&tfile->tx_array, 0, sizeof(tfile->tx_array)); + } +} + static void __tun_detach(struct tun_file *tfile, bool clean) { struct tun_file *ntfile; @@ -566,8 +574,7 @@ static void __tun_detach(struct tun_file tun->dev->reg_state == NETREG_REGISTERED) unregister_netdevice(tun->dev); } - if (tun) - skb_array_cleanup(&tfile->tx_array); + tun_cleanup_tx_array(tfile); sock_put(&tfile->sk); } } @@ -606,11 +613,13 @@ static void tun_detach_all(struct net_de /* Drop read queue */ tun_queue_purge(tfile); sock_put(&tfile->sk); + tun_cleanup_tx_array(tfile); } list_for_each_entry_safe(tfile, tmp, &tun->disabled, next) { tun_enable_queue(tfile); tun_queue_purge(tfile); sock_put(&tfile->sk); + tun_cleanup_tx_array(tfile); } BUG_ON(tun->numdisabled != 0); @@ -2363,6 +2372,8 @@ static int tun_chr_open(struct inode *in sock_set_flag(&tfile->sk, SOCK_ZEROCOPY); + memset(&tfile->tx_array, 0, sizeof(tfile->tx_array)); + return 0; } Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are queue-4.9/tipc-fix-a-memory-leak-in-tipc_nl_node_get_link.patch queue-4.9/tun-fix-a-memory-leak-for-tfile-tx_array.patch

7 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror