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: <200908050432.35016.vda.linux@googlemail.com>
Date:	Wed, 5 Aug 2009 04:32:34 +0200
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	Takashi Iwai <tiwai@...e.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: sound: -EPERM on first mplayer invocation

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

mplayer:
alsa-control: error setting left channel, Operation not permitted

The pid is mplayer's pid:

# ps -A | grep mpl
 2067 root       0:01 mplayer The_league_of_extraordinary_gentlemen.avi
 2081 root       0:00 grep mpl

It has one thread, btw, no funky multithreading stuff:

# ls -l /proc/2067/task
dr-xr-xr-x    4 root     root            0 Aug  5 04:28 2067

-- 
vda
--
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/