Messages in this thread | | | Date | Sun, 27 Jun 1999 19:46:35 +0100 | From | Steve Dodd <> | Subject | Re: [patch] 2.3.8+ UP masq |
| |
On Sun, Jun 27, 1999 at 03:11:39PM -0300, Juanjo Ciarlante wrote:
> > How come? As I understand it, > > the masq stuff is called by the networking stuff > > the networking stuff is called from the bottom half > > the bottom halves are run in sched.c, out of irq context (obviously)
> Yup: thats kernel path > [I used irq locks instead of bh locks because of > the tiny area they protect, given that the actual code that blocks IRQ was > faster (this assumption may be wrong)]
Errr... Call me stupid, but..
Blocking interrupts does just that: nothing else (spin_{,un}lock_irq don't define a 'critical section', but they don't need to on UP). We're never called from interrupt context as far as I can see, so we don't need to do it? SMP is obviously a different matter, but that's what vanilla spinlocks are for in the first place, surely?
> The lock is _actually_ needed because of ip_masq_user module, that allows > creation of masq tunnels from U-space (so it must protect itself from > bh-firing in this region).
Yes, but user space can't trigger access from interrupt context, can it? It's just a syscall, so we're executing normally but in kernel context. bh's are run by the scheduler in between tasks; actually, it also ensures IIUC that they're not entered on more than one CPU at once, but as you point out a normal task could enter ip_masq_uctl() outside of the BH on a different CPU on SMP.
BTW:
Are all accesses to ip_masq_user_hook in ip_masq.c done with the kernel lock held? If not, there might be a problem there too.
-- "Hey! Who took the cork off my lunch??!" -- W. C. Fields
- 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/
| |