aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2019-01-17leds: lp5523: fix a missing check of return value of lp55xx_readKangjie Lu1-1/+3
When lp55xx_read() fails, "status" is an uninitialized variable and thus may contain random value; using it leads to undefined behaviors. The fix inserts a check for the return value of lp55xx_read: if it fails, returns with its error code. Signed-off-by: Kangjie Lu <kjlu@umn.edu> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2019-01-17hwmon: (tmp421) Correct the misspelling of the tmp442 compatible attribute in OF device ID tableCheng-Min Ao1-1/+1
Correct a typo in OF device ID table The last one should be 'ti,tmp442' Signed-off-by: Cheng-Min Ao <tony_ao@wiwynn.com> Signed-off-by: Yu-Hsiang Chen <matt_chen@wiwynn.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2019-01-17afs: Fix race in async call refcountingDavid Howells2-5/+32
There's a race between afs_make_call() and afs_wake_up_async_call() in the case that an error is returned from rxrpc_kernel_send_data() after it has queued the final packet. afs_make_call() will try and clean up the mess, but the call state may have been moved on thereby causing afs_process_async_call() to also try and to delete the call. Fix this by: (1) Getting an extra ref for an asynchronous call for the call itself to hold. This makes sure the call doesn't evaporate on us accidentally and will allow the call to be retained by the caller in a future patch. The ref is released on leaving afs_make_call() or afs_wait_for_call_to_complete(). (2) In the event of an error from rxrpc_kernel_send_data(): (a) Don't set the call state to AFS_CALL_COMPLETE until *after* the call has been aborted and ended. This prevents afs_deliver_to_call() from doing anything with any notifications it gets. (b) Explicitly end the call immediately to prevent further callbacks. (c) Cancel any queued async_work and wait for the work if it's executing. This allows us to be sure the race won't recur when we change the state. We put the work queue's ref on the call if we managed to cancel it. (d) Put the call's ref that we got in (1). This belongs to us as long as the call is in state AFS_CALL_CL_REQUESTING. Fixes: 341f741f04be ("afs: Refcount the afs_call struct") Signed-off-by: David Howells <dhowells@redhat.com>
2019-01-17afs: Provide a function to get a ref on a callDavid Howells1-6/+12
Provide a function to get a reference on an afs_call struct. Signed-off-by: David Howells <dhowells@redhat.com>
2019-01-17afs: Fix key refcounting in file locking codeDavid Howells2-2/+4
Fix the refcounting of the authentication keys in the file locking code. The vnode->lock_key member points to a key on which it expects to be holding a ref, but it isn't always given an extra ref, however. Fixes: 0fafdc9f888b ("afs: Fix file locking") Signed-off-by: David Howells <dhowells@redhat.com>
2019-01-17afs: Don't set vnode->cb_s_break in afs_validate()Marc Dionne1-1/+0
A cb_interest record is not necessarily attached to the vnode on entry to afs_validate(), which can cause an oops when we try to bring the vnode's cb_s_break up to date in the default case (ie. no current callback promise and the vnode has not been deleted). Fix this by simply removing the line, as vnode->cb_s_break will be set when needed by afs_register_server_cb_interest() when we next get a callback promise from RPC call. The oops looks something like: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 ... RIP: 0010:afs_validate+0x66/0x250 [kafs] ... Call Trace: afs_d_revalidate+0x8d/0x340 [kafs] ? __d_lookup+0x61/0x150 lookup_dcache+0x44/0x70 ? lookup_dcache+0x44/0x70 __lookup_hash+0x24/0xa0 do_unlinkat+0x11d/0x2c0 __x64_sys_unlink+0x23/0x30 do_syscall_64+0x4d/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: ae3b7361dc0e ("afs: Fix validation/callback interaction") Signed-off-by: Marc Dionne <marc.dionne@auristor.com> Signed-off-by: David Howells <dhowells@redhat.com>
2019-01-17kbuild: mark prepare0 as PHONY to fix external module buildMasahiro Yamada1-2/+2
Commit c3ff2a5193fa ("powerpc/32: add stack protector support") caused kernel panic on PowerPC when an external module is used with CONFIG_STACKPROTECTOR because the 'prepare' target was not executed for the external module build. Commit e07db28eea38 ("kbuild: fix single target build for external module") turned it into a build error because the 'prepare' target is now executed but the 'prepare0' target is missing for the external module build. External module on arm/arm64 with CONFIG_STACKPROTECTOR_PER_TASK is also broken in the same way. Move 'PHONY += prepare0' to the common place. GNU Make is fine with missing rule for phony targets. I also removed the comment which is wrong irrespective of this commit. I minimize the change so it can be easily backported to 4.20.x To fix v4.20, please backport e07db28eea38 ("kbuild: fix single target build for external module"), and then this commit. Link: https://bugzilla.kernel.org/show_bug.cgi?id=201891 Fixes: e07db28eea38 ("kbuild: fix single target build for external module") Fixes: c3ff2a5193fa ("powerpc/32: add stack protector support") Fixes: 189af4657186 ("ARM: smp: add support for per-task stack canaries") Fixes: 0a1213fa7432 ("arm64: enable per-task stack canaries") Cc: linux-stable <stable@vger.kernel.org> # v4.20 Reported-by: Samuel Holland <samuel@sholland.org> Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
2019-01-17openrisc: remove unneeded code in arch/openrisc/MakefileMasahiro Yamada1-3/+0
- LDFLAGS_vmlinux is cleared by the top Makefile - 'all: vmlinux' is specified by the top Makefile Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-01-17nds32: remove unneeded code in arch/nds32/MakefileMasahiro Yamada1-8/+0
- scripts/Kbuild.include already defined 'comma' - The top Makefile has 'PHONY += FORCE' - include/asm-*/ was moved to arch/*/include/asm/ a decade ago Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-01-16LSM: Check for NULL cred-security on freeJames Morris1-0/+7
From: Casey Schaufler <casey@schaufler-ca.com> Check that the cred security blob has been set before trying to clean it up. There is a case during credential initialization that could result in this. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Acked-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <james.morris@microsoft.com> Reported-by: syzbot+69ca07954461f189e808@syzkaller.appspotmail.com
2019-01-16drm/amd/display: Detach backlight from streamDavid Francis4-15/+3
[Why] Backlight is conceptually a property of links, not streams. All backlight programming is done on links, but there is a stream property bl_pwm_level that is used to restore backlight on dpms on and s3 resume. This is unnecessary, as backlight is already restored by hardware with no driver intervention. [How] Remove bl_pwm_level, and the stream argument to set_backlight Bug: https://bugs.freedesktop.org/show_bug.cgi?id=109375 Signed-off-by: David Francis <David.Francis@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Acked-by: Anthony Koo <Anthony.Koo@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 923fe4951282cbdfce05186c10380bbc45b5e03b)
2019-01-16Yama: Check for pid death before checking ancestryKees Cook1-1/+3
It's possible that a pid has died before we take the rcu lock, in which case we can't walk the ancestry list as it may be detached. Instead, check for death first before doing the walk. Reported-by: syzbot+a9ac39bf55329e206219@syzkaller.appspotmail.com Fixes: 2d514487faf1 ("security: Yama LSM") Cc: stable@vger.kernel.org Suggested-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-01-16dt-bindings: reset: meson-axg: fix SPDX license idJerome Brunet1-2/+1
As reported, the SPDX license id is not placed correctly and the variant of the BSD License used should be specified. Fixes: c16292578ffa ("dt-bindings: reset: Add bindings for the Meson-AXG SoC Reset Controller") Reported-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Rob Herring <robh@kernel.org>
2019-01-16dt-bindings: soc: qcom: Fix trivial language typosKrzysztof Kozlowski2-3/+3
Fix few trivial language typos in bindings. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org>
2019-01-16doc: gpio-mvebu: fix broken reference to cp110-system-controller0.txt fileOtto Sabart1-2/+0
The cp110-system-controller0.txt file was renamed to cp110-system-controller.txt. Fixes: 4aa5496980e4 ("dt-bindings: cp110: rename cp110 syscon file") Signed-off-by: Otto Sabart <ottosabart@seberm.com> Signed-off-by: Rob Herring <robh@kernel.org>
2019-01-16OF: properties: add missing of_node_putJulia Lawall1-0/+1
Add an of_node_put when the result of of_graph_get_remote_port_parent is not available. The semantic match that finds this problem is as follows (http://coccinelle.lip6.fr): // <smpl> @r exists@ local idexpression e; expression x; @@ e = of_graph_get_remote_port_parent(...); ... when != x = e when != true e == NULL when != of_node_put(e) when != of_fwnode_handle(e) ( return e; | *return ...; ) // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Cc: stable@vger.kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
2019-01-16xen: Fix x86 sched_clock() interface for xenJuergen Gross2-4/+10
Commit f94c8d11699759 ("sched/clock, x86/tsc: Rework the x86 'unstable' sched_clock() interface") broke Xen guest time handling across migration: [ 187.249951] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 187.251137] OOM killer disabled. [ 187.251137] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 187.252299] suspending xenstore... [ 187.266987] xen:grant_table: Grant tables using version 1 layout [18446743811.706476] OOM killer enabled. [18446743811.706478] Restarting tasks ... done. [18446743811.720505] Setting capacity to 16777216 Fix that by setting xen_sched_clock_offset at resume time to ensure a monotonic clock value. [boris: replaced pr_info() with pr_info_once() in xen_callback_vector() to avoid printing with incorrect timestamp during resume (as we haven't re-adjusted the clock yet)] Fixes: f94c8d11699759 ("sched/clock, x86/tsc: Rework the x86 'unstable' sched_clock() interface") Cc: <stable@vger.kernel.org> # 4.11 Reported-by: Hans van Kranenburg <hans.van.kranenburg@mendix.com> Signed-off-by: Juergen Gross <jgross@suse.com> Tested-by: Hans van Kranenburg <hans.van.kranenburg@mendix.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2019-01-16fbdev: fbmem: convert CONFIG_FB_LOGO_CENTER into a cmd line optionPeter Rosin5-18/+26
A command line option is much more flexible than a config option and the supporting code is small. Gets rid of #ifdefs in the code too... Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2019-01-16swiotlb: clear io_tlb_start and io_tlb_end in swiotlb_exitChristoph Hellwig1-0/+2
Otherwise is_swiotlb_buffer will return false positives when we first initialize a swiotlb buffer, but then free it because we have an IOMMU available. Fixes: 55897af63091 ("dma-direct: merge swiotlb_dma_ops into the dma_direct code") Reported-by: Sibren Vasse <sibren@sibrenvasse.nl> Signed-off-by: Christoph Hellwig <hch@lst.de> Tested-by: Sibren Vasse <sibren@sibrenvasse.nl> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2019-01-16ia64: remove redundant 'export AWK'Masahiro Yamada1-2/+0
This is exported by the top Makefile. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-01-16kbuild: remove unused archmrproperMasahiro Yamada2-4/+2
No one uses archmrproper. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-01-15ACPI: EC: Look for ECDT EC after calling acpi_load_tables()Rafael J. Wysocki1-12/+12
Some systems have had functional issues since commit 5a8361f7ecce (ACPICA: Integrate package handling with module-level code) that, among other things, changed the initial values of the acpi_gbl_group_module_level_code and acpi_gbl_parse_table_as_term_list global flags in ACPICA which implicitly caused acpi_ec_ecdt_probe() to be called before acpi_load_tables() on the vast majority of platforms. Namely, before commit 5a8361f7ecce, acpi_load_tables() was called from acpi_early_init() if acpi_gbl_parse_table_as_term_list was FALSE and acpi_gbl_group_module_level_code was TRUE, which almost always was the case as FALSE and TRUE were their initial values, respectively. The acpi_gbl_parse_table_as_term_list value would be changed to TRUE for a couple of platforms in acpi_quirks_dmi_table[], but it remained FALSE in the vast majority of cases. After commit 5a8361f7ecce, the initial values of the two flags have been reversed, so in effect acpi_load_tables() has not been called from acpi_early_init() any more. That, in turn, affects acpi_ec_ecdt_probe() which is invoked before acpi_load_tables() now and it is not possible to evaluate the _REG method for the EC address space handler installed by it. That effectively causes the EC address space to be inaccessible to AML on platforms with an ECDT matching the EC device definition in the DSDT and functional problems ensue in there. Because the default behavior before commit 5a8361f7ecce was to call acpi_ec_ecdt_probe() after acpi_load_tables(), it should be safe to do that again. Moreover, the EC address space handler installed by acpi_ec_ecdt_probe() is only needed for AML to be able to access the EC address space and the only AML that can run during acpi_load_tables() is module-level code which only is allowed to access address spaces with default handlers (memory, I/O and PCI config space). For this reason, move the acpi_ec_ecdt_probe() invocation back to acpi_bus_init(), from where it was taken away by commit d737f333b211 (ACPI: probe ECDT before loading AML tables regardless of module-level code flag), and put it after the invocation of acpi_load_tables() to restore the original code ordering from before commit 5a8361f7ecce. Fixes: 5a8361f7ecce ("ACPICA: Integrate package handling with module-level code") Link: https://bugzilla.kernel.org/show_bug.cgi?id=199981 Reported-by: step-ali <sunmooon15@gmail.com> Reported-by: Charles Stanhope <charles.stanhope@gmail.com> Tested-by: Charles Stanhope <charles.stanhope@gmail.com> Reported-by: Paulo Nascimento <paulo.ulusu@googlemail.com> Reported-by: David Purton <dcpurton@marshwiggle.net> Reported-by: Adam Harvey <adam@adamharvey.name> Reported-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Jean-Marc Lenoir <archlinux@jihemel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-01-15drivers: thermal: int340x_thermal: Make PCI dependency explicitSinan Kaya1-1/+1
After commit 5d32a66541c4 (PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set) dependencies on CONFIG_PCI that previously were satisfied implicitly through dependencies on CONFIG_ACPI have to be specified directly. IOSF_CORE depends on PCI. For this reason, add a direct dependency on CONFIG_PCI. Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set") Signed-off-by: Sinan Kaya <okaya@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-01-15x86/intel/lpss: Make PCI dependency explicitSinan Kaya1-1/+1
After commit 5d32a66541c4 (PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set) dependencies on CONFIG_PCI that previously were satisfied implicitly through dependencies on CONFIG_ACPI have to be specified directly. LPSS code relies on PCI infrastructure but this dependency has not been called out explicitly yet. Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set") Signed-off-by: Sinan Kaya <okaya@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-01-15platform/x86: apple-gmux: Make PCI dependency explicitSinan Kaya1-1/+1
After commit 5d32a66541c4 (PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set) dependencies on CONFIG_PCI that previously were satisfied implicitly through dependencies on CONFIG_ACPI have to be specified directly. This driver depends on the PCI infrastructure but the dependency has not been called out explicitly yet. Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set") Signed-off-by: Sinan Kaya <okaya@kernel.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-01-15platform/x86: intel_pmc: Make PCI dependency explicitSinan Kaya1-1/+1
After commit 5d32a66541c4 (PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set) dependencies on CONFIG_PCI that previously were satisfied implicitly through dependencies on CONFIG_ACPI have to be specified directly. Some code in intel_pmc relies on PCI for execution. Specify this in the Kconfig. [ Andy S: For sake of a quick fix this introduces a new mandatory dependency to the driver which may survive without it. Otherwise we need to revisit the driver architecture to address this properly. ] Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set") Signed-off-by: Sinan Kaya <okaya@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-01-15platform/x86: intel_ips: make PCI dependency explicitSinan Kaya1-1/+1
After commit 5d32a66541c4 (PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set) dependencies on CONFIG_PCI that previously were satisfied implicitly through dependencies on CONFIG_ACPI have to be specified directly. intel_ips is a PCI device driver but this has not been mentioned anywhere in Kconfig. Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set") Signed-off-by: Sinan Kaya <okaya@kernel.org> Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-01-15vga-switcheroo: make PCI dependency explicitSinan Kaya1-0/+1
This driver depends on the PCI infrastructure, but the dependency has not been explicitly called out. Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set") Signed-off-by: Sinan Kaya <okaya@kernel.org> Reviewed-by: Lukas Wunner <lukas@wunner.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-01-15ata: pata_acpi: Make PCI dependency explicitSinan Kaya1-1/+1
After commit 5d32a66541c4 (PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set) dependencies on CONFIG_PCI that previously were satisfied implicitly through dependencies on CONFIG_ACPI have to be specified directly. PATA_ACPI is a PCI device driver but the PCI dependency has not been explicitly called out. Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set") Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Sinan Kaya <okaya@kernel.org> Reviewed-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-01-15ACPI / LPSS: Make PCI dependency explicitSinan Kaya2-1/+6
After commit 5d32a66541c4 (PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set), it is possible to build ACPI without any PCI support. This code depends on PCI. Compile only when PCI is present. Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set") Signed-off-by: Sinan Kaya <okaya@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-01-15pvcalls-front: fix potential null dereferenceWen Yang1-0/+3
static checker warning: drivers/xen/pvcalls-front.c:373 alloc_active_ring() error: we previously assumed 'map->active.ring' could be null (see line 357) drivers/xen/pvcalls-front.c 351 static int alloc_active_ring(struct sock_mapping *map) 352 { 353 void *bytes; 354 355 map->active.ring = (struct pvcalls_data_intf *) 356 get_zeroed_page(GFP_KERNEL); 357 if (!map->active.ring) ^^^^^^^^^^^^^^^^^ Check 358 goto out; 359 360 map->active.ring->ring_order = PVCALLS_RING_ORDER; 361 bytes = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO, 362 PVCALLS_RING_ORDER); 363 if (!bytes) 364 goto out; 365 366 map->active.data.in = bytes; 367 map->active.data.out = bytes + 368 XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER); 369 370 return 0; 371 372 out: --> 373 free_active_ring(map); ^^^ Add null check on map->active.ring before dereferencing it to avoid any NULL pointer dereferences. Fixes: 9f51c05dc41a ("pvcalls-front: Avoid get_free_pages(GFP_KERNEL) under spinlock") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Suggested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Wen Yang <wen.yang99@zte.com.cn> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> CC: Boris Ostrovsky <boris.ostrovsky@oracle.com> CC: Juergen Gross <jgross@suse.com> CC: Stefano Stabellini <sstabellini@kernel.org> CC: Dan Carpenter <dan.carpenter@oracle.com> CC: xen-devel@lists.xenproject.org CC: linux-kernel@vger.kernel.org Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2019-01-15drm/sun4i: backend: add missing of_node_putsJulia Lawall1-2/+3
The device node iterators perform an of_node_get on each iteration, so a jump out of the loop requires an of_node_put. Remote and port also have augmented reference counts, so drop them on each iteration and at the end of the function, respectively. Remote is only used for the address it contains, not for the contents of that address, so the reference count can be dropped immediately. The semantic patch that fixes the first part of this problem is as follows (http://coccinelle.lip6.fr): // <smpl> @@ expression root,e; local idexpression child; iterator name for_each_child_of_node; @@ for_each_available_child_of_node(root, child) { ... when != of_node_put(child) when != e = child + of_node_put(child); ? break; ... } ... when != child // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/1547369264-24831-5-git-send-email-Julia.Lawall@lip6.fr
2019-01-15seccomp: fix UAF in user-trap codeTycho Andersen1-0/+4
On the failure path, we do an fput() of the listener fd if the filter fails to install (e.g. because of a TSYNC race that's lost, or if the thread is killed, etc.). fput() doesn't actually release the fd, it just ads it to a work queue. Then the thread proceeds to free the filter, even though the listener struct file has a reference to it. To fix this, on the failure path let's set the private data to null, so we know in ->release() to ignore the filter. Reported-by: syzbot+981c26489b2d1c6316ba@syzkaller.appspotmail.com Fixes: 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace") Signed-off-by: Tycho Andersen <tycho@tycho.ws> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-01-15tracing/kprobes: Fix NULL pointer dereference in trace_kprobe_create()Andrea Righi1-3/+9
It is possible to trigger a NULL pointer dereference by writing an incorrectly formatted string to krpobe_events (trying to create a kretprobe omitting the symbol). Example: echo "r:event_1 " >> /sys/kernel/debug/tracing/kprobe_events That triggers this: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 #PF error: [normal kernel read fault] PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 6 PID: 1757 Comm: bash Not tainted 5.0.0-rc1+ #125 Hardware name: Dell Inc. XPS 13 9370/0F6P3V, BIOS 1.5.1 08/09/2018 RIP: 0010:kstrtoull+0x2/0x20 Code: 28 00 00 00 75 17 48 83 c4 18 5b 41 5c 5d c3 b8 ea ff ff ff eb e1 b8 de ff ff ff eb da e8 d6 36 bb ff 66 0f 1f 44 00 00 31 c0 <80> 3f 2b 55 48 89 e5 0f 94 c0 48 01 c7 e8 5c ff ff ff 5d c3 66 2e RSP: 0018:ffffb5d482e57cb8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffffffff82b12720 RDX: ffffb5d482e57cf8 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb5d482e57d70 R08: ffffa0c05e5a7080 R09: ffffa0c05e003980 R10: 0000000000000000 R11: 0000000040000000 R12: ffffa0c04fe87b08 R13: 0000000000000001 R14: 000000000000000b R15: ffffa0c058d749e1 FS: 00007f137c7f7740(0000) GS:ffffa0c05e580000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000497d46004 CR4: 00000000003606e0 Call Trace: ? trace_kprobe_create+0xb6/0x840 ? _cond_resched+0x19/0x40 ? _cond_resched+0x19/0x40 ? __kmalloc+0x62/0x210 ? argv_split+0x8f/0x140 ? trace_kprobe_create+0x840/0x840 ? trace_kprobe_create+0x840/0x840 create_or_delete_trace_kprobe+0x11/0x30 trace_run_command+0x50/0x90 trace_parse_run_command+0xc1/0x160 probes_write+0x10/0x20 __vfs_write+0x3a/0x1b0 ? apparmor_file_permission+0x1a/0x20 ? security_file_permission+0x31/0xf0 ? _cond_resched+0x19/0x40 vfs_write+0xb1/0x1a0 ksys_write+0x55/0xc0 __x64_sys_write+0x1a/0x20 do_syscall_64+0x5a/0x120 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fix by doing the proper argument checks in trace_kprobe_create(). Cc: Ingo Molnar <mingo@redhat.com> Link: https://lore.kernel.org/lkml/20190111095108.b79a2ee026185cbd62365977@kernel.org Link: http://lkml.kernel.org/r/20190111060113.GA22841@xps-13 Fixes: 6212dd29683e ("tracing/kprobes: Use dyn_event framework for kprobe events") Acked-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Andrea Righi <righi.andrea@gmail.com> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2019-01-15Revert "drm/amdgpu: validate user pitch alignment"Michel Dänzer1-10/+0
The check turned out to be too strict in some cases. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-15Revert "drm/amdgpu: validate user GEM object size"Alex Deucher1-8/+0
It was at the same time too strict (for linear tiling modes, where no height alignment is required) and too lenient (for 2D tiling modes, where height may need to be aligned to values > 8). Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-15drm/meson: Fix atomic mode switching regressionNeil Armstrong2-21/+7
Since commit 2bcd3ecab773 when switching mode from X11 (ubuntu mate for example) the display gets blurry, looking like an invalid framebuffer width. This commit fixed atomic crtc modesetting in a totally wrong way and introduced a local unnecessary ->enabled crtc state. This commit reverts the crctc _begin() and _enable() changes and simply adds drm_atomic_helper_commit_tail_rpm as helper. Reported-by: Tony McKahan <tonymckahan@gmail.com> Suggested-by: Daniel Vetter <daniel@ffwll.ch> Fixes: 2bcd3ecab773 ("drm/meson: Fixes for drm_crtc_vblank_on/off support") Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> [narmstrong: fixed blank line issue from checkpatch] Link: https://patchwork.freedesktop.org/patch/msgid/20190114153118.8024-1-narmstrong@baylibre.com
2019-01-15drm/i915/gvt: Fix mmap range checkZhenyu Wang1-2/+12
This is to fix missed mmap range check on vGPU bar2 region and only allow to map vGPU allocated GMADDR range, which means user space should support sparse mmap to get proper offset for mmap vGPU aperture. And this takes care of actual pgoff in mmap request as original code always does from beginning of vGPU aperture. Fixes: 659643f7d814 ("drm/i915/gvt/kvmgt: add vfio/mdev support to KVMGT") Cc: "Monroy, Rodrigo Axel" <rodrigo.axel.monroy@intel.com> Cc: "Orrala Contreras, Alfredo" <alfredo.orrala.contreras@intel.com> Cc: stable@vger.kernel.org # v4.10+ Reviewed-by: Hang Yuan <hang.yuan@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-01-15powerpc/syscalls: Fix syscall tracingMichael Ellerman1-7/+0
Recently in commit fbf508da7440 ("powerpc: split compat syscall table out from native table") we changed the layout of the system call table. Instead of having two entries for each syscall number, one for the regular entry point and one for the compat entry point, we now have separate tables for regular and compat entry points. This inadvertently broke syscall tracing (CONFIG_FTRACE_SYSCALLS), because our implementation of arch_syscall_addr() knew about the layout of the table (it did nr * 2). We can fix it just by dropping our version of arch_syscall_addr() and using the generic version which does: return (unsigned long)sys_call_table[nr]; Fixes: fbf508da7440 ("powerpc: split compat syscall table out from native table") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-01-15drm/i915/gvt: free VFIO region space in vgpu detachHang Yuan3-4/+16
VFIO region space is allocated when one region is registered for one vgpu. So free the space when destroy the vgpu. Also change the parameter of detach_vgpu callback to use vgpu directly. Fixes: b851adeac0858c7d257b3 ("drm/i915/gvt: Add opregion support") Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-01-15powerpc/pseries: Fix build break due to pnv_npu2_init()Jason A. Donenfeld1-0/+2
Commit 3be2df00e299 ("powerpc/pseries/npu: Enable platform support") added a call to pnv_npu2_init() in pseries code. This causes a build break if we build with CONFIG_PPC_PSERIES && !CONFIG_PPC_POWERNV: powerpc64le-pc-linux-gnu-ld: arch/powerpc/platforms/pseries/pci.o: in function `pSeries_final_fixup': pci.c:(.init.text+0x1b0): undefined reference to `pnv_npu2_init' This commit therefore wraps that line in an ifdef, so that pseries builds without powernv. Fixes: 3be2df00e299 ("powerpc/pseries/npu: Enable platform support") Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> [mpe: Frob change log a bit to blame a different commit] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-01-15sbitmap: Protect swap_lock from hardirqMing Lei1-2/+3
Because we may call blk_mq_get_driver_tag() directly from blk_mq_dispatch_rq_list() without holding any lock, then HARDIRQ may come and the above DEADLOCK is triggered. Commit ab53dcfb3e7b ("sbitmap: Protect swap_lock from hardirq") tries to fix this issue by using 'spin_lock_bh', which isn't enough because we complete request from hardirq context direclty in case of multiqueue. Cc: Clark Williams <williams@redhat.com> Fixes: ab53dcfb3e7b ("sbitmap: Protect swap_lock from hardirq") Cc: Jens Axboe <axboe@kernel.dk> Cc: Ming Lei <ming.lei@redhat.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-01-14regmap-irq: do not write mask register if mask_base is zeroMark Zhang1-0/+6
If client have not provided the mask base register then do not write into the mask register. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Jinyoung Park <jinyoungp@nvidia.com> Signed-off-by: Venkat Reddy Talla <vreddytalla@nvidia.com> Signed-off-by: Mark Zhang <markz@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-01-14RDMA/uverbs: Mark ioctl responses with UVERBS_ATTR_F_VALID_OUTPUTJason Gunthorpe4-13/+59
When the ioctl interface for the write commands was introduced it did not mark the core response with UVERBS_ATTR_F_VALID_OUTPUT. This causes rdma-core in userspace to not mark the buffers as written for valgrind. Along the same lines it turns out we have always missed marking the driver data. Fixing both of these makes valgrind work properly with rdma-core and ioctl. Fixes: 4785860e04bc ("RDMA/uverbs: Implement an ioctl that can call write and write_ex handlers") Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> Reviewed-by: Artemy Kovalyov <artemyko@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
2019-01-14drm/amd/display: Fix disabled cursor on top screen edgeNicholas Kazlauskas2-2/+2
[Why] The cursor vanishes when touching the top of edge of the screen for Raven on Linux. This occurs because the cursor height is not taken into account when deciding to disable the cursor. [How] Factor in the cursor height into the cursor calculations - and mimic the existing x position calculations. Fixes: 94a4ffd1d40b ("drm/amd/display: fix PIP bugs on Dal3") Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-14drm/amd/display: fix warning on raven hotplugRoman Li1-13/+6
[Why] Hotplug on raven results in REG_WAIT_TIMEOUT warning due to failing attempt to lock disabled otg for the hubp interdependent pipes programming. [How] Don't setup pipe interdependencies for disabled otg. Also removed the unnecessary duplicate logic checks. Signed-off-by: Roman Li <Roman.Li@amd.com> Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-14drm/amd/display: fix PME notification not working in RV desktopCharlene Liu1-1/+6
[Why] PPLIB not receive the PME when unplug. Signed-off-by: Charlene Liu <charlene.liu@amd.com> Reviewed-by: Chris Park <Chris.Park@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-14drm/amd/display: Only get the connector state for VRR when toggledNicholas Kazlauskas1-1/+1
[Why] This fixes a stuttering issue that occurs when moving a hardware cursor when VRR is enabled. Previously when VRR is enabled atomic check will grab the connector state for every atomic update. This has to lock the connector in order to do so. The locking is bad enough by itself for performance, but it gets worse with what we do just below that - add all the planes for the CRTC to the commit. This prevents the cursor fast path from working - there's more than one plane now. With state->allow_modeset = true on top of this, it also adds and removes all the planes from the DC context triggering a full (very slow) update in DC. [How] We need the connector state to get the VRR min/max capbilities, but we only need them when there's a CRTC mode change or when VRR is toggled. The condition has been updated accordingly. Fixes: 3cc22f281318 ("drm/amdgpu: Set FreeSync state using drm VRR properties") Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-14drm/amd/display: Pack DMCU iRAM alignmentJosip Pavic1-0/+2
[Why] When the DMCU's iRAM definition was moved to the newly created power_helpers, a #pragma pack was lost, causing the iRAM to be misaligned [How] Restore the #pragma pack Signed-off-by: Josip Pavic <Josip.Pavic@amd.com> Reviewed-by: Anthony Koo <Anthony.Koo@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-14drm/amd/powerplay: run acg btc for Vega12Kenneth Feng1-0/+21
acg btc was added to Vega12 Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>