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: <96cbaba0-29bb-7282-3e30-b4ebdd859b99@intel.com>
Date:	Mon, 30 May 2016 15:49:58 +0300
From:	Crestez Dan Leonard <leonard.crestez@...el.com>
To:	Jonathan Cameron <jic23@...nel.org>, linux-iio@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org, Hartmut Knaack <knaack.h@....de>,
	Lars-Peter Clausen <lars@...afoo.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/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.

-- 
Regards,
Leonard