- 25 Jan, 2020 1 commit
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/inputLinus Torvalds authored
Pull input fixes from Dmitry Torokhov: - add sanity checks to USB endpoints in various dirvers - max77650-onkey was missing an OF table which was preventing module autoloading - a revert and a different fix for F54 handling in Synaptics dirver - a fixup for handling register in pm8xxx vibrator driver * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: pm8xxx-vib - fix handling of separate enable register Input: keyspan-remote - fix control-message timeouts Input: max77650-onkey - add of_match table Input: rmi_f54 - read from FIFO in 32 byte blocks Revert "Input: synaptics-rmi4 - don't increment rmiaddr for SMBus transfers" Input: sur40 - fix interface sanity checks Input: gtco - drop redundant variable reinit Input: gtco - fix extra-descriptor debug message Input: gtco - fix endpoint sanity check Input: aiptek - use descriptors of current altsetting Input: aiptek - fix endpoint sanity check Input: pegasus_notetaker - fix endpoint sanity check Input: sun4i-ts - add a check for devm_thermal_zone_of_sensor_register Input: evdev - convert kzalloc()/vzalloc() to kvzalloc()
-
- 24 Jan, 2020 7 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommuLinus Torvalds authored
Pull iommu fixes from Joerg Roedel: "Two fixes: - Fix NULL-ptr dereference bug in Intel IOMMU driver - Properly save and restore AMD IOMMU performance counter registers when testing if they are writable" * tag 'iommu-fixes-v5.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: iommu/amd: Fix IOMMU perf counter clobbering during init iommu/vt-d: Call __dmar_remove_one_dev_info with valid pointer
-
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linuxLinus Torvalds authored
Pull powerpc fixes from Michael Ellerman: "Some more powerpc fixes for 5.5: - Fix our hash MMU code to avoid having overlapping ids between user and kernel, which isn't as bad as it sounds but led to crashes on some machines. - A fix for the Power9 XIVE interrupt code, which could return the wrong interrupt state in obscure error conditions. - A minor Kconfig fix for the recently added CONFIG_PPC_UV code. Thanks to Aneesh Kumar K.V, Bharata B Rao, Cédric Le Goater, Frederic Barrat" * tag 'powerpc-5.5-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/mm/hash: Fix sharing context ids between kernel & userspace powerpc/xive: Discard ESB load value when interrupt is invalid powerpc: Ultravisor: Fix the dependencies for CONFIG_PPC_UV
-
git://anongit.freedesktop.org/drm/drmLinus Torvalds authored
Pull drm fixes from Dave Airlie: "This one has a core mst fix and two i915 fixes. amdgpu just enables some hw outside experimental. The panfrost fix is a little bigger than I'd like at this stage but it fixes a fairly fundamental problem with global shared buffers in that driver, and since it's confined to that driver and I've taken a look at it, I think it's fine to get into the tree now, so it can get stable propagated as well. core/mst: - Fix SST branch device handling amdgpu: - enable renoir outside experimental i915: - Avoid overflow with huge userptr objects - uAPI fix to correctly handle negative values in engine->uabi_class/instance (cc: stable) panfrost: - Fix mapping of globally visible BO's (Boris)" * tag 'drm-fixes-2020-01-24' of git://anongit.freedesktop.org/drm/drm: drm/amdgpu: remove the experimental flag for renoir drm/panfrost: Add the panfrost_gem_mapping concept drm/i915: Align engine->uabi_class/instance with i915_drm.h drm/i915/userptr: fix size calculation drm/dp_mst: Handle SST-only branch device case
-
Christophe Leroy authored
The range passed to user_access_begin() by strncpy_from_user() and strnlen_user() starts at 'src' and goes up to the limit of userspace although reads will be limited by the 'count' param. On 32 bits powerpc (book3s/32) access has to be granted for each 256Mbytes segment and the cost increases with the number of segments to unlock. Limit the range with 'count' param. Fixes: 594cc251 ("make 'user_access_begin()' do 'access_ok()'") Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Shuah Khan authored
init_iommu_perf_ctr() clobbers the register when it checks write access to IOMMU perf counters and fails to restore when they are writable. Add save and restore to fix it. Signed-off-by:
Shuah Khan <skhan@linuxfoundation.org> Fixes: 30861ddc ("perf/x86/amd: Add IOMMU Performance Counter resource management") Reviewed-by:
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Tested-by:
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de>
-
Jerry Snitselaar authored
It is possible for archdata.iommu to be set to DEFER_DEVICE_DOMAIN_INFO or DUMMY_DEVICE_DOMAIN_INFO so check for those values before calling __dmar_remove_one_dev_info. Without a check it can result in a null pointer dereference. This has been seen while booting a kdump kernel on an HP dl380 gen9. Cc: Joerg Roedel <joro@8bytes.org> Cc: Lu Baolu <baolu.lu@linux.intel.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: stable@vger.kernel.org # 5.3+ Cc: linux-kernel@vger.kernel.org Fixes: ae23bfb6 ("iommu/vt-d: Detach domain before using a private one") Signed-off-by:
Jerry Snitselaar <jsnitsel@redhat.com> Acked-by:
Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de>
-
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmcLinus Torvalds authored
Pull MMC fixes from Ulf Hansson: "A couple of MMC host fixes: - sdhci: Fix minimum clock rate for v3 controllers - sdhci-tegra: Fix SDR50 tuning override - sdhci_am654: Fixup tuning issues and support for CQHCI - sdhci_am654: Remove wrong write protect flag" * tag 'mmc-v5.5-rc2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: sdhci: fix minimum clock rate for v3 controller mmc: tegra: fix SDR50 tuning override mmc: sdhci_am654: Fix Command Queuing in AM65x mmc: sdhci_am654: Reset Command and Data line after tuning mmc: sdhci_am654: Remove Inverted Write Protect flag
-
- 23 Jan, 2020 11 commits
-
-
Dave Airlie authored
Merge tag 'amd-drm-fixes-5.5-2020-01-23' of git://people.freedesktop.org/~agd5f/linux into drm-fixes amd-drm-fixes-5.5-2020-01-23: amdgpu: - remove the experimental flag from renoir Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123191424.3849-1-alexander.deucher@amd.com
-
Dave Airlie authored
Merge tag 'drm-intel-fixes-2020-01-23' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Avoid overflow with huge userptr objects - uAPI fix to correctly handle negative values in engine->uabi_class/instance (cc: stable) Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123135045.GA12584@jlahtine-desk.ger.corp.intel.com
-
git://git.infradead.org/users/willy/linux-daxLinus Torvalds authored
Pull XArray fixes from Matthew Wilcox: "Primarily bugfixes, mostly around handling index wrap-around correctly. A couple of doc fixes and adding missing APIs. I had an oops live on stage at linux.conf.au this year, and it turned out to be a bug in xas_find() which I can't prove isn't triggerable in the current codebase. Then in looking for the bug, I spotted two more bugs. The bots have had a few days to chew on this with no problems reported, and it passes the test-suite (which now has more tests to make sure these problems don't come back)" * tag 'xarray-5.5' of git://git.infradead.org/users/willy/linux-dax: XArray: Add xa_for_each_range XArray: Fix xas_find returning too many entries XArray: Fix xa_find_after with multi-index entries XArray: Fix infinite loop with entry at ULONG_MAX XArray: Add wrappers for nested spinlocks XArray: Improve documentation of search marks XArray: Fix xas_pause at ULONG_MAX
-
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-traceLinus Torvalds authored
Pull tracing fixes from Steven Rostedt: "Various tracing fixes: - Fix a function comparison warning for a xen trace event macro - Fix a double perf_event linking to a trace_uprobe_filter for multiple events - Fix suspicious RCU warnings in trace event code for using list_for_each_entry_rcu() when the "_rcu" portion wasn't needed. - Fix a bug in the histogram code when using the same variable - Fix a NULL pointer dereference when tracefs lockdown enabled and calling trace_set_default_clock() - A fix to a bug found with the double perf_event linking patch" * tag 'trace-v5.5-rc6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: tracing/uprobe: Fix to make trace_uprobe_filter alignment safe tracing: Do not set trace clock if tracefs lockdown is in effect tracing: Fix histogram code when expression has same var as value tracing: trigger: Replace unneeded RCU-list traversals tracing/uprobe: Fix double perf_event linking on multiprobe uprobe tracing: xen: Ordered comparison of function pointers
-
https://github.com/ceph/ceph-clientLinus Torvalds authored
Pull ceph fix from Ilya Dryomov: "A fix for a potential use-after-free from Jeff, marked for stable" * tag 'ceph-for-5.5-rc8' of https://github.com/ceph/ceph-client: ceph: hold extra reference to r_parent over life of request
-
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pmLinus Torvalds authored
Pull power management fix from Rafael Wysocki: "Prevent the kernel from crashing during resume from hibernation if free pages contain leftover data from the restore kernel and init_on_free is set (Alexander Potapenko)" * tag 'pm-5.5-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: PM: hibernate: fix crashes with init_on_free=1
-
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pciLinus Torvalds authored
Pull PCI fix from Bjorn Helgaas: "Mark ATS as broken on AMD Navi14 GPU rev 0xc5 (Alex Deucher)" * tag 'pci-v5.5-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: PCI: Mark AMD Navi14 GPU rev 0xc5 ATS as broken
-
Linus Torvalds authored
In commit 9f79b78e ("Convert filldir[64]() from __put_user() to unsafe_put_user()") I changed filldir to not do individual __put_user() accesses, but instead use unsafe_put_user() surrounded by the proper user_access_begin/end() pair. That make them enormously faster on modern x86, where the STAC/CLAC games make individual user accesses fairly heavy-weight. However, the user_access_begin() range was not really the exact right one, since filldir() has the unfortunate problem that it needs to not only fill out the new directory entry, it also needs to fix up the previous one to contain the proper file offset. It's unfortunate, but the "d_off" field in "struct dirent" is _not_ the file offset of the directory entry itself - it's the offset of the next one. So we end up backfilling the offset in the previous entry as we walk along. But since x86 didn't really care about the exact range, and used to be the only architecture that did anything fancy in user_access_begin() to begin with, the filldir[64]() changes did something lazy, and even commented on it: /* * Note! This range-checks 'previous' (which may be NULL). * The real range was checked in getdents */ if (!user_access_begin(dirent, sizeof(*dirent))) goto efault; and it all worked fine. But now 32-bit ppc is starting to also implement user_access_begin(), and the fact that we faked the range to only be the (possibly not even valid) previous directory entry becomes a problem, because ppc32 will actually be using the range that is passed in for more than just "check that it's user space". This is a complete rewrite of Christophe's original patch. By saving off the record length of the previous entry instead of a pointer to it in the filldir data structures, we can simplify the range check and the writing of the previous entry d_off field. No need for any conditionals in the user accesses themselves, although we retain the conditional EINTR checking for the "was this the first directory entry" signal handling latency logic. Fixes: 9f79b78e ("Convert filldir[64]() from __put_user() to unsafe_put_user()") Link: https://lore.kernel.org/lkml/a02d3426f93f7eb04960a4d9140902d278cab0bb.1579697910.git.christophe.leroy@c-s.fr/ Link: https://lore.kernel.org/lkml/408c90c4068b00ea8f1c41cca45b84ec23d4946b.1579783936.git.christophe.leroy@c-s.fr/Reported-and-tested-by:
Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
Commit 8a23eb80 ("Make filldir[64]() verify the directory entry filename is valid") added some minimal validity checks on the directory entries passed to filldir[64](). But they really were pretty minimal. This fleshes out at least the name length check: we used to disallow zero-length names, but really, negative lengths or oevr-long names aren't ok either. Both could happen if there is some filesystem corruption going on. Now, most filesystems tend to use just an "unsigned char" or similar for the length of a directory entry name, so even with a corrupt filesystem you should never see anything odd like that. But since we then use the name length to create the directory entry record length, let's make sure it actually is half-way sensible. Note how POSIX states that the size of a path component is limited by NAME_MAX, but we actually use PATH_MAX for the check here. That's because while NAME_MAX is generally the correct maximum name length (it's 255, for the same old "name length is usually just a byte on disk"), there's nothing in the VFS layer that really cares. So the real limitation at a VFS layer is the total pathname length you can pass as a filename: PATH_MAX. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Alex Deucher authored
Should work properly with the latest sbios on 5.5 and newer kernels. Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Aneesh Kumar K.V authored
Commit 0034d395 ("powerpc/mm/hash64: Map all the kernel regions in the same 0xc range") has a bug in the definition of MIN_USER_CONTEXT. The result is that the context id used for the vmemmap and the lowest context id handed out to userspace are the same. The context id is essentially the process identifier as far as the first stage of the MMU translation is concerned. This can result in multiple SLB entries with the same VSID (Virtual Segment ID), accessible to the kernel and some random userspace process that happens to get the overlapping id, which is not expected eg: 07 c00c000008000000 40066bdea7000500 1T ESID= c00c00 VSID= 66bdea7 LLP:100 12 0002000008000000 40066bdea7000d80 1T ESID= 200 VSID= 66bdea7 LLP:100 Even though the user process and the kernel use the same VSID, the permissions in the hash page table prevent the user process from reading or writing to any kernel mappings. It can also lead to SLB entries with different base page size encodings (LLP), eg: 05 c00c000008000000 00006bde0053b500 256M ESID=c00c00000 VSID= 6bde0053b LLP:100 09 0000000008000000 00006bde0053bc80 256M ESID= 0 VSID= 6bde0053b LLP: 0 Such SLB entries can result in machine checks, eg. as seen on a G5: Oops: Machine check, sig: 7 [#1] BE PAGE SIZE=64K MU-Hash SMP NR_CPUS=4 NUMA Power Mac NIP: c00000000026f248 LR: c000000000295e58 CTR: 0000000000000000 REGS: c0000000erfd3d70 TRAP: 0200 Tainted: G M (5.5.0-rcl-gcc-8.2.0-00010-g228b667d8ea1) MSR: 9000000000109032 <SF,HV,EE,ME,IR,DR,RI> CR: 24282048 XER: 00000000 DAR: c00c000000612c80 DSISR: 00000400 IRQMASK: 0 ... NIP [c00000000026f248] .kmem_cache_free+0x58/0x140 LR [c088000008295e58] .putname 8x88/0xa Call Trace: .putname+0xB8/0xa .filename_lookup.part.76+0xbe/0x160 .do_faccessat+0xe0/0x380 system_call+0x5c/ex68 This happens with 256MB segments and 64K pages, as the duplicate VSID is hit with the first vmemmap segment and the first user segment, and older 32-bit userspace maps things in the first user segment. On other CPUs a machine check is not seen. Instead the userspace process can get stuck continuously faulting, with the fault never properly serviced, due to the kernel not understanding that there is already a HPTE for the address but with inaccessible permissions. On machines with 1T segments we've not seen the bug hit other than by deliberately exercising it. That seems to be just a matter of luck though, due to the typical layout of the user virtual address space and the ranges of vmemmap that are typically populated. To fix it we add 2 to MIN_USER_CONTEXT. This ensures the lowest context given to userspace doesn't overlap with the VMEMMAP context, or with the context for INVALID_REGION_ID. Fixes: 0034d395 ("powerpc/mm/hash64: Map all the kernel regions in the same 0xc range") Cc: stable@vger.kernel.org # v5.2+ Reported-by:
Christian Marillat <marillat@debian.org> Reported-by:
Romain Dolbeau <romain@dolbeau.org> Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> [mpe: Account for INVALID_REGION_ID, mostly rewrite change log] Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200123102547.11623-1-mpe@ellerman.id.au
-
- 22 Jan, 2020 13 commits
-
-
Dave Airlie authored
Merge tag 'drm-misc-fixes-2020-01-22-1' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes -mst: Fix SST branch device handling (Wayne) -panfrost: Fix mapping of globally visible BO's (Boris) Cc: Wayne Lin <Wayne.Lin@amd.com> CC: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20200122213725.GA22099@art_vandelay
-
git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-ledsLinus Torvalds authored
Pull LED fixes from Pavel Machek: "Jacek's fix for an uninitialized gpio label is why I'm requesting this pull; it fixes regression in debugging output in sysfs. Others are just bugfixes that should be safe. Everything has been in -next for while" * tag 'leds-5.5-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds: leds: lm3532: add pointer to documentation and fix typo leds: rb532: cleanup whitespace ledtrig-pattern: fix email address quoting in MODULE_AUTHOR() led: max77650: add of_match table leds-as3645a: Drop fwnode reference on ignored node leds: gpio: Fix uninitialized gpio label for fwnode based probe
-
Linus Torvalds authored
Merge tag 'hwmon-for-v5.5-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: - In hwmon core, do not use the hwmon parent device for device managed memory allocations, since parent device lifetime may not match hwmon device lifetime. - Fix discrepancy between read and write values in adt7475 driver. - Fix alarms and voltage limits in nct7802 driver. * tag 'hwmon-for-v5.5-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (core) Do not use device managed functions for memory allocations hwmon: (adt7475) Make volt2reg return same reg as reg2volt input hwmon: (nct7802) Fix non-working alarm on voltages hwmon: (nct7802) Fix voltage limits to wrong registers
-
Pavel authored
Add pointer to datasheet and fix typo in printk message. Signed-off-by:
Pavel Machek <pavel@ucw.cz>
-
Pavel Machek authored
Trivial cleanup removing empty line at wrong place. Signed-off-by:
Pavel Machek <pavel@ucw.cz>
-
Pavel Machek authored
Apparently it is quite easy to forget ">" in quoting of email address. This fixes it. Signed-off-by:
Pavel Machek <pavel@ucw.cz>
-
Bartosz Golaszewski authored
We need the of_match table if we want to use the compatible string in the pmic's child node and get the led driver loaded automatically. Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by:
Pavel Machek <pavel@ucw.cz>
-
Sakari Ailus authored
If a node is ignored, do not get a reference to it. Fix the bug by moving fwnode_handle_get() where a reference to an fwnode is saved for clarity. Reported-by:
Andy Shevchenko <andriy.shevchenko@intel.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Pavel Machek <pavel@ucw.cz>
-
Jacek Anaszewski authored
When switching to using generic LED name composition mechanism via devm_led_classdev_register_ext() API the part of code initializing struct gpio_led's template name property was removed alongside. It was however overlooked that the property was also passed to devm_fwnode_get_gpiod_from_child() in place of "label" parameter, which when set to NULL, results in gpio label being initialized to '?'. It could be observed in debugfs and failed to properly identify gpio association with LED consumer. Fix this shortcoming by updating the GPIO label after the LED is registered and its final name is known. Fixes: d7235f5f ("leds: gpio: Use generic support for composing LED names") Cc: Russell King <linux@armlinux.org.uk> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Jacek Anaszewski <jacek.anaszewski@gmail.com> [fixed comment] Signed-off-by:
Pavel Machek <pavel@ucw.cz>
-
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull io_uring fix from Jens Axboe: "This was supposed to have gone in last week, but due to a brain fart on my part, I forgot that we made this struct addition in the 5.5 cycle. So here it is for 5.5, to prevent having a 32 vs 64-bit compatability issue with the files_update command" * tag 'io_uring-5.5-2020-01-22' of git://git.kernel.dk/linux-block: io_uring: fix compat for IORING_REGISTER_FILES_UPDATE
-
Masami Hiramatsu authored
Commit 99c9a923 ("tracing/uprobe: Fix double perf_event linking on multiprobe uprobe") moved trace_uprobe_filter on trace_probe_event. However, since it introduced a flexible data structure with char array and type casting, the alignment of trace_uprobe_filter can be broken. This changes the type of the array to trace_uprobe_filter data strucure to fix it. Link: http://lore.kernel.org/r/20200120124022.GA14897@hirez.programming.kicks-ass.net Link: http://lkml.kernel.org/r/157966340499.5107.10978352478952144902.stgit@devnote2 Fixes: 99c9a923 ("tracing/uprobe: Fix double perf_event linking on multiprobe uprobe") Suggested-by:
Peter Zijlstra <peterz@infradead.org> Signed-off-by:
Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org>
-
Frederic Barrat authored
A load on an ESB page returning all 1's means that the underlying device has invalidated the access to the PQ state of the interrupt through mmio. It may happen, for example when querying a PHB interrupt while the PHB is in an error state. In that case, we should consider the interrupt to be invalid when checking its state in the irq_get_irqchip_state() handler. Fixes: da15c03b ("powerpc/xive: Implement get_irqchip_state method for XIVE to fix shutdown race") Cc: stable@vger.kernel.org # v5.4+ Signed-off-by:
Frederic Barrat <fbarrat@linux.ibm.com> [clg: wrote a commit log, introduced XIVE_ESB_INVALID ] Signed-off-by:
Cédric Le Goater <clg@kaod.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200113130118.27969-1-clg@kaod.org
-
Bharata B Rao authored
Let PPC_UV depend only on DEVICE_PRIVATE which in turn will satisfy all the other required dependencies Fixes: 013a53f2 ("powerpc: Ultravisor: Add PPC_UV config option") Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Bharata B Rao <bharata@linux.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200109092047.24043-1-bharata@linux.ibm.com
-
- 21 Jan, 2020 6 commits
-
-
Jeff Layton authored
Currently, we just assume that it will stick around by virtue of the submitter's reference, but later patches will allow the syscall to return early and we can't rely on that reference at that point. While I'm not aware of any reports of it, Xiubo pointed out that this may fix a use-after-free. If the wait for a reply times out or is canceled via signal, and then the reply comes in after the syscall returns, the client can end up trying to access r_parent without a reference. Take an extra reference to the inode when setting r_parent and release it when releasing the request. Cc: stable@vger.kernel.org Signed-off-by:
Jeff Layton <jlayton@kernel.org> Reviewed-by:
"Yan, Zheng" <zyan@redhat.com> Signed-off-by:
Ilya Dryomov <idryomov@gmail.com>
-
Boris Brezillon authored
With the introduction of per-FD address space, the same BO can be mapped in different address space if the BO is globally visible (GEM_FLINK) and opened in different context or if the dmabuf is self-imported. The current implementation does not take case into account, and attaches the mapping directly to the panfrost_gem_object. Let's create a panfrost_gem_mapping struct and allow multiple mappings per BO. The mappings are refcounted which helps solve another problem where mappings were torn down (GEM handle closed by userspace) while GPU jobs accessing those BOs were still in-flight. Jobs now keep a reference on the mappings they use. v2 (robh): - Minor review comment clean-ups from Steven - Use list_is_singular helper - Just WARN if we add a mapping when madvise state is not WILLNEED. With that, drop the use of object_name_lock. v3 (robh): - Revert returning list iterator in panfrost_gem_mapping_get() Fixes: a5efb4c9 ("drm/panfrost: Restructure the GEM object creation") Fixes: 7282f764 ("drm/panfrost: Implement per FD address spaces") Cc: <stable@vger.kernel.org> Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by:
Rob Herring <robh@kernel.org> Acked-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200116021554.15090-1-robh@kernel.org
-
Tvrtko Ursulin authored
In our ABI we have defined I915_ENGINE_CLASS_INVALID_NONE and I915_ENGINE_CLASS_INVALID_VIRTUAL as negative values which creates implicit coupling with type widths used in, also ABI, struct i915_engine_class_instance. One place where we export engine->uabi_class I915_ENGINE_CLASS_INVALID_VIRTUAL is from our our tracepoints. Because the type of the former is u8 in contrast to u16 defined in the ABI, 254 will be returned instead of 65534 which userspace would legitimately expect. Another place is I915_CONTEXT_PARAM_ENGINES. Therefore we need to align the type used to store engine ABI class and instance. v2: * Update the commit message mentioning get_engines and cc stable. (Chris) Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 6d06779e ("drm/i915: Load balancing across a virtual engine") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: <stable@vger.kernel.org> # v5.3+ Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200116134508.25211-1-tvrtko.ursulin@linux.intel.com (cherry picked from commit 0b3bd0cd) Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Matthew Auld authored
If we create a rather large userptr object(e.g 1ULL << 32) we might shift past the type-width of num_pages: (int)num_pages << PAGE_SHIFT, resulting in a totally bogus sg_table, which fortunately will eventually manifest as: gen8_ppgtt_insert_huge:463 GEM_BUG_ON(iter->sg->length < page_size) kernel BUG at drivers/gpu/drm/i915/gt/gen8_ppgtt.c:463! v2: more unsigned long prefer I915_GTT_PAGE_SIZE Fixes: 5cc9ed4b ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl") Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200117132413.1170563-2-matthew.auld@intel.com (cherry picked from commit 8e78871b) Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Stephan Gerhold authored
Setting the vibrator enable_mask is not implemented correctly: For regmap_update_bits(map, reg, mask, val) we give in either regs->enable_mask or 0 (= no-op) as mask and "val" as value. But "val" actually refers to the vibrator voltage control register, which has nothing to do with the enable_mask. So we usually end up doing nothing when we really wanted to enable the vibrator. We want to set or clear the enable_mask (to enable/disable the vibrator). Therefore, change the call to always modify the enable_mask and set the bits only if we want to enable the vibrator. Fixes: d4c7c5c9 ("Input: pm8xxx-vib - handle separate enable register") Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20200114183442.45720-1-stephan@gerhold.netSigned-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Eugene Syromiatnikov authored
fds field of struct io_uring_files_update is problematic with regards to compat user space, as pointer size is different in 32-bit, 32-on-64-bit, and 64-bit user space. In order to avoid custom handling of compat in the syscall implementation, make fds __u64 and use u64_to_user_ptr in order to retrieve it. Also, align the field naturally and check that no garbage is passed there. Fixes: c3a31e60 ("io_uring: add support for IORING_REGISTER_FILES_UPDATE") Signed-off-by:
Eugene Syromiatnikov <esyr@redhat.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
- 20 Jan, 2020 2 commits
-
-
Masami Ichikawa authored
When trace_clock option is not set and unstable clcok detected, tracing_set_default_clock() sets trace_clock(ThinkPad A285 is one of case). In that case, if lockdown is in effect, null pointer dereference error happens in ring_buffer_set_clock(). Link: http://lkml.kernel.org/r/20200116131236.3866925-1-masami256@gmail.com Cc: stable@vger.kernel.org Fixes: 17911ff3 ("tracing: Add locked_down checks to the open calls of files created for tracefs") Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1788488Signed-off-by:
Masami Ichikawa <masami256@gmail.com> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org>
-
Steven Rostedt (VMware) authored
While working on a tool to convert SQL syntex into the histogram language of the kernel, I discovered the following bug: # echo 'first u64 start_time u64 end_time pid_t pid u64 delta' >> synthetic_events # echo 'hist:keys=pid:start=common_timestamp' > events/sched/sched_waking/trigger # echo 'hist:keys=next_pid:delta=common_timestamp-$start,start2=$start:onmatch(sched.sched_waking).trace(first,$start2,common_timestamp,next_pid,$delta)' > events/sched/sched_switch/trigger Would not display any histograms in the sched_switch histogram side. But if I were to swap the location of "delta=common_timestamp-$start" with "start2=$start" Such that the last line had: # echo 'hist:keys=next_pid:start2=$start,delta=common_timestamp-$start:onmatch(sched.sched_waking).trace(first,$start2,common_timestamp,next_pid,$delta)' > events/sched/sched_switch/trigger The histogram works as expected. What I found out is that the expressions clear out the value once it is resolved. As the variables are resolved in the order listed, when processing: delta=common_timestamp-$start The $start is cleared. When it gets to "start2=$start", it errors out with "unresolved symbol" (which is silent as this happens at the location of the trace), and the histogram is dropped. When processing the histogram for variable references, instead of adding a new reference for a variable used twice, use the same reference. That way, not only is it more efficient, but the order will no longer matter in processing of the variables. From Tom Zanussi: "Just to clarify some more about what the problem was is that without your patch, we would have two separate references to the same variable, and during resolve_var_refs(), they'd both want to be resolved separately, so in this case, since the first reference to start wasn't part of an expression, it wouldn't get the read-once flag set, so would be read normally, and then the second reference would do the read-once read and also be read but using read-once. So everything worked and you didn't see a problem: from: start2=$start,delta=common_timestamp-$start In the second case, when you switched them around, the first reference would be resolved by doing the read-once, and following that the second reference would try to resolve and see that the variable had already been read, so failed as unset, which caused it to short-circuit out and not do the trigger action to generate the synthetic event: to: delta=common_timestamp-$start,start2=$start With your patch, we only have the single resolution which happens correctly the one time it's resolved, so this can't happen." Link: https://lore.kernel.org/r/20200116154216.58ca08eb@gandalf.local.home Cc: stable@vger.kernel.org Fixes: 067fe038 ("tracing: Add variable reference handling to hist triggers") Reviewed-by:
Tom Zanuss <zanussi@kernel.org> Tested-by:
Tom Zanussi <zanussi@kernel.org> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org>
-