linux-kernel - Re: Sound problems with snd_hda on x86

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] [day] [month] [year] [list]

Message-ID: <s5hzmetn7n2.wl%tiwai@suse.de>
Date:	Fri, 28 Jul 2006 16:09:21 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Denis Vlasenko <vda.linux@...glemail.com>
Cc:	alsa-devel@...a-project.org, linux-kernel@...r.kernel.org
Subject: Re: Sound problems with snd_hda on x86_64

[CC list reduced since it's pretty ALSA specific now]

At Fri, 28 Jul 2006 15:14:13 +0200,
Denis Vlasenko wrote:
> 
> On Friday 28 July 2006 13:33, Takashi Iwai wrote:
> > > Why artsd attempts mmap at all then?
> > 
> > The app must try mmap.  From the application side, you can't know
> > whether you're 32bit-emulation mode or it's really on 32bit
> > architecture.  And, mmap is usually done automatically via alsa-lib
> > plugin for optimization or soft-mixing purpose.
> 
> Well, alsa seems to have info about mmap-ability here:
> 
> static struct snd_pcm_hardware azx_pcm_hw = {
>         .info =                 (SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_INTERLEAVED |
>                                  SNDRV_PCM_INFO_BLOCK_TRANSFER |
>                                  SNDRV_PCM_INFO_MMAP_VALID |
>                                  SNDRV_PCM_INFO_PAUSE /*|*/
>                                  /*SNDRV_PCM_INFO_RESUME*/),
> ...
> };
> 
> but it is not split into "can mmap data", "can mmap control/status".

It's only for mmap data and has nothing to do with control/status
mmap.

> When this one triggers:
> 
> snd_pcm_ioctl_compat()
> ...
>         /*
>          * When PCM is used on 32bit mode, we need to disable
>          * mmap of PCM status/control records because of the size
>          * incompatibility.
>          */
>         substream->no_mmap_ctrl = 1;
> 
> It does not clear any such flags. If there will be separate bits
> for data and "status/control", should they be cleared here too?
> 
> What will happen if fd is opened in 64-bit process and then
> process will exec a 32-bit one, _after_ doing ioctl
> but _before_ mmap?! substream->no_mmap_ctrl will remain cleared.
> Looks disastrous.

mmap is called always after ioctl as long as you use alsa-lib.

> And still _now_ there is only one bit. Does it mean
> "mmap works on data and status/control" or 
> "mmap works on data and _maybe_ on status/control"?

The PCM bit is only for mmap data.  The status/control mmap is
irrelevant, and can be used even the PCM data is non-mmappable.

> Another matter. IIRC this mmap is not to the hardware
> (hardware memory-mapped structures won't change layout when one
> replaces 32bit kernel by 64bit one) but to some software alsa
> structure. Can it be made more clever in this case, like
> using 32bit structure for 32bit tasks? Or allowing 32bit tasks
> to detect that structure is 64bit and they should use it?

Would be nice, but how to detect it?

> Second one sounds saner.

Well, the simplest solution is to fix that 64bit incompatiblity in the
struct definition.  Right now, it's still unchanged just to keep the
compatibility with older versions, but it's possible to introduce a
new struct together with new mmap offset, for example.


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