On Mon, 2015-02-23 at 18:56 +0200, Or Gerlitz wrote: > On Sun, Feb 22, 2015 at 2:27 AM, Doug Ledford <dledf...@redhat.com> wrote: > > We needed the mcast_mutex when we had to prevent the join completion > > callback from having the value it stored in mcast->mc overwritten > > downstream patches of this series (7/9 and 8/9) make pretty much heavy > usage of the mcast_mutex (e.g add/delete lines that use it), and patch > 9/9 removes it altogether.. which would be very confusing for > maintaining purposes. Is there a sane way to avoid that?!
No. The changes that make dropping the mutex possible are part of patch
7. Patch 7 changes the semantics of the MCAST_FLAG_BUSY usage, and
fixes some locking bugs, but that's different than wholesale changing of
the locking type. If you want to preserve bisecability and be able to
test the semantic changes to the FLAG_BUSY usage separate from the
changes to the locking type, then they have to be separated. So, for
the sake of good engineering practices and separation of distinctly
different types of changes, that locking change should not be folded
into patch 7.
--
Doug Ledford <dledf...@redhat.com>
GPG KeyID: 0E572FDD
signature.asc
Description: This is a digitally signed message part
