Linux-kernel mailing list archive 2000-26,: Re: owner field in `struct fs'

# Re: owner field in `struct fs'

Philipp Rumpf (prumpf@uzix.org)
Sun, 25 Jun 2000 08:48:45 -0700

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Simon Kirby: "Re: the ridiculously large granularity of "errno" (was Red Hat problem on a cobalt server)"
- Previous message: Linda Walsh: "RE: IMMUTABLE and APPEND-ONLY rationales"

On Sun, Jun 25, 2000 at 10:32:48PM +1000, Andrew Morton wrote:
> Alexander Viro wrote:
> >
> > On Sun, 25 Jun 2000, Andrew Morton wrote:
> >
> > > > I'm less than happy about ->do_ioctl(), though - are you sure that it can
> > > > happen with refcount==0? AFAICS it does not touch the reference counter
> > > > and it means that we need to be extra cautious inside...
> > >
> > > Yes, these methods are called with refcount == 0. For example, the
> > > 'mii-diag' tool may be used to manipulate the device's MII when the
> > > interface is downed (via netdevice.do_ioctl())
> >
> > And what happens if it blocks?
>
> Bad things, potentially. It would be most extraordinary if these little
> methods _were_ to block, but there's nothing which says they
> can't/don't.

With the grab-all-CPUs patch, there are three kinds of module functions:

open functions, which return some structure used in external code; open
functions need to MOD_INC_USE_COUNT early (before going to sleep).

close functions, which do some cleanup for external code; close functions
need to MOD_DEC_USE_COUNT late (after they last slept).

net-ioctl-like functions, basically anything that isn't open or close; those
functions only need to MOD_{INC,DEC}_USE_COUNT if they sleep.

> > Let me get it straight: currently
> > d) modules are loaded by dev_load() and nothing prevents them from
> > immediate removal.
> > e) normally, module can be unloaded if the interface is down. It
> > may destroy settings made by ->do_ioctl().

these are just broken regardless of how module unload works. You need to
have some way of giving userspace the guarantee the changes it made to
eth0 a second ago are still in effect. For now, disallowing (I believe this
was your example, Andrew)

ifconfig eth0 down
ifconfig eth0 mtu 1000

seems like the cleanest way to do it

> > increment/decrement upon up/down. Then we could be sure that whenever we
> > pick the structure by name it will stay around until we explicitly say
> > that we don't care and we would know that pointers to such structure

Ah. so you want ifconfig eth0 unregister ? Userspace needs to know when
we're going to reuse device names.

> It'll work. What's your take on the 'grab all the other CPUs' idea?
> That pushes all the module uglies into one place.

It doesn't solve the net device problem.

Philipp

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Simon Kirby: "Re: the ridiculously large granularity of "errno" (was Red Hat problem on a cobalt server)"
- Previous message: Linda Walsh: "RE: IMMUTABLE and APPEND-ONLY rationales"