linux-kernel - Re: [RFC 6/7] iio: Refuse to register triggers with duplicate names

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: <574D99B0.6000105@metafoo.de>
Date:	Tue, 31 May 2016 16:03:28 +0200
From:	Lars-Peter Clausen <lars@...afoo.de>
To:	Crestez Dan Leonard <leonard.crestez@...el.com>,
	Jonathan Cameron <jic23@...nel.org>, linux-iio@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org, Hartmut Knaack <knaack.h@....de>,
	Peter Meerwald-Stadler <pmeerw@...erw.net>,
	Daniel Baluta <daniel.baluta@...el.com>
Subject: Re: [RFC 6/7] iio: Refuse to register triggers with duplicate names

On 05/30/2016 02:49 PM, Crestez Dan Leonard wrote:
> On 05/29/2016 10:48 PM, Jonathan Cameron wrote:
>> On 23/05/16 19:40, Crestez Dan Leonard wrote:
>>> The trigger name is documented as unique but drivers are currently
>>> allowed to register triggers with duplicate names. This should be
>>> considered a bug since it makes the 'current_trigger' interface
>>> unusable.
>>>
>>> Signed-off-by: Crestez Dan Leonard <leonard.crestez@...el.com>
>> This feels like the right approach to my mind (and should have been there
>> all along - oops).
>>
>> However, we do need to avoid breaking userspace. It's ugly but for those 3 drivers
>> can we assume that using more than one on a board was impossible before this series
>> and as such play a slight game in which we don't change the trigger name they
>> are exporting, unless that name is already in use?
>>
>> It's ugly but it gets us the nicest solution for all drivers for a bit of ugly in
>> 3 of them...
> 
> How would that look like? I guess I could handle -EEXIST from
> iio_trigger_register and try again with another name? Unfortunately the
> name is initialized at alloc time while uniqueness can only be checked
> at register time. This would require some refactoring in drivers for
> devices I don't have.
> 
> An alternative would be to just submit patches 4/5 and only give a
> warning when non-unique trigger names are used. After all, iio device
> names are not unique, the easy way would be to give up on this guarantee
> for trigger names as well.
> 

I'd say apply this patch keep things as they are in the drivers and if
somebody creates a board with more than one of those devices let them come
up with a fix.