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: <s5hr5vt8jyp.wl%tiwai@suse.de>
Date:	Mon, 03 Aug 2009 08:55:42 +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 Sun, 2 Aug 2009 23:36:48 +0200,
Denys Vlasenko wrote:
> 
> Hi,
> 
> 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
> 
> 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 (!(vd->access & SNDRV_CTL_ELEM_ACCESS_WRITE) ||
>                     kctl->put == NULL ||
>                     (file && vd->owner && vd->owner != file)) {
>  printk("EPERM:\n");
>  printk("vd->access & SNDRV_CTL_ELEM_ACCESS_WRITE:%x\n", vd->access & SNDRV_CTL_ELEM_ACCESS_WRITE);
>  printk("kctl->put:%p\n", kctl->put);
>  printk("file:%p vd->owner:%p\n", file, vd->owner);
>                         result = -EPERM;
>                 } else {
> 
> The above printk triggers and prints:
> 
> EPERM:
> vd->access & SNDRV_CTL_ELEM_ACCESS_WRITE:2
> kctl->put:ffffffffa009e8de
> file:ffff88007c56a5c0 vd->owner:ffff88007bc34740
> 
> 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*".


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/