All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rich Felker <dalias@libc.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: musl@lists.openwall.com, Takashi Iwai <tiwai@suse.de>,
	Michael Forney <mforney@mforney.org>,
	ALSA Development Mailing List <alsa-devel@alsa-project.org>,
	Takashi Iwai <tiwai@suse.com>,
	Baolin Wang <baolin.wang@linaro.org>,
	y2038 Mailman List <y2038@lists.linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Mark Brown <broonie@kernel.org>,
	Baolin Wang <baolin.wang7@gmail.com>
Subject: Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
Date: Tue, 19 Oct 2021 10:16:24 -0400	[thread overview]
Message-ID: <20211019141622.GN7074@brightrain.aerifal.cx> (raw)
In-Reply-To: <20211018204203.GM7074@brightrain.aerifal.cx>

[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]

On Mon, Oct 18, 2021 at 04:42:04PM -0400, Rich Felker wrote:
> On Mon, Oct 18, 2021 at 05:26:35PM +0200, Arnd Bergmann wrote:
> > On Mon, Oct 18, 2021 at 5:08 PM Rich Felker <dalias@libc.org> wrote:
> > > On Mon, Oct 18, 2021 at 04:58:03PM +0200, Takashi Iwai wrote:
> > > > On Mon, 18 Oct 2021 16:43:00 +0200, Rich Felker wrote:
> > >
> > > No, I don't think so. The musl translator is to translate between the
> > > time64 ioctl structures and the old time32 ones for the sake of
> > > executing on an old kernel. Up til now, it has been broken comparably
> > > to how 32-bit binaries running in compat mode on a 64-bit kernel were
> > > broken: the code in musl translated the time64 structure to (and back
> > > from) the time32 one assuming the intended padding. But the
> > > application was using the actual kernel uapi struct where the padding
> > > was (and still is) illogical. Thus, nothing was built with the wrong
> > > ABI; it's only the musl-internal translation logic that was wrong (and
> > > only pre-time64 kernels are affected).
> > >
> > > The attached patch should fix it, I think.
> > >
> > > + int adj = BYTE_ORDER==BIG_ENDIAN ? 4 : 0;
> > > + if (dir==W) {
> > > +     memcpy(old+68, new+72+adj, 4);
> > > +     memcpy(old+72, new+72+4+2*adj, 4);
> > 
> > I think that should be "new+72+4+3*adj": the "2*adj" would
> > be what the code does already for the originally intended
> > format.
> 
> Well for little endian either would work (because adj is 0 :) but yes
> there are 3 such paddings before the second member on big endian, so
> it should be 3.

How about this? It avoids open coding the logic and handles it as 2
4-byte substructures with endian-specific offsets.

Rich

[-- Attachment #2: snd_pcm_mmap_control_v2.diff --]
[-- Type: text/plain, Size: 1506 bytes --]

diff --git a/src/misc/ioctl.c b/src/misc/ioctl.c
index 49282811..35804f02 100644
--- a/src/misc/ioctl.c
+++ b/src/misc/ioctl.c
@@ -6,6 +6,7 @@
 #include <stddef.h>
 #include <stdint.h>
 #include <string.h>
+#include <endian.h>
 #include "syscall.h"
 
 #define alignof(t) offsetof(struct { char c; t x; }, x)
@@ -53,7 +54,7 @@ static const struct ioctl_compat_map compat_map[] = {
 	{ _IOWR('A', 0x23, char[136]), _IOWR('A', 0x23, char[132]), 0, WR, 1, 0 },
 	{ 0, 0, 4, WR, 1, 0 }, /* snd_pcm_sync_ptr (flags only) */
 	{ 0, 0, 32, WR, 1, OFFS(8,12,16,24,28) }, /* snd_pcm_mmap_status */
-	{ 0, 0, 8, WR, 1, OFFS(0,4) }, /* snd_pcm_mmap_control */
+	{ 0, 0, 4, WR, 1, 0 }, /* snd_pcm_mmap_control (each member) */
 
 	/* VIDIOC_QUERYBUF, VIDIOC_QBUF, VIDIOC_DQBUF, VIDIOC_PREPARE_BUF */
 	{ _IOWR('V',  9, new_misaligned(68)), _IOWR('V',  9, char[68]), 68, WR, 1, OFFS(20, 24) },
@@ -90,7 +91,11 @@ static void convert_ioctl_struct(const struct ioctl_compat_map *map, char *old,
 		 * if another exception appears this needs changing. */
 		convert_ioctl_struct(map+1, old, new, dir);
 		convert_ioctl_struct(map+2, old+4, new+8, dir);
-		convert_ioctl_struct(map+3, old+68, new+72, dir);
+		/* snd_pcm_mmap_control, special-cased due to kernel
+		 * type definition having been botched. */
+		int adj = BYTE_ORDER==BIG_ENDIAN ? 4 : 0;
+		convert_ioctl_struct(map+3, old+68, new+72+adj, dir);
+		convert_ioctl_struct(map+3, old+72, new+76+3*adj, dir);
 		return;
 	}
 	for (int i=0; i < map->noffs; i++) {

WARNING: multiple messages have this Message-ID (diff)
From: Rich Felker <dalias@libc.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: ALSA Development Mailing List <alsa-devel@alsa-project.org>,
	Baolin Wang <baolin.wang@linaro.org>,
	Takashi Iwai <tiwai@suse.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	musl@lists.openwall.com, Takashi Iwai <tiwai@suse.com>,
	Michael Forney <mforney@mforney.org>,
	y2038 Mailman List <y2038@lists.linaro.org>,
	Mark Brown <broonie@kernel.org>,
	Baolin Wang <baolin.wang7@gmail.com>
Subject: Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
Date: Tue, 19 Oct 2021 10:16:24 -0400	[thread overview]
Message-ID: <20211019141622.GN7074@brightrain.aerifal.cx> (raw)
In-Reply-To: <20211018204203.GM7074@brightrain.aerifal.cx>

[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]

On Mon, Oct 18, 2021 at 04:42:04PM -0400, Rich Felker wrote:
> On Mon, Oct 18, 2021 at 05:26:35PM +0200, Arnd Bergmann wrote:
> > On Mon, Oct 18, 2021 at 5:08 PM Rich Felker <dalias@libc.org> wrote:
> > > On Mon, Oct 18, 2021 at 04:58:03PM +0200, Takashi Iwai wrote:
> > > > On Mon, 18 Oct 2021 16:43:00 +0200, Rich Felker wrote:
> > >
> > > No, I don't think so. The musl translator is to translate between the
> > > time64 ioctl structures and the old time32 ones for the sake of
> > > executing on an old kernel. Up til now, it has been broken comparably
> > > to how 32-bit binaries running in compat mode on a 64-bit kernel were
> > > broken: the code in musl translated the time64 structure to (and back
> > > from) the time32 one assuming the intended padding. But the
> > > application was using the actual kernel uapi struct where the padding
> > > was (and still is) illogical. Thus, nothing was built with the wrong
> > > ABI; it's only the musl-internal translation logic that was wrong (and
> > > only pre-time64 kernels are affected).
> > >
> > > The attached patch should fix it, I think.
> > >
> > > + int adj = BYTE_ORDER==BIG_ENDIAN ? 4 : 0;
> > > + if (dir==W) {
> > > +     memcpy(old+68, new+72+adj, 4);
> > > +     memcpy(old+72, new+72+4+2*adj, 4);
> > 
> > I think that should be "new+72+4+3*adj": the "2*adj" would
> > be what the code does already for the originally intended
> > format.
> 
> Well for little endian either would work (because adj is 0 :) but yes
> there are 3 such paddings before the second member on big endian, so
> it should be 3.

How about this? It avoids open coding the logic and handles it as 2
4-byte substructures with endian-specific offsets.

Rich

[-- Attachment #2: snd_pcm_mmap_control_v2.diff --]
[-- Type: text/plain, Size: 1506 bytes --]

diff --git a/src/misc/ioctl.c b/src/misc/ioctl.c
index 49282811..35804f02 100644
--- a/src/misc/ioctl.c
+++ b/src/misc/ioctl.c
@@ -6,6 +6,7 @@
 #include <stddef.h>
 #include <stdint.h>
 #include <string.h>
+#include <endian.h>
 #include "syscall.h"
 
 #define alignof(t) offsetof(struct { char c; t x; }, x)
@@ -53,7 +54,7 @@ static const struct ioctl_compat_map compat_map[] = {
 	{ _IOWR('A', 0x23, char[136]), _IOWR('A', 0x23, char[132]), 0, WR, 1, 0 },
 	{ 0, 0, 4, WR, 1, 0 }, /* snd_pcm_sync_ptr (flags only) */
 	{ 0, 0, 32, WR, 1, OFFS(8,12,16,24,28) }, /* snd_pcm_mmap_status */
-	{ 0, 0, 8, WR, 1, OFFS(0,4) }, /* snd_pcm_mmap_control */
+	{ 0, 0, 4, WR, 1, 0 }, /* snd_pcm_mmap_control (each member) */
 
 	/* VIDIOC_QUERYBUF, VIDIOC_QBUF, VIDIOC_DQBUF, VIDIOC_PREPARE_BUF */
 	{ _IOWR('V',  9, new_misaligned(68)), _IOWR('V',  9, char[68]), 68, WR, 1, OFFS(20, 24) },
@@ -90,7 +91,11 @@ static void convert_ioctl_struct(const struct ioctl_compat_map *map, char *old,
 		 * if another exception appears this needs changing. */
 		convert_ioctl_struct(map+1, old, new, dir);
 		convert_ioctl_struct(map+2, old+4, new+8, dir);
-		convert_ioctl_struct(map+3, old+68, new+72, dir);
+		/* snd_pcm_mmap_control, special-cased due to kernel
+		 * type definition having been botched. */
+		int adj = BYTE_ORDER==BIG_ENDIAN ? 4 : 0;
+		convert_ioctl_struct(map+3, old+68, new+72+adj, dir);
+		convert_ioctl_struct(map+3, old+72, new+76+3*adj, dir);
 		return;
 	}
 	for (int i=0; i < map->noffs; i++) {

  reply	other threads:[~2021-10-19 14:16 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-11 21:20 [PATCH v7 0/8] Fix year 2038 issue for sound subsystem Arnd Bergmann
2019-12-11 21:20 ` [alsa-devel] " Arnd Bergmann
2019-12-11 21:20 ` [PATCH v7 1/9] ALSA: Replace timespec with timespec64 Arnd Bergmann
2019-12-11 21:20   ` [alsa-devel] " Arnd Bergmann
2019-12-11 21:20 ` [PATCH v7 2/9] ALSA: Avoid using timespec for struct snd_timer_status Arnd Bergmann
2019-12-11 21:20   ` [alsa-devel] " Arnd Bergmann
2019-12-11 21:20 ` [PATCH v7 3/9] ALSA: Avoid using timespec for struct snd_ctl_elem_value Arnd Bergmann
2019-12-11 21:20   ` [alsa-devel] " Arnd Bergmann
2019-12-11 21:20 ` [PATCH v7 4/9] ALSA: Avoid using timespec for struct snd_pcm_status Arnd Bergmann
2019-12-11 21:20   ` [alsa-devel] " Arnd Bergmann
2019-12-11 21:20 ` [PATCH v7 5/9] ALSA: Avoid using timespec for struct snd_rawmidi_status Arnd Bergmann
2019-12-11 21:20   ` [alsa-devel] " Arnd Bergmann
2019-12-11 21:20 ` [PATCH v7 6/9] ALSA: Avoid using timespec for struct snd_timer_tread Arnd Bergmann
2019-12-11 21:20   ` [alsa-devel] " Arnd Bergmann
2019-12-12  0:14   ` [Y2038] " Ben Hutchings
2019-12-12  0:14     ` [alsa-devel] " Ben Hutchings
2019-12-12  9:57     ` Arnd Bergmann
2019-12-12  9:57       ` [alsa-devel] " Arnd Bergmann
2019-12-12 14:27       ` Ben Hutchings
2019-12-12 14:27         ` [alsa-devel] " Ben Hutchings
2019-12-13 10:25         ` Arnd Bergmann
2019-12-13 10:25           ` [alsa-devel] " Arnd Bergmann
2019-12-11 21:20 ` [PATCH v7 7/9] ALSA: move snd_pcm_ioctl_sync_ptr_compat into pcm_native.c Arnd Bergmann
2019-12-11 21:20   ` [alsa-devel] " Arnd Bergmann
2019-12-11 21:20 ` [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control Arnd Bergmann
2019-12-11 21:20   ` [alsa-devel] " Arnd Bergmann
2021-10-06 17:49   ` Michael Forney
2021-10-06 17:49     ` Michael Forney
2021-10-07 10:52     ` Takashi Iwai
2021-10-07 10:52       ` Takashi Iwai
2021-10-07 11:48       ` Arnd Bergmann
2021-10-07 11:48         ` Arnd Bergmann
2021-10-07 12:43         ` Takashi Iwai
2021-10-07 12:43           ` Takashi Iwai
2021-10-07 13:02           ` Takashi Iwai
2021-10-07 13:02             ` Takashi Iwai
2021-10-07 13:11           ` Arnd Bergmann
2021-10-07 13:11             ` Arnd Bergmann
2021-10-07 15:33             ` Takashi Iwai
2021-10-07 15:33               ` Takashi Iwai
2021-10-07 16:06               ` [musl] " Rich Felker
2021-10-07 16:06                 ` Rich Felker
2021-10-07 16:18                 ` Takashi Iwai
2021-10-07 16:18                   ` Takashi Iwai
2021-10-07 16:51                   ` Rich Felker
2021-10-07 16:51                     ` Rich Felker
2021-10-08  8:43                     ` Takashi Iwai
2021-10-08  8:43                       ` Takashi Iwai
2021-10-08  8:44                       ` Takashi Iwai
2021-10-08  8:44                         ` Takashi Iwai
2021-10-08  9:24                       ` Arnd Bergmann
2021-10-08  9:24                         ` Arnd Bergmann
2021-10-08 11:11                         ` Takashi Iwai
2021-10-08 11:11                           ` Takashi Iwai
2021-10-08 11:45                           ` Arnd Bergmann
2021-10-08 11:45                             ` Arnd Bergmann
2021-10-08 11:53                             ` Takashi Iwai
2021-10-08 11:53                               ` Takashi Iwai
2021-10-08 12:13                               ` Arnd Bergmann
2021-10-08 12:13                                 ` Arnd Bergmann
2021-10-08 12:07                           ` Rich Felker
2021-10-08 12:07                             ` Rich Felker
2021-10-10  7:53                             ` Takashi Iwai
2021-10-10  7:53                               ` Takashi Iwai
2021-10-18 14:43                               ` Rich Felker
2021-10-18 14:43                                 ` Rich Felker
2021-10-18 14:58                                 ` Takashi Iwai
2021-10-18 14:58                                   ` Takashi Iwai
2021-10-18 15:08                                   ` Rich Felker
2021-10-18 15:08                                     ` Rich Felker
2021-10-18 15:26                                     ` Arnd Bergmann
2021-10-18 15:26                                       ` Arnd Bergmann
2021-10-18 20:42                                       ` Rich Felker
2021-10-18 20:42                                         ` Rich Felker
2021-10-19 14:16                                         ` Rich Felker [this message]
2021-10-19 14:16                                           ` Rich Felker
2021-10-19 14:23                                           ` Arnd Bergmann
2021-10-19 14:23                                             ` Arnd Bergmann
2021-10-08 12:06                         ` Rich Felker
2021-10-08 12:06                           ` Rich Felker
2021-10-08 12:37                           ` Arnd Bergmann
2021-10-08 12:37                             ` Arnd Bergmann
2021-10-08 17:20                             ` Rich Felker
2021-10-08 17:20                               ` Rich Felker
2019-12-11 21:20 ` [PATCH v7 9/9] ALSA: bump uapi version numbers Arnd Bergmann
2019-12-11 21:20   ` [alsa-devel] " Arnd Bergmann
2019-12-17 10:42 ` [PATCH v7 0/8] Fix year 2038 issue for sound subsystem Takashi Iwai
2019-12-17 10:42   ` [alsa-devel] " Takashi Iwai
2019-12-17 21:15   ` Arnd Bergmann
2019-12-17 21:15     ` [alsa-devel] " Arnd Bergmann
2019-12-17 21:16     ` [GIT PULL, v8] " Arnd Bergmann
2019-12-17 21:16       ` [alsa-devel] " Arnd Bergmann
2019-12-17 22:22     ` [PATCH v7 0/8] " Takashi Iwai
2019-12-17 22:22       ` [alsa-devel] " 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=20211019141622.GN7074@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=arnd@arndb.de \
    --cc=baolin.wang7@gmail.com \
    --cc=baolin.wang@linaro.org \
    --cc=broonie@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mforney@mforney.org \
    --cc=musl@lists.openwall.com \
    --cc=tiwai@suse.com \
    --cc=tiwai@suse.de \
    --cc=y2038@lists.linaro.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.