From: Takashi Iwai <tiwai@suse.de>
To: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: alsa-devel@alsa-project.org, clemens@ladisch.de
Subject: Re: [PATCH 3/5] ALSA: control: fix logic error about control count in a device
Date: Thu, 12 Feb 2015 14:29:31 +0100 [thread overview]
Message-ID: <s5h7fvnb6mc.wl-tiwai@suse.de> (raw)
In-Reply-To: <54DCA8B0.1050306@sakamocchi.jp>
At Thu, 12 Feb 2015 22:20:48 +0900,
Takashi Sakamoto wrote:
>
> On 2015年02月11日 22:15, Takashi Iwai wrote:
> > At Wed, 11 Feb 2015 19:40:11 +0900,
> > Takashi Sakamoto wrote:
> >>
> >> It's assumed that the number of userspace controls is just 1 in several
> >> parts, while this assumptions is not always true because the value of
> >> 'owner' member can be assigned to.
> >>
> >> This commit fixes this issue.
> >
> > Well, the current code isn't incorrect, it deals with the number of
> > grouped elements, not the total number of elements.
>
> I didn't read such design from these comments.
>
> include/sound/core.h:
> struct snd_card {
> ...
> int controls_count; /* count of all controls */
> int user_ctl_count; /* count of all user controls */
> }}}
>
> But '32' is a bit little as maximum number of userspace controls, so
> your explaination may be true. If so, the comment should be 'count of
> user control groups', at least, different expression should be used.
Actually the text wasn't updated when we changed the code to allow
multiple counts.
> > So, this is rather a change of the semantics of card->user_ctl_count
> > field than a fix, and it's the question: whether we should limit for
> > the whole number of elements.
>
> We should assume that userspace applications include any bugs. There may
> be an application which adds too many controls. In this reason, we
> should limit the maximum number of elements.
It's already limited (as each type has the limited number of max
elements). Your patch would just limit it more strictly.
> > There is a very slight chance of user-space breakage by counting the
> > whole numbers, but pragmatically seen, I think it's acceptable from
> > the safety POV.
>
> Kernel drivers don't add so many controls, thus such breakage is caused
> by userspace applications. But I cannot imagine such breakage. How it
> occurs?
The patch essentially reduces the max user elements. If a user-space
program knows of the limitation and works around it secretly by use of
multiple counts, this application would be broken after your patch.
This can be seen as a kernel regression.
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
next prev parent reply other threads:[~2015-02-12 13:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-11 10:40 [PATCH 0/5] ALSA: control: improve core codes with intrusion Takashi Sakamoto
2015-02-11 10:40 ` [PATCH 1/5] ALSA: control: drop a sub-effect for caller's data Takashi Sakamoto
2015-02-11 10:40 ` [PATCH 2/5] ALSA: control: use dev_dbg() for warning to add duplicated controls Takashi Sakamoto
2015-02-11 10:40 ` [PATCH 3/5] ALSA: control: fix logic error about control count in a device Takashi Sakamoto
2015-02-11 13:15 ` Takashi Iwai
2015-02-12 13:20 ` Takashi Sakamoto
2015-02-12 13:29 ` Takashi Iwai [this message]
2015-02-12 23:06 ` Takashi Sakamoto
2015-02-13 8:31 ` Takashi Iwai
2015-02-11 10:40 ` [PATCH 4/5] ALSA: control: improve returned value because of the rest Takashi Sakamoto
2015-02-11 12:05 ` Takashi Iwai
2015-02-11 10:40 ` [PATCH 5/5] ALSA: control: save stack usage at creating new instance Takashi Sakamoto
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=s5h7fvnb6mc.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=clemens@ladisch.de \
--cc=o-takashi@sakamocchi.jp \
/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