看板 DFBSD_kernel 關於我們 聯絡資訊
On Fri, Jan 14, 2011 at 3:33 AM, Matthew Dillon <dillon@apollo.backplane.com> wrote: > :Hi all, > : > :Please review the devel^2 ~ devel^5 (inclusive) at: > :http://gitweb.dragonflybsd.org/~sephe/dragonfly.git/shortlog/refs/heads/devel > : > :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, > :sephe > > ꀠ啱've been looking at this. 啱t merges cleanly into master. 啱t looks > ꀠ氲ommitable but I do have two concerns: > > ꀠꀪ The barrier is going to be very very expensive on machines with lots > ꀠꀠ漑f 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 > ꀠꀠ烀ith the udbinfo locked. 嚒ince the sysctl does a copyout to userland > ꀠꀠ湶t is possible for userland to deadlock the kernel due to the lock > ꀠꀠ毪eing held during the copyout. > > ꀠ嗰y recommendation is to perhaps make the udbinfo_lock() a lwkt_token > ꀠ乸nd not a hard serializer. 糍hat 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. > > ꀠ啱'm not sure re: the barrier. :) Best Regards, sephe -- Tomorrow Will Never Die