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: <20101110221412.GB7063@angua.secretlab.ca>
Date:	Wed, 10 Nov 2010 15:14:12 -0700
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Maciej Szmigiero <mhej@...pl>
Cc:	Thomas Gleixner <tglx@...utronix.de>, 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

On Wed, Nov 10, 2010 at 10:01:40PM +0100, Maciej Szmigiero wrote:
> 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.

BTW, switching to using a kobject != rewriting the whole GPIO code.
kobjects are not all that scary and the biggest impact is adding
kobject get/put operation on the gpio get/release apis.  I don't
expect it to end up being overly complex.

The Documentation/kobject.txt file should offer some insight.

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