Messages in this thread | | | Subject | Re: Badness in __mutex_unlock_slowpath | From | Arjan van de Ven <> | Date | Sat, 07 Jan 2006 22:13:42 +0100 |
| |
On Sat, 2006-01-07 at 15:51 -0500, Andrew James Wade wrote: > Hello, > > I got this when "amaroK" started playing: > > Badness in __mutex_unlock_slowpath at kernel/mutex.c:214 > [<c03538e8>] __mutex_unlock_slowpath+0x56/0x1a2 > [<c0302f08>] snd_pcm_oss_write+0x0/0x1e0 > [<c0302f3c>] snd_pcm_oss_write+0x34/0x1e0 > [<c0302f08>] snd_pcm_oss_write+0x0/0x1e0 > [<c0148221>] vfs_write+0x83/0x122 > [<c0148a36>] sys_write+0x3c/0x63 > [<c0102ba3>] sysenter_past_esp+0x54/0x75 > > (2.6.15-mm2)
this looks like a really evil alsa bug:
(pre mutex code below)
static ssize_t snd_pcm_oss_write(struct file *file, const char __user *buf, size_t count, loff_t *offset) { snd_pcm_oss_file_t *pcm_oss_file; snd_pcm_substream_t *substream; long result;
pcm_oss_file = file->private_data; substream = pcm_oss_file->streams[SNDRV_PCM_STREAM_PLAYBACK]; if (substream == NULL) return -ENXIO; up(&file->f_dentry->d_inode->i_sem); result = snd_pcm_oss_write1(substream, buf, count); down(&file->f_dentry->d_inode->i_sem);
this is a .write method of a driver, which doesn't run with i_sem helt at all. Best guess I have is that this code has up() and down() confused and switched...
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |