From: Takashi Iwai <tiwai@suse.de>
To: Jaroslav Kysela <perex@perex.cz>
Cc: ALSA development <alsa-devel@alsa-project.org>
Subject: Re: [PATCH] alsactl: Skip restore during the lock
Date: Fri, 11 Dec 2020 18:06:53 +0100 [thread overview]
Message-ID: <s5hblf0nufm.wl-tiwai@suse.de> (raw)
In-Reply-To: <s5heejwnusm.wl-tiwai@suse.de>
On Fri, 11 Dec 2020 17:59:05 +0100,
Takashi Iwai wrote:
>
> On Fri, 11 Dec 2020 17:45:45 +0100,
> Jaroslav Kysela wrote:
> >
> > Dne 11. 12. 20 v 9:38 Takashi Iwai napsal(a):
> > > Currently alsactl-restore tries to initialize the device when an error
> > > is found for restore action. But this isn't the right behavior in the
> > > case where the lock is held; it implies that another alsactl is
> > > running concurrently, hence you shouldn't initialize the card at the
> > > same time. The situation is found easily when two alsactls get
> > > started by both udev and systemd (note that those two invocations are
> > > the designed behavior, see /usr/lib/udev/rules.d/78-sound-cards.rules
> > > for details).
> > >
> > > This patch changes load_state() not to handle the initialization if
> > > the locking fails.
> >
> > The operation should serialize in this case (there's limit of 10 seconds which
> > should be enough to finish the initialization). The state_lock() function
> > should return -EBUSY when the file is locked (and I'm fine to change the
> > behaviour from 'init' to 'skip' for this lock state).
> >
> > It seems that -EEXIST is returned when the lock file exists, but the
> > open(file, O_CREAT|O_EXCL, 0644) caller has not enough priviledges to access
> > this file when another user owns the file.
> >
> > But alsactl from /lib/udev/rules.d/90-alsa-restore.rules and
> > /lib/systemd/system/alsa-restore.service should be run as root, right?
>
> Yes, it should be root.
>
> I also wondered how EEXIST comes, too. Maybe it's also the race
> between the first open(O_RDWR) and the second
> open(O_RDWR|O_CREAT|O_EXCL)? If so, it'd be better to go back again
> to the normal open(O_RDWR)?
... something like below
diff --git a/alsactl/lock.c b/alsactl/lock.c
index 4a485392b3bd..c1c30f0c5eee 100644
--- a/alsactl/lock.c
+++ b/alsactl/lock.c
@@ -64,6 +64,9 @@ static int state_lock_(const char *file, int lock, int timeout, int _fd)
if (errno == EBUSY || errno == EAGAIN) {
sleep(1);
timeout--;
+ } if (errno == EEXIST){
+ /* race at creating a lock, try again */
+ continue;
} else {
err = -errno;
goto out;
Takashi
next prev parent reply other threads:[~2020-12-11 17:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-11 8:38 [PATCH] alsactl: Skip restore during the lock Takashi Iwai
2020-12-11 16:45 ` Jaroslav Kysela
2020-12-11 16:59 ` Takashi Iwai
2020-12-11 17:06 ` Takashi Iwai [this message]
2020-12-11 17:23 ` Jaroslav Kysela
2020-12-11 17:37 ` Takashi Iwai
2020-12-11 17:56 ` Jaroslav Kysela
2020-12-11 18:44 ` Takashi Iwai
2020-12-11 18:48 ` Jaroslav Kysela
2020-12-11 17:20 ` Jaroslav Kysela
2020-12-11 17:35 ` Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=s5hblf0nufm.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=perex@perex.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox