public inbox for alsa-devel@alsa-project.org
 help / color / mirror / Atom feed
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

  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