- Sep 13, 2017
-
-
Kirill A. Shutemov authored
The 0-day test bot found a performance regression that was tracked down to switching x86 to the generic get_user_pages_fast() implementation: http://lkml.kernel.org/r/20170710024020.GA26389@yexl-desktop The regression was caused by the fact that we now use local_irq_save() + local_irq_restore() in get_user_pages_fast() to disable interrupts. In x86 implementation local_irq_disable() + local_irq_enable() was used. The fix is to make get_user_pages_fast() use local_irq_disable(), leaving local_irq_save() for __get_user_pages_fast() that can be called with interrupts disabled. Numbers for pinning a gigabyte of memory, one page a time, 20 repeats: Before: Average: 14.91 ms, stddev: 0.45 ms After: Average: 10.76 ms, stddev: 0.18 ms Signed-off-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Huang Ying <ying.huang@intel.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Thorsten Leemhuis <regressions@leemhuis.info> Cc: linux-mm@kvack.org Fixes: e585513b ("x86/mm/gup: Switch GUP to the generic get_user_page_fast() implementation") Link: http://lkml.kernel.org/r/20170908215603.9189-3-kirill.shutemov@linux.intel.com Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
- Aug 31, 2017
-
-
Vitaly Kuznetsov authored
There's a subtle bug in how some of the paravirt guest code handles page table freeing on x86: On x86 software page table walkers depend on the fact that remote TLB flush does an IPI: walk is performed lockless but with interrupts disabled and in case the page table is freed the freeing CPU will get blocked as remote TLB flush is required. On other architectures which don't require an IPI to do remote TLB flush we have an RCU-based mechanism (see include/asm-generic/tlb.h for more details). In virtualized environments we may want to override the ->flush_tlb_others callback in pv_mmu_ops and use a hypercall asking the hypervisor to do a remote TLB flush for us. This breaks the assumption about IPIs. Xen PV has been doing this for years and the upcoming remote TLB flush for Hyper-V will do it too. This is not safe, as software page table walkers may step on an already freed page. Fix the bug by enabling the RCU-based page table freeing mechanism, CONFIG_HAVE_RCU_TABLE_FREE=y. Testing with kernbench and mmap/munmap microbenchmarks, and neither showed any noticeable performance impact. Suggested-by:
Peter Zijlstra <peterz@infradead.org> Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Acked-by:
Peter Zijlstra <peterz@infradead.org> Acked-by:
Juergen Gross <jgross@suse.com> Acked-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Andrew Cooper <andrew.cooper3@citrix.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Jork Loeser <Jork.Loeser@microsoft.com> Cc: KY Srinivasan <kys@microsoft.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Stephen Hemminger <sthemmin@microsoft.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: xen-devel@lists.xenproject.org Link: http://lkml.kernel.org/r/20170828082251.5562-1-vkuznets@redhat.com [ Rewrote/fixed/clarified the changelog. ] Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Jan Beulich authored
The lack of newlines in preceding format strings is a clear indication that these were meant to be continuations of one another, and indeed output ends up quite a bit more compact (and readable) that way. Switch other plain printk()-s in the function instances to pr_info(), as requested. Signed-off-by:
Jan Beulich <jbeulich@suse.com> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/59A7D72B0200007800175E4E@prv-mh.provo.novell.com Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
- Aug 29, 2017
-
-
Borislav Petkov authored
sme_encrypt_execute() stashes the stack pointer on entry into %rbp because it allocates a one-page stack in the non-encrypted area for the encryption routine to use. When the latter is done, it restores it from %rbp again, before returning. However, it uses the FRAME_* macros partially but restores %rsp from %rbp explicitly with a MOV. And this is fine as long as the macros *actually* do something. Unless, you do a !CONFIG_FRAME_POINTER build where those macros are empty. Then, we still restore %rsp from %rbp but %rbp contains *something* and this leads to a stack corruption. The manifestation being a triple-fault during early boot when testing SME. Good luck to me debugging this with the clumsy endless-loop-in-asm method and narrowing it down gradually. :-( So, long story short, open-code the frame macros so that there's no monkey business and we avoid subtly breaking SME depending on the .config. Fixes: 6ebcb060 ("x86/mm: Add support to encrypt the kernel in-place") Signed-off-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Tom Lendacky <thomas.lendacky@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Link: http://lkml.kernel.org/r/20170827163924.25552-1-bp@alien8.de
-
- Aug 26, 2017
-
-
Brijesh Singh authored
The following commit: d0ec49d4 ("kvm/x86/svm: Support Secure Memory Encryption within KVM") uses __sme_clr() to remove the C-bit in rsvd_bits(). rsvd_bits() is just a simple function to return some 1 bits. Applying a mask based on properties of the host MMU is incorrect. Additionally, the masks computed by __reset_rsvds_bits_mask also apply to guest page tables, where the C bit is reserved since we don't emulate SME. The fix is to clear the C-bit from rsvd_bits_mask array after it has been populated from __reset_rsvds_bits_mask() Suggested-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Brijesh Singh <brijesh.singh@amd.com> Acked-by:
Paolo Bonzini <pbonzini@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: kvm@vger.kernel.org Cc: paolo.bonzini@gmail.com Fixes: d0ec49d4 ("kvm/x86/svm: Support Secure Memory Encryption within KVM") Link: http://lkml.kernel.org/r/20170825205540.123531-1-brijesh.singh@amd.com Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Ingo Molnar authored
Conflicts: arch/x86/kernel/head64.c arch/x86/mm/mmap.c Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
- Aug 25, 2017
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdmaLinus Torvalds authored
Pull more rdma fixes from Doug Ledford: "Well, I thought we were going to be done for this -rc cycle. I should have known better than to say so though. We have four additional items that trickled in. One was a simple mistake on my part. I took a patch into my for-next thinking that the issue was less severe than it was. I was then notified that it needed to be in my -rc area instead. The other three were just found late in testing. Summary: - One core fix accidentally applied first to for-next and then cherry picked back because it needed to be in the -rc cycles instead - Another core fix - Two mlx5 fixes" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma: IB/mlx5: Always return success for RoCE modify port IB/mlx5: Fix Raw Packet QP event handler assignment IB/core: Avoid accessing non-allocated memory when inferring port type RDMA/uverbs: Initialize cq_context appropriately
-
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pmLinus Torvalds authored
Pull ACPI fixes from Rafael Wysocki: "These fix two recent regressions (in ACPICA and in the ACPI EC driver) and one bug in code introduced during the 4.12 cycle (ACPI device properties library routine). Specifics: - Fix a regression in the ACPI EC driver causing a kernel to crash during initialization on some systems due to a code ordering issue exposed by a recent change (Lv Zheng). - Fix a recent regression in ACPICA due to a change of the behavior of a library function in a way that is not backwards compatible with some existing callers of it (Rafael Wysocki). - Fix a coding mistake in a library function related to the handling of ACPI device properties introduced during the 4.12 cycle (Sakari Ailus)" * tag 'acpi-4.13-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: device property: Fix node lookup in acpi_graph_get_child_prop_value() ACPICA: Fix acpi_evaluate_object_typed() ACPI: EC: Fix regression related to wrong ECDT initialization order
-
Linus Torvalds authored
Merge tag 'kbuild-fixes-v4.13' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes from Masahiro Yamada: - fix linker script regression caused by dead code elimination support - fix typos and outdated comments - specify kselftest-clean as a PHONY target - fix "make dtbs_install" when $(srctree) includes shell special characters like '~' - Move -fshort-wchar to the global option list because defining it partially emits warnings * tag 'kbuild-fixes-v4.13' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kbuild: update comments of Makefile.asm-generic kbuild: Do not use hyphen in exported variable name Makefile: add kselftest-clean to PHONY target list Kbuild: use -fshort-wchar globally fixdep: trivial: typo fix and correction kbuild: trivial cleanups on the comments kbuild: linker script do not match C names unless LD_DEAD_CODE_DATA_ELIMINATION is configured
-
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linuxLinus Torvalds authored
Pull btrfs fix from David Sterba: "We have one more fixup that stems from the blk_status_t conversion that did not quite cover everything. The normal cases were not affected because the code is 0, but any error and retries could mix up new and old values" * 'for-4.13-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: Btrfs: fix blk_status_t/errno confusion
-
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-traceLinus Torvalds authored
Pull tracing fixes from Steven Rostedt: "Various bug fixes: - Two small memory leaks in error paths. - A missed return error code on an error path. - A fix to check the tracing ring buffer CPU when it doesn't exist (caused by setting maxcpus on the command line that is less than the actual number of CPUs, and then onlining them manually). - A fix to have the reset of boot tracers called by lateinit_sync() instead of just lateinit(). As some of the tracers register via lateinit(), and if the clear happens before the tracer is registered, it will never start even though it was told to via the kernel command line" * tag 'trace-v4.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: tracing: Fix freeing of filter in create_filter() when set_str is false tracing: Fix kmemleak in tracing_map_array_free() ftrace: Check for null ret_stack on profile function graph entry function ring-buffer: Have ring_buffer_alloc_read_page() return error on offline CPU tracing: Missing error code in tracer_alloc_buffers() tracing: Call clear_boot_tracer() at lateinit_sync
-
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-socLinus Torvalds authored
Pull ARM SoC fixes from Arnd Bergmann: "A small number of bugfixes, again nothing serious. - Alexander Dahl found multiple bugs in the Atmel memory interface driver - A randconfig build fix for at91 was incomplete, the second attempt fixes the remaining corner case - One fix for the TI Keystone queue handler - The Odroid XU4 HDMI port (added in 4.13) needs a small DT fix" * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: ARM: dts: exynos: add needs-hpd for Odroid-XU3/4 ARM: at91: don't select CONFIG_ARM_CPU_SUSPEND for old platforms soc: ti: knav: Add a NULL pointer check for kdev in knav_pool_create memory: atmel-ebi: Fix smc cycle xlate converter memory: atmel-ebi: Allow t_DF timings of zero ns memory: atmel-ebi: Fix smc timing return value evaluation
-
Eric W. Biederman authored
The implementation of TIOCGPTPEER has two issues. When /dev/ptmx (as opposed to /dev/pts/ptmx) is opened the wrong vfsmount is passed to dentry_open. Which results in the kernel displaying the wrong pathname for the peer. The second is simply by caching the vfsmount and dentry of the peer it leaves them open, in a way they were not previously Which because of the inreased reference counts can cause unnecessary behaviour differences resulting in regressions. To fix these move the ioctl into tty_io.c at a generic level allowing the ioctl to have access to the struct file on which the ioctl is being called. This allows the path of the slave to be derived when opening the slave through TIOCGPTPEER instead of requiring the path to the slave be cached. Thus removing the need for caching the path. A new function devpts_ptmx_path is factored out of devpts_acquire and used to implement a function devpts_mntget. The new function devpts_mntget takes a filp to perform the lookup on and fsi so that it can confirm that the superblock that is found by devpts_ptmx_path is the proper superblock. v2: Lots of fixes to make the code actually work v3: Suggestions by Linus - Removed the unnecessary initialization of filp in ptm_open_peer - Simplified devpts_ptmx_path as gotos are no longer required [ This is the fix for the issue that was reverted in commit 143c97cc, but this time without breaking 'pbuilder' due to increased reference counts - Linus ] Fixes: 54ebbfb1 ("tty: add TIOCGPTPEER ioctl") Reported-by:
Christian Brauner <christian.brauner@canonical.com> Reported-and-tested-by:
Stefan Lippers-Hollmann <s.l-h@gmx.de> Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Rafael J. Wysocki authored
* acpica-fix: ACPICA: Fix acpi_evaluate_object_typed() * acpi-ec-fix: ACPI: EC: Fix regression related to wrong ECDT initialization order * acpi-properties-fix: ACPI: device property: Fix node lookup in acpi_graph_get_child_prop_value()
-
Majd Dibbiny authored
CM layer calls ib_modify_port() regardless of the link layer. For the Ethernet ports, qkey violation and Port capabilities are meaningless. Therefore, always return success for ib_modify_port calls on the Ethernet ports. Cc: Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by:
Majd Dibbiny <majd@mellanox.com> Reviewed-by:
Moni Shoua <monis@mellanox.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
Doug Ledford <dledford@redhat.com>
-
Majd Dibbiny authored
In case we have SQ and RQ for Raw Packet QP, the SQ's event handler wasn't assigned. Fixing this by assigning event handler for each WQ after creation. [ 1877.145243] Call Trace: [ 1877.148644] <IRQ> [ 1877.150580] [<ffffffffa07987c5>] ? mlx5_rsc_event+0x105/0x210 [mlx5_core] [ 1877.159581] [<ffffffffa0795bd7>] ? mlx5_cq_event+0x57/0xd0 [mlx5_core] [ 1877.167137] [<ffffffffa079208e>] mlx5_eq_int+0x53e/0x6c0 [mlx5_core] [ 1877.174526] [<ffffffff8101a679>] ? sched_clock+0x9/0x10 [ 1877.180753] [<ffffffff810f717e>] handle_irq_event_percpu+0x3e/0x1e0 [ 1877.188014] [<ffffffff810f735d>] handle_irq_event+0x3d/0x60 [ 1877.194567] [<ffffffff810f9fe7>] handle_edge_irq+0x77/0x130 [ 1877.201129] [<ffffffff81014c3f>] handle_irq+0xbf/0x150 [ 1877.207244] [<ffffffff815ed78a>] ? atomic_notifier_call_chain+0x1a/0x20 [ 1877.214829] [<ffffffff815f434f>] do_IRQ+0x4f/0xf0 [ 1877.220498] [<ffffffff815e94ad>] common_interrupt+0x6d/0x6d [ 1877.227025] <EOI> [ 1877.228967] [<ffffffff814834e2>] ? cpuidle_enter_state+0x52/0xc0 [ 1877.236990] [<ffffffff81483615>] cpuidle_idle_call+0xc5/0x200 [ 1877.243676] [<ffffffff8101bc7e>] arch_cpu_idle+0xe/0x30 [ 1877.249831] [<ffffffff810b4725>] cpu_startup_entry+0xf5/0x290 [ 1877.256513] [<ffffffff815cfee1>] start_secondary+0x265/0x27b [ 1877.263111] Code: Bad RIP value. [ 1877.267296] RIP [< (null)>] (null) [ 1877.273264] RSP <ffff88046fd63df8> [ 1877.277531] CR2: 0000000000000000 Fixes: 19098df2 ("IB/mlx5: Refactor mlx5_ib_qp to accommodate other QP types") Signed-off-by:
Majd Dibbiny <majd@mellanox.com> Reviewed-by:
Yishai Hadas <yishaih@mellanox.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
Doug Ledford <dledford@redhat.com>
-
Noa Osherovich authored
Commit 44c58487 ("IB/core: Define 'ib' and 'roce' rdma_ah_attr types") introduced the concept of type in ah_attr: * During ib_register_device, each port is checked for its type which is stored in ib_device's port_immutable array. * During uverbs' modify_qp, the type is inferred using the port number in ib_uverbs_qp_dest struct (address vector) by accessing the relevant port_immutable array and the type is passed on to providers. IB spec (version 1.3) enforces a valid port value only in Reset to Init. During Init to RTR, the address vector must be valid but port number is not mentioned as a field in the address vector, so its value is not validated, which leads to accesses to a non-allocated memory when inferring the port type. Save the real port number in ib_qp during modify to Init (when the comp_mask indicates that the port number is valid) and use this value to infer the port type. Avoid copying the address vector fields if the matching bit is not set in the attr_mask. Address vector can't be modified before the port, so no valid flow is affected. Fixes: 44c58487 ('IB/core: Define 'ib' and 'roce' rdma_ah_attr types') Signed-off-by:
Noa Osherovich <noaos@mellanox.com> Reviewed-by:
Yishai Hadas <yishaih@mellanox.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
Doug Ledford <dledford@redhat.com>
-
- Aug 24, 2017
-
-
Omar Sandoval authored
This fixes several instances of blk_status_t and bare errno ints being mixed up, some of which are real bugs. In the normal case, 0 matches BLK_STS_OK, so we don't observe any effects of the missing conversion, but in case of errors or passes through the repair/retry paths, the errors get mixed up. The changes were identified using 'sparse', we don't have reports of the buggy behaviour. Fixes: 4e4cbee9 ("block: switch bios to blk_status_t") Signed-off-by:
Omar Sandoval <osandov@fb.com> Reviewed-by:
Liu Bo <bo.li.liu@oracle.com> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
David Sterba <dsterba@suse.com>
-
Cao jin authored
Signed-off-by:
Cao jin <caoj.fnst@cn.fujitsu.com> Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com>
-
Steven Rostedt (VMware) authored
Performing the following task with kmemleak enabled: # cd /sys/kernel/tracing/events/irq/irq_handler_entry/ # echo 'enable_event:kmem:kmalloc:3 if irq >' > trigger # echo 'enable_event:kmem:kmalloc:3 if irq > 31' > trigger # echo scan > /sys/kernel/debug/kmemleak # cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8800b9290308 (size 32): comm "bash", pid 1114, jiffies 4294848451 (age 141.139s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff81cef5aa>] kmemleak_alloc+0x4a/0xa0 [<ffffffff81357938>] kmem_cache_alloc_trace+0x158/0x290 [<ffffffff81261c09>] create_filter_start.constprop.28+0x99/0x940 [<ffffffff812639c9>] create_filter+0xa9/0x160 [<ffffffff81263bdc>] create_event_filter+0xc/0x10 [<ffffffff812655e5>] set_trigger_filter+0xe5/0x210 [<ffffffff812660c4>] event_enable_trigger_func+0x324/0x490 [<ffffffff812652e2>] event_trigger_write+0x1a2/0x260 [<ffffffff8138cf87>] __vfs_write+0xd7/0x380 [<ffffffff8138f421>] vfs_write+0x101/0x260 [<ffffffff8139187b>] SyS_write+0xab/0x130 [<ffffffff81cfd501>] entry_SYSCALL_64_fastpath+0x1f/0xbe [<ffffffffffffffff>] 0xffffffffffffffff The function create_filter() is passed a 'filterp' pointer that gets allocated, and if "set_str" is true, it is up to the caller to free it, even on error. The problem is that the pointer is not freed by create_filter() when set_str is false. This is a bug, and it is not up to the caller to free the filter on error if it doesn't care about the string. Link: http://lkml.kernel.org/r/1502705898-27571-2-git-send-email-chuhu@redhat.com Cc: stable@vger.kernel.org Fixes: 38b78eb8 ("tracing: Factorize filter creation") Reported-by:
Chunyu Hu <chuhu@redhat.com> Tested-by:
Chunyu Hu <chuhu@redhat.com> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org>
-
Chunyu Hu authored
kmemleak reported the below leak when I was doing clear of the hist trigger. With this patch, the kmeamleak is gone. unreferenced object 0xffff94322b63d760 (size 32): comm "bash", pid 1522, jiffies 4403687962 (age 2442.311s) hex dump (first 32 bytes): 00 01 00 00 04 00 00 00 08 00 00 00 ff 00 00 00 ................ 10 00 00 00 00 00 00 00 80 a8 7a f2 31 94 ff ff ..........z.1... backtrace: [<ffffffff9e96c27a>] kmemleak_alloc+0x4a/0xa0 [<ffffffff9e424cba>] kmem_cache_alloc_trace+0xca/0x1d0 [<ffffffff9e377736>] tracing_map_array_alloc+0x26/0x140 [<ffffffff9e261be0>] kretprobe_trampoline+0x0/0x50 [<ffffffff9e38b935>] create_hist_data+0x535/0x750 [<ffffffff9e38bd47>] event_hist_trigger_func+0x1f7/0x420 [<ffffffff9e38893d>] event_trigger_write+0xfd/0x1a0 [<ffffffff9e44dfc7>] __vfs_write+0x37/0x170 [<ffffffff9e44f552>] vfs_write+0xb2/0x1b0 [<ffffffff9e450b85>] SyS_write+0x55/0xc0 [<ffffffff9e203857>] do_syscall_64+0x67/0x150 [<ffffffff9e977ce7>] return_from_SYSCALL_64+0x0/0x6a [<ffffffffffffffff>] 0xffffffffffffffff unreferenced object 0xffff9431f27aa880 (size 128): comm "bash", pid 1522, jiffies 4403687962 (age 2442.311s) hex dump (first 32 bytes): 00 00 8c 2a 32 94 ff ff 00 f0 8b 2a 32 94 ff ff ...*2......*2... 00 e0 8b 2a 32 94 ff ff 00 d0 8b 2a 32 94 ff ff ...*2......*2... backtrace: [<ffffffff9e96c27a>] kmemleak_alloc+0x4a/0xa0 [<ffffffff9e425348>] __kmalloc+0xe8/0x220 [<ffffffff9e3777c1>] tracing_map_array_alloc+0xb1/0x140 [<ffffffff9e261be0>] kretprobe_trampoline+0x0/0x50 [<ffffffff9e38b935>] create_hist_data+0x535/0x750 [<ffffffff9e38bd47>] event_hist_trigger_func+0x1f7/0x420 [<ffffffff9e38893d>] event_trigger_write+0xfd/0x1a0 [<ffffffff9e44dfc7>] __vfs_write+0x37/0x170 [<ffffffff9e44f552>] vfs_write+0xb2/0x1b0 [<ffffffff9e450b85>] SyS_write+0x55/0xc0 [<ffffffff9e203857>] do_syscall_64+0x67/0x150 [<ffffffff9e977ce7>] return_from_SYSCALL_64+0x0/0x6a [<ffffffffffffffff>] 0xffffffffffffffff Link: http://lkml.kernel.org/r/1502705898-27571-1-git-send-email-chuhu@redhat.com Cc: stable@vger.kernel.org Fixes: 08d43a5f ("tracing: Add lock-free tracing_map") Signed-off-by:
Chunyu Hu <chuhu@redhat.com> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org>
-
Steven Rostedt (VMware) authored
There's a small race when function graph shutsdown and the calling of the registered function graph entry callback. The callback must not reference the task's ret_stack without first checking that it is not NULL. Note, when a ret_stack is allocated for a task, it stays allocated until the task exits. The problem here, is that function_graph is shutdown, and a new task was created, which doesn't have its ret_stack allocated. But since some of the functions are still being traced, the callbacks can still be called. The normal function_graph code handles this, but starting with commit 8861dd30 ("ftrace: Access ret_stack->subtime only in the function profiler") the profiler code references the ret_stack on function entry, but doesn't check if it is NULL first. Link: https://bugzilla.kernel.org/show_bug.cgi?id=196611 Cc: stable@vger.kernel.org Fixes: 8861dd30 ("ftrace: Access ret_stack->subtime only in the function profiler") Reported-by:
<lilydjwg@gmail.com> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org>
-
Linus Torvalds authored
This reverts commit c8c03f18 . It turns out that while fixing the ptmx file descriptor to have the correct 'struct path' to the associated slave pty is a really good thing, it breaks some user space tools for a very annoying reason. The problem is that /dev/ptmx and its associated slave pty (/dev/pts/X) are on different mounts. That was what caused us to have the wrong path in the first place (we would mix up the vfsmount of the 'ptmx' node, with the dentry of the pty slave node), but it also means that now while we use the right vfsmount, having the pty master open also keeps the pts mount busy. And it turn sout that that makes 'pbuilder' very unhappy, as noted by Stefan Lippers-Hollmann: "This patch introduces a regression for me when using pbuilder 0.228.7[2] (a helper to build Debian packages in a chroot and to create and update its chroots) when trying to umount /dev/ptmx (inside the chroot) on Debian/ unstable (full log and pbuilder configuration file[3] attached). [...] Setting up build-essential (12.3) ... Processing triggers for libc-bin (2.24-15) ... I: unmounting dev/ptmx filesystem W: Could not unmount dev/ptmx: umount: /var/cache/pbuilder/build/1340/dev/ptmx: target is busy (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1).)" apparently pbuilder tries to unmount the /dev/pts filesystem while still holding at least one master node open, which is arguably not very nice, but we don't break user space even when fixing other bugs. So this commit has to be reverted. I'll try to figure out a way to avoid caching the path to the slave pty in the master pty. The only thing that actually wants that slave pty path is the "TIOCGPTPEER" ioctl, and I think we could just recreate the path at that time. Reported-by:
Stefan Lippers-Hollmann <s.l-h@gmx.de> Cc: Eric W Biederman <ebiederm@xmission.com> Cc: Christian Brauner <christian.brauner@canonical.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Hans Verkuil authored
CEC support was added for Exynos5 in 4.13, but for the Odroids we need to set 'needs-hpd' as well since CEC is disabled when there is no HDMI hotplug signal, just as for the exynos4 Odroid-U3. This is due to the level-shifter that is disabled when there is no HPD, thus blocking the CEC signal as well. Same close-but-no-cigar board design as the Odroid-U3. Tested with my Odroid XU4. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de>
-
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linuxLinus Torvalds authored
Pull arm64 fixes from Will Deacon: "Late arm64 fixes. They fix very early boot failures with KASLR where the early mapping of the kernel is incorrect, so the failure mode looks like a hang with no output. There's also a signal-handling fix when a uaccess routine faults with a fatal signal pending, which could be used to create unkillable user tasks using userfaultfd and finally a state leak fix for the floating pointer registers across a call to exec(). We're still seeing some random issues crop up (inode memory corruption and spinlock recursion) but we've not managed to reproduce things reliably enough to debug or bisect them yet. Summary: - Fix very early boot failures with KASLR enabled - Fix fatal signal handling on userspace access from kernel - Fix leakage of floating point register state across exec()" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: kaslr: Adjust the offset to avoid Image across alignment boundary arm64: kaslr: ignore modulo offset when validating virtual displacement arm64: mm: abort uaccess retries upon fatal signal arm64: fpsimd: Prevent registers leaking across exec
-
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpioLinus Torvalds authored
Pull GPIO fixes from Linus Walleij: "Here are the (hopefully) last GPIO fixes for v4.13: - an important core fix to reject invalid GPIOs *before* trying to obtain a GPIO descriptor for it. - a driver fix for the mvebu driver IRQ handling" * tag 'gpio-v4.13-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpio: mvebu: Fix cause computation in irq handler gpio: reject invalid gpio before getting gpio_desc
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds authored
Pull SCSI fixes from James Bottomley: "Six minor and error leg fixes, plus one major change: the reversion of scsi-mq as the default. We're doing the latter temporarily (with a backport to stable) to give us time to fix all the issues that turned up with this default before trying again" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: cxgb4i: call neigh_event_send() to update MAC address Revert "scsi: default to scsi-mq" scsi: sd_zbc: Write unlock zone from sd_uninit_cmnd() scsi: aacraid: Fix out of bounds in aac_get_name_resp scsi: csiostor: fail probe if fw does not support FCoE scsi: megaraid_sas: fix error handle in megasas_probe_one
-
- Aug 23, 2017
-
-
Arnd Bergmann authored
My previous patch fixed a link error for all at91 platforms when CONFIG_ARM_CPU_SUSPEND was not set, however this caused another problem on a configuration that enabled CONFIG_ARCH_AT91 but none of the individual SoCs, and that also enabled CPU_ARM720 as the only CPU: warning: (ARCH_AT91 && SOC_IMX23 && SOC_IMX28 && ARCH_PXA && MACH_MVEBU_V7 && SOC_IMX6 && ARCH_OMAP3 && ARCH_OMAP4 && SOC_OMAP5 && SOC_AM33XX && SOC_DRA7XX && ARCH_EXYNOS3 && ARCH_EXYNOS4 && EXYNOS5420_MCPM && EXYNOS_CPU_SUSPEND && ARCH_VEXPRESS_TC2_PM && ARM_BIG_LITTLE_CPUIDLE && ARM_HIGHBANK_CPUIDLE && QCOM_PM) selects ARM_CPU_SUSPEND which has unmet direct dependencies (ARCH_SUSPEND_POSSIBLE) arch/arm/kernel/sleep.o: In function `cpu_resume': (.text+0xf0): undefined reference to `cpu_arm720_suspend_size' arch/arm/kernel/suspend.o: In function `__cpu_suspend_save': suspend.c:(.text+0x134): undefined reference to `cpu_arm720_do_suspend' This improves the hack some more by only selecting ARM_CPU_SUSPEND for the part that requires it, and changing pm.c to drop the contents of unused init functions so we no longer refer to cpu_resume on at91 platforms that don't need it. Fixes: cc7a938f ("ARM: at91: select CONFIG_ARM_CPU_SUSPEND") Acked-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de>
-
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4Linus Torvalds authored
Pull ext4 fixes from Ted Ts'o: "Fix a clang build regression and an potential xattr corruption bug" * tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: ext4: add missing xattr hash update ext4: fix clang build regression
-
Sakari Ailus authored
acpi_graph_get_child_prop_value() is intended to find a child node with a certain property value pair. The check if (!fwnode_property_read_u32(fwnode, prop_name, &nr)) continue; is faulty: fwnode_property_read_u32() returns zero on success, not on failure, leading to comparing values only if the searched property was not found. Moreover, the check is made against the parent device node instead of the child one as it should be. Fixes: 79389a83 (ACPI / property: Add support for remote endpoints) Reported-by:
Hyungwoo Yang <hyungwoo.yang@intel.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Cc: 4.12+ <stable@vger.kernel.org> # 4.12+ [ rjw: Changelog ] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
Commit 2d2a9543 (ACPICA: Update two error messages to emit control method name) causes acpi_evaluate_object_typed() to fail if its pathname argument is NULL, but some callers of that function in the kernel, particularly acpi_nondev_subnode_data_ok(), pass NULL as pathname to it and expect it to work. For this reason, make acpi_evaluate_object_typed() check if its pathname argument is NULL and fall back to using the pathname of its handle argument if that is the case. Reported-by:
Sakari Ailus <sakari.ailus@intel.com> Tested-by:
Yang, Hyungwoo <hyungwoo.yang@intel.com> Fixes: 2d2a9543 (ACPICA: Update two error messages to emit control method name) Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Bharat Potnuri authored
Initializing cq_context with ev_queue in create_cq(), leads to NULL pointer dereference in ib_uverbs_comp_handler(), if application doesnot use completion channel. This patch fixes the cq_context initialization. Fixes: 1e7710f3 ("IB/core: Change completion channel to use the reworked") Cc: stable@vger.kernel.org # 4.12 Signed-off-by:
Potnuri Bharat Teja <bharat@chelsio.com> Reviewed-by:
Matan Barak <matanb@mellanox.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> (cherry picked from commit 699a2d5b)
-
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfdLinus Torvalds authored
Pull MFD fix from Lee Jones: "Revert duplicate commit in da9062-core" * tag 'mfd-fixes-4.13' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: Revert "mfd: da9061: Fix to remove BBAT_CONT register from chip model"
-
Catalin Marinas authored
With 16KB pages and a kernel Image larger than 16MB, the current kaslr_early_init() logic for avoiding mappings across swapper table boundaries fails since increasing the offset by kimg_sz just moves the problem to the next boundary. This patch rounds the offset down to (1 << SWAPPER_TABLE_SHIFT) if the Image crosses a PMD_SIZE boundary. Fixes: afd0e5a8 ("arm64: kaslr: Fix up the kernel image alignment") Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Neeraj Upadhyay <neeraju@codeaurora.org> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com>
-
Ard Biesheuvel authored
In the KASLR setup routine, we ensure that the early virtual mapping of the kernel image does not cover more than a single table entry at the level above the swapper block level, so that the assembler routines involved in setting up this mapping can remain simple. In this calculation we add the proposed KASLR offset to the values of the _text and _end markers, and reject it if they would end up falling in different swapper table sized windows. However, when taking the addresses of _text and _end, the modulo offset (the physical displacement modulo 2 MB) is already accounted for, and so adding it again results in incorrect results. So disregard the modulo offset from the calculation. Fixes: 08cdac61 ("arm64: relocatable: deal with physically misaligned ...") Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Tested-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Will Deacon <will.deacon@arm.com>
-
Mark Rutland authored
When there's a fatal signal pending, arm64's do_page_fault() implementation returns 0. The intent is that we'll return to the faulting userspace instruction, delivering the signal on the way. However, if we take a fatal signal during fixing up a uaccess, this results in a return to the faulting kernel instruction, which will be instantly retried, resulting in the same fault being taken forever. As the task never reaches userspace, the signal is not delivered, and the task is left unkillable. While the task is stuck in this state, it can inhibit the forward progress of the system. To avoid this, we must ensure that when a fatal signal is pending, we apply any necessary fixup for a faulting kernel instruction. Thus we will return to an error path, and it is up to that code to make forward progress towards delivering the fatal signal. Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Laura Abbott <labbott@redhat.com> Cc: stable@vger.kernel.org Reviewed-by:
Steve Capper <steve.capper@arm.com> Tested-by:
Steve Capper <steve.capper@arm.com> Reviewed-by:
James Morse <james.morse@arm.com> Tested-by:
James Morse <james.morse@arm.com> Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com>
-
Dave Martin authored
There are some tricky dependencies between the different stages of flushing the FPSIMD register state during exec, and these can race with context switch in ways that can cause the old task's regs to leak across. In particular, a context switch during the memset() can cause some of the task's old FPSIMD registers to reappear. Disabling preemption for this small window would be no big deal for performance: preemption is already disabled for similar scenarios like updating the FPSIMD registers in sigreturn. So, instead of rearranging things in ways that might swap existing subtle bugs for new ones, this patch just disables preemption around the FPSIMD state flushing so that races of this type can't occur here. This brings fpsimd_flush_thread() into line with other code paths. Cc: stable@vger.kernel.org Fixes: 674c242c ("arm64: flush FP/SIMD state correctly after execve()") Reviewed-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Dave Martin <Dave.Martin@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com>
-
- Aug 22, 2017
-
-
Arnd Bergmann authored
Merge tag 'at91-ab-4.13-drivers-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux into fixes Pull "Driver fixes for 4.13" from Alexandre Belloni: - Multiple EBI/SMC timing setting/calculation fixes * tag 'at91-ab-4.13-drivers-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: memory: atmel-ebi: Fix smc cycle xlate converter memory: atmel-ebi: Allow t_DF timings of zero ns memory: atmel-ebi: Fix smc timing return value evaluation
-
Lee Jones authored
This patch was applied to the MFD twice, causing unwanted behavour. This reverts commit b77eb79a. Fixes: b77eb79a ("mfd: da9061: Fix to remove BBAT_CONT register from chip model") Reported-by:
Steve Twiss <stwiss.opensource@diasemi.com> Reviewed-by:
Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparcLinus Torvalds authored
Pull sparc fixes from David Miller: "Just a couple small fixes, two of which have to do with gcc-7: 1) Don't clobber kernel fixed registers in __multi4 libgcc helper. 2) Fix a new uninitialized variable warning on sparc32 with gcc-7, from Thomas Petazzoni. 3) Adjust pmd_t initializer on sparc32 to make gcc happy. 4) If ATU isn't available, don't bark in the logs. From Tushar Dave" * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc: sparc: kernel/pcic: silence gcc 7.x warning in pcibios_fixup_bus() sparc64: remove unnecessary log message sparc64: Don't clibber fixed registers in __multi4. mm: add pmd_t initializer __pmd() to work around a GCC bug.
-