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).
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: g.lettieri at iet.unipi.it
On Tue, Feb 16, 2016 at 12:44:46AM +0300, Slawa Olhovchenkov wrote:> 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?Do you commit this fix?> - 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). >