I am sorry, I did not participate to the implementation of kqueue
support and I am not able to comment. Luigi and Adrian should know, however.
Cheers,
Giuseppe
Il 15/02/2016 22:44, Slawa Olhovchenkov ha scritto:
On Mon, Feb 15, 2016 at 05:02:36PM +0100, Giuseppe Lettieri wrote:
Il 15/02/2016 16:13, Slawa Olhovchenkov ha scritto:
On Mon, Feb 15, 2016 at 04:10:30PM +0100, Giuseppe Lettieri wrote:
Hi Slawa,
I think WITNESS is seeing a false positive, since those two are always
different mutexes.
The actual deadlock you experience should be caused by something else. I
Are you sure? When deadlock occur I am see threads waiting on nm_kn_lock.
The deadlock I mentioned still involves nm_kn_locks, sorry if I was not
clear about that. I am just saying that we never try to take the same
lock that we already holding.
Nonetheless, there are indeed problems in the path that WITNESS has
seen. The problem is that pipes have to notify the other end while
called by kevent. kevent holds the nm_kn_lock on the TX src ring and the
notification takes the nm_kn_lock on the RX dst ring.
Can you comment other issuses? Is this by design or is this bug?
- with kevent sync for transmiting need first register
EVFILT_WRITE/EV_DISABLE and after every write
EVFILT_WRITE/EV_DISPATCH
- with kevent sync all opening /dev/netmap and registering need do
from same thread as kevent using for sinc (unless no RX/TX).
--
Dr. Ing. Giuseppe Lettieri
Dipartimento di Ingegneria della Informazione
Universita' di Pisa
Largo Lucio Lazzarino 1, 56122 Pisa - Italy
Ph. : (+39) 050-2217.649 (direct) .599 (switch)
Fax : (+39) 050-2217.600
e-mail: [email protected]
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[email protected]"
