Re: [PATCH v4] uio: fix unregister_device
From: gregkh@xxxxxxxxxxxxxxxxxxx
Date: Fri Apr 03 2026 - 05:58:35 EST
On Thu, Apr 02, 2026 at 04:19:09PM +0000, Igor Klochko (Nokia) wrote:
> uio: mirrored uio_register/unregister_device
>
> When uio devices are created end removed in parallel, then we sometimes
> encounter kernel traces along the following lines:
>
> sysfs: cannot create duplicate filename '/class/uio/uio899'
>
> which stem from:
>
> sysfs_create_link+0x24/0x50
> device_add+0x2f0/0x780
> __uio_register_device+0x18c/0x550
>
> The sysfs directory creation is performed synchronously as part of the
> device_add call. The high level sequence for uio registration is:
>
> 1. uio_get_minor (idr call, in critical section)
> 2. device_add (leads to sysfs directory)
> 3. manage attributes (popuplates part of the sysfs directory)
>
> For unregistration we have by default the following flow:
>
> 1. clean-up attributes
> 2. uio_free_minor (idr call, in critical section)
> 3. device_unregister (cleans up sysfs directory)
>
> This creates a racing problem when we are in parallel creating and
> removing uio devices.
> The uio-minor that is freed when calling uio_free_minor can be
> claimed by a subsequent uio_get_minor call.
> The problem is that the device_add flow can end up triggered,
> leading to a sysfs directory creation; while the
> device_unregister flow has not yet cleaned up the sysfs directory.
>
> This patch cleans up this problem by mirroring the registration and
> Unregistration flow correctly.
> After this patch, the unregistration flow becomes:
>
> 1. clean-up attributes
> 2. device_unregister
> 3. uio_free_minor
>
> Fixes: 0c9ae0b86050 ("uio: Fix use-after-free in uio_open")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Philippe Belet <philippe.belet@xxxxxxxxx>
> Reviewed-by: Igor Klochko <igor.klochko@xxxxxxxxx>
You sent this patch, so you too must sign off on it.
> ---
> v4:
> - reformat the patch
> v3:
> - Updated email subject
> v2:
> - Fixed commit message wrapping
> - Placed 12 char sha1 in "fixes"
> - cc'd stable
> v1:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> .kernel.org%2Flkml%2FAM9PR07MB720434A2B0CC99BC0BDCD74E8D61A%40AM9PR07M
> B7204.eurprd07.prod.outlook.com%2F%23&data=05%7C02%7Cigor.klochko%40no
> kia.com%7C065fe0dc34a742a815d208de90bee494%7C5d4717519675428d917b70f44
> f9630b0%7C0%7C0%7C639107346738079714%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e
> U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld
> UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2h7wcsPPy0iiFG0jCYCTgl3iRzan%2FSIP2F5
> xDJrzHc4%3D&reserved=0
Not really a valid url :(
thanks,
greg k-h