The patch titled
Subject: fs/proc/task_mmu.c: fix smaps_rollup pss_locked calculation
has been added to the -mm tree. Its filename is
mm-proc-smaps_rollup-fix-pss_locked-calculation.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-proc-smaps_rollup-fix-pss_locke…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-proc-smaps_rollup-fix-pss_locke…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Sandeep Patil <sspatil(a)android.com>
Subject: fs/proc/task_mmu.c: fix smaps_rollup pss_locked calculation
The 'pss_locked' field of smaps_rollup was being calculated incorrectly as
it accumulated the current pss everytime a locked VMA was found.
Fix that by making sure we record the current pss value before each VMA is
walked. So, we can only add the delta if the VMA was found to be
VM_LOCKED.
Link: http://lkml.kernel.org/r/20190121011049.160505-1-sspatil@android.com
Fixes: 493b0e9d945f ("mm: add /proc/pid/smaps_rollup")
Signed-off-by: Sandeep Patil <sspatil(a)android.com>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Alexey Dobriyan <adobriyan(a)gmail.com>
Cc: Andrey Vagin <avagin(a)openvz.org>
Cc: Daniel Colascione <dancol(a)google.com>
Cc: <stable(a)vger.kernel.org> [4.14.x 4.19.x]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/proc/task_mmu.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/fs/proc/task_mmu.c~mm-proc-smaps_rollup-fix-pss_locked-calculation
+++ a/fs/proc/task_mmu.c
@@ -721,6 +721,7 @@ static void smap_gather_stats(struct vm_
#endif
.mm = vma->vm_mm,
};
+ unsigned long pss;
smaps_walk.private = mss;
@@ -749,11 +750,12 @@ static void smap_gather_stats(struct vm_
}
}
#endif
-
+ /* record current pss so we can calculate the delta after page walk */
+ pss = mss->pss;
/* mmap_sem is held in m_start */
walk_page_vma(vma, &smaps_walk);
if (vma->vm_flags & VM_LOCKED)
- mss->pss_locked += mss->pss;
+ mss->pss_locked += mss->pss - pss;
}
#define SEQ_PUT_DEC(str, val) \
_
Patches currently in -mm which might be from sspatil(a)android.com are
mm-proc-smaps_rollup-fix-pss_locked-calculation.patch
The patch titled
Subject: mm, oom: fix use-after-free in oom_kill_process
has been added to the -mm tree. Its filename is
mm-oom-fix-use-after-free-in-oom_kill_process.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-oom-fix-use-after-free-in-oom_k…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-oom-fix-use-after-free-in-oom_k…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Shakeel Butt <shakeelb(a)google.com>
Subject: mm, oom: fix use-after-free in oom_kill_process
Syzbot instance running on upstream kernel found a use-after-free bug in
oom_kill_process. On further inspection it seems like the process
selected to be oom-killed has exited even before reaching
read_lock(&tasklist_lock) in oom_kill_process(). More specifically the
tsk->usage is 1 which is due to get_task_struct() in oom_evaluate_task()
and the put_task_struct within for_each_thread() frees the tsk and
for_each_thread() tries to access the tsk. The easiest fix is to do
get/put across the for_each_thread() on the selected task.
Now the next question is should we continue with the oom-kill as the
previously selected task has exited? However before adding more
complexity and heuristics, let's answer why we even look at the children
of oom-kill selected task? The select_bad_process() has already selected
the worst process in the system/memcg. Due to race, the selected process
might not be the worst at the kill time but does that matter? The
userspace can use the oom_score_adj interface to prefer children to be
killed before the parent. I looked at the history but it seems like this
is there before git history.
Link: http://lkml.kernel.org/r/20190121215850.221745-1-shakeelb@google.com
Reported-by: syzbot+7fbbfa368521945f0e3d(a)syzkaller.appspotmail.com
Fixes: 6b0c81b3be11 ("mm, oom: reduce dependency on tasklist_lock")
Signed-off-by: Shakeel Butt <shakeelb(a)google.com>
Reviewed-by: Roman Gushchin <guro(a)fb.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: David Rientjes <rientjes(a)google.com>
Cc: Johannes Weiner <hannes(a)cmpxchg.org>
Cc: Tetsuo Handa <penguin-kernel(a)i-love.sakura.ne.jp>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/oom_kill.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/mm/oom_kill.c~mm-oom-fix-use-after-free-in-oom_kill_process
+++ a/mm/oom_kill.c
@@ -975,6 +975,13 @@ static void oom_kill_process(struct oom_
* still freeing memory.
*/
read_lock(&tasklist_lock);
+
+ /*
+ * The task 'p' might have already exited before reaching here. The
+ * put_task_struct() will free task_struct 'p' while the loop still try
+ * to access the field of 'p', so, get an extra reference.
+ */
+ get_task_struct(p);
for_each_thread(p, t) {
list_for_each_entry(child, &t->children, sibling) {
unsigned int child_points;
@@ -994,6 +1001,7 @@ static void oom_kill_process(struct oom_
}
}
}
+ put_task_struct(p);
read_unlock(&tasklist_lock);
/*
_
Patches currently in -mm which might be from shakeelb(a)google.com are
mm-oom-fix-use-after-free-in-oom_kill_process.patch
memcg-localize-memcg_kmem_enabled-check.patch
memcg-schedule-high-reclaim-for-remote-memcgs-on-high_work.patch
memcg-schedule-high-reclaim-for-remote-memcgs-on-high_work-v3.patch
mm-oom-remove-prefer-children-over-parent-heuristic.patch
Jann Horn identified a racy access to p->mm in the global expedited
command of the membarrier system call.
The suggested fix is to hold the task_lock() around the accesses to
p->mm and to the mm_struct membarrier_state field to guarantee the
existence of the mm_struct.
Link: https://lore.kernel.org/lkml/CAG48ez2G8ctF8dHS42TF37pThfr3y0RNOOYTmxvACm4u8…
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com>
Tested-by: Jann Horn <jannh(a)google.com>
CC: Jann Horn <jannh(a)google.com>
CC: Thomas Gleixner <tglx(a)linutronix.de>
CC: Peter Zijlstra (Intel) <peterz(a)infradead.org>
CC: Ingo Molnar <mingo(a)kernel.org>
CC: Andrea Parri <parri.andrea(a)gmail.com>
CC: Andy Lutomirski <luto(a)kernel.org>
CC: Avi Kivity <avi(a)scylladb.com>
CC: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
CC: Boqun Feng <boqun.feng(a)gmail.com>
CC: Dave Watson <davejwatson(a)fb.com>
CC: David Sehr <sehr(a)google.com>
CC: H. Peter Anvin <hpa(a)zytor.com>
CC: Linus Torvalds <torvalds(a)linux-foundation.org>
CC: Maged Michael <maged.michael(a)gmail.com>
CC: Michael Ellerman <mpe(a)ellerman.id.au>
CC: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
CC: Paul Mackerras <paulus(a)samba.org>
CC: Russell King <linux(a)armlinux.org.uk>
CC: Will Deacon <will.deacon(a)arm.com>
CC: stable(a)vger.kernel.org # v4.16+
CC: linux-api(a)vger.kernel.org
---
kernel/sched/membarrier.c | 27 +++++++++++++++++++++------
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c
index 76e0eaf4654e..305fdcc4c5f7 100644
--- a/kernel/sched/membarrier.c
+++ b/kernel/sched/membarrier.c
@@ -81,12 +81,27 @@ static int membarrier_global_expedited(void)
rcu_read_lock();
p = task_rcu_dereference(&cpu_rq(cpu)->curr);
- if (p && p->mm && (atomic_read(&p->mm->membarrier_state) &
- MEMBARRIER_STATE_GLOBAL_EXPEDITED)) {
- if (!fallback)
- __cpumask_set_cpu(cpu, tmpmask);
- else
- smp_call_function_single(cpu, ipi_mb, NULL, 1);
+ /*
+ * Skip this CPU if the runqueue's current task is NULL or if
+ * it is a kernel thread.
+ */
+ if (p && READ_ONCE(p->mm)) {
+ bool mm_match;
+
+ /*
+ * Read p->mm and access membarrier_state while holding
+ * the task lock to ensure existence of mm.
+ */
+ task_lock(p);
+ mm_match = p->mm && (atomic_read(&p->mm->membarrier_state) &
+ MEMBARRIER_STATE_GLOBAL_EXPEDITED);
+ task_unlock(p);
+ if (mm_match) {
+ if (!fallback)
+ __cpumask_set_cpu(cpu, tmpmask);
+ else
+ smp_call_function_single(cpu, ipi_mb, NULL, 1);
+ }
}
rcu_read_unlock();
}
--
2.17.1
The patch below does not apply to the 4.20-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From b5679cebf780c6f1c2451a73bf1842a4409840e7 Mon Sep 17 00:00:00 2001
From: Dexuan Cui <decui(a)microsoft.com>
Date: Wed, 9 Jan 2019 20:56:06 +0000
Subject: [PATCH] vmbus: fix subchannel removal
The changes to split ring allocation from open/close, broke
the cleanup of subchannels. This resulted in problems using
uio on network devices because the subchannel was left behind
when the network device was unbound.
The cause was in the disconnect logic which used list splice
to move the subchannel list into a local variable. This won't
work because the subchannel list is needed later during the
process of the rescind messages (relid2channel).
The fix is to just leave the subchannel list in place
which is what the original code did. The list is cleaned
up later when the host rescind is processed.
Without the fix, we have a lot of "hang" issues in netvsc when we
try to change the NIC's MTU, set the number of channels, etc.
Fixes: ae6935ed7d42 ("vmbus: split ring buffer allocation from open")
Cc: stable(a)vger.kernel.org
Signed-off-by: Stephen Hemminger <sthemmin(a)microsoft.com>
Signed-off-by: Dexuan Cui <decui(a)microsoft.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index ce0ba2062723..bea4c9850247 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -701,19 +701,12 @@ static int vmbus_close_internal(struct vmbus_channel *channel)
int vmbus_disconnect_ring(struct vmbus_channel *channel)
{
struct vmbus_channel *cur_channel, *tmp;
- unsigned long flags;
- LIST_HEAD(list);
int ret;
if (channel->primary_channel != NULL)
return -EINVAL;
- /* Snapshot the list of subchannels */
- spin_lock_irqsave(&channel->lock, flags);
- list_splice_init(&channel->sc_list, &list);
- spin_unlock_irqrestore(&channel->lock, flags);
-
- list_for_each_entry_safe(cur_channel, tmp, &list, sc_list) {
+ list_for_each_entry_safe(cur_channel, tmp, &channel->sc_list, sc_list) {
if (cur_channel->rescind)
wait_for_completion(&cur_channel->rescind_event);
Hello,
We ran automated tests on a patchset that was proposed for merging into this
kernel tree. The patches were applied to:
Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Commit: 9f1a389a0b5b Linux 4.20.5
The results of these automated tests are provided below.
Overall result: FAILED (see details below)
Patch merge: OK
Compile: OK
Kernel tests: FAILED
One or more kernel tests failed:
powerpc64le: PASSED
s390x: PASSED
aarch64: PASSED
x86_64: PASSED
We hope that these logs can help you find the problem quickly. For the full
detail on our testing procedures, please scroll to the bottom of this message.
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
Merge testing
-------------
We cloned this repository and checked out a ref:
Repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Ref: 9f1a389a0b5b Linux 4.20.5
We then merged the following patches with `git am`:
amd-xgbe-fix-mdio-access-for-non-zero-ports-and-clause-45-phys.patch
net-bridge-fix-ethernet-header-pointer-before-check-skb-forwardable.patch
net-fix-usage-of-pskb_trim_rcsum.patch
net-phy-marvell-errata-for-mv88e6390-internal-phys.patch
net-phy-mdio_bus-add-missing-device_del-in-mdiobus_register-error-handling.patch
net-phy-phy-driver-features-are-mandatory.patch
net-sched-act_tunnel_key-fix-memory-leak-in-case-of-action-replace.patch
net_sched-refetch-skb-protocol-for-each-filter.patch
openvswitch-avoid-oob-read-when-parsing-flow-nlattrs.patch
vhost-log-dirty-page-correctly.patch
mlxsw-pci-increase-pci-sw-reset-timeout.patch
net-ipv4-fix-memory-leak-in-network-namespace-dismantle.patch
mlxsw-spectrum_fid-update-dummy-fid-index.patch
mlxsw-pci-ring-cq-s-doorbell-before-rdq-s.patch
net-sched-cls_flower-allocate-mask-dynamically-in-fl_change.patch
udp-with-udp_segment-release-on-error-path.patch
ip6_gre-fix-tunnel-list-corruption-for-x-netns.patch
erspan-build-the-header-with-the-right-proto-according-to-erspan_ver.patch
net-phy-marvell-fix-deadlock-from-wrong-locking.patch
ip6_gre-update-version-related-info-when-changing-link.patch
tcp-allow-msg_zerocopy-transmission-also-in-close_wait-state.patch
arm-fix-the-cockup-in-the-previous-patch.patch
sunrpc-address-kerberos-performance-behavior-regress.patch
mei-me-mark-lbg-devices-as-having-dma-support.patch
mei-me-add-denverton-innovation-engine-device-ids.patch
usb-leds-fix-regression-in-usbport-led-trigger.patch
usb-ehci-ehci-mv-add-module_device_table.patch
usb-serial-ftdi_sio-fix-gpio-not-working-in-autosuspend.patch
usb-serial-simple-add-motorola-tetra-tpg2200-device-id.patch
usb-serial-pl2303-add-new-pid-to-support-pl2303tb.patch
ceph-clear-inode-pointer-when-snap-realm-gets-dropped-by-its-inode.patch
asoc-atom-fix-a-missing-check-of-snd_pcm_lib_malloc_pages.patch
asoc-rt5514-spi-fix-potential-null-pointer-dereference.patch
asoc-tlv320aic32x4-kernel-oops-while-entering-dapm-standby-mode.patch
clk-zynqmp-fix-memory-allocation-in-zynqmp_clk_setup.patch
clk-socfpga-stratix10-fix-rate-calculation-for-pll-clocks.patch
clk-socfpga-stratix10-fix-naming-convention-for-the-fixed-clocks.patch
inotify-fix-fd-refcount-leak-in-inotify_add_watch.patch
alsa-hda-realtek-fix-typo-for-alc225-model.patch
alsa-hda-add-mute-led-support-for-hp-probook-470-g5.patch
arcv2-lib-memeset-fix-doing-prefetchw-outside-of-buffer.patch
arc-adjust-memblock_reserve-of-kernel-memory.patch
arc-perf-map-generic-branches-to-correct-hardware-condition.patch
s390-vdso-correct-vdso-mapping-for-compat-tasks.patch
s390-mm-always-force-a-load-of-the-primary-asce-on-context-switch.patch
s390-early-improve-machine-detection.patch
s390-smp-fix-cpu-hotplug-deadlock-with-cpu-rescan.patch
s390-smp-fix-calling-smp_call_ipl_cpu-from-ipl-cpu.patch
misc-ibmvsm-fix-potential-null-pointer-dereference.patch
char-mwave-fix-potential-spectre-v1-vulnerability.patch
mmc-sdhci-iproc-handle-mmc_of_parse-errors-during-probe.patch
mmc-dw_mmc-bluefield-fix-the-license-information.patch
mmc-meson-gx-free-irq-in-release-callback.patch
staging-rtl8188eu-add-device-code-for-d-link-dwa-121-rev-b1.patch
tty-handle-problem-if-line-discipline-does-not-have-receive_buf.patch
uart-fix-crash-in-uart_write-and-uart_put_char.patch
tty-n_hdlc-fix-__might_sleep-warning.patch
hv_balloon-avoid-touching-uninitialized-struct-page-during-tail-onlining.patch
drivers-hv-vmbus-check-for-ring-when-getting-debug-info.patch
vgacon-unconfuse-vc_origin-when-using-soft-scrollback.patch
cifs-fix-possible-hang-during-async-mtu-reads-and-writes.patch
cifs-fix-credits-calculations-for-reads-with-errors.patch
cifs-fix-credit-calculation-for-encrypted-reads-with-errors.patch
cifs-do-not-reconnect-tcp-session-in-add_credits.patch
smb3-add-credits-we-receive-from-oplock-break-pdus.patch
input-xpad-add-support-for-steelseries-stratus-duo.patch
input-input_event-provide-override-for-sparc64.patch
input-uinput-fix-undefined-behavior-in-uinput_validate_absinfo.patch
acpi-nfit-block-function-zero-dsms.patch
acpi-nfit-fix-command-supported-detection.patch
scsi-ufs-use-explicit-access-size-in-ufshcd_dump_regs.patch
dm-thin-fix-passdown_double_checking_shared_status.patch
dm-crypt-fix-parsing-of-extended-iv-arguments.patch
drm-amdgpu-add-aptx-quirk-for-lenovo-laptop.patch
edac-altera-fix-s10-persistent-register-offset.patch
kvm-x86-fix-single-step-debugging.patch
kvm-x86-fix-pv-ipis-for-32-bit-kvm-host.patch
kvm-x86-warn_once-if-sending-a-pv-ipi-returns-a-fatal-error.patch
kvm-x86-vmx-use-kzalloc-for-cached_vmcs12.patch
x86-pkeys-properly-copy-pkey-state-at-fork.patch
x86-selftests-pkeys-fork-to-check-for-state-being-preserved.patch
x86-kaslr-fix-incorrect-i8254-outb-parameters.patch
x86-entry-64-compat-fix-stack-switching-for-xen-pv.patch
posix-cpu-timers-unbreak-timer-rearming.patch
net-sun-cassini-cleanup-license-conflict.patch
irqchip-gic-v3-its-align-pci-multi-msi-allocation-on-their-size.patch
can-dev-__can_get_echo_skb-fix-bogous-check-for-non-existing-skb-by-removing-it.patch
can-bcm-check-timer-values-before-ktime-conversion.patch
can-flexcan-fix-null-pointer-exception-during-bringup.patch
vt-make-vt_console_print-compatible-with-the-unicode-screen-buffer.patch
vt-always-call-notifier-with-the-console-lock-held.patch
vt-invoke-notifier-on-screen-size-change.patch
Compile testing
---------------
We compiled the kernel for 4 architectures:
powerpc64le:
make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64
configuration: https://artifacts.cki-project.org/builds/ppc64le/37ab853d978ad56fe7282effaf…
s390x:
make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64
configuration: https://artifacts.cki-project.org/builds/s390x/a46196bd00443d94448839972e96…
aarch64:
make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64
configuration: https://artifacts.cki-project.org/builds/aarch64/ad27f389bdca6633caea1a474f…
x86_64:
make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64
configuration: https://artifacts.cki-project.org/builds/x86_64/45a926f1b63beab12bfa2e5cd35…
Hardware testing
----------------
We booted each kernel and ran the following tests:
powerpc:
s390:
Boot test
- URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution…
/distribution/command
LTP lite - release 20180926
- URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution…
AMTU (Abstract Machine Test Utility)
- URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu
arm64:
Boot test
- URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution…
/distribution/command
LTP lite - release 20180926
- URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution…
xfstests: xfs
- URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems…
AMTU (Abstract Machine Test Utility)
- URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu
Usex - version 1.9-29
- URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us…
x86_64:
Boot test
- URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution…
/distribution/command
LTP lite - release 20180926
- URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution…
xfstests: xfs
- URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems…
AMTU (Abstract Machine Test Utility)
- URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu
Usex - version 1.9-29
- URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us…
Jann Horn identified a racy access to p->mm in the global expedited
command of the membarrier system call.
The suggested fix is to hold the task_lock() around the accesses to
p->mm and to the mm_struct membarrier_state field to guarantee the
existence of the mm_struct.
Link: https://lore.kernel.org/lkml/CAG48ez2G8ctF8dHS42TF37pThfr3y0RNOOYTmxvACm4u8…
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com>
CC: Jann Horn <jannh(a)google.com>
CC: Thomas Gleixner <tglx(a)linutronix.de>
CC: Peter Zijlstra (Intel) <peterz(a)infradead.org>
CC: Ingo Molnar <mingo(a)kernel.org>
CC: Andrea Parri <parri.andrea(a)gmail.com>
CC: Andrew Hunter <ahh(a)google.com>
CC: Andy Lutomirski <luto(a)kernel.org>
CC: Avi Kivity <avi(a)scylladb.com>
CC: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
CC: Boqun Feng <boqun.feng(a)gmail.com>
CC: Dave Watson <davejwatson(a)fb.com>
CC: David Sehr <sehr(a)google.com>
CC: Greg Hackmann <ghackmann(a)google.com>
CC: H. Peter Anvin <hpa(a)zytor.com>
CC: Linus Torvalds <torvalds(a)linux-foundation.org>
CC: Maged Michael <maged.michael(a)gmail.com>
CC: Michael Ellerman <mpe(a)ellerman.id.au>
CC: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
CC: Paul Mackerras <paulus(a)samba.org>
CC: Russell King <linux(a)armlinux.org.uk>
CC: Will Deacon <will.deacon(a)arm.com>
CC: stable(a)vger.kernel.org # v4.16+
CC: linux-api(a)vger.kernel.org
---
kernel/sched/membarrier.c | 27 +++++++++++++++++++++------
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c
index 76e0eaf4654e..305fdcc4c5f7 100644
--- a/kernel/sched/membarrier.c
+++ b/kernel/sched/membarrier.c
@@ -81,12 +81,27 @@ static int membarrier_global_expedited(void)
rcu_read_lock();
p = task_rcu_dereference(&cpu_rq(cpu)->curr);
- if (p && p->mm && (atomic_read(&p->mm->membarrier_state) &
- MEMBARRIER_STATE_GLOBAL_EXPEDITED)) {
- if (!fallback)
- __cpumask_set_cpu(cpu, tmpmask);
- else
- smp_call_function_single(cpu, ipi_mb, NULL, 1);
+ /*
+ * Skip this CPU if the runqueue's current task is NULL or if
+ * it is a kernel thread.
+ */
+ if (p && READ_ONCE(p->mm)) {
+ bool mm_match;
+
+ /*
+ * Read p->mm and access membarrier_state while holding
+ * the task lock to ensure existence of mm.
+ */
+ task_lock(p);
+ mm_match = p->mm && (atomic_read(&p->mm->membarrier_state) &
+ MEMBARRIER_STATE_GLOBAL_EXPEDITED);
+ task_unlock(p);
+ if (mm_match) {
+ if (!fallback)
+ __cpumask_set_cpu(cpu, tmpmask);
+ else
+ smp_call_function_single(cpu, ipi_mb, NULL, 1);
+ }
}
rcu_read_unlock();
}
--
2.17.1
The following patches are targeted at 4.20 stable tree.
Thanks!
Daniel Borkmann (10):
bpf: move {prev_,}insn_idx into verifier env
bpf: move tmp variable into ax register in interpreter
bpf: enable access to ax register also from verifier rewrite
bpf: restrict map value pointer arithmetic for unprivileged
bpf: restrict stack pointer arithmetic for unprivileged
bpf: restrict unknown scalars of mixed signed bounds for unprivileged
bpf: fix check_map_access smin_value test when pointer contains offset
bpf: prevent out of bounds speculation on pointer arithmetic
bpf: fix sanitation of alu op with pointer / scalar type from
different paths
bpf: fix inner map masking to prevent oob under speculation
include/linux/bpf_verifier.h | 13 ++
include/linux/filter.h | 10 +-
kernel/bpf/core.c | 54 +++--
kernel/bpf/map_in_map.c | 17 +-
kernel/bpf/verifier.c | 369 +++++++++++++++++++++++++++++------
5 files changed, 377 insertions(+), 86 deletions(-)
--
2.17.1
This is much louder then we want. VCPI allocation failures are quite
normal, since they will happen if any part of the modesetting process is
interrupted by removing the DP MST topology in question. So just print a
debugging message on VCPI failures instead.
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream")
Cc: Ben Skeggs <bskeggs(a)redhat.com>
Cc: dri-devel(a)lists.freedesktop.org
Cc: nouveau(a)lists.freedesktop.org
Cc: <stable(a)vger.kernel.org> # v4.10+
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 2e8a5fd9b262..09a9c747c7bb 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -811,7 +811,8 @@ nv50_msto_enable(struct drm_encoder *encoder)
slots = drm_dp_find_vcpi_slots(&mstm->mgr, mstc->pbn);
r = drm_dp_mst_allocate_vcpi(&mstm->mgr, mstc->port, mstc->pbn, slots);
- WARN_ON(!r);
+ if (!r)
+ DRM_DEBUG_KMS("Failed to allocate VCPI\n");
if (!mstm->links++)
nv50_outp_acquire(mstm->outp);
--
2.20.1
The following patches are targeted at 4.19 stable tree.
Thanks!
Alexei Starovoitov (2):
bpf: improve verifier branch analysis
bpf: add per-insn complexity limit
Daniel Borkmann (10):
bpf: move {prev_,}insn_idx into verifier env
bpf: move tmp variable into ax register in interpreter
bpf: enable access to ax register also from verifier rewrite
bpf: restrict map value pointer arithmetic for unprivileged
bpf: restrict stack pointer arithmetic for unprivileged
bpf: restrict unknown scalars of mixed signed bounds for unprivileged
bpf: fix check_map_access smin_value test when pointer contains offset
bpf: prevent out of bounds speculation on pointer arithmetic
bpf: fix sanitation of alu op with pointer / scalar type from
different paths
bpf: fix inner map masking to prevent oob under speculation
include/linux/bpf_verifier.h | 13 +
include/linux/filter.h | 10 +-
kernel/bpf/core.c | 54 ++--
kernel/bpf/map_in_map.c | 17 +-
kernel/bpf/verifier.c | 470 +++++++++++++++++++++++++++++------
5 files changed, 463 insertions(+), 101 deletions(-)
--
2.17.1
I run a qemu/kvm VM with debian and I've started getting segfaults and failing checksums on
downloaded files. The failures are undeterministic and similar to the failures you get with
bad ram. I tried to diagnose the problem with various testing tools and found that
"stress-ng --verify --cpu 1" always give an error. Stress-ng give one of these errors
usually within 60 sec:
stress-ng-cpu: Newton-Rapshon sqrt not accurate enough
stress-ng-cpu: prime error detected, number of primes between 0 and 1000000 miscalculated
Nothing relevant has changed recently in the VM but the host kernel was upgraded from
4.14.93 to 4.14.96. I can't reproduce the stress-ng error with a 4.14.93 host kernel. There
is only one kvm related change in that range so I tried to revert that one.
By reverting commit 4124a4cff344abbf8187775eb643d9827830e715
"x86,kvm: move qemu/guest FPU switching out to vcpu_run" on kernel 4.14.96 I can't reproduce
the stress-ng error and I have no segfault or other problems with the guest.
The commit was originally introduced in v4.15-rc3 (Nov 14 2017) and was only recently
backported to 4.14. The other stable kernels before 4.14 didn't get any backport so it looks
like a broken 4.14 backport. That backport also cause problems for other people.
https://bugzilla.kernel.org/show_bug.cgi?id=202419
I've rebooted between the different kernels and rebooted the VM enough to be reasonably sure
that commit is the problem. Stress-ng never lasts more than 10 min with that commit but works
for hours without it.
Steps to reproduce would be to create a qemu/kvm VM with debian stretch, install stress-ng
version 0.07.16 and run "stress-ng --verify --cpu 1".
Here is the qemu-3.1.0 commandline generated by libvirt:
/usr/bin/qemu-system-x86_64 -name guest=debian,debug-threads=on -S -object
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-debian/master-key.aes
-machine pc-i440fx-2.4,accel=kvm,usb=off,dump-guest-core=off -cpu Haswell-noTSX -m 2048
-realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid
0473ded4-d417-4b0e-a4f5-36ba5a2cd675 -no-user-config -nodefaults -chardev
socket,id=charmonitor,fd=21,server,nowait -mon chardev=charmonitor,id=monitor,mode=control
-rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown
-global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on
-device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device
ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device
ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device
ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -drive
if=none,id=drive-ide0-0-1,readonly=on -device
ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=2 -drive
file=/mnt/gemini.61rn.3T/Backups/debian.raw,format=raw,if=none,id=drive-virtio-disk0 -device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-netdev tap,fd=23,id=hostnet0 -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=00:11:22:33:44:55,bus=pci.0,addr=0x3 -spice
port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device
VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x2 -device AC97,id=sound0,bus=pci.0,addr=0x7
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -object
rng-random,id=objrng0,filename=/dev/random -device
virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x8 -sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on
My host kernel .config is big so I put it in a paste: http://sprunge.us/u7YNBt
The patch titled
Subject: mm: migrate: don't rely on PageMovable() of newpage after unlocking it
has been removed from the -mm tree. Its filename was
mm-migrate-dont-rely-on-pagemovable-of-newpage-after-unlocking-it.patch
This patch was dropped because it is obsolete
------------------------------------------------------
From: David Hildenbrand <david(a)redhat.com>
Subject: mm: migrate: don't rely on PageMovable() of newpage after unlocking it
While debugging some crashes related to virtio-balloon deflation that
happened under the old balloon migration code, I stumbled over a race that
still exists today.
What we experienced:
drivers/virtio/virtio_balloon.c:release_pages_balloon():
- WARNING: CPU: 13 PID: 6586 at lib/list_debug.c:59 __list_del_entry+0xa1/0xd0
- list_del corruption. prev->next should be ffffe253961090a0, but was dead000000000100
Turns out after having added the page to a local list when dequeuing, the
page would suddenly be moved to an LRU list before we would free it via
the local list, corrupting both lists. So a page we own and that is !LRU
was moved to an LRU list.
In __unmap_and_move(), we lock the old and newpage and perform the
migration. In case of vitio-balloon, the new page will become movable,
the old page will no longer be movable.
However, after unlocking newpage, there is nothing stopping the newpage
from getting dequeued and freed by virtio-balloon. This
will result in the newpage
1. No longer having PageMovable()
2. Getting moved to the local list before finally freeing it (using
page->lru)
Back in the migration thread in __unmap_and_move(), we would after
unlocking the newpage suddenly no longer have PageMovable(newpage) and
will therefore call putback_lru_page(newpage), modifying page->lru
although that list is still in use by virtio-balloon.
To summarize, we have a race between migrating the newpage and checking
for PageMovable(newpage). Instead of checking PageMovable(newpage), we
can simply rely on is_lru of the original page.
Looks like this was introduced by d6d86c0a7f8d ("mm/balloon_compaction:
redesign ballooned pages management"), which was backported up to 3.12.
Old compaction code used PageBalloon() via -_is_movable_balloon_page()
instead of PageMovable(), however with the same semantics.
Link: http://lkml.kernel.org/r/20190128160403.16657-1-david@redhat.com
Fixes: d6d86c0a7f8d ("mm/balloon_compaction: redesign ballooned pages management")
Signed-off-by: David Hildenbrand <david(a)redhat.com>
Reported-by: Vratislav Bendel <vbendel(a)redhat.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Acked-by: Rafael Aquini <aquini(a)redhat.com>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com>
Cc: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com>
Cc: Jan Kara <jack(a)suse.cz>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: Dominik Brodowski <linux(a)dominikbrodowski.net>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Konstantin Khlebnikov <k.khlebnikov(a)samsung.com>
Cc: Minchan Kim <minchan(a)kernel.org>
Cc: <stable(a)vger.kernel.org> [3.12+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/migrate.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/mm/migrate.c~mm-migrate-dont-rely-on-pagemovable-of-newpage-after-unlocking-it
+++ a/mm/migrate.c
@@ -1135,10 +1135,12 @@ out:
* If migration is successful, decrease refcount of the newpage
* which will not free the page because new page owner increased
* refcounter. As well, if it is LRU page, add the page to LRU
- * list in here.
+ * list in here. Don't rely on PageMovable(newpage), as that could
+ * already have changed after unlocking newpage (e.g.
+ * virtio-balloon deflation).
*/
if (rc == MIGRATEPAGE_SUCCESS) {
- if (unlikely(__PageMovable(newpage)))
+ if (unlikely(!is_lru))
put_page(newpage);
else
putback_lru_page(newpage);
_
Patches currently in -mm which might be from david(a)redhat.com are
mm-balloon-update-comment-about-isolation-migration-compaction.patch
mm-convert-pg_balloon-to-pg_offline.patch
kexec-export-pg_offline-to-vmcoreinfo.patch
xen-balloon-mark-inflated-pages-pg_offline.patch
hv_balloon-mark-inflated-pages-pg_offline.patch
vmw_balloon-mark-inflated-pages-pg_offline.patch
vmw_balloon-mark-inflated-pages-pg_offline-v2.patch
pm-hibernate-use-pfn_to_online_page.patch
pm-hibernate-exclude-all-pageoffline-pages.patch
pm-hibernate-exclude-all-pageoffline-pages-v2.patch
Hi Greg,
Can you please revert this commit in 4.14?
commit e65cd9a20343ea90f576c24c38ee85ab6e7d5fec
Author: Tycho Andersen <tycho(a)tycho.ws>
Date: Tue Feb 20 19:47:47 2018 -0700
seccomp: add a selftest for get_metadata
[ Upstream commit d057dc4e35e16050befa3dda943876dab39cbf80 ]
Let's test that we get the flags correctly, and that we preserve
the filter
index across the ptrace(PTRACE_SECCOMP_GET_METADATA) correctly.
PTRACE_SECCOMP_GET_METADATA was only added in 4.16
(26500475ac1b499d8636ff281311d633909f5d20)
And it's also breaking seccomp_bpf.c compilation for me:
seccomp_bpf.c: In function ‘get_metadata’:
seccomp_bpf.c:2878:26: error: storage size of ‘md’ isn’t known
struct seccomp_metadata md;
^~
-Tommi
Hi Greg,
Can you please pick these two upstream patches to 4.14?
They fix broken perf unwinding for me.
commit 3d20c6246690219881786de10d2dda93f616d0ac
Author: Martin Vuille <
jpmv27(a)aim.com>
Date: Sun Feb 11 16:24:20 2018 -0500
perf unwind: Unwind with libdw doesn't take symfs into account
commit 1fe627da30331024f453faef04d500079b901107
Author: Milian Wolff <
milian.wolff(a)kdab.com>
Date: Mon Oct 29 15:16:44 2018 +0100
perf unwind: Take pgoff into account when reporting elf to libdwfl
-Tommi
From: "Gustavo A. R. Silva" <gustavo(a)embeddedor.com>
[ Upstream commit a37805098900a6e73a55b3a43b7d3bcd987bb3f4 ]
idx can be indirectly controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
drivers/gpu/drm/drm_bufs.c:1420 drm_legacy_freebufs() warn: potential
spectre issue 'dma->buflist' [r] (local cap)
Fix this by sanitizing idx before using it to index dma->buflist
Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].
[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
Signed-off-by: Gustavo A. R. Silva <gustavo(a)embeddedor.com>
Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016095549.GA23586@embedd…
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
drivers/gpu/drm/drm_bufs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 7412acaf3cde..d7d10cabb9bb 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -36,6 +36,8 @@
#include <drm/drmP.h>
#include "drm_legacy.h"
+#include <linux/nospec.h>
+
static struct drm_map_list *drm_find_matching_map(struct drm_device *dev,
struct drm_local_map *map)
{
@@ -1417,6 +1419,7 @@ int drm_legacy_freebufs(struct drm_device *dev, void *data,
idx, dma->buf_count - 1);
return -EINVAL;
}
+ idx = array_index_nospec(idx, dma->buf_count);
buf = dma->buflist[idx];
if (buf->file_priv != file_priv) {
DRM_ERROR("Process %d freeing buffer not owned\n",
--
2.19.1
The patch titled
Subject: Revert "mm, memory_hotplug: initialize struct pages for the full memory section"
has been added to the -mm tree. Its filename is
revert-mm-memory_hotplug-initialize-struct-pages-for-the-full-memory-section.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/revert-mm-memory_hotplug-initializ…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/revert-mm-memory_hotplug-initializ…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Michal Hocko <mhocko(a)suse.com>
Subject: Revert "mm, memory_hotplug: initialize struct pages for the full memory section"
This reverts 2830bf6f05fb3e05b ("mm, memory_hotplug: initialize struct
pages for the full memory section").
The underlying assumption that one sparse section belongs into a single
numa node doesn't hold really. Robert Shteynfeld has reported a boot
failure. The boot log was not captured but his memory layout is as
follows:
[ 0.286954] Early memory node ranges
[ 0.286955] node 1: [mem 0x0000000000001000-0x0000000000090fff]
[ 0.286955] node 1: [mem 0x0000000000100000-0x00000000dbdf8fff]
[ 0.286956] node 1: [mem 0x0000000100000000-0x0000001423ffffff]
[ 0.286956] node 0: [mem 0x0000001424000000-0x0000002023ffffff]
This means that node0 starts in the middle of a memory section which is
also in node1. memmap_init_zone tries to initialize padding of a section
even when it is outside of the given pfn range because there are code
paths (e.g. memory hotplug) which assume that the full worth of memory
section is always initialized. In this particular case, though, such a
range is already intialized and most likely already managed by the page
allocator. Scribbling over those pages corrupts the internal state and
likely blows up when any of those pages gets used.
Link: http://lkml.kernel.org/r/20190125181549.GE20411@dhcp22.suse.cz
Fixes: 2830bf6f05fb ("mm, memory_hotplug: initialize struct pages for the full memory section")
Signed-off-by: Michal Hocko <mhocko(a)suse.com>
Reported-by: Robert Shteynfeld <robert.shteynfeld(a)gmail.com>
Cc: Mikhail Zaslonko <zaslonko(a)linux.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer(a)de.ibm.com>
Cc: Mikhail Gavrilov <mikhail.v.gavrilov(a)gmail.com>
Cc: Dave Hansen <dave.hansen(a)intel.com>
Cc: Alexander Duyck <alexander.h.duyck(a)linux.intel.com>
Cc: Pasha Tatashin <Pavel.Tatashin(a)microsoft.com>
Cc: Martin Schwidefsky <schwidefsky(a)de.ibm.com>
Cc: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/page_alloc.c | 12 ------------
1 file changed, 12 deletions(-)
--- a/mm/page_alloc.c~revert-mm-memory_hotplug-initialize-struct-pages-for-the-full-memory-section
+++ a/mm/page_alloc.c
@@ -5701,18 +5701,6 @@ void __meminit memmap_init_zone(unsigned
cond_resched();
}
}
-#ifdef CONFIG_SPARSEMEM
- /*
- * If the zone does not span the rest of the section then
- * we should at least initialize those pages. Otherwise we
- * could blow up on a poisoned page in some paths which depend
- * on full sections being initialized (e.g. memory hotplug).
- */
- while (end_pfn % PAGES_PER_SECTION) {
- __init_single_page(pfn_to_page(end_pfn), end_pfn, zone, nid);
- end_pfn++;
- }
-#endif
}
#ifdef CONFIG_ZONE_DEVICE
_
Patches currently in -mm which might be from mhocko(a)suse.com are
mm-memory_hotplug-is_mem_section_removable-do-not-pass-the-end-of-a-zone.patch
revert-mm-memory_hotplug-initialize-struct-pages-for-the-full-memory-section.patch
mm-oom-marks-all-killed-tasks-as-oom-victims.patch
memcg-do-not-report-racy-no-eligible-oom-tasks.patch
The patch titled
Subject: mm: migrate: make buffer_migrate_page_norefs() actually succeed
has been added to the -mm tree. Its filename is
mm-migrate-make-buffer_migrate_page_norefs-actually-succeed.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-migrate-make-buffer_migrate_pag…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-migrate-make-buffer_migrate_pag…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Jan Kara <jack(a)suse.cz>
Subject: mm: migrate: make buffer_migrate_page_norefs() actually succeed
Currently, buffer_migrate_page_norefs() was constantly failing because
buffer_migrate_lock_buffers() grabbed reference on each buffer. In fact,
there's no reason for buffer_migrate_lock_buffers() to grab any buffer
references as the page is locked during all our operation and thus nobody
can reclaim buffers from the page. So remove grabbing of buffer
references which also makes buffer_migrate_page_norefs() succeed.
Link: http://lkml.kernel.org/r/20190116131217.7226-1-jack@suse.cz
Fixes: 89cb0888ca14 "mm: migrate: provide buffer_migrate_page_norefs()"
Signed-off-by: Jan Kara <jack(a)suse.cz>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work(a)gmail.com>
Cc: Pavel Machek <pavel(a)ucw.cz>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: David Rientjes <rientjes(a)google.com>
Cc: Michal Hocko <mhocko(a)kernel.org>
Cc: Zi Yan <zi.yan(a)cs.rutgers.edu>
Cc: Johannes Weiner <hannes(a)cmpxchg.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/migrate.c | 5 -----
1 file changed, 5 deletions(-)
--- a/mm/migrate.c~mm-migrate-make-buffer_migrate_page_norefs-actually-succeed
+++ a/mm/migrate.c
@@ -709,7 +709,6 @@ static bool buffer_migrate_lock_buffers(
/* Simple case, sync compaction */
if (mode != MIGRATE_ASYNC) {
do {
- get_bh(bh);
lock_buffer(bh);
bh = bh->b_this_page;
@@ -720,18 +719,15 @@ static bool buffer_migrate_lock_buffers(
/* async case, we cannot block on lock_buffer so use trylock_buffer */
do {
- get_bh(bh);
if (!trylock_buffer(bh)) {
/*
* We failed to lock the buffer and cannot stall in
* async migration. Release the taken locks
*/
struct buffer_head *failed_bh = bh;
- put_bh(failed_bh);
bh = head;
while (bh != failed_bh) {
unlock_buffer(bh);
- put_bh(bh);
bh = bh->b_this_page;
}
return false;
@@ -818,7 +814,6 @@ unlock_buffers:
bh = head;
do {
unlock_buffer(bh);
- put_bh(bh);
bh = bh->b_this_page;
} while (bh != head);
_
Patches currently in -mm which might be from jack(a)suse.cz are
mm-migrate-make-buffer_migrate_page_norefs-actually-succeed.patch
The patch titled
Subject: mm: migrate: don't rely on PageMovable() of newpage after unlocking it
has been added to the -mm tree. Its filename is
mm-migrate-dont-rely-on-pagemovable-of-newpage-after-unlocking-it.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-migrate-dont-rely-on-pagemovabl…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-migrate-dont-rely-on-pagemovabl…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: David Hildenbrand <david(a)redhat.com>
Subject: mm: migrate: don't rely on PageMovable() of newpage after unlocking it
While debugging some crashes related to virtio-balloon deflation that
happened under the old balloon migration code, I stumbled over a race that
still exists today.
What we experienced:
drivers/virtio/virtio_balloon.c:release_pages_balloon():
- WARNING: CPU: 13 PID: 6586 at lib/list_debug.c:59 __list_del_entry+0xa1/0xd0
- list_del corruption. prev->next should be ffffe253961090a0, but was dead000000000100
Turns out after having added the page to a local list when dequeuing, the
page would suddenly be moved to an LRU list before we would free it via
the local list, corrupting both lists. So a page we own and that is !LRU
was moved to an LRU list.
In __unmap_and_move(), we lock the old and newpage and perform the
migration. In case of vitio-balloon, the new page will become movable,
the old page will no longer be movable.
However, after unlocking newpage, there is nothing stopping the newpage
from getting dequeued and freed by virtio-balloon. This
will result in the newpage
1. No longer having PageMovable()
2. Getting moved to the local list before finally freeing it (using
page->lru)
Back in the migration thread in __unmap_and_move(), we would after
unlocking the newpage suddenly no longer have PageMovable(newpage) and
will therefore call putback_lru_page(newpage), modifying page->lru
although that list is still in use by virtio-balloon.
To summarize, we have a race between migrating the newpage and checking
for PageMovable(newpage). Instead of checking PageMovable(newpage), we
can simply rely on is_lru of the original page.
Looks like this was introduced by d6d86c0a7f8d ("mm/balloon_compaction:
redesign ballooned pages management"), which was backported up to 3.12.
Old compaction code used PageBalloon() via -_is_movable_balloon_page()
instead of PageMovable(), however with the same semantics.
Link: http://lkml.kernel.org/r/20190128160403.16657-1-david@redhat.com
Fixes: d6d86c0a7f8d ("mm/balloon_compaction: redesign ballooned pages management")
Signed-off-by: David Hildenbrand <david(a)redhat.com>
Reported-by: Vratislav Bendel <vbendel(a)redhat.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Acked-by: Rafael Aquini <aquini(a)redhat.com>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com>
Cc: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com>
Cc: Jan Kara <jack(a)suse.cz>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: Dominik Brodowski <linux(a)dominikbrodowski.net>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Konstantin Khlebnikov <k.khlebnikov(a)samsung.com>
Cc: Minchan Kim <minchan(a)kernel.org>
Cc: <stable(a)vger.kernel.org> [3.12+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/migrate.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/mm/migrate.c~mm-migrate-dont-rely-on-pagemovable-of-newpage-after-unlocking-it
+++ a/mm/migrate.c
@@ -1135,10 +1135,12 @@ out:
* If migration is successful, decrease refcount of the newpage
* which will not free the page because new page owner increased
* refcounter. As well, if it is LRU page, add the page to LRU
- * list in here.
+ * list in here. Don't rely on PageMovable(newpage), as that could
+ * already have changed after unlocking newpage (e.g.
+ * virtio-balloon deflation).
*/
if (rc == MIGRATEPAGE_SUCCESS) {
- if (unlikely(__PageMovable(newpage)))
+ if (unlikely(!is_lru))
put_page(newpage);
else
putback_lru_page(newpage);
_
Patches currently in -mm which might be from david(a)redhat.com are
mm-balloon-update-comment-about-isolation-migration-compaction.patch
mm-convert-pg_balloon-to-pg_offline.patch
kexec-export-pg_offline-to-vmcoreinfo.patch
xen-balloon-mark-inflated-pages-pg_offline.patch
hv_balloon-mark-inflated-pages-pg_offline.patch
vmw_balloon-mark-inflated-pages-pg_offline.patch
vmw_balloon-mark-inflated-pages-pg_offline-v2.patch
pm-hibernate-use-pfn_to_online_page.patch
pm-hibernate-exclude-all-pageoffline-pages.patch
pm-hibernate-exclude-all-pageoffline-pages-v2.patch
mm-migrate-dont-rely-on-pagemovable-of-newpage-after-unlocking-it.patch
The patch below does not apply to the 4.20-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From a1e1cb72d96491277ede8d257ce6b48a381dd336 Mon Sep 17 00:00:00 2001
From: Mike Snitzer <snitzer(a)redhat.com>
Date: Thu, 17 Jan 2019 10:48:01 -0500
Subject: [PATCH] dm: fix redundant IO accounting for bios that need splitting
The risk of redundant IO accounting was not taken into consideration
when commit 18a25da84354 ("dm: ensure bio submission follows a
depth-first tree walk") introduced IO splitting in terms of recursion
via generic_make_request().
Fix this by subtracting the split bio's payload from the IO stats that
were already accounted for by start_io_acct() upon dm_make_request()
entry. This repeat oscillation of the IO accounting, up then down,
isn't ideal but refactoring DM core's IO splitting to pre-split bios
_before_ they are accounted turned out to be an excessive amount of
change that will need a full development cycle to refine and verify.
Before this fix:
/dev/mapper/stripe_dev is a 4-way stripe using a 32k chunksize, so
bios are split on 32k boundaries.
# fio --name=16M --filename=/dev/mapper/stripe_dev --rw=write --bs=64k --size=16M \
--iodepth=1 --ioengine=libaio --direct=1 --refill_buffers
with debugging added:
[103898.310264] device-mapper: core: start_io_acct: dm-2 WRITE bio->bi_iter.bi_sector=0 len=128
[103898.318704] device-mapper: core: __split_and_process_bio: recursing for following split bio:
[103898.329136] device-mapper: core: start_io_acct: dm-2 WRITE bio->bi_iter.bi_sector=64 len=64
...
16M written yet 136M (278528 * 512b) accounted:
# cat /sys/block/dm-2/stat | awk '{ print $7 }'
278528
After this fix:
16M written and 16M (32768 * 512b) accounted:
# cat /sys/block/dm-2/stat | awk '{ print $7 }'
32768
Fixes: 18a25da84354 ("dm: ensure bio submission follows a depth-first tree walk")
Cc: stable(a)vger.kernel.org # 4.16+
Reported-by: Bryan Gurney <bgurney(a)redhat.com>
Reviewed-by: Ming Lei <ming.lei(a)redhat.com>
Signed-off-by: Mike Snitzer <snitzer(a)redhat.com>
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index fcb97b0a5743..fbadda68e23b 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -1584,6 +1584,9 @@ static void init_clone_info(struct clone_info *ci, struct mapped_device *md,
ci->sector = bio->bi_iter.bi_sector;
}
+#define __dm_part_stat_sub(part, field, subnd) \
+ (part_stat_get(part, field) -= (subnd))
+
/*
* Entry point to split a bio into clones and submit them to the targets.
*/
@@ -1638,6 +1641,19 @@ static blk_qc_t __split_and_process_bio(struct mapped_device *md,
struct bio *b = bio_split(bio, bio_sectors(bio) - ci.sector_count,
GFP_NOIO, &md->queue->bio_split);
ci.io->orig_bio = b;
+
+ /*
+ * Adjust IO stats for each split, otherwise upon queue
+ * reentry there will be redundant IO accounting.
+ * NOTE: this is a stop-gap fix, a proper fix involves
+ * significant refactoring of DM core's bio splitting
+ * (by eliminating DM's splitting and just using bio_split)
+ */
+ part_stat_lock();
+ __dm_part_stat_sub(&dm_disk(md)->part0,
+ sectors[op_stat_group(bio_op(bio))], ci.sector_count);
+ part_stat_unlock();
+
bio_chain(b, bio);
ret = generic_make_request(bio);
break;
From: "Gustavo A. R. Silva" <gustavo(a)embeddedor.com>
[ Upstream commit a37805098900a6e73a55b3a43b7d3bcd987bb3f4 ]
idx can be indirectly controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
drivers/gpu/drm/drm_bufs.c:1420 drm_legacy_freebufs() warn: potential
spectre issue 'dma->buflist' [r] (local cap)
Fix this by sanitizing idx before using it to index dma->buflist
Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].
[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
Signed-off-by: Gustavo A. R. Silva <gustavo(a)embeddedor.com>
Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016095549.GA23586@embedd…
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
drivers/gpu/drm/drm_bufs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index f1a204d253cc..ac22b8d86249 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -36,6 +36,8 @@
#include <drm/drmP.h>
#include "drm_legacy.h"
+#include <linux/nospec.h>
+
static struct drm_map_list *drm_find_matching_map(struct drm_device *dev,
struct drm_local_map *map)
{
@@ -1332,6 +1334,7 @@ int drm_legacy_freebufs(struct drm_device *dev, void *data,
idx, dma->buf_count - 1);
return -EINVAL;
}
+ idx = array_index_nospec(idx, dma->buf_count);
buf = dma->buflist[idx];
if (buf->file_priv != file_priv) {
DRM_ERROR("Process %d freeing buffer not owned\n",
--
2.19.1
From: "Gustavo A. R. Silva" <gustavo(a)embeddedor.com>
[ Upstream commit a37805098900a6e73a55b3a43b7d3bcd987bb3f4 ]
idx can be indirectly controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
drivers/gpu/drm/drm_bufs.c:1420 drm_legacy_freebufs() warn: potential
spectre issue 'dma->buflist' [r] (local cap)
Fix this by sanitizing idx before using it to index dma->buflist
Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].
[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
Signed-off-by: Gustavo A. R. Silva <gustavo(a)embeddedor.com>
Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016095549.GA23586@embedd…
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
drivers/gpu/drm/drm_bufs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index adb1dd7fde5f..9ccd7d702cd3 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -36,6 +36,8 @@
#include <drm/drmP.h>
#include "drm_legacy.h"
+#include <linux/nospec.h>
+
static struct drm_map_list *drm_find_matching_map(struct drm_device *dev,
struct drm_local_map *map)
{
@@ -1413,6 +1415,7 @@ int drm_legacy_freebufs(struct drm_device *dev, void *data,
idx, dma->buf_count - 1);
return -EINVAL;
}
+ idx = array_index_nospec(idx, dma->buf_count);
buf = dma->buflist[idx];
if (buf->file_priv != file_priv) {
DRM_ERROR("Process %d freeing buffer not owned\n",
--
2.19.1