Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*modular\s+net\s+drivers\s*$/: 64 ]

Total 64 documents matching your query.

1. modular net drivers (score: 1)
Author: xxxx>
Date: Mon, 19 Jun 2000 23:54:30 +1000
As you may have noticed, Al Viro is running around the kernel getting rid of MOD_INC_USE_COUNT and MOD_DEC_USE_COUNT. His long-term plan is to remove MOD_INC_USE_COUNT and MOD_DEC_USE_COUNT completel
/archives/netdev/2000-06/msg00210.html (11,249 bytes)

2. Re: modular net drivers (score: 1)
Author: xxxx>
Date: Tue, 20 Jun 2000 01:20:41 +1000
Racy. The module referred to by dev->owner might be in the middle of being unloaded. You need try_inc_mod_count() with a check on its result instead of __MOD_INC_USE_COUNT.
/archives/netdev/2000-06/msg00211.html (8,768 bytes)

3. Re: modular net drivers (score: 1)
Author: xxxx>
Date: Mon, 19 Jun 2000 17:20:04 MET-1
You should change it to if (dev->owner) __MOD_INC_USE_COUNT(dev->owner); if (dev->open) ret = dev->open(dev); if (ret != 0 && dev->owner) __MOD_DEC_USE_COUNT(dev->owner); ... as 'ret' is preinitializ
/archives/netdev/2000-06/msg00212.html (10,099 bytes)

4. Re: modular net drivers (score: 1)
Author: xxxx>
Date: Tue, 20 Jun 2000 02:06:47 +1000
eww. That would mean the existing code is racy. I assumed it took care of this elsewhere. Maybe not. try_inc_mod_count looks good. <slaps head>
/archives/netdev/2000-06/msg00213.html (8,856 bytes)

5. Re: modular net drivers (score: 1)
Author: xxxx>
Date: Mon, 19 Jun 2000 20:19:06 -0400 (EDT)
Hmmm, this is curious. Should not the "feature freeze" phase come well after the "interface freeze"? This is pretty obviously an interface change. "Twisty logic"? Most of the drivers have straight-fo
/archives/netdev/2000-06/msg00214.html (9,257 bytes)

6. Re: modular net drivers (score: 1)
Author: xxxx>
Date: Tue, 20 Jun 2000 10:29:59 +1000
It is also an important bug fix. The module code has suffered from unload races ever since the kernel locking became fine grained, users can crash the kernel. There are inherent unload races when cod
/archives/netdev/2000-06/msg00215.html (10,011 bytes)

7. Re: modular net drivers (score: 1)
Author: xxxx>
Date: Tue, 20 Jun 2000 00:58:16 +0000
Hello, Donald. Yes, I find it amusing that when something stable is imminent, people start madly running around cleaning up stuff that should have been done months/years ago. Oh well. Better than not
/archives/netdev/2000-06/msg00216.html (11,155 bytes)

8. Re: modular net drivers (score: 1)
Author: xxxx>
Date: Tue, 20 Jun 2000 12:41:46 +0200
At least for open/close() that is not true -- rtnl_lock() protects against that. For that there are the same rules as in 2.2 (INC before first sleep, DEC after last sleep) -Andi -- This is like TV. I
/archives/netdev/2000-06/msg00217.html (10,014 bytes)

9. Re: modular net drivers (score: 1)
Author: xxxx>
Date: Tue, 20 Jun 2000 17:01:56 +1000
Races which can be largely solved at the moment by having the module page removal code sync all bh's and softirqs after calling cleanup(). Hell, we could even poll all CPUs and check they're not exec
/archives/netdev/2000-06/msg00221.html (9,695 bytes)

10. Re: modular net drivers (score: 1)
Author: xxxx>
Date: Wed, 21 Jun 2000 07:49:40 +1000
This race is not obvious but IMHO it exists. The original theory was Kernel load and unload code runs under the big kernel lock. open() and similar code runs under the big kernel lock. If the code do
/archives/netdev/2000-06/msg00223.html (11,303 bytes)

