linux-kernel - Re: [PATCH 1/2] prevent gpio chip drivers from unloading while used

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: <200802081714.18795.david-b@pacbell.net>
Date:	Fri, 8 Feb 2008 17:14:18 -0800
From:	David Brownell <david-b@...bell.net>
To:	Guennadi Liakhovetski <g.liakhovetski@...gutronix.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] prevent gpio chip drivers from unloading while used

> > > As long as one or more GPIOs on a gpio chip are used its driver should not 
> > > be unloaded.
> > 
> > The mechanism currently in place is to have gpiochip_remove() fail
> > if the platform's teardown() logic doesn't reject it.  (It may be
> > practical to have the teardown code get rid of the users...)  That
> > would be reflected as an "rmmod" failure.
> > 
> > Are you saying that doesn't work?
> 
> Yes, that's what I'm saying. I had a GPIO in use and rmmod-ed pca953x. It 
> did produce an error message
> 
> pca953x 0-0041: gpiochip_remove() failed, -16
> 
> , but rmmod completed.

Doesn't that seem buglike to you?

Oh, right -- the module exit code will ignore that status, it doesn't
even have a way to report failures any more.  Crap.

So it looks like we have no choice but to do this.  Can you make sure
all the rmmod-capable gpio_chip drivers support this?  Ignore the SOC
support, that never supports rmmod -- just the stuff in drivers/gpio.


> AFAIU, the only 2 ways currently to prevent rmmod  
> from completing, are: increment module use-count, then the respective 
> module_exit() function is not called at all and rmmod fails with -EBUSY. 
> Or block in rmmod until the resource becomes free. None of these has 
> happened. BTW, I think, there's the same problem with i2c adapter drivers.

Right.  In fact, every time you'd expect driver removal errors to
cause module removal to fail.   Maybe this is part of that whole
"should we even *support* rmmod" discussion, which I tuned out.

- Dave


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