linux-kernel - Re: [PATCH 0/6] Make return type of i2c_del_adapter() (and i2c_del_mux

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130331095623.146f65db@endymion.delvare>
Date:	Sun, 31 Mar 2013 09:56:23 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	Lars-Peter Clausen <lars@...afoo.de>
Cc:	Wolfram Sang <wsa@...-dreams.de>, Ben Dooks <ben-linux@...ff.org>,
	linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/6]  Make return type of i2c_del_adapter() (and
 i2c_del_mux_adapter())  void

On Sat, 30 Mar 2013 21:43:29 +0100, Lars-Peter Clausen wrote:
> On 03/30/2013 09:13 PM, Jean Delvare wrote:
> > I see:
> > 
> > struct device_driver {
> > 	(...)
> > 	int (*probe) (struct device *dev);
> > 	int (*remove) (struct device *dev);
> >
> > So the driver core does allow remove functions to return an error.
> 
> Well, the return type is int, but the return value is never checked. So you
> can return an error value, but the device driver core is going to care and
> the device is still removed. So any code which does return an error in it's
> probe function in the assumption that this means the device will still be
> present is broken and leaves the system in an undefined state. So if that
> happens the kernel will probably crash sooner or later, or if you are lucky
> you only created a few resources leaks.
> 
> And no we can't change the core to handle errors from a drivers remove
> callback. It's a basic inherent property of the Linux device driver model
> that any device can be removed at any time.
> 
> > Are you going to fix all subsystems as you are doing for i2c now, and then
> > change device_driver.remove to return void? If not, I don't see the
> > point of changing it in i2c.
> 
> As I said it's a bug if a driver returns an error in its remove function.
> And the fact that the return type of the remove callback is int is pretty
> much misleading in this regard, so the long term goal is to make the return
> type void. But that's a long way to go until we get there, fixing the return
> type of i2c_del_adapter() is kind of the low hanging fruit.

OK, makes sense, thanks for the clarification.

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/