linux-stable.git/drivers/rapidio, branch linux-6.3.y

driver core: make struct bus_type.uevent() take a const *

2023-01-27T12:45:52+00:00

The uevent() callback in struct bus_type should not be modifying the
device that is passed into it, so mark it as a const * and propagate the
function signature changes out into all relevant subsystems that use
this callback.

Acked-by: Rafael J. Wysocki 
Acked-by: Hans de Goede 
Link: https://lore.kernel.org/r/20230111113018.459199-16-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman

rapidio: devices: fix missing put_device in mport_cdev_open

2022-12-12T03:30:20+00:00

When kfifo_alloc fails, the refcount of chdev->dev is left incremental. 
We should use put_device(&chdev->dev) to decrease the ref count of
chdev->dev to avoid refcount leak.

Link: https://lkml.kernel.org/r/20221203085721.13146-1-caixinchen1@huawei.com
Fixes: e8de370188d0 ("rapidio: add mport char device driver")
Signed-off-by: Cai Xinchen 
Cc: Alexandre Bounine 
Cc: Dan Carpenter 
Cc: Jakob Koschel 
Cc: John Hubbard 
Cc: Matt Porter 
Cc: Wang Weiyang 
Cc: Yang Yingliang 
Signed-off-by: Andrew Morton

rapidio: fix possible UAF when kfifo_alloc() fails

2022-12-12T03:30:18+00:00

If kfifo_alloc() fails in mport_cdev_open(), goto err_fifo and just free
priv. But priv is still in the chdev->file_list, then list traversal
may cause UAF. This fixes the following smatch warning:

drivers/rapidio/devices/rio_mport_cdev.c:1930 mport_cdev_open() warn: '&priv->list' not removed from list

Link: https://lkml.kernel.org/r/20221123095147.52408-1-wangweiyang2@huawei.com
Fixes: e8de370188d0 ("rapidio: add mport char device driver")
Signed-off-by: Wang Weiyang 
Cc: Alexandre Bounine 
Cc: Dan Carpenter 
Cc: Jakob Koschel 
Cc: John Hubbard 
Cc: Matt Porter 
Cc: Yang Yingliang 
Signed-off-by: Andrew Morton

rapidio: rio: fix possible name leak in rio_register_mport()

2022-12-01T00:13:17+00:00

If device_register() returns error, the name allocated by dev_set_name()
need be freed.  It should use put_device() to give up the reference in the
error path, so that the name can be freed in kobject_cleanup(), and
list_del() is called to delete the port from rio_mports.

Link: https://lkml.kernel.org/r/20221114152636.2939035-3-yangyingliang@huawei.com
Fixes: 2aaf308b95b2 ("rapidio: rework device hierarchy and introduce mport class of devices")
Signed-off-by: Yang Yingliang 
Cc: Alexandre Bounine 
Cc: Matt Porter 
Signed-off-by: Andrew Morton

rapidio: fix possible name leaks when rio_add_device() fails

2022-12-01T00:13:17+00:00

Patch series "rapidio: fix three possible memory leaks".

This patchset fixes three name leaks in error handling.
 - patch #1 fixes two name leaks while rio_add_device() fails.
 - patch #2 fixes a name leak while  rio_register_mport() fails.


This patch (of 2):

If rio_add_device() returns error, the name allocated by dev_set_name()
need be freed.  It should use put_device() to give up the reference in the
error path, so that the name can be freed in kobject_cleanup(), and the
'rdev' can be freed in rio_release_dev().

Link: https://lkml.kernel.org/r/20221114152636.2939035-1-yangyingliang@huawei.com
Link: https://lkml.kernel.org/r/20221114152636.2939035-2-yangyingliang@huawei.com
Fixes: e8de370188d0 ("rapidio: add mport char device driver")
Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array")
Signed-off-by: Yang Yingliang 
Cc: Alexandre Bounine 
Cc: Matt Porter 
Signed-off-by: Andrew Morton

rapidio/tsi721: replace flush_scheduled_work() with flush_work()

2022-11-18T21:55:09+00:00

Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a
macro") says, flush_scheduled_work() is dangerous and will be forbidden. 
We are on the way for removing all flush_scheduled_work() callers from the
kernel, and this patch is for removing flush_scheduled_work() call from
tsi721 driver.

Since "struct tsi721_device" is per a device struct, I assume that
tsi721_remove() needs to wait for only two works associated with that
device.  Therefore, wait for only these works using flush_work().

Link: https://lkml.kernel.org/r/0e8a2023-7526-f03a-f520-efafbb0ef45c@I-love.SAKURA.ne.jp
Signed-off-by: Tetsuo Handa 
Cc: Alexandre Bounine 
Cc: Arnd Bergmann 
Cc: Christophe JAILLET 
Cc: Matt Porter 
Signed-off-by: Andrew Morton

rapidio: remove unnecessary use of list iterator

2022-04-29T21:38:03+00:00

req->map is set in the valid case and always equals 'map' if the break was
hit.  It therefore is unnecessary to use the list iterator variable and
the use of 'map' can be replaced with req->map.

