Dan Williams [Thu, 21 May 2020 21:06:17 +0000 (14:06 -0700)]
/dev/mem: Revoke mappings when a driver claims the region
Close the hole of holding a mapping over kernel driver takeover event of
a given address range.
Commit 90a545e98126 ("restrict /dev/mem to idle io memory ranges")
introduced CONFIG_IO_STRICT_DEVMEM with the goal of protecting the
kernel against scenarios where a /dev/mem user tramples memory that a
kernel driver owns. However, this protection only prevents *new* read(),
write() and mmap() requests. Established mappings prior to the driver
calling request_mem_region() are left alone.
Especially with persistent memory, and the core kernel metadata that is
stored there, there are plentiful scenarios for a /dev/mem user to
violate the expectations of the driver and cause amplified damage.
Teach request_mem_region() to find and shoot down active /dev/mem
mappings that it believes it has successfully claimed for the exclusive
use of the driver. Effectively a driver call to request_mem_region()
becomes a hole-punch on the /dev/mem device.
The typical usage of unmap_mapping_range() is part of
truncate_pagecache() to punch a hole in a file, but in this case the
implementation is only doing the "first half" of a hole punch. Namely it
is just evacuating current established mappings of the "hole", and it
relies on the fact that /dev/mem establishes mappings in terms of
absolute physical address offsets. Once existing mmap users are
invalidated they can attempt to re-establish the mapping, or attempt to
continue issuing read(2) / write(2) to the invalidated extent, but they
will then be subject to the CONFIG_IO_STRICT_DEVMEM checking that can
block those subsequent accesses.
Cc: Arnd Bergmann <arnd@arndb.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Kees Cook <keescook@chromium.org> Cc: Matthew Wilcox <willy@infradead.org> Cc: Russell King <linux@arm.linux.org.uk> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Fixes: 90a545e98126 ("restrict /dev/mem to idle io memory ranges") Signed-off-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/159009507306.847224.8502634072429766747.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This code was using get_user_pages*(), in approximately a "Case 1"
scenario (Direct IO), using the categorization from [1]. That means
that it's time to convert the get_user_pages*() + put_page() calls to
pin_user_pages*() + unpin_user_pages() calls.
There is some helpful background in [2]: basically, this is a small
part of fixing a long-standing disconnect between pinning pages, and
file systems' use of those pages.
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
John Hubbard [Wed, 27 May 2020 01:26:27 +0000 (18:26 -0700)]
misc: xilinx-sdfec: cleanup return value in xsdfec_table_write()
Return 0 for success, rather than the value of an incrementing
"reg" index. The reg value was never actually used, so this
simplifies the caller slightly.
This fixes the case of get_user_pages_fast() returning a -errno.
The result needs to be stored in a signed integer. And for safe
signed/unsigned comparisons, it's best to keep everything signed.
And get_user_pages_fast() also expects a signed value for number
of pages to pin.
Therefore, change most relevant variables, from u32 to int. Leave
"n" unsigned, for convenience in checking for overflow. And provide
a WARN_ON_ONCE() and early return, if overflow occurs.
Also, as long as we're tidying up: rename the page array from page,
to pages, in order to match the conventions used in most other call
sites.
qfprom has different address spaces for read and write. Reads are
always done from corrected address space, where as writes are done
on raw address space.
Writing to corrected address space is invalid and ignored, so it
does not make sense to have this support in the driver which only
supports corrected address space regions at the moment.
Merge tag 'misc-habanalabs-next-2020-05-25' of git://people.freedesktop.org/~gabbayo/linux into char-misc-next
Oded writes:
This tag contains the following changes for kernel 5.8:
- Improve MMU cache invalidation code and handle case where the
invalidation doesn't finish in a reasonable time.
- Remove the option to perform soft-reset to GAUDI. Soft-reset is where the
driver only resets the compute and DMA engines of the ASIC. This is not
relevant to GAUDI as we must also reset the NIC ports. And when we reset
the NIC ports, we must also reset other stuff so we prefer to just do
hard-reset (where we reset the entire ASIC except for PCIe).
- Fail the hard-reset procedure in case we still have user processes which
have active file-descriptors on a device. Doing hard-reset in that case
can result in a kernel panic because of gen_pool checks
- Don't initialize the default wait callback of dma_buf with the default
wait function as that's the default...
* tag 'misc-habanalabs-next-2020-05-25' of git://people.freedesktop.org/~gabbayo/linux:
habanalabs: handle MMU cache invalidation timeout
habanalabs: don't allow hard reset with open processes
habanalabs: GAUDI does not support soft-reset
habanalabs: add print for soft reset due to event
habanalabs: improve MMU cache invalidation code
habanalabs: don't set default fence_ops->wait
Omer Shpigelman [Sun, 24 May 2020 20:06:59 +0000 (23:06 +0300)]
habanalabs: handle MMU cache invalidation timeout
MMU cache invalidation timeout indicates that the device is unstable and
therefore unusable.
Hence in such case do hard reset and return an error to the user if was
called from ioctl.
In addition, change the print to error level and rephrase its text.
Omer Shpigelman [Mon, 18 May 2020 19:27:46 +0000 (22:27 +0300)]
habanalabs: don't allow hard reset with open processes
When the MMU is heavily used by the engines, unmapping might take a lot of
time due to a full MMU cache invalidation done as part of the unmap flow.
Hence we might not be able to kill all open processes before going to hard
reset the device, as it involves unmapping of all user memory.
In case of a failure in killing all open processes, we should stop the
hard reset flow as it might lead to a kernel crash - one thread (killing
of a process) is updating MMU structures that other thread (hard reset) is
freeing.
Stopping a hard reset flow leaves the device as nonoperational and the
user can then initiate a hard reset via sysfs to reinitialize the device.
Daniel Vetter [Mon, 11 May 2020 09:11:42 +0000 (11:11 +0200)]
habanalabs: don't set default fence_ops->wait
It's the default.
Also so much for "we're not going to tell the graphics people how to
review their code", dma_fence is a pretty core piece of gpu driver
infrastructure. And it's very much uapi relevant, including piles of
corresponding userspace protocols and libraries for how to pass these
around.
Would be great if habanalabs would not use this (from a quick look
it's not needed at all), since open source the userspace and playing
by the usual rules isn't on the table. If that's not possible (because
it's actually using the uapi part of dma_fence to interact with gpu
drivers) then we have exactly what everyone promised we'd want to
avoid.
rts5249_set_aspm() and rts5260_set_aspm() do nothing more than the default
rtsx_comm_set_aspm() does, so remove them and use the default. No
functional change intended.
Bjorn Helgaas [Thu, 21 May 2020 18:05:43 +0000 (13:05 -0500)]
misc: rtsx: Use pcie_capability_clear_and_set_word() for PCI_EXP_LNKCTL
Instead of using the driver-specific rtsx_pci_update_cfg_byte() to update
the PCIe Link Control Register, use pcie_capability_clear_and_set_word()
like the rest of the kernel does. This makes it easier to maintain ASPM
across the PCI core and drivers.
Remove the now-unused rtsx_pci_update_cfg_byte() and ASPM_MASK_NEG
definitions.
Bjorn Helgaas [Thu, 21 May 2020 18:05:41 +0000 (13:05 -0500)]
misc: rtsx: Removed unused dev_aspm_mode
The struct rtsx_cr_option.dev_aspm_mode member is never set to anything
other than DEV_ASPM_DYNAMIC (0). Remove it and code that tests it. No
functional change intended.
Jeffrey Hugo [Thu, 21 May 2020 17:02:49 +0000 (22:32 +0530)]
bus: mhi: core: Handle syserr during power_up
The MHI device may be in the syserr state when we attempt to init it in
power_up(). Since we have no local state, the handling is simple -
reset the device and wait for it to transition out of the reset state.
Hemant Kumar [Thu, 21 May 2020 17:02:48 +0000 (22:32 +0530)]
bus: mhi: core: Handle write lock properly in mhi_pm_m0_transition
Take write lock only to protect db_mode member of mhi channel.
This allows rest of the mhi channels to just take read lock which
fine grains the locking. It prevents channel readers to starve if
they try to enter critical section after a writer.
Hemant Kumar [Thu, 21 May 2020 17:02:47 +0000 (22:32 +0530)]
bus: mhi: core: Do not process SYS_ERROR if RDDM is supported
Devices that support RDDM do not require processing SYS_ERROR as it is
deemed redundant. Avoid SYS_ERROR processing if RDDM is supported by
the device.
Hemant Kumar [Thu, 21 May 2020 17:02:46 +0000 (22:32 +0530)]
bus: mhi: core: Skip handling BHI irq if MHI reg access is not allowed
Driver continues handling of BHI interrupt even if MHI register access
is not allowed. By doing so it calls the status call back and performs
early notification for the MHI client. This is not needed when MHI
register access is not allowed. Hence skip the handling in this case and
return. Also add debug log to print device state, local EE and device EE
when reg access is valid.
Hemant Kumar [Thu, 21 May 2020 17:02:45 +0000 (22:32 +0530)]
bus: mhi: core: Handle disable transitions in state worker
Mission mode transition is handled by state worker thread but
power off is not. There is a possibility while mission mode
transition is in progress which calls MHI client driver probe,
power off is issued by MHI controller. This results into client
driver probe and remove running in parallel and causes use after
free situation. By queuing disable transition work when mission
mode is in progress prevents the race condition.
Hemant Kumar [Thu, 21 May 2020 17:02:44 +0000 (22:32 +0530)]
bus: mhi: core: Remove the system error worker thread
Remove the system error worker thread and instead have the
execution environment worker handle that transition to serialize
processing and avoid any possible race conditions during
shutdown.
Bhaumik Bhatt [Thu, 21 May 2020 17:02:43 +0000 (22:32 +0530)]
bus: mhi: core: Ensure non-zero session or sequence ID values are used
While writing any sequence or session identifiers, it is possible that
the host could write a zero value, whereas only non-zero values should
be supported writes to those registers. Ensure that the host does not
write a non-zero value for them and also log them in debug messages. A
macro is introduced to simplify this check and the existing checks are
also converted to use this macro.
When loading AMSS firmware using BHIe protocol, return -ETIMEDOUT if no
response is received within the timeout or return -EIO in case of a
protocol returned failure or an MHI error state.
Bhaumik Bhatt [Thu, 21 May 2020 17:02:40 +0000 (22:32 +0530)]
bus: mhi: core: Handle firmware load using state worker
Upon power up, driver queues firmware worker thread if the execution
environment is PBL. Firmware worker is blocked with a timeout until
state worker gets a chance to run and unblock firmware worker. An
endpoint power up failure can be seen if state worker gets a chance to
run after firmware worker has timed out. Remove this dependency and
handle firmware load directly using state worker thread.
Hemant Kumar [Thu, 21 May 2020 17:02:39 +0000 (22:32 +0530)]
bus: mhi: core: Read transfer length from an event properly
When MHI Driver receives an EOT event, it reads xfer_len from the
event in the last TRE. The value is under control of the MHI device
and never validated by Host MHI driver. The value should never be
larger than the real size of the buffer but a malicious device can
set the value 0xFFFF as maximum. This causes driver to memory
overflow (both read or write). Fix this issue by reading minimum of
transfer length from event and the buffer length provided.
Hemant Kumar [Thu, 21 May 2020 17:02:38 +0000 (22:32 +0530)]
bus: mhi: core: Add range check for channel id received in event ring
MHI data completion handler function reads channel id from event
ring element. Value is under the control of MHI devices and can be
any value between 0 and 255. In order to prevent out of bound access
add a bound check against the max channel supported by controller
and skip processing of that event ring element.
Hemant Kumar [Thu, 21 May 2020 17:02:37 +0000 (22:32 +0530)]
bus: mhi: core: Cache intmod from mhi event to mhi channel
Driver is using zero initialized intmod value from mhi channel when
configuring TRE for bei field. This prevents interrupt moderation to
take effect in case it is supported by an event ring. Fix this by
copying intmod value from associated event ring to mhi channel upon
registering mhi controller.
Hemant Kumar [Thu, 21 May 2020 17:02:36 +0000 (22:32 +0530)]
bus: mhi: core: Refactor mhi queue APIs
Move all the common code to generate TRE from mhi_queue_buf,
mhi_queue_dma and mhi_queue_skb to mhi_gen_tre. This helps
to centralize the TRE generation code which makes any future
bug fixing easier to manage in these APIs.
Merge tag 'soundwire-5.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire into char-misc-next
Vinod writes:
soundwire updates for v5.8-rc1
This contains sdw_master_device patches and other updates done by Intel
folks.
Details:
- sdw_master_device to represent the master instances.
- sysfs properties for sdw_master_device and sdw_slave.
- Documentation update for TDM modes.
- some code cleanup patches and odd updates.
* tag 'soundwire-5.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire:
soundwire: intel: use a single module
soundwire: fix spelling mistake
soundwire: fix trailing line in sysfs_slave.c
soundwire: add Slave sysfs support
soundwire: master: add sysfs support
soundwire: disco: s/ch/channels/
soundwire: master: add runtime pm support
soundwire: bus_type: add sdw_master_device support
soundwire: bus: add unique bus id
soundwire: bus_type: introduce sdw_slave_type and sdw_master_type
soundwire: bus: rename sdw_bus_master_add/delete, add arguments
soundwire: intel: (cosmetic) remove multiple superfluous "else" statements
soundwire: (cosmetic) remove multiple superfluous "else" statements
soundwire: qcom: Use IRQF_ONESHOT
soundwire: bus: reduce verbosity on enumeration
soundwire: debugfs: clarify SDPX license with GPL-2.0-only
soundwire: slave: don't init debugfs on device registration error
Documentation: SoundWire: clarify TDM mode support
soundwire: qcom: fix error handling in probe
soundwire: intel: use asoc_rtd_to_cpu() / asoc_rtd_to_codec() macro for DAI pointer
Merge tag 'icc-5.8-rc1' of https://git.linaro.org/people/georgi.djakov/linux into char-misc-next
Georgi writes:
interconnect changes for 5.8
These are the interconnect changes for the 5.8-rc1 merge window:
Core changes:
- Convert the framework core from tristate to bool to make handling
dependencies between other core frameworks easier
- Add of_icc_get_by_index()
- Add devm_of_icc_get() helper function
- Add icc_enable() and icc_disable() helpers
New drivers:
- Platform driver for NXP i.MX8MM SoC
- Platform driver for NXP i.MX8MN SoC
- Platform driver for NXP i.MX8MQ SoC
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
* tag 'icc-5.8-rc1' of https://git.linaro.org/people/georgi.djakov/linux:
interconnect: Remove unused module exit code from core
interconnect: Disallow interconnect core to be built as a module
interconnect: Add of_icc_get_by_index() helper function
interconnect: Add helpers for enabling/disabling a path
interconnect: imx: Fix return value check in imx_icc_node_init_qos()
interconnect: imx: Add platform driver for imx8mn
interconnect: imx: Add platform driver for imx8mq
interconnect: imx: Add platform driver for imx8mm
interconnect: Add imx core driver
dt-bindings: interconnect: Add bindings for imx8m noc
interconnect: Add devm_of_icc_get() as exported API for users
Colin Ian King [Tue, 19 May 2020 15:45:53 +0000 (16:45 +0100)]
w1_therm: remove redundant assignments to variable ret
The variable ret is being initialized with a value that is never read
and it is being updated later with a new value. The initialization
is redundant and can be removed.
Dan Carpenter [Wed, 20 May 2020 12:00:19 +0000 (15:00 +0300)]
w1_therm: Free the correct variable
The problem is that we change "p_args" to point to the middle of the
string so when we free it at the end of the function it's not freeing
the same pointer that we originally allocated.
Rander Wang [Tue, 19 May 2020 19:19:02 +0000 (03:19 +0800)]
soundwire: intel: use a single module
It's not clear why we have two modules for the Intel controller/master
support when there is a single Kconfig. This adds complexity for no
good reason, the two parts need to work together anyways.
For Slave properties and Data Port 0, the attributes are managed with
simple devm_ support.
A Slave Device may have more than one Data Port (DPN), and each Data
Port can be sink or source. The attributes are created dynamically
using pre-canned macros, but still use devm_ with a name attribute
group to avoid creating kobjects - as requested by GregKH. In the
_show function, we use container_of() to retrieve port number and
direction required to extract the information.
Audio modes are not supported for now. Depending on the discussions
the SoundWire Device Class, we may add it later as is or follow the
new specification.
Souptick Joarder [Mon, 18 May 2020 18:19:51 +0000 (23:49 +0530)]
fpga: dfl: afu: Corrected error handling levels
Corrected error handling goto sequnece. Level put_pages should
be called when pinned pages >= 0 && pinned != npages. Level
free_pages should be called when pinned pages < 0.
This code was using get_user_pages*(), in a "Case 2" scenario
(DMA/RDMA), using the categorization from [1]. That means that it's
time to convert the get_user_pages*() + put_page() calls to
pin_user_pages*() + unpin_user_pages() calls.
There is some helpful background in [2]: basically, this is a small
part of fixing a long-standing disconnect between pinning pages, and
file systems' use of those pages.
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
This code was using get_user_pages*(), in a "Case 2" scenario
(DMA/RDMA), using the categorization from [1]. That means that it's
time to convert the get_user_pages*() + put_page() calls to
pin_user_pages*() + unpin_user_pages() calls.
There is some helpful background in [2]: basically, this is a small
part of fixing a long-standing disconnect between pinning pages, and
file systems' use of those pages.
Note that this effectively changes the code's behavior as well: it now
ultimately calls set_page_dirty_lock(), instead of SetPageDirty(). This
is probably more accurate.
As Christoph Hellwig put it, "set_page_dirty() is only safe if we are
dealing with a file backed page where we have reference on the inode it
hangs off." [3]
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
Suzuki K Poulose [Mon, 18 May 2020 18:02:40 +0000 (12:02 -0600)]
coresight: etm4x: Fix use-after-free of per-cpu etm drvdata
etm probe could be deferred due to the dependency in the trace
path chain and may be retried. We need to clear the per-cpu
etmdrvdata entry for the etm in case of a failure to avoid
use-after-free cases as reported below:
KASAN use-after-free bug in etm4_cpu_pm_notify():
[ 8.574566] coresight etm0: CPU0: ETM v4.2 initialized
[ 8.581920] BUG: KASAN: use-after-free in etm4_cpu_pm_notify+0x580/0x2024
[ 8.581925] Read of size 8 at addr ffffff813304f8c8 by task swapper/3/0
[ 8.581927]
[ 8.581934] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G S W 5.4.28 #314
[ 8.587775] coresight etm1: CPU1: ETM v4.2 initialized
[ 8.594195] Call trace:
[ 8.594205] dump_backtrace+0x0/0x188
[ 8.594209] show_stack+0x20/0x2c
[ 8.594216] dump_stack+0xdc/0x144
[ 8.594227] print_address_description+0x3c/0x494
[ 8.594232] __kasan_report+0x144/0x168
[ 8.601598] coresight etm2: CPU2: ETM v4.2 initialized
[ 8.602563] kasan_report+0x10/0x18
[ 8.602568] check_memory_region+0x1a4/0x1b4
[ 8.602572] __kasan_check_read+0x18/0x24
[ 8.602577] etm4_cpu_pm_notify+0x580/0x2024
[ 8.665945] notifier_call_chain+0x5c/0x90
[ 8.670166] __atomic_notifier_call_chain+0x90/0xf8
[ 8.675182] cpu_pm_notify+0x40/0x6c
[ 8.678858] cpu_pm_enter+0x38/0x80
[ 8.682451] psci_enter_idle_state+0x34/0x70
[ 8.686844] cpuidle_enter_state+0xb8/0x20c
[ 8.691143] cpuidle_enter+0x38/0x4c
[ 8.694820] call_cpuidle+0x3c/0x68
[ 8.698408] do_idle+0x1a0/0x280
[ 8.701729] cpu_startup_entry+0x24/0x28
[ 8.705768] secondary_start_kernel+0x15c/0x170
[ 8.710423]
[ 8.711972] Allocated by task 242:
[ 8.715473] __kasan_kmalloc+0xf0/0x1ac
[ 8.719426] kasan_slab_alloc+0x14/0x1c
[ 8.723375] __kmalloc_track_caller+0x23c/0x388
[ 8.728040] devm_kmalloc+0x38/0x94
[ 8.731632] etm4_probe+0x48/0x3c8
[ 8.735140] amba_probe+0xbc/0x158
[ 8.738645] really_probe+0x144/0x408
[ 8.742412] driver_probe_device+0x70/0x140
[ 8.746716] __device_attach_driver+0x9c/0x110
[ 8.751287] bus_for_each_drv+0x90/0xd8
[ 8.755236] __device_attach+0xb4/0x164
[ 8.759188] device_initial_probe+0x20/0x2c
[ 8.763490] bus_probe_device+0x34/0x94
[ 8.767436] device_add+0x34c/0x3e0
[ 8.771029] amba_device_try_add+0x68/0x440
[ 8.775332] amba_deferred_retry_func+0x48/0xc8
[ 8.779997] process_one_work+0x344/0x648
[ 8.784127] worker_thread+0x2ac/0x47c
[ 8.787987] kthread+0x128/0x138
[ 8.791313] ret_from_fork+0x10/0x18
[ 8.794993]
[ 8.796532] Freed by task 242:
[ 8.799684] __kasan_slab_free+0x15c/0x22c
[ 8.803897] kasan_slab_free+0x10/0x1c
[ 8.807761] kfree+0x25c/0x4bc
[ 8.810913] release_nodes+0x240/0x2b0
[ 8.814767] devres_release_all+0x3c/0x54
[ 8.818887] really_probe+0x178/0x408
[ 8.822661] driver_probe_device+0x70/0x140
[ 8.826963] __device_attach_driver+0x9c/0x110
[ 8.831539] bus_for_each_drv+0x90/0xd8
[ 8.835487] __device_attach+0xb4/0x164
[ 8.839431] device_initial_probe+0x20/0x2c
[ 8.843732] bus_probe_device+0x34/0x94
[ 8.847678] device_add+0x34c/0x3e0
[ 8.851274] amba_device_try_add+0x68/0x440
[ 8.855576] amba_deferred_retry_func+0x48/0xc8
[ 8.860240] process_one_work+0x344/0x648
[ 8.864366] worker_thread+0x2ac/0x47c
[ 8.868228] kthread+0x128/0x138
[ 8.871557] ret_from_fork+0x10/0x18
[ 8.875231]
[ 8.876782] The buggy address belongs to the object at ffffff813304f800
[ 8.876782] which belongs to the cache kmalloc-1k of size 1024
[ 8.889632] The buggy address is located 200 bytes inside of
[ 8.889632] 1024-byte region [ffffff813304f800, ffffff813304fc00)
[ 8.901761] The buggy address belongs to the page:
[ 8.906695] page:ffffffff04ac1200 refcount:1 mapcount:0 mapping:ffffff8146c03800 index:0x0 compound_mapcount: 0
[ 8.917047] flags: 0x4000000000010200(slab|head)
[ 8.921799] raw: 4000000000010200dead000000000100dead000000000122ffffff8146c03800
[ 8.929753] raw: 0000000000000000000000000010001000000001ffffffff0000000000000000
[ 8.937703] page dumped because: kasan: bad access detected
[ 8.943433]
[ 8.944974] Memory state around the buggy address:
[ 8.949903] ffffff813304f780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 8.957320] ffffff813304f800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 8.964742] >ffffff813304f880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 8.972157] ^
[ 8.977886] ffffff813304f900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 8.985298] ffffff813304f980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 8.992713] ==================================================================
Fixes: f188b5e76aae ("coresight: etm4x: Save/restore state across CPU low power states") Reported-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Mike Leach <mike.leach@linaro.org> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200518180242.7916-22-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephen Boyd [Mon, 18 May 2020 18:02:39 +0000 (12:02 -0600)]
coresight: Avoid casting void pointers
We don't need to cast void pointers, such as the amba_id data. Assign to
a local variable to make the code prettier and also return NULL instead
of 0 to make sparse happy.
Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Mike Leach <mike.leach@linaro.org> Reviewed-by: Joe Perches <joe@perches.com> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Mike Leach <mike.leach@linaro.org> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200518180242.7916-21-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephen Boyd [Mon, 18 May 2020 18:02:38 +0000 (12:02 -0600)]
coresight: Include required headers in C files
We should include headers that C files use in the C files that use them
and avoid relying on implicit includes as much as possible. This helps
avoid compiler errors in the future about missing declarations when
header files change includes in the future.
Cc: Douglas Anderson <dianders@chromium.org> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Mike Leach <mike.leach@linaro.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200518180242.7916-20-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
These variables are assigned again before they're used. Leave them
unassigned at first so that the compiler can detect problems in the
future with use before initialization.
Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Mike Leach <mike.leach@linaro.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200518180242.7916-18-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mike Leach [Mon, 18 May 2020 18:02:33 +0000 (12:02 -0600)]
coresight: etmv4: Update default filter and initialisation
Differing default states set on driver init / perf init and as a result
of a sysfs reset.
The ETMv4 can be programmed to trace the entire instruction address range
without the need to use address comparator filter resources.
(Described in the ETMv4.x technical reference manual)
sysfs reset was using this method, perf and default driver init were setup
with an address range comparator for the entire address range.
The perf / driver init has been altered to use the method without needing
any comparator address hardware.
Minor adjustment to the vinst_ctrl register initialisation to ensure
correct zero initialisation.
coresight: tmc: Fix TMC mode read in tmc_read_prepare_etb()
On some QCOM platforms like SC7180, SDM845 and SM8150,
reading TMC mode register without proper coresight power
management can lead to async exceptions like the one in
the call trace below in tmc_read_prepare_etb(). This can
happen if the user tries to read the TMC etf data via
device node without setting up source and the sink first.
Fix this by having a check for coresight sysfs mode
before reading TMC mode management register.
Suzuki K Poulose [Mon, 18 May 2020 18:02:31 +0000 (12:02 -0600)]
coresight: Fix support for sparsely populated ports
On some systems the firmware may not describe all the ports
connected to a component (e.g, for security reasons). This
could be especially problematic for "funnels" where we could
end up in modifying memory beyond the allocated space for
refcounts.
e.g, for a funnel with input ports listed 0, 3, 5, nr_inport = 3.
However the we could access refcnts[5] while checking for
references, like :
[ 526.316810]
[ 526.318364] Freed by task 0:
[ 526.321344] (stack is not available)
[ 526.325024]
[ 526.326580] The buggy address belongs to the object at ffffff8135f95480
[ 526.326580] which belongs to the cache kmalloc-128 of size 128
[ 526.339439] The buggy address is located 28 bytes inside of
[ 526.339439] 128-byte region [ffffff8135f95480, ffffff8135f95500)
[ 526.351399] The buggy address belongs to the page:
[ 526.356342] page:ffffffff04b7e500 refcount:1 mapcount:0 mapping:ffffff814b00c380 index:0x0 compound_mapcount: 0
[ 526.366711] flags: 0x4000000000010200(slab|head)
[ 526.371475] raw: 4000000000010200ffffffff05034008ffffffff0501eb08ffffff814b00c380
[ 526.379435] raw: 0000000000000000000000000019001900000001ffffffff0000000000000000
[ 526.387393] page dumped because: kasan: bad access detected
[ 526.393128]
[ 526.394681] Memory state around the buggy address:
[ 526.399619] ffffff8135f95380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 526.407046] ffffff8135f95400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 526.414473] >ffffff8135f95480: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 526.421900] ^
[ 526.426029] ffffff8135f95500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 526.433456] ffffff8135f95580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 526.440883] ==================================================================
To keep the code simple, we now track the maximum number of
possible input/output connections to/from this component
@ nr_inport and nr_outport in platform_data, respectively.
Thus the output connections could be sparse and code is
adjusted to skip the unspecified connections.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Mike Leach <mike.leach@linaro.org> Reported-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Tested-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200518180242.7916-13-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason Yan [Mon, 18 May 2020 18:02:29 +0000 (12:02 -0600)]
coresight: cti: Make some symbols static
Fix the following sparse warning:
drivers/hwtracing/coresight/coresight-cti.c:22:1: warning: symbol
'ect_net' was not declared. Should it be static?
drivers/hwtracing/coresight/coresight-cti.c:625:32: warning: symbol
'cti_ops_ect' was not declared. Should it be static?
drivers/hwtracing/coresight/coresight-cti.c:630:28: warning: symbol
'cti_ops' was not declared. Should it be static?
Suzuki K Poulose [Mon, 18 May 2020 18:02:23 +0000 (12:02 -0600)]
coresight: Expose device connections via sysfs
Coresight device connections are a bit complicated and is not
exposed currently to the user. One has to look at the platform
descriptions (DT bindings or ACPI bindings) to make an understanding.
Given the new naming scheme, it will be helpful to have this information
to choose the appropriate devices for tracing. This patch exposes
the device connections via links in the sysfs directories.
e.g, for a connection devA[OutputPort_X] -> devB[InputPort_Y]
is represented as two symlinks:
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
[Revised to use the generic sysfs links functions & link structures.
Provides a connections sysfs group in each device to hold the links.] Co-developed-by: Mike Leach <mike.leach@linaro.org> Signed-off-by: Mike Leach <mike.leach@linaro.org> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200518180242.7916-5-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mike Leach [Mon, 18 May 2020 18:02:22 +0000 (12:02 -0600)]
coresight: Add generic sysfs link creation functions
To allow the connections between coresight components to be represented
in sysfs, generic methods for creating sysfs links between two coresight
devices are added.
Signed-off-by: Mike Leach <mike.leach@linaro.org> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200518180242.7916-4-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suzuki K Poulose [Mon, 18 May 2020 18:02:21 +0000 (12:02 -0600)]
coresight: Add return value for fixup connections
Handle failures in fixing up connections for a newly registered
device. This will be useful to handle cases where we fail to expose
the links via sysfs for the connections.
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Mike Leach <mike.leach@linaro.org> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200518180242.7916-3-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suzuki K Poulose [Mon, 18 May 2020 18:02:20 +0000 (12:02 -0600)]
coresight: Pass coresight_device for coresight_release_platform_data
As we prepare to expose the links between the devices in
sysfs, pass the coresight_device instance to the
coresight_release_platform_data in order to free up the connections
when the device is removed.
No functional changes as such in this patch.
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Mike Leach <mike.leach@linaro.org> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200518180242.7916-2-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge tag 'misc-habanalabs-next-2020-05-19' of git://people.freedesktop.org/~gabbayo/linux into char-misc-next
Oded writes:
This tag contains the following changes for kernel 5.8:
- GAUDI ASIC support. The tag contains code and header files needed to
initialize the GAUDI ASIC and run workloads on it. There are changes to
the common code that are needed for GAUDI and there is the addition of
new ASIC-dependent code of GAUDI.
- Add new feature of signal/wait command submissions. This is relevant to
GAUDI only and allows the user to sync between streams (queues) inside
the device.
- Allow user to retrieve the device time alongside the host time, to allow
a user application to synchronize device time together with host
time during profiling.
- Change ASIC's CPU initialization by loading its boot loader code from the
Host memory (instead of it being programmed on the on-board FLASH).
- Expose more attributes through HWMON.
- Move the ASIC event handling code to be "common code". This will be
shared between GAUDI and future ASICs. Goya will still use its own code.
- Fix bug in command submission parsing in Goya.
- Small fixes to security configuration (open up some registers for user
access).
- Improvements to ASIC reset code.
* tag 'misc-habanalabs-next-2020-05-19' of git://people.freedesktop.org/~gabbayo/linux: (38 commits)
habanalabs: update patched_cb_size for Wreg32
habanalabs: move event handling to common firmware file
habanalabs: enable gaudi code in driver
habanalabs: add gaudi profiler module
habanalabs: add gaudi security module
habanalabs: add hwmgr module for gaudi
habanalabs: add gaudi asic-dependent code
uapi: habanalabs: add gaudi defines
habanalabs: add gaudi asic registers header files
habanalabs: get card type, location from F/W
habanalabs: support clock gating enable/disable
habanalabs: set PM profile to auto only for goya
habanalabs: add dedicated define for hard reset
habanalabs: check if CoreSight is supported
habanalabs: add signal/wait to CS IOCTL operations
habanalabs: handle the h/w sync object
habanalabs: define ASIC-dependent interface for signal/wait
uapi: habanalabs: add signal/wait operations
habanalabs: add missing MODULE_DEVICE_TABLE
habanalabs: print all CB handles as hex numbers
...
Ofir Bitton [Sun, 10 May 2020 10:41:28 +0000 (13:41 +0300)]
habanalabs: move event handling to common firmware file
Instead of writing similar event handling code for each ASIC, move the code
to the common firmware file. This code will be used for GAUDI and all
future ASICs.
In addition, add two new fields to the auto-generated events file: valid
and description. This will save the need to manually write the events
description in the source code and simplify the code.
Omer Shpigelman [Mon, 11 May 2020 07:46:29 +0000 (10:46 +0300)]
habanalabs: add gaudi profiler module
Add the GAUDI code to initialize the ASIC's profiler. The profile receives
its initialization values from the user, same as in Goya, but the code to
initialize is in the driver because the configuration space of the
device is not directly exposed to the user.
Omer Shpigelman [Mon, 11 May 2020 07:45:12 +0000 (10:45 +0300)]
habanalabs: add gaudi security module
Add the code to initialize the security module of GAUDI. Similar to Goya,
we have two dedicated mechanisms for security: Range Registers and
Protection bits. Those mechanisms protect sensitive memory and
configuration areas inside the device.
In addition, in Gaudi we moved to a 3-level security scheme, where the F/W
runs with the highest security level (Privileged), the driver runs with a
less secured level (Secured) and the user is neither privileged nor
secured. The security module in the driver configures the Secured parts so
the user won't be able to access them. The Privileged parts are configured
by the F/W.
Oded Gabbay [Mon, 11 May 2020 07:41:37 +0000 (10:41 +0300)]
habanalabs: add hwmgr module for gaudi
The hwmgr module is responsible for messages sent to GAUDI F/W that are
not common to all habanalabs ASICs.
In GAUDI, we provide the user a simplified mode of controlling the ASIC
clock frequency. Instead of three different clocks, we present a single
clock property that the user can configure via sysfs.
Oded Gabbay [Mon, 11 May 2020 07:29:27 +0000 (10:29 +0300)]
habanalabs: add gaudi asic-dependent code
Add the ASIC-dependent code for GAUDI. Supply (almost) all of the function
callbacks that the driver's common code need to initialize, finalize and
submit workloads to the GAUDI ASIC.
It also contains the code to initialize the F/W of the GAUDI ASIC and to
receive events from the F/W.
Oded Gabbay [Sun, 3 May 2020 14:33:40 +0000 (17:33 +0300)]
habanalabs: add gaudi asic registers header files
Add the relevant GAUDI ASIC registers header files. These files are
generated automatically from a tool maintained by the VLSI engineers.
There are more files which are not upstreamed because only very few defines
from those files are used in the driver. For those files, we copied the
relevant defines into gaudi_regs.h and gaudi_masks.h, to reduce the size of
this patch.
Omer Shpigelman [Sun, 3 May 2020 14:35:54 +0000 (17:35 +0300)]
habanalabs: get card type, location from F/W
For Gaudi the driver gets two new additional properties from the F/W:
1. The card's type - PCI or PMC
2. The card's location in the Gaudi's box (relevant only for PMC).
The card's location is also passed to the user in the HW IP info structure
as it needs this property for establishing communication between Gaudis.
Oded Gabbay [Sat, 9 May 2020 09:17:21 +0000 (12:17 +0300)]
habanalabs: support clock gating enable/disable
In Gaudi there is a feature of clock gating certain engines.
Therefore, add this property to the device structure.
In addition, due to a limitation of this feature, the driver needs to
dynamically enable or disable this feature during run-time. Therefore, add
ASIC interface functions to enable/disable this function from the common
code.
Moreover, this feature must be turned off when the user wishes to debug the
ASIC by reading/writing registers and/or memory through the driver's
debugfs. Therefore, add an option to enable/disable clock gating via the
debugfs interface.
Oded Gabbay [Sat, 9 May 2020 09:18:26 +0000 (12:18 +0300)]
habanalabs: set PM profile to auto only for goya
For Gaudi, the driver doesn't change the PM profile automatically due to
device-controlled PM capabilities. Therefore, set the PM profile to auto
only for Goya so the driver's code to automatically change the profile
won't run on Gaudi.
Omer Shpigelman [Sat, 9 May 2020 09:18:01 +0000 (12:18 +0300)]
habanalabs: add dedicated define for hard reset
Gaudi requires longer waiting during reset due to closing of network ports.
Add this explanation to the relevant comment in the code and add a
dedicated define for this reset timeout period, instead of multiplying
another define.
Omer Shpigelman [Thu, 7 May 2020 11:31:49 +0000 (14:31 +0300)]
habanalabs: add signal/wait to CS IOCTL operations
Add the following two operations to the CS IOCTL:
Signal:
The signal operation is basically a command submission, that is created by
the driver upon user request. It will be implemented using a dedicated PQE
that will increment a specific SOB. There will be a new flag:
HL_CS_FLAGS_SIGNAL. When the user set this flag in the CS IOCTL structure,
the driver will execute a dedicated code path that will prepare this
special PQE and submit it. The user only needs to provide a queue index on
which to put the signal.
Wait:
The wait operation is also a command submission that is created by the
driver upon user request. It will be implemented using a dedicated PQE that
will contain packets of "ARM a monitor" + FENCE packet. There will be a new
flag: HL_CS_FLAGS_WAIT. When the user set this flag in the CS structure,
the driver will execute a dedicated code path that will prepare this
special PQE and submit it.
The user needs to provide the following parameters:
1. queue ID
2. an array of signal_seq numbers and the number of signals to wait on
(the length of signal_seq_arr).
The IOCTL will return the CS sequence number of the wait it put on the
queue ID.
Currently, the code supports signal_seq_nr==1. But this API definition will
allow us to put a single PQE that waits on multiple signals.
To correctly configure the monitor and fence, the driver will need to
retrieve the specified signal CS object that contains the relevant SOB and
its expected value. In case the signal CS has already been completed, there
is no point of adding a wait operation. In this case, the driver will
return to the user *without* putting anything on the PQ. The return code
should reflect to the user that the signal was completed, as we won't
return a CS sequence number for this wait.
Omer Shpigelman [Thu, 7 May 2020 10:57:36 +0000 (13:57 +0300)]
habanalabs: handle the h/w sync object
Define a structure representing the h/w sync object (SOB).
a SOB can contain up to 2^15 values. Each signal CS will increment the SOB
by 1, so after some time we will reach the maximum number the SOB can
represent. When that happens, the driver needs to move to a different SOB
for the signal operation.
A SOB can be in 1 of 4 states:
1. Working state with value < 2^15
2. We reached a value of 2^15, but the signal operations weren't completed
yet OR there are pending waits on this signal. For the next submission, the
driver will move to another SOB.
3. ALL the signal operations on the SOB have finished AND there are no more
pending waits on the SOB AND we reached a value of 2^15 (This basically
means the refcnt of the SOB is 0 - see explanation below). When that
happens, the driver can clear the SOB by simply doing WREG32 0 to it and
set the refcnt back to 1.
4. The SOB is cleared and can be used next time by the driver when it needs
to reuse an SOB.
Per SOB, the driver will maintain a single refcnt, that will be initialized
to 1. When a signal or wait operation on this SOB is submitted to the PQ,
the refcnt will be incremented. When a signal or wait operation on this SOB
completes, the refcnt will be decremented. After the submission of the
signal operation that increments the SOB to a value of 2^15, the refcnt is
also decremented.
Omer Shpigelman [Thu, 7 May 2020 10:43:05 +0000 (13:43 +0300)]
habanalabs: define ASIC-dependent interface for signal/wait
This feature requires handling h/w resources which are a bit different from
one ASIC to the other. Therefore, we need to define a set of interfaces the
ASIC code provides to the common code to signal, wait, reset sync object
and to reset and init a queue.
As this feature is not supported in Goya, provide an empty implementation
of those functions.
Omer Shpigelman [Thu, 7 May 2020 10:41:16 +0000 (13:41 +0300)]
uapi: habanalabs: add signal/wait operations
This is a pre-requisite to upstreaming GAUDI support.
Signal/wait operations are done by the user to perform sync between two
Primary Queues (PQs). The sync is done using the sync manager and it is
usually resolved inside the device, but sometimes it can be resolved in the
host, i.e. the user should be able to wait in the host until a signal has
been completed.
The mechanism to define signal and wait operations is done by the driver
because it needs atomicity and serialization, which is already done in the
driver when submitting work to the different queues.
To implement this feature, the driver "takes" a couple of h/w resources,
and this is reflected by the defines added to the uapi file.
The signal/wait operations are done via the existing CS IOCTL, and they use
the same data structure. There is a difference in the meaning of some of
the parameters, and for that we added unions to make the code more
readable.
The user must leave space for 2xMSG_PROT in the external CB, so adjust the
define of max size accordingly. The driver, however, can still create a CB
with the maximum size of 2MB. Therefore, we need to add a check
specifically for the user requested size.
Tomer Tayar [Tue, 31 Mar 2020 19:46:36 +0000 (22:46 +0300)]
habanalabs: Add INFO IOCTL opcode for time sync information
Add a new opcode to the INFO IOCTL that retrieves the device time
alongside the host time, to allow a user application that want to measure
device time together with host time (such as a profiler) to synchronize
these times.
projects / kernel.git / log