February 2019 - Linux-stable-mirror

[PATCH v2] drm/vgem: fix use-after-free when drm_gem_handle_create() fails

by Eric Biggers

From: Eric Biggers <ebiggers(a)google.com> If drm_gem_handle_create() fails in vgem_gem_create(), then the drm_vgem_gem_object is freed twice: once when the reference is dropped by drm_gem_object_put_unlocked(), and again by __vgem_gem_destroy(). This was hit by syzkaller using fault injection. Fix it by skipping the second free. Reported-by: syzbot+e73f2fb5ed5a5df36d33(a)syzkaller.appspotmail.com Fixes: af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces") Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Laura Abbott <labbott(a)redhat.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: stable(a)vger.kernel.org Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- drivers/gpu/drm/vgem/vgem_drv.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c index 5930facd6d2d8..11a8f99ba18c5 100644 --- a/drivers/gpu/drm/vgem/vgem_drv.c +++ b/drivers/gpu/drm/vgem/vgem_drv.c @@ -191,13 +191,9 @@ static struct drm_gem_object *vgem_gem_create(struct drm_device *dev, ret = drm_gem_handle_create(file, &obj->base, handle); drm_gem_object_put_unlocked(&obj->base); if (ret) - goto err; + return ERR_PTR(ret); return &obj->base; - -err: - __vgem_gem_destroy(obj); - return ERR_PTR(ret); } static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, -- 2.21.0.rc2.261.ga7da99ff1b-goog

5 years, 2 months

3
2
0 0

[PATCH] powerpc/32: Clear on-stack exception marker upon exception return

by Christophe Leroy

Clear the on-stack STACK_FRAME_REGS_MARKER on exception exit in order to avoid confusing stacktrace like the one below. Call Trace: [c0e9dca0] [c01c42a0] print_address_description+0x64/0x2bc (unreliable) [c0e9dcd0] [c01c4684] kasan_report+0xfc/0x180 [c0e9dd10] [c0895130] memchr+0x24/0x74 [c0e9dd30] [c00a9e38] msg_print_text+0x124/0x574 [c0e9dde0] [c00ab710] console_unlock+0x114/0x4f8 [c0e9de40] [c00adc60] vprintk_emit+0x188/0x1c4 --- interrupt: c0e9df00 at 0x400f330 LR = init_stack+0x1f00/0x2000 [c0e9de80] [c00ae3c4] printk+0xa8/0xcc (unreliable) [c0e9df20] [c0c27e44] early_irq_init+0x38/0x108 [c0e9df50] [c0c15434] start_kernel+0x310/0x488 [c0e9dff0] [00003484] 0x3484 With this patch the trace becomes: Call Trace: [c0e9dca0] [c01c42c0] print_address_description+0x64/0x2bc (unreliable) [c0e9dcd0] [c01c46a4] kasan_report+0xfc/0x180 [c0e9dd10] [c0895150] memchr+0x24/0x74 [c0e9dd30] [c00a9e58] msg_print_text+0x124/0x574 [c0e9dde0] [c00ab730] console_unlock+0x114/0x4f8 [c0e9de40] [c00adc80] vprintk_emit+0x188/0x1c4 [c0e9de80] [c00ae3e4] printk+0xa8/0xcc [c0e9df20] [c0c27e44] early_irq_init+0x38/0x108 [c0e9df50] [c0c15434] start_kernel+0x310/0x488 [c0e9dff0] [00003484] 0x3484 Cc: stable(a)vger.kernel.org Cc: Nicolai Stange <nstange(a)suse.de> Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr> --- arch/powerpc/kernel/entry_32.S | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S index 96dce6a4b61e..b61cfd29c76f 100644 --- a/arch/powerpc/kernel/entry_32.S +++ b/arch/powerpc/kernel/entry_32.S @@ -730,6 +730,9 @@ fast_exception_return: mtcr r10 lwz r10,_LINK(r11) mtlr r10 + /* Clear the exception_marker on the stack to avoid confusing stacktrace */ + li r10, 0 + stw r10, 8(r11) REST_GPR(10, r11) #if defined(CONFIG_PPC_8xx) && defined(CONFIG_PERF_EVENTS) mtspr SPRN_NRI, r0 @@ -961,6 +964,9 @@ END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX) mtcrf 0xFF,r10 mtlr r11 + /* Clear the exception_marker on the stack to avoid confusing stacktrace */ + li r10, 0 + stw r10, 8(r1) /* * Once we put values in SRR0 and SRR1, we are in a state * where exceptions are not recoverable, since taking an @@ -997,6 +1003,9 @@ exc_exit_restart_end: mtlr r11 lwz r10,_CCR(r1) mtcrf 0xff,r10 + /* Clear the exception_marker on the stack to avoid confusing stacktrace */ + li r10, 0 + stw r10, 8(r1) REST_2GPRS(9, r1) .globl exc_exit_restart exc_exit_restart: -- 2.13.3

