cvs commit: src/sys/dev/sound/pcm dsp.c mixer.c sound.c sound.h vchan.c

Ariff Abdullah ariff at
Tue Apr 4 17:43:54 UTC 2006

ariff       2006-04-04 17:43:49 UTC

  FreeBSD src repository

  Modified files:        (Branch: RELENG_6)
    sys/dev/sound/pcm    dsp.c mixer.c sound.c sound.h vchan.c 
          dsp.c           revision 1.95
          mixer.c         revision 1.49
          sound.c         revision 1.103
          sound.h         revision 1.68
          vchan.c         revision 1.24
  MEGA Fixes / Cleanup
  Fix severe 8bit integer overflow during channel creation and
  destruction, especially for vchans. It turns out that channel
  numbering always depend on d->devcount counter (which keep
  increasing), while PCMMKMINOR() truncate everything to 8bit length.
  At some point the truncation cause the newly created character device
  overlapped with the existed one, causing erratic overall system
  behaviour and panic. Easily reproduce with something like:
          (Luckily, only root can reproduce this)
          while : ; do
                  sysctl hw.snd.pcm0.vchans=200
                  sysctl hw.snd.pcm0.vchans=100
  - Enforce channel/chardev numbering within 8bit boundary. Return
    E2BIG if necessary.
  - Traverse d->channels SLIST and try to reclaim "free" counter during
    channel creation. Don't rely on d->devcount at all.
  - Determine open direction using 'flags', not 'mode'. This bug exist
    since past 4 years.
  - Don't allow opening the same device twice, be it in a same or
    different direction.
  - O_RDWR is allowed, provided that it is done by a single open (for
    example by mixer(8)) and the underlying hardware support true
    full-duplex operation.
  - Seal the fate of long standing memory leak (4 years, 7 months)
    during pcm_unregister(). While destroying cdevs, scan / detect
    possible children and free its SLIST placeholder properly.
  - Optimize channel allocation / numbering even further. Do brute
    cyclic checking only if the channel numbering screwed.
  - Mega vchan create/destroy cleanup:
    o Implement pcm_setvchans() so everybody can use it freely instead
      of implementing their own, be it through sysctl or channel auto
    o Increase vchan creation/destruction resiliency:
      + it's possible to increase/decrease total vchans even during
        busy playback/recording. Busy channel will be left alone,
        untouched. Abusive test sample:
        # play whatever...
           while : ; do
             sysctl hw.snd.pcm0.vchans=1
             sysctl hw.snd.pcm0.vchans=10
             sysctl hw.snd.pcm0.vchans=100
             sysctl hw.snd.pcm0.vchans=200
        # Play something else, leave above loop running frantically.
      + Seal another 4 years old bug where it is possible to destroy
        (virtual) channel even when its cdevs being referenced by other
        process.  The "First Come First Served" nature of dsp_clone() is
        the main culprit of this issue, and usually manifest itself as
        dangling channel <-> process association. Ensure that all of its
        cdevs are free from being referenced before destroying it
        (through ORPHAN_CDEVT() macross).
  Approved by:    re (scottl)
  Revision  Changes    Path  +66 -90    src/sys/dev/sound/pcm/dsp.c  +13 -1     src/sys/dev/sound/pcm/mixer.c  +373 -303  src/sys/dev/sound/pcm/sound.c  +12 -7     src/sys/dev/sound/pcm/sound.h  +49 -33    src/sys/dev/sound/pcm/vchan.c

More information about the cvs-src mailing list