linux.git/drivers/misc, branch v5.7.15

lkdtm/heap: Avoid edge and middle of slabs

2020-08-11T13:35:33+00:00

commit e12145cf1c3a8077e6d9f575711e38dd7d8a3ebc upstream.

Har har, after I moved the slab freelist pointer into the middle of the
slab, now it looks like the contents are getting poisoned. Adjust the
test to avoid the freelist pointer again.

Fixes: 3202fa62fb43 ("slub: relocate freelist pointer to middle of object")
Cc: stable@vger.kernel.org
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20200625203704.317097-3-keescook@chromium.org
Signed-off-by: Greg Kroah-Hartman

habanalabs: prevent possible out-of-bounds array access

2020-08-05T07:58:48+00:00

[ Upstream commit cea7a0449ea3fa4883bf5dc8397f000d6b67d6cd ]

Queue index is received from the user. Therefore, we must validate it
before using it to access the queue props array.

Signed-off-by: Oded Gabbay 
Reviewed-by: Tomer Tayar 
Signed-off-by: Sasha Levin

misc: atmel-ssc: lock with mutex instead of spinlock

2020-07-22T07:34:24+00:00

commit b037d60a3b1d1227609fd858fa34321f41829911 upstream.

Uninterruptible context is not needed in the driver and causes lockdep
warning because of mutex taken in of_alias_get_id(). Convert the lock to
mutex to avoid the issue.

Cc: stable@vger.kernel.org
Fixes: 099343c64e16 ("ARM: at91: atmel-ssc: add device tree support")
Signed-off-by: Michał Mirosław 
Link: https://lore.kernel.org/r/50f0d7fa107f318296afb49477c3571e4d6978c5.1592998403.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Greg Kroah-Hartman

mei: bus: don't clean driver pointer

2020-07-22T07:34:21+00:00

commit e852c2c251ed9c23ae6e3efebc5ec49adb504207 upstream.

It's not needed to set driver to NULL in mei_cl_device_remove()
which is bus_type remove() handler as this is done anyway
in __device_release_driver().

Actually this is causing an endless loop in driver_detach()
on ubuntu patched kernel, while removing (rmmod) the mei_hdcp module.
The reason list_empty(&drv->p->klist_devices.k_list) is always not-empty.
as the check is always true in  __device_release_driver()
	if (dev->driver != drv)
		return;

The non upstream patch is causing this behavior, titled:
'vfio -- release device lock before userspace requests'

Nevertheless the fix is correct also for the upstream.

Link: https://patchwork.ozlabs.org/project/ubuntu-kernel/patch/20180912085046.3401-2-apw@canonical.com/
Cc: 
Cc: Andy Whitcroft 
Signed-off-by: Alexander Usyskin 
Signed-off-by: Tomas Winkler 
Link: https://lore.kernel.org/r/20200628225359.2185929-1-tomas.winkler@intel.com
Signed-off-by: Greg Kroah-Hartman

habanalabs: Align protection bits configuration of all TPCs

2020-07-22T07:34:12+00:00

commit 79c823c57e69d9e584a5ee4ee6406eb3854393ae upstream.

Align the protection bits configuration of all TPC cores to be as of TPC
core 0.

Fixes: a513f9a7eca5 ("habanalabs: make tpc registers secured")

Signed-off-by: Tomer Tayar 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
Signed-off-by: Greg Kroah-Hartman

mei: me: add tiger lake point device ids for H platforms.

2020-06-30T19:35:54+00:00

commit 8c289ea064165237891a7b4be77b74d5cba8fa99 upstream.

Add Tiger Lake device ids H for HECI1.
TGH_H is also used in Tatlow SPS platform we need to
disable the mei interface there.

Cc: 
Signed-off-by: Alexander Usyskin 
Signed-off-by: Tomas Winkler 
Link: https://lore.kernel.org/r/20200619165121.2145330-7-tomas.winkler@intel.com
Signed-off-by: Greg Kroah-Hartman

mei: me: disable mei interface on Mehlow server platforms

2020-06-30T19:35:54+00:00

commit f76d77f50b343bc7f7d01e4c2771d43fb074f617 upstream.

For SPS firmware versions 5.0 and newer the way detection has changed.
The detection is done now via PCI_CFG_HFS_3 register.
To prevent conflict the previous method will get sps_4 suffix
Disable both CNP_H and CNP_H_3 interfaces. CNP_H_3 requires
a separate configuration as it doesn't support DMA.

Cc: 
Signed-off-by: Tomas Winkler 
Link: https://lore.kernel.org/r/20200619165121.2145330-1-tomas.winkler@intel.com
Signed-off-by: Greg Kroah-Hartman

misc: xilinx-sdfec: improve get_user_pages_fast() error handling

2020-06-24T15:48:58+00:00

[ Upstream commit 57343d51613227373759f5b0f2eede257fd4b82e ]

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.

Fixes: 20ec628e8007e ("misc: xilinx_sdfec: Add ability to configure LDPC")
Cc: Derek Kiernan 
Cc: Dragan Cvetic 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Cc: Michal Simek 
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: John Hubbard 
Link: https://lore.kernel.org/r/20200527012628.1100649-2-jhubbard@nvidia.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

habanalabs: increase timeout during reset

2020-06-24T15:48:47+00:00

[ Upstream commit 7a65ee046b2238e053f6ebb610e1a082cfc49490 ]

When doing training, the DL framework (e.g. tensorflow) performs hundreds
of thousands of memory allocations and mappings. In case the driver needs
to perform hard-reset during training, the driver kills the application and
unmaps all those memory allocations. Unfortunately, because of that large
amount of mappings, the driver isn't able to do that in the current timeout
(5 seconds). Therefore, increase the timeout significantly to 30 seconds
to avoid situation where the driver resets the device with active mappings,
which sometime can cause a kernel bug.

BTW, it doesn't mean we will spend all the 30 seconds because the reset
thread checks every one second if the unmap operation is done.

Reviewed-by: Omer Shpigelman 
Signed-off-by: Oded Gabbay 
Signed-off-by: Sasha Levin

habanalabs: don't allow hard reset with open processes

2020-06-24T15:48:26+00:00

[ Upstream commit 36fafe87edd636292a4ed6a3af9608f2c7d0d0fb ]

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.

Signed-off-by: Omer Shpigelman 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
Signed-off-by: Sasha Levin