linux-kernel - Re: sound: -EPERM on first mplayer invocation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <s5hd47aes85.wl%tiwai@suse.de>
Date:	Wed, 05 Aug 2009 07:37:30 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Denys Vlasenko <vda.linux@...glemail.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: sound: -EPERM on first mplayer invocation

At Wed, 5 Aug 2009 04:32:34 +0200,
Denys Vlasenko wrote:
> 
> On Tuesday 04 August 2009 11:16, Takashi Iwai wrote:
> > > > > For a long time I observe the following nuisance:
> > > > > when I run mplayer for the very first time after boot,
> > > > > I can't adjust the volume. mplayer spews this to stderr:
> > > > > 
> > > > > alsa-control: error setting left channel, Operation not permitted
> > > > > 
> > > > > This happens even if I login as root and run mplayer as root.
> > > > > 
> > > > > I tracked it down to snd_ctl_elem_write in sound/core/control.c
> > > > > 
> > > ...
> > > > > 
> > > > > Thus, vd->owner != file.
> > > > > 
> > > > > As I said, it only happens on very first run of mplayer,
> > > > > and it isn't a recent change, I think I saw it at least
> > > > > for one year with different kernels.
> > > > > 
> > > > > Takashi, any idea what might be happening here?
> > > > > How can I help you more with tracking it down?
> > > > 
> > > > This implies that another process (e.g. a sound daemon like PA)
> > > > already opened the device and locked this specific control element.
> > > > If so, this is no bug but the right behavior.
> > > > Check "fuser /dev/snd/controlC*".
> > > 
> > > Nothing uses them:
> > > 
> > > shadow:~# lsof -nP | grep '/dev/.*control'
> > > shadow:~# fuser /dev/snd/controlC*
> > > shadow:~#
> > > 
> > > I tried running bare X with only xterm and mplayer,
> > 
> > Hm, but according to your debug session, the vd->owner is set
> > to a different value, right?  Check vd->owner_pid in the error path.
> > It'll show the pid blocking that control element.
> 
> I modified 2.6.31-rc2 source as follows:
> 
> static int snd_ctl_elem_write(struct snd_card *card, struct snd_ctl_file *file,
>                               struct snd_ctl_elem_value *control)
> {
>         struct snd_kcontrol *kctl;
>         struct snd_kcontrol_volatile *vd;
>         unsigned int index_offset;
>         int result;
> 
>         down_read(&card->controls_rwsem);
>         kctl = snd_ctl_find_id(card, &control->id);
>         if (kctl == NULL) {
>                 result = -ENOENT;
>         } else {
>                 index_offset = snd_ctl_get_ioff(kctl, &control->id);
>                 vd = &kctl->vd[index_offset];
> if (file && vd->owner)
>  printk("file:%p vd->owner:%p\n", file, vd->owner);
>                 if (!(vd->access & SNDRV_CTL_ELEM_ACCESS_WRITE) ||
>                     kctl->put == NULL ||
>                     (file && vd->owner && vd->owner != file)) {
> if (file && vd->owner)
>  printk("vd->owner_pid:%d vd->owner->pid:%d file->pid:%d\n", vd->owner_pid, vd->owner->pid, file->pid);
>                         result = -EPERM;
>                 } else {
> ...
> 
> and when I start mplayer, I see this:
> 
> dmesg:
> file:ffff8800798af940 vd->owner:ffff8800798af940
> file:ffff8800798af940 vd->owner:ffff8800798af940
> 
> I assume it's some sort of initialization, no EPERM here.
> Then I press "lower the volume" key (keypad "/")
> in mplayer window, twice:
> 
> dmesg:
> file:ffff8800798af8c0 vd->owner:ffff8800798af940
> vd->owner_pid:0 vd->owner->pid:2067 file->pid:2067
> file:ffff8800798af740 vd->owner:ffff8800798af940
> vd->owner_pid:0 vd->owner->pid:2067 file->pid:2067

The file instances are different.  It implies that mplayer opens the
device at each time but doesn't close.
It sounds like a bug in mplayer to me.


Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/