Re: owner field in `struct fs'

From: Philipp Rumpf (prumpf@uzix.org)
Date: Mon Jun 26 2000 - 11:04:41 EST


On Mon, Jun 26, 2000 at 11:46:22AM -0400, Alexander Viro wrote:
>
>
> On Mon, 26 Jun 2000, Philipp Rumpf wrote:
>
> > On Mon, Jun 26, 2000 at 11:15:44AM +0100, David Woodhouse wrote:
> > > prumpf@uzix.org said:
> > > > Yes. schedule() out of a zero-refcount module is a bug. In fact,
> > > > it's quite easy to make it a BUG() as well:
> > >
> > > That's nice but not sufficient - just _being_ in a zero-refcount module is a
> > > bug, if you don't have the BKL or the unload_lock.
> >
> > Most of this thread is/was about how you can make it perfectly legal (if
> > you synchronize things across all CPUs for module unload). Right now I
> > agree it's always a bug but I don't think anyone disagrees the current
> > (pre-inc/dec use count in upper layer) mechanisms are broken.
>
> Erm? try_inc_mod_count()/__MOD_DEC_USE_COUNT() in upper layer looks OK
> with me. Care to give the reasons why that is broken?

Sorry, what I meant was no one disagrees the old way of doing things (i.e.
MOD_INC_USE_COUNT in open(), MOD_DEC_USE_COUNT in release() without any
further protection) was broken. Your way works fine and doesn't even
conflict with the grab all CPUs patch.

        Philipp Rumpf

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



This archive was generated by hypermail 2b29 : Mon Jun 26 2000 - 21:00:09 EST