kernel-janitors.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: walter harms <wharms@bfs.de>
To: Takashi Iwai <tiwai@suse.de>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
	Jaroslav Kysela <perex@perex.cz>,
	Yacine Belkadi <yacine.belkadi.1@gmail.com>,
	alsa-devel@alsa-project.org, kernel-janitors@vger.kernel.org
Subject: Re: [patch] ALSA: bits vs bytes bug in snd_card_create()
Date: Thu, 23 Jan 2014 09:27:18 +0000	[thread overview]
Message-ID: <52E0E076.7020707@bfs.de> (raw)
In-Reply-To: <s5hr47zt6jn.wl%tiwai@suse.de>



Am 23.01.2014 10:02, schrieb Takashi Iwai:
> At Thu, 23 Jan 2014 09:55:31 +0100,
> walter harms wrote:
>>
>>
>> Am 23.01.2014 09:21, schrieb Dan Carpenter:
>>> The test here is intended intended to prevent shift wrapping bugs when
>>> we do "1U << idx2".  We should consider the number of bits in a u32
>>> instead of the number of bytes.
>>>
>>> Fixes: 7bb2491b35a2 ('ALSA: Add kconfig to specify the max card numbers')
>>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>>> ---
>>> WARNING:  Please check this one carefully because I might be wrong.
>>>
>>> diff --git a/sound/core/init.c b/sound/core/init.c
>>> index 1351f22f651c..e9e3db321e64 100644
>>> --- a/sound/core/init.c
>>> +++ b/sound/core/init.c
>>> @@ -183,7 +183,7 @@ int snd_card_create(int idx, const char *xid,
>>>  	if (idx < 0) {
>>>  		for (idx2 = 0; idx2 < SNDRV_CARDS; idx2++) {
>>>  			/* idx = -1 = 0xffff means: take any free slot */
>>> -			if (idx2 < sizeof(int) && !(idx & (1U << idx2)))
>>> +			if (idx2 < 32 && !(idx & (1U << idx2)))
>>>  				continue;
>>>  			if (!test_bit(idx2, snd_cards_lock)) {
>>>  				if (!slots[idx2] || !*slots[idx2]) {
>>> --
>>
>> Funny bug,
>> to be 100% sure you could multiply by CHAR_BIT ;)
>>
>> other code simple does (1UL << (nr & 31))
>> on the other side a check like:
>>
>> #if SNDRV_CARDS > 32
>> # error to much sound
>> #endif
>>
>> whould give the user a hint what is going on instead of silently ignoring
>> that error.
> 
> SNDRV_CARDS can be more than 32.  That's why the check was
> introduced.
> 

yes of cause, but so far i understand this code will do "continue" if SNDRV_CARDS
is more that 31, no warning.
(warning Start academic discussion):
If anyone ever has more that 31 soundcard he will wonder why 31 are working but the
rest will remain silent. It would be nice to have a idea that there is an internal limit
and it is not sufficient to change  SNDRV_CARDS from 8 to 256. (did i understand the code
correctly ?) and there is no warning.

re,
 wh



      reply	other threads:[~2014-01-23  9:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-23  8:21 [patch] ALSA: bits vs bytes bug in snd_card_create() Dan Carpenter
2014-01-23  8:36 ` Takashi Iwai
2014-01-23 10:48   ` Takashi Iwai
2014-01-23  8:55 ` walter harms
2014-01-23  9:02   ` Takashi Iwai
2014-01-23  9:27     ` walter harms [this message]

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=52E0E076.7020707@bfs.de \
    --to=wharms@bfs.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=dan.carpenter@oracle.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=tiwai@suse.de \
    --cc=yacine.belkadi.1@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).