KASAN reports a use-after-free when running xfstest generic/531, with the
following trace:
[ 293.903362] kasan_report+0xe/0x20
[ 293.903365] rb_erase+0x1f/0x790
[ 293.903370] __ceph_remove_cap+0x201/0x370
[ 293.903375] __ceph_remove_caps+0x4b/0x70
[ 293.903380] ceph_evict_inode+0x4e/0x360
[ 293.903386] evict+0x169/0x290
[ 293.903390] __dentry_kill+0x16f/0x250
[ 293.903394] dput+0x1c6/0x440
[ 293.903398] __fput+0x184/0x330
[ 293.903404] task_work_run+0xb9/0xe0
[ 293.903410] exit_to_usermode_loop+0xd3/0xe0
[ 293.903413] do_syscall_64+0x1a0/0x1c0
[ 293.903417] entry_SYSCALL_64_after_hwframe+0x44/0xa9
This happens because __ceph_remove_cap() may queue a cap release
(__ceph_queue_cap_release) which can be scheduled before that cap is
removed from the inode list with
rb_erase(&cap->ci_node, &ci->i_caps);
And, when this finally happens, the use-after-free will occur.
This can be fixed by removing the cap from the inode list before being
removed from the session list, and thus eliminating the risk of an UAF.
Cc: stable@vger.kernel.org
Signed-off-by: Luis Henriques <lhenriques@suse.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Our existing behaviour is to allow contexts and their GPU requests to
persist past the point of closure until the requests are complete. This
allows clients to operate in a 'fire-and-forget' manner where they can
setup a rendering pipeline and hand it over to the display server and
immediately exit. As the rendering pipeline is kept alive until
completion, the display server (or other consumer) can use the results
in the future and present them to the user.
The compute model is a little different. They have little to no buffer
sharing between processes as their kernels tend to operate on a
continuous stream, feeding the results back to the client application.
These kernels operate for an indeterminate length of time, with many
clients wishing that the kernel was always running for as long as they
keep feeding in the data, i.e. acting like a DSP.
Not all clients want this persistent "desktop" behaviour and would prefer
that the contexts are cleaned up immediately upon closure. This ensures
that when clients are run without hangchecking (e.g. for compute kernels
of indeterminate runtime), any GPU hang or other unexpected workloads
are terminated with the process and does not continue to hog resources.
The default behaviour for new contexts is the legacy persistence mode,
as some desktop applications are dependent upon the existing behaviour.
New clients will have to opt in to immediate cleanup on context
closure. If the hangchecking modparam is disabled, so is persistent
context support -- all contexts will be terminated on closure.
We expect this behaviour change to be welcomed by compute users, who
have often been caught between a rock and a hard place. They disable
hangchecking to avoid their kernels being "unfairly" declared hung, but
have also experienced true hangs that the system was then unable to
clean up. Naturally, this leads to bug reports.
Testcase: igt/gem_ctx_persistence
Link: https://github.com/intel/compute-runtime/pull/228
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029202338.8841-1-chris@chris-wilson.co.uk
- it fixes a build warning message, 'static' is not at beginning
of declaration [-Wold-style-declaration], by moving static keyword.
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEEaNgt5qhas/jh16fIAgVwiH27uaUFAl22350ACgkQAgVwiH27
uaX4jAv7BXxBo4ZUCcS5lACuE/75rn7xnxJ3lBFolNaWXCudaWGf48SPHHkSq/9Q
UM0gYs8szMzCupT8ueQfw62xQraQ6G65JJIMm16a5wPUau2mCOtkrflkFKxaAZCQ
LKIYRhrmSTsK3ysUh0Q60D2Us/I6RuCDbp2yMHOm/1cwXCZwDblwlAcvsdaYPdDZ
RhQ1vJBC06KPaehv7QlLgBz4BeMGubzk8vR0IPnTK5T3ieooGr9x5vTDx3NTOg27
/q1Zd4NQWdustXCMyB8JOrzTlmfIh0PUL6q0Nd9Taf/I0I/zGOyaXXbw5brxi849
UnkH5+zFDG8zfwRiASJkMG8mJRdhK/eRyCkM1MjCsu3Ag5ZkSCdEiGy4WUxosTsC
EGeAsLr7KnFt40rwHHJwP+A3GEfAlSkdUPW9FT7IzFzPDuJm87eMu3c8SaZulqEU
ycDvXoxLfaoao3IUBwI+BwFSZ6evWrlL3sVFPnYyaujxYy2vfPTolSZvyC8W00Jd
s+3z2T9w
=TA+Z
-----END PGP SIGNATURE-----
Merge tag 'exynos-drm-next-for-v5.5' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next
Fix a build warning at mixer driver
- it fixes a build warning message, 'static' is not at beginning
of declaration [-Wold-style-declaration], by moving static keyword.
Signed-off-by: Dave Airlie <airlied@redhat.com>
# gpg: Signature made Mon 28 Oct 2019 10:31:25 PM AEST
# gpg: using RSA key 020570887DBBB9A5
# gpg: Can't check signature: public key not found
From: Inki Dae <daeinki@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191028123434.30034-1-daeinki@gmail.com
UAPI Changes:
-syncobj: allow querying the last submitted timeline value (David)
-fourcc: explicitly defineDRM_FORMAT_BIG_ENDIAN as unsigned (Adam)
-omap: revert the OMAP_BO_* flags that were added -- no userspace (Sean)
Cross-subsystem Changes:
-MAINTAINERS: add Mihail as komeda co-maintainer (Mihail)
Core Changes:
-edid: a few cleanups, add AVI infoframe bar info (Ville)
-todo: remove i915 device_link item and add difficulty levels (Daniel)
-dp_helpers: add a few new helpers to parse dpcd (Thierry)
Driver Changes:
-gma500: fix a few memory disclosure leaks (Kangjie)
-qxl: convert to use the new drm_gem_object_funcs.mmap (Gerd)
-various: open code dp_link helpers in preparation for helper removal (Thierry)
Cc: Chunming Zhou <david1.zhou@amd.com>
Cc: Adam Jackson <ajax@redhat.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Kangjie Lu <kjlu@umn.edu>
Cc: Mihail Atanassov <mihail.atanassov@arm.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Thierry Reding <treding@nvidia.com>
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEHF6rntfJ3enn8gh8cywAJXLcr3kFAl2xxiYACgkQcywAJXLc
r3mJowf/U9ANPuvF+lahI6IVKpE4KD8Pz+73uNhjmxq5TnmcA7eNJ2pb8HO38tU2
lkchhaQEGZR96nVL962DkegEDu8p08RpYYwKv8r+sDV+zw/aviN/ANLSmTVtZ//m
wzgUI7zIqF1WxKdFEzNmQVuY0hYd4fWBn6kGvw1jS/6xL2/3KR6hKVigBZwkICSt
/ZiCZyxA7HhAlqzasn+PqGkuLVYv6NvFu4Ug6YG4nBOh57IrKmGt1a6cEUjGsHFf
6Ets5wTPu2ydMRvY+v6rUDDRj6JJQph7Lv4hVKtg13FerJ1+OQ7xjhu4gIk1oNl/
7zIgRWMVZj79ksMXyk6zgFD2rZAF3w==
=Fm3U
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-next-2019-10-24-2' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for 5.5:
UAPI Changes:
-syncobj: allow querying the last submitted timeline value (David)
-fourcc: explicitly defineDRM_FORMAT_BIG_ENDIAN as unsigned (Adam)
-omap: revert the OMAP_BO_* flags that were added -- no userspace (Sean)
Cross-subsystem Changes:
-MAINTAINERS: add Mihail as komeda co-maintainer (Mihail)
Core Changes:
-edid: a few cleanups, add AVI infoframe bar info (Ville)
-todo: remove i915 device_link item and add difficulty levels (Daniel)
-dp_helpers: add a few new helpers to parse dpcd (Thierry)
Driver Changes:
-gma500: fix a few memory disclosure leaks (Kangjie)
-qxl: convert to use the new drm_gem_object_funcs.mmap (Gerd)
-various: open code dp_link helpers in preparation for helper removal (Thierry)
Cc: Chunming Zhou <david1.zhou@amd.com>
Cc: Adam Jackson <ajax@redhat.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Kangjie Lu <kjlu@umn.edu>
Cc: Mihail Atanassov <mihail.atanassov@arm.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20191024155535.GA10294@art_vandelay
We're seeing some failures where an aux transaction still shows as
'busy' well after the timeout limit that the hardware is supposed to
enforce. Improve the error message so that we can see exactly which aux
channel this error happened on and what the status bits were during this
case that isn't supposed to happen.
v2:
- Make timeout a const variable so that the timeout & message will
match if we decide to change it in the future. (Lucas)
- Don't bother testing intel_dp->aux.name for NULL. (Lucas)
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029173102.9451-1-matthew.d.roper@intel.com
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
drm-next-5.5-2019-10-25:
amdgpu:
- BACO support for CI and VI asics
- Quick memory training support for navi
- MSI-X support
- RAS fixes
- Display AVI infoframe fixes
- Display ref clock fixes for renoir
- Fix number of audio endpoints in renoir
- Fix for discovery tables
- Powerplay fixes
- Documentation fixes
- Misc cleanups
radeon:
- revert a PPC fix which broke x86
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191025221020.203546-1-alexander.deucher@amd.com
Some user might want to go through all registered wakeup sources
and doing things accordingly. For example, SoC PM driver might need to
do HW programming to prevent powering down specific IP which wakeup
source depending on. So add this API to help walk through all registered
wakeup source objects on that list and return them one by one.
Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
Tested-by: Leonard Crestez <leonard.crestez@nxp.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Li Yang <leoyang.li@nxp.com>
This patch updates device tree for RTC and PMC to allow system wake
from deep sleep on RTC alarm.
Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The NVIDIA Tegra210 contains an ARM PMU v3 that can be used to gather
statistics about the processors and their memory system. Add a device
tree node so that this functionality can be exposed.
Reported-by: William Cohen <giantklein@gmail.com>
Tested-by: William Cohen <giantklein@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Enable both USB-C/DP ports on Jetson AGX Xavier and wire up the power
supplies for the SORs that drive these outputs.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Some of the PMIC regulators had names that don't match the schematics.
Rename them so that it is easier to cross-reference with the hardware
documentation.
Signed-off-by: Thierry Reding <treding@nvidia.com>
It turns out that both SORs on Tegra186 are the same, so there's no need
to distinguish between them in the compatible string.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add the AVDD_IO_EDP_1V05 and enable the SOR and DPAUX hardware blocks
that are used to drive DisplayPort on Jetson Nano.
Signed-off-by: Thierry Reding <treding@nvidia.com>
This clock was not previously used because it is a fixed clock. However,
adding it here allows operating systems to deal with SOR0 the same way
as SOR1.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Although Tegra194 has support for CLKREQ sideband signal and P2972
has routing of the same till the slot, it is the case most of the time
that the connected device doesn't have CLKREQ support. Hence, it makes
sense to assume that there is no CLKREQ support by default and it can
be enabled on need basis when a card with CLKREQ support is connected.
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This enables the use of the USB ports found on the Jetson TX2 for input
or external storage, for example.
Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Enabling the SMMU for XUSB host allows buffers to be mapped through the
ARM SMMU, which helps protecting the system from rogue memory accesses
by the XUSB host.
Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The XUSB pad controller is a prerequisite for enabling XUSB support.
Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Tegra194 EQOS controller is used as primary Ethernet interface.
Set the ethernet0 alias to reflect that.
Generic bootloader code can use this to find the primary Ethernet device
and set the MAC address, for example.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The EQOS Ethernet controller found on Tegra194 is compatible with its
predecessor or Tegra186. However, it is an established practice to add
a compatible string for the most recent generation of the SoC as well,
just in case some incompatibilities or bugs are later discovered.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The SOR1 hardware block's registers start at physical address 0x15b40000
as correctly specified by the unit-address, but the reg property lists a
wrong value, likely because it was copy-and-pasted from SOR0 but not
correctly updated.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The ACONNECT complex starts at physical address 0x2900000, so give it a
unit-address to comply with standard naming practices checked for by the
device tree compiler.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The control back-bone (CBB) starts at physical address 0, so give it a
unit-address to comply with standard naming practices checked for by the
device tree compiler.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Tegra194 has four CPU clusters, each with their own cache hierarchy.
This patch creates the CPU map for these clusters and adds the second-
and third-level caches and associates them with the CPUs.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Commit 4fdbfd60a3a2 ("arm64: tegra: Add PCIe slot supply information
in p2972-0000 platform") added regulators for the PCIe slot on the
Jetson Xavier platform. One of these regulators has an active-low enable
and this commit incorrectly added an active-low specifier for the GPIO
which causes the following warning to occur on boot ...
WARNING KERN regulator@3 GPIO handle specifies active low - ignored
The fixed-regulator binding does not use the active-low flag from the
gpio specifier and purely relies of the presence of the
'enable-active-high' property to determine if it is active high or low
(if this property is omitted). Fix this warning by setting the GPIO
to active-high in the GPIO specifier. Finally, remove the
'enable-active-low' as this is not a valid property.
Fixes: 4fdbfd60a3a2 ("arm64: tegra: Add PCIe slot supply information in p2972-0000 platform")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Commit 3499359418 ("arm64: tegra: Enable HDMI on Jetson TX1")
added a regulator for HDMI on the Jetson TX1 platform. This regulator
has an active high enable, but the GPIO specifier for enabling the
regulator incorrectly defines it as active-low. This causes the
following warning to occur on boot ...
WARNING KERN regulator@10 GPIO handle specifies active low - ignored
The fixed-regulator binding does not use the active-low flag from the
gpio specifier and purely relies of the presence of the
'enable-active-high' property to determine if it is active high or low
(if this property is omitted). Fix this warning by setting the GPIO
to active-high in the GPIO specifier which aligns with the presense of
the 'enable-active-high' property.
Fixes: 3499359418 ("arm64: tegra: Enable HDMI on Jetson TX1")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Utilize common Tegra30 CPU OPP table. CPU DVFS is available now on
Cardhu A04.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Set minimum and maximum voltages, and couple CPU/CORE regulators.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Utilize common Tegra20 CPU OPP table. CPU voltage scaling is available
now on TrimSlice.
Tested-by: Nicolas Chauvet <kwizart@gmail.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Utilize common Tegra20 CPU OPP table. CPU DVFS is available now on
AC100.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Set minimum and maximum voltages, and couple CPU/CORE/RTC regulators.
Tested-by: Nicolas Chauvet <kwizart@gmail.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Operating Point are specified per HW version. The OPP voltages are kept
in a separate DTSI file because some boards may not define CPU regulator
in their device-tree if voltage scaling isn't necessary for them.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Operating Point are specified per HW version. The OPP voltages are kept
in a separate DTSI file because some boards may not define CPU regulator
in their device-tree if voltage scaling isn't necessary, like for example
in a case of tegra20-trimslice which is outlet-powered device.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add timings for RAM codes 4 and 6 and a timing for 528mHz of RAM code 1,
which was missed due to the clock driver bug that is fixed now in all of
stable kernels.
Tested-by: Steev Klimaszewski <steev@kali.org>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The power supplies needed to drive eDP on Venice2 were never hooked up,
so things only worked because those regulators are already enabled by
other devices.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add the stmpe-adc DT node as found on Toradex T30 modules
Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
Reviewed-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add device-tree binding for NVIDIA Tegra30 External Memory Controller.
The binding is based on the Tegra124 EMC binding since hardware is
similar, although there are couple significant differences.
Note that the memory timing description is given in a platform-specific
form because there is no detailed information on how to convert a
typical-common DDR timing into the register values. The timing format is
borrowed from downstream kernel, hence there is no hurdle in regards to
upstreaming of memory timings for the boards.
Acked-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
