linux-kernel - Re: [PATCH] 2.6.24-rc1: ensure "present" sysfs attribute even if battery is absent

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:	Sat, 27 Oct 2007 22:18:14 +0400
From:	Alexey Starikovskiy <aystarik@...il.com>
To:	Andrey Borzenkov <arvidjaar@...l.ru>
CC:	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
	cbou@...l.ru, dwmw2@...radead.org
Subject: Re: [PATCH] 2.6.24-rc1: ensure "present" sysfs attribute even if
 battery is absent

Andrey Borzenkov wrote:
> On Saturday 27 October 2007, Alexey Starikovskiy wrote:
>> Andrey Borzenkov wrote:
>>> I am not exactly sure about this one ... what other power_supply class
>>> drivers do? Should I fix HAL instead (but then, I do not know whether HAL
>>> is the only application that is using this interface).
>> Hm, do you need separate set of properties for that? You could register
>> either of existing two, and read function will not allow read of anything
>> but "present". IMHO, this is what other modules do (/drivers/power)
> 
> Do they have different set of properties depending on underlying hardware that 
> you can't query unless hardware is present? I'd rather avoid adding fake 
> attributes; but I do not actually care so which one do you prefer? :)
I prefer less code :) 
> 
>> One remaining trick here, you need to call unregister/register for
>> power_supply if you change attributes -- so please check if your patched
>> driver survives insertion of the battery.
>>
> 
> 
> Neither does your code (nor kpowersave :) ) Remove battery and set of 
> attributes is "stuck" instead of being reset to only fixed set of power 
> device attributes (basically "info"). The only call to power_supply_register 
> is in acpi_battery_add and as far as I can tell this is executed on adding 
> *slot* not when content of this slot changes.
Point is -- it does not break :) If you start to play with shorter length of 
attributes table and don't call unregister/register, power_supply may 
go past the end of table.





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