linux-kernel - Re: Regression in module wmi since 2.6.32 (bisected to commit 1caab3c)

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: <4B362C95.4040700@lwfinger.net>
Date:	Sat, 26 Dec 2009 09:32:37 -0600
From:	Larry Finger <Larry.Finger@...inger.net>
To:	Carlos Corbacho <carlos@...angeworlds.co.uk>
CC:	Matthew Garrett <mjg@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux ACPI <linux-acpi@...r.kernel.org>
Subject: Re: Regression in module wmi since 2.6.32 (bisected to commit 1caab3c)

On 12/25/2009 07:18 PM, Carlos Corbacho wrote:
> On Friday 25 December 2009 22:09:28 Larry Finger wrote:
>> On 12/25/2009 03:58 PM, Carlos Corbacho wrote:
>>> On Friday 25 December 2009 21:35:49 Larry Finger wrote:
>>>> Should I attach the files DSDT.dat, acpidump.out, or DSDT?
>>>
>>> DSDT from /proc/acpi/dsdt will do fine for my purposes.
>>
>> Attached.
> 
> This is the same as bugzilla #14846 - in both cases, the GUID 05901221-D566-11D1-B2F0-00A0C9062910 (a data block query) is duplicated in two different devices, although both look like they are nVidia related hooks.
> 
> Since we don't currently have any in kernel drivers that use that stuff, and the query in question just returns a binary MOF, the simplest solution (for now) seems to be to just ignore these duplicates - if and when someone wants to support these hooks, they can clean the mess up properly when they figure out how WMI is supposed to cope with conflicting GUID's. 
> 
> Matthew, you looked at NVIF for your sins, can you see a better solution? We could just blacklist the offending GUID, rather than trying to catch all duplicates? Although just ignoring all duplicates strikes me as a better solution to catch the next time that J Random BIOS Developer decides to duplicate GUIDs in WMI.
> 
> Initial patch below which takes the "ignore all duplicate GUIDs" approach.

The patch fixes my machine.

Thanks,

Larry

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