sepherosa at gmail.com
Fri Jan 14 21:55:42 PST 2011
On Fri, Jan 14, 2011 at 3:33 AM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
> :Hi all,
> :Please review the devel^2 ~ devel^5 (inclusive) at:
> :The modification/accessing to the udbinfo is protected by two mechanism:
> :1) netisr barrier, which prevents code running in netisr from
> :accessing udbinfo when the modification is going to happen
> :2) serializer, which prevents code not running in netisr (e.g. sysctl,
> :interface detaching) from accessing udbinfo when the modification is
> :going to happen
> :1) makes the udp input/output path lock free.
> :Best Regards,
> I've been looking at this. It merges cleanly into master. It looks
> commitable but I do have two concerns:
> * The barrier is going to be very very expensive on machines with lots
> of cpus.
Yeah, but currently only the things like client side DNS resolving
(getaddrinfo()) could be seriously affected (given it close() and
open() a UDP socket each time).
Else it should be much better than holding token when accessing the
udbinfo. If token-based protection is used, we will also need extra
mechanism to make sure that any further processing on the located pcb
could not be blocked (e.g. by the sockbuf token)
The barrier cost probably would be greatly amortized if a UDP socket
is used for some data.
> * The sysctl callback (in_pcblist_global_nomarker()) is being called
> with the udbinfo locked. Since the sysctl does a copyout to userland
> it is possible for userland to deadlock the kernel due to the lock
> being held during the copyout.
> My recommendation is to perhaps make the udbinfo_lock() a lwkt_token
> and not a hard serializer. That will solve the sysctl/copyout issue.
OK, I see. But the concern is that token will be auto-released upon
blocking, however, I think we could allocate a temp buffer to save pcb
info and release serializer when doing copyout.
> I'm not sure re: the barrier.
Tomorrow Will Never Die
More information about the Kernel