linux-kernel - Re: [GPIO]implement sleeping GPIO chip removal

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: <4CDB0834.4080101@o2.pl>
Date:	Wed, 10 Nov 2010 22:01:40 +0100
From:	Maciej Szmigiero <mhej@...pl>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	Grant Likely <grant.likely@...retlab.ca>,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	Anton Vorontsov <avorontsov@...mvista.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Uwe Kleine-K?nig <u.kleine-koenig@...gutronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	Jonathan Cameron <jic23@....ac.uk>,
	Ben Nizette <bn@...sdigital.com>
Subject: Re: [GPIO]implement sleeping GPIO chip removal

W dniu 10.11.2010 21:42, Thomas Gleixner pisze:
> On Wed, 10 Nov 2010, Maciej Szmigiero wrote:
>> W dniu 10.11.2010 10:49, Thomas Gleixner pisze:
>>> Maybe because it open codes a sloppy refcounting with a loop and magic
>>> sleeps instead of converting the code to kobjects and proper
>>> refcounting ?
>>>
>>
>> The only way to do GPIO chip removal in the current code is to busy-loop.
>> "Sloppy" (as you called it) waiting is still more CPU-friendly than looping 
>> in hope that somebody will finally release the chip.
>> If you would like to implement it as kobject then go ahead and post the code
>> so it can be used in drivers.
> 
> Wait a moment. You are getting something backwards here.
> 
> Fact is that the current code is not designed for easy hotunplugging
> and therefor requires looping.
> 
> So _you_ propose a work-around to replace the busy-loop by a sleeping
> loop with "hope that ....". Hope is the least thing what counts in
> programming.
> 
> Now a reviewer tells you that your idea of replacing the busy-loop by
> a sleeping in hope loop is flawed, because it does not solve the
> underlying design problem of the GPIO code. And you get a suggestion
> how to solve it correctly.
> 
> Now you go and request from that reviewer to implement that? That's
> not how it works.
> 
> You sent a flawed patch in the first place and people try to tell you
> how to do it right. Then it's on you to either go and do it right or
> at least ask politely for help and pointers.
> 
> Thanks,
> 
> 	tglx
> 

You misunderstood me.
By "looping in hope that somebody will finally release the chip" I meant the only
real way to handle a GPIO chip unplugging in the current kernel.
Which is way worse that preventing new requests, then waiting for existing one to be released.
And this is exactly what my patch does.

I understand that it could be simplified by removing redundant code (as Grant Likely had suggested before), and
moving it to completion interface instead of manipulating a task structure directly, but this doesn't mean
that the whole GPIO code has to be rewritten just to add one functionality.

Best regards,
Maciej Szmigiero







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