linux-kernel - Re: FW: 2.6.24 breaks BIOS updates on all Dell machines

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]

Date:	Tue, 29 Jan 2008 23:15:22 +0100
From:	"Jean Delvare" <khali@...ux-fr.org>
To:	greg@...ah.com, markus.rechberger@....com
CC:	"Matt_Domsch@...l.com" <Matt_Domsch@...l.com>,
	"Jos?? Luis Tall??n" <jltallon@...-solutions.net>,
	"Douglas_Warzecha@...l.com" <Douglas_Warzecha@...l.com>,
	"Abhay_Salunke@...l.com" <Abhay_Salunke@...l.com>,
	linux-kernel@...r.kernel.org,
	"Michael E Brown" <Michael_E_Brown@...l.com>,
	"Greg KH" <gregkh@...e.de>
Subject: Re: FW: 2.6.24 breaks BIOS updates on all Dell machines

Hi Greg,

Le 29/1/2008, "Greg KH" <greg@...ah.com> a écrit:

>On Tue, Jan 29, 2008 at 03:59:44PM +0100, Markus Rechberger wrote:
>>> -----Original Message-----
>>> (...)
>>> On Tue, Jan 29, 2008 at 12:32:44AM -0600, Michael E Brown wrote:
>>>
>>>> BIOS updates are broken on all Dell systems due to Commit
>>>> 109f0e93b6b728f03c1eb4af02bc25d71b646c59, which is now in 2.6.24.
>>>>
>>>>   static inline void fw_setup_device_id(struct device *f_dev, struct
>>>> device *dev)
>>>>   {
>>>> -       /* XXX warning we should watch out for name collisions */
>>>> -       strlcpy(f_dev->bus_id, dev->bus_id, BUS_ID_SIZE);
>>>> +       snprintf(f_dev->bus_id, BUS_ID_SIZE, "firmware-%s",
>>>> dev->bus_id);
>>>>  }
>>>>
>> reverting this breaks support for several media (DVB/V4L) devices. I would
>> have to look up some bugreports the same name collision happened with
>> several different drivers.
>> There was a comment in the fw code to watch out for name collisions earlier
>> already, so it needs a fix somewhere.
>>
>> Here's some history:
>> http://mcentral.de/wiki/index.php5/Bugtracker#i2c_dev_problem
>
>Yes, but we can't break existing code that has been working for quite
>some time.  That's just unacceptable.  The i2c devices can fix things by
>changing their module names so this collision doesn't happen :)

Actually, the i2c-dev driver was there before the firmware class, so if
anything, the firmware class broke something that was working before. It
just happens that nobody really needs to poke at the i2c-dev sysfs
directories, while user-space tools need to access firmware sysfs
directories. And most people do not need i2c-dev at all.

Also note that the way firmware directories were originally named (by the
name of the device itself!) wasn't exactly smart and was calling for
confusion if not trouble IMHO.

>So, I'm all for reverting this patch.
>
>And then, feel free to revisit the problem by proposing something that
>doesn't break existing users of the interface.

I'm a bit confused. It seems to me that the "class devices" are named
differently in recent kernels. The i2c-dev class devices were originally
showing as i2c-%d in their parent device directories (causing the
collision), and now show as i2c-dev:i2c-%d. This suggests that the
collision the patch above was trying to solve is in fact already fixed
(by prefixing the device name with the class name). The good news is
that it would mean that we can just revert the patch in question...

But quite frankly I'm not really sure, the class devices look different
on every kernel I looked at, depending on the version and whether
CONFIG_SYSFS_DEPRECATED is set or not.

--
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/