unload device driver

From: "Peter T. Breuer" <ptb@oboe.it.uc3m.es>
Subject: Re: device or resource busy
Date: Tue, 4 Feb 2003 15:13:45 +0100
References: <3E3F4612.4010705@dontemailme.com>
<j5a4h-982.ln1@samiam.org>
<7r5o1b.kr9.ln@news.it.uc3m.es>
<SvO%9.161283$VU6.121632@rwcrnsc52.ops.asp.att.net> 

Tony Lawrence <tony@pcunix.com> wrote:
> Peter T. Breuer wrote:
>> Having not completed init, the kernel has done well to isolate
>> the unit. Locks are preventing it being removed since it has not
>> finished inserting. This is the best that can be done since in any case
>> the situation requires a reboot (the kernel has oopsed!) and any
>> more intelligent response would require detailed controls that would
>> give rise to more race conditions in general.

> I don't totally understand this.  Is the concern that the driver may 
> have trampled other kernel structures?  If so, that would seem to 

Anything at all may have happened.  Module init has not completed, so we
know that the ordinary flow of execution was not followed.  Normally
when you start a subroutine you exit from it some time later!

> indicate that you shouldn't be continuing at all.

Indeed, you should not. However, you get the opportunity right now to
gather data about the oops. Save it and play it through ksymoops.

> If it has been isolated, then why can't it be removed?  I assume 

Becuase it hasn't finished its init. It's a transaction. You can't
remove a module /while/ it's inserting. And it's still inserting!
By saying that it was isolated I meant that it's only this modules lock
that is affected. All other modules are OK.

> isolated means that nothing is going to be allowed to reference any of 
> its routines, that the entry points for the device just don't point 
> there, that no part of it is in the scheduler?

Exactly. None of this is predictable. The init routine can do anything
and will normally register functions elsewhere in the kernel. They may
be associated with its major and they may not.

> Understand that I'm not arguing the point: I'm far, far from enough 
> expertise in this are to even begin to do that.  I'm just curious if the 
> reasoning behind this can be explained in a way we mere mortals can 

It looks obvious to me. You can't remove until inserted. Insertion has
not completed. End of story. ANything more subtle would require
knowledge of the module innards, and the kernel doesn;t have that.

> comprehend.

>  > THere is a movement towards not allowing removal of any driver, once
>  > inserted.

> So I have read, but again I do not totally understand that.  Again, 
> speaking from my incomplete understanding: if you can close off the 
> entry points and remove any scheduled handlers, why wouldn't you then be 
> able to drop it? Yes, processes may be waiting on it, but isn't that a 

Because you can't control what the module has done.  It may have planted
a timebomb elsewhere, say a task that in 10s will start to send requests
to a function of its own whose code no longer exists, since you removed
it ...

> separate problem?

> It just seems to me that this is a design decision at some basic level. 

It is. Linus decided that there was no need to put excessive
complication in here since you can always just whip the admin
responsible for breakage until he stops doing it. And all attempts
to add complication simply expose more complicated rce conditions,
in my opinion, at least.

What is going on right now in 2.5 however makes me shudder ...

>    Obviously (?) you *could* design to remove or replace recacitrant 

No, you couldn't, not safely.

> kernel code, but maybe the required effort is just too high?  Again, 

Yes. It requires coding discipline that is too much to ask of authors.

> just asking :-)

Essentially, removing a module is a race. You try and remove it before
anyone new can use it!

Peter
 

Comments?

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.