On Mon, Aug 13, 2007 at 02:31:06PM +0200, Max Laier wrote: > > It looks like a whole lot of complex code can be run with pfil rwlock > > held. More complex code - harder to avoid sleeping. Is it not possible > > to call ->pfil_func() without holding pfil rwlock? For example by > > acquiring the lock, taking a hook, increasing its reference count so it > > won't go away, dropping the lock and calling ->pfil_func() ? > > Won't help a bit. There are other locks on the way that would need > similar changes. I believe that things that hook into pfil(9) must be > aware that they are running in the hot transmission path. Actions that > can not be performed with a mutex held must be deferred to another > context. Note that traditional pfil(9) consumers used to run at splnet, > where sleeping is a bad idea as well. After I send that e-mail, I realized that sleeping with read lock should be ok. When we acquire read lock and sleep, other readers can also acquire it and when we need write lock, we don't operate in fast path (I assume we need write lock when we register/deregister hook mostly). In other words we could change pfil lock from rwlock(9) to sx(9). In this very case posted in the begining of the thread I see nothing wrong in thread sleeping in sendfile(2), because it won't affect other processes. BUT if as you said there are other locks in the way, my idea doesn't apply. -- Pawel Jakub Dawidek http://www.wheel.pl pjd_at_FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am!
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:16 UTC