Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 18 Mar 2004 01:55:11 -0800 (PST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   cvs commit: src/sys/net if_tap.c
Message-ID:  <200403180955.i2I9tBeG019264@repoman.freebsd.org>

next in thread | raw e-mail | index | archive | help
rwatson     2004/03/18 01:55:11 PST

  FreeBSD src repository

  Modified files:
    sys/net              if_tap.c 
  Log:
  sAdd a comment indicating why there continues to be a race condition in
  the tap driver, even with Giant over the cdev operation vector, due to
  a non-atomic test-and-set of the si_drv1 field in the dev_t.  This bug
  exists with Giant under high memory pressure, as malloc() may sleep
  in tapcreate(), but is less likely to occur.  The resolution will
  probably be to cover si_drv1 using the global tapmtx since no softc is
  available, but I need to think about this problem more generally
  across a range of drivers using si_drv1 in combination with SI_CHEAPCLONE
  to defer expensive allocation to open().
  
  Correct what appears to be a bug in the original if_tap implementation,
  in which tapopen() will panic if a tap device instance is opened more
  than once due to an incorrect assertion -- only triggered if INVARIANTS
  is compiled in (i.e., when built into a kernel).  Return EBUSY instead.
  
  Expand mtx_lock() coverage using tp->tap_mtx to include tp->ether_addr.
  
  Revision  Changes    Path
  1.41      +14 -5     src/sys/net/if_tap.c



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403180955.i2I9tBeG019264>