This is done in preparation to limit the scope of a list iterator to the
list traversal loop [1].

Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/
Link: https://lkml.kernel.org/r/20220319203344.2547702-1-jakobkoschel@gmail.com
Signed-off-by: Jakob Koschel 
Reviewed-by: John Hubbard 
Cc: Matt Porter 
Cc: Alexandre Bounine 
Cc: Kees Cook 
Cc: Mike Rapoport 
Cc: "Brian Johannesmeyer" 
Cc: Cristiano Giuffrida 
Cc: "Bos, H.J." 
Signed-off-by: Andrew Morton

rapidio/tsi721: Remove usage of the deprecated "pci-dma-compat.h" API

2022-02-25T16:19:21+00:00

In [1], Christoph Hellwig has proposed to remove the wrappers in
include/linux/pci-dma-compat.h.

Some reasons why this API should be removed have been given by Julia
Lawall in [2].

A coccinelle script has been used to perform the needed transformation.
It can be found in [3].

[1]: https://lore.kernel.org/kernel-janitors/20200421081257.GA131897@infradead.org/
[2]: https://lore.kernel.org/kernel-janitors/alpine.DEB.2.22.394.2007120902170.2424@hadrien/
[3]: https://lore.kernel.org/kernel-janitors/20200716192821.321233-1-christophe.jaillet@wanadoo.fr/

Signed-off-by: Christophe JAILLET 
Reviewed-by: Arnd Bergmann 
Signed-off-by: Christoph Hellwig

rapidio: remove not used code about RIO_VID_TUNDRA

2021-12-21T09:22:19+00:00

According to https://rapidio.org/vendor-id/, there is no 0x000d vendor id
in the complete and current list of VendorIDs, it means that the related
code is dead code now, so just remove them.

Signed-off-by: Tiezhu Yang 
Link: https://lore.kernel.org/r/1639625581-22867-3-git-send-email-yangtiezhu@loongson.cn
Signed-off-by: Greg Kroah-Hartman

rapidio: avoid bogus __alloc_size warning

2021-11-06T20:30:33+00:00

Patch series "Add __alloc_size()", v3.

GCC and Clang both use the "alloc_size" attribute to assist with bounds
checking around the use of allocation functions.  Add the attribute,
adjust the Makefile to silence needless warnings, and add the hints to
the allocators where possible.  These changes have been in use for a
while now in GrapheneOS.

This patch (of 8):

After adding __alloc_size attributes to the allocators, GCC 9.3 (but not
later) may incorrectly evaluate the arguments to check_copy_size(),
getting seemingly confused by the size being returned from array_size().
Instead, perform the calculation once, which both makes the code more
readable and avoids the bug in GCC.

   In file included from arch/x86/include/asm/preempt.h:7,
                    from include/linux/preempt.h:78,
                    from include/linux/spinlock.h:55,
                    from include/linux/mm_types.h:9,
                    from include/linux/buildid.h:5,
                    from include/linux/module.h:14,
                    from drivers/rapidio/devices/rio_mport_cdev.c:13:
   In function 'check_copy_size',
       inlined from 'copy_from_user' at include/linux/uaccess.h:191:6,
       inlined from 'rio_mport_transfer_ioctl' at drivers/rapidio/devices/rio_mport_cdev.c:983:6:
   include/linux/thread_info.h:213:4: error: call to '__bad_copy_to' declared with attribute error: copy destination size is too small
     213 |    __bad_copy_to();
         |    ^~~~~~~~~~~~~~~

But the allocation size and the copy size are identical:

	transfer = vmalloc(array_size(sizeof(*transfer), transaction.count));
	if (!transfer)
		return -ENOMEM;

	if (unlikely(copy_from_user(transfer,
				    (void __user *)(uintptr_t)transaction.block,
				    array_size(sizeof(*transfer), transaction.count)))) {

Link: https://lkml.kernel.org/r/20210930222704.2631604-1-keescook@chromium.org
Link: https://lkml.kernel.org/r/20210930222704.2631604-2-keescook@chromium.org
Link: https://lore.kernel.org/linux-mm/202109091134.FHnRmRxu-lkp@intel.com/
Signed-off-by: Kees Cook 
Reviewed-by: John Hubbard 
Reported-by: kernel test robot 
Cc: Matt Porter 
Cc: Alexandre Bounine 
Cc: Jing Xiangfeng 
Cc: Ira Weiny 
Cc: Souptick Joarder 
Cc: Gustavo A. R. Silva 
Cc: Andy Whitcroft 
Cc: Christoph Lameter 
Cc: Daniel Micay 
Cc: David Rientjes 
Cc: Dennis Zhou 
Cc: Dwaipayan Ray 
Cc: Joe Perches 
Cc: Joonsoo Kim 
Cc: Lukas Bulwahn 
Cc: Miguel Ojeda 
Cc: Nathan Chancellor 
Cc: Nick Desaulniers 
Cc: Pekka Enberg 
Cc: Randy Dunlap 
Cc: Tejun Heo 
Cc: Vlastimil Babka 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds