linux-stable.git/drivers/misc, branch v5.14.9

misc: genwqe: Fixes DMA mask setting

2021-09-30T08:12:55+00:00

commit 8d753db5c227d1f403c4bc9cae4ae02c862413cd upstream.

Commit 505b08777d78 ("misc: genwqe: Use dma_set_mask_and_coherent to simplify code")
changed the logic in the code.

Instead of a ||, a && should have been used to keep the code the same.

Fixes: 505b08777d78 ("misc: genwqe: Use dma_set_mask_and_coherent to simplify code")
Cc: stable 
Signed-off-by: Christophe JAILLET 
Link: https://lore.kernel.org/r/be49835baa8ba6daba5813b399edf6300f7fdbda.1631130862.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman

misc: bcm-vk: fix tty registration race

2021-09-30T08:12:55+00:00

commit d9d1232b48344c6c72dbdf89fae1e7638e5df757 upstream.

Make sure to set the tty class-device driver data before registering the
tty to avoid having a racing open() dereference a NULL pointer.

Fixes: 91ca10d6fa07 ("misc: bcm-vk: add ttyVK support")
Cc: stable@vger.kernel.org      # 5.12
Signed-off-by: Johan Hovold 
Link: https://lore.kernel.org/r/20210917115736.5816-1-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman

habanalabs: cannot sleep while holding spinlock

2021-09-26T12:10:24+00:00

[ Upstream commit 607b1468c2263e082d74c1a3e71399a9026b41ce ]

Fix 2 areas in the code where it's possible the code will
go to sleep while holding a spinlock.

Reported-by: Dan Carpenter 
Signed-off-by: farah kassabri 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
Signed-off-by: Sasha Levin

habanalabs: add "in device creation" status

2021-09-26T12:10:24+00:00

[ Upstream commit 71731090ab17a208a58020e4b342fdfee280458a ]

On init, the disabled state is cleared right before hw_init and that
causes the device to report on "Operational" state before the device
initialization is finished. Although the char device is not yet exposed
to the user at this stage, the sysfs entries are exposed.

This can cause errors in monitoring applications that use the sysfs
entries.

In order to avoid this, a new state "in device creation" is introduced
to ne reported when the device is not disabled but is still in init
flow.

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

habanalabs: fix mmu node address resolution in debugfs

2021-09-26T12:10:24+00:00

[ Upstream commit 09ae43043c748423a5dcdc7bb1e63e4dcabe9bd6 ]

The address resolution via debugfs was not taking into consideration the
page offset, resulting in a wrong address.

Signed-off-by: Yuri Nudelman 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
Signed-off-by: Sasha Levin

habanalabs: add validity check for event ID received from F/W

2021-09-26T12:10:23+00:00

[ Upstream commit a6c849012b0f51c674f52384bd9a4f3dc0a33c31 ]

Currently there is no validity check for event ID received from F/W,
Thus exposing driver to memory overrun.

Signed-off-by: Ofir Bitton 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
Signed-off-by: Sasha Levin

habanalabs: fix nullifying of destroyed mmu pgt pool

2021-09-26T12:10:23+00:00

[ Upstream commit 89aad770d692e4d2d9a604c1674e9dfa69421430 ]

In case of host-resident MMU, when the page tables pool is destroyed,
its pointer is not nullified correctly.
As a result, on a device fini which happens after a failing reset, the
already destroyed pool is accessed, which leads to a kernel panic.
The patch fixes the setting of the pool pointer to NULL.

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

misc: sram: Only map reserved areas in Tegra SYSRAM

2021-09-18T11:43:47+00:00

[ Upstream commit fec29bf04994b478a43a7e60e6dd5ac1f7cb53ae ]

On Tegra186 and later, a portion of the SYSRAM may be reserved for use
by TZ. Non-TZ memory accesses to this portion, including speculative
accesses, trigger SErrors that bring down the system. This does also
happen in practice occasionally (due to speculative accesses).

To fix the issue, add a flag to the SRAM driver to only map the
device tree-specified reserved areas depending on a flag set
based on the compatibility string. This would not affect non-Tegra
systems that rely on the entire thing being memory mapped.

If 64K pages are being used, we cannot exactly map the 4K regions
that are placed in SYSRAM - ioremap code instead aligns to closest
64K pages. However, since in practice the non-accessible memory area
is 64K aligned, these mappings do not overlap with the non-accessible
memory area and things work out.

Reviewed-by: Mian Yousaf Kaukab 
Signed-off-by: Mikko Perttunen 
Link: https://lore.kernel.org/r/20210715103423.1811101-1-mperttunen@nvidia.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

misc/pvpanic-pci: Allow automatic loading

2021-09-18T11:43:40+00:00

[ Upstream commit 28b6a003bcdfa1fc4603b9185b247ecca7af9bef ]

The virtual machine monitor (QEMU) exposes the pvpanic-pci
device to the guest. On guest side the module exists but
currently isn't loaded automatically. So the driver fails
to be probed and does not its job of handling guest panic
events.

Instead of requiring manual modprobe, let's include a device
database using the MODULE_DEVICE_TABLE macro and let the
module auto-load when the guest gets exposed with such a
pvpanic-pci device.

Signed-off-by: Eric Auger 
Link: https://lore.kernel.org/r/20210629072214.901004-1-eric.auger@redhat.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

VMCI: fix NULL pointer dereference when unmapping queue pair

2021-09-18T11:43:23+00:00

commit a30dc6cf0dc51419021550152e435736aaef8799 upstream.

I got a NULL pointer dereference report when doing fuzz test:

Call Trace:
  qp_release_pages+0xae/0x130
  qp_host_unregister_user_memory.isra.25+0x2d/0x80
  vmci_qp_broker_unmap+0x191/0x320
  ? vmci_host_do_alloc_queuepair.isra.9+0x1c0/0x1c0
  vmci_host_unlocked_ioctl+0x59f/0xd50
  ? do_vfs_ioctl+0x14b/0xa10
  ? tomoyo_file_ioctl+0x28/0x30
  ? vmci_host_do_alloc_queuepair.isra.9+0x1c0/0x1c0
  __x64_sys_ioctl+0xea/0x120
  do_syscall_64+0x34/0xb0
  entry_SYSCALL_64_after_hwframe+0x44/0xae

When a queue pair is created by the following call, it will not
register the user memory if the page_store is NULL, and the
entry->state will be set to VMCIQPB_CREATED_NO_MEM.

vmci_host_unlocked_ioctl
  vmci_host_do_alloc_queuepair
    vmci_qp_broker_alloc
      qp_broker_alloc
        qp_broker_create // set entry->state = VMCIQPB_CREATED_NO_MEM;

When unmapping this queue pair, qp_host_unregister_user_memory() will
be called to unregister the non-existent user memory, which will
result in a null pointer reference. It will also change
VMCIQPB_CREATED_NO_MEM to VMCIQPB_CREATED_MEM, which should not be
present in this operation.

Only when the qp broker has mem, it can unregister the user
memory when unmapping the qp broker.

Only when the qp broker has no mem, it can register the user
memory when mapping the qp broker.

Fixes: 06164d2b72aa ("VMCI: queue pairs implementation.")
Cc: stable 
Reported-by: Hulk Robot 
Reviewed-by: Jorgen Hansen 
Signed-off-by: Wang Hai 
Link: https://lore.kernel.org/r/20210818124845.488312-1-wanghai38@huawei.com
Signed-off-by: Greg Kroah-Hartman