5 years, 2 months

2
1
0 0

Re: [RFC] kprobes: Fix locking in recycle_rp_inst

by Jiri Olsa

On Wed, Feb 27, 2019 at 05:38:46PM +0900, Masami Hiramatsu wrote: SNIP > > When we switch it to raw_spin_lock_irqsave the return probe > > on _raw_spin_lock starts working. > > Yes, there can be a race between probes and probe on irq handler. > > kretprobe_hash_lock()/kretprobe_hash_unlock() are safe because > those disables irqs. Only recycle_rp_inst() has this problem. > > Acked-by: Masami Hiramatsu <mhiramat(a)kernel.org> > > And this is one of the oldest bug in kprobe. > > commit ef53d9c5e4da ("kprobes: improve kretprobe scalability with hashed locking") > > introduced the spin_lock(&rp->lock) in recycle_rp_inst() but forgot to disable irqs. > And > > commit c9becf58d935 ("[PATCH] kretprobe: kretprobe-booster") ok, so I'll add: Fixes: c9becf58d935 ("[PATCH] kretprobe: kretprobe-booster") > > introduced assembly-based trampoline which didn't disable irq. > > Could you add Cc:stable to this patch too? sure, attaching patch with updated changelog thanks, jirka --- We can call recycle_rp_inst from both task and irq contexts, so we should irqsave/irqrestore locking functions. I wasn't able to hit this particular lockup, but I found it while checking on why return probe on _raw_spin_lock locks the system, reported by David by using bpftrace on simple script, like: kprobe:_raw_spin_lock { @time[tid] = nsecs; @symb[tid] = arg0; } kretprobe:_raw_spin_lock / @time[tid] / { delete(@time[tid]); delete(@symb[tid]); } or by perf tool: # perf probe -a _raw_spin_lock:%return # perf record -e probe:_raw_spin_lock__return -a The thing is that the _raw_spin_lock call in recycle_rp_inst, is the only one that return probe code paths call and it will trigger another kprobe instance while already processing one and lock up on kretprobe_table_lock lock: #12 [ffff99c337403d28] queued_spin_lock_slowpath at ffffffff9712693b #13 [ffff99c337403d28] _raw_spin_lock_irqsave at ffffffff9794c100 #14 [ffff99c337403d38] pre_handler_kretprobe at ffffffff9719435c #15 [ffff99c337403d68] kprobe_ftrace_handler at ffffffff97059f12 #16 [ffff99c337403d98] ftrace_ops_assist_func at ffffffff971a0421 #17 [ffff99c337403dd8] handle_edge_irq at ffffffff97139f55 #18 [ffff99c337403df0] handle_edge_irq at ffffffff97139f55 #19 [ffff99c337403e58] _raw_spin_lock at ffffffff9794c111 #20 [ffff99c337403e88] _raw_spin_lock at ffffffff9794c115 #21 [ffff99c337403ea8] trampoline_handler at ffffffff97058a8f #22 [ffff99c337403f00] kretprobe_trampoline at ffffffff970586d5 #23 [ffff99c337403fb0] handle_irq at ffffffff97027b1f #24 [ffff99c337403fc0] do_IRQ at ffffffff97a01bc9 --- <IRQ stack> --- #25 [ffffa5c3c1f9fb38] ret_from_intr at ffffffff97a0098f [exception RIP: smp_call_function_many+460] RIP: ffffffff9716685c RSP: ffffa5c3c1f9fbe0 RFLAGS: 00000202 RAX: 0000000000000005 RBX: ffff99c337421c80 RCX: ffff99c337566260 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff99c337421c88 RBP: ffff99c337421c88 R8: 0000000000000001 R9: ffffffff98352940 R10: ffff99c33703c910 R11: ffffffff9794c110 R12: ffffffff97055680 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000040 ORIG_RAX: ffffffffffffffde CS: 0010 SS: 0018 #26 [ffffa5c3c1f9fc20] on_each_cpu at ffffffff97166918 #27 [ffffa5c3c1f9fc40] ftrace_replace_code at ffffffff97055a34 #28 [ffffa5c3c1f9fc88] ftrace_modify_all_code at ffffffff971a3552 #29 [ffffa5c3c1f9fca8] arch_ftrace_update_code at ffffffff97055a6c #30 [ffffa5c3c1f9fcb0] ftrace_run_update_code at ffffffff971a3683 #31 [ffffa5c3c1f9fcc0] ftrace_startup at ffffffff971a6638 #32 [ffffa5c3c1f9fce8] register_ftrace_function at ffffffff971a66a0 When we switch it to raw_spin_lock_irqsave the return probe on _raw_spin_lock starts working. Fixes: c9becf58d935 ("[PATCH] kretprobe: kretprobe-booster") Cc: stable(a)vger.kernel.org Reported-by: David Valin <dvalin(a)redhat.com> Acked-by: Masami Hiramatsu <mhiramat(a)kernel.org> Signed-off-by: Jiri Olsa <jolsa(a)kernel.org> --- kernel/kprobes.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/kernel/kprobes.c b/kernel/kprobes.c index c83e54727131..c82056b354cc 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -1154,9 +1154,11 @@ void recycle_rp_inst(struct kretprobe_instance *ri, hlist_del(&ri->hlist); INIT_HLIST_NODE(&ri->hlist); if (likely(rp)) { - raw_spin_lock(&rp->lock); + unsigned long flags; + + raw_spin_lock_irqsave(&rp->lock, flags); hlist_add_head(&ri->hlist, &rp->free_instances); - raw_spin_unlock(&rp->lock); + raw_spin_unlock_irqrestore(&rp->lock, flags); } else /* Unregistering */ hlist_add_head(&ri->hlist, head); -- 2.17.2

5 years, 2 months

3
2
0 0

Re: Patch "sfc: suppress duplicate nvmem partition types in efx_ef10_mtd_probe" has been added to the 4.20-stable tree

by Edward Cree

On 27/02/19 22:31, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > sfc: suppress duplicate nvmem partition types in efx_ef10_mtd_probe > > to the 4.20-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: > sfc-suppress-duplicate-nvmem-partition-types-in-efx_.patch > and it can be found in the queue-4.20 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. If you are taking this patch, you also need c65285428b6e sfc: initialise found bitmap in efx_ef10_mtd_probe which fixes bugs in the above patch; I don't currently see it in the stable-queue. (Also, it's not clear whether the original fix is really needed on stable kernels; while the bug is present there, it is harmless until a v5.0-rc1 commit, probably c4dfa25ab307 ("mtd: add support for reading MTD devices via the nvmem API") interacts with it.) The above remarks apply to all six stable trees for which this patch has been queued. -Ed The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited.

5 years, 2 months

2
1
0 0

[4.14] powerpc: Always initialize input array when calling epapr_hypercall()

by A. Wilcox

Kernel 4.14 fails to build with GCC 8 on powerpc64, due to 'in' being uninitialised in epapr_hypercall*. This is fixed in commit 186b8f1587c79c2fa04bfa392fdf08 upstream, and this commit applies cleanly to the 4.14 tree. This commit is already on the 4.19 branch. Best, --arw -- A. Wilcox (awilfox) Project Lead, Adélie Linux https://www.adelielinux.org