11. Re: modular net drivers (score: 1)
Author: xxxx>
Date: Wed, 21 Jun 2000 16:56:44 +1000
[ Entry into other points of module during module_cleanup() example snipped ] Well, that race is obvious, IMHO. module_cleanup should unregister everything first, before doing other cleaning up (whic
/archives/netdev/2000-06/msg00242.html (10,674 bytes)

12. Re: modular net drivers (score: 1)
Author: xxxx>
Date: Thu, 22 Jun 2000 03:31:39 +0000
Yup. module_cleanup() calls unregister_netdev(). It would be better to do the unregister_netdev(), then to wait for everyone to stop using the device (but how?) and to then reap the module. Please. p
/archives/netdev/2000-06/msg00243.html (10,025 bytes)

13. Re: modular net drivers (score: 1)
Author: xxxx>
Date: Thu, 22 Jun 2000 08:44:29 -0400
Two things to remember: one, module_cleanup is called only when module use count (and hence user count) drops to zero, and two unregister_netdev closes the net device, so any users that slipped in an
/archives/netdev/2000-06/msg00246.html (10,580 bytes)

14. Re: modular net drivers (score: 1)
Author: xxxx>
Date: Thu, 22 Jun 2000 23:03:57 +1000
Not that simple. Module cleanup is entered with the big kernel lock which is supposed to prevent open() or its equivalents from entering the module until cleanup has completed. But module cleanup can
/archives/netdev/2000-06/msg00247.html (11,521 bytes)

15. Re: modular net drivers (score: 1)
Author: xxxx>
Date: Fri, 23 Jun 2000 00:01:16 +1000
The problem with the net drivers is that they are "opened" within the module constructor, "closed" with the module destructor and their "open" and "close" methods don't (can't) manipulate the refcoun
/archives/netdev/2000-06/msg00248.html (9,822 bytes)

16. Re: modular net drivers (score: 1)
Author: xxxx>
Date: Fri, 23 Jun 2000 03:48:58 +1000
OK. Here is how it would work: 1) struct module gets an `int cleanup_cpu'. 2) Modules supply a `deactivate()' method, which guarantees that (after synchronization) module count will NEVER increase. 3
/archives/netdev/2000-06/msg00250.html (11,825 bytes)

17. Re: modular net drivers (score: 1)
Author: kema)
Date: Sat, 24 Jun 2000 02:48:05 +1000
Alternate solution to avoid module problems: Phil Rumpf and I came up with basically identical answers. It assumes that MOD_INC_USE_COUNT is always called in user context, and involves no changes to
/archives/netdev/2000-06/msg00254.html (9,879 bytes)

18. Re: modular net drivers (score: 1)
Author: xxxx>
Date: Sat, 24 Jun 2000 13:08:29 +1000
Yup. I think this can be generalised and pushed out to userland more. A new system call: int sys_stop_cpu(int yep) sys_stop_cpu(1) Causes the current CPU to enter a busy loop, with local interrupts d
/archives/netdev/2000-06/msg00257.html (11,192 bytes)

19. Re: modular net drivers (score: 1)
Author: xxxx>
Date: Sat, 24 Jun 2000 08:01:06 -0700
Do we need to disable local interrupts ? interrupt handlers are safe because disable_irq is synchronous, not sure about softirqs. What's the point of exporting int sys_stop_cpu(int yep) ? I can't rea
/archives/netdev/2000-06/msg00259.html (12,656 bytes)

20. Re: modular net drivers (score: 1)
Author: xxxx>
Date: Sun, 25 Jun 2000 01:30:50 +1000
OK. I've flung together a prototype. It doesn't immediately crash.... -- linux-official/kernel/module.c Fri Jun 9 23:00:28 2000 +++ linux-akpm/kernel/module.c Sun Jun 25 01:15:57 2000 @@ -365,17 +365
/archives/netdev/2000-06/msg00260.html (11,779 bytes)


This search system is powered by Namazu