On Sat, Oct 28, 2000 at 11:50:22AM -0400, Brian Gerst wrote:
> Philipp Rumpf wrote:
> >
> > On Sat, Oct 28, 2000 at 09:55:21AM -0400, Brian Gerst wrote:
> > > Yes, but they can be called (and sleep) with module refcount == 0. This
> > > is because the file descripter used to perform the ioctl is
Brian Gerst wrote:
>
> With or without your patch, the network ioctls are unsafe, since they
> don't currently do refcounting at all. Adding it in the layer above the
> driver is the easier and cleaner solution.
As long as the drivers use unregister_netdevice() then that's
fairly easy to fix wi
Philipp Rumpf wrote:
>
> On Sat, Oct 28, 2000 at 09:55:21AM -0400, Brian Gerst wrote:
> > Yes, but they can be called (and sleep) with module refcount == 0. This
> > is because the file descripter used to perform the ioctl isn't directly
> > associated with the network device, thereby not increm
On Sat, Oct 28, 2000 at 09:55:21AM -0400, Brian Gerst wrote:
> Yes, but they can be called (and sleep) with module refcount == 0. This
> is because the file descripter used to perform the ioctl isn't directly
> associated with the network device, thereby not incrementing the
> refcount on open.
Philipp Rumpf wrote:
>
> On Sat, Oct 28, 2000 at 09:37:28AM -0400, Brian Gerst wrote:
> > Philipp Rumpf wrote:
> > > - you can't copy_(from|to)_user in the module exit function (which would
> > > be copies from/to rmmod anyway)
> >
> > Unfortunately, you need to be able to use copy_*_user() from
On Sat, Oct 28, 2000 at 09:37:28AM -0400, Brian Gerst wrote:
> Philipp Rumpf wrote:
> > - you can't copy_(from|to)_user in the module exit function (which would
> > be copies from/to rmmod anyway)
>
> Unfortunately, you need to be able to use copy_*_user() from the network
> ioctls, and this is
Philipp Rumpf wrote:
>
> On Fri, Oct 27, 2000 at 10:49:53PM +1100, Andrew Morton wrote:
> > Look, this modules stuff is really bad. Phillip Rumpf proposed
> > a radical alternative a while back which I felt was not given
>
> While it might be a "radical alternative", it doesn't require any chan
On Fri, Oct 27, 2000 at 10:49:53PM +1100, Andrew Morton wrote:
> Look, this modules stuff is really bad. Phillip Rumpf proposed
> a radical alternative a while back which I felt was not given
While it might be a "radical alternative", it doesn't require any changes
to the subsystems that have be
Brian Gerst wrote:
> > > + struct module *owner;
> > > + struct module *owner;
> > > bix:/home/morton>
> >
> > We use it throught the fops_get/fops_put macros to in/decrease the mod
> > counter. See the definitions for those macros (include/linux/fs.h)
> >
> > Patrick
>
> Th
Patrick van de Lageweg wrote:
>
> On Fri, 27 Oct 2000, Andrew Morton wrote:
>
> > Patrick van de Lageweg wrote:
> > >
> > > Hi all,
> > >
> > > Here is the second try for the atm refcount problem. I've made made
> > > several enhancement over the previos patch. Can you take a look at it if
> > >
On Fri, 27 Oct 2000, Andrew Morton wrote:
> Patrick van de Lageweg wrote:
> >
> > Hi all,
> >
> > Here is the second try for the atm refcount problem. I've made made
> > several enhancement over the previos patch. Can you take a look at it if
> > I've missed anything? (This time it also include
Andrew Morton wrote:
>
> Patrick van de Lageweg wrote:
> >
> > Hi all,
> >
> > Here is the second try for the atm refcount problem. I've made made
> > several enhancement over the previos patch. Can you take a look at it if
> > I've missed anything? (This time it also includes the driver for the
Patrick van de Lageweg wrote:
>
> Hi all,
>
> Here is the second try for the atm refcount problem. I've made made
> several enhancement over the previos patch. Can you take a look at it if
> I've missed anything? (This time it also includes the driver for the
> firestream card. That's why the pa
Hi all,
Here is the second try for the atm refcount problem. I've made made
several enhancement over the previos patch. Can you take a look at it if
I've missed anything? (This time it also includes the driver for the
firestream card. That's why the patch is so large. It's gziped and
uuencoded).
Hi,
1 - couldn't there be a problem through :
atm_release/svc_release -> atm_release_vcc_sk (...vcc->dev->ops->close) ->
sigd_close -> *atm_devs walk*
2 -
> --- linux-2.4.0-test10-pre4.clean/net/atm/common.cWed Jul 12 12:26:08 2000
> +++ linux-2.4.0-test10-pre4.fs50/net/atm/common.c
Hi All,
Could you take a look at this patch for the atm reference counting and
locking problems? I think this will fix these problems. But I could
have missed someting. Please ignore the "firestream" parts. They are
for an other driver (which will come later).
Patrick
diff -u -r li
16 matches
Mail list logo