Yes, I can reproduce it, for example I have 2 vms, and I configure 2K bfd monitored tunnel together at the same time. And then, I can see one end will be deadlocked.
On Mon, Apr 7, 2014 at 5:20 PM, Ben Pfaff <b...@nicira.com> wrote: > On Thu, Apr 03, 2014 at 09:02:48PM -0700, Alex Wang wrote: > > Commit 6b59b543 (ovs-thread: Use fair (but nonrecursive) > > rwlocks on glibc.) changed the rwlocks to nonrecursive, > > writer-biased lock. It also made the following deadlock > > situation possible. > > > > Assume BFD is used on both end of a link. Consider the > > following events: > > 1. Handler at one end received the BFD control packet with > > POLL flag set while holding the read lock of 'xlate_rwlock'. > > Since a BFD control packet with FINAL flag set should be > > sent back immediately, it calls the > > ofproto_dpif_monitor_port_send_soon(), in which, it tries > > to grab the 'monitor_mutex'. > > 2. The main thread needs to configure the ofproto-dpif-xlate > > module. It tries to grab the write lock of 'xlate_rwlock' > > and is blocked by event 1. > > 3. The monitor thread, after acquired the 'monitor_mutex', > > wants to acquire the read lock of 'xlate_rwlock'. > > > > Since the rwlock is now writer-biased, the attempt of acquiring > > read lock in event 3 will be blocked by event 2. This will > > subsequently cause the block of event 1, since monitor thread > > is holding the 'monitor_mutex'. So the deadlock happens. > > Have you observed this deadlock or just found it in the source code. > Is there a good way to reproduce the deadlock? I'd like to do some > experiments. >
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
