Date: Thu, 19 Nov 2020 23:24:13 +0000 From: "Wall, Stephen" <stephen.wall@redcom.com> To: "freebsd-drivers@freebsd.org" <freebsd-drivers@freebsd.org> Subject: bug in sound driver? Message-ID: <DM6PR09MB4807F15897B9571B9D824D78EEE00@DM6PR09MB4807.namprd09.prod.outlook.com>
next in thread | raw e-mail | index | archive | help
I am working on a driver that is a modified copy of the sound driver, and I= 've found something that might be a bug. In sys/dev/sound/pcm/dsp.c, the funcion dap_io_ops() (called by dsp_read() = and dsp_write()) calls getchns() to get pointers to the channel control str= uctures. getchns() also locks the mutexs on those channels. After calling getchns(), dsp_io_ops() checks to see if a NULL pointer was r= eturns, OR if channels flags field does not have CHN_F_BUSY set. If either= of those are true, it release Giant and exits. That's fine if the pointer= is NULL, since the lock wouldn't have happened but if the BUSY flag is not= set, then dsp_io_ops() (and dsp_read/write()) returns with the channel sti= ll locked. In my driver, I am seeing kernel panics in some situations with this messag= e as a result: Sleeping thread (tid xxx, pid yyy) owns a non-sleepable lock Is this a bug in the sound driver? Should it check these two conditions se= parately and call relchns() if it fails due to the BUSY flag? -- Stephen Wall Senior Staff Software Engineer 585.924.7550 [1600261365931] REDCOM Laboratories, Inc. One Redcom Center Victor, NY 14564-0995 www.redcom.com DUNS 09-166-5919 | CAGE 1U548 Woman Owned Small Business
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DM6PR09MB4807F15897B9571B9D824D78EEE00>