linux-kernel - Re: [PATCH v3] char: xillybus: Fix error handling in xillybus_init

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <fae36efb-be09-8b60-ff84-db6cb38fc18e@outbound.gmail.com>
Date: Sat, 19 Jul 2025 14:26:14 +0200
From: Eli Billauer <eli.billauer@...il.com>
To: Ma Ke <make24@...as.ac.cn>, arnd@...db.de, gregkh@...uxfoundation.org
Cc: akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
 stable@...r.kernel.org
Subject: Re: [PATCH v3] char: xillybus: Fix error handling in
 xillybus_init_chrdev()

On 18/07/2025 12:08, Ma Ke wrote:
> Use cdev_del() instead of direct kobject_put() when cdev_add() fails.
> This aligns with standard kernel practice and maintains consistency
> within the driver's own error paths.
> 

Could you please point at how and why this is "standard kernel 
practice"? In my reply to PATCH v2, I pointed out that indeed, in 
fs/fuse/cuse.c a failure of cdev_add() leads to a call to cdev_del(), 
like you suggested. However, in uio/uio.c the same scenario is handled 
by a call to kobject_put(), exactly as in my driver. So which way is 
"standard"?

There are indeed kernel-global efforts to align code with a certain 
coding style every now and then. Is there any such in relation to this 
issue?

Otherwise, please leave this alone. Playing around with error handling 
flows is a dangerous business, and can lead to vulnerabilities. One 
needs a good reason to do that on code that has been out there for a 
while (four years, in this case).

And now, to the patch itself:

> @@ -157,8 +156,6 @@ int xillybus_init_chrdev(struct device *dev,
>   		device_destroy(&xillybus_class, MKDEV(unit->major,
>   						     i + unit->lowest_minor));
>   
> -	cdev_del(unit->cdev);
> -
>   unregister_chrdev:
>   	unregister_chrdev_region(MKDEV(unit->major, unit->lowest_minor),
>   				 unit->num_nodes);

Why did you do this? It just adds a memory leak, and it's out of the way 
of even trying to fix anything: The only effect this has is that 
cdev_del() isn't called on error situations that occur after cdev_add() 
has been successful. It has nothing to do with the kobject_put() / 
cdev_add() thing, because that case jumps to unregister_chrdev, which is 
after this removal.

I have to say, both the language of the patch description as well as the 
weird removal of cdev_del() remind me of nonsense ChatGPT does when it's 
given tasks related to programming. If you're using AI to suggest 
patches, please stop.

Regards,
    Eli