5 years, 2 months

2
1
0 0

Re: [PATCH 1/1] iommu/vt-d: Check identity map for hot-added devices

by Joerg Roedel

Hi Sasha, Thanks for the heads-up! On Tue, Feb 26, 2019 at 09:24:00PM +0000, Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a -stable tag. > The stable tag indicates that it's relevant for the following trees: all > > The bot has tested the following trees: v4.20.12, v4.19.25, v4.14.103, v4.9.160, v4.4.176, v3.18.136. > Lu Baolu, can you please check for which stable trees this commit is relevant and provide the backports of the patch (with dependencies if necessary) to the relevant stable trees? Thanks, Joerg

5 years, 2 months

2
1
0 0

Stable queue: queue-4.20

by CKI

Hello, We ran automated tests on a patchset that was proposed for merging into this kernel tree. The patches were applied to: Repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Commit: 0f7c162c1df5 Linux 4.20.13 The results of these automated tests are provided below. Overall result: PASSED Merge: OK Compile: OK Tests: OK 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 ----- We cloned this repository and checked out a ref: Repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Ref: 0f7c162c1df5 Linux 4.20.13 We then merged the following patches with `git am`: genirq-matrix-improve-target-cpu-selection-for-manag.patch scsi-libsas-fix-rphy-phy_identifier-for-phys-with-end-devices-attached.patch drm-msm-unblock-writer-if-reader-closes-file.patch asoc-intel-haswell-broadwell-fix-setting-for-.dynami.patch alsa-compress-prevent-potential-divide-by-zero-bugs.patch asoc-rt5682-fix-recording-no-sound-issue.patch asoc-variable-val-in-function-rt274_i2c_probe-could-.patch clk-tegra-dfll-fix-a-potential-oop-in-remove.patch clk-sysfs-fix-invalid-json-in-clk_dump.patch clk-vc5-abort-clock-configuration-without-upstream-c.patch thermal-int340x_thermal-fix-a-null-vs-is_err-check.patch usb-dwc3-gadget-synchronize_irq-dwc-irq-in-suspend.patch usb-dwc3-gadget-fix-the-uninitialized-link_state-whe.patch usb-gadget-potential-null-dereference-on-allocation-.patch hid-i2c-hid-disable-runtime-pm-on-goodix-touchpad.patch asoc-core-make-snd_soc_find_component-more-robust.patch selftests-rtc-rtctest-fix-alarm-tests.patch selftests-rtc-rtctest-add-alarm-test-on-minute-bound.patch genirq-make-sure-the-initial-affinity-is-not-empty.patch x86-mm-mem_encrypt-fix-erroneous-sizeof.patch asoc-rt5682-fix-pll-source-register-definitions.patch asoc-dapm-change-snprintf-to-scnprintf-for-possible-.patch asoc-imx-audmux-change-snprintf-to-scnprintf-for-pos.patch selftests-vm-gup_benchmark.c-match-gup-struct-to-ker.patch phy-ath79-usb-fix-the-power-on-error-path.patch phy-ath79-usb-fix-the-main-reset-name-to-match-the-d.patch selftests-seccomp-use-ldlibs-instead-of-ldflags.patch selftests-gpio-mockup-chardev-check-asprintf-for-err.patch irqchip-gic-v3-mbi-fix-uninitialized-mbi_lock.patch arc-fix-__ffs-return-value-to-avoid-build-warnings.patch arc-show_regs-lockdep-avoid-page-allocator.patch drivers-thermal-int340x_thermal-fix-sysfs-race-condi.patch staging-rtl8723bs-fix-build-error-with-clang-when-in.patch mac80211-fix-miscounting-of-ttl-dropped-frames.patch sched-wait-fix-rcuwait_wake_up-ordering.patch sched-wake_q-fix-wakeup-ordering-for-wake_q.patch futex-fix-possible-missed-wakeup.patch locking-rwsem-fix-possible-missed-wakeup.patch drm-amd-powerplay-od-setting-fix-on-vega10.patch tty-serial-qcom_geni_serial-allow-mctrl-when-flow-co.patch serial-fsl_lpuart-fix-maximum-acceptable-baud-rate-w.patch drm-sun4i-hdmi-fix-usage-of-tmds-clock.patch staging-android-ion-support-cpu-access-during-dma_bu.patch direct-io-allow-direct-writes-to-empty-inodes.patch writeback-synchronize-sync-2-against-cgroup-writebac.patch scsi-lpfc-nvme-avoid-hang-use-after-free-when-destro.patch scsi-lpfc-nvmet-avoid-hang-use-after-free-when-destr.patch scsi-csiostor-fix-null-pointer-dereference-in-csio_v.patch net-altera_tse-fix-connect_local_phy-error-path.patch hv_netvsc-fix-ethtool-change-hash-key-error.patch hv_netvsc-refactor-assignments-of-struct-netvsc_devi.patch hv_netvsc-fix-hash-key-value-reset-after-other-ops.patch sfc-suppress-duplicate-nvmem-partition-types-in-efx_.patch nvme-rdma-fix-timeout-handler.patch nvme-multipath-drop-optimization-for-static-ana-grou.patch cifs-fix-memory-leak-of-an-allocated-cifs_ntsd-struc.patch drm-msm-fix-a6xx-support-for-opp-level.patch drm-msm-avoid-unused-function-warning.patch net-usb-asix-ax88772_bind-return-error-when-hw_reset.patch net-dev_is_mac_header_xmit-true-for-arphrd_rawip.patch ibmveth-do-not-process-frames-after-calling-napi_res.patch mac80211-don-t-initiate-tdls-connection-if-station-i.patch mac80211-add-attribute-aligned-2-to-struct-action.patch cfg80211-extend-range-deviation-for-dmg.patch svm-fix-avic-incomplete-ipi-emulation.patch kvm-nsvm-clear-events-pending-from-svm_complete_inte.patch kvm-selftests-fix-region-overlap-check-in-kvm_util.patch kvm-selftests-check-returned-evmcs-version-range.patch Compile ------- We compiled the kernel for 3 architectures: powerpc64le: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/ppc64le/294c7281365aa60159a34db264… aarch64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/aarch64/b6d2618dbc1911b951d001551e… x86_64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/x86_64/b442c9949114b776daf70c808e6… Tests ----- We booted each kernel and ran the following tests: powerpc: PASSED: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… PASSED: LTP lite - release 20190115 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… PASSED: Loopdev Sanity - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#filesystems/… PASSED: xfstests: xfs - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… PASSED: AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu PASSED: Ethernet drivers sanity - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/networking/… WAIVED: PASSED: httpd: php sanity - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/htt… WAIVED: PASSED: tuned: tune-processes-through-perf - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/tun… PASSED: Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us… arm64: PASSED: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… PASSED: LTP lite - release 20190115 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… PASSED: Loopdev Sanity - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#filesystems/… PASSED: xfstests: xfs - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… PASSED: AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu PASSED: Ethernet drivers sanity - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/networking/… WAIVED: PASSED: httpd: php sanity - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/htt… WAIVED: PASSED: tuned: tune-processes-through-perf - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/tun… PASSED: Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us… x86_64: PASSED: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… PASSED: LTP lite - release 20190115 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… PASSED: Loopdev Sanity - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#filesystems/… PASSED: xfstests: xfs - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… PASSED: AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu PASSED: Ethernet drivers sanity - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/networking/… WAIVED: PASSED: httpd: php sanity - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/htt… WAIVED: PASSED: tuned: tune-processes-through-perf - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/tun… PASSED: Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us…

5 years, 2 months

1
0
0 0

Re: [PATCH] numa: Change get_mempolicy() to use nr_node_ids instead of MAX_NUMNODES

by Vlastimil Babka

On 2/11/19 8:27 PM, Andrew Morton wrote: > On Mon, 11 Feb 2019 10:02:45 -0800 <rcampbell(a)nvidia.com> wrote: > >> From: Ralph Campbell <rcampbell(a)nvidia.com> >> >> The system call, get_mempolicy() [1], passes an unsigned long *nodemask >> pointer and an unsigned long maxnode argument which specifies the >> length of the user's nodemask array in bits (which is rounded up). >> The manual page says that if the maxnode value is too small, >> get_mempolicy will return EINVAL but there is no system call to return >> this minimum value. To determine this value, some programs search >> /proc/<pid>/status for a line starting with "Mems_allowed:" and use >> the number of digits in the mask to determine the minimum value. >> A recent change to the way this line is formatted [2] causes these >> programs to compute a value less than MAX_NUMNODES so get_mempolicy() >> returns EINVAL. >> >> Change get_mempolicy(), the older compat version of get_mempolicy(), and >> the copy_nodes_to_user() function to use nr_node_ids instead of >> MAX_NUMNODES, thus preserving the defacto method of computing the >> minimum size for the nodemask array and the maxnode argument. >> >> [1] http://man7.org/linux/man-pages/man2/get_mempolicy.2.html >> [2] https://lore.kernel.org/lkml/1545405631-6808-1-git-send-email-longman@redha… Please, the next time include linux-api and people involved in the previous thread [1] into the CC list. Likely there should have been a Suggested-by: for Alexander as well. >> > > Ugh, what a mess. I'm afraid it's even somewhat worse mess now. > For a start, that's a crazy interface. I wish that had been brought to > our attention so we could have provided a sane way for userspace to > determine MAX_NUMNODES. > > Secondly, 4fb8e5b89bcbbb ("include/linux/nodemask.h: use nr_node_ids > (not MAX_NUMNODES) in __nodemask_pr_numnodes()") introduced a There's no such commit, that sha was probably from linux-next. The patch is still in mmotm [1]. Luckily, I would say. Maybe Linus or some automation could run some script to check for bogus Fixes tags before accepting patches? > regession. The proposed get_mempolicy() change appears to be a good > one, but is a strange way of addressing the regression. I suppose it's > acceptable, as long as this change is backported into kernels which > have 4fb8e5b89bcbbb. Based on the non-existing sha, hopefully it wasn't backported anywhere, but maybe some AI did anyway. Ah, seems like it indeed made it as far as 4.9, as a fix for non-existing commit and without proper linux-api consideration :( I guess it's too late to revert it for 5.0. Hopefully the change is really safe and won't break anything, i.e. hopefully nobody was determining MAX_NUMNODES by increasing buffer size until get_mempolicy() stopped returning EINVAL. Or other problem in e.g. CRIU context. What about the manpage? It says "The value specified by maxnode is less than the number of node IDs supported by the system." which could be perhaps applied both to nr_node_ids or MAX_NUMNODES. Or should we update it? [1] https://lore.kernel.org/linux-mm/631c44cc-df2d-40d4-a537-d24864df0679@nvidi… [2] https://www.ozlabs.org/~akpm/mmotm/broken-out/include-linux-nodemaskh-use-n…

5 years, 2 months

2
2
0 0

Re: [Intel-gfx] [PATCH] drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake.

by Chris Wilson

Quoting Kenneth Graunke (2018-01-05 06:06:34) > On Thursday, January 4, 2018 4:41:35 PM PST Rodrigo Vivi wrote: > > On Thu, Jan 04, 2018 at 11:39:23PM +0000, Kenneth Graunke wrote: > > > On Thursday, January 4, 2018 1:23:06 PM PST Chris Wilson wrote: > > > > Quoting Kenneth Graunke (2018-01-04 19:38:05) > > > > > Geminilake requires the 3D driver to select whether barriers are > > > > > intended for compute shaders, or tessellation control shaders, by > > > > > whacking a "Barrier Mode" bit in SLICE_COMMON_ECO_CHICKEN1 when > > > > > switching pipelines. Failure to do this properly can result in GPU > > > > > hangs. > > > > > > > > > > Unfortunately, this means it needs to switch mid-batch, so only > > > > > userspace can properly set it. To facilitate this, the kernel needs > > > > > to whitelist the register. > > > > > > > > > > Signed-off-by: Kenneth Graunke <kenneth(a)whitecape.org> > > > > > Cc: stable(a)vger.kernel.org > > > > > --- > > > > > drivers/gpu/drm/i915/i915_reg.h | 2 ++ > > > > > drivers/gpu/drm/i915/intel_engine_cs.c | 5 +++++ > > > > > 2 files changed, 7 insertions(+) > > > > > > > > > > Hello, > > > > > > > > > > We unfortunately need to whitelist an extra register for GPU hang fix > > > > > on Geminilake. Here's the corresponding Mesa patch: > > > > > > > > Thankfully it appears to be context saved. Has a w/a name been assigned > > > > for this? > > > > -Chris > > > > > > There doesn't appear to be one. The workaround page lists it, but there > > > is no name. The register description has a note saying that you need to > > > set this, but doesn't call it out as a workaround. > > > > It mentions only BXT:ALL, but not mention to GLK. > > > > Should we add to both then? > > Well, that's irritating. On the workarounds page, it does indeed say > "BXT" with no mention of GLK. But the workaround text says to set > "SLICE_COMMON_CHICKEN_ECO1 Barrier Mode [...] (bit 7 of MMIO 0x731C)." > > Looking at the register definition for SLICE_COMMON_ECO_CHICKEN1, bit 7 > is "Barrier Mode" on [GLK] only, with no mention of BXT. It's marked > reserved PBC on [SKL+, not GLK, not KBL]. On KBL it's something else. > > I believe Mark saw hangs in tessellation control shader hangs on > Geminilake only, and never saw this issue on Broxton. So, my guess is > that the workaround really is new on Geminilake, and the BXT tag on the > workarounds page is incorrect. (Mark, does that sound right to you?) Hi, I'm back! This fails a selftest on glk as we can't even write to the register 0x731c, or at least can't read from the register. Did bspec ever get updated to include this register & wa? -Chris

5 years, 2 months

1
0
0 0

[4.4-stable PATCH 0/2] Fix KVM/arm regression in 4.4.175

by Marc Zyngier

Daniel Verkamp reported that the backport of 0d640732dbeb ("arm64: KVM: Skip MMIO insn after emulation") to 4.4-stable has broken KVM on arm/arm64. It turns out that the guest cannot make forward progress as soon as it hits a device emulated by the host kernel, like the interrupt controller. The reason for this is a set of missing dependencies from the 4.7 era. With these patches added to 4.4.175, I'm able to boot guests normally. Tested with both kvmtool and crossvm. Christoffer Dall (1): KVM: arm/arm64: Fix MMIO emulation data handling Marc Zyngier (1): arm/arm64: KVM: Feed initialized memory to MMIO accesses arch/arm/kvm/mmio.c | 10 ++++++---- virt/kvm/arm/vgic.c | 7 ------- 2 files changed, 6 insertions(+), 11 deletions(-) -- 2.20.1

5 years, 2 months

3
4
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2019