* [alsa-devel] [PATCH v7 0/8] Fix year 2038 issue for sound subsystem
@ 2019-12-11 21:20 ` Arnd Bergmann
0 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-11 21:20 UTC (permalink / raw)
To: alsa-devel, Takashi Iwai
Cc: Arnd Bergmann, y2038, linux-kernel, Mark Brown, Baolin Wang
This is a series I worked on with Baolin in 2017 and 2018, but we
never quite managed to finish up the last pieces. During the
ALSA developer meetup at ELC-E 2018 in Edinburgh, a decision was
made to go with this approach for keeping best compatibility
with existing source code, and then I failed to follow up by
resending the patches.
Now I have patches for all remaining time_t uses in the kernel,
so it's absolutely time to revisit them. I have done more
review of the patches myself and found a couple of minor issues
that I have fixed up, otherwise the series is still the same as
before.
Conceptually, the idea of these patches is:
- 64-bit applications should see no changes at all, neither
compile-time nor run-time.
- 32-bit code compiled with a 64-bit time_t currently
does not work with ALSA, and requires kernel changes and/or
sound/asound.h changes
- Most 32-bit code using these interfaces will work correctly
on a modified kernel, with or without the uapi header changes.
- 32-bit code using SNDRV_TIMER_IOCTL_TREAD requires the
updated header file for 64-bit time_t support
- 32-bit i386 user space with 64-bit time_t is broken for
SNDRV_PCM_IOCTL_STATUS, SNDRV_RAWMIDI_IOCTL_STATUS and
SNDRV_PCM_IOCTL_SYNC_PTR because of i386 alignment. This is also
addressed by the updated uapi header.
- PCM mmap is currently supported on native x86 kernels
(both 32-bit and 64-bit) but not for compat mode. This series breaks
the 32-bit native mmap support for 32-bit time_t, but instead allows
it for 64-bit time_t on both native and compat kernels. This seems to
be the best trade-off, as mmap support is optional already, and most
32-bit code runs in compat mode anyway.
- I've tried to avoid breaking compilation of 32-bit code
as much as possible. Anything that does break however is likely code
that is already broken on 64-bit time_t and needs source changes to
fix them.
I hope I addressed all review comments by now, so please pull this
for linux-5.6.
A git branch with the same contents is available for testing at [1].
Arnd
[1] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git y2038-alsa-v7
[2] https://lore.kernel.org/lkml/CAK8P3a2Os66+iwQYf97qh05W2JP8rmWao8zmKoHiXqVHvyYAJA@mail.gmail.com/T/#m6519cb07cfda08adf1dedea6596bb98892b4d5dc
Changes since v6: (Arnd):
- Add a patch to update the API versions
- Hide a timespec reference in #ifndef __KERNEL__ to remove the
last reference to time_t
- Use a more readable way to do padding and describe it in the
changelog
- Rebase to linux-5.5-rc1, changing include/sound/soc-component.h
and sound/drivers/aloop.c as needed.
Changes since v5 (Arnd):
- Rebased to linux-5.4-rc4
- Updated to completely remove timespec and time_t references from alsa
- found and fixed a few bugs
Changes since v4 (Baolin):
- Add patch 5 to change trigger_tstamp member of struct snd_pcm_runtime.
- Add patch 8 to change internal timespec.
- Add more explanation in commit message.
- Use ktime_get_real_ts64() in patch 6.
- Split common code out into a separate function in patch 6.
- Fix tu->tread bug in patch 6 and remove #if __BITS_PER_LONG == 64 macro.
Changes since v3:
- Move struct snd_pcm_status32 to pcm.h file.
- Modify comments and commit message.
- Add new patch2 ~ patch6.
Changes since v2:
- Renamed all structures to make clear.
- Remove CONFIG_X86_X32 macro and introduced new compat_snd_pcm_status64_x86_32.
Changes since v1:
- Add one macro for struct snd_pcm_status_32 which only active in 32bits kernel.
- Convert pcm_compat.c to use struct snd_pcm_status_64.
- Convert pcm_native.c to use struct snd_pcm_status_64.
---
Arnd Bergmann (3):
ALSA: move snd_pcm_ioctl_sync_ptr_compat into pcm_native.c
ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
ALSA: bump uapi version numbers
Baolin Wang (6):
ALSA: Replace timespec with timespec64
ALSA: Avoid using timespec for struct snd_timer_status
ALSA: Avoid using timespec for struct snd_ctl_elem_value
ALSA: Avoid using timespec for struct snd_pcm_status
ALSA: Avoid using timespec for struct snd_rawmidi_status
ALSA: Avoid using timespec for struct snd_timer_tread
include/sound/pcm.h | 74 ++++++--
include/sound/soc-component.h | 4 +-
include/sound/timer.h | 4 +-
include/uapi/sound/asound.h | 145 +++++++++++++--
sound/core/pcm.c | 12 +-
sound/core/pcm_compat.c | 282 ++++++++----------------------
sound/core/pcm_lib.c | 38 ++--
sound/core/pcm_native.c | 226 +++++++++++++++++++++---
sound/core/rawmidi.c | 132 +++++++++++---
sound/core/rawmidi_compat.c | 87 +++------
sound/core/timer.c | 229 ++++++++++++++++++------
sound/core/timer_compat.c | 62 +------
sound/drivers/aloop.c | 2 +-
sound/pci/hda/hda_controller.c | 10 +-
sound/soc/intel/skylake/skl-pcm.c | 4 +-
15 files changed, 817 insertions(+), 494 deletions(-)
--
2.20.0
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v7 1/9] ALSA: Replace timespec with timespec64
2019-12-11 21:20 ` [alsa-devel] " Arnd Bergmann
@ 2019-12-11 21:20 ` Arnd Bergmann
-1 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-11 21:20 UTC (permalink / raw)
To: alsa-devel, Takashi Iwai
Cc: Baolin Wang, y2038, linux-kernel, Jaroslav Kysela, Mark Brown,
Baolin Wang, Arnd Bergmann
From: Baolin Wang <baolin.wang@linaro.org>
Since timespec is not year 2038 safe on 32bit system, and we need to
convert all timespec variables to timespec64 type for sound subsystem.
This patch is used to do preparation for following patches, that will
convert all structures defined in uapi/sound/asound.h to use 64-bit
time_t.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/sound/pcm.h | 18 ++++++++--------
include/sound/soc-component.h | 4 ++--
include/sound/timer.h | 4 ++--
sound/core/pcm_lib.c | 36 +++++++++++++++++++------------
sound/core/pcm_native.c | 12 +++++++----
sound/core/timer.c | 28 ++++++++++++------------
sound/drivers/aloop.c | 2 +-
sound/pci/hda/hda_controller.c | 10 ++++-----
sound/soc/intel/skylake/skl-pcm.c | 4 ++--
9 files changed, 65 insertions(+), 53 deletions(-)
diff --git a/include/sound/pcm.h b/include/sound/pcm.h
index 8a89fa6fdd5e..cb407fade933 100644
--- a/include/sound/pcm.h
+++ b/include/sound/pcm.h
@@ -62,7 +62,7 @@ struct snd_pcm_ops {
int (*sync_stop)(struct snd_pcm_substream *substream);
snd_pcm_uframes_t (*pointer)(struct snd_pcm_substream *substream);
int (*get_time_info)(struct snd_pcm_substream *substream,
- struct timespec *system_ts, struct timespec *audio_ts,
+ struct timespec64 *system_ts, struct timespec64 *audio_ts,
struct snd_pcm_audio_tstamp_config *audio_tstamp_config,
struct snd_pcm_audio_tstamp_report *audio_tstamp_report);
int (*fill_silence)(struct snd_pcm_substream *substream, int channel,
@@ -343,7 +343,7 @@ static inline void snd_pcm_pack_audio_tstamp_report(__u32 *data, __u32 *accuracy
struct snd_pcm_runtime {
/* -- Status -- */
struct snd_pcm_substream *trigger_master;
- struct timespec trigger_tstamp; /* trigger timestamp */
+ struct timespec64 trigger_tstamp; /* trigger timestamp */
bool trigger_tstamp_latched; /* trigger timestamp latched in low-level driver/hardware */
int overrange;
snd_pcm_uframes_t avail_max;
@@ -421,7 +421,7 @@ struct snd_pcm_runtime {
/* -- audio timestamp config -- */
struct snd_pcm_audio_tstamp_config audio_tstamp_config;
struct snd_pcm_audio_tstamp_report audio_tstamp_report;
- struct timespec driver_tstamp;
+ struct timespec64 driver_tstamp;
#if IS_ENABLED(CONFIG_SND_PCM_OSS)
/* -- OSS things -- */
@@ -1155,22 +1155,22 @@ static inline void snd_pcm_set_runtime_buffer(struct snd_pcm_substream *substrea
}
/**
- * snd_pcm_gettime - Fill the timespec depending on the timestamp mode
+ * snd_pcm_gettime - Fill the timespec64 depending on the timestamp mode
* @runtime: PCM runtime instance
- * @tv: timespec to fill
+ * @tv: timespec64 to fill
*/
static inline void snd_pcm_gettime(struct snd_pcm_runtime *runtime,
- struct timespec *tv)
+ struct timespec64 *tv)
{
switch (runtime->tstamp_type) {
case SNDRV_PCM_TSTAMP_TYPE_MONOTONIC:
- ktime_get_ts(tv);
+ ktime_get_ts64(tv);
break;
case SNDRV_PCM_TSTAMP_TYPE_MONOTONIC_RAW:
- getrawmonotonic(tv);
+ ktime_get_raw_ts64(tv);
break;
default:
- getnstimeofday(tv);
+ ktime_get_real_ts64(tv);
break;
}
}
diff --git a/include/sound/soc-component.h b/include/sound/soc-component.h
index 506f72a6b2c2..154d02fbbfed 100644
--- a/include/sound/soc-component.h
+++ b/include/sound/soc-component.h
@@ -93,8 +93,8 @@ struct snd_soc_component_driver {
snd_pcm_uframes_t (*pointer)(struct snd_soc_component *component,
struct snd_pcm_substream *substream);
int (*get_time_info)(struct snd_soc_component *component,
- struct snd_pcm_substream *substream, struct timespec *system_ts,
- struct timespec *audio_ts,
+ struct snd_pcm_substream *substream, struct timespec64 *system_ts,
+ struct timespec64 *audio_ts,
struct snd_pcm_audio_tstamp_config *audio_tstamp_config,
struct snd_pcm_audio_tstamp_report *audio_tstamp_report);
int (*copy_user)(struct snd_soc_component *component,
diff --git a/include/sound/timer.h b/include/sound/timer.h
index a53e37bcd746..23e885d31525 100644
--- a/include/sound/timer.h
+++ b/include/sound/timer.h
@@ -89,7 +89,7 @@ struct snd_timer_instance {
unsigned long ticks, unsigned long resolution);
void (*ccallback) (struct snd_timer_instance * timeri,
int event,
- struct timespec * tstamp,
+ struct timespec64 * tstamp,
unsigned long resolution);
void (*disconnect)(struct snd_timer_instance *timeri);
void *callback_data;
@@ -113,7 +113,7 @@ struct snd_timer_instance {
*/
int snd_timer_new(struct snd_card *card, char *id, struct snd_timer_id *tid, struct snd_timer **rtimer);
-void snd_timer_notify(struct snd_timer *timer, int event, struct timespec *tstamp);
+void snd_timer_notify(struct snd_timer *timer, int event, struct timespec64 *tstamp);
int snd_timer_global_new(char *id, int device, struct snd_timer **rtimer);
int snd_timer_global_free(struct snd_timer *timer);
int snd_timer_global_register(struct snd_timer *timer);
diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c
index 2236b5e0c1f2..ea5518d44e66 100644
--- a/sound/core/pcm_lib.c
+++ b/sound/core/pcm_lib.c
@@ -144,8 +144,12 @@ void __snd_pcm_xrun(struct snd_pcm_substream *substream)
struct snd_pcm_runtime *runtime = substream->runtime;
trace_xrun(substream);
- if (runtime->tstamp_mode == SNDRV_PCM_TSTAMP_ENABLE)
- snd_pcm_gettime(runtime, (struct timespec *)&runtime->status->tstamp);
+ if (runtime->tstamp_mode == SNDRV_PCM_TSTAMP_ENABLE) {
+ struct timespec64 tstamp;
+
+ snd_pcm_gettime(runtime, &tstamp);
+ runtime->status->tstamp = timespec64_to_timespec(tstamp);
+ }
snd_pcm_stop(substream, SNDRV_PCM_STATE_XRUN);
if (xrun_debug(substream, XRUN_DEBUG_BASIC)) {
char name[16];
@@ -200,12 +204,12 @@ int snd_pcm_update_state(struct snd_pcm_substream *substream,
}
static void update_audio_tstamp(struct snd_pcm_substream *substream,
- struct timespec *curr_tstamp,
- struct timespec *audio_tstamp)
+ struct timespec64 *curr_tstamp,
+ struct timespec64 *audio_tstamp)
{
struct snd_pcm_runtime *runtime = substream->runtime;
u64 audio_frames, audio_nsecs;
- struct timespec driver_tstamp;
+ struct timespec64 driver_tstamp;
if (runtime->tstamp_mode != SNDRV_PCM_TSTAMP_ENABLE)
return;
@@ -229,18 +233,22 @@ static void update_audio_tstamp(struct snd_pcm_substream *substream,
}
audio_nsecs = div_u64(audio_frames * 1000000000LL,
runtime->rate);
- *audio_tstamp = ns_to_timespec(audio_nsecs);
+ *audio_tstamp = ns_to_timespec64(audio_nsecs);
}
- if (!timespec_equal(&runtime->status->audio_tstamp, audio_tstamp)) {
- runtime->status->audio_tstamp = *audio_tstamp;
- runtime->status->tstamp = *curr_tstamp;
+
+ if (runtime->status->audio_tstamp.tv_sec != audio_tstamp->tv_sec ||
+ runtime->status->audio_tstamp.tv_nsec != audio_tstamp->tv_nsec) {
+ runtime->status->audio_tstamp =
+ timespec64_to_timespec(*audio_tstamp);
+ runtime->status->tstamp = timespec64_to_timespec(*curr_tstamp);
}
+
/*
* re-take a driver timestamp to let apps detect if the reference tstamp
* read by low-level hardware was provided with a delay
*/
- snd_pcm_gettime(substream->runtime, (struct timespec *)&driver_tstamp);
+ snd_pcm_gettime(substream->runtime, &driver_tstamp);
runtime->driver_tstamp = driver_tstamp;
}
@@ -253,8 +261,8 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream *substream,
snd_pcm_sframes_t hdelta, delta;
unsigned long jdelta;
unsigned long curr_jiffies;
- struct timespec curr_tstamp;
- struct timespec audio_tstamp;
+ struct timespec64 curr_tstamp;
+ struct timespec64 audio_tstamp;
int crossed_boundary = 0;
old_hw_ptr = runtime->status->hw_ptr;
@@ -277,9 +285,9 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream *substream,
/* re-test in case tstamp type is not supported in hardware and was demoted to DEFAULT */
if (runtime->audio_tstamp_report.actual_type == SNDRV_PCM_AUDIO_TSTAMP_TYPE_DEFAULT)
- snd_pcm_gettime(runtime, (struct timespec *)&curr_tstamp);
+ snd_pcm_gettime(runtime, &curr_tstamp);
} else
- snd_pcm_gettime(runtime, (struct timespec *)&curr_tstamp);
+ snd_pcm_gettime(runtime, &curr_tstamp);
}
if (pos == SNDRV_PCM_POS_XRUN) {
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index 1fe581167b7b..67fe14bad7cb 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -918,12 +918,12 @@ int snd_pcm_status(struct snd_pcm_substream *substream,
status->suspended_state = runtime->status->suspended_state;
if (status->state == SNDRV_PCM_STATE_OPEN)
goto _end;
- status->trigger_tstamp = runtime->trigger_tstamp;
+ status->trigger_tstamp = timespec64_to_timespec(runtime->trigger_tstamp);
if (snd_pcm_running(substream)) {
snd_pcm_update_hw_ptr(substream);
if (runtime->tstamp_mode == SNDRV_PCM_TSTAMP_ENABLE) {
status->tstamp = runtime->status->tstamp;
- status->driver_tstamp = runtime->driver_tstamp;
+ status->driver_tstamp = timespec64_to_timespec(runtime->driver_tstamp);
status->audio_tstamp =
runtime->status->audio_tstamp;
if (runtime->audio_tstamp_report.valid == 1)
@@ -936,8 +936,12 @@ int snd_pcm_status(struct snd_pcm_substream *substream,
}
} else {
/* get tstamp only in fallback mode and only if enabled */
- if (runtime->tstamp_mode == SNDRV_PCM_TSTAMP_ENABLE)
- snd_pcm_gettime(runtime, &status->tstamp);
+ if (runtime->tstamp_mode == SNDRV_PCM_TSTAMP_ENABLE) {
+ struct timespec64 tstamp;
+
+ snd_pcm_gettime(runtime, &tstamp);
+ status->tstamp = timespec64_to_timespec(tstamp);
+ }
}
_tstamp_end:
status->appl_ptr = runtime->control->appl_ptr;
diff --git a/sound/core/timer.c b/sound/core/timer.c
index 24fed5c78273..d808d5554c7a 100644
--- a/sound/core/timer.c
+++ b/sound/core/timer.c
@@ -59,7 +59,7 @@ struct snd_timer_user {
spinlock_t qlock;
unsigned long last_resolution;
unsigned int filter;
- struct timespec tstamp; /* trigger tstamp */
+ struct timespec64 tstamp; /* trigger tstamp */
wait_queue_head_t qchange_sleep;
struct fasync_struct *fasync;
struct mutex ioctl_lock;
@@ -453,12 +453,12 @@ static void snd_timer_notify1(struct snd_timer_instance *ti, int event)
struct snd_timer *timer = ti->timer;
unsigned long resolution = 0;
struct snd_timer_instance *ts;
- struct timespec tstamp;
+ struct timespec64 tstamp;
if (timer_tstamp_monotonic)
- ktime_get_ts(&tstamp);
+ ktime_get_ts64(&tstamp);
else
- getnstimeofday(&tstamp);
+ ktime_get_real_ts64(&tstamp);
if (snd_BUG_ON(event < SNDRV_TIMER_EVENT_START ||
event > SNDRV_TIMER_EVENT_PAUSE))
return;
@@ -1025,7 +1025,7 @@ static int snd_timer_dev_disconnect(struct snd_device *device)
return 0;
}
-void snd_timer_notify(struct snd_timer *timer, int event, struct timespec *tstamp)
+void snd_timer_notify(struct snd_timer *timer, int event, struct timespec64 *tstamp)
{
unsigned long flags;
unsigned long resolution = 0;
@@ -1318,7 +1318,7 @@ static void snd_timer_user_append_to_tqueue(struct snd_timer_user *tu,
static void snd_timer_user_ccallback(struct snd_timer_instance *timeri,
int event,
- struct timespec *tstamp,
+ struct timespec64 *tstamp,
unsigned long resolution)
{
struct snd_timer_user *tu = timeri->callback_data;
@@ -1332,7 +1332,7 @@ static void snd_timer_user_ccallback(struct snd_timer_instance *timeri,
return;
memset(&r1, 0, sizeof(r1));
r1.event = event;
- r1.tstamp = *tstamp;
+ r1.tstamp = timespec64_to_timespec(*tstamp);
r1.val = resolution;
spin_lock_irqsave(&tu->qlock, flags);
snd_timer_user_append_to_tqueue(tu, &r1);
@@ -1355,7 +1355,7 @@ static void snd_timer_user_tinterrupt(struct snd_timer_instance *timeri,
{
struct snd_timer_user *tu = timeri->callback_data;
struct snd_timer_tread *r, r1;
- struct timespec tstamp;
+ struct timespec64 tstamp;
int prev, append = 0;
memset(&r1, 0, sizeof(r1));
@@ -1368,14 +1368,14 @@ static void snd_timer_user_tinterrupt(struct snd_timer_instance *timeri,
}
if (tu->last_resolution != resolution || ticks > 0) {
if (timer_tstamp_monotonic)
- ktime_get_ts(&tstamp);
+ ktime_get_ts64(&tstamp);
else
- getnstimeofday(&tstamp);
+ ktime_get_real_ts64(&tstamp);
}
if ((tu->filter & (1 << SNDRV_TIMER_EVENT_RESOLUTION)) &&
tu->last_resolution != resolution) {
r1.event = SNDRV_TIMER_EVENT_RESOLUTION;
- r1.tstamp = tstamp;
+ r1.tstamp = timespec64_to_timespec(tstamp);
r1.val = resolution;
snd_timer_user_append_to_tqueue(tu, &r1);
tu->last_resolution = resolution;
@@ -1389,14 +1389,14 @@ static void snd_timer_user_tinterrupt(struct snd_timer_instance *timeri,
prev = tu->qtail == 0 ? tu->queue_size - 1 : tu->qtail - 1;
r = &tu->tqueue[prev];
if (r->event == SNDRV_TIMER_EVENT_TICK) {
- r->tstamp = tstamp;
+ r->tstamp = timespec64_to_timespec(tstamp);
r->val += ticks;
append++;
goto __wake;
}
}
r1.event = SNDRV_TIMER_EVENT_TICK;
- r1.tstamp = tstamp;
+ r1.tstamp = timespec64_to_timespec(tstamp);
r1.val = ticks;
snd_timer_user_append_to_tqueue(tu, &r1);
append++;
@@ -1885,7 +1885,7 @@ static int snd_timer_user_status(struct file *file,
if (!tu->timeri)
return -EBADFD;
memset(&status, 0, sizeof(status));
- status.tstamp = tu->tstamp;
+ status.tstamp = timespec64_to_timespec(tu->tstamp);
status.resolution = snd_timer_resolution(tu->timeri);
status.lost = tu->timeri->lost;
status.overrun = tu->overrun;
diff --git a/sound/drivers/aloop.c b/sound/drivers/aloop.c
index 6bb46423f5ae..bc83b1731541 100644
--- a/sound/drivers/aloop.c
+++ b/sound/drivers/aloop.c
@@ -804,7 +804,7 @@ static void loopback_snd_timer_tasklet(unsigned long arg)
static void loopback_snd_timer_event(struct snd_timer_instance *timeri,
int event,
- struct timespec *tstamp,
+ struct timespec64 *tstamp,
unsigned long resolution)
{
/* Do not lock cable->lock here because timer->lock is already hold.
diff --git a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c
index 2f3b7a35f2d9..e95c3ae7aa93 100644
--- a/sound/pci/hda/hda_controller.c
+++ b/sound/pci/hda/hda_controller.c
@@ -491,7 +491,7 @@ static inline bool is_link_time_supported(struct snd_pcm_runtime *runtime,
}
static int azx_get_time_info(struct snd_pcm_substream *substream,
- struct timespec *system_ts, struct timespec *audio_ts,
+ struct timespec64 *system_ts, struct timespec64 *audio_ts,
struct snd_pcm_audio_tstamp_config *audio_tstamp_config,
struct snd_pcm_audio_tstamp_report *audio_tstamp_report)
{
@@ -511,7 +511,7 @@ static int azx_get_time_info(struct snd_pcm_substream *substream,
if (audio_tstamp_config->report_delay)
nsec = azx_adjust_codec_delay(substream, nsec);
- *audio_ts = ns_to_timespec(nsec);
+ *audio_ts = ns_to_timespec64(nsec);
audio_tstamp_report->actual_type = SNDRV_PCM_AUDIO_TSTAMP_TYPE_LINK;
audio_tstamp_report->accuracy_report = 1; /* rest of structure is valid */
@@ -528,16 +528,16 @@ static int azx_get_time_info(struct snd_pcm_substream *substream,
return -EINVAL;
case SNDRV_PCM_TSTAMP_TYPE_MONOTONIC_RAW:
- *system_ts = ktime_to_timespec(xtstamp.sys_monoraw);
+ *system_ts = ktime_to_timespec64(xtstamp.sys_monoraw);
break;
default:
- *system_ts = ktime_to_timespec(xtstamp.sys_realtime);
+ *system_ts = ktime_to_timespec64(xtstamp.sys_realtime);
break;
}
- *audio_ts = ktime_to_timespec(xtstamp.device);
+ *audio_ts = ktime_to_timespec64(xtstamp.device);
audio_tstamp_report->actual_type =
SNDRV_PCM_AUDIO_TSTAMP_TYPE_LINK_SYNCHRONIZED;
diff --git a/sound/soc/intel/skylake/skl-pcm.c b/sound/soc/intel/skylake/skl-pcm.c
index 8b9abb79a69e..900746c30bff 100644
--- a/sound/soc/intel/skylake/skl-pcm.c
+++ b/sound/soc/intel/skylake/skl-pcm.c
@@ -1258,7 +1258,7 @@ static u64 skl_adjust_codec_delay(struct snd_pcm_substream *substream,
static int skl_platform_soc_get_time_info(
struct snd_soc_component *component,
struct snd_pcm_substream *substream,
- struct timespec *system_ts, struct timespec *audio_ts,
+ struct timespec64 *system_ts, struct timespec64 *audio_ts,
struct snd_pcm_audio_tstamp_config *audio_tstamp_config,
struct snd_pcm_audio_tstamp_report *audio_tstamp_report)
{
@@ -1276,7 +1276,7 @@ static int skl_platform_soc_get_time_info(
if (audio_tstamp_config->report_delay)
nsec = skl_adjust_codec_delay(substream, nsec);
- *audio_ts = ns_to_timespec(nsec);
+ *audio_ts = ns_to_timespec64(nsec);
audio_tstamp_report->actual_type = SNDRV_PCM_AUDIO_TSTAMP_TYPE_LINK;
audio_tstamp_report->accuracy_report = 1; /* rest of struct is valid */
--
2.20.0
^ permalink raw reply related [flat|nested] 94+ messages in thread* [alsa-devel] [PATCH v7 1/9] ALSA: Replace timespec with timespec64
@ 2019-12-11 21:20 ` Arnd Bergmann
0 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-11 21:20 UTC (permalink / raw)
To: alsa-devel, Takashi Iwai
Cc: Arnd Bergmann, Baolin Wang, y2038, linux-kernel, Mark Brown, Baolin Wang
From: Baolin Wang <baolin.wang@linaro.org>
Since timespec is not year 2038 safe on 32bit system, and we need to
convert all timespec variables to timespec64 type for sound subsystem.
This patch is used to do preparation for following patches, that will
convert all structures defined in uapi/sound/asound.h to use 64-bit
time_t.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/sound/pcm.h | 18 ++++++++--------
include/sound/soc-component.h | 4 ++--
include/sound/timer.h | 4 ++--
sound/core/pcm_lib.c | 36 +++++++++++++++++++------------
sound/core/pcm_native.c | 12 +++++++----
sound/core/timer.c | 28 ++++++++++++------------
sound/drivers/aloop.c | 2 +-
sound/pci/hda/hda_controller.c | 10 ++++-----
sound/soc/intel/skylake/skl-pcm.c | 4 ++--
9 files changed, 65 insertions(+), 53 deletions(-)
diff --git a/include/sound/pcm.h b/include/sound/pcm.h
index 8a89fa6fdd5e..cb407fade933 100644
--- a/include/sound/pcm.h
+++ b/include/sound/pcm.h
@@ -62,7 +62,7 @@ struct snd_pcm_ops {
int (*sync_stop)(struct snd_pcm_substream *substream);
snd_pcm_uframes_t (*pointer)(struct snd_pcm_substream *substream);
int (*get_time_info)(struct snd_pcm_substream *substream,
- struct timespec *system_ts, struct timespec *audio_ts,
+ struct timespec64 *system_ts, struct timespec64 *audio_ts,
struct snd_pcm_audio_tstamp_config *audio_tstamp_config,
struct snd_pcm_audio_tstamp_report *audio_tstamp_report);
int (*fill_silence)(struct snd_pcm_substream *substream, int channel,
@@ -343,7 +343,7 @@ static inline void snd_pcm_pack_audio_tstamp_report(__u32 *data, __u32 *accuracy
struct snd_pcm_runtime {
/* -- Status -- */
struct snd_pcm_substream *trigger_master;
- struct timespec trigger_tstamp; /* trigger timestamp */
+ struct timespec64 trigger_tstamp; /* trigger timestamp */
bool trigger_tstamp_latched; /* trigger timestamp latched in low-level driver/hardware */
int overrange;
snd_pcm_uframes_t avail_max;
@@ -421,7 +421,7 @@ struct snd_pcm_runtime {
/* -- audio timestamp config -- */
struct snd_pcm_audio_tstamp_config audio_tstamp_config;
struct snd_pcm_audio_tstamp_report audio_tstamp_report;
- struct timespec driver_tstamp;
+ struct timespec64 driver_tstamp;
#if IS_ENABLED(CONFIG_SND_PCM_OSS)
/* -- OSS things -- */
@@ -1155,22 +1155,22 @@ static inline void snd_pcm_set_runtime_buffer(struct snd_pcm_substream *substrea
}
/**
- * snd_pcm_gettime - Fill the timespec depending on the timestamp mode
+ * snd_pcm_gettime - Fill the timespec64 depending on the timestamp mode
* @runtime: PCM runtime instance
- * @tv: timespec to fill
+ * @tv: timespec64 to fill
*/
static inline void snd_pcm_gettime(struct snd_pcm_runtime *runtime,
- struct timespec *tv)
+ struct timespec64 *tv)
{
switch (runtime->tstamp_type) {
case SNDRV_PCM_TSTAMP_TYPE_MONOTONIC:
- ktime_get_ts(tv);
+ ktime_get_ts64(tv);
break;
case SNDRV_PCM_TSTAMP_TYPE_MONOTONIC_RAW:
- getrawmonotonic(tv);
+ ktime_get_raw_ts64(tv);
break;
default:
- getnstimeofday(tv);
+ ktime_get_real_ts64(tv);
break;
}
}
diff --git a/include/sound/soc-component.h b/include/sound/soc-component.h
index 506f72a6b2c2..154d02fbbfed 100644
--- a/include/sound/soc-component.h
+++ b/include/sound/soc-component.h
@@ -93,8 +93,8 @@ struct snd_soc_component_driver {
snd_pcm_uframes_t (*pointer)(struct snd_soc_component *component,
struct snd_pcm_substream *substream);
int (*get_time_info)(struct snd_soc_component *component,
- struct snd_pcm_substream *substream, struct timespec *system_ts,
- struct timespec *audio_ts,
+ struct snd_pcm_substream *substream, struct timespec64 *system_ts,
+ struct timespec64 *audio_ts,
struct snd_pcm_audio_tstamp_config *audio_tstamp_config,
struct snd_pcm_audio_tstamp_report *audio_tstamp_report);
int (*copy_user)(struct snd_soc_component *component,
diff --git a/include/sound/timer.h b/include/sound/timer.h
index a53e37bcd746..23e885d31525 100644
--- a/include/sound/timer.h
+++ b/include/sound/timer.h
@@ -89,7 +89,7 @@ struct snd_timer_instance {
unsigned long ticks, unsigned long resolution);
void (*ccallback) (struct snd_timer_instance * timeri,
int event,
- struct timespec * tstamp,
+ struct timespec64 * tstamp,
unsigned long resolution);
void (*disconnect)(struct snd_timer_instance *timeri);
void *callback_data;
@@ -113,7 +113,7 @@ struct snd_timer_instance {
*/
int snd_timer_new(struct snd_card *card, char *id, struct snd_timer_id *tid, struct snd_timer **rtimer);
-void snd_timer_notify(struct snd_timer *timer, int event, struct timespec *tstamp);
+void snd_timer_notify(struct snd_timer *timer, int event, struct timespec64 *tstamp);
int snd_timer_global_new(char *id, int device, struct snd_timer **rtimer);
int snd_timer_global_free(struct snd_timer *timer);
int snd_timer_global_register(struct snd_timer *timer);
diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c
index 2236b5e0c1f2..ea5518d44e66 100644
--- a/sound/core/pcm_lib.c
+++ b/sound/core/pcm_lib.c
@@ -144,8 +144,12 @@ void __snd_pcm_xrun(struct snd_pcm_substream *substream)
struct snd_pcm_runtime *runtime = substream->runtime;
trace_xrun(substream);
- if (runtime->tstamp_mode == SNDRV_PCM_TSTAMP_ENABLE)
- snd_pcm_gettime(runtime, (struct timespec *)&runtime->status->tstamp);
+ if (runtime->tstamp_mode == SNDRV_PCM_TSTAMP_ENABLE) {
+ struct timespec64 tstamp;
+
+ snd_pcm_gettime(runtime, &tstamp);
+ runtime->status->tstamp = timespec64_to_timespec(tstamp);
+ }
snd_pcm_stop(substream, SNDRV_PCM_STATE_XRUN);
if (xrun_debug(substream, XRUN_DEBUG_BASIC)) {
char name[16];
@@ -200,12 +204,12 @@ int snd_pcm_update_state(struct snd_pcm_substream *substream,
}
static void update_audio_tstamp(struct snd_pcm_substream *substream,
- struct timespec *curr_tstamp,
- struct timespec *audio_tstamp)
+ struct timespec64 *curr_tstamp,
+ struct timespec64 *audio_tstamp)
{
struct snd_pcm_runtime *runtime = substream->runtime;
u64 audio_frames, audio_nsecs;
- struct timespec driver_tstamp;
+ struct timespec64 driver_tstamp;
if (runtime->tstamp_mode != SNDRV_PCM_TSTAMP_ENABLE)
return;
@@ -229,18 +233,22 @@ static void update_audio_tstamp(struct snd_pcm_substream *substream,
}
audio_nsecs = div_u64(audio_frames * 1000000000LL,
runtime->rate);
- *audio_tstamp = ns_to_timespec(audio_nsecs);
+ *audio_tstamp = ns_to_timespec64(audio_nsecs);
}
- if (!timespec_equal(&runtime->status->audio_tstamp, audio_tstamp)) {
- runtime->status->audio_tstamp = *audio_tstamp;
- runtime->status->tstamp = *curr_tstamp;
+
+ if (runtime->status->audio_tstamp.tv_sec != audio_tstamp->tv_sec ||
+ runtime->status->audio_tstamp.tv_nsec != audio_tstamp->tv_nsec) {
+ runtime->status->audio_tstamp =
+ timespec64_to_timespec(*audio_tstamp);
+ runtime->status->tstamp = timespec64_to_timespec(*curr_tstamp);
}
+
/*
* re-take a driver timestamp to let apps detect if the reference tstamp
* read by low-level hardware was provided with a delay
*/
- snd_pcm_gettime(substream->runtime, (struct timespec *)&driver_tstamp);
+ snd_pcm_gettime(substream->runtime, &driver_tstamp);
runtime->driver_tstamp = driver_tstamp;
}
@@ -253,8 +261,8 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream *substream,
snd_pcm_sframes_t hdelta, delta;
unsigned long jdelta;
unsigned long curr_jiffies;
- struct timespec curr_tstamp;
- struct timespec audio_tstamp;
+ struct timespec64 curr_tstamp;
+ struct timespec64 audio_tstamp;
int crossed_boundary = 0;
old_hw_ptr = runtime->status->hw_ptr;
@@ -277,9 +285,9 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream *substream,
/* re-test in case tstamp type is not supported in hardware and was demoted to DEFAULT */
if (runtime->audio_tstamp_report.actual_type == SNDRV_PCM_AUDIO_TSTAMP_TYPE_DEFAULT)
- snd_pcm_gettime(runtime, (struct timespec *)&curr_tstamp);
+ snd_pcm_gettime(runtime, &curr_tstamp);
} else
- snd_pcm_gettime(runtime, (struct timespec *)&curr_tstamp);
+ snd_pcm_gettime(runtime, &curr_tstamp);
}
if (pos == SNDRV_PCM_POS_XRUN) {
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index 1fe581167b7b..67fe14bad7cb 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -918,12 +918,12 @@ int snd_pcm_status(struct snd_pcm_substream *substream,
status->suspended_state = runtime->status->suspended_state;
if (status->state == SNDRV_PCM_STATE_OPEN)
goto _end;
- status->trigger_tstamp = runtime->trigger_tstamp;
+ status->trigger_tstamp = timespec64_to_timespec(runtime->trigger_tstamp);
if (snd_pcm_running(substream)) {
snd_pcm_update_hw_ptr(substream);
if (runtime->tstamp_mode == SNDRV_PCM_TSTAMP_ENABLE) {
status->tstamp = runtime->status->tstamp;
- status->driver_tstamp = runtime->driver_tstamp;
+ status->driver_tstamp = timespec64_to_timespec(runtime->driver_tstamp);
status->audio_tstamp =
runtime->status->audio_tstamp;
if (runtime->audio_tstamp_report.valid == 1)
@@ -936,8 +936,12 @@ int snd_pcm_status(struct snd_pcm_substream *substream,
}
} else {
/* get tstamp only in fallback mode and only if enabled */
- if (runtime->tstamp_mode == SNDRV_PCM_TSTAMP_ENABLE)
- snd_pcm_gettime(runtime, &status->tstamp);
+ if (runtime->tstamp_mode == SNDRV_PCM_TSTAMP_ENABLE) {
+ struct timespec64 tstamp;
+
+ snd_pcm_gettime(runtime, &tstamp);
+ status->tstamp = timespec64_to_timespec(tstamp);
+ }
}
_tstamp_end:
status->appl_ptr = runtime->control->appl_ptr;
diff --git a/sound/core/timer.c b/sound/core/timer.c
index 24fed5c78273..d808d5554c7a 100644
--- a/sound/core/timer.c
+++ b/sound/core/timer.c
@@ -59,7 +59,7 @@ struct snd_timer_user {
spinlock_t qlock;
unsigned long last_resolution;
unsigned int filter;
- struct timespec tstamp; /* trigger tstamp */
+ struct timespec64 tstamp; /* trigger tstamp */
wait_queue_head_t qchange_sleep;
struct fasync_struct *fasync;
struct mutex ioctl_lock;
@@ -453,12 +453,12 @@ static void snd_timer_notify1(struct snd_timer_instance *ti, int event)
struct snd_timer *timer = ti->timer;
unsigned long resolution = 0;
struct snd_timer_instance *ts;
- struct timespec tstamp;
+ struct timespec64 tstamp;
if (timer_tstamp_monotonic)
- ktime_get_ts(&tstamp);
+ ktime_get_ts64(&tstamp);
else
- getnstimeofday(&tstamp);
+ ktime_get_real_ts64(&tstamp);
if (snd_BUG_ON(event < SNDRV_TIMER_EVENT_START ||
event > SNDRV_TIMER_EVENT_PAUSE))
return;
@@ -1025,7 +1025,7 @@ static int snd_timer_dev_disconnect(struct snd_device *device)
return 0;
}
-void snd_timer_notify(struct snd_timer *timer, int event, struct timespec *tstamp)
+void snd_timer_notify(struct snd_timer *timer, int event, struct timespec64 *tstamp)
{
unsigned long flags;
unsigned long resolution = 0;
@@ -1318,7 +1318,7 @@ static void snd_timer_user_append_to_tqueue(struct snd_timer_user *tu,
static void snd_timer_user_ccallback(struct snd_timer_instance *timeri,
int event,
- struct timespec *tstamp,
+ struct timespec64 *tstamp,
unsigned long resolution)
{
struct snd_timer_user *tu = timeri->callback_data;
@@ -1332,7 +1332,7 @@ static void snd_timer_user_ccallback(struct snd_timer_instance *timeri,
return;
memset(&r1, 0, sizeof(r1));
r1.event = event;
- r1.tstamp = *tstamp;
+ r1.tstamp = timespec64_to_timespec(*tstamp);
r1.val = resolution;
spin_lock_irqsave(&tu->qlock, flags);
snd_timer_user_append_to_tqueue(tu, &r1);
@@ -1355,7 +1355,7 @@ static void snd_timer_user_tinterrupt(struct snd_timer_instance *timeri,
{
struct snd_timer_user *tu = timeri->callback_data;
struct snd_timer_tread *r, r1;
- struct timespec tstamp;
+ struct timespec64 tstamp;
int prev, append = 0;
memset(&r1, 0, sizeof(r1));
@@ -1368,14 +1368,14 @@ static void snd_timer_user_tinterrupt(struct snd_timer_instance *timeri,
}
if (tu->last_resolution != resolution || ticks > 0) {
if (timer_tstamp_monotonic)
- ktime_get_ts(&tstamp);
+ ktime_get_ts64(&tstamp);
else
- getnstimeofday(&tstamp);
+ ktime_get_real_ts64(&tstamp);
}
if ((tu->filter & (1 << SNDRV_TIMER_EVENT_RESOLUTION)) &&
tu->last_resolution != resolution) {
r1.event = SNDRV_TIMER_EVENT_RESOLUTION;
- r1.tstamp = tstamp;
+ r1.tstamp = timespec64_to_timespec(tstamp);
r1.val = resolution;
snd_timer_user_append_to_tqueue(tu, &r1);
tu->last_resolution = resolution;
@@ -1389,14 +1389,14 @@ static void snd_timer_user_tinterrupt(struct snd_timer_instance *timeri,
prev = tu->qtail == 0 ? tu->queue_size - 1 : tu->qtail - 1;
r = &tu->tqueue[prev];
if (r->event == SNDRV_TIMER_EVENT_TICK) {
- r->tstamp = tstamp;
+ r->tstamp = timespec64_to_timespec(tstamp);
r->val += ticks;
append++;
goto __wake;
}
}
r1.event = SNDRV_TIMER_EVENT_TICK;
- r1.tstamp = tstamp;
+ r1.tstamp = timespec64_to_timespec(tstamp);
r1.val = ticks;
snd_timer_user_append_to_tqueue(tu, &r1);
append++;
@@ -1885,7 +1885,7 @@ static int snd_timer_user_status(struct file *file,
if (!tu->timeri)
return -EBADFD;
memset(&status, 0, sizeof(status));
- status.tstamp = tu->tstamp;
+ status.tstamp = timespec64_to_timespec(tu->tstamp);
status.resolution = snd_timer_resolution(tu->timeri);
status.lost = tu->timeri->lost;
status.overrun = tu->overrun;
diff --git a/sound/drivers/aloop.c b/sound/drivers/aloop.c
index 6bb46423f5ae..bc83b1731541 100644
--- a/sound/drivers/aloop.c
+++ b/sound/drivers/aloop.c
@@ -804,7 +804,7 @@ static void loopback_snd_timer_tasklet(unsigned long arg)
static void loopback_snd_timer_event(struct snd_timer_instance *timeri,
int event,
- struct timespec *tstamp,
+ struct timespec64 *tstamp,
unsigned long resolution)
{
/* Do not lock cable->lock here because timer->lock is already hold.
diff --git a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c
index 2f3b7a35f2d9..e95c3ae7aa93 100644
--- a/sound/pci/hda/hda_controller.c
+++ b/sound/pci/hda/hda_controller.c
@@ -491,7 +491,7 @@ static inline bool is_link_time_supported(struct snd_pcm_runtime *runtime,
}
static int azx_get_time_info(struct snd_pcm_substream *substream,
- struct timespec *system_ts, struct timespec *audio_ts,
+ struct timespec64 *system_ts, struct timespec64 *audio_ts,
struct snd_pcm_audio_tstamp_config *audio_tstamp_config,
struct snd_pcm_audio_tstamp_report *audio_tstamp_report)
{
@@ -511,7 +511,7 @@ static int azx_get_time_info(struct snd_pcm_substream *substream,
if (audio_tstamp_config->report_delay)
nsec = azx_adjust_codec_delay(substream, nsec);
- *audio_ts = ns_to_timespec(nsec);
+ *audio_ts = ns_to_timespec64(nsec);
audio_tstamp_report->actual_type = SNDRV_PCM_AUDIO_TSTAMP_TYPE_LINK;
audio_tstamp_report->accuracy_report = 1; /* rest of structure is valid */
@@ -528,16 +528,16 @@ static int azx_get_time_info(struct snd_pcm_substream *substream,
return -EINVAL;
case SNDRV_PCM_TSTAMP_TYPE_MONOTONIC_RAW:
- *system_ts = ktime_to_timespec(xtstamp.sys_monoraw);
+ *system_ts = ktime_to_timespec64(xtstamp.sys_monoraw);
break;
default:
- *system_ts = ktime_to_timespec(xtstamp.sys_realtime);
+ *system_ts = ktime_to_timespec64(xtstamp.sys_realtime);
break;
}
- *audio_ts = ktime_to_timespec(xtstamp.device);
+ *audio_ts = ktime_to_timespec64(xtstamp.device);
audio_tstamp_report->actual_type =
SNDRV_PCM_AUDIO_TSTAMP_TYPE_LINK_SYNCHRONIZED;
diff --git a/sound/soc/intel/skylake/skl-pcm.c b/sound/soc/intel/skylake/skl-pcm.c
index 8b9abb79a69e..900746c30bff 100644
--- a/sound/soc/intel/skylake/skl-pcm.c
+++ b/sound/soc/intel/skylake/skl-pcm.c
@@ -1258,7 +1258,7 @@ static u64 skl_adjust_codec_delay(struct snd_pcm_substream *substream,
static int skl_platform_soc_get_time_info(
struct snd_soc_component *component,
struct snd_pcm_substream *substream,
- struct timespec *system_ts, struct timespec *audio_ts,
+ struct timespec64 *system_ts, struct timespec64 *audio_ts,
struct snd_pcm_audio_tstamp_config *audio_tstamp_config,
struct snd_pcm_audio_tstamp_report *audio_tstamp_report)
{
@@ -1276,7 +1276,7 @@ static int skl_platform_soc_get_time_info(
if (audio_tstamp_config->report_delay)
nsec = skl_adjust_codec_delay(substream, nsec);
- *audio_ts = ns_to_timespec(nsec);
+ *audio_ts = ns_to_timespec64(nsec);
audio_tstamp_report->actual_type = SNDRV_PCM_AUDIO_TSTAMP_TYPE_LINK;
audio_tstamp_report->accuracy_report = 1; /* rest of struct is valid */
--
2.20.0
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH v7 2/9] ALSA: Avoid using timespec for struct snd_timer_status
2019-12-11 21:20 ` [alsa-devel] " Arnd Bergmann
@ 2019-12-11 21:20 ` Arnd Bergmann
-1 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-11 21:20 UTC (permalink / raw)
To: alsa-devel, Takashi Iwai
Cc: Baolin Wang, y2038, linux-kernel, Jaroslav Kysela, Mark Brown,
Baolin Wang, Arnd Bergmann
From: Baolin Wang <baolin.wang@linaro.org>
struct snd_timer_status uses 'timespec' type variables to record
timestamp, which will be changed to an incompatible layout with
updated user space using 64-bit time_t.
To handle both the old and the new layout on 32-bit architectures,
this patch introduces 'struct snd_timer_status32' and 'struct snd_timer_status64'
to handle 32bit time_t and 64bit time_t in native mode and compat mode,
which replaces timespec with s64 type.
When glibc changes time_t to 64-bit, any recompiled program will issue
ioctl commands that the kernel does not understand without this patch.
In the public uapi header, snd_timer_status is now guarded by
an #ifndef __KERNEL__ to avoid referencing 'struct timespec'.
The timespec definition will be removed from the kernel to prevent
new y2038 bugs and to avoid the conflict with an incompatible libc
type of the same name.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/uapi/sound/asound.h | 2 ++
sound/core/timer.c | 62 +++++++++++++++++++++++++++++++++----
sound/core/timer_compat.c | 57 ++++------------------------------
3 files changed, 64 insertions(+), 57 deletions(-)
diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
index df1153cea0b7..930854f67fd3 100644
--- a/include/uapi/sound/asound.h
+++ b/include/uapi/sound/asound.h
@@ -761,6 +761,7 @@ struct snd_timer_params {
unsigned char reserved[60]; /* reserved */
};
+#ifndef __KERNEL__
struct snd_timer_status {
struct timespec tstamp; /* Timestamp - last update */
unsigned int resolution; /* current period resolution in ns */
@@ -769,6 +770,7 @@ struct snd_timer_status {
unsigned int queue; /* used queue size */
unsigned char reserved[64]; /* reserved */
};
+#endif
#define SNDRV_TIMER_IOCTL_PVERSION _IOR('T', 0x00, int)
#define SNDRV_TIMER_IOCTL_NEXT_DEVICE _IOWR('T', 0x01, struct snd_timer_id)
diff --git a/sound/core/timer.c b/sound/core/timer.c
index d808d5554c7a..d2f69039f941 100644
--- a/sound/core/timer.c
+++ b/sound/core/timer.c
@@ -65,6 +65,30 @@ struct snd_timer_user {
struct mutex ioctl_lock;
};
+struct snd_timer_status32 {
+ s32 tstamp_sec; /* Timestamp - last update */
+ s32 tstamp_nsec;
+ unsigned int resolution; /* current period resolution in ns */
+ unsigned int lost; /* counter of master tick lost */
+ unsigned int overrun; /* count of read queue overruns */
+ unsigned int queue; /* used queue size */
+ unsigned char reserved[64]; /* reserved */
+};
+
+#define SNDRV_TIMER_IOCTL_STATUS32 _IOR('T', 0x14, struct snd_timer_status32)
+
+struct snd_timer_status64 {
+ s64 tstamp_sec; /* Timestamp - last update */
+ s64 tstamp_nsec;
+ unsigned int resolution; /* current period resolution in ns */
+ unsigned int lost; /* counter of master tick lost */
+ unsigned int overrun; /* count of read queue overruns */
+ unsigned int queue; /* used queue size */
+ unsigned char reserved[64]; /* reserved */
+};
+
+#define SNDRV_TIMER_IOCTL_STATUS64 _IOR('T', 0x14, struct snd_timer_status64)
+
/* list of timers */
static LIST_HEAD(snd_timer_list);
@@ -1875,17 +1899,41 @@ static int snd_timer_user_params(struct file *file,
return err;
}
-static int snd_timer_user_status(struct file *file,
- struct snd_timer_status __user *_status)
+static int snd_timer_user_status32(struct file *file,
+ struct snd_timer_status32 __user *_status)
+ {
+ struct snd_timer_user *tu;
+ struct snd_timer_status32 status;
+
+ tu = file->private_data;
+ if (!tu->timeri)
+ return -EBADFD;
+ memset(&status, 0, sizeof(status));
+ status.tstamp_sec = tu->tstamp.tv_sec;
+ status.tstamp_nsec = tu->tstamp.tv_nsec;
+ status.resolution = snd_timer_resolution(tu->timeri);
+ status.lost = tu->timeri->lost;
+ status.overrun = tu->overrun;
+ spin_lock_irq(&tu->qlock);
+ status.queue = tu->qused;
+ spin_unlock_irq(&tu->qlock);
+ if (copy_to_user(_status, &status, sizeof(status)))
+ return -EFAULT;
+ return 0;
+}
+
+static int snd_timer_user_status64(struct file *file,
+ struct snd_timer_status64 __user *_status)
{
struct snd_timer_user *tu;
- struct snd_timer_status status;
+ struct snd_timer_status64 status;
tu = file->private_data;
if (!tu->timeri)
return -EBADFD;
memset(&status, 0, sizeof(status));
- status.tstamp = timespec64_to_timespec(tu->tstamp);
+ status.tstamp_sec = tu->tstamp.tv_sec;
+ status.tstamp_nsec = tu->tstamp.tv_nsec;
status.resolution = snd_timer_resolution(tu->timeri);
status.lost = tu->timeri->lost;
status.overrun = tu->overrun;
@@ -2009,8 +2057,10 @@ static long __snd_timer_user_ioctl(struct file *file, unsigned int cmd,
return snd_timer_user_info(file, argp);
case SNDRV_TIMER_IOCTL_PARAMS:
return snd_timer_user_params(file, argp);
- case SNDRV_TIMER_IOCTL_STATUS:
- return snd_timer_user_status(file, argp);
+ case SNDRV_TIMER_IOCTL_STATUS32:
+ return snd_timer_user_status32(file, argp);
+ case SNDRV_TIMER_IOCTL_STATUS64:
+ return snd_timer_user_status64(file, argp);
case SNDRV_TIMER_IOCTL_START:
case SNDRV_TIMER_IOCTL_START_OLD:
return snd_timer_user_start(file);
diff --git a/sound/core/timer_compat.c b/sound/core/timer_compat.c
index bb6be484dfd3..20eef5bc304b 100644
--- a/sound/core/timer_compat.c
+++ b/sound/core/timer_compat.c
@@ -69,54 +69,11 @@ static int snd_timer_user_info_compat(struct file *file,
return 0;
}
-struct snd_timer_status32 {
- struct compat_timespec tstamp;
- u32 resolution;
- u32 lost;
- u32 overrun;
- u32 queue;
- unsigned char reserved[64];
-};
-
-static int snd_timer_user_status_compat(struct file *file,
- struct snd_timer_status32 __user *_status)
-{
- struct snd_timer_user *tu;
- struct snd_timer_status32 status;
-
- tu = file->private_data;
- if (!tu->timeri)
- return -EBADFD;
- memset(&status, 0, sizeof(status));
- status.tstamp.tv_sec = tu->tstamp.tv_sec;
- status.tstamp.tv_nsec = tu->tstamp.tv_nsec;
- status.resolution = snd_timer_resolution(tu->timeri);
- status.lost = tu->timeri->lost;
- status.overrun = tu->overrun;
- spin_lock_irq(&tu->qlock);
- status.queue = tu->qused;
- spin_unlock_irq(&tu->qlock);
- if (copy_to_user(_status, &status, sizeof(status)))
- return -EFAULT;
- return 0;
-}
-
-#ifdef CONFIG_X86_X32
-/* X32 ABI has the same struct as x86-64 */
-#define snd_timer_user_status_x32(file, s) \
- snd_timer_user_status(file, s)
-#endif /* CONFIG_X86_X32 */
-
-/*
- */
-
enum {
SNDRV_TIMER_IOCTL_GPARAMS32 = _IOW('T', 0x04, struct snd_timer_gparams32),
SNDRV_TIMER_IOCTL_INFO32 = _IOR('T', 0x11, struct snd_timer_info32),
- SNDRV_TIMER_IOCTL_STATUS32 = _IOW('T', 0x14, struct snd_timer_status32),
-#ifdef CONFIG_X86_X32
- SNDRV_TIMER_IOCTL_STATUS_X32 = _IOW('T', 0x14, struct snd_timer_status),
-#endif /* CONFIG_X86_X32 */
+ SNDRV_TIMER_IOCTL_STATUS_COMPAT32 = _IOW('T', 0x14, struct snd_timer_status32),
+ SNDRV_TIMER_IOCTL_STATUS_COMPAT64 = _IOW('T', 0x14, struct snd_timer_status64),
};
static long __snd_timer_user_ioctl_compat(struct file *file, unsigned int cmd,
@@ -145,12 +102,10 @@ static long __snd_timer_user_ioctl_compat(struct file *file, unsigned int cmd,
return snd_timer_user_gparams_compat(file, argp);
case SNDRV_TIMER_IOCTL_INFO32:
return snd_timer_user_info_compat(file, argp);
- case SNDRV_TIMER_IOCTL_STATUS32:
- return snd_timer_user_status_compat(file, argp);
-#ifdef CONFIG_X86_X32
- case SNDRV_TIMER_IOCTL_STATUS_X32:
- return snd_timer_user_status_x32(file, argp);
-#endif /* CONFIG_X86_X32 */
+ case SNDRV_TIMER_IOCTL_STATUS_COMPAT32:
+ return snd_timer_user_status32(file, argp);
+ case SNDRV_TIMER_IOCTL_STATUS_COMPAT64:
+ return snd_timer_user_status64(file, argp);
}
return -ENOIOCTLCMD;
}
--
2.20.0
^ permalink raw reply related [flat|nested] 94+ messages in thread* [alsa-devel] [PATCH v7 2/9] ALSA: Avoid using timespec for struct snd_timer_status
@ 2019-12-11 21:20 ` Arnd Bergmann
0 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-11 21:20 UTC (permalink / raw)
To: alsa-devel, Takashi Iwai
Cc: Arnd Bergmann, Baolin Wang, y2038, linux-kernel, Mark Brown, Baolin Wang
From: Baolin Wang <baolin.wang@linaro.org>
struct snd_timer_status uses 'timespec' type variables to record
timestamp, which will be changed to an incompatible layout with
updated user space using 64-bit time_t.
To handle both the old and the new layout on 32-bit architectures,
this patch introduces 'struct snd_timer_status32' and 'struct snd_timer_status64'
to handle 32bit time_t and 64bit time_t in native mode and compat mode,
which replaces timespec with s64 type.
When glibc changes time_t to 64-bit, any recompiled program will issue
ioctl commands that the kernel does not understand without this patch.
In the public uapi header, snd_timer_status is now guarded by
an #ifndef __KERNEL__ to avoid referencing 'struct timespec'.
The timespec definition will be removed from the kernel to prevent
new y2038 bugs and to avoid the conflict with an incompatible libc
type of the same name.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/uapi/sound/asound.h | 2 ++
sound/core/timer.c | 62 +++++++++++++++++++++++++++++++++----
sound/core/timer_compat.c | 57 ++++------------------------------
3 files changed, 64 insertions(+), 57 deletions(-)
diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
index df1153cea0b7..930854f67fd3 100644
--- a/include/uapi/sound/asound.h
+++ b/include/uapi/sound/asound.h
@@ -761,6 +761,7 @@ struct snd_timer_params {
unsigned char reserved[60]; /* reserved */
};
+#ifndef __KERNEL__
struct snd_timer_status {
struct timespec tstamp; /* Timestamp - last update */
unsigned int resolution; /* current period resolution in ns */
@@ -769,6 +770,7 @@ struct snd_timer_status {
unsigned int queue; /* used queue size */
unsigned char reserved[64]; /* reserved */
};
+#endif
#define SNDRV_TIMER_IOCTL_PVERSION _IOR('T', 0x00, int)
#define SNDRV_TIMER_IOCTL_NEXT_DEVICE _IOWR('T', 0x01, struct snd_timer_id)
diff --git a/sound/core/timer.c b/sound/core/timer.c
index d808d5554c7a..d2f69039f941 100644
--- a/sound/core/timer.c
+++ b/sound/core/timer.c
@@ -65,6 +65,30 @@ struct snd_timer_user {
struct mutex ioctl_lock;
};
+struct snd_timer_status32 {
+ s32 tstamp_sec; /* Timestamp - last update */
+ s32 tstamp_nsec;
+ unsigned int resolution; /* current period resolution in ns */
+ unsigned int lost; /* counter of master tick lost */
+ unsigned int overrun; /* count of read queue overruns */
+ unsigned int queue; /* used queue size */
+ unsigned char reserved[64]; /* reserved */
+};
+
+#define SNDRV_TIMER_IOCTL_STATUS32 _IOR('T', 0x14, struct snd_timer_status32)
+
+struct snd_timer_status64 {
+ s64 tstamp_sec; /* Timestamp - last update */
+ s64 tstamp_nsec;
+ unsigned int resolution; /* current period resolution in ns */
+ unsigned int lost; /* counter of master tick lost */
+ unsigned int overrun; /* count of read queue overruns */
+ unsigned int queue; /* used queue size */
+ unsigned char reserved[64]; /* reserved */
+};
+
+#define SNDRV_TIMER_IOCTL_STATUS64 _IOR('T', 0x14, struct snd_timer_status64)
+
/* list of timers */
static LIST_HEAD(snd_timer_list);
@@ -1875,17 +1899,41 @@ static int snd_timer_user_params(struct file *file,
return err;
}
-static int snd_timer_user_status(struct file *file,
- struct snd_timer_status __user *_status)
+static int snd_timer_user_status32(struct file *file,
+ struct snd_timer_status32 __user *_status)
+ {
+ struct snd_timer_user *tu;
+ struct snd_timer_status32 status;
+
+ tu = file->private_data;
+ if (!tu->timeri)
+ return -EBADFD;
+ memset(&status, 0, sizeof(status));
+ status.tstamp_sec = tu->tstamp.tv_sec;
+ status.tstamp_nsec = tu->tstamp.tv_nsec;
+ status.resolution = snd_timer_resolution(tu->timeri);
+ status.lost = tu->timeri->lost;
+ status.overrun = tu->overrun;
+ spin_lock_irq(&tu->qlock);
+ status.queue = tu->qused;
+ spin_unlock_irq(&tu->qlock);
+ if (copy_to_user(_status, &status, sizeof(status)))
+ return -EFAULT;
+ return 0;
+}
+
+static int snd_timer_user_status64(struct file *file,
+ struct snd_timer_status64 __user *_status)
{
struct snd_timer_user *tu;
- struct snd_timer_status status;
+ struct snd_timer_status64 status;
tu = file->private_data;
if (!tu->timeri)
return -EBADFD;
memset(&status, 0, sizeof(status));
- status.tstamp = timespec64_to_timespec(tu->tstamp);
+ status.tstamp_sec = tu->tstamp.tv_sec;
+ status.tstamp_nsec = tu->tstamp.tv_nsec;
status.resolution = snd_timer_resolution(tu->timeri);
status.lost = tu->timeri->lost;
status.overrun = tu->overrun;
@@ -2009,8 +2057,10 @@ static long __snd_timer_user_ioctl(struct file *file, unsigned int cmd,
return snd_timer_user_info(file, argp);
case SNDRV_TIMER_IOCTL_PARAMS:
return snd_timer_user_params(file, argp);
- case SNDRV_TIMER_IOCTL_STATUS:
- return snd_timer_user_status(file, argp);
+ case SNDRV_TIMER_IOCTL_STATUS32:
+ return snd_timer_user_status32(file, argp);
+ case SNDRV_TIMER_IOCTL_STATUS64:
+ return snd_timer_user_status64(file, argp);
case SNDRV_TIMER_IOCTL_START:
case SNDRV_TIMER_IOCTL_START_OLD:
return snd_timer_user_start(file);
diff --git a/sound/core/timer_compat.c b/sound/core/timer_compat.c
index bb6be484dfd3..20eef5bc304b 100644
--- a/sound/core/timer_compat.c
+++ b/sound/core/timer_compat.c
@@ -69,54 +69,11 @@ static int snd_timer_user_info_compat(struct file *file,
return 0;
}
-struct snd_timer_status32 {
- struct compat_timespec tstamp;
- u32 resolution;
- u32 lost;
- u32 overrun;
- u32 queue;
- unsigned char reserved[64];
-};
-
-static int snd_timer_user_status_compat(struct file *file,
- struct snd_timer_status32 __user *_status)
-{
- struct snd_timer_user *tu;
- struct snd_timer_status32 status;
-
- tu = file->private_data;
- if (!tu->timeri)
- return -EBADFD;
- memset(&status, 0, sizeof(status));
- status.tstamp.tv_sec = tu->tstamp.tv_sec;
- status.tstamp.tv_nsec = tu->tstamp.tv_nsec;
- status.resolution = snd_timer_resolution(tu->timeri);
- status.lost = tu->timeri->lost;
- status.overrun = tu->overrun;
- spin_lock_irq(&tu->qlock);
- status.queue = tu->qused;
- spin_unlock_irq(&tu->qlock);
- if (copy_to_user(_status, &status, sizeof(status)))
- return -EFAULT;
- return 0;
-}
-
-#ifdef CONFIG_X86_X32
-/* X32 ABI has the same struct as x86-64 */
-#define snd_timer_user_status_x32(file, s) \
- snd_timer_user_status(file, s)
-#endif /* CONFIG_X86_X32 */
-
-/*
- */
-
enum {
SNDRV_TIMER_IOCTL_GPARAMS32 = _IOW('T', 0x04, struct snd_timer_gparams32),
SNDRV_TIMER_IOCTL_INFO32 = _IOR('T', 0x11, struct snd_timer_info32),
- SNDRV_TIMER_IOCTL_STATUS32 = _IOW('T', 0x14, struct snd_timer_status32),
-#ifdef CONFIG_X86_X32
- SNDRV_TIMER_IOCTL_STATUS_X32 = _IOW('T', 0x14, struct snd_timer_status),
-#endif /* CONFIG_X86_X32 */
+ SNDRV_TIMER_IOCTL_STATUS_COMPAT32 = _IOW('T', 0x14, struct snd_timer_status32),
+ SNDRV_TIMER_IOCTL_STATUS_COMPAT64 = _IOW('T', 0x14, struct snd_timer_status64),
};
static long __snd_timer_user_ioctl_compat(struct file *file, unsigned int cmd,
@@ -145,12 +102,10 @@ static long __snd_timer_user_ioctl_compat(struct file *file, unsigned int cmd,
return snd_timer_user_gparams_compat(file, argp);
case SNDRV_TIMER_IOCTL_INFO32:
return snd_timer_user_info_compat(file, argp);
- case SNDRV_TIMER_IOCTL_STATUS32:
- return snd_timer_user_status_compat(file, argp);
-#ifdef CONFIG_X86_X32
- case SNDRV_TIMER_IOCTL_STATUS_X32:
- return snd_timer_user_status_x32(file, argp);
-#endif /* CONFIG_X86_X32 */
+ case SNDRV_TIMER_IOCTL_STATUS_COMPAT32:
+ return snd_timer_user_status32(file, argp);
+ case SNDRV_TIMER_IOCTL_STATUS_COMPAT64:
+ return snd_timer_user_status64(file, argp);
}
return -ENOIOCTLCMD;
}
--
2.20.0
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH v7 3/9] ALSA: Avoid using timespec for struct snd_ctl_elem_value
2019-12-11 21:20 ` [alsa-devel] " Arnd Bergmann
@ 2019-12-11 21:20 ` Arnd Bergmann
-1 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-11 21:20 UTC (permalink / raw)
To: alsa-devel, Takashi Iwai
Cc: Baolin Wang, y2038, linux-kernel, Jaroslav Kysela, Mark Brown,
Baolin Wang, Arnd Bergmann
From: Baolin Wang <baolin.wang@linaro.org>
The struct snd_ctl_elem_value will use 'timespec' type variables to record
timestamp, which is not year 2038 safe on 32bits system.
Since there are no drivers will implemented the tstamp member of the
struct snd_ctl_elem_value, and also the stucture size will not be changed
if we change timespec to s64 for tstamp member of struct snd_ctl_elem_value.
From Takashi's comments, "In the library, applications are not expected
to access to this structure directly. The applications get opaque pointer
to the structure and must use any control APIs to operate it. Actually the
library produce no API to handle 'struct snd_ctl_elem_value.tstamp'. This
means that we can drop this member from alsa-lib without decline of
functionality." Thus we can simply remove the tstamp member to avoid using
the type which is not year 2038 safe on 32bits system.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/uapi/sound/asound.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
index 930854f67fd3..40a23d8418fe 100644
--- a/include/uapi/sound/asound.h
+++ b/include/uapi/sound/asound.h
@@ -957,8 +957,7 @@ struct snd_ctl_elem_value {
} bytes;
struct snd_aes_iec958 iec958;
} value; /* RO */
- struct timespec tstamp;
- unsigned char reserved[128-sizeof(struct timespec)];
+ unsigned char reserved[128];
};
struct snd_ctl_tlv {
--
2.20.0
^ permalink raw reply related [flat|nested] 94+ messages in thread* [alsa-devel] [PATCH v7 3/9] ALSA: Avoid using timespec for struct snd_ctl_elem_value
@ 2019-12-11 21:20 ` Arnd Bergmann
0 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-11 21:20 UTC (permalink / raw)
To: alsa-devel, Takashi Iwai
Cc: Arnd Bergmann, Baolin Wang, y2038, linux-kernel, Mark Brown, Baolin Wang
From: Baolin Wang <baolin.wang@linaro.org>
The struct snd_ctl_elem_value will use 'timespec' type variables to record
timestamp, which is not year 2038 safe on 32bits system.
Since there are no drivers will implemented the tstamp member of the
struct snd_ctl_elem_value, and also the stucture size will not be changed
if we change timespec to s64 for tstamp member of struct snd_ctl_elem_value.
From Takashi's comments, "In the library, applications are not expected
to access to this structure directly. The applications get opaque pointer
to the structure and must use any control APIs to operate it. Actually the
library produce no API to handle 'struct snd_ctl_elem_value.tstamp'. This
means that we can drop this member from alsa-lib without decline of
functionality." Thus we can simply remove the tstamp member to avoid using
the type which is not year 2038 safe on 32bits system.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/uapi/sound/asound.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
index 930854f67fd3..40a23d8418fe 100644
--- a/include/uapi/sound/asound.h
+++ b/include/uapi/sound/asound.h
@@ -957,8 +957,7 @@ struct snd_ctl_elem_value {
} bytes;
struct snd_aes_iec958 iec958;
} value; /* RO */
- struct timespec tstamp;
- unsigned char reserved[128-sizeof(struct timespec)];
+ unsigned char reserved[128];
};
struct snd_ctl_tlv {
--
2.20.0
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH v7 4/9] ALSA: Avoid using timespec for struct snd_pcm_status
2019-12-11 21:20 ` [alsa-devel] " Arnd Bergmann
@ 2019-12-11 21:20 ` Arnd Bergmann
-1 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-11 21:20 UTC (permalink / raw)
To: alsa-devel, Takashi Iwai
Cc: Baolin Wang, y2038, linux-kernel, Jaroslav Kysela, Mark Brown,
Baolin Wang, Arnd Bergmann
From: Baolin Wang <baolin.wang@linaro.org>
The struct snd_pcm_status will use 'timespec' type variables to record
timestamp, which is not year 2038 safe on 32bits system.
Userspace will use SNDRV_PCM_IOCTL_STATUS and SNDRV_PCM_IOCTL_STATUS_EXT
as commands to issue ioctl() to fill the 'snd_pcm_status' structure in
userspace. The command number is always defined through _IOR/_IOW/IORW,
so when userspace changes the definition of 'struct timespec' to use
64-bit types, the command number also changes.
Thus in the kernel, we now need to define two versions of each such ioctl
and corresponding ioctl commands to handle 32bit time_t and 64bit time_t
in native mode:
struct snd_pcm_status32 {
......
s32 trigger_tstamp_sec;
s32 trigger_tstamp_nsec;
......
s32 audio_tstamp_sec;
s32 audio_tstamp_nsec;
......
};
struct snd_pcm_status64 {
......
s32 trigger_tstamp_sec;
s32 trigger_tstamp_nsec;
......
s32 audio_tstamp_sec;
s32 audio_tstamp_nsec;
......
};
Moreover in compat file, we renamed or introduced new structures to handle
32bit/64bit time_t in compatible mode. The 'struct snd_pcm_status32' and
snd_pcm_status_user32() are used to handle 32bit time_t in compat mode.
'struct compat_snd_pcm_status64' and snd_pcm_status_user_compat64() are used
to handle 64bit time_t.
The implicit padding before timespec is made explicit to avoid incompatible
structure layout between 32-bit and 64-bit x86 due to the different
alignment requirements, and the snd_pcm_status structure is now hidden
from the kernel to avoid relying on the timespec definitio definitionn
Finally we can replace SNDRV_PCM_IOCTL_STATUS and SNDRV_PCM_IOCTL_STATUS_EXT
with new commands and introduce new functions to fill new 'struct snd_pcm_status64'
instead of using unsafe 'struct snd_pcm_status'. Then in future, the new
commands can be matched when userspace changes 'timespec' to 64bit type
to make a size change of 'struct snd_pcm_status'. When glibc changes time_t
to 64-bit, any recompiled program will issue ioctl commands that the kernel
does not understand without this patch.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/sound/pcm.h | 56 ++++++++++++-
include/uapi/sound/asound.h | 6 ++
sound/core/pcm.c | 12 +--
sound/core/pcm_compat.c | 154 +++++++++++++-----------------------
sound/core/pcm_native.c | 96 ++++++++++++++++++----
5 files changed, 198 insertions(+), 126 deletions(-)
diff --git a/include/sound/pcm.h b/include/sound/pcm.h
index cb407fade933..5a31525e2df6 100644
--- a/include/sound/pcm.h
+++ b/include/sound/pcm.h
@@ -44,6 +44,7 @@ struct snd_pcm_hardware {
size_t fifo_size; /* fifo size in bytes */
};
+struct snd_pcm_status64;
struct snd_pcm_substream;
struct snd_pcm_audio_tstamp_config; /* definitions further down */
@@ -558,8 +559,8 @@ int snd_pcm_notify(struct snd_pcm_notify *notify, int nfree);
int snd_pcm_info(struct snd_pcm_substream *substream, struct snd_pcm_info *info);
int snd_pcm_info_user(struct snd_pcm_substream *substream,
struct snd_pcm_info __user *info);
-int snd_pcm_status(struct snd_pcm_substream *substream,
- struct snd_pcm_status *status);
+int snd_pcm_status64(struct snd_pcm_substream *substream,
+ struct snd_pcm_status64 *status);
int snd_pcm_start(struct snd_pcm_substream *substream);
int snd_pcm_stop(struct snd_pcm_substream *substream, snd_pcm_state_t status);
int snd_pcm_drain_done(struct snd_pcm_substream *substream);
@@ -1422,4 +1423,55 @@ static inline u64 pcm_format_to_bits(snd_pcm_format_t pcm_format)
#define pcm_dbg(pcm, fmt, args...) \
dev_dbg((pcm)->card->dev, fmt, ##args)
+struct snd_pcm_status64 {
+ snd_pcm_state_t state; /* stream state */
+ u8 rsvd[4];
+ s64 trigger_tstamp_sec; /* time when stream was started/stopped/paused */
+ s64 trigger_tstamp_nsec;
+ s64 tstamp_sec; /* reference timestamp */
+ s64 tstamp_nsec;
+ snd_pcm_uframes_t appl_ptr; /* appl ptr */
+ snd_pcm_uframes_t hw_ptr; /* hw ptr */
+ snd_pcm_sframes_t delay; /* current delay in frames */
+ snd_pcm_uframes_t avail; /* number of frames available */
+ snd_pcm_uframes_t avail_max; /* max frames available on hw since last status */
+ snd_pcm_uframes_t overrange; /* count of ADC (capture) overrange detections from last status */
+ snd_pcm_state_t suspended_state; /* suspended stream state */
+ __u32 audio_tstamp_data; /* needed for 64-bit alignment, used for configs/report to/from userspace */
+ s64 audio_tstamp_sec; /* sample counter, wall clock, PHC or on-demand sync'ed */
+ s64 audio_tstamp_nsec;
+ s64 driver_tstamp_sec; /* useful in case reference system tstamp is reported with delay */
+ s64 driver_tstamp_nsec;
+ __u32 audio_tstamp_accuracy; /* in ns units, only valid if indicated in audio_tstamp_data */
+ unsigned char reserved[52-4*sizeof(s64)]; /* must be filled with zero */
+};
+
+#define SNDRV_PCM_IOCTL_STATUS64 _IOR('A', 0x20, struct snd_pcm_status64)
+#define SNDRV_PCM_IOCTL_STATUS_EXT64 _IOWR('A', 0x24, struct snd_pcm_status64)
+
+struct snd_pcm_status32 {
+ s32 state; /* stream state */
+ s32 trigger_tstamp_sec; /* time when stream was started/stopped/paused */
+ s32 trigger_tstamp_nsec;
+ s32 tstamp_sec; /* reference timestamp */
+ s32 tstamp_nsec;
+ u32 appl_ptr; /* appl ptr */
+ u32 hw_ptr; /* hw ptr */
+ s32 delay; /* current delay in frames */
+ u32 avail; /* number of frames available */
+ u32 avail_max; /* max frames available on hw since last status */
+ u32 overrange; /* count of ADC (capture) overrange detections from last status */
+ s32 suspended_state; /* suspended stream state */
+ u32 audio_tstamp_data; /* needed for 64-bit alignment, used for configs/report to/from userspace */
+ s32 audio_tstamp_sec; /* sample counter, wall clock, PHC or on-demand sync'ed */
+ s32 audio_tstamp_nsec;
+ s32 driver_tstamp_sec; /* useful in case reference system tstamp is reported with delay */
+ s32 driver_tstamp_nsec;
+ u32 audio_tstamp_accuracy; /* in ns units, only valid if indicated in audio_tstamp_data */
+ unsigned char reserved[52-4*sizeof(s32)]; /* must be filled with zero */
+};
+
+#define SNDRV_PCM_IOCTL_STATUS32 _IOR('A', 0x20, struct snd_pcm_status32)
+#define SNDRV_PCM_IOCTL_STATUS_EXT32 _IOWR('A', 0x24, struct snd_pcm_status32)
+
#endif /* __SOUND_PCM_H */
diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
index 40a23d8418fe..d2c88c098b20 100644
--- a/include/uapi/sound/asound.h
+++ b/include/uapi/sound/asound.h
@@ -456,8 +456,13 @@ enum {
SNDRV_PCM_AUDIO_TSTAMP_TYPE_LAST = SNDRV_PCM_AUDIO_TSTAMP_TYPE_LINK_SYNCHRONIZED
};
+#ifndef __KERNEL__
+/* explicit padding avoids incompatibility between i386 and x86-64 */
+typedef struct { unsigned char pad[sizeof(time_t) - sizeof(int)] __time_pad;
+
struct snd_pcm_status {
snd_pcm_state_t state; /* stream state */
+ __time_pad pad1; /* align to timespec */
struct timespec trigger_tstamp; /* time when stream was started/stopped/paused */
struct timespec tstamp; /* reference timestamp */
snd_pcm_uframes_t appl_ptr; /* appl ptr */
@@ -473,6 +478,7 @@ struct snd_pcm_status {
__u32 audio_tstamp_accuracy; /* in ns units, only valid if indicated in audio_tstamp_data */
unsigned char reserved[52-2*sizeof(struct timespec)]; /* must be filled with zero */
};
+#endif
struct snd_pcm_mmap_status {
snd_pcm_state_t state; /* RO: state - SNDRV_PCM_STATE_XXXX */
diff --git a/sound/core/pcm.c b/sound/core/pcm.c
index 9a72d641743d..85db55ea49fd 100644
--- a/sound/core/pcm.c
+++ b/sound/core/pcm.c
@@ -443,7 +443,7 @@ static void snd_pcm_substream_proc_status_read(struct snd_info_entry *entry,
{
struct snd_pcm_substream *substream = entry->private_data;
struct snd_pcm_runtime *runtime;
- struct snd_pcm_status status;
+ struct snd_pcm_status64 status;
int err;
mutex_lock(&substream->pcm->open_mutex);
@@ -453,17 +453,17 @@ static void snd_pcm_substream_proc_status_read(struct snd_info_entry *entry,
goto unlock;
}
memset(&status, 0, sizeof(status));
- err = snd_pcm_status(substream, &status);
+ err = snd_pcm_status64(substream, &status);
if (err < 0) {
snd_iprintf(buffer, "error %d\n", err);
goto unlock;
}
snd_iprintf(buffer, "state: %s\n", snd_pcm_state_name(status.state));
snd_iprintf(buffer, "owner_pid : %d\n", pid_vnr(substream->pid));
- snd_iprintf(buffer, "trigger_time: %ld.%09ld\n",
- status.trigger_tstamp.tv_sec, status.trigger_tstamp.tv_nsec);
- snd_iprintf(buffer, "tstamp : %ld.%09ld\n",
- status.tstamp.tv_sec, status.tstamp.tv_nsec);
+ snd_iprintf(buffer, "trigger_time: %lld.%09lld\n",
+ status.trigger_tstamp_sec, status.trigger_tstamp_nsec);
+ snd_iprintf(buffer, "tstamp : %lld.%09lld\n",
+ status.tstamp_sec, status.tstamp_nsec);
snd_iprintf(buffer, "delay : %ld\n", status.delay);
snd_iprintf(buffer, "avail : %ld\n", status.avail);
snd_iprintf(buffer, "avail_max : %ld\n", status.avail_max);
diff --git a/sound/core/pcm_compat.c b/sound/core/pcm_compat.c
index 6f9003b1869a..2671658442ea 100644
--- a/sound/core/pcm_compat.c
+++ b/sound/core/pcm_compat.c
@@ -168,73 +168,13 @@ static int snd_pcm_channel_info_user(struct snd_pcm_substream *substream,
snd_pcm_channel_info_user(s, p)
#endif /* CONFIG_X86_X32 */
-struct snd_pcm_status32 {
+struct compat_snd_pcm_status64 {
s32 state;
- struct compat_timespec trigger_tstamp;
- struct compat_timespec tstamp;
- u32 appl_ptr;
- u32 hw_ptr;
- s32 delay;
- u32 avail;
- u32 avail_max;
- u32 overrange;
- s32 suspended_state;
- u32 audio_tstamp_data;
- struct compat_timespec audio_tstamp;
- struct compat_timespec driver_tstamp;
- u32 audio_tstamp_accuracy;
- unsigned char reserved[52-2*sizeof(struct compat_timespec)];
-} __attribute__((packed));
-
-
-static int snd_pcm_status_user_compat(struct snd_pcm_substream *substream,
- struct snd_pcm_status32 __user *src,
- bool ext)
-{
- struct snd_pcm_status status;
- int err;
-
- memset(&status, 0, sizeof(status));
- /*
- * with extension, parameters are read/write,
- * get audio_tstamp_data from user,
- * ignore rest of status structure
- */
- if (ext && get_user(status.audio_tstamp_data,
- (u32 __user *)(&src->audio_tstamp_data)))
- return -EFAULT;
- err = snd_pcm_status(substream, &status);
- if (err < 0)
- return err;
-
- if (clear_user(src, sizeof(*src)))
- return -EFAULT;
- if (put_user(status.state, &src->state) ||
- compat_put_timespec(&status.trigger_tstamp, &src->trigger_tstamp) ||
- compat_put_timespec(&status.tstamp, &src->tstamp) ||
- put_user(status.appl_ptr, &src->appl_ptr) ||
- put_user(status.hw_ptr, &src->hw_ptr) ||
- put_user(status.delay, &src->delay) ||
- put_user(status.avail, &src->avail) ||
- put_user(status.avail_max, &src->avail_max) ||
- put_user(status.overrange, &src->overrange) ||
- put_user(status.suspended_state, &src->suspended_state) ||
- put_user(status.audio_tstamp_data, &src->audio_tstamp_data) ||
- compat_put_timespec(&status.audio_tstamp, &src->audio_tstamp) ||
- compat_put_timespec(&status.driver_tstamp, &src->driver_tstamp) ||
- put_user(status.audio_tstamp_accuracy, &src->audio_tstamp_accuracy))
- return -EFAULT;
-
- return err;
-}
-
-#ifdef CONFIG_X86_X32
-/* X32 ABI has 64bit timespec and 64bit alignment */
-struct snd_pcm_status_x32 {
- s32 state;
- u32 rsvd; /* alignment */
- struct timespec trigger_tstamp;
- struct timespec tstamp;
+ u8 rsvd[4]; /* alignment */
+ s64 trigger_tstamp_sec;
+ s64 trigger_tstamp_nsec;
+ s64 tstamp_sec;
+ s64 tstamp_nsec;
u32 appl_ptr;
u32 hw_ptr;
s32 delay;
@@ -243,22 +183,26 @@ struct snd_pcm_status_x32 {
u32 overrange;
s32 suspended_state;
u32 audio_tstamp_data;
- struct timespec audio_tstamp;
- struct timespec driver_tstamp;
+ s64 audio_tstamp_sec;
+ s64 audio_tstamp_nsec;
+ s64 driver_tstamp_sec;
+ s64 driver_tstamp_nsec;
u32 audio_tstamp_accuracy;
- unsigned char reserved[52-2*sizeof(struct timespec)];
+ unsigned char reserved[52-4*sizeof(s64)];
} __packed;
#define put_timespec(src, dst) copy_to_user(dst, src, sizeof(*dst))
-static int snd_pcm_status_user_x32(struct snd_pcm_substream *substream,
- struct snd_pcm_status_x32 __user *src,
- bool ext)
+static int snd_pcm_status_user_compat64(struct snd_pcm_substream *substream,
+ struct compat_snd_pcm_status64 __user *src,
+ bool ext)
{
- struct snd_pcm_status status;
+ struct snd_pcm_status64 status;
+ struct compat_snd_pcm_status64 compat_status64;
int err;
memset(&status, 0, sizeof(status));
+ memset(&compat_status64, 0, sizeof(compat_status64));
/*
* with extension, parameters are read/write,
* get audio_tstamp_data from user,
@@ -267,31 +211,39 @@ static int snd_pcm_status_user_x32(struct snd_pcm_substream *substream,
if (ext && get_user(status.audio_tstamp_data,
(u32 __user *)(&src->audio_tstamp_data)))
return -EFAULT;
- err = snd_pcm_status(substream, &status);
+ err = snd_pcm_status64(substream, &status);
if (err < 0)
return err;
if (clear_user(src, sizeof(*src)))
return -EFAULT;
- if (put_user(status.state, &src->state) ||
- put_timespec(&status.trigger_tstamp, &src->trigger_tstamp) ||
- put_timespec(&status.tstamp, &src->tstamp) ||
- put_user(status.appl_ptr, &src->appl_ptr) ||
- put_user(status.hw_ptr, &src->hw_ptr) ||
- put_user(status.delay, &src->delay) ||
- put_user(status.avail, &src->avail) ||
- put_user(status.avail_max, &src->avail_max) ||
- put_user(status.overrange, &src->overrange) ||
- put_user(status.suspended_state, &src->suspended_state) ||
- put_user(status.audio_tstamp_data, &src->audio_tstamp_data) ||
- put_timespec(&status.audio_tstamp, &src->audio_tstamp) ||
- put_timespec(&status.driver_tstamp, &src->driver_tstamp) ||
- put_user(status.audio_tstamp_accuracy, &src->audio_tstamp_accuracy))
+
+ compat_status64 = (struct compat_snd_pcm_status64) {
+ .state = status.state,
+ .trigger_tstamp_sec = status.trigger_tstamp_sec,
+ .trigger_tstamp_nsec = status.trigger_tstamp_nsec,
+ .tstamp_sec = status.tstamp_sec,
+ .tstamp_nsec = status.tstamp_nsec,
+ .appl_ptr = status.appl_ptr,
+ .hw_ptr = status.hw_ptr,
+ .delay = status.delay,
+ .avail = status.avail,
+ .avail_max = status.avail_max,
+ .overrange = status.overrange,
+ .suspended_state = status.suspended_state,
+ .audio_tstamp_data = status.audio_tstamp_data,
+ .audio_tstamp_sec = status.audio_tstamp_sec,
+ .audio_tstamp_nsec = status.audio_tstamp_nsec,
+ .driver_tstamp_sec = status.audio_tstamp_sec,
+ .driver_tstamp_nsec = status.audio_tstamp_nsec,
+ .audio_tstamp_accuracy = status.audio_tstamp_accuracy,
+ };
+
+ if (copy_to_user(src, &compat_status64, sizeof(compat_status64)))
return -EFAULT;
return err;
}
-#endif /* CONFIG_X86_X32 */
/* both for HW_PARAMS and HW_REFINE */
static int snd_pcm_ioctl_hw_params_compat(struct snd_pcm_substream *substream,
@@ -616,8 +568,8 @@ enum {
SNDRV_PCM_IOCTL_HW_REFINE32 = _IOWR('A', 0x10, struct snd_pcm_hw_params32),
SNDRV_PCM_IOCTL_HW_PARAMS32 = _IOWR('A', 0x11, struct snd_pcm_hw_params32),
SNDRV_PCM_IOCTL_SW_PARAMS32 = _IOWR('A', 0x13, struct snd_pcm_sw_params32),
- SNDRV_PCM_IOCTL_STATUS32 = _IOR('A', 0x20, struct snd_pcm_status32),
- SNDRV_PCM_IOCTL_STATUS_EXT32 = _IOWR('A', 0x24, struct snd_pcm_status32),
+ SNDRV_PCM_IOCTL_STATUS_COMPAT32 = _IOR('A', 0x20, struct snd_pcm_status32),
+ SNDRV_PCM_IOCTL_STATUS_EXT_COMPAT32 = _IOWR('A', 0x24, struct snd_pcm_status32),
SNDRV_PCM_IOCTL_DELAY32 = _IOR('A', 0x21, s32),
SNDRV_PCM_IOCTL_CHANNEL_INFO32 = _IOR('A', 0x32, struct snd_pcm_channel_info32),
SNDRV_PCM_IOCTL_REWIND32 = _IOW('A', 0x46, u32),
@@ -627,10 +579,10 @@ enum {
SNDRV_PCM_IOCTL_WRITEN_FRAMES32 = _IOW('A', 0x52, struct snd_xfern32),
SNDRV_PCM_IOCTL_READN_FRAMES32 = _IOR('A', 0x53, struct snd_xfern32),
SNDRV_PCM_IOCTL_SYNC_PTR32 = _IOWR('A', 0x23, struct snd_pcm_sync_ptr32),
+ SNDRV_PCM_IOCTL_STATUS_COMPAT64 = _IOR('A', 0x20, struct compat_snd_pcm_status64),
+ SNDRV_PCM_IOCTL_STATUS_EXT_COMPAT64 = _IOWR('A', 0x24, struct compat_snd_pcm_status64),
#ifdef CONFIG_X86_X32
SNDRV_PCM_IOCTL_CHANNEL_INFO_X32 = _IOR('A', 0x32, struct snd_pcm_channel_info),
- SNDRV_PCM_IOCTL_STATUS_X32 = _IOR('A', 0x20, struct snd_pcm_status_x32),
- SNDRV_PCM_IOCTL_STATUS_EXT_X32 = _IOWR('A', 0x24, struct snd_pcm_status_x32),
SNDRV_PCM_IOCTL_SYNC_PTR_X32 = _IOWR('A', 0x23, struct snd_pcm_sync_ptr_x32),
#endif /* CONFIG_X86_X32 */
};
@@ -680,10 +632,10 @@ static long snd_pcm_ioctl_compat(struct file *file, unsigned int cmd, unsigned l
return snd_pcm_ioctl_hw_params_compat(substream, 0, argp);
case SNDRV_PCM_IOCTL_SW_PARAMS32:
return snd_pcm_ioctl_sw_params_compat(substream, argp);
- case SNDRV_PCM_IOCTL_STATUS32:
- return snd_pcm_status_user_compat(substream, argp, false);
- case SNDRV_PCM_IOCTL_STATUS_EXT32:
- return snd_pcm_status_user_compat(substream, argp, true);
+ case SNDRV_PCM_IOCTL_STATUS_COMPAT32:
+ return snd_pcm_status_user32(substream, argp, false);
+ case SNDRV_PCM_IOCTL_STATUS_EXT_COMPAT32:
+ return snd_pcm_status_user32(substream, argp, true);
case SNDRV_PCM_IOCTL_SYNC_PTR32:
return snd_pcm_ioctl_sync_ptr_compat(substream, argp);
case SNDRV_PCM_IOCTL_CHANNEL_INFO32:
@@ -702,11 +654,11 @@ static long snd_pcm_ioctl_compat(struct file *file, unsigned int cmd, unsigned l
return snd_pcm_ioctl_rewind_compat(substream, argp);
case SNDRV_PCM_IOCTL_FORWARD32:
return snd_pcm_ioctl_forward_compat(substream, argp);
+ case SNDRV_PCM_IOCTL_STATUS_COMPAT64:
+ return snd_pcm_status_user_compat64(substream, argp, false);
+ case SNDRV_PCM_IOCTL_STATUS_EXT_COMPAT64:
+ return snd_pcm_status_user_compat64(substream, argp, true);
#ifdef CONFIG_X86_X32
- case SNDRV_PCM_IOCTL_STATUS_X32:
- return snd_pcm_status_user_x32(substream, argp, false);
- case SNDRV_PCM_IOCTL_STATUS_EXT_X32:
- return snd_pcm_status_user_x32(substream, argp, true);
case SNDRV_PCM_IOCTL_SYNC_PTR_X32:
return snd_pcm_ioctl_sync_ptr_x32(substream, argp);
case SNDRV_PCM_IOCTL_CHANNEL_INFO_X32:
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index 67fe14bad7cb..ad4cf1e3e3bd 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -891,8 +891,8 @@ snd_pcm_calc_delay(struct snd_pcm_substream *substream)
return delay + substream->runtime->delay;
}
-int snd_pcm_status(struct snd_pcm_substream *substream,
- struct snd_pcm_status *status)
+int snd_pcm_status64(struct snd_pcm_substream *substream,
+ struct snd_pcm_status64 *status)
{
struct snd_pcm_runtime *runtime = substream->runtime;
@@ -918,14 +918,22 @@ int snd_pcm_status(struct snd_pcm_substream *substream,
status->suspended_state = runtime->status->suspended_state;
if (status->state == SNDRV_PCM_STATE_OPEN)
goto _end;
- status->trigger_tstamp = timespec64_to_timespec(runtime->trigger_tstamp);
+ status->trigger_tstamp_sec = runtime->trigger_tstamp.tv_sec;
+ status->trigger_tstamp_nsec = runtime->trigger_tstamp.tv_nsec;
if (snd_pcm_running(substream)) {
snd_pcm_update_hw_ptr(substream);
if (runtime->tstamp_mode == SNDRV_PCM_TSTAMP_ENABLE) {
- status->tstamp = runtime->status->tstamp;
- status->driver_tstamp = timespec64_to_timespec(runtime->driver_tstamp);
- status->audio_tstamp =
- runtime->status->audio_tstamp;
+ status->tstamp_sec = runtime->status->tstamp.tv_sec;
+ status->tstamp_nsec =
+ runtime->status->tstamp.tv_nsec;
+ status->driver_tstamp_sec =
+ runtime->driver_tstamp.tv_sec;
+ status->driver_tstamp_nsec =
+ runtime->driver_tstamp.tv_nsec;
+ status->audio_tstamp_sec =
+ runtime->status->audio_tstamp.tv_sec;
+ status->audio_tstamp_nsec =
+ runtime->status->audio_tstamp.tv_nsec;
if (runtime->audio_tstamp_report.valid == 1)
/* backwards compatibility, no report provided in COMPAT mode */
snd_pcm_pack_audio_tstamp_report(&status->audio_tstamp_data,
@@ -940,7 +948,8 @@ int snd_pcm_status(struct snd_pcm_substream *substream,
struct timespec64 tstamp;
snd_pcm_gettime(runtime, &tstamp);
- status->tstamp = timespec64_to_timespec(tstamp);
+ status->tstamp_sec = tstamp.tv_sec;
+ status->tstamp_nsec = tstamp.tv_nsec;
}
}
_tstamp_end:
@@ -958,11 +967,11 @@ int snd_pcm_status(struct snd_pcm_substream *substream,
return 0;
}
-static int snd_pcm_status_user(struct snd_pcm_substream *substream,
- struct snd_pcm_status __user * _status,
- bool ext)
+static int snd_pcm_status_user64(struct snd_pcm_substream *substream,
+ struct snd_pcm_status64 __user * _status,
+ bool ext)
{
- struct snd_pcm_status status;
+ struct snd_pcm_status64 status;
int res;
memset(&status, 0, sizeof(status));
@@ -974,7 +983,7 @@ static int snd_pcm_status_user(struct snd_pcm_substream *substream,
if (ext && get_user(status.audio_tstamp_data,
(u32 __user *)(&_status->audio_tstamp_data)))
return -EFAULT;
- res = snd_pcm_status(substream, &status);
+ res = snd_pcm_status64(substream, &status);
if (res < 0)
return res;
if (copy_to_user(_status, &status, sizeof(status)))
@@ -982,6 +991,55 @@ static int snd_pcm_status_user(struct snd_pcm_substream *substream,
return 0;
}
+static int snd_pcm_status_user32(struct snd_pcm_substream *substream,
+ struct snd_pcm_status32 __user * _status,
+ bool ext)
+{
+ struct snd_pcm_status64 status64;
+ struct snd_pcm_status32 status32;
+ int res;
+
+ memset(&status64, 0, sizeof(status64));
+ memset(&status32, 0, sizeof(status32));
+ /*
+ * with extension, parameters are read/write,
+ * get audio_tstamp_data from user,
+ * ignore rest of status structure
+ */
+ if (ext && get_user(status64.audio_tstamp_data,
+ (u32 __user *)(&_status->audio_tstamp_data)))
+ return -EFAULT;
+ res = snd_pcm_status64(substream, &status64);
+ if (res < 0)
+ return res;
+
+ status32 = (struct snd_pcm_status32) {
+ .state = status64.state,
+ .trigger_tstamp_sec = status64.trigger_tstamp_sec,
+ .trigger_tstamp_nsec = status64.trigger_tstamp_nsec,
+ .tstamp_sec = status64.tstamp_sec,
+ .tstamp_nsec = status64.tstamp_nsec,
+ .appl_ptr = status64.appl_ptr,
+ .hw_ptr = status64.hw_ptr,
+ .delay = status64.delay,
+ .avail = status64.avail,
+ .avail_max = status64.avail_max,
+ .overrange = status64.overrange,
+ .suspended_state = status64.suspended_state,
+ .audio_tstamp_data = status64.audio_tstamp_data,
+ .audio_tstamp_sec = status64.audio_tstamp_sec,
+ .audio_tstamp_nsec = status64.audio_tstamp_nsec,
+ .driver_tstamp_sec = status64.audio_tstamp_sec,
+ .driver_tstamp_nsec = status64.audio_tstamp_nsec,
+ .audio_tstamp_accuracy = status64.audio_tstamp_accuracy,
+ };
+
+ if (copy_to_user(_status, &status32, sizeof(status32)))
+ return -EFAULT;
+
+ return 0;
+}
+
static int snd_pcm_channel_info(struct snd_pcm_substream *substream,
struct snd_pcm_channel_info * info)
{
@@ -2959,10 +3017,14 @@ static int snd_pcm_common_ioctl(struct file *file,
return snd_pcm_hw_free(substream);
case SNDRV_PCM_IOCTL_SW_PARAMS:
return snd_pcm_sw_params_user(substream, arg);
- case SNDRV_PCM_IOCTL_STATUS:
- return snd_pcm_status_user(substream, arg, false);
- case SNDRV_PCM_IOCTL_STATUS_EXT:
- return snd_pcm_status_user(substream, arg, true);
+ case SNDRV_PCM_IOCTL_STATUS32:
+ return snd_pcm_status_user32(substream, arg, false);
+ case SNDRV_PCM_IOCTL_STATUS_EXT32:
+ return snd_pcm_status_user32(substream, arg, true);
+ case SNDRV_PCM_IOCTL_STATUS64:
+ return snd_pcm_status_user64(substream, arg, false);
+ case SNDRV_PCM_IOCTL_STATUS_EXT64:
+ return snd_pcm_status_user64(substream, arg, true);
case SNDRV_PCM_IOCTL_CHANNEL_INFO:
return snd_pcm_channel_info_user(substream, arg);
case SNDRV_PCM_IOCTL_PREPARE:
--
2.20.0
^ permalink raw reply related [flat|nested] 94+ messages in thread* [alsa-devel] [PATCH v7 4/9] ALSA: Avoid using timespec for struct snd_pcm_status
@ 2019-12-11 21:20 ` Arnd Bergmann
0 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-11 21:20 UTC (permalink / raw)
To: alsa-devel, Takashi Iwai
Cc: Arnd Bergmann, Baolin Wang, y2038, linux-kernel, Mark Brown, Baolin Wang
From: Baolin Wang <baolin.wang@linaro.org>
The struct snd_pcm_status will use 'timespec' type variables to record
timestamp, which is not year 2038 safe on 32bits system.
Userspace will use SNDRV_PCM_IOCTL_STATUS and SNDRV_PCM_IOCTL_STATUS_EXT
as commands to issue ioctl() to fill the 'snd_pcm_status' structure in
userspace. The command number is always defined through _IOR/_IOW/IORW,
so when userspace changes the definition of 'struct timespec' to use
64-bit types, the command number also changes.
Thus in the kernel, we now need to define two versions of each such ioctl
and corresponding ioctl commands to handle 32bit time_t and 64bit time_t
in native mode:
struct snd_pcm_status32 {
......
s32 trigger_tstamp_sec;
s32 trigger_tstamp_nsec;
......
s32 audio_tstamp_sec;
s32 audio_tstamp_nsec;
......
};
struct snd_pcm_status64 {
......
s32 trigger_tstamp_sec;
s32 trigger_tstamp_nsec;
......
s32 audio_tstamp_sec;
s32 audio_tstamp_nsec;
......
};
Moreover in compat file, we renamed or introduced new structures to handle
32bit/64bit time_t in compatible mode. The 'struct snd_pcm_status32' and
snd_pcm_status_user32() are used to handle 32bit time_t in compat mode.
'struct compat_snd_pcm_status64' and snd_pcm_status_user_compat64() are used
to handle 64bit time_t.
The implicit padding before timespec is made explicit to avoid incompatible
structure layout between 32-bit and 64-bit x86 due to the different
alignment requirements, and the snd_pcm_status structure is now hidden
from the kernel to avoid relying on the timespec definitio definitionn
Finally we can replace SNDRV_PCM_IOCTL_STATUS and SNDRV_PCM_IOCTL_STATUS_EXT
with new commands and introduce new functions to fill new 'struct snd_pcm_status64'
instead of using unsafe 'struct snd_pcm_status'. Then in future, the new
commands can be matched when userspace changes 'timespec' to 64bit type
to make a size change of 'struct snd_pcm_status'. When glibc changes time_t
to 64-bit, any recompiled program will issue ioctl commands that the kernel
does not understand without this patch.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/sound/pcm.h | 56 ++++++++++++-
include/uapi/sound/asound.h | 6 ++
sound/core/pcm.c | 12 +--
sound/core/pcm_compat.c | 154 +++++++++++++-----------------------
sound/core/pcm_native.c | 96 ++++++++++++++++++----
5 files changed, 198 insertions(+), 126 deletions(-)
diff --git a/include/sound/pcm.h b/include/sound/pcm.h
index cb407fade933..5a31525e2df6 100644
--- a/include/sound/pcm.h
+++ b/include/sound/pcm.h
@@ -44,6 +44,7 @@ struct snd_pcm_hardware {
size_t fifo_size; /* fifo size in bytes */
};
+struct snd_pcm_status64;
struct snd_pcm_substream;
struct snd_pcm_audio_tstamp_config; /* definitions further down */
@@ -558,8 +559,8 @@ int snd_pcm_notify(struct snd_pcm_notify *notify, int nfree);
int snd_pcm_info(struct snd_pcm_substream *substream, struct snd_pcm_info *info);
int snd_pcm_info_user(struct snd_pcm_substream *substream,
struct snd_pcm_info __user *info);
-int snd_pcm_status(struct snd_pcm_substream *substream,
- struct snd_pcm_status *status);
+int snd_pcm_status64(struct snd_pcm_substream *substream,
+ struct snd_pcm_status64 *status);
int snd_pcm_start(struct snd_pcm_substream *substream);
int snd_pcm_stop(struct snd_pcm_substream *substream, snd_pcm_state_t status);
int snd_pcm_drain_done(struct snd_pcm_substream *substream);
@@ -1422,4 +1423,55 @@ static inline u64 pcm_format_to_bits(snd_pcm_format_t pcm_format)
#define pcm_dbg(pcm, fmt, args...) \
dev_dbg((pcm)->card->dev, fmt, ##args)
+struct snd_pcm_status64 {
+ snd_pcm_state_t state; /* stream state */
+ u8 rsvd[4];
+ s64 trigger_tstamp_sec; /* time when stream was started/stopped/paused */
+ s64 trigger_tstamp_nsec;
+ s64 tstamp_sec; /* reference timestamp */
+ s64 tstamp_nsec;
+ snd_pcm_uframes_t appl_ptr; /* appl ptr */
+ snd_pcm_uframes_t hw_ptr; /* hw ptr */
+ snd_pcm_sframes_t delay; /* current delay in frames */
+ snd_pcm_uframes_t avail; /* number of frames available */
+ snd_pcm_uframes_t avail_max; /* max frames available on hw since last status */
+ snd_pcm_uframes_t overrange; /* count of ADC (capture) overrange detections from last status */
+ snd_pcm_state_t suspended_state; /* suspended stream state */
+ __u32 audio_tstamp_data; /* needed for 64-bit alignment, used for configs/report to/from userspace */
+ s64 audio_tstamp_sec; /* sample counter, wall clock, PHC or on-demand sync'ed */
+ s64 audio_tstamp_nsec;
+ s64 driver_tstamp_sec; /* useful in case reference system tstamp is reported with delay */
+ s64 driver_tstamp_nsec;
+ __u32 audio_tstamp_accuracy; /* in ns units, only valid if indicated in audio_tstamp_data */
+ unsigned char reserved[52-4*sizeof(s64)]; /* must be filled with zero */
+};
+
+#define SNDRV_PCM_IOCTL_STATUS64 _IOR('A', 0x20, struct snd_pcm_status64)
+#define SNDRV_PCM_IOCTL_STATUS_EXT64 _IOWR('A', 0x24, struct snd_pcm_status64)
+
+struct snd_pcm_status32 {
+ s32 state; /* stream state */
+ s32 trigger_tstamp_sec; /* time when stream was started/stopped/paused */
+ s32 trigger_tstamp_nsec;
+ s32 tstamp_sec; /* reference timestamp */
+ s32 tstamp_nsec;
+ u32 appl_ptr; /* appl ptr */
+ u32 hw_ptr; /* hw ptr */
+ s32 delay; /* current delay in frames */
+ u32 avail; /* number of frames available */
+ u32 avail_max; /* max frames available on hw since last status */
+ u32 overrange; /* count of ADC (capture) overrange detections from last status */
+ s32 suspended_state; /* suspended stream state */
+ u32 audio_tstamp_data; /* needed for 64-bit alignment, used for configs/report to/from userspace */
+ s32 audio_tstamp_sec; /* sample counter, wall clock, PHC or on-demand sync'ed */
+ s32 audio_tstamp_nsec;
+ s32 driver_tstamp_sec; /* useful in case reference system tstamp is reported with delay */
+ s32 driver_tstamp_nsec;
+ u32 audio_tstamp_accuracy; /* in ns units, only valid if indicated in audio_tstamp_data */
+ unsigned char reserved[52-4*sizeof(s32)]; /* must be filled with zero */
+};
+
+#define SNDRV_PCM_IOCTL_STATUS32 _IOR('A', 0x20, struct snd_pcm_status32)
+#define SNDRV_PCM_IOCTL_STATUS_EXT32 _IOWR('A', 0x24, struct snd_pcm_status32)
+
#endif /* __SOUND_PCM_H */
diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
index 40a23d8418fe..d2c88c098b20 100644
--- a/include/uapi/sound/asound.h
+++ b/include/uapi/sound/asound.h
@@ -456,8 +456,13 @@ enum {
SNDRV_PCM_AUDIO_TSTAMP_TYPE_LAST = SNDRV_PCM_AUDIO_TSTAMP_TYPE_LINK_SYNCHRONIZED
};
+#ifndef __KERNEL__
+/* explicit padding avoids incompatibility between i386 and x86-64 */
+typedef struct { unsigned char pad[sizeof(time_t) - sizeof(int)] __time_pad;
+
struct snd_pcm_status {
snd_pcm_state_t state; /* stream state */
+ __time_pad pad1; /* align to timespec */
struct timespec trigger_tstamp; /* time when stream was started/stopped/paused */
struct timespec tstamp; /* reference timestamp */
snd_pcm_uframes_t appl_ptr; /* appl ptr */
@@ -473,6 +478,7 @@ struct snd_pcm_status {
__u32 audio_tstamp_accuracy; /* in ns units, only valid if indicated in audio_tstamp_data */
unsigned char reserved[52-2*sizeof(struct timespec)]; /* must be filled with zero */
};
+#endif
struct snd_pcm_mmap_status {
snd_pcm_state_t state; /* RO: state - SNDRV_PCM_STATE_XXXX */
diff --git a/sound/core/pcm.c b/sound/core/pcm.c
index 9a72d641743d..85db55ea49fd 100644
--- a/sound/core/pcm.c
+++ b/sound/core/pcm.c
@@ -443,7 +443,7 @@ static void snd_pcm_substream_proc_status_read(struct snd_info_entry *entry,
{
struct snd_pcm_substream *substream = entry->private_data;
struct snd_pcm_runtime *runtime;
- struct snd_pcm_status status;
+ struct snd_pcm_status64 status;
int err;
mutex_lock(&substream->pcm->open_mutex);
@@ -453,17 +453,17 @@ static void snd_pcm_substream_proc_status_read(struct snd_info_entry *entry,
goto unlock;
}
memset(&status, 0, sizeof(status));
- err = snd_pcm_status(substream, &status);
+ err = snd_pcm_status64(substream, &status);
if (err < 0) {
snd_iprintf(buffer, "error %d\n", err);
goto unlock;
}
snd_iprintf(buffer, "state: %s\n", snd_pcm_state_name(status.state));
snd_iprintf(buffer, "owner_pid : %d\n", pid_vnr(substream->pid));
- snd_iprintf(buffer, "trigger_time: %ld.%09ld\n",
- status.trigger_tstamp.tv_sec, status.trigger_tstamp.tv_nsec);
- snd_iprintf(buffer, "tstamp : %ld.%09ld\n",
- status.tstamp.tv_sec, status.tstamp.tv_nsec);
+ snd_iprintf(buffer, "trigger_time: %lld.%09lld\n",
+ status.trigger_tstamp_sec, status.trigger_tstamp_nsec);
+ snd_iprintf(buffer, "tstamp : %lld.%09lld\n",
+ status.tstamp_sec, status.tstamp_nsec);
snd_iprintf(buffer, "delay : %ld\n", status.delay);
snd_iprintf(buffer, "avail : %ld\n", status.avail);
snd_iprintf(buffer, "avail_max : %ld\n", status.avail_max);
diff --git a/sound/core/pcm_compat.c b/sound/core/pcm_compat.c
index 6f9003b1869a..2671658442ea 100644
--- a/sound/core/pcm_compat.c
+++ b/sound/core/pcm_compat.c
@@ -168,73 +168,13 @@ static int snd_pcm_channel_info_user(struct snd_pcm_substream *substream,
snd_pcm_channel_info_user(s, p)
#endif /* CONFIG_X86_X32 */
-struct snd_pcm_status32 {
+struct compat_snd_pcm_status64 {
s32 state;
- struct compat_timespec trigger_tstamp;
- struct compat_timespec tstamp;
- u32 appl_ptr;
- u32 hw_ptr;
- s32 delay;
- u32 avail;
- u32 avail_max;
- u32 overrange;
- s32 suspended_state;
- u32 audio_tstamp_data;
- struct compat_timespec audio_tstamp;
- struct compat_timespec driver_tstamp;
- u32 audio_tstamp_accuracy;
- unsigned char reserved[52-2*sizeof(struct compat_timespec)];
-} __attribute__((packed));
-
-
-static int snd_pcm_status_user_compat(struct snd_pcm_substream *substream,
- struct snd_pcm_status32 __user *src,
- bool ext)
-{
- struct snd_pcm_status status;
- int err;
-
- memset(&status, 0, sizeof(status));
- /*
- * with extension, parameters are read/write,
- * get audio_tstamp_data from user,
- * ignore rest of status structure
- */
- if (ext && get_user(status.audio_tstamp_data,
- (u32 __user *)(&src->audio_tstamp_data)))
- return -EFAULT;
- err = snd_pcm_status(substream, &status);
- if (err < 0)
- return err;
-
- if (clear_user(src, sizeof(*src)))
- return -EFAULT;
- if (put_user(status.state, &src->state) ||
- compat_put_timespec(&status.trigger_tstamp, &src->trigger_tstamp) ||
- compat_put_timespec(&status.tstamp, &src->tstamp) ||
- put_user(status.appl_ptr, &src->appl_ptr) ||
- put_user(status.hw_ptr, &src->hw_ptr) ||
- put_user(status.delay, &src->delay) ||
- put_user(status.avail, &src->avail) ||
- put_user(status.avail_max, &src->avail_max) ||
- put_user(status.overrange, &src->overrange) ||
- put_user(status.suspended_state, &src->suspended_state) ||
- put_user(status.audio_tstamp_data, &src->audio_tstamp_data) ||
- compat_put_timespec(&status.audio_tstamp, &src->audio_tstamp) ||
- compat_put_timespec(&status.driver_tstamp, &src->driver_tstamp) ||
- put_user(status.audio_tstamp_accuracy, &src->audio_tstamp_accuracy))
- return -EFAULT;
-
- return err;
-}
-
-#ifdef CONFIG_X86_X32
-/* X32 ABI has 64bit timespec and 64bit alignment */
-struct snd_pcm_status_x32 {
- s32 state;
- u32 rsvd; /* alignment */
- struct timespec trigger_tstamp;
- struct timespec tstamp;
+ u8 rsvd[4]; /* alignment */
+ s64 trigger_tstamp_sec;
+ s64 trigger_tstamp_nsec;
+ s64 tstamp_sec;
+ s64 tstamp_nsec;
u32 appl_ptr;
u32 hw_ptr;
s32 delay;
@@ -243,22 +183,26 @@ struct snd_pcm_status_x32 {
u32 overrange;
s32 suspended_state;
u32 audio_tstamp_data;
- struct timespec audio_tstamp;
- struct timespec driver_tstamp;
+ s64 audio_tstamp_sec;
+ s64 audio_tstamp_nsec;
+ s64 driver_tstamp_sec;
+ s64 driver_tstamp_nsec;
u32 audio_tstamp_accuracy;
- unsigned char reserved[52-2*sizeof(struct timespec)];
+ unsigned char reserved[52-4*sizeof(s64)];
} __packed;
#define put_timespec(src, dst) copy_to_user(dst, src, sizeof(*dst))
-static int snd_pcm_status_user_x32(struct snd_pcm_substream *substream,
- struct snd_pcm_status_x32 __user *src,
- bool ext)
+static int snd_pcm_status_user_compat64(struct snd_pcm_substream *substream,
+ struct compat_snd_pcm_status64 __user *src,
+ bool ext)
{
- struct snd_pcm_status status;
+ struct snd_pcm_status64 status;
+ struct compat_snd_pcm_status64 compat_status64;
int err;
memset(&status, 0, sizeof(status));
+ memset(&compat_status64, 0, sizeof(compat_status64));
/*
* with extension, parameters are read/write,
* get audio_tstamp_data from user,
@@ -267,31 +211,39 @@ static int snd_pcm_status_user_x32(struct snd_pcm_substream *substream,
if (ext && get_user(status.audio_tstamp_data,
(u32 __user *)(&src->audio_tstamp_data)))
return -EFAULT;
- err = snd_pcm_status(substream, &status);
+ err = snd_pcm_status64(substream, &status);
if (err < 0)
return err;
if (clear_user(src, sizeof(*src)))
return -EFAULT;
- if (put_user(status.state, &src->state) ||
- put_timespec(&status.trigger_tstamp, &src->trigger_tstamp) ||
- put_timespec(&status.tstamp, &src->tstamp) ||
- put_user(status.appl_ptr, &src->appl_ptr) ||
- put_user(status.hw_ptr, &src->hw_ptr) ||
- put_user(status.delay, &src->delay) ||
- put_user(status.avail, &src->avail) ||
- put_user(status.avail_max, &src->avail_max) ||
- put_user(status.overrange, &src->overrange) ||
- put_user(status.suspended_state, &src->suspended_state) ||
- put_user(status.audio_tstamp_data, &src->audio_tstamp_data) ||
- put_timespec(&status.audio_tstamp, &src->audio_tstamp) ||
- put_timespec(&status.driver_tstamp, &src->driver_tstamp) ||
- put_user(status.audio_tstamp_accuracy, &src->audio_tstamp_accuracy))
+
+ compat_status64 = (struct compat_snd_pcm_status64) {
+ .state = status.state,
+ .trigger_tstamp_sec = status.trigger_tstamp_sec,
+ .trigger_tstamp_nsec = status.trigger_tstamp_nsec,
+ .tstamp_sec = status.tstamp_sec,
+ .tstamp_nsec = status.tstamp_nsec,
+ .appl_ptr = status.appl_ptr,
+ .hw_ptr = status.hw_ptr,
+ .delay = status.delay,
+ .avail = status.avail,
+ .avail_max = status.avail_max,
+ .overrange = status.overrange,
+ .suspended_state = status.suspended_state,
+ .audio_tstamp_data = status.audio_tstamp_data,
+ .audio_tstamp_sec = status.audio_tstamp_sec,
+ .audio_tstamp_nsec = status.audio_tstamp_nsec,
+ .driver_tstamp_sec = status.audio_tstamp_sec,
+ .driver_tstamp_nsec = status.audio_tstamp_nsec,
+ .audio_tstamp_accuracy = status.audio_tstamp_accuracy,
+ };
+
+ if (copy_to_user(src, &compat_status64, sizeof(compat_status64)))
return -EFAULT;
return err;
}
-#endif /* CONFIG_X86_X32 */
/* both for HW_PARAMS and HW_REFINE */
static int snd_pcm_ioctl_hw_params_compat(struct snd_pcm_substream *substream,
@@ -616,8 +568,8 @@ enum {
SNDRV_PCM_IOCTL_HW_REFINE32 = _IOWR('A', 0x10, struct snd_pcm_hw_params32),
SNDRV_PCM_IOCTL_HW_PARAMS32 = _IOWR('A', 0x11, struct snd_pcm_hw_params32),
SNDRV_PCM_IOCTL_SW_PARAMS32 = _IOWR('A', 0x13, struct snd_pcm_sw_params32),
- SNDRV_PCM_IOCTL_STATUS32 = _IOR('A', 0x20, struct snd_pcm_status32),
- SNDRV_PCM_IOCTL_STATUS_EXT32 = _IOWR('A', 0x24, struct snd_pcm_status32),
+ SNDRV_PCM_IOCTL_STATUS_COMPAT32 = _IOR('A', 0x20, struct snd_pcm_status32),
+ SNDRV_PCM_IOCTL_STATUS_EXT_COMPAT32 = _IOWR('A', 0x24, struct snd_pcm_status32),
SNDRV_PCM_IOCTL_DELAY32 = _IOR('A', 0x21, s32),
SNDRV_PCM_IOCTL_CHANNEL_INFO32 = _IOR('A', 0x32, struct snd_pcm_channel_info32),
SNDRV_PCM_IOCTL_REWIND32 = _IOW('A', 0x46, u32),
@@ -627,10 +579,10 @@ enum {
SNDRV_PCM_IOCTL_WRITEN_FRAMES32 = _IOW('A', 0x52, struct snd_xfern32),
SNDRV_PCM_IOCTL_READN_FRAMES32 = _IOR('A', 0x53, struct snd_xfern32),
SNDRV_PCM_IOCTL_SYNC_PTR32 = _IOWR('A', 0x23, struct snd_pcm_sync_ptr32),
+ SNDRV_PCM_IOCTL_STATUS_COMPAT64 = _IOR('A', 0x20, struct compat_snd_pcm_status64),
+ SNDRV_PCM_IOCTL_STATUS_EXT_COMPAT64 = _IOWR('A', 0x24, struct compat_snd_pcm_status64),
#ifdef CONFIG_X86_X32
SNDRV_PCM_IOCTL_CHANNEL_INFO_X32 = _IOR('A', 0x32, struct snd_pcm_channel_info),
- SNDRV_PCM_IOCTL_STATUS_X32 = _IOR('A', 0x20, struct snd_pcm_status_x32),
- SNDRV_PCM_IOCTL_STATUS_EXT_X32 = _IOWR('A', 0x24, struct snd_pcm_status_x32),
SNDRV_PCM_IOCTL_SYNC_PTR_X32 = _IOWR('A', 0x23, struct snd_pcm_sync_ptr_x32),
#endif /* CONFIG_X86_X32 */
};
@@ -680,10 +632,10 @@ static long snd_pcm_ioctl_compat(struct file *file, unsigned int cmd, unsigned l
return snd_pcm_ioctl_hw_params_compat(substream, 0, argp);
case SNDRV_PCM_IOCTL_SW_PARAMS32:
return snd_pcm_ioctl_sw_params_compat(substream, argp);
- case SNDRV_PCM_IOCTL_STATUS32:
- return snd_pcm_status_user_compat(substream, argp, false);
- case SNDRV_PCM_IOCTL_STATUS_EXT32:
- return snd_pcm_status_user_compat(substream, argp, true);
+ case SNDRV_PCM_IOCTL_STATUS_COMPAT32:
+ return snd_pcm_status_user32(substream, argp, false);
+ case SNDRV_PCM_IOCTL_STATUS_EXT_COMPAT32:
+ return snd_pcm_status_user32(substream, argp, true);
case SNDRV_PCM_IOCTL_SYNC_PTR32:
return snd_pcm_ioctl_sync_ptr_compat(substream, argp);
case SNDRV_PCM_IOCTL_CHANNEL_INFO32:
@@ -702,11 +654,11 @@ static long snd_pcm_ioctl_compat(struct file *file, unsigned int cmd, unsigned l
return snd_pcm_ioctl_rewind_compat(substream, argp);
case SNDRV_PCM_IOCTL_FORWARD32:
return snd_pcm_ioctl_forward_compat(substream, argp);
+ case SNDRV_PCM_IOCTL_STATUS_COMPAT64:
+ return snd_pcm_status_user_compat64(substream, argp, false);
+ case SNDRV_PCM_IOCTL_STATUS_EXT_COMPAT64:
+ return snd_pcm_status_user_compat64(substream, argp, true);
#ifdef CONFIG_X86_X32
- case SNDRV_PCM_IOCTL_STATUS_X32:
- return snd_pcm_status_user_x32(substream, argp, false);
- case SNDRV_PCM_IOCTL_STATUS_EXT_X32:
- return snd_pcm_status_user_x32(substream, argp, true);
case SNDRV_PCM_IOCTL_SYNC_PTR_X32:
return snd_pcm_ioctl_sync_ptr_x32(substream, argp);
case SNDRV_PCM_IOCTL_CHANNEL_INFO_X32:
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index 67fe14bad7cb..ad4cf1e3e3bd 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -891,8 +891,8 @@ snd_pcm_calc_delay(struct snd_pcm_substream *substream)
return delay + substream->runtime->delay;
}
-int snd_pcm_status(struct snd_pcm_substream *substream,
- struct snd_pcm_status *status)
+int snd_pcm_status64(struct snd_pcm_substream *substream,
+ struct snd_pcm_status64 *status)
{
struct snd_pcm_runtime *runtime = substream->runtime;
@@ -918,14 +918,22 @@ int snd_pcm_status(struct snd_pcm_substream *substream,
status->suspended_state = runtime->status->suspended_state;
if (status->state == SNDRV_PCM_STATE_OPEN)
goto _end;
- status->trigger_tstamp = timespec64_to_timespec(runtime->trigger_tstamp);
+ status->trigger_tstamp_sec = runtime->trigger_tstamp.tv_sec;
+ status->trigger_tstamp_nsec = runtime->trigger_tstamp.tv_nsec;
if (snd_pcm_running(substream)) {
snd_pcm_update_hw_ptr(substream);
if (runtime->tstamp_mode == SNDRV_PCM_TSTAMP_ENABLE) {
- status->tstamp = runtime->status->tstamp;
- status->driver_tstamp = timespec64_to_timespec(runtime->driver_tstamp);
- status->audio_tstamp =
- runtime->status->audio_tstamp;
+ status->tstamp_sec = runtime->status->tstamp.tv_sec;
+ status->tstamp_nsec =
+ runtime->status->tstamp.tv_nsec;
+ status->driver_tstamp_sec =
+ runtime->driver_tstamp.tv_sec;
+ status->driver_tstamp_nsec =
+ runtime->driver_tstamp.tv_nsec;
+ status->audio_tstamp_sec =
+ runtime->status->audio_tstamp.tv_sec;
+ status->audio_tstamp_nsec =
+ runtime->status->audio_tstamp.tv_nsec;
if (runtime->audio_tstamp_report.valid == 1)
/* backwards compatibility, no report provided in COMPAT mode */
snd_pcm_pack_audio_tstamp_report(&status->audio_tstamp_data,
@@ -940,7 +948,8 @@ int snd_pcm_status(struct snd_pcm_substream *substream,
struct timespec64 tstamp;
snd_pcm_gettime(runtime, &tstamp);
- status->tstamp = timespec64_to_timespec(tstamp);
+ status->tstamp_sec = tstamp.tv_sec;
+ status->tstamp_nsec = tstamp.tv_nsec;
}
}
_tstamp_end:
@@ -958,11 +967,11 @@ int snd_pcm_status(struct snd_pcm_substream *substream,
return 0;
}
-static int snd_pcm_status_user(struct snd_pcm_substream *substream,
- struct snd_pcm_status __user * _status,
- bool ext)
+static int snd_pcm_status_user64(struct snd_pcm_substream *substream,
+ struct snd_pcm_status64 __user * _status,
+ bool ext)
{
- struct snd_pcm_status status;
+ struct snd_pcm_status64 status;
int res;
memset(&status, 0, sizeof(status));
@@ -974,7 +983,7 @@ static int snd_pcm_status_user(struct snd_pcm_substream *substream,
if (ext && get_user(status.audio_tstamp_data,
(u32 __user *)(&_status->audio_tstamp_data)))
return -EFAULT;
- res = snd_pcm_status(substream, &status);
+ res = snd_pcm_status64(substream, &status);
if (res < 0)
return res;
if (copy_to_user(_status, &status, sizeof(status)))
@@ -982,6 +991,55 @@ static int snd_pcm_status_user(struct snd_pcm_substream *substream,
return 0;
}
+static int snd_pcm_status_user32(struct snd_pcm_substream *substream,
+ struct snd_pcm_status32 __user * _status,
+ bool ext)
+{
+ struct snd_pcm_status64 status64;
+ struct snd_pcm_status32 status32;
+ int res;
+
+ memset(&status64, 0, sizeof(status64));
+ memset(&status32, 0, sizeof(status32));
+ /*
+ * with extension, parameters are read/write,
+ * get audio_tstamp_data from user,
+ * ignore rest of status structure
+ */
+ if (ext && get_user(status64.audio_tstamp_data,
+ (u32 __user *)(&_status->audio_tstamp_data)))
+ return -EFAULT;
+ res = snd_pcm_status64(substream, &status64);
+ if (res < 0)
+ return res;
+
+ status32 = (struct snd_pcm_status32) {
+ .state = status64.state,
+ .trigger_tstamp_sec = status64.trigger_tstamp_sec,
+ .trigger_tstamp_nsec = status64.trigger_tstamp_nsec,
+ .tstamp_sec = status64.tstamp_sec,
+ .tstamp_nsec = status64.tstamp_nsec,
+ .appl_ptr = status64.appl_ptr,
+ .hw_ptr = status64.hw_ptr,
+ .delay = status64.delay,
+ .avail = status64.avail,
+ .avail_max = status64.avail_max,
+ .overrange = status64.overrange,
+ .suspended_state = status64.suspended_state,
+ .audio_tstamp_data = status64.audio_tstamp_data,
+ .audio_tstamp_sec = status64.audio_tstamp_sec,
+ .audio_tstamp_nsec = status64.audio_tstamp_nsec,
+ .driver_tstamp_sec = status64.audio_tstamp_sec,
+ .driver_tstamp_nsec = status64.audio_tstamp_nsec,
+ .audio_tstamp_accuracy = status64.audio_tstamp_accuracy,
+ };
+
+ if (copy_to_user(_status, &status32, sizeof(status32)))
+ return -EFAULT;
+
+ return 0;
+}
+
static int snd_pcm_channel_info(struct snd_pcm_substream *substream,
struct snd_pcm_channel_info * info)
{
@@ -2959,10 +3017,14 @@ static int snd_pcm_common_ioctl(struct file *file,
return snd_pcm_hw_free(substream);
case SNDRV_PCM_IOCTL_SW_PARAMS:
return snd_pcm_sw_params_user(substream, arg);
- case SNDRV_PCM_IOCTL_STATUS:
- return snd_pcm_status_user(substream, arg, false);
- case SNDRV_PCM_IOCTL_STATUS_EXT:
- return snd_pcm_status_user(substream, arg, true);
+ case SNDRV_PCM_IOCTL_STATUS32:
+ return snd_pcm_status_user32(substream, arg, false);
+ case SNDRV_PCM_IOCTL_STATUS_EXT32:
+ return snd_pcm_status_user32(substream, arg, true);
+ case SNDRV_PCM_IOCTL_STATUS64:
+ return snd_pcm_status_user64(substream, arg, false);
+ case SNDRV_PCM_IOCTL_STATUS_EXT64:
+ return snd_pcm_status_user64(substream, arg, true);
case SNDRV_PCM_IOCTL_CHANNEL_INFO:
return snd_pcm_channel_info_user(substream, arg);
case SNDRV_PCM_IOCTL_PREPARE:
--
2.20.0
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH v7 5/9] ALSA: Avoid using timespec for struct snd_rawmidi_status
2019-12-11 21:20 ` [alsa-devel] " Arnd Bergmann
@ 2019-12-11 21:20 ` Arnd Bergmann
-1 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-11 21:20 UTC (permalink / raw)
To: alsa-devel, Takashi Iwai
Cc: Baolin Wang, y2038, linux-kernel, Jaroslav Kysela, Mark Brown,
Baolin Wang, Arnd Bergmann
From: Baolin Wang <baolin.wang@linaro.org>
The struct snd_rawmidi_status will use 'timespec' type variables to record
timestamp, which is not year 2038 safe on 32bits system.
Thus we introduced 'struct snd_rawmidi_status32' and 'struct snd_rawmidi_status64'
to handle 32bit time_t and 64bit time_t in native mode, which replace
timespec with s64 type.
In compat mode, we renamed or introduced new structures to handle 32bit/64bit
time_t in compatible mode. The 'struct snd_rawmidi_status32' and
snd_rawmidi_ioctl_status32() are used to handle 32bit time_t in compat mode.
'struct compat_snd_rawmidi_status64' is used to handle 64bit time_t.
When glibc changes time_t to 64-bit, any recompiled program will issue ioctl
commands that the kernel does not understand without this patch.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/uapi/sound/asound.h | 3 +
sound/core/rawmidi.c | 132 ++++++++++++++++++++++++++++--------
sound/core/rawmidi_compat.c | 87 ++++++------------------
3 files changed, 128 insertions(+), 94 deletions(-)
diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
index d2c88c098b20..e0ada33afa1e 100644
--- a/include/uapi/sound/asound.h
+++ b/include/uapi/sound/asound.h
@@ -654,13 +654,16 @@ struct snd_rawmidi_params {
unsigned char reserved[16]; /* reserved for future use */
};
+#ifndef __KERNEL__
struct snd_rawmidi_status {
int stream;
+ __time_pad pad1;
struct timespec tstamp; /* Timestamp */
size_t avail; /* available bytes */
size_t xruns; /* count of overruns since last status (in bytes) */
unsigned char reserved[16]; /* reserved for future use */
};
+#endif
#define SNDRV_RAWMIDI_IOCTL_PVERSION _IOR('W', 0x00, int)
#define SNDRV_RAWMIDI_IOCTL_INFO _IOR('W', 0x01, struct snd_rawmidi_info)
diff --git a/sound/core/rawmidi.c b/sound/core/rawmidi.c
index 8a12a7538d63..cd9bbb546846 100644
--- a/sound/core/rawmidi.c
+++ b/sound/core/rawmidi.c
@@ -50,6 +50,29 @@ static DEFINE_MUTEX(register_mutex);
#define rmidi_dbg(rmidi, fmt, args...) \
dev_dbg(&(rmidi)->dev, fmt, ##args)
+struct snd_rawmidi_status32 {
+ s32 stream;
+ s32 tstamp_sec; /* Timestamp */
+ s32 tstamp_nsec;
+ u32 avail; /* available bytes */
+ u32 xruns; /* count of overruns since last status (in bytes) */
+ unsigned char reserved[16]; /* reserved for future use */
+};
+
+#define SNDRV_RAWMIDI_IOCTL_STATUS32 _IOWR('W', 0x20, struct snd_rawmidi_status32)
+
+struct snd_rawmidi_status64 {
+ int stream;
+ u8 rsvd[4]; /* alignment */
+ s64 tstamp_sec; /* Timestamp */
+ s64 tstamp_nsec;
+ size_t avail; /* available bytes */
+ size_t xruns; /* count of overruns since last status (in bytes) */
+ unsigned char reserved[16]; /* reserved for future use */
+};
+
+#define SNDRV_RAWMIDI_IOCTL_STATUS64 _IOWR('W', 0x20, struct snd_rawmidi_status64)
+
static struct snd_rawmidi *snd_rawmidi_search(struct snd_card *card, int device)
{
struct snd_rawmidi *rawmidi;
@@ -677,7 +700,7 @@ int snd_rawmidi_input_params(struct snd_rawmidi_substream *substream,
EXPORT_SYMBOL(snd_rawmidi_input_params);
static int snd_rawmidi_output_status(struct snd_rawmidi_substream *substream,
- struct snd_rawmidi_status *status)
+ struct snd_rawmidi_status64 *status)
{
struct snd_rawmidi_runtime *runtime = substream->runtime;
@@ -690,7 +713,7 @@ static int snd_rawmidi_output_status(struct snd_rawmidi_substream *substream,
}
static int snd_rawmidi_input_status(struct snd_rawmidi_substream *substream,
- struct snd_rawmidi_status *status)
+ struct snd_rawmidi_status64 *status)
{
struct snd_rawmidi_runtime *runtime = substream->runtime;
@@ -704,6 +727,80 @@ static int snd_rawmidi_input_status(struct snd_rawmidi_substream *substream,
return 0;
}
+static int snd_rawmidi_ioctl_status32(struct snd_rawmidi_file *rfile,
+ struct snd_rawmidi_status32 __user *argp)
+{
+ int err = 0;
+ struct snd_rawmidi_status32 __user *status = argp;
+ struct snd_rawmidi_status32 status32;
+ struct snd_rawmidi_status64 status64;
+
+ if (copy_from_user(&status32, argp,
+ sizeof(struct snd_rawmidi_status32)))
+ return -EFAULT;
+
+ switch (status32.stream) {
+ case SNDRV_RAWMIDI_STREAM_OUTPUT:
+ if (rfile->output == NULL)
+ return -EINVAL;
+ err = snd_rawmidi_output_status(rfile->output, &status64);
+ break;
+ case SNDRV_RAWMIDI_STREAM_INPUT:
+ if (rfile->input == NULL)
+ return -EINVAL;
+ err = snd_rawmidi_input_status(rfile->input, &status64);
+ break;
+ default:
+ return -EINVAL;
+ }
+ if (err < 0)
+ return err;
+
+ status32 = (struct snd_rawmidi_status32) {
+ .stream = status64.stream,
+ .tstamp_sec = status64.tstamp_sec,
+ .tstamp_nsec = status64.tstamp_nsec,
+ .avail = status64.avail,
+ .xruns = status64.xruns,
+ };
+
+ if (copy_to_user(status, &status32, sizeof(*status)))
+ return -EFAULT;
+
+ return 0;
+}
+
+static int snd_rawmidi_ioctl_status64(struct snd_rawmidi_file *rfile,
+ struct snd_rawmidi_status64 __user *argp)
+{
+ int err = 0;
+ struct snd_rawmidi_status64 status;
+
+ if (copy_from_user(&status, argp, sizeof(struct snd_rawmidi_status64)))
+ return -EFAULT;
+
+ switch (status.stream) {
+ case SNDRV_RAWMIDI_STREAM_OUTPUT:
+ if (rfile->output == NULL)
+ return -EINVAL;
+ err = snd_rawmidi_output_status(rfile->output, &status);
+ break;
+ case SNDRV_RAWMIDI_STREAM_INPUT:
+ if (rfile->input == NULL)
+ return -EINVAL;
+ err = snd_rawmidi_input_status(rfile->input, &status);
+ break;
+ default:
+ return -EINVAL;
+ }
+ if (err < 0)
+ return err;
+ if (copy_to_user(argp, &status,
+ sizeof(struct snd_rawmidi_status64)))
+ return -EFAULT;
+ return 0;
+}
+
static long snd_rawmidi_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
struct snd_rawmidi_file *rfile;
@@ -750,33 +847,10 @@ static long snd_rawmidi_ioctl(struct file *file, unsigned int cmd, unsigned long
return -EINVAL;
}
}
- case SNDRV_RAWMIDI_IOCTL_STATUS:
- {
- int err = 0;
- struct snd_rawmidi_status status;
-
- if (copy_from_user(&status, argp, sizeof(struct snd_rawmidi_status)))
- return -EFAULT;
- switch (status.stream) {
- case SNDRV_RAWMIDI_STREAM_OUTPUT:
- if (rfile->output == NULL)
- return -EINVAL;
- err = snd_rawmidi_output_status(rfile->output, &status);
- break;
- case SNDRV_RAWMIDI_STREAM_INPUT:
- if (rfile->input == NULL)
- return -EINVAL;
- err = snd_rawmidi_input_status(rfile->input, &status);
- break;
- default:
- return -EINVAL;
- }
- if (err < 0)
- return err;
- if (copy_to_user(argp, &status, sizeof(struct snd_rawmidi_status)))
- return -EFAULT;
- return 0;
- }
+ case SNDRV_RAWMIDI_IOCTL_STATUS32:
+ return snd_rawmidi_ioctl_status32(rfile, argp);
+ case SNDRV_RAWMIDI_IOCTL_STATUS64:
+ return snd_rawmidi_ioctl_status64(rfile, argp);
case SNDRV_RAWMIDI_IOCTL_DROP:
{
int val;
diff --git a/sound/core/rawmidi_compat.c b/sound/core/rawmidi_compat.c
index 66eee61674b6..7397130976d0 100644
--- a/sound/core/rawmidi_compat.c
+++ b/sound/core/rawmidi_compat.c
@@ -41,19 +41,22 @@ static int snd_rawmidi_ioctl_params_compat(struct snd_rawmidi_file *rfile,
return -EINVAL;
}
-struct snd_rawmidi_status32 {
+struct compat_snd_rawmidi_status64 {
s32 stream;
- struct compat_timespec tstamp;
+ u8 rsvd[4]; /* alignment */
+ s64 tstamp_sec;
+ s64 tstamp_nsec;
u32 avail;
u32 xruns;
unsigned char reserved[16];
} __attribute__((packed));
-static int snd_rawmidi_ioctl_status_compat(struct snd_rawmidi_file *rfile,
- struct snd_rawmidi_status32 __user *src)
+static int snd_rawmidi_ioctl_status_compat64(struct snd_rawmidi_file *rfile,
+ struct compat_snd_rawmidi_status64 __user *src)
{
int err;
- struct snd_rawmidi_status status;
+ struct snd_rawmidi_status64 status;
+ struct compat_snd_rawmidi_status64 compat_status;
if (get_user(status.stream, &src->stream))
return -EFAULT;
@@ -75,68 +78,24 @@ static int snd_rawmidi_ioctl_status_compat(struct snd_rawmidi_file *rfile,
if (err < 0)
return err;
- if (compat_put_timespec(&status.tstamp, &src->tstamp) ||
- put_user(status.avail, &src->avail) ||
- put_user(status.xruns, &src->xruns))
- return -EFAULT;
-
- return 0;
-}
-
-#ifdef CONFIG_X86_X32
-/* X32 ABI has 64bit timespec and 64bit alignment */
-struct snd_rawmidi_status_x32 {
- s32 stream;
- u32 rsvd; /* alignment */
- struct timespec tstamp;
- u32 avail;
- u32 xruns;
- unsigned char reserved[16];
-} __attribute__((packed));
-
-#define put_timespec(src, dst) copy_to_user(dst, src, sizeof(*dst))
-
-static int snd_rawmidi_ioctl_status_x32(struct snd_rawmidi_file *rfile,
- struct snd_rawmidi_status_x32 __user *src)
-{
- int err;
- struct snd_rawmidi_status status;
-
- if (get_user(status.stream, &src->stream))
- return -EFAULT;
-
- switch (status.stream) {
- case SNDRV_RAWMIDI_STREAM_OUTPUT:
- if (!rfile->output)
- return -EINVAL;
- err = snd_rawmidi_output_status(rfile->output, &status);
- break;
- case SNDRV_RAWMIDI_STREAM_INPUT:
- if (!rfile->input)
- return -EINVAL;
- err = snd_rawmidi_input_status(rfile->input, &status);
- break;
- default:
- return -EINVAL;
- }
- if (err < 0)
- return err;
+ compat_status = (struct compat_snd_rawmidi_status64) {
+ .stream = status.stream,
+ .tstamp_sec = status.tstamp_sec,
+ .tstamp_nsec = status.tstamp_nsec,
+ .avail = status.avail,
+ .xruns = status.xruns,
+ };
- if (put_timespec(&status.tstamp, &src->tstamp) ||
- put_user(status.avail, &src->avail) ||
- put_user(status.xruns, &src->xruns))
+ if (copy_to_user(src, &compat_status, sizeof(*src)))
return -EFAULT;
return 0;
}
-#endif /* CONFIG_X86_X32 */
enum {
SNDRV_RAWMIDI_IOCTL_PARAMS32 = _IOWR('W', 0x10, struct snd_rawmidi_params32),
- SNDRV_RAWMIDI_IOCTL_STATUS32 = _IOWR('W', 0x20, struct snd_rawmidi_status32),
-#ifdef CONFIG_X86_X32
- SNDRV_RAWMIDI_IOCTL_STATUS_X32 = _IOWR('W', 0x20, struct snd_rawmidi_status_x32),
-#endif /* CONFIG_X86_X32 */
+ SNDRV_RAWMIDI_IOCTL_STATUS_COMPAT32 = _IOWR('W', 0x20, struct snd_rawmidi_status32),
+ SNDRV_RAWMIDI_IOCTL_STATUS_COMPAT64 = _IOWR('W', 0x20, struct compat_snd_rawmidi_status64),
};
static long snd_rawmidi_ioctl_compat(struct file *file, unsigned int cmd, unsigned long arg)
@@ -153,12 +112,10 @@ static long snd_rawmidi_ioctl_compat(struct file *file, unsigned int cmd, unsign
return snd_rawmidi_ioctl(file, cmd, (unsigned long)argp);
case SNDRV_RAWMIDI_IOCTL_PARAMS32:
return snd_rawmidi_ioctl_params_compat(rfile, argp);
- case SNDRV_RAWMIDI_IOCTL_STATUS32:
- return snd_rawmidi_ioctl_status_compat(rfile, argp);
-#ifdef CONFIG_X86_X32
- case SNDRV_RAWMIDI_IOCTL_STATUS_X32:
- return snd_rawmidi_ioctl_status_x32(rfile, argp);
-#endif /* CONFIG_X86_X32 */
+ case SNDRV_RAWMIDI_IOCTL_STATUS_COMPAT32:
+ return snd_rawmidi_ioctl_status32(rfile, argp);
+ case SNDRV_RAWMIDI_IOCTL_STATUS_COMPAT64:
+ return snd_rawmidi_ioctl_status_compat64(rfile, argp);
}
return -ENOIOCTLCMD;
}
--
2.20.0
^ permalink raw reply related [flat|nested] 94+ messages in thread* [alsa-devel] [PATCH v7 5/9] ALSA: Avoid using timespec for struct snd_rawmidi_status
@ 2019-12-11 21:20 ` Arnd Bergmann
0 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-11 21:20 UTC (permalink / raw)
To: alsa-devel, Takashi Iwai
Cc: Arnd Bergmann, Baolin Wang, y2038, linux-kernel, Mark Brown, Baolin Wang
From: Baolin Wang <baolin.wang@linaro.org>
The struct snd_rawmidi_status will use 'timespec' type variables to record
timestamp, which is not year 2038 safe on 32bits system.
Thus we introduced 'struct snd_rawmidi_status32' and 'struct snd_rawmidi_status64'
to handle 32bit time_t and 64bit time_t in native mode, which replace
timespec with s64 type.
In compat mode, we renamed or introduced new structures to handle 32bit/64bit
time_t in compatible mode. The 'struct snd_rawmidi_status32' and
snd_rawmidi_ioctl_status32() are used to handle 32bit time_t in compat mode.
'struct compat_snd_rawmidi_status64' is used to handle 64bit time_t.
When glibc changes time_t to 64-bit, any recompiled program will issue ioctl
commands that the kernel does not understand without this patch.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/uapi/sound/asound.h | 3 +
sound/core/rawmidi.c | 132 ++++++++++++++++++++++++++++--------
sound/core/rawmidi_compat.c | 87 ++++++------------------
3 files changed, 128 insertions(+), 94 deletions(-)
diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
index d2c88c098b20..e0ada33afa1e 100644
--- a/include/uapi/sound/asound.h
+++ b/include/uapi/sound/asound.h
@@ -654,13 +654,16 @@ struct snd_rawmidi_params {
unsigned char reserved[16]; /* reserved for future use */
};
+#ifndef __KERNEL__
struct snd_rawmidi_status {
int stream;
+ __time_pad pad1;
struct timespec tstamp; /* Timestamp */
size_t avail; /* available bytes */
size_t xruns; /* count of overruns since last status (in bytes) */
unsigned char reserved[16]; /* reserved for future use */
};
+#endif
#define SNDRV_RAWMIDI_IOCTL_PVERSION _IOR('W', 0x00, int)
#define SNDRV_RAWMIDI_IOCTL_INFO _IOR('W', 0x01, struct snd_rawmidi_info)
diff --git a/sound/core/rawmidi.c b/sound/core/rawmidi.c
index 8a12a7538d63..cd9bbb546846 100644
--- a/sound/core/rawmidi.c
+++ b/sound/core/rawmidi.c
@@ -50,6 +50,29 @@ static DEFINE_MUTEX(register_mutex);
#define rmidi_dbg(rmidi, fmt, args...) \
dev_dbg(&(rmidi)->dev, fmt, ##args)
+struct snd_rawmidi_status32 {
+ s32 stream;
+ s32 tstamp_sec; /* Timestamp */
+ s32 tstamp_nsec;
+ u32 avail; /* available bytes */
+ u32 xruns; /* count of overruns since last status (in bytes) */
+ unsigned char reserved[16]; /* reserved for future use */
+};
+
+#define SNDRV_RAWMIDI_IOCTL_STATUS32 _IOWR('W', 0x20, struct snd_rawmidi_status32)
+
+struct snd_rawmidi_status64 {
+ int stream;
+ u8 rsvd[4]; /* alignment */
+ s64 tstamp_sec; /* Timestamp */
+ s64 tstamp_nsec;
+ size_t avail; /* available bytes */
+ size_t xruns; /* count of overruns since last status (in bytes) */
+ unsigned char reserved[16]; /* reserved for future use */
+};
+
+#define SNDRV_RAWMIDI_IOCTL_STATUS64 _IOWR('W', 0x20, struct snd_rawmidi_status64)
+
static struct snd_rawmidi *snd_rawmidi_search(struct snd_card *card, int device)
{
struct snd_rawmidi *rawmidi;
@@ -677,7 +700,7 @@ int snd_rawmidi_input_params(struct snd_rawmidi_substream *substream,
EXPORT_SYMBOL(snd_rawmidi_input_params);
static int snd_rawmidi_output_status(struct snd_rawmidi_substream *substream,
- struct snd_rawmidi_status *status)
+ struct snd_rawmidi_status64 *status)
{
struct snd_rawmidi_runtime *runtime = substream->runtime;
@@ -690,7 +713,7 @@ static int snd_rawmidi_output_status(struct snd_rawmidi_substream *substream,
}
static int snd_rawmidi_input_status(struct snd_rawmidi_substream *substream,
- struct snd_rawmidi_status *status)
+ struct snd_rawmidi_status64 *status)
{
struct snd_rawmidi_runtime *runtime = substream->runtime;
@@ -704,6 +727,80 @@ static int snd_rawmidi_input_status(struct snd_rawmidi_substream *substream,
return 0;
}
+static int snd_rawmidi_ioctl_status32(struct snd_rawmidi_file *rfile,
+ struct snd_rawmidi_status32 __user *argp)
+{
+ int err = 0;
+ struct snd_rawmidi_status32 __user *status = argp;
+ struct snd_rawmidi_status32 status32;
+ struct snd_rawmidi_status64 status64;
+
+ if (copy_from_user(&status32, argp,
+ sizeof(struct snd_rawmidi_status32)))
+ return -EFAULT;
+
+ switch (status32.stream) {
+ case SNDRV_RAWMIDI_STREAM_OUTPUT:
+ if (rfile->output == NULL)
+ return -EINVAL;
+ err = snd_rawmidi_output_status(rfile->output, &status64);
+ break;
+ case SNDRV_RAWMIDI_STREAM_INPUT:
+ if (rfile->input == NULL)
+ return -EINVAL;
+ err = snd_rawmidi_input_status(rfile->input, &status64);
+ break;
+ default:
+ return -EINVAL;
+ }
+ if (err < 0)
+ return err;
+
+ status32 = (struct snd_rawmidi_status32) {
+ .stream = status64.stream,
+ .tstamp_sec = status64.tstamp_sec,
+ .tstamp_nsec = status64.tstamp_nsec,
+ .avail = status64.avail,
+ .xruns = status64.xruns,
+ };
+
+ if (copy_to_user(status, &status32, sizeof(*status)))
+ return -EFAULT;
+
+ return 0;
+}
+
+static int snd_rawmidi_ioctl_status64(struct snd_rawmidi_file *rfile,
+ struct snd_rawmidi_status64 __user *argp)
+{
+ int err = 0;
+ struct snd_rawmidi_status64 status;
+
+ if (copy_from_user(&status, argp, sizeof(struct snd_rawmidi_status64)))
+ return -EFAULT;
+
+ switch (status.stream) {
+ case SNDRV_RAWMIDI_STREAM_OUTPUT:
+ if (rfile->output == NULL)
+ return -EINVAL;
+ err = snd_rawmidi_output_status(rfile->output, &status);
+ break;
+ case SNDRV_RAWMIDI_STREAM_INPUT:
+ if (rfile->input == NULL)
+ return -EINVAL;
+ err = snd_rawmidi_input_status(rfile->input, &status);
+ break;
+ default:
+ return -EINVAL;
+ }
+ if (err < 0)
+ return err;
+ if (copy_to_user(argp, &status,
+ sizeof(struct snd_rawmidi_status64)))
+ return -EFAULT;
+ return 0;
+}
+
static long snd_rawmidi_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
struct snd_rawmidi_file *rfile;
@@ -750,33 +847,10 @@ static long snd_rawmidi_ioctl(struct file *file, unsigned int cmd, unsigned long
return -EINVAL;
}
}
- case SNDRV_RAWMIDI_IOCTL_STATUS:
- {
- int err = 0;
- struct snd_rawmidi_status status;
-
- if (copy_from_user(&status, argp, sizeof(struct snd_rawmidi_status)))
- return -EFAULT;
- switch (status.stream) {
- case SNDRV_RAWMIDI_STREAM_OUTPUT:
- if (rfile->output == NULL)
- return -EINVAL;
- err = snd_rawmidi_output_status(rfile->output, &status);
- break;
- case SNDRV_RAWMIDI_STREAM_INPUT:
- if (rfile->input == NULL)
- return -EINVAL;
- err = snd_rawmidi_input_status(rfile->input, &status);
- break;
- default:
- return -EINVAL;
- }
- if (err < 0)
- return err;
- if (copy_to_user(argp, &status, sizeof(struct snd_rawmidi_status)))
- return -EFAULT;
- return 0;
- }
+ case SNDRV_RAWMIDI_IOCTL_STATUS32:
+ return snd_rawmidi_ioctl_status32(rfile, argp);
+ case SNDRV_RAWMIDI_IOCTL_STATUS64:
+ return snd_rawmidi_ioctl_status64(rfile, argp);
case SNDRV_RAWMIDI_IOCTL_DROP:
{
int val;
diff --git a/sound/core/rawmidi_compat.c b/sound/core/rawmidi_compat.c
index 66eee61674b6..7397130976d0 100644
--- a/sound/core/rawmidi_compat.c
+++ b/sound/core/rawmidi_compat.c
@@ -41,19 +41,22 @@ static int snd_rawmidi_ioctl_params_compat(struct snd_rawmidi_file *rfile,
return -EINVAL;
}
-struct snd_rawmidi_status32 {
+struct compat_snd_rawmidi_status64 {
s32 stream;
- struct compat_timespec tstamp;
+ u8 rsvd[4]; /* alignment */
+ s64 tstamp_sec;
+ s64 tstamp_nsec;
u32 avail;
u32 xruns;
unsigned char reserved[16];
} __attribute__((packed));
-static int snd_rawmidi_ioctl_status_compat(struct snd_rawmidi_file *rfile,
- struct snd_rawmidi_status32 __user *src)
+static int snd_rawmidi_ioctl_status_compat64(struct snd_rawmidi_file *rfile,
+ struct compat_snd_rawmidi_status64 __user *src)
{
int err;
- struct snd_rawmidi_status status;
+ struct snd_rawmidi_status64 status;
+ struct compat_snd_rawmidi_status64 compat_status;
if (get_user(status.stream, &src->stream))
return -EFAULT;
@@ -75,68 +78,24 @@ static int snd_rawmidi_ioctl_status_compat(struct snd_rawmidi_file *rfile,
if (err < 0)
return err;
- if (compat_put_timespec(&status.tstamp, &src->tstamp) ||
- put_user(status.avail, &src->avail) ||
- put_user(status.xruns, &src->xruns))
- return -EFAULT;
-
- return 0;
-}
-
-#ifdef CONFIG_X86_X32
-/* X32 ABI has 64bit timespec and 64bit alignment */
-struct snd_rawmidi_status_x32 {
- s32 stream;
- u32 rsvd; /* alignment */
- struct timespec tstamp;
- u32 avail;
- u32 xruns;
- unsigned char reserved[16];
-} __attribute__((packed));
-
-#define put_timespec(src, dst) copy_to_user(dst, src, sizeof(*dst))
-
-static int snd_rawmidi_ioctl_status_x32(struct snd_rawmidi_file *rfile,
- struct snd_rawmidi_status_x32 __user *src)
-{
- int err;
- struct snd_rawmidi_status status;
-
- if (get_user(status.stream, &src->stream))
- return -EFAULT;
-
- switch (status.stream) {
- case SNDRV_RAWMIDI_STREAM_OUTPUT:
- if (!rfile->output)
- return -EINVAL;
- err = snd_rawmidi_output_status(rfile->output, &status);
- break;
- case SNDRV_RAWMIDI_STREAM_INPUT:
- if (!rfile->input)
- return -EINVAL;
- err = snd_rawmidi_input_status(rfile->input, &status);
- break;
- default:
- return -EINVAL;
- }
- if (err < 0)
- return err;
+ compat_status = (struct compat_snd_rawmidi_status64) {
+ .stream = status.stream,
+ .tstamp_sec = status.tstamp_sec,
+ .tstamp_nsec = status.tstamp_nsec,
+ .avail = status.avail,
+ .xruns = status.xruns,
+ };
- if (put_timespec(&status.tstamp, &src->tstamp) ||
- put_user(status.avail, &src->avail) ||
- put_user(status.xruns, &src->xruns))
+ if (copy_to_user(src, &compat_status, sizeof(*src)))
return -EFAULT;
return 0;
}
-#endif /* CONFIG_X86_X32 */
enum {
SNDRV_RAWMIDI_IOCTL_PARAMS32 = _IOWR('W', 0x10, struct snd_rawmidi_params32),
- SNDRV_RAWMIDI_IOCTL_STATUS32 = _IOWR('W', 0x20, struct snd_rawmidi_status32),
-#ifdef CONFIG_X86_X32
- SNDRV_RAWMIDI_IOCTL_STATUS_X32 = _IOWR('W', 0x20, struct snd_rawmidi_status_x32),
-#endif /* CONFIG_X86_X32 */
+ SNDRV_RAWMIDI_IOCTL_STATUS_COMPAT32 = _IOWR('W', 0x20, struct snd_rawmidi_status32),
+ SNDRV_RAWMIDI_IOCTL_STATUS_COMPAT64 = _IOWR('W', 0x20, struct compat_snd_rawmidi_status64),
};
static long snd_rawmidi_ioctl_compat(struct file *file, unsigned int cmd, unsigned long arg)
@@ -153,12 +112,10 @@ static long snd_rawmidi_ioctl_compat(struct file *file, unsigned int cmd, unsign
return snd_rawmidi_ioctl(file, cmd, (unsigned long)argp);
case SNDRV_RAWMIDI_IOCTL_PARAMS32:
return snd_rawmidi_ioctl_params_compat(rfile, argp);
- case SNDRV_RAWMIDI_IOCTL_STATUS32:
- return snd_rawmidi_ioctl_status_compat(rfile, argp);
-#ifdef CONFIG_X86_X32
- case SNDRV_RAWMIDI_IOCTL_STATUS_X32:
- return snd_rawmidi_ioctl_status_x32(rfile, argp);
-#endif /* CONFIG_X86_X32 */
+ case SNDRV_RAWMIDI_IOCTL_STATUS_COMPAT32:
+ return snd_rawmidi_ioctl_status32(rfile, argp);
+ case SNDRV_RAWMIDI_IOCTL_STATUS_COMPAT64:
+ return snd_rawmidi_ioctl_status_compat64(rfile, argp);
}
return -ENOIOCTLCMD;
}
--
2.20.0
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH v7 6/9] ALSA: Avoid using timespec for struct snd_timer_tread
2019-12-11 21:20 ` [alsa-devel] " Arnd Bergmann
@ 2019-12-11 21:20 ` Arnd Bergmann
-1 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-11 21:20 UTC (permalink / raw)
To: alsa-devel, Takashi Iwai
Cc: Baolin Wang, y2038, linux-kernel, Jaroslav Kysela, Mark Brown,
Baolin Wang, Arnd Bergmann
From: Baolin Wang <baolin.wang@linaro.org>
The struct snd_timer_tread will use 'timespec' type variables to record
timestamp, which is not year 2038 safe on 32bits system.
Since the struct snd_timer_tread is passed through read() rather than
ioctl(), and the read syscall has no command number that lets us pick
between the 32-bit or 64-bit version of this structure.
Thus we introduced one new command SNDRV_TIMER_IOCTL_TREAD64 and new
struct snd_timer_tread64 replacing timespec with s64 type to handle
64bit time_t. That means we will set tu->tread = TREAD_FORMAT_64BIT
when user space has a 64bit time_t, then we will copy to user with
struct snd_timer_tread64. Otherwise we will use 32bit time_t variables
when copying to user.
Moreover this patch replaces timespec type with timespec64 type and
related y2038 safe APIs.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/uapi/sound/asound.h | 15 +++-
sound/core/timer.c | 149 +++++++++++++++++++++++++++---------
sound/core/timer_compat.c | 5 +-
3 files changed, 130 insertions(+), 39 deletions(-)
diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
index e0ada33afa1e..ad86c5a7a1e2 100644
--- a/include/uapi/sound/asound.h
+++ b/include/uapi/sound/asound.h
@@ -783,7 +783,7 @@ struct snd_timer_status {
#define SNDRV_TIMER_IOCTL_PVERSION _IOR('T', 0x00, int)
#define SNDRV_TIMER_IOCTL_NEXT_DEVICE _IOWR('T', 0x01, struct snd_timer_id)
-#define SNDRV_TIMER_IOCTL_TREAD _IOW('T', 0x02, int)
+#define SNDRV_TIMER_IOCTL_TREAD_OLD _IOW('T', 0x02, int)
#define SNDRV_TIMER_IOCTL_GINFO _IOWR('T', 0x03, struct snd_timer_ginfo)
#define SNDRV_TIMER_IOCTL_GPARAMS _IOW('T', 0x04, struct snd_timer_gparams)
#define SNDRV_TIMER_IOCTL_GSTATUS _IOWR('T', 0x05, struct snd_timer_gstatus)
@@ -796,6 +796,15 @@ struct snd_timer_status {
#define SNDRV_TIMER_IOCTL_STOP _IO('T', 0xa1)
#define SNDRV_TIMER_IOCTL_CONTINUE _IO('T', 0xa2)
#define SNDRV_TIMER_IOCTL_PAUSE _IO('T', 0xa3)
+#define SNDRV_TIMER_IOCTL_TREAD64 _IOW('T', 0xa4, int)
+
+#if __BITS_PER_LONG == 64
+#define SNDRV_TIMER_IOCTL_TREAD SNDRV_TIMER_IOCTL_TREAD_OLD
+#else
+#define SNDRV_TIMER_IOCTL_TREAD ((sizeof(__kernel_long_t) >= sizeof(time_t)) ? \
+ SNDRV_TIMER_IOCTL_TREAD_OLD : \
+ SNDRV_TIMER_IOCTL_TREAD64)
+#endif
struct snd_timer_read {
unsigned int resolution;
@@ -821,11 +830,15 @@ enum {
SNDRV_TIMER_EVENT_MRESUME = SNDRV_TIMER_EVENT_RESUME + 10,
};
+#ifndef __KERNEL__
struct snd_timer_tread {
int event;
+ __time_pad pad1;
struct timespec tstamp;
unsigned int val;
+ __time_pad pad2;
};
+#endif
/****************************************************************************
* *
diff --git a/sound/core/timer.c b/sound/core/timer.c
index d2f69039f941..b33fd63ce923 100644
--- a/sound/core/timer.c
+++ b/sound/core/timer.c
@@ -44,6 +44,28 @@ MODULE_PARM_DESC(timer_tstamp_monotonic, "Use posix monotonic clock source for t
MODULE_ALIAS_CHARDEV(CONFIG_SND_MAJOR, SNDRV_MINOR_TIMER);
MODULE_ALIAS("devname:snd/timer");
+enum timer_tread_format {
+ TREAD_FORMAT_NONE = 0,
+ TREAD_FORMAT_TIME64,
+ TREAD_FORMAT_TIME32,
+};
+
+struct snd_timer_tread32 {
+ int event;
+ s32 tstamp_sec;
+ s32 tstamp_nsec;
+ unsigned int val;
+};
+
+struct snd_timer_tread64 {
+ int event;
+ u8 pad1[4];
+ s64 tstamp_sec;
+ s64 tstamp_nsec;
+ unsigned int val;
+ u8 pad2[4];
+};
+
struct snd_timer_user {
struct snd_timer_instance *timeri;
int tread; /* enhanced read with timestamps and events */
@@ -55,7 +77,7 @@ struct snd_timer_user {
int queue_size;
bool disconnected;
struct snd_timer_read *queue;
- struct snd_timer_tread *tqueue;
+ struct snd_timer_tread64 *tqueue;
spinlock_t qlock;
unsigned long last_resolution;
unsigned int filter;
@@ -1329,7 +1351,7 @@ static void snd_timer_user_interrupt(struct snd_timer_instance *timeri,
}
static void snd_timer_user_append_to_tqueue(struct snd_timer_user *tu,
- struct snd_timer_tread *tread)
+ struct snd_timer_tread64 *tread)
{
if (tu->qused >= tu->queue_size) {
tu->overrun++;
@@ -1346,7 +1368,7 @@ static void snd_timer_user_ccallback(struct snd_timer_instance *timeri,
unsigned long resolution)
{
struct snd_timer_user *tu = timeri->callback_data;
- struct snd_timer_tread r1;
+ struct snd_timer_tread64 r1;
unsigned long flags;
if (event >= SNDRV_TIMER_EVENT_START &&
@@ -1356,7 +1378,8 @@ static void snd_timer_user_ccallback(struct snd_timer_instance *timeri,
return;
memset(&r1, 0, sizeof(r1));
r1.event = event;
- r1.tstamp = timespec64_to_timespec(*tstamp);
+ r1.tstamp_sec = tstamp->tv_sec;
+ r1.tstamp_nsec = tstamp->tv_nsec;
r1.val = resolution;
spin_lock_irqsave(&tu->qlock, flags);
snd_timer_user_append_to_tqueue(tu, &r1);
@@ -1378,7 +1401,7 @@ static void snd_timer_user_tinterrupt(struct snd_timer_instance *timeri,
unsigned long ticks)
{
struct snd_timer_user *tu = timeri->callback_data;
- struct snd_timer_tread *r, r1;
+ struct snd_timer_tread64 *r, r1;
struct timespec64 tstamp;
int prev, append = 0;
@@ -1399,7 +1422,8 @@ static void snd_timer_user_tinterrupt(struct snd_timer_instance *timeri,
if ((tu->filter & (1 << SNDRV_TIMER_EVENT_RESOLUTION)) &&
tu->last_resolution != resolution) {
r1.event = SNDRV_TIMER_EVENT_RESOLUTION;
- r1.tstamp = timespec64_to_timespec(tstamp);
+ r1.tstamp_sec = tstamp.tv_sec;
+ r1.tstamp_nsec = tstamp.tv_nsec;
r1.val = resolution;
snd_timer_user_append_to_tqueue(tu, &r1);
tu->last_resolution = resolution;
@@ -1413,14 +1437,16 @@ static void snd_timer_user_tinterrupt(struct snd_timer_instance *timeri,
prev = tu->qtail == 0 ? tu->queue_size - 1 : tu->qtail - 1;
r = &tu->tqueue[prev];
if (r->event == SNDRV_TIMER_EVENT_TICK) {
- r->tstamp = timespec64_to_timespec(tstamp);
+ r->tstamp_sec = tstamp.tv_sec;
+ r->tstamp_nsec = tstamp.tv_nsec;
r->val += ticks;
append++;
goto __wake;
}
}
r1.event = SNDRV_TIMER_EVENT_TICK;
- r1.tstamp = timespec64_to_timespec(tstamp);
+ r1.tstamp_sec = tstamp.tv_sec;
+ r1.tstamp_nsec = tstamp.tv_nsec;
r1.val = ticks;
snd_timer_user_append_to_tqueue(tu, &r1);
append++;
@@ -1435,7 +1461,7 @@ static void snd_timer_user_tinterrupt(struct snd_timer_instance *timeri,
static int realloc_user_queue(struct snd_timer_user *tu, int size)
{
struct snd_timer_read *queue = NULL;
- struct snd_timer_tread *tqueue = NULL;
+ struct snd_timer_tread64 *tqueue = NULL;
if (tu->tread) {
tqueue = kcalloc(size, sizeof(*tqueue), GFP_KERNEL);
@@ -1874,11 +1900,11 @@ static int snd_timer_user_params(struct file *file,
tu->qhead = tu->qtail = tu->qused = 0;
if (tu->timeri->flags & SNDRV_TIMER_IFLG_EARLY_EVENT) {
if (tu->tread) {
- struct snd_timer_tread tread;
+ struct snd_timer_tread64 tread;
memset(&tread, 0, sizeof(tread));
tread.event = SNDRV_TIMER_EVENT_EARLY;
- tread.tstamp.tv_sec = 0;
- tread.tstamp.tv_nsec = 0;
+ tread.tstamp_sec = 0;
+ tread.tstamp_nsec = 0;
tread.val = 0;
snd_timer_user_append_to_tqueue(tu, &tread);
} else {
@@ -2008,6 +2034,36 @@ static int snd_timer_user_pause(struct file *file)
return 0;
}
+static int snd_timer_user_tread(void __user *argp, struct snd_timer_user *tu,
+ unsigned int cmd, bool compat)
+{
+ int __user *p = argp;
+ int xarg, old_tread;
+
+ if (tu->timeri) /* too late */
+ return -EBUSY;
+ if (get_user(xarg, p))
+ return -EFAULT;
+
+ old_tread = tu->tread;
+
+ if (!xarg)
+ tu->tread = TREAD_FORMAT_NONE;
+ else if (cmd == SNDRV_TIMER_IOCTL_TREAD64 ||
+ (IS_ENABLED(CONFIG_64BITS) && !compat))
+ tu->tread = TREAD_FORMAT_TIME64;
+ else
+ tu->tread = TREAD_FORMAT_TIME32;
+
+ if (tu->tread != old_tread &&
+ realloc_user_queue(tu, tu->queue_size) < 0) {
+ tu->tread = old_tread;
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
enum {
SNDRV_TIMER_IOCTL_START_OLD = _IO('T', 0x20),
SNDRV_TIMER_IOCTL_STOP_OLD = _IO('T', 0x21),
@@ -2016,7 +2072,7 @@ enum {
};
static long __snd_timer_user_ioctl(struct file *file, unsigned int cmd,
- unsigned long arg)
+ unsigned long arg, bool compat)
{
struct snd_timer_user *tu;
void __user *argp = (void __user *)arg;
@@ -2028,23 +2084,9 @@ static long __snd_timer_user_ioctl(struct file *file, unsigned int cmd,
return put_user(SNDRV_TIMER_VERSION, p) ? -EFAULT : 0;
case SNDRV_TIMER_IOCTL_NEXT_DEVICE:
return snd_timer_user_next_device(argp);
- case SNDRV_TIMER_IOCTL_TREAD:
- {
- int xarg, old_tread;
-
- if (tu->timeri) /* too late */
- return -EBUSY;
- if (get_user(xarg, p))
- return -EFAULT;
- old_tread = tu->tread;
- tu->tread = xarg ? 1 : 0;
- if (tu->tread != old_tread &&
- realloc_user_queue(tu, tu->queue_size) < 0) {
- tu->tread = old_tread;
- return -ENOMEM;
- }
- return 0;
- }
+ case SNDRV_TIMER_IOCTL_TREAD_OLD:
+ case SNDRV_TIMER_IOCTL_TREAD64:
+ return snd_timer_user_tread(argp, tu, cmd, compat);
case SNDRV_TIMER_IOCTL_GINFO:
return snd_timer_user_ginfo(file, argp);
case SNDRV_TIMER_IOCTL_GPARAMS:
@@ -2084,7 +2126,7 @@ static long snd_timer_user_ioctl(struct file *file, unsigned int cmd,
long ret;
mutex_lock(&tu->ioctl_lock);
- ret = __snd_timer_user_ioctl(file, cmd, arg);
+ ret = __snd_timer_user_ioctl(file, cmd, arg, false);
mutex_unlock(&tu->ioctl_lock);
return ret;
}
@@ -2100,13 +2142,28 @@ static int snd_timer_user_fasync(int fd, struct file * file, int on)
static ssize_t snd_timer_user_read(struct file *file, char __user *buffer,
size_t count, loff_t *offset)
{
+ struct snd_timer_tread64 *tread;
+ struct snd_timer_tread32 tread32;
struct snd_timer_user *tu;
long result = 0, unit;
int qhead;
int err = 0;
tu = file->private_data;
- unit = tu->tread ? sizeof(struct snd_timer_tread) : sizeof(struct snd_timer_read);
+ switch (tu->tread) {
+ case TREAD_FORMAT_TIME64:
+ unit = sizeof(struct snd_timer_tread64);
+ break;
+ case TREAD_FORMAT_TIME32:
+ unit = sizeof(struct snd_timer_tread32);
+ break;
+ case TREAD_FORMAT_NONE:
+ unit = sizeof(struct snd_timer_read);
+ break;
+ default:
+ return -ENOTSUPP;
+ }
+
mutex_lock(&tu->ioctl_lock);
spin_lock_irq(&tu->qlock);
while ((long)count - result >= unit) {
@@ -2145,14 +2202,34 @@ static ssize_t snd_timer_user_read(struct file *file, char __user *buffer,
tu->qused--;
spin_unlock_irq(&tu->qlock);
- if (tu->tread) {
- if (copy_to_user(buffer, &tu->tqueue[qhead],
- sizeof(struct snd_timer_tread)))
+ tread = &tu->tqueue[qhead];
+
+ switch (tu->tread) {
+ case TREAD_FORMAT_TIME64:
+ if (copy_to_user(buffer, tread,
+ sizeof(struct snd_timer_tread64)))
err = -EFAULT;
- } else {
+ break;
+ case TREAD_FORMAT_TIME32:
+ memset(&tread32, 0, sizeof(tread32));
+ tread32 = (struct snd_timer_tread32) {
+ .event = tread->event,
+ .tstamp_sec = tread->tstamp_sec,
+ .tstamp_sec = tread->tstamp_nsec,
+ .val = tread->val,
+ };
+
+ if (copy_to_user(buffer, &tread32, sizeof(tread32)))
+ err = -EFAULT;
+ break;
+ case TREAD_FORMAT_NONE:
if (copy_to_user(buffer, &tu->queue[qhead],
sizeof(struct snd_timer_read)))
err = -EFAULT;
+ break;
+ default:
+ err = -ENOTSUPP;
+ break;
}
spin_lock_irq(&tu->qlock);
diff --git a/sound/core/timer_compat.c b/sound/core/timer_compat.c
index 20eef5bc304b..0103d16f6f9f 100644
--- a/sound/core/timer_compat.c
+++ b/sound/core/timer_compat.c
@@ -83,7 +83,8 @@ static long __snd_timer_user_ioctl_compat(struct file *file, unsigned int cmd,
switch (cmd) {
case SNDRV_TIMER_IOCTL_PVERSION:
- case SNDRV_TIMER_IOCTL_TREAD:
+ case SNDRV_TIMER_IOCTL_TREAD_OLD:
+ case SNDRV_TIMER_IOCTL_TREAD64:
case SNDRV_TIMER_IOCTL_GINFO:
case SNDRV_TIMER_IOCTL_GSTATUS:
case SNDRV_TIMER_IOCTL_SELECT:
@@ -97,7 +98,7 @@ static long __snd_timer_user_ioctl_compat(struct file *file, unsigned int cmd,
case SNDRV_TIMER_IOCTL_PAUSE:
case SNDRV_TIMER_IOCTL_PAUSE_OLD:
case SNDRV_TIMER_IOCTL_NEXT_DEVICE:
- return __snd_timer_user_ioctl(file, cmd, (unsigned long)argp);
+ return __snd_timer_user_ioctl(file, cmd, (unsigned long)argp, true);
case SNDRV_TIMER_IOCTL_GPARAMS32:
return snd_timer_user_gparams_compat(file, argp);
case SNDRV_TIMER_IOCTL_INFO32:
--
2.20.0
^ permalink raw reply related [flat|nested] 94+ messages in thread* [alsa-devel] [PATCH v7 6/9] ALSA: Avoid using timespec for struct snd_timer_tread
@ 2019-12-11 21:20 ` Arnd Bergmann
0 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-11 21:20 UTC (permalink / raw)
To: alsa-devel, Takashi Iwai
Cc: Arnd Bergmann, Baolin Wang, y2038, linux-kernel, Mark Brown, Baolin Wang
From: Baolin Wang <baolin.wang@linaro.org>
The struct snd_timer_tread will use 'timespec' type variables to record
timestamp, which is not year 2038 safe on 32bits system.
Since the struct snd_timer_tread is passed through read() rather than
ioctl(), and the read syscall has no command number that lets us pick
between the 32-bit or 64-bit version of this structure.
Thus we introduced one new command SNDRV_TIMER_IOCTL_TREAD64 and new
struct snd_timer_tread64 replacing timespec with s64 type to handle
64bit time_t. That means we will set tu->tread = TREAD_FORMAT_64BIT
when user space has a 64bit time_t, then we will copy to user with
struct snd_timer_tread64. Otherwise we will use 32bit time_t variables
when copying to user.
Moreover this patch replaces timespec type with timespec64 type and
related y2038 safe APIs.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/uapi/sound/asound.h | 15 +++-
sound/core/timer.c | 149 +++++++++++++++++++++++++++---------
sound/core/timer_compat.c | 5 +-
3 files changed, 130 insertions(+), 39 deletions(-)
diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
index e0ada33afa1e..ad86c5a7a1e2 100644
--- a/include/uapi/sound/asound.h
+++ b/include/uapi/sound/asound.h
@@ -783,7 +783,7 @@ struct snd_timer_status {
#define SNDRV_TIMER_IOCTL_PVERSION _IOR('T', 0x00, int)
#define SNDRV_TIMER_IOCTL_NEXT_DEVICE _IOWR('T', 0x01, struct snd_timer_id)
-#define SNDRV_TIMER_IOCTL_TREAD _IOW('T', 0x02, int)
+#define SNDRV_TIMER_IOCTL_TREAD_OLD _IOW('T', 0x02, int)
#define SNDRV_TIMER_IOCTL_GINFO _IOWR('T', 0x03, struct snd_timer_ginfo)
#define SNDRV_TIMER_IOCTL_GPARAMS _IOW('T', 0x04, struct snd_timer_gparams)
#define SNDRV_TIMER_IOCTL_GSTATUS _IOWR('T', 0x05, struct snd_timer_gstatus)
@@ -796,6 +796,15 @@ struct snd_timer_status {
#define SNDRV_TIMER_IOCTL_STOP _IO('T', 0xa1)
#define SNDRV_TIMER_IOCTL_CONTINUE _IO('T', 0xa2)
#define SNDRV_TIMER_IOCTL_PAUSE _IO('T', 0xa3)
+#define SNDRV_TIMER_IOCTL_TREAD64 _IOW('T', 0xa4, int)
+
+#if __BITS_PER_LONG == 64
+#define SNDRV_TIMER_IOCTL_TREAD SNDRV_TIMER_IOCTL_TREAD_OLD
+#else
+#define SNDRV_TIMER_IOCTL_TREAD ((sizeof(__kernel_long_t) >= sizeof(time_t)) ? \
+ SNDRV_TIMER_IOCTL_TREAD_OLD : \
+ SNDRV_TIMER_IOCTL_TREAD64)
+#endif
struct snd_timer_read {
unsigned int resolution;
@@ -821,11 +830,15 @@ enum {
SNDRV_TIMER_EVENT_MRESUME = SNDRV_TIMER_EVENT_RESUME + 10,
};
+#ifndef __KERNEL__
struct snd_timer_tread {
int event;
+ __time_pad pad1;
struct timespec tstamp;
unsigned int val;
+ __time_pad pad2;
};
+#endif
/****************************************************************************
* *
diff --git a/sound/core/timer.c b/sound/core/timer.c
index d2f69039f941..b33fd63ce923 100644
--- a/sound/core/timer.c
+++ b/sound/core/timer.c
@@ -44,6 +44,28 @@ MODULE_PARM_DESC(timer_tstamp_monotonic, "Use posix monotonic clock source for t
MODULE_ALIAS_CHARDEV(CONFIG_SND_MAJOR, SNDRV_MINOR_TIMER);
MODULE_ALIAS("devname:snd/timer");
+enum timer_tread_format {
+ TREAD_FORMAT_NONE = 0,
+ TREAD_FORMAT_TIME64,
+ TREAD_FORMAT_TIME32,
+};
+
+struct snd_timer_tread32 {
+ int event;
+ s32 tstamp_sec;
+ s32 tstamp_nsec;
+ unsigned int val;
+};
+
+struct snd_timer_tread64 {
+ int event;
+ u8 pad1[4];
+ s64 tstamp_sec;
+ s64 tstamp_nsec;
+ unsigned int val;
+ u8 pad2[4];
+};
+
struct snd_timer_user {
struct snd_timer_instance *timeri;
int tread; /* enhanced read with timestamps and events */
@@ -55,7 +77,7 @@ struct snd_timer_user {
int queue_size;
bool disconnected;
struct snd_timer_read *queue;
- struct snd_timer_tread *tqueue;
+ struct snd_timer_tread64 *tqueue;
spinlock_t qlock;
unsigned long last_resolution;
unsigned int filter;
@@ -1329,7 +1351,7 @@ static void snd_timer_user_interrupt(struct snd_timer_instance *timeri,
}
static void snd_timer_user_append_to_tqueue(struct snd_timer_user *tu,
- struct snd_timer_tread *tread)
+ struct snd_timer_tread64 *tread)
{
if (tu->qused >= tu->queue_size) {
tu->overrun++;
@@ -1346,7 +1368,7 @@ static void snd_timer_user_ccallback(struct snd_timer_instance *timeri,
unsigned long resolution)
{
struct snd_timer_user *tu = timeri->callback_data;
- struct snd_timer_tread r1;
+ struct snd_timer_tread64 r1;
unsigned long flags;
if (event >= SNDRV_TIMER_EVENT_START &&
@@ -1356,7 +1378,8 @@ static void snd_timer_user_ccallback(struct snd_timer_instance *timeri,
return;
memset(&r1, 0, sizeof(r1));
r1.event = event;
- r1.tstamp = timespec64_to_timespec(*tstamp);
+ r1.tstamp_sec = tstamp->tv_sec;
+ r1.tstamp_nsec = tstamp->tv_nsec;
r1.val = resolution;
spin_lock_irqsave(&tu->qlock, flags);
snd_timer_user_append_to_tqueue(tu, &r1);
@@ -1378,7 +1401,7 @@ static void snd_timer_user_tinterrupt(struct snd_timer_instance *timeri,
unsigned long ticks)
{
struct snd_timer_user *tu = timeri->callback_data;
- struct snd_timer_tread *r, r1;
+ struct snd_timer_tread64 *r, r1;
struct timespec64 tstamp;
int prev, append = 0;
@@ -1399,7 +1422,8 @@ static void snd_timer_user_tinterrupt(struct snd_timer_instance *timeri,
if ((tu->filter & (1 << SNDRV_TIMER_EVENT_RESOLUTION)) &&
tu->last_resolution != resolution) {
r1.event = SNDRV_TIMER_EVENT_RESOLUTION;
- r1.tstamp = timespec64_to_timespec(tstamp);
+ r1.tstamp_sec = tstamp.tv_sec;
+ r1.tstamp_nsec = tstamp.tv_nsec;
r1.val = resolution;
snd_timer_user_append_to_tqueue(tu, &r1);
tu->last_resolution = resolution;
@@ -1413,14 +1437,16 @@ static void snd_timer_user_tinterrupt(struct snd_timer_instance *timeri,
prev = tu->qtail == 0 ? tu->queue_size - 1 : tu->qtail - 1;
r = &tu->tqueue[prev];
if (r->event == SNDRV_TIMER_EVENT_TICK) {
- r->tstamp = timespec64_to_timespec(tstamp);
+ r->tstamp_sec = tstamp.tv_sec;
+ r->tstamp_nsec = tstamp.tv_nsec;
r->val += ticks;
append++;
goto __wake;
}
}
r1.event = SNDRV_TIMER_EVENT_TICK;
- r1.tstamp = timespec64_to_timespec(tstamp);
+ r1.tstamp_sec = tstamp.tv_sec;
+ r1.tstamp_nsec = tstamp.tv_nsec;
r1.val = ticks;
snd_timer_user_append_to_tqueue(tu, &r1);
append++;
@@ -1435,7 +1461,7 @@ static void snd_timer_user_tinterrupt(struct snd_timer_instance *timeri,
static int realloc_user_queue(struct snd_timer_user *tu, int size)
{
struct snd_timer_read *queue = NULL;
- struct snd_timer_tread *tqueue = NULL;
+ struct snd_timer_tread64 *tqueue = NULL;
if (tu->tread) {
tqueue = kcalloc(size, sizeof(*tqueue), GFP_KERNEL);
@@ -1874,11 +1900,11 @@ static int snd_timer_user_params(struct file *file,
tu->qhead = tu->qtail = tu->qused = 0;
if (tu->timeri->flags & SNDRV_TIMER_IFLG_EARLY_EVENT) {
if (tu->tread) {
- struct snd_timer_tread tread;
+ struct snd_timer_tread64 tread;
memset(&tread, 0, sizeof(tread));
tread.event = SNDRV_TIMER_EVENT_EARLY;
- tread.tstamp.tv_sec = 0;
- tread.tstamp.tv_nsec = 0;
+ tread.tstamp_sec = 0;
+ tread.tstamp_nsec = 0;
tread.val = 0;
snd_timer_user_append_to_tqueue(tu, &tread);
} else {
@@ -2008,6 +2034,36 @@ static int snd_timer_user_pause(struct file *file)
return 0;
}
+static int snd_timer_user_tread(void __user *argp, struct snd_timer_user *tu,
+ unsigned int cmd, bool compat)
+{
+ int __user *p = argp;
+ int xarg, old_tread;
+
+ if (tu->timeri) /* too late */
+ return -EBUSY;
+ if (get_user(xarg, p))
+ return -EFAULT;
+
+ old_tread = tu->tread;
+
+ if (!xarg)
+ tu->tread = TREAD_FORMAT_NONE;
+ else if (cmd == SNDRV_TIMER_IOCTL_TREAD64 ||
+ (IS_ENABLED(CONFIG_64BITS) && !compat))
+ tu->tread = TREAD_FORMAT_TIME64;
+ else
+ tu->tread = TREAD_FORMAT_TIME32;
+
+ if (tu->tread != old_tread &&
+ realloc_user_queue(tu, tu->queue_size) < 0) {
+ tu->tread = old_tread;
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
enum {
SNDRV_TIMER_IOCTL_START_OLD = _IO('T', 0x20),
SNDRV_TIMER_IOCTL_STOP_OLD = _IO('T', 0x21),
@@ -2016,7 +2072,7 @@ enum {
};
static long __snd_timer_user_ioctl(struct file *file, unsigned int cmd,
- unsigned long arg)
+ unsigned long arg, bool compat)
{
struct snd_timer_user *tu;
void __user *argp = (void __user *)arg;
@@ -2028,23 +2084,9 @@ static long __snd_timer_user_ioctl(struct file *file, unsigned int cmd,
return put_user(SNDRV_TIMER_VERSION, p) ? -EFAULT : 0;
case SNDRV_TIMER_IOCTL_NEXT_DEVICE:
return snd_timer_user_next_device(argp);
- case SNDRV_TIMER_IOCTL_TREAD:
- {
- int xarg, old_tread;
-
- if (tu->timeri) /* too late */
- return -EBUSY;
- if (get_user(xarg, p))
- return -EFAULT;
- old_tread = tu->tread;
- tu->tread = xarg ? 1 : 0;
- if (tu->tread != old_tread &&
- realloc_user_queue(tu, tu->queue_size) < 0) {
- tu->tread = old_tread;
- return -ENOMEM;
- }
- return 0;
- }
+ case SNDRV_TIMER_IOCTL_TREAD_OLD:
+ case SNDRV_TIMER_IOCTL_TREAD64:
+ return snd_timer_user_tread(argp, tu, cmd, compat);
case SNDRV_TIMER_IOCTL_GINFO:
return snd_timer_user_ginfo(file, argp);
case SNDRV_TIMER_IOCTL_GPARAMS:
@@ -2084,7 +2126,7 @@ static long snd_timer_user_ioctl(struct file *file, unsigned int cmd,
long ret;
mutex_lock(&tu->ioctl_lock);
- ret = __snd_timer_user_ioctl(file, cmd, arg);
+ ret = __snd_timer_user_ioctl(file, cmd, arg, false);
mutex_unlock(&tu->ioctl_lock);
return ret;
}
@@ -2100,13 +2142,28 @@ static int snd_timer_user_fasync(int fd, struct file * file, int on)
static ssize_t snd_timer_user_read(struct file *file, char __user *buffer,
size_t count, loff_t *offset)
{
+ struct snd_timer_tread64 *tread;
+ struct snd_timer_tread32 tread32;
struct snd_timer_user *tu;
long result = 0, unit;
int qhead;
int err = 0;
tu = file->private_data;
- unit = tu->tread ? sizeof(struct snd_timer_tread) : sizeof(struct snd_timer_read);
+ switch (tu->tread) {
+ case TREAD_FORMAT_TIME64:
+ unit = sizeof(struct snd_timer_tread64);
+ break;
+ case TREAD_FORMAT_TIME32:
+ unit = sizeof(struct snd_timer_tread32);
+ break;
+ case TREAD_FORMAT_NONE:
+ unit = sizeof(struct snd_timer_read);
+ break;
+ default:
+ return -ENOTSUPP;
+ }
+
mutex_lock(&tu->ioctl_lock);
spin_lock_irq(&tu->qlock);
while ((long)count - result >= unit) {
@@ -2145,14 +2202,34 @@ static ssize_t snd_timer_user_read(struct file *file, char __user *buffer,
tu->qused--;
spin_unlock_irq(&tu->qlock);
- if (tu->tread) {
- if (copy_to_user(buffer, &tu->tqueue[qhead],
- sizeof(struct snd_timer_tread)))
+ tread = &tu->tqueue[qhead];
+
+ switch (tu->tread) {
+ case TREAD_FORMAT_TIME64:
+ if (copy_to_user(buffer, tread,
+ sizeof(struct snd_timer_tread64)))
err = -EFAULT;
- } else {
+ break;
+ case TREAD_FORMAT_TIME32:
+ memset(&tread32, 0, sizeof(tread32));
+ tread32 = (struct snd_timer_tread32) {
+ .event = tread->event,
+ .tstamp_sec = tread->tstamp_sec,
+ .tstamp_sec = tread->tstamp_nsec,
+ .val = tread->val,
+ };
+
+ if (copy_to_user(buffer, &tread32, sizeof(tread32)))
+ err = -EFAULT;
+ break;
+ case TREAD_FORMAT_NONE:
if (copy_to_user(buffer, &tu->queue[qhead],
sizeof(struct snd_timer_read)))
err = -EFAULT;
+ break;
+ default:
+ err = -ENOTSUPP;
+ break;
}
spin_lock_irq(&tu->qlock);
diff --git a/sound/core/timer_compat.c b/sound/core/timer_compat.c
index 20eef5bc304b..0103d16f6f9f 100644
--- a/sound/core/timer_compat.c
+++ b/sound/core/timer_compat.c
@@ -83,7 +83,8 @@ static long __snd_timer_user_ioctl_compat(struct file *file, unsigned int cmd,
switch (cmd) {
case SNDRV_TIMER_IOCTL_PVERSION:
- case SNDRV_TIMER_IOCTL_TREAD:
+ case SNDRV_TIMER_IOCTL_TREAD_OLD:
+ case SNDRV_TIMER_IOCTL_TREAD64:
case SNDRV_TIMER_IOCTL_GINFO:
case SNDRV_TIMER_IOCTL_GSTATUS:
case SNDRV_TIMER_IOCTL_SELECT:
@@ -97,7 +98,7 @@ static long __snd_timer_user_ioctl_compat(struct file *file, unsigned int cmd,
case SNDRV_TIMER_IOCTL_PAUSE:
case SNDRV_TIMER_IOCTL_PAUSE_OLD:
case SNDRV_TIMER_IOCTL_NEXT_DEVICE:
- return __snd_timer_user_ioctl(file, cmd, (unsigned long)argp);
+ return __snd_timer_user_ioctl(file, cmd, (unsigned long)argp, true);
case SNDRV_TIMER_IOCTL_GPARAMS32:
return snd_timer_user_gparams_compat(file, argp);
case SNDRV_TIMER_IOCTL_INFO32:
--
2.20.0
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply related [flat|nested] 94+ messages in thread* Re: [Y2038] [PATCH v7 6/9] ALSA: Avoid using timespec for struct snd_timer_tread
2019-12-11 21:20 ` [alsa-devel] " Arnd Bergmann
@ 2019-12-12 0:14 ` Ben Hutchings
-1 siblings, 0 replies; 94+ messages in thread
From: Ben Hutchings @ 2019-12-12 0:14 UTC (permalink / raw)
To: Arnd Bergmann, alsa-devel, Takashi Iwai
Cc: Baolin Wang, y2038, linux-kernel, Jaroslav Kysela, Mark Brown,
Baolin Wang
On Wed, 2019-12-11 at 22:20 +0100, Arnd Bergmann wrote:
[...]
> +static int snd_timer_user_tread(void __user *argp, struct snd_timer_user *tu,
> + unsigned int cmd, bool compat)
> +{
> + int __user *p = argp;
> + int xarg, old_tread;
> +
> + if (tu->timeri) /* too late */
> + return -EBUSY;
> + if (get_user(xarg, p))
> + return -EFAULT;
> +
> + old_tread = tu->tread;
> +
> + if (!xarg)
> + tu->tread = TREAD_FORMAT_NONE;
> + else if (cmd == SNDRV_TIMER_IOCTL_TREAD64 ||
> + (IS_ENABLED(CONFIG_64BITS) && !compat))
This needs to check for CONFIG_64BIT not CONFIG_64BITS.
[...]
> @@ -2145,14 +2202,34 @@ static ssize_t snd_timer_user_read(struct file *file, char __user *buffer,
> tu->qused--;
> spin_unlock_irq(&tu->qlock);
>
> - if (tu->tread) {
> - if (copy_to_user(buffer, &tu->tqueue[qhead],
> - sizeof(struct snd_timer_tread)))
> + tread = &tu->tqueue[qhead];
> +
> + switch (tu->tread) {
> + case TREAD_FORMAT_TIME64:
> + if (copy_to_user(buffer, tread,
> + sizeof(struct snd_timer_tread64)))
> err = -EFAULT;
> - } else {
> + break;
> + case TREAD_FORMAT_TIME32:
> + memset(&tread32, 0, sizeof(tread32));
> + tread32 = (struct snd_timer_tread32) {
> + .event = tread->event,
> + .tstamp_sec = tread->tstamp_sec,
> + .tstamp_sec = tread->tstamp_nsec,
> + .val = tread->val,
> + };
> +
> + if (copy_to_user(buffer, &tread32, sizeof(tread32)))
> + err = -EFAULT;
> + break;
> + case TREAD_FORMAT_NONE:
> if (copy_to_user(buffer, &tu->queue[qhead],
> sizeof(struct snd_timer_read)))
> err = -EFAULT;
> + break;
> + default:
> + err = -ENOTSUPP;
[...]
This is not a valid error code for returning to user-space, but this
case should be impossible so I don't think it matters.
Ben.
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [alsa-devel] [Y2038] [PATCH v7 6/9] ALSA: Avoid using timespec for struct snd_timer_tread
@ 2019-12-12 0:14 ` Ben Hutchings
0 siblings, 0 replies; 94+ messages in thread
From: Ben Hutchings @ 2019-12-12 0:14 UTC (permalink / raw)
To: Arnd Bergmann, alsa-devel, Takashi Iwai
Cc: Baolin Wang, y2038, linux-kernel, Mark Brown, Baolin Wang
On Wed, 2019-12-11 at 22:20 +0100, Arnd Bergmann wrote:
[...]
> +static int snd_timer_user_tread(void __user *argp, struct snd_timer_user *tu,
> + unsigned int cmd, bool compat)
> +{
> + int __user *p = argp;
> + int xarg, old_tread;
> +
> + if (tu->timeri) /* too late */
> + return -EBUSY;
> + if (get_user(xarg, p))
> + return -EFAULT;
> +
> + old_tread = tu->tread;
> +
> + if (!xarg)
> + tu->tread = TREAD_FORMAT_NONE;
> + else if (cmd == SNDRV_TIMER_IOCTL_TREAD64 ||
> + (IS_ENABLED(CONFIG_64BITS) && !compat))
This needs to check for CONFIG_64BIT not CONFIG_64BITS.
[...]
> @@ -2145,14 +2202,34 @@ static ssize_t snd_timer_user_read(struct file *file, char __user *buffer,
> tu->qused--;
> spin_unlock_irq(&tu->qlock);
>
> - if (tu->tread) {
> - if (copy_to_user(buffer, &tu->tqueue[qhead],
> - sizeof(struct snd_timer_tread)))
> + tread = &tu->tqueue[qhead];
> +
> + switch (tu->tread) {
> + case TREAD_FORMAT_TIME64:
> + if (copy_to_user(buffer, tread,
> + sizeof(struct snd_timer_tread64)))
> err = -EFAULT;
> - } else {
> + break;
> + case TREAD_FORMAT_TIME32:
> + memset(&tread32, 0, sizeof(tread32));
> + tread32 = (struct snd_timer_tread32) {
> + .event = tread->event,
> + .tstamp_sec = tread->tstamp_sec,
> + .tstamp_sec = tread->tstamp_nsec,
> + .val = tread->val,
> + };
> +
> + if (copy_to_user(buffer, &tread32, sizeof(tread32)))
> + err = -EFAULT;
> + break;
> + case TREAD_FORMAT_NONE:
> if (copy_to_user(buffer, &tu->queue[qhead],
> sizeof(struct snd_timer_read)))
> err = -EFAULT;
> + break;
> + default:
> + err = -ENOTSUPP;
[...]
This is not a valid error code for returning to user-space, but this
case should be impossible so I don't think it matters.
Ben.
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [Y2038] [PATCH v7 6/9] ALSA: Avoid using timespec for struct snd_timer_tread
2019-12-12 0:14 ` [alsa-devel] " Ben Hutchings
@ 2019-12-12 9:57 ` Arnd Bergmann
-1 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-12 9:57 UTC (permalink / raw)
To: Ben Hutchings
Cc: ALSA Development Mailing List, Takashi Iwai, Baolin Wang,
y2038 Mailman List, linux-kernel, Jaroslav Kysela, Mark Brown,
Baolin Wang
On Thu, Dec 12, 2019 at 1:14 AM Ben Hutchings
<ben.hutchings@codethink.co.uk> wrote:
>
> On Wed, 2019-12-11 at 22:20 +0100, Arnd Bergmann wrote:
> [...]
> > +static int snd_timer_user_tread(void __user *argp, struct snd_timer_user *tu,
> > + unsigned int cmd, bool compat)
> > +{
> > + int __user *p = argp;
> > + int xarg, old_tread;
> > +
> > + if (tu->timeri) /* too late */
> > + return -EBUSY;
> > + if (get_user(xarg, p))
> > + return -EFAULT;
> > +
> > + old_tread = tu->tread;
> > +
> > + if (!xarg)
> > + tu->tread = TREAD_FORMAT_NONE;
> > + else if (cmd == SNDRV_TIMER_IOCTL_TREAD64 ||
> > + (IS_ENABLED(CONFIG_64BITS) && !compat))
>
> This needs to check for CONFIG_64BIT not CONFIG_64BITS.
Fixed now, good catch!
> > @@ -2145,14 +2202,34 @@ static ssize_t snd_timer_user_read(struct file *file, char __user *buffer,
> > + case TREAD_FORMAT_NONE:
> > if (copy_to_user(buffer, &tu->queue[qhead],
> > sizeof(struct snd_timer_read)))
> > err = -EFAULT;
> > + break;
> > + default:
> > + err = -ENOTSUPP;
> [...]
>
> This is not a valid error code for returning to user-space, but this
> case should be impossible so I don't think it matters.
Agreed. Maybe it should also WARN_ON(1), as there getting here
would indicate a bug in the kernel.
Arnd
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [alsa-devel] [Y2038] [PATCH v7 6/9] ALSA: Avoid using timespec for struct snd_timer_tread
@ 2019-12-12 9:57 ` Arnd Bergmann
0 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-12 9:57 UTC (permalink / raw)
To: Ben Hutchings
Cc: ALSA Development Mailing List, Baolin Wang, y2038 Mailman List,
Takashi Iwai, linux-kernel, Mark Brown, Baolin Wang
On Thu, Dec 12, 2019 at 1:14 AM Ben Hutchings
<ben.hutchings@codethink.co.uk> wrote:
>
> On Wed, 2019-12-11 at 22:20 +0100, Arnd Bergmann wrote:
> [...]
> > +static int snd_timer_user_tread(void __user *argp, struct snd_timer_user *tu,
> > + unsigned int cmd, bool compat)
> > +{
> > + int __user *p = argp;
> > + int xarg, old_tread;
> > +
> > + if (tu->timeri) /* too late */
> > + return -EBUSY;
> > + if (get_user(xarg, p))
> > + return -EFAULT;
> > +
> > + old_tread = tu->tread;
> > +
> > + if (!xarg)
> > + tu->tread = TREAD_FORMAT_NONE;
> > + else if (cmd == SNDRV_TIMER_IOCTL_TREAD64 ||
> > + (IS_ENABLED(CONFIG_64BITS) && !compat))
>
> This needs to check for CONFIG_64BIT not CONFIG_64BITS.
Fixed now, good catch!
> > @@ -2145,14 +2202,34 @@ static ssize_t snd_timer_user_read(struct file *file, char __user *buffer,
> > + case TREAD_FORMAT_NONE:
> > if (copy_to_user(buffer, &tu->queue[qhead],
> > sizeof(struct snd_timer_read)))
> > err = -EFAULT;
> > + break;
> > + default:
> > + err = -ENOTSUPP;
> [...]
>
> This is not a valid error code for returning to user-space, but this
> case should be impossible so I don't think it matters.
Agreed. Maybe it should also WARN_ON(1), as there getting here
would indicate a bug in the kernel.
Arnd
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [Y2038] [PATCH v7 6/9] ALSA: Avoid using timespec for struct snd_timer_tread
2019-12-12 9:57 ` [alsa-devel] " Arnd Bergmann
@ 2019-12-12 14:27 ` Ben Hutchings
-1 siblings, 0 replies; 94+ messages in thread
From: Ben Hutchings @ 2019-12-12 14:27 UTC (permalink / raw)
To: Arnd Bergmann
Cc: ALSA Development Mailing List, Takashi Iwai, Baolin Wang,
y2038 Mailman List, linux-kernel, Jaroslav Kysela, Mark Brown,
Baolin Wang
On Thu, 2019-12-12 at 10:57 +0100, Arnd Bergmann wrote:
> On Thu, Dec 12, 2019 at 1:14 AM Ben Hutchings
> <ben.hutchings@codethink.co.uk> wrote:
> > On Wed, 2019-12-11 at 22:20 +0100, Arnd Bergmann wrote:
> > [...]
> > > +static int snd_timer_user_tread(void __user *argp, struct snd_timer_user *tu,
> > > + unsigned int cmd, bool compat)
> > > +{
> > > + int __user *p = argp;
> > > + int xarg, old_tread;
> > > +
> > > + if (tu->timeri) /* too late */
> > > + return -EBUSY;
> > > + if (get_user(xarg, p))
> > > + return -EFAULT;
> > > +
> > > + old_tread = tu->tread;
> > > +
> > > + if (!xarg)
> > > + tu->tread = TREAD_FORMAT_NONE;
> > > + else if (cmd == SNDRV_TIMER_IOCTL_TREAD64 ||
> > > + (IS_ENABLED(CONFIG_64BITS) && !compat))
> >
> > This needs to check for CONFIG_64BIT not CONFIG_64BITS.
>
> Fixed now, good catch!
>
> > > @@ -2145,14 +2202,34 @@ static ssize_t snd_timer_user_read(struct file *file, char __user *buffer,
> > > + case TREAD_FORMAT_NONE:
> > > if (copy_to_user(buffer, &tu->queue[qhead],
> > > sizeof(struct snd_timer_read)))
> > > err = -EFAULT;
> > > + break;
> > > + default:
> > > + err = -ENOTSUPP;
> > [...]
> >
> > This is not a valid error code for returning to user-space, but this
> > case should be impossible so I don't think it matters.
>
> Agreed. Maybe it should also WARN_ON(1), as there getting here
> would indicate a bug in the kernel.
Yes, WARN_ON() or WARN_ON_ONCE() would make sense.
Ben.
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [alsa-devel] [Y2038] [PATCH v7 6/9] ALSA: Avoid using timespec for struct snd_timer_tread
@ 2019-12-12 14:27 ` Ben Hutchings
0 siblings, 0 replies; 94+ messages in thread
From: Ben Hutchings @ 2019-12-12 14:27 UTC (permalink / raw)
To: Arnd Bergmann
Cc: ALSA Development Mailing List, Baolin Wang, y2038 Mailman List,
Takashi Iwai, linux-kernel, Mark Brown, Baolin Wang
On Thu, 2019-12-12 at 10:57 +0100, Arnd Bergmann wrote:
> On Thu, Dec 12, 2019 at 1:14 AM Ben Hutchings
> <ben.hutchings@codethink.co.uk> wrote:
> > On Wed, 2019-12-11 at 22:20 +0100, Arnd Bergmann wrote:
> > [...]
> > > +static int snd_timer_user_tread(void __user *argp, struct snd_timer_user *tu,
> > > + unsigned int cmd, bool compat)
> > > +{
> > > + int __user *p = argp;
> > > + int xarg, old_tread;
> > > +
> > > + if (tu->timeri) /* too late */
> > > + return -EBUSY;
> > > + if (get_user(xarg, p))
> > > + return -EFAULT;
> > > +
> > > + old_tread = tu->tread;
> > > +
> > > + if (!xarg)
> > > + tu->tread = TREAD_FORMAT_NONE;
> > > + else if (cmd == SNDRV_TIMER_IOCTL_TREAD64 ||
> > > + (IS_ENABLED(CONFIG_64BITS) && !compat))
> >
> > This needs to check for CONFIG_64BIT not CONFIG_64BITS.
>
> Fixed now, good catch!
>
> > > @@ -2145,14 +2202,34 @@ static ssize_t snd_timer_user_read(struct file *file, char __user *buffer,
> > > + case TREAD_FORMAT_NONE:
> > > if (copy_to_user(buffer, &tu->queue[qhead],
> > > sizeof(struct snd_timer_read)))
> > > err = -EFAULT;
> > > + break;
> > > + default:
> > > + err = -ENOTSUPP;
> > [...]
> >
> > This is not a valid error code for returning to user-space, but this
> > case should be impossible so I don't think it matters.
>
> Agreed. Maybe it should also WARN_ON(1), as there getting here
> would indicate a bug in the kernel.
Yes, WARN_ON() or WARN_ON_ONCE() would make sense.
Ben.
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [Y2038] [PATCH v7 6/9] ALSA: Avoid using timespec for struct snd_timer_tread
2019-12-12 14:27 ` [alsa-devel] " Ben Hutchings
@ 2019-12-13 10:25 ` Arnd Bergmann
-1 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-13 10:25 UTC (permalink / raw)
To: Ben Hutchings
Cc: ALSA Development Mailing List, Takashi Iwai, Baolin Wang,
y2038 Mailman List, linux-kernel, Jaroslav Kysela, Mark Brown,
Baolin Wang
On Thu, Dec 12, 2019 at 3:27 PM Ben Hutchings
<ben.hutchings@codethink.co.uk> wrote:
> On Thu, 2019-12-12 at 10:57 +0100, Arnd Bergmann wrote:
> > On Thu, Dec 12, 2019 at 1:14 AM Ben Hutchings
> > <ben.hutchings@codethink.co.uk> wrote:
> > > On Wed, 2019-12-11 at 22:20 +0100, Arnd Bergmann wrote:
> > > > @@ -2145,14 +2202,34 @@ static ssize_t snd_timer_user_read(struct file *file, char __user *buffer,
> > > > + case TREAD_FORMAT_NONE:
> > > > if (copy_to_user(buffer, &tu->queue[qhead],
> > > > sizeof(struct snd_timer_read)))
> > > > err = -EFAULT;
> > > > + break;
> > > > + default:
> > > > + err = -ENOTSUPP;
> > > [...]
> > >
> > > This is not a valid error code for returning to user-space, but this
> > > case should be impossible so I don't think it matters.
> >
> > Agreed. Maybe it should also WARN_ON(1), as there getting here
> > would indicate a bug in the kernel.
>
> Yes, WARN_ON() or WARN_ON_ONCE() would make sense.
This is what I added now:
--- a/sound/core/timer.c
+++ b/sound/core/timer.c
@@ -2161,6 +2161,7 @@ static ssize_t snd_timer_user_read(struct file
*file, char __user *buffer,
unit = sizeof(struct snd_timer_read);
break;
default:
+ WARN_ONCE(1, "Corrupt snd_timer_user\n");
return -ENOTSUPP;
}
Arnd
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [alsa-devel] [Y2038] [PATCH v7 6/9] ALSA: Avoid using timespec for struct snd_timer_tread
@ 2019-12-13 10:25 ` Arnd Bergmann
0 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-13 10:25 UTC (permalink / raw)
To: Ben Hutchings
Cc: ALSA Development Mailing List, Baolin Wang, y2038 Mailman List,
Takashi Iwai, linux-kernel, Mark Brown, Baolin Wang
On Thu, Dec 12, 2019 at 3:27 PM Ben Hutchings
<ben.hutchings@codethink.co.uk> wrote:
> On Thu, 2019-12-12 at 10:57 +0100, Arnd Bergmann wrote:
> > On Thu, Dec 12, 2019 at 1:14 AM Ben Hutchings
> > <ben.hutchings@codethink.co.uk> wrote:
> > > On Wed, 2019-12-11 at 22:20 +0100, Arnd Bergmann wrote:
> > > > @@ -2145,14 +2202,34 @@ static ssize_t snd_timer_user_read(struct file *file, char __user *buffer,
> > > > + case TREAD_FORMAT_NONE:
> > > > if (copy_to_user(buffer, &tu->queue[qhead],
> > > > sizeof(struct snd_timer_read)))
> > > > err = -EFAULT;
> > > > + break;
> > > > + default:
> > > > + err = -ENOTSUPP;
> > > [...]
> > >
> > > This is not a valid error code for returning to user-space, but this
> > > case should be impossible so I don't think it matters.
> >
> > Agreed. Maybe it should also WARN_ON(1), as there getting here
> > would indicate a bug in the kernel.
>
> Yes, WARN_ON() or WARN_ON_ONCE() would make sense.
This is what I added now:
--- a/sound/core/timer.c
+++ b/sound/core/timer.c
@@ -2161,6 +2161,7 @@ static ssize_t snd_timer_user_read(struct file
*file, char __user *buffer,
unit = sizeof(struct snd_timer_read);
break;
default:
+ WARN_ONCE(1, "Corrupt snd_timer_user\n");
return -ENOTSUPP;
}
Arnd
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH v7 7/9] ALSA: move snd_pcm_ioctl_sync_ptr_compat into pcm_native.c
2019-12-11 21:20 ` [alsa-devel] " Arnd Bergmann
@ 2019-12-11 21:20 ` Arnd Bergmann
-1 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-11 21:20 UTC (permalink / raw)
To: alsa-devel, Takashi Iwai
Cc: Baolin Wang, y2038, linux-kernel, Jaroslav Kysela, Mark Brown,
Arnd Bergmann, Baolin Wang
This is a preparation patch, moving the compat handler for
snd_pcm_ioctl_sync_ptr_compat from pcm_compat.c to pcm_native.c.
No other changes are indented.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
sound/core/pcm_compat.c | 98 ---------------------------------------
sound/core/pcm_native.c | 100 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 100 insertions(+), 98 deletions(-)
diff --git a/sound/core/pcm_compat.c b/sound/core/pcm_compat.c
index 2671658442ea..6a2e5ea145e6 100644
--- a/sound/core/pcm_compat.c
+++ b/sound/core/pcm_compat.c
@@ -83,19 +83,6 @@ struct snd_pcm_sw_params32 {
unsigned char reserved[56];
};
-/* recalcuate the boundary within 32bit */
-static snd_pcm_uframes_t recalculate_boundary(struct snd_pcm_runtime *runtime)
-{
- snd_pcm_uframes_t boundary;
-
- if (! runtime->buffer_size)
- return 0;
- boundary = runtime->buffer_size;
- while (boundary * 2 <= 0x7fffffffUL - runtime->buffer_size)
- boundary *= 2;
- return boundary;
-}
-
static int snd_pcm_ioctl_sw_params_compat(struct snd_pcm_substream *substream,
struct snd_pcm_sw_params32 __user *src)
{
@@ -388,91 +375,6 @@ static int snd_pcm_ioctl_xfern_compat(struct snd_pcm_substream *substream,
return err;
}
-
-struct snd_pcm_mmap_status32 {
- s32 state;
- s32 pad1;
- u32 hw_ptr;
- struct compat_timespec tstamp;
- s32 suspended_state;
- struct compat_timespec audio_tstamp;
-} __attribute__((packed));
-
-struct snd_pcm_mmap_control32 {
- u32 appl_ptr;
- u32 avail_min;
-};
-
-struct snd_pcm_sync_ptr32 {
- u32 flags;
- union {
- struct snd_pcm_mmap_status32 status;
- unsigned char reserved[64];
- } s;
- union {
- struct snd_pcm_mmap_control32 control;
- unsigned char reserved[64];
- } c;
-} __attribute__((packed));
-
-static int snd_pcm_ioctl_sync_ptr_compat(struct snd_pcm_substream *substream,
- struct snd_pcm_sync_ptr32 __user *src)
-{
- struct snd_pcm_runtime *runtime = substream->runtime;
- volatile struct snd_pcm_mmap_status *status;
- volatile struct snd_pcm_mmap_control *control;
- u32 sflags;
- struct snd_pcm_mmap_control scontrol;
- struct snd_pcm_mmap_status sstatus;
- snd_pcm_uframes_t boundary;
- int err;
-
- if (snd_BUG_ON(!runtime))
- return -EINVAL;
-
- if (get_user(sflags, &src->flags) ||
- get_user(scontrol.appl_ptr, &src->c.control.appl_ptr) ||
- get_user(scontrol.avail_min, &src->c.control.avail_min))
- return -EFAULT;
- if (sflags & SNDRV_PCM_SYNC_PTR_HWSYNC) {
- err = snd_pcm_hwsync(substream);
- if (err < 0)
- return err;
- }
- status = runtime->status;
- control = runtime->control;
- boundary = recalculate_boundary(runtime);
- if (! boundary)
- boundary = 0x7fffffff;
- snd_pcm_stream_lock_irq(substream);
- /* FIXME: we should consider the boundary for the sync from app */
- if (!(sflags & SNDRV_PCM_SYNC_PTR_APPL))
- control->appl_ptr = scontrol.appl_ptr;
- else
- scontrol.appl_ptr = control->appl_ptr % boundary;
- if (!(sflags & SNDRV_PCM_SYNC_PTR_AVAIL_MIN))
- control->avail_min = scontrol.avail_min;
- else
- scontrol.avail_min = control->avail_min;
- sstatus.state = status->state;
- sstatus.hw_ptr = status->hw_ptr % boundary;
- sstatus.tstamp = status->tstamp;
- sstatus.suspended_state = status->suspended_state;
- sstatus.audio_tstamp = status->audio_tstamp;
- snd_pcm_stream_unlock_irq(substream);
- if (put_user(sstatus.state, &src->s.status.state) ||
- put_user(sstatus.hw_ptr, &src->s.status.hw_ptr) ||
- compat_put_timespec(&sstatus.tstamp, &src->s.status.tstamp) ||
- put_user(sstatus.suspended_state, &src->s.status.suspended_state) ||
- compat_put_timespec(&sstatus.audio_tstamp,
- &src->s.status.audio_tstamp) ||
- put_user(scontrol.appl_ptr, &src->c.control.appl_ptr) ||
- put_user(scontrol.avail_min, &src->c.control.avail_min))
- return -EFAULT;
-
- return 0;
-}
-
#ifdef CONFIG_X86_X32
/* X32 ABI has 64bit timespec and 64bit alignment */
struct snd_pcm_mmap_status_x32 {
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index ad4cf1e3e3bd..ba0636a2b437 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -4,6 +4,7 @@
* Copyright (c) by Jaroslav Kysela <perex@perex.cz>
*/
+#include <linux/compat.h>
#include <linux/mm.h>
#include <linux/module.h>
#include <linux/file.h>
@@ -2888,6 +2889,105 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
return 0;
}
+#ifdef CONFIG_COMPAT
+struct snd_pcm_mmap_status32 {
+ s32 state;
+ s32 pad1;
+ u32 hw_ptr;
+ struct compat_timespec tstamp;
+ s32 suspended_state;
+ struct compat_timespec audio_tstamp;
+} __attribute__((packed));
+
+struct snd_pcm_mmap_control32 {
+ u32 appl_ptr;
+ u32 avail_min;
+};
+
+struct snd_pcm_sync_ptr32 {
+ u32 flags;
+ union {
+ struct snd_pcm_mmap_status32 status;
+ unsigned char reserved[64];
+ } s;
+ union {
+ struct snd_pcm_mmap_control32 control;
+ unsigned char reserved[64];
+ } c;
+} __attribute__((packed));
+
+/* recalcuate the boundary within 32bit */
+static snd_pcm_uframes_t recalculate_boundary(struct snd_pcm_runtime *runtime)
+{
+ snd_pcm_uframes_t boundary;
+
+ if (! runtime->buffer_size)
+ return 0;
+ boundary = runtime->buffer_size;
+ while (boundary * 2 <= 0x7fffffffUL - runtime->buffer_size)
+ boundary *= 2;
+ return boundary;
+}
+
+static int snd_pcm_ioctl_sync_ptr_compat(struct snd_pcm_substream *substream,
+ struct snd_pcm_sync_ptr32 __user *src)
+{
+ struct snd_pcm_runtime *runtime = substream->runtime;
+ volatile struct snd_pcm_mmap_status *status;
+ volatile struct snd_pcm_mmap_control *control;
+ u32 sflags;
+ struct snd_pcm_mmap_control scontrol;
+ struct snd_pcm_mmap_status sstatus;
+ snd_pcm_uframes_t boundary;
+ int err;
+
+ if (snd_BUG_ON(!runtime))
+ return -EINVAL;
+
+ if (get_user(sflags, &src->flags) ||
+ get_user(scontrol.appl_ptr, &src->c.control.appl_ptr) ||
+ get_user(scontrol.avail_min, &src->c.control.avail_min))
+ return -EFAULT;
+ if (sflags & SNDRV_PCM_SYNC_PTR_HWSYNC) {
+ err = snd_pcm_hwsync(substream);
+ if (err < 0)
+ return err;
+ }
+ status = runtime->status;
+ control = runtime->control;
+ boundary = recalculate_boundary(runtime);
+ if (! boundary)
+ boundary = 0x7fffffff;
+ snd_pcm_stream_lock_irq(substream);
+ /* FIXME: we should consider the boundary for the sync from app */
+ if (!(sflags & SNDRV_PCM_SYNC_PTR_APPL))
+ control->appl_ptr = scontrol.appl_ptr;
+ else
+ scontrol.appl_ptr = control->appl_ptr % boundary;
+ if (!(sflags & SNDRV_PCM_SYNC_PTR_AVAIL_MIN))
+ control->avail_min = scontrol.avail_min;
+ else
+ scontrol.avail_min = control->avail_min;
+ sstatus.state = status->state;
+ sstatus.hw_ptr = status->hw_ptr % boundary;
+ sstatus.tstamp = status->tstamp;
+ sstatus.suspended_state = status->suspended_state;
+ sstatus.audio_tstamp = status->audio_tstamp;
+ snd_pcm_stream_unlock_irq(substream);
+ if (put_user(sstatus.state, &src->s.status.state) ||
+ put_user(sstatus.hw_ptr, &src->s.status.hw_ptr) ||
+ compat_put_timespec(&sstatus.tstamp, &src->s.status.tstamp) ||
+ put_user(sstatus.suspended_state, &src->s.status.suspended_state) ||
+ compat_put_timespec(&sstatus.audio_tstamp,
+ &src->s.status.audio_tstamp) ||
+ put_user(scontrol.appl_ptr, &src->c.control.appl_ptr) ||
+ put_user(scontrol.avail_min, &src->c.control.avail_min))
+ return -EFAULT;
+
+ return 0;
+}
+#endif
+
static int snd_pcm_tstamp(struct snd_pcm_substream *substream, int __user *_arg)
{
struct snd_pcm_runtime *runtime = substream->runtime;
--
2.20.0
^ permalink raw reply related [flat|nested] 94+ messages in thread* [alsa-devel] [PATCH v7 7/9] ALSA: move snd_pcm_ioctl_sync_ptr_compat into pcm_native.c
@ 2019-12-11 21:20 ` Arnd Bergmann
0 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-11 21:20 UTC (permalink / raw)
To: alsa-devel, Takashi Iwai
Cc: Arnd Bergmann, Baolin Wang, y2038, linux-kernel, Mark Brown, Baolin Wang
This is a preparation patch, moving the compat handler for
snd_pcm_ioctl_sync_ptr_compat from pcm_compat.c to pcm_native.c.
No other changes are indented.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
sound/core/pcm_compat.c | 98 ---------------------------------------
sound/core/pcm_native.c | 100 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 100 insertions(+), 98 deletions(-)
diff --git a/sound/core/pcm_compat.c b/sound/core/pcm_compat.c
index 2671658442ea..6a2e5ea145e6 100644
--- a/sound/core/pcm_compat.c
+++ b/sound/core/pcm_compat.c
@@ -83,19 +83,6 @@ struct snd_pcm_sw_params32 {
unsigned char reserved[56];
};
-/* recalcuate the boundary within 32bit */
-static snd_pcm_uframes_t recalculate_boundary(struct snd_pcm_runtime *runtime)
-{
- snd_pcm_uframes_t boundary;
-
- if (! runtime->buffer_size)
- return 0;
- boundary = runtime->buffer_size;
- while (boundary * 2 <= 0x7fffffffUL - runtime->buffer_size)
- boundary *= 2;
- return boundary;
-}
-
static int snd_pcm_ioctl_sw_params_compat(struct snd_pcm_substream *substream,
struct snd_pcm_sw_params32 __user *src)
{
@@ -388,91 +375,6 @@ static int snd_pcm_ioctl_xfern_compat(struct snd_pcm_substream *substream,
return err;
}
-
-struct snd_pcm_mmap_status32 {
- s32 state;
- s32 pad1;
- u32 hw_ptr;
- struct compat_timespec tstamp;
- s32 suspended_state;
- struct compat_timespec audio_tstamp;
-} __attribute__((packed));
-
-struct snd_pcm_mmap_control32 {
- u32 appl_ptr;
- u32 avail_min;
-};
-
-struct snd_pcm_sync_ptr32 {
- u32 flags;
- union {
- struct snd_pcm_mmap_status32 status;
- unsigned char reserved[64];
- } s;
- union {
- struct snd_pcm_mmap_control32 control;
- unsigned char reserved[64];
- } c;
-} __attribute__((packed));
-
-static int snd_pcm_ioctl_sync_ptr_compat(struct snd_pcm_substream *substream,
- struct snd_pcm_sync_ptr32 __user *src)
-{
- struct snd_pcm_runtime *runtime = substream->runtime;
- volatile struct snd_pcm_mmap_status *status;
- volatile struct snd_pcm_mmap_control *control;
- u32 sflags;
- struct snd_pcm_mmap_control scontrol;
- struct snd_pcm_mmap_status sstatus;
- snd_pcm_uframes_t boundary;
- int err;
-
- if (snd_BUG_ON(!runtime))
- return -EINVAL;
-
- if (get_user(sflags, &src->flags) ||
- get_user(scontrol.appl_ptr, &src->c.control.appl_ptr) ||
- get_user(scontrol.avail_min, &src->c.control.avail_min))
- return -EFAULT;
- if (sflags & SNDRV_PCM_SYNC_PTR_HWSYNC) {
- err = snd_pcm_hwsync(substream);
- if (err < 0)
- return err;
- }
- status = runtime->status;
- control = runtime->control;
- boundary = recalculate_boundary(runtime);
- if (! boundary)
- boundary = 0x7fffffff;
- snd_pcm_stream_lock_irq(substream);
- /* FIXME: we should consider the boundary for the sync from app */
- if (!(sflags & SNDRV_PCM_SYNC_PTR_APPL))
- control->appl_ptr = scontrol.appl_ptr;
- else
- scontrol.appl_ptr = control->appl_ptr % boundary;
- if (!(sflags & SNDRV_PCM_SYNC_PTR_AVAIL_MIN))
- control->avail_min = scontrol.avail_min;
- else
- scontrol.avail_min = control->avail_min;
- sstatus.state = status->state;
- sstatus.hw_ptr = status->hw_ptr % boundary;
- sstatus.tstamp = status->tstamp;
- sstatus.suspended_state = status->suspended_state;
- sstatus.audio_tstamp = status->audio_tstamp;
- snd_pcm_stream_unlock_irq(substream);
- if (put_user(sstatus.state, &src->s.status.state) ||
- put_user(sstatus.hw_ptr, &src->s.status.hw_ptr) ||
- compat_put_timespec(&sstatus.tstamp, &src->s.status.tstamp) ||
- put_user(sstatus.suspended_state, &src->s.status.suspended_state) ||
- compat_put_timespec(&sstatus.audio_tstamp,
- &src->s.status.audio_tstamp) ||
- put_user(scontrol.appl_ptr, &src->c.control.appl_ptr) ||
- put_user(scontrol.avail_min, &src->c.control.avail_min))
- return -EFAULT;
-
- return 0;
-}
-
#ifdef CONFIG_X86_X32
/* X32 ABI has 64bit timespec and 64bit alignment */
struct snd_pcm_mmap_status_x32 {
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index ad4cf1e3e3bd..ba0636a2b437 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -4,6 +4,7 @@
* Copyright (c) by Jaroslav Kysela <perex@perex.cz>
*/
+#include <linux/compat.h>
#include <linux/mm.h>
#include <linux/module.h>
#include <linux/file.h>
@@ -2888,6 +2889,105 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
return 0;
}
+#ifdef CONFIG_COMPAT
+struct snd_pcm_mmap_status32 {
+ s32 state;
+ s32 pad1;
+ u32 hw_ptr;
+ struct compat_timespec tstamp;
+ s32 suspended_state;
+ struct compat_timespec audio_tstamp;
+} __attribute__((packed));
+
+struct snd_pcm_mmap_control32 {
+ u32 appl_ptr;
+ u32 avail_min;
+};
+
+struct snd_pcm_sync_ptr32 {
+ u32 flags;
+ union {
+ struct snd_pcm_mmap_status32 status;
+ unsigned char reserved[64];
+ } s;
+ union {
+ struct snd_pcm_mmap_control32 control;
+ unsigned char reserved[64];
+ } c;
+} __attribute__((packed));
+
+/* recalcuate the boundary within 32bit */
+static snd_pcm_uframes_t recalculate_boundary(struct snd_pcm_runtime *runtime)
+{
+ snd_pcm_uframes_t boundary;
+
+ if (! runtime->buffer_size)
+ return 0;
+ boundary = runtime->buffer_size;
+ while (boundary * 2 <= 0x7fffffffUL - runtime->buffer_size)
+ boundary *= 2;
+ return boundary;
+}
+
+static int snd_pcm_ioctl_sync_ptr_compat(struct snd_pcm_substream *substream,
+ struct snd_pcm_sync_ptr32 __user *src)
+{
+ struct snd_pcm_runtime *runtime = substream->runtime;
+ volatile struct snd_pcm_mmap_status *status;
+ volatile struct snd_pcm_mmap_control *control;
+ u32 sflags;
+ struct snd_pcm_mmap_control scontrol;
+ struct snd_pcm_mmap_status sstatus;
+ snd_pcm_uframes_t boundary;
+ int err;
+
+ if (snd_BUG_ON(!runtime))
+ return -EINVAL;
+
+ if (get_user(sflags, &src->flags) ||
+ get_user(scontrol.appl_ptr, &src->c.control.appl_ptr) ||
+ get_user(scontrol.avail_min, &src->c.control.avail_min))
+ return -EFAULT;
+ if (sflags & SNDRV_PCM_SYNC_PTR_HWSYNC) {
+ err = snd_pcm_hwsync(substream);
+ if (err < 0)
+ return err;
+ }
+ status = runtime->status;
+ control = runtime->control;
+ boundary = recalculate_boundary(runtime);
+ if (! boundary)
+ boundary = 0x7fffffff;
+ snd_pcm_stream_lock_irq(substream);
+ /* FIXME: we should consider the boundary for the sync from app */
+ if (!(sflags & SNDRV_PCM_SYNC_PTR_APPL))
+ control->appl_ptr = scontrol.appl_ptr;
+ else
+ scontrol.appl_ptr = control->appl_ptr % boundary;
+ if (!(sflags & SNDRV_PCM_SYNC_PTR_AVAIL_MIN))
+ control->avail_min = scontrol.avail_min;
+ else
+ scontrol.avail_min = control->avail_min;
+ sstatus.state = status->state;
+ sstatus.hw_ptr = status->hw_ptr % boundary;
+ sstatus.tstamp = status->tstamp;
+ sstatus.suspended_state = status->suspended_state;
+ sstatus.audio_tstamp = status->audio_tstamp;
+ snd_pcm_stream_unlock_irq(substream);
+ if (put_user(sstatus.state, &src->s.status.state) ||
+ put_user(sstatus.hw_ptr, &src->s.status.hw_ptr) ||
+ compat_put_timespec(&sstatus.tstamp, &src->s.status.tstamp) ||
+ put_user(sstatus.suspended_state, &src->s.status.suspended_state) ||
+ compat_put_timespec(&sstatus.audio_tstamp,
+ &src->s.status.audio_tstamp) ||
+ put_user(scontrol.appl_ptr, &src->c.control.appl_ptr) ||
+ put_user(scontrol.avail_min, &src->c.control.avail_min))
+ return -EFAULT;
+
+ return 0;
+}
+#endif
+
static int snd_pcm_tstamp(struct snd_pcm_substream *substream, int __user *_arg)
{
struct snd_pcm_runtime *runtime = substream->runtime;
--
2.20.0
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2019-12-11 21:20 ` [alsa-devel] " Arnd Bergmann
@ 2019-12-11 21:20 ` Arnd Bergmann
-1 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-11 21:20 UTC (permalink / raw)
To: alsa-devel, Takashi Iwai
Cc: Baolin Wang, y2038, linux-kernel, Jaroslav Kysela, Mark Brown,
Arnd Bergmann, Baolin Wang
The snd_pcm_mmap_status and snd_pcm_mmap_control interfaces are one of the
trickiest areas to get right when moving to 64-bit time_t in user space.
The snd_pcm_mmap_status structure layout is incompatible with user space
that uses a 64-bit time_t, so we need a new layout for it. Since the
SNDRV_PCM_IOCTL_SYNC_PTR ioctl combines it with snd_pcm_mmap_control
into snd_pcm_sync_ptr, we need to change those two as well.
Both structures are also exported via an mmap() operation on certain
architectures, and this suffers from incompatibility between 32-bit
and 64-bit user space. As we have to change both structures anyway,
this is a good opportunity to fix the mmap() problem as well, so let's
standardize on the existing 64-bit layout of the structure where possible.
The downside is that we lose mmap() support for existing 32-bit x86 and
powerpc applications, adding that would introduce very noticeable runtime
overhead and complexity. My assumption here is that not too many people
will miss the removed feature, given that:
- Almost all x86 and powerpc users these days are on 64-bit kernels,
the majority of today's 32-bit users are on architectures that never
supported mmap (ARM, MIPS, ...).
- It never worked in compat mode (it was intentionally disabled there)
- The application already needs to work with a fallback to
SNDRV_PCM_IOCTL_SYNC_PTR, which will keep working with both the old
and new structure layout.
Both the ioctl() and mmap() based interfaces are changed at the same
time, as they are based on the same structures. Unlike other interfaces,
we change the uapi header to export both the traditional structure and
a version that is portable between 32-bit and 64-bit user space code
and that corresponds to the existing 64-bit layout. We further check the
__USE_TIME_BITS64 macro that will be defined by future C library versions
whenever we use the new time_t definition, so any existing user space
source code will not see any changes until it gets rebuilt against a new
C library. However, the new structures are all visible in addition to the
old ones, allowing applications to explicitly request the new structures.
In order to detect the difference between the old snd_pcm_mmap_status and
the new __snd_pcm_mmap_status64 structure from the ioctl command number,
we rely on one quirk in the structure definition: snd_pcm_mmap_status
must be aligned to alignof(time_t), which leads the compiler to insert
four bytes of padding in struct snd_pcm_sync_ptr after 'flags' and a
corresponding change in the size of snd_pcm_sync_ptr itself. On x86-32
(and only there), the compiler doesn't use 64-bit alignment in structure,
so I'm adding an explicit pad in the structure that has no effect on the
existing 64-bit architectures but ensures that the layout matches for x86.
The snd_pcm_uframes_t type compatibility requires another hack: we can't
easily make that 64 bit wide, so I leave the type as 'unsigned long',
but add padding before and after it, to ensure that the data is properly
aligned to the respective 64-bit field in the in-kernel structure.
For the SNDRV_PCM_MMAP_OFFSET_STATUS/CONTROL constants that are used
as the virtual file offset in the mmap() function, we also have to
introduce new constants that depend on hte __USE_TIME_BITS64 macro:
The existing macros are renamed to SNDRV_PCM_MMAP_OFFSET_STATUS_OLD
and SNDRV_PCM_MMAP_OFFSET_CONTROL_OLD, they continue to work fine on
64-bit architectures, but stop working on native 32-bit user space.
The replacement _NEW constants are now used by default for user space
built with __USE_TIME_BITS64, those now work on all new kernels for x86,
ppc and alpha (32 and 64 bit, native and compat). It might be a good idea
for a future alsa-lib to support both the _OLD and _NEW macros and use
the corresponding structures directly. Unmodified alsa-lib source code
will retain the current behavior, so it will no longer be able to use
mmap() for the status/control structures on 32-bit systems, until either
the C library gets updated to 64-bit time_t or alsa-lib gets updated to
support both mmap() layouts.
Co-developed-with: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/uapi/sound/asound.h | 110 ++++++++++++++++++++++++++++++++----
sound/core/pcm_compat.c | 30 +++++-----
sound/core/pcm_lib.c | 10 ++--
sound/core/pcm_native.c | 38 ++++++++-----
4 files changed, 147 insertions(+), 41 deletions(-)
diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
index ad86c5a7a1e2..df9983e7ead5 100644
--- a/include/uapi/sound/asound.h
+++ b/include/uapi/sound/asound.h
@@ -35,6 +35,8 @@
#include <time.h>
#endif
+#include <asm/byteorder.h>
+
/*
* protocol version
*/
@@ -301,7 +303,9 @@ typedef int __bitwise snd_pcm_subformat_t;
#define SNDRV_PCM_INFO_DRAIN_TRIGGER 0x40000000 /* internal kernel flag - trigger in drain */
#define SNDRV_PCM_INFO_FIFO_IN_FRAMES 0x80000000 /* internal kernel flag - FIFO size is in frames */
-
+#if (__BITS_PER_LONG == 32 && defined(__USE_TIME_BITS64)) || defined __KERNEL__
+#define __SND_STRUCT_TIME64
+#endif
typedef int __bitwise snd_pcm_state_t;
#define SNDRV_PCM_STATE_OPEN ((__force snd_pcm_state_t) 0) /* stream is open */
@@ -317,8 +321,17 @@ typedef int __bitwise snd_pcm_state_t;
enum {
SNDRV_PCM_MMAP_OFFSET_DATA = 0x00000000,
- SNDRV_PCM_MMAP_OFFSET_STATUS = 0x80000000,
- SNDRV_PCM_MMAP_OFFSET_CONTROL = 0x81000000,
+ SNDRV_PCM_MMAP_OFFSET_STATUS_OLD = 0x80000000,
+ SNDRV_PCM_MMAP_OFFSET_CONTROL_OLD = 0x81000000,
+ SNDRV_PCM_MMAP_OFFSET_STATUS_NEW = 0x82000000,
+ SNDRV_PCM_MMAP_OFFSET_CONTROL_NEW = 0x83000000,
+#ifdef __SND_STRUCT_TIME64
+ SNDRV_PCM_MMAP_OFFSET_STATUS = SNDRV_PCM_MMAP_OFFSET_STATUS_NEW,
+ SNDRV_PCM_MMAP_OFFSET_CONTROL = SNDRV_PCM_MMAP_OFFSET_CONTROL_NEW,
+#else
+ SNDRV_PCM_MMAP_OFFSET_STATUS = SNDRV_PCM_MMAP_OFFSET_STATUS_OLD,
+ SNDRV_PCM_MMAP_OFFSET_CONTROL = SNDRV_PCM_MMAP_OFFSET_CONTROL_OLD,
+#endif
};
union snd_pcm_sync_id {
@@ -480,16 +493,46 @@ struct snd_pcm_status {
};
#endif
-struct snd_pcm_mmap_status {
+/*
+ * For mmap operations, we need the 64-bit layout, both for compat mode,
+ * and for y2038 compatibility. For 64-bit applications, the two definitions
+ * are identical, so we keep the traditional version.
+ */
+#ifdef __SND_STRUCT_TIME64
+#define __snd_pcm_mmap_status64 snd_pcm_mmap_status
+#define __snd_pcm_mmap_control64 snd_pcm_mmap_control
+#define __snd_pcm_sync_ptr64 snd_pcm_sync_ptr
+#ifdef __KERNEL__
+#define __snd_timespec64 __kernel_timespec
+#else
+#define __snd_timespec64 timespec
+#endif
+struct __snd_timespec {
+ __s32 tv_sec;
+ __s32 tv_nsec;
+};
+#else
+#define __snd_pcm_mmap_status snd_pcm_mmap_status
+#define __snd_pcm_mmap_control snd_pcm_mmap_control
+#define __snd_pcm_sync_ptr snd_pcm_sync_ptr
+#define __snd_timespec timespec
+struct __snd_timespec64 {
+ __s64 tv_sec;
+ __s64 tv_nsec;
+};
+
+#endif
+
+struct __snd_pcm_mmap_status {
snd_pcm_state_t state; /* RO: state - SNDRV_PCM_STATE_XXXX */
int pad1; /* Needed for 64 bit alignment */
snd_pcm_uframes_t hw_ptr; /* RO: hw ptr (0...boundary-1) */
- struct timespec tstamp; /* Timestamp */
+ struct __snd_timespec tstamp; /* Timestamp */
snd_pcm_state_t suspended_state; /* RO: suspended stream state */
- struct timespec audio_tstamp; /* from sample counter or wall clock */
+ struct __snd_timespec audio_tstamp; /* from sample counter or wall clock */
};
-struct snd_pcm_mmap_control {
+struct __snd_pcm_mmap_control {
snd_pcm_uframes_t appl_ptr; /* RW: appl ptr (0...boundary-1) */
snd_pcm_uframes_t avail_min; /* RW: min available frames for wakeup */
};
@@ -498,14 +541,59 @@ struct snd_pcm_mmap_control {
#define SNDRV_PCM_SYNC_PTR_APPL (1<<1) /* get appl_ptr from driver (r/w op) */
#define SNDRV_PCM_SYNC_PTR_AVAIL_MIN (1<<2) /* get avail_min from driver */
-struct snd_pcm_sync_ptr {
+struct __snd_pcm_sync_ptr {
unsigned int flags;
union {
- struct snd_pcm_mmap_status status;
+ struct __snd_pcm_mmap_status status;
+ unsigned char reserved[64];
+ } s;
+ union {
+ struct __snd_pcm_mmap_control control;
+ unsigned char reserved[64];
+ } c;
+};
+
+#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
+typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
+typedef char __pad_after_uframe[0];
+#endif
+
+#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
+typedef char __pad_before_uframe[0];
+typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
+#endif
+
+struct __snd_pcm_mmap_status64 {
+ __s32 state; /* RO: state - SNDRV_PCM_STATE_XXXX */
+ __u32 pad1; /* Needed for 64 bit alignment */
+ __pad_before_uframe __pad1;
+ snd_pcm_uframes_t hw_ptr; /* RO: hw ptr (0...boundary-1) */
+ __pad_after_uframe __pad2;
+ struct __snd_timespec64 tstamp; /* Timestamp */
+ __s32 suspended_state; /* RO: suspended stream state */
+ __u32 pad3; /* Needed for 64 bit alignment */
+ struct __snd_timespec64 audio_tstamp; /* sample counter or wall clock */
+};
+
+struct __snd_pcm_mmap_control64 {
+ __pad_before_uframe __pad1;
+ snd_pcm_uframes_t appl_ptr; /* RW: appl ptr (0...boundary-1) */
+ __pad_before_uframe __pad2;
+
+ __pad_before_uframe __pad3;
+ snd_pcm_uframes_t avail_min; /* RW: min available frames for wakeup */
+ __pad_after_uframe __pad4;
+};
+
+struct __snd_pcm_sync_ptr64 {
+ __u32 flags;
+ __u32 pad1;
+ union {
+ struct __snd_pcm_mmap_status64 status;
unsigned char reserved[64];
} s;
union {
- struct snd_pcm_mmap_control control;
+ struct __snd_pcm_mmap_control64 control;
unsigned char reserved[64];
} c;
};
@@ -590,6 +678,8 @@ enum {
#define SNDRV_PCM_IOCTL_STATUS _IOR('A', 0x20, struct snd_pcm_status)
#define SNDRV_PCM_IOCTL_DELAY _IOR('A', 0x21, snd_pcm_sframes_t)
#define SNDRV_PCM_IOCTL_HWSYNC _IO('A', 0x22)
+#define __SNDRV_PCM_IOCTL_SYNC_PTR _IOWR('A', 0x23, struct __snd_pcm_sync_ptr)
+#define __SNDRV_PCM_IOCTL_SYNC_PTR64 _IOWR('A', 0x23, struct __snd_pcm_sync_ptr64)
#define SNDRV_PCM_IOCTL_SYNC_PTR _IOWR('A', 0x23, struct snd_pcm_sync_ptr)
#define SNDRV_PCM_IOCTL_STATUS_EXT _IOWR('A', 0x24, struct snd_pcm_status)
#define SNDRV_PCM_IOCTL_CHANNEL_INFO _IOR('A', 0x32, struct snd_pcm_channel_info)
diff --git a/sound/core/pcm_compat.c b/sound/core/pcm_compat.c
index 6a2e5ea145e6..967c689fb8da 100644
--- a/sound/core/pcm_compat.c
+++ b/sound/core/pcm_compat.c
@@ -178,8 +178,6 @@ struct compat_snd_pcm_status64 {
unsigned char reserved[52-4*sizeof(s64)];
} __packed;
-#define put_timespec(src, dst) copy_to_user(dst, src, sizeof(*dst))
-
static int snd_pcm_status_user_compat64(struct snd_pcm_substream *substream,
struct compat_snd_pcm_status64 __user *src,
bool ext)
@@ -382,10 +380,12 @@ struct snd_pcm_mmap_status_x32 {
s32 pad1;
u32 hw_ptr;
u32 pad2; /* alignment */
- struct timespec tstamp;
+ s64 tstamp_sec;
+ s64 tstamp_nsec;
s32 suspended_state;
s32 pad3;
- struct timespec audio_tstamp;
+ s64 audio_tstamp_sec;
+ s64 audio_tstamp_nsec;
} __packed;
struct snd_pcm_mmap_control_x32 {
@@ -453,9 +453,11 @@ static int snd_pcm_ioctl_sync_ptr_x32(struct snd_pcm_substream *substream,
snd_pcm_stream_unlock_irq(substream);
if (put_user(sstatus.state, &src->s.status.state) ||
put_user(sstatus.hw_ptr, &src->s.status.hw_ptr) ||
- put_timespec(&sstatus.tstamp, &src->s.status.tstamp) ||
+ put_user(sstatus.tstamp.tv_sec, &src->s.status.tstamp_sec) ||
+ put_user(sstatus.tstamp.tv_nsec, &src->s.status.tstamp_nsec) ||
put_user(sstatus.suspended_state, &src->s.status.suspended_state) ||
- put_timespec(&sstatus.audio_tstamp, &src->s.status.audio_tstamp) ||
+ put_user(sstatus.audio_tstamp.tv_sec, &src->s.status.audio_tstamp_sec) ||
+ put_user(sstatus.audio_tstamp.tv_nsec, &src->s.status.audio_tstamp_nsec) ||
put_user(scontrol.appl_ptr, &src->c.control.appl_ptr) ||
put_user(scontrol.avail_min, &src->c.control.avail_min))
return -EFAULT;
@@ -480,7 +482,6 @@ enum {
SNDRV_PCM_IOCTL_READI_FRAMES32 = _IOR('A', 0x51, struct snd_xferi32),
SNDRV_PCM_IOCTL_WRITEN_FRAMES32 = _IOW('A', 0x52, struct snd_xfern32),
SNDRV_PCM_IOCTL_READN_FRAMES32 = _IOR('A', 0x53, struct snd_xfern32),
- SNDRV_PCM_IOCTL_SYNC_PTR32 = _IOWR('A', 0x23, struct snd_pcm_sync_ptr32),
SNDRV_PCM_IOCTL_STATUS_COMPAT64 = _IOR('A', 0x20, struct compat_snd_pcm_status64),
SNDRV_PCM_IOCTL_STATUS_EXT_COMPAT64 = _IOWR('A', 0x24, struct compat_snd_pcm_status64),
#ifdef CONFIG_X86_X32
@@ -504,8 +505,8 @@ static long snd_pcm_ioctl_compat(struct file *file, unsigned int cmd, unsigned l
/*
* When PCM is used on 32bit mode, we need to disable
- * mmap of PCM status/control records because of the size
- * incompatibility.
+ * mmap of the old PCM status/control records because
+ * of the size incompatibility.
*/
pcm_file->no_compat_mmap = 1;
@@ -527,6 +528,13 @@ static long snd_pcm_ioctl_compat(struct file *file, unsigned int cmd, unsigned l
case SNDRV_PCM_IOCTL_XRUN:
case SNDRV_PCM_IOCTL_LINK:
case SNDRV_PCM_IOCTL_UNLINK:
+ case __SNDRV_PCM_IOCTL_SYNC_PTR32:
+ return snd_pcm_common_ioctl(file, substream, cmd, argp);
+ case __SNDRV_PCM_IOCTL_SYNC_PTR64:
+#ifdef CONFIG_X86_X32
+ if (in_x32_syscall())
+ return snd_pcm_ioctl_sync_ptr_x32(substream, argp);
+#endif /* CONFIG_X86_X32 */
return snd_pcm_common_ioctl(file, substream, cmd, argp);
case SNDRV_PCM_IOCTL_HW_REFINE32:
return snd_pcm_ioctl_hw_params_compat(substream, 1, argp);
@@ -538,8 +546,6 @@ static long snd_pcm_ioctl_compat(struct file *file, unsigned int cmd, unsigned l
return snd_pcm_status_user32(substream, argp, false);
case SNDRV_PCM_IOCTL_STATUS_EXT_COMPAT32:
return snd_pcm_status_user32(substream, argp, true);
- case SNDRV_PCM_IOCTL_SYNC_PTR32:
- return snd_pcm_ioctl_sync_ptr_compat(substream, argp);
case SNDRV_PCM_IOCTL_CHANNEL_INFO32:
return snd_pcm_ioctl_channel_info_compat(substream, argp);
case SNDRV_PCM_IOCTL_WRITEI_FRAMES32:
@@ -561,8 +567,6 @@ static long snd_pcm_ioctl_compat(struct file *file, unsigned int cmd, unsigned l
case SNDRV_PCM_IOCTL_STATUS_EXT_COMPAT64:
return snd_pcm_status_user_compat64(substream, argp, true);
#ifdef CONFIG_X86_X32
- case SNDRV_PCM_IOCTL_SYNC_PTR_X32:
- return snd_pcm_ioctl_sync_ptr_x32(substream, argp);
case SNDRV_PCM_IOCTL_CHANNEL_INFO_X32:
return snd_pcm_ioctl_channel_info_x32(substream, argp);
#endif /* CONFIG_X86_X32 */
diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c
index ea5518d44e66..0271802bfba9 100644
--- a/sound/core/pcm_lib.c
+++ b/sound/core/pcm_lib.c
@@ -148,7 +148,8 @@ void __snd_pcm_xrun(struct snd_pcm_substream *substream)
struct timespec64 tstamp;
snd_pcm_gettime(runtime, &tstamp);
- runtime->status->tstamp = timespec64_to_timespec(tstamp);
+ runtime->status->tstamp.tv_sec = tstamp.tv_sec;
+ runtime->status->tstamp.tv_nsec = tstamp.tv_nsec;
}
snd_pcm_stop(substream, SNDRV_PCM_STATE_XRUN);
if (xrun_debug(substream, XRUN_DEBUG_BASIC)) {
@@ -238,9 +239,10 @@ static void update_audio_tstamp(struct snd_pcm_substream *substream,
if (runtime->status->audio_tstamp.tv_sec != audio_tstamp->tv_sec ||
runtime->status->audio_tstamp.tv_nsec != audio_tstamp->tv_nsec) {
- runtime->status->audio_tstamp =
- timespec64_to_timespec(*audio_tstamp);
- runtime->status->tstamp = timespec64_to_timespec(*curr_tstamp);
+ runtime->status->audio_tstamp.tv_sec = audio_tstamp->tv_sec;
+ runtime->status->audio_tstamp.tv_nsec = audio_tstamp->tv_nsec;
+ runtime->status->tstamp.tv_sec = curr_tstamp->tv_sec;
+ runtime->status->tstamp.tv_nsec = curr_tstamp->tv_nsec;
}
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index ba0636a2b437..5a1245509eac 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -2889,14 +2889,15 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
return 0;
}
-#ifdef CONFIG_COMPAT
struct snd_pcm_mmap_status32 {
s32 state;
s32 pad1;
u32 hw_ptr;
- struct compat_timespec tstamp;
+ s32 tstamp_sec;
+ s32 tstamp_nsec;
s32 suspended_state;
- struct compat_timespec audio_tstamp;
+ s32 audio_tstamp_sec;
+ s32 audio_tstamp_nsec;
} __attribute__((packed));
struct snd_pcm_mmap_control32 {
@@ -2976,17 +2977,18 @@ static int snd_pcm_ioctl_sync_ptr_compat(struct snd_pcm_substream *substream,
snd_pcm_stream_unlock_irq(substream);
if (put_user(sstatus.state, &src->s.status.state) ||
put_user(sstatus.hw_ptr, &src->s.status.hw_ptr) ||
- compat_put_timespec(&sstatus.tstamp, &src->s.status.tstamp) ||
+ put_user(sstatus.tstamp.tv_sec, &src->s.status.tstamp_sec) ||
+ put_user(sstatus.tstamp.tv_nsec, &src->s.status.tstamp_nsec) ||
put_user(sstatus.suspended_state, &src->s.status.suspended_state) ||
- compat_put_timespec(&sstatus.audio_tstamp,
- &src->s.status.audio_tstamp) ||
+ put_user(sstatus.audio_tstamp.tv_sec, &src->s.status.audio_tstamp_sec) ||
+ put_user(sstatus.audio_tstamp.tv_nsec, &src->s.status.audio_tstamp_nsec) ||
put_user(scontrol.appl_ptr, &src->c.control.appl_ptr) ||
put_user(scontrol.avail_min, &src->c.control.avail_min))
return -EFAULT;
return 0;
}
-#endif
+#define __SNDRV_PCM_IOCTL_SYNC_PTR32 _IOWR('A', 0x23, struct snd_pcm_sync_ptr32)
static int snd_pcm_tstamp(struct snd_pcm_substream *substream, int __user *_arg)
{
@@ -3156,7 +3158,9 @@ static int snd_pcm_common_ioctl(struct file *file,
return -EFAULT;
return 0;
}
- case SNDRV_PCM_IOCTL_SYNC_PTR:
+ case __SNDRV_PCM_IOCTL_SYNC_PTR32:
+ return snd_pcm_ioctl_sync_ptr_compat(substream, arg);
+ case __SNDRV_PCM_IOCTL_SYNC_PTR64:
return snd_pcm_sync_ptr(substream, arg);
#ifdef CONFIG_SND_SUPPORT_OLD_API
case SNDRV_PCM_IOCTL_HW_REFINE_OLD:
@@ -3494,8 +3498,6 @@ static int snd_pcm_mmap_control(struct snd_pcm_substream *substream, struct file
static bool pcm_status_mmap_allowed(struct snd_pcm_file *pcm_file)
{
- if (pcm_file->no_compat_mmap)
- return false;
/* See pcm_control_mmap_allowed() below.
* Since older alsa-lib requires both status and control mmaps to be
* coupled, we have to disable the status mmap for old alsa-lib, too.
@@ -3720,11 +3722,19 @@ static int snd_pcm_mmap(struct file *file, struct vm_area_struct *area)
offset = area->vm_pgoff << PAGE_SHIFT;
switch (offset) {
- case SNDRV_PCM_MMAP_OFFSET_STATUS:
+ case SNDRV_PCM_MMAP_OFFSET_STATUS_OLD:
+ if (pcm_file->no_compat_mmap || !IS_ENABLED(CONFIG_64BIT))
+ return -ENXIO;
+ /* fallthrough */
+ case SNDRV_PCM_MMAP_OFFSET_STATUS_NEW:
if (!pcm_status_mmap_allowed(pcm_file))
return -ENXIO;
return snd_pcm_mmap_status(substream, file, area);
- case SNDRV_PCM_MMAP_OFFSET_CONTROL:
+ case SNDRV_PCM_MMAP_OFFSET_CONTROL_OLD:
+ if (pcm_file->no_compat_mmap || !IS_ENABLED(CONFIG_64BIT))
+ return -ENXIO;
+ /* fallthrough */
+ case SNDRV_PCM_MMAP_OFFSET_CONTROL_NEW:
if (!pcm_control_mmap_allowed(pcm_file))
return -ENXIO;
return snd_pcm_mmap_control(substream, file, area);
@@ -3884,9 +3894,9 @@ static unsigned long snd_pcm_get_unmapped_area(struct file *file,
unsigned long offset = pgoff << PAGE_SHIFT;
switch (offset) {
- case SNDRV_PCM_MMAP_OFFSET_STATUS:
+ case SNDRV_PCM_MMAP_OFFSET_STATUS_NEW:
return (unsigned long)runtime->status;
- case SNDRV_PCM_MMAP_OFFSET_CONTROL:
+ case SNDRV_PCM_MMAP_OFFSET_CONTROL_NEW:
return (unsigned long)runtime->control;
default:
return (unsigned long)runtime->dma_area + offset;
--
2.20.0
^ permalink raw reply related [flat|nested] 94+ messages in thread* [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2019-12-11 21:20 ` Arnd Bergmann
0 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-11 21:20 UTC (permalink / raw)
To: alsa-devel, Takashi Iwai
Cc: Arnd Bergmann, Baolin Wang, y2038, linux-kernel, Mark Brown, Baolin Wang
The snd_pcm_mmap_status and snd_pcm_mmap_control interfaces are one of the
trickiest areas to get right when moving to 64-bit time_t in user space.
The snd_pcm_mmap_status structure layout is incompatible with user space
that uses a 64-bit time_t, so we need a new layout for it. Since the
SNDRV_PCM_IOCTL_SYNC_PTR ioctl combines it with snd_pcm_mmap_control
into snd_pcm_sync_ptr, we need to change those two as well.
Both structures are also exported via an mmap() operation on certain
architectures, and this suffers from incompatibility between 32-bit
and 64-bit user space. As we have to change both structures anyway,
this is a good opportunity to fix the mmap() problem as well, so let's
standardize on the existing 64-bit layout of the structure where possible.
The downside is that we lose mmap() support for existing 32-bit x86 and
powerpc applications, adding that would introduce very noticeable runtime
overhead and complexity. My assumption here is that not too many people
will miss the removed feature, given that:
- Almost all x86 and powerpc users these days are on 64-bit kernels,
the majority of today's 32-bit users are on architectures that never
supported mmap (ARM, MIPS, ...).
- It never worked in compat mode (it was intentionally disabled there)
- The application already needs to work with a fallback to
SNDRV_PCM_IOCTL_SYNC_PTR, which will keep working with both the old
and new structure layout.
Both the ioctl() and mmap() based interfaces are changed at the same
time, as they are based on the same structures. Unlike other interfaces,
we change the uapi header to export both the traditional structure and
a version that is portable between 32-bit and 64-bit user space code
and that corresponds to the existing 64-bit layout. We further check the
__USE_TIME_BITS64 macro that will be defined by future C library versions
whenever we use the new time_t definition, so any existing user space
source code will not see any changes until it gets rebuilt against a new
C library. However, the new structures are all visible in addition to the
old ones, allowing applications to explicitly request the new structures.
In order to detect the difference between the old snd_pcm_mmap_status and
the new __snd_pcm_mmap_status64 structure from the ioctl command number,
we rely on one quirk in the structure definition: snd_pcm_mmap_status
must be aligned to alignof(time_t), which leads the compiler to insert
four bytes of padding in struct snd_pcm_sync_ptr after 'flags' and a
corresponding change in the size of snd_pcm_sync_ptr itself. On x86-32
(and only there), the compiler doesn't use 64-bit alignment in structure,
so I'm adding an explicit pad in the structure that has no effect on the
existing 64-bit architectures but ensures that the layout matches for x86.
The snd_pcm_uframes_t type compatibility requires another hack: we can't
easily make that 64 bit wide, so I leave the type as 'unsigned long',
but add padding before and after it, to ensure that the data is properly
aligned to the respective 64-bit field in the in-kernel structure.
For the SNDRV_PCM_MMAP_OFFSET_STATUS/CONTROL constants that are used
as the virtual file offset in the mmap() function, we also have to
introduce new constants that depend on hte __USE_TIME_BITS64 macro:
The existing macros are renamed to SNDRV_PCM_MMAP_OFFSET_STATUS_OLD
and SNDRV_PCM_MMAP_OFFSET_CONTROL_OLD, they continue to work fine on
64-bit architectures, but stop working on native 32-bit user space.
The replacement _NEW constants are now used by default for user space
built with __USE_TIME_BITS64, those now work on all new kernels for x86,
ppc and alpha (32 and 64 bit, native and compat). It might be a good idea
for a future alsa-lib to support both the _OLD and _NEW macros and use
the corresponding structures directly. Unmodified alsa-lib source code
will retain the current behavior, so it will no longer be able to use
mmap() for the status/control structures on 32-bit systems, until either
the C library gets updated to 64-bit time_t or alsa-lib gets updated to
support both mmap() layouts.
Co-developed-with: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/uapi/sound/asound.h | 110 ++++++++++++++++++++++++++++++++----
sound/core/pcm_compat.c | 30 +++++-----
sound/core/pcm_lib.c | 10 ++--
sound/core/pcm_native.c | 38 ++++++++-----
4 files changed, 147 insertions(+), 41 deletions(-)
diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
index ad86c5a7a1e2..df9983e7ead5 100644
--- a/include/uapi/sound/asound.h
+++ b/include/uapi/sound/asound.h
@@ -35,6 +35,8 @@
#include <time.h>
#endif
+#include <asm/byteorder.h>
+
/*
* protocol version
*/
@@ -301,7 +303,9 @@ typedef int __bitwise snd_pcm_subformat_t;
#define SNDRV_PCM_INFO_DRAIN_TRIGGER 0x40000000 /* internal kernel flag - trigger in drain */
#define SNDRV_PCM_INFO_FIFO_IN_FRAMES 0x80000000 /* internal kernel flag - FIFO size is in frames */
-
+#if (__BITS_PER_LONG == 32 && defined(__USE_TIME_BITS64)) || defined __KERNEL__
+#define __SND_STRUCT_TIME64
+#endif
typedef int __bitwise snd_pcm_state_t;
#define SNDRV_PCM_STATE_OPEN ((__force snd_pcm_state_t) 0) /* stream is open */
@@ -317,8 +321,17 @@ typedef int __bitwise snd_pcm_state_t;
enum {
SNDRV_PCM_MMAP_OFFSET_DATA = 0x00000000,
- SNDRV_PCM_MMAP_OFFSET_STATUS = 0x80000000,
- SNDRV_PCM_MMAP_OFFSET_CONTROL = 0x81000000,
+ SNDRV_PCM_MMAP_OFFSET_STATUS_OLD = 0x80000000,
+ SNDRV_PCM_MMAP_OFFSET_CONTROL_OLD = 0x81000000,
+ SNDRV_PCM_MMAP_OFFSET_STATUS_NEW = 0x82000000,
+ SNDRV_PCM_MMAP_OFFSET_CONTROL_NEW = 0x83000000,
+#ifdef __SND_STRUCT_TIME64
+ SNDRV_PCM_MMAP_OFFSET_STATUS = SNDRV_PCM_MMAP_OFFSET_STATUS_NEW,
+ SNDRV_PCM_MMAP_OFFSET_CONTROL = SNDRV_PCM_MMAP_OFFSET_CONTROL_NEW,
+#else
+ SNDRV_PCM_MMAP_OFFSET_STATUS = SNDRV_PCM_MMAP_OFFSET_STATUS_OLD,
+ SNDRV_PCM_MMAP_OFFSET_CONTROL = SNDRV_PCM_MMAP_OFFSET_CONTROL_OLD,
+#endif
};
union snd_pcm_sync_id {
@@ -480,16 +493,46 @@ struct snd_pcm_status {
};
#endif
-struct snd_pcm_mmap_status {
+/*
+ * For mmap operations, we need the 64-bit layout, both for compat mode,
+ * and for y2038 compatibility. For 64-bit applications, the two definitions
+ * are identical, so we keep the traditional version.
+ */
+#ifdef __SND_STRUCT_TIME64
+#define __snd_pcm_mmap_status64 snd_pcm_mmap_status
+#define __snd_pcm_mmap_control64 snd_pcm_mmap_control
+#define __snd_pcm_sync_ptr64 snd_pcm_sync_ptr
+#ifdef __KERNEL__
+#define __snd_timespec64 __kernel_timespec
+#else
+#define __snd_timespec64 timespec
+#endif
+struct __snd_timespec {
+ __s32 tv_sec;
+ __s32 tv_nsec;
+};
+#else
+#define __snd_pcm_mmap_status snd_pcm_mmap_status
+#define __snd_pcm_mmap_control snd_pcm_mmap_control
+#define __snd_pcm_sync_ptr snd_pcm_sync_ptr
+#define __snd_timespec timespec
+struct __snd_timespec64 {
+ __s64 tv_sec;
+ __s64 tv_nsec;
+};
+
+#endif
+
+struct __snd_pcm_mmap_status {
snd_pcm_state_t state; /* RO: state - SNDRV_PCM_STATE_XXXX */
int pad1; /* Needed for 64 bit alignment */
snd_pcm_uframes_t hw_ptr; /* RO: hw ptr (0...boundary-1) */
- struct timespec tstamp; /* Timestamp */
+ struct __snd_timespec tstamp; /* Timestamp */
snd_pcm_state_t suspended_state; /* RO: suspended stream state */
- struct timespec audio_tstamp; /* from sample counter or wall clock */
+ struct __snd_timespec audio_tstamp; /* from sample counter or wall clock */
};
-struct snd_pcm_mmap_control {
+struct __snd_pcm_mmap_control {
snd_pcm_uframes_t appl_ptr; /* RW: appl ptr (0...boundary-1) */
snd_pcm_uframes_t avail_min; /* RW: min available frames for wakeup */
};
@@ -498,14 +541,59 @@ struct snd_pcm_mmap_control {
#define SNDRV_PCM_SYNC_PTR_APPL (1<<1) /* get appl_ptr from driver (r/w op) */
#define SNDRV_PCM_SYNC_PTR_AVAIL_MIN (1<<2) /* get avail_min from driver */
-struct snd_pcm_sync_ptr {
+struct __snd_pcm_sync_ptr {
unsigned int flags;
union {
- struct snd_pcm_mmap_status status;
+ struct __snd_pcm_mmap_status status;
+ unsigned char reserved[64];
+ } s;
+ union {
+ struct __snd_pcm_mmap_control control;
+ unsigned char reserved[64];
+ } c;
+};
+
+#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
+typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
+typedef char __pad_after_uframe[0];
+#endif
+
+#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
+typedef char __pad_before_uframe[0];
+typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
+#endif
+
+struct __snd_pcm_mmap_status64 {
+ __s32 state; /* RO: state - SNDRV_PCM_STATE_XXXX */
+ __u32 pad1; /* Needed for 64 bit alignment */
+ __pad_before_uframe __pad1;
+ snd_pcm_uframes_t hw_ptr; /* RO: hw ptr (0...boundary-1) */
+ __pad_after_uframe __pad2;
+ struct __snd_timespec64 tstamp; /* Timestamp */
+ __s32 suspended_state; /* RO: suspended stream state */
+ __u32 pad3; /* Needed for 64 bit alignment */
+ struct __snd_timespec64 audio_tstamp; /* sample counter or wall clock */
+};
+
+struct __snd_pcm_mmap_control64 {
+ __pad_before_uframe __pad1;
+ snd_pcm_uframes_t appl_ptr; /* RW: appl ptr (0...boundary-1) */
+ __pad_before_uframe __pad2;
+
+ __pad_before_uframe __pad3;
+ snd_pcm_uframes_t avail_min; /* RW: min available frames for wakeup */
+ __pad_after_uframe __pad4;
+};
+
+struct __snd_pcm_sync_ptr64 {
+ __u32 flags;
+ __u32 pad1;
+ union {
+ struct __snd_pcm_mmap_status64 status;
unsigned char reserved[64];
} s;
union {
- struct snd_pcm_mmap_control control;
+ struct __snd_pcm_mmap_control64 control;
unsigned char reserved[64];
} c;
};
@@ -590,6 +678,8 @@ enum {
#define SNDRV_PCM_IOCTL_STATUS _IOR('A', 0x20, struct snd_pcm_status)
#define SNDRV_PCM_IOCTL_DELAY _IOR('A', 0x21, snd_pcm_sframes_t)
#define SNDRV_PCM_IOCTL_HWSYNC _IO('A', 0x22)
+#define __SNDRV_PCM_IOCTL_SYNC_PTR _IOWR('A', 0x23, struct __snd_pcm_sync_ptr)
+#define __SNDRV_PCM_IOCTL_SYNC_PTR64 _IOWR('A', 0x23, struct __snd_pcm_sync_ptr64)
#define SNDRV_PCM_IOCTL_SYNC_PTR _IOWR('A', 0x23, struct snd_pcm_sync_ptr)
#define SNDRV_PCM_IOCTL_STATUS_EXT _IOWR('A', 0x24, struct snd_pcm_status)
#define SNDRV_PCM_IOCTL_CHANNEL_INFO _IOR('A', 0x32, struct snd_pcm_channel_info)
diff --git a/sound/core/pcm_compat.c b/sound/core/pcm_compat.c
index 6a2e5ea145e6..967c689fb8da 100644
--- a/sound/core/pcm_compat.c
+++ b/sound/core/pcm_compat.c
@@ -178,8 +178,6 @@ struct compat_snd_pcm_status64 {
unsigned char reserved[52-4*sizeof(s64)];
} __packed;
-#define put_timespec(src, dst) copy_to_user(dst, src, sizeof(*dst))
-
static int snd_pcm_status_user_compat64(struct snd_pcm_substream *substream,
struct compat_snd_pcm_status64 __user *src,
bool ext)
@@ -382,10 +380,12 @@ struct snd_pcm_mmap_status_x32 {
s32 pad1;
u32 hw_ptr;
u32 pad2; /* alignment */
- struct timespec tstamp;
+ s64 tstamp_sec;
+ s64 tstamp_nsec;
s32 suspended_state;
s32 pad3;
- struct timespec audio_tstamp;
+ s64 audio_tstamp_sec;
+ s64 audio_tstamp_nsec;
} __packed;
struct snd_pcm_mmap_control_x32 {
@@ -453,9 +453,11 @@ static int snd_pcm_ioctl_sync_ptr_x32(struct snd_pcm_substream *substream,
snd_pcm_stream_unlock_irq(substream);
if (put_user(sstatus.state, &src->s.status.state) ||
put_user(sstatus.hw_ptr, &src->s.status.hw_ptr) ||
- put_timespec(&sstatus.tstamp, &src->s.status.tstamp) ||
+ put_user(sstatus.tstamp.tv_sec, &src->s.status.tstamp_sec) ||
+ put_user(sstatus.tstamp.tv_nsec, &src->s.status.tstamp_nsec) ||
put_user(sstatus.suspended_state, &src->s.status.suspended_state) ||
- put_timespec(&sstatus.audio_tstamp, &src->s.status.audio_tstamp) ||
+ put_user(sstatus.audio_tstamp.tv_sec, &src->s.status.audio_tstamp_sec) ||
+ put_user(sstatus.audio_tstamp.tv_nsec, &src->s.status.audio_tstamp_nsec) ||
put_user(scontrol.appl_ptr, &src->c.control.appl_ptr) ||
put_user(scontrol.avail_min, &src->c.control.avail_min))
return -EFAULT;
@@ -480,7 +482,6 @@ enum {
SNDRV_PCM_IOCTL_READI_FRAMES32 = _IOR('A', 0x51, struct snd_xferi32),
SNDRV_PCM_IOCTL_WRITEN_FRAMES32 = _IOW('A', 0x52, struct snd_xfern32),
SNDRV_PCM_IOCTL_READN_FRAMES32 = _IOR('A', 0x53, struct snd_xfern32),
- SNDRV_PCM_IOCTL_SYNC_PTR32 = _IOWR('A', 0x23, struct snd_pcm_sync_ptr32),
SNDRV_PCM_IOCTL_STATUS_COMPAT64 = _IOR('A', 0x20, struct compat_snd_pcm_status64),
SNDRV_PCM_IOCTL_STATUS_EXT_COMPAT64 = _IOWR('A', 0x24, struct compat_snd_pcm_status64),
#ifdef CONFIG_X86_X32
@@ -504,8 +505,8 @@ static long snd_pcm_ioctl_compat(struct file *file, unsigned int cmd, unsigned l
/*
* When PCM is used on 32bit mode, we need to disable
- * mmap of PCM status/control records because of the size
- * incompatibility.
+ * mmap of the old PCM status/control records because
+ * of the size incompatibility.
*/
pcm_file->no_compat_mmap = 1;
@@ -527,6 +528,13 @@ static long snd_pcm_ioctl_compat(struct file *file, unsigned int cmd, unsigned l
case SNDRV_PCM_IOCTL_XRUN:
case SNDRV_PCM_IOCTL_LINK:
case SNDRV_PCM_IOCTL_UNLINK:
+ case __SNDRV_PCM_IOCTL_SYNC_PTR32:
+ return snd_pcm_common_ioctl(file, substream, cmd, argp);
+ case __SNDRV_PCM_IOCTL_SYNC_PTR64:
+#ifdef CONFIG_X86_X32
+ if (in_x32_syscall())
+ return snd_pcm_ioctl_sync_ptr_x32(substream, argp);
+#endif /* CONFIG_X86_X32 */
return snd_pcm_common_ioctl(file, substream, cmd, argp);
case SNDRV_PCM_IOCTL_HW_REFINE32:
return snd_pcm_ioctl_hw_params_compat(substream, 1, argp);
@@ -538,8 +546,6 @@ static long snd_pcm_ioctl_compat(struct file *file, unsigned int cmd, unsigned l
return snd_pcm_status_user32(substream, argp, false);
case SNDRV_PCM_IOCTL_STATUS_EXT_COMPAT32:
return snd_pcm_status_user32(substream, argp, true);
- case SNDRV_PCM_IOCTL_SYNC_PTR32:
- return snd_pcm_ioctl_sync_ptr_compat(substream, argp);
case SNDRV_PCM_IOCTL_CHANNEL_INFO32:
return snd_pcm_ioctl_channel_info_compat(substream, argp);
case SNDRV_PCM_IOCTL_WRITEI_FRAMES32:
@@ -561,8 +567,6 @@ static long snd_pcm_ioctl_compat(struct file *file, unsigned int cmd, unsigned l
case SNDRV_PCM_IOCTL_STATUS_EXT_COMPAT64:
return snd_pcm_status_user_compat64(substream, argp, true);
#ifdef CONFIG_X86_X32
- case SNDRV_PCM_IOCTL_SYNC_PTR_X32:
- return snd_pcm_ioctl_sync_ptr_x32(substream, argp);
case SNDRV_PCM_IOCTL_CHANNEL_INFO_X32:
return snd_pcm_ioctl_channel_info_x32(substream, argp);
#endif /* CONFIG_X86_X32 */
diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c
index ea5518d44e66..0271802bfba9 100644
--- a/sound/core/pcm_lib.c
+++ b/sound/core/pcm_lib.c
@@ -148,7 +148,8 @@ void __snd_pcm_xrun(struct snd_pcm_substream *substream)
struct timespec64 tstamp;
snd_pcm_gettime(runtime, &tstamp);
- runtime->status->tstamp = timespec64_to_timespec(tstamp);
+ runtime->status->tstamp.tv_sec = tstamp.tv_sec;
+ runtime->status->tstamp.tv_nsec = tstamp.tv_nsec;
}
snd_pcm_stop(substream, SNDRV_PCM_STATE_XRUN);
if (xrun_debug(substream, XRUN_DEBUG_BASIC)) {
@@ -238,9 +239,10 @@ static void update_audio_tstamp(struct snd_pcm_substream *substream,
if (runtime->status->audio_tstamp.tv_sec != audio_tstamp->tv_sec ||
runtime->status->audio_tstamp.tv_nsec != audio_tstamp->tv_nsec) {
- runtime->status->audio_tstamp =
- timespec64_to_timespec(*audio_tstamp);
- runtime->status->tstamp = timespec64_to_timespec(*curr_tstamp);
+ runtime->status->audio_tstamp.tv_sec = audio_tstamp->tv_sec;
+ runtime->status->audio_tstamp.tv_nsec = audio_tstamp->tv_nsec;
+ runtime->status->tstamp.tv_sec = curr_tstamp->tv_sec;
+ runtime->status->tstamp.tv_nsec = curr_tstamp->tv_nsec;
}
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index ba0636a2b437..5a1245509eac 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -2889,14 +2889,15 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
return 0;
}
-#ifdef CONFIG_COMPAT
struct snd_pcm_mmap_status32 {
s32 state;
s32 pad1;
u32 hw_ptr;
- struct compat_timespec tstamp;
+ s32 tstamp_sec;
+ s32 tstamp_nsec;
s32 suspended_state;
- struct compat_timespec audio_tstamp;
+ s32 audio_tstamp_sec;
+ s32 audio_tstamp_nsec;
} __attribute__((packed));
struct snd_pcm_mmap_control32 {
@@ -2976,17 +2977,18 @@ static int snd_pcm_ioctl_sync_ptr_compat(struct snd_pcm_substream *substream,
snd_pcm_stream_unlock_irq(substream);
if (put_user(sstatus.state, &src->s.status.state) ||
put_user(sstatus.hw_ptr, &src->s.status.hw_ptr) ||
- compat_put_timespec(&sstatus.tstamp, &src->s.status.tstamp) ||
+ put_user(sstatus.tstamp.tv_sec, &src->s.status.tstamp_sec) ||
+ put_user(sstatus.tstamp.tv_nsec, &src->s.status.tstamp_nsec) ||
put_user(sstatus.suspended_state, &src->s.status.suspended_state) ||
- compat_put_timespec(&sstatus.audio_tstamp,
- &src->s.status.audio_tstamp) ||
+ put_user(sstatus.audio_tstamp.tv_sec, &src->s.status.audio_tstamp_sec) ||
+ put_user(sstatus.audio_tstamp.tv_nsec, &src->s.status.audio_tstamp_nsec) ||
put_user(scontrol.appl_ptr, &src->c.control.appl_ptr) ||
put_user(scontrol.avail_min, &src->c.control.avail_min))
return -EFAULT;
return 0;
}
-#endif
+#define __SNDRV_PCM_IOCTL_SYNC_PTR32 _IOWR('A', 0x23, struct snd_pcm_sync_ptr32)
static int snd_pcm_tstamp(struct snd_pcm_substream *substream, int __user *_arg)
{
@@ -3156,7 +3158,9 @@ static int snd_pcm_common_ioctl(struct file *file,
return -EFAULT;
return 0;
}
- case SNDRV_PCM_IOCTL_SYNC_PTR:
+ case __SNDRV_PCM_IOCTL_SYNC_PTR32:
+ return snd_pcm_ioctl_sync_ptr_compat(substream, arg);
+ case __SNDRV_PCM_IOCTL_SYNC_PTR64:
return snd_pcm_sync_ptr(substream, arg);
#ifdef CONFIG_SND_SUPPORT_OLD_API
case SNDRV_PCM_IOCTL_HW_REFINE_OLD:
@@ -3494,8 +3498,6 @@ static int snd_pcm_mmap_control(struct snd_pcm_substream *substream, struct file
static bool pcm_status_mmap_allowed(struct snd_pcm_file *pcm_file)
{
- if (pcm_file->no_compat_mmap)
- return false;
/* See pcm_control_mmap_allowed() below.
* Since older alsa-lib requires both status and control mmaps to be
* coupled, we have to disable the status mmap for old alsa-lib, too.
@@ -3720,11 +3722,19 @@ static int snd_pcm_mmap(struct file *file, struct vm_area_struct *area)
offset = area->vm_pgoff << PAGE_SHIFT;
switch (offset) {
- case SNDRV_PCM_MMAP_OFFSET_STATUS:
+ case SNDRV_PCM_MMAP_OFFSET_STATUS_OLD:
+ if (pcm_file->no_compat_mmap || !IS_ENABLED(CONFIG_64BIT))
+ return -ENXIO;
+ /* fallthrough */
+ case SNDRV_PCM_MMAP_OFFSET_STATUS_NEW:
if (!pcm_status_mmap_allowed(pcm_file))
return -ENXIO;
return snd_pcm_mmap_status(substream, file, area);
- case SNDRV_PCM_MMAP_OFFSET_CONTROL:
+ case SNDRV_PCM_MMAP_OFFSET_CONTROL_OLD:
+ if (pcm_file->no_compat_mmap || !IS_ENABLED(CONFIG_64BIT))
+ return -ENXIO;
+ /* fallthrough */
+ case SNDRV_PCM_MMAP_OFFSET_CONTROL_NEW:
if (!pcm_control_mmap_allowed(pcm_file))
return -ENXIO;
return snd_pcm_mmap_control(substream, file, area);
@@ -3884,9 +3894,9 @@ static unsigned long snd_pcm_get_unmapped_area(struct file *file,
unsigned long offset = pgoff << PAGE_SHIFT;
switch (offset) {
- case SNDRV_PCM_MMAP_OFFSET_STATUS:
+ case SNDRV_PCM_MMAP_OFFSET_STATUS_NEW:
return (unsigned long)runtime->status;
- case SNDRV_PCM_MMAP_OFFSET_CONTROL:
+ case SNDRV_PCM_MMAP_OFFSET_CONTROL_NEW:
return (unsigned long)runtime->control;
default:
return (unsigned long)runtime->dma_area + offset;
--
2.20.0
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply related [flat|nested] 94+ messages in thread* Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2019-12-11 21:20 ` [alsa-devel] " Arnd Bergmann
@ 2021-10-06 17:49 ` Michael Forney
-1 siblings, 0 replies; 94+ messages in thread
From: Michael Forney @ 2021-10-06 17:49 UTC (permalink / raw)
To: Arnd Bergmann
Cc: alsa-devel, Takashi Iwai, Baolin Wang, y2038, linux-kernel,
Mark Brown, Baolin Wang
Arnd Bergmann <arnd@arndb.de> wrote:
> +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> +typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> +typedef char __pad_after_uframe[0];
> +#endif
> +
> +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> +typedef char __pad_before_uframe[0];
> +typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> +#endif
> +
> +struct __snd_pcm_mmap_status64 {
> + __s32 state; /* RO: state - SNDRV_PCM_STATE_XXXX */
> + __u32 pad1; /* Needed for 64 bit alignment */
> + __pad_before_uframe __pad1;
> + snd_pcm_uframes_t hw_ptr; /* RO: hw ptr (0...boundary-1) */
> + __pad_after_uframe __pad2;
> + struct __snd_timespec64 tstamp; /* Timestamp */
> + __s32 suspended_state; /* RO: suspended stream state */
> + __u32 pad3; /* Needed for 64 bit alignment */
> + struct __snd_timespec64 audio_tstamp; /* sample counter or wall clock */
> +};
> +
> +struct __snd_pcm_mmap_control64 {
> + __pad_before_uframe __pad1;
> + snd_pcm_uframes_t appl_ptr; /* RW: appl ptr (0...boundary-1) */
> + __pad_before_uframe __pad2;
I was looking through this header and happened to notice that this
padding is wrong. I believe it should be __pad_after_uframe here.
I'm not sure of the implications of this typo, but I suspect it
breaks something on 32-bit systems with 64-bit time (regardless of
the endianness, since it changes the offset of avail_min).
> +
> + __pad_before_uframe __pad3;
> + snd_pcm_uframes_t avail_min; /* RW: min available frames for wakeup */
> + __pad_after_uframe __pad4;
> +};
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-06 17:49 ` Michael Forney
0 siblings, 0 replies; 94+ messages in thread
From: Michael Forney @ 2021-10-06 17:49 UTC (permalink / raw)
To: Arnd Bergmann
Cc: alsa-devel, Baolin Wang, y2038, linux-kernel, Takashi Iwai,
Mark Brown, Baolin Wang
Arnd Bergmann <arnd@arndb.de> wrote:
> +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> +typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> +typedef char __pad_after_uframe[0];
> +#endif
> +
> +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> +typedef char __pad_before_uframe[0];
> +typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> +#endif
> +
> +struct __snd_pcm_mmap_status64 {
> + __s32 state; /* RO: state - SNDRV_PCM_STATE_XXXX */
> + __u32 pad1; /* Needed for 64 bit alignment */
> + __pad_before_uframe __pad1;
> + snd_pcm_uframes_t hw_ptr; /* RO: hw ptr (0...boundary-1) */
> + __pad_after_uframe __pad2;
> + struct __snd_timespec64 tstamp; /* Timestamp */
> + __s32 suspended_state; /* RO: suspended stream state */
> + __u32 pad3; /* Needed for 64 bit alignment */
> + struct __snd_timespec64 audio_tstamp; /* sample counter or wall clock */
> +};
> +
> +struct __snd_pcm_mmap_control64 {
> + __pad_before_uframe __pad1;
> + snd_pcm_uframes_t appl_ptr; /* RW: appl ptr (0...boundary-1) */
> + __pad_before_uframe __pad2;
I was looking through this header and happened to notice that this
padding is wrong. I believe it should be __pad_after_uframe here.
I'm not sure of the implications of this typo, but I suspect it
breaks something on 32-bit systems with 64-bit time (regardless of
the endianness, since it changes the offset of avail_min).
> +
> + __pad_before_uframe __pad3;
> + snd_pcm_uframes_t avail_min; /* RW: min available frames for wakeup */
> + __pad_after_uframe __pad4;
> +};
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-06 17:49 ` Michael Forney
@ 2021-10-07 10:52 ` Takashi Iwai
-1 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2021-10-07 10:52 UTC (permalink / raw)
To: Michael Forney
Cc: Arnd Bergmann, alsa-devel, Takashi Iwai, Baolin Wang, y2038,
linux-kernel, Mark Brown, Baolin Wang
On Wed, 06 Oct 2021 19:49:17 +0200,
Michael Forney wrote:
>
> Arnd Bergmann <arnd@arndb.de> wrote:
> > +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> > +typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > +typedef char __pad_after_uframe[0];
> > +#endif
> > +
> > +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> > +typedef char __pad_before_uframe[0];
> > +typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > +#endif
> > +
> > +struct __snd_pcm_mmap_status64 {
> > + __s32 state; /* RO: state - SNDRV_PCM_STATE_XXXX */
> > + __u32 pad1; /* Needed for 64 bit alignment */
> > + __pad_before_uframe __pad1;
> > + snd_pcm_uframes_t hw_ptr; /* RO: hw ptr (0...boundary-1) */
> > + __pad_after_uframe __pad2;
> > + struct __snd_timespec64 tstamp; /* Timestamp */
> > + __s32 suspended_state; /* RO: suspended stream state */
> > + __u32 pad3; /* Needed for 64 bit alignment */
> > + struct __snd_timespec64 audio_tstamp; /* sample counter or wall clock */
> > +};
> > +
> > +struct __snd_pcm_mmap_control64 {
> > + __pad_before_uframe __pad1;
> > + snd_pcm_uframes_t appl_ptr; /* RW: appl ptr (0...boundary-1) */
> > + __pad_before_uframe __pad2;
>
> I was looking through this header and happened to notice that this
> padding is wrong. I believe it should be __pad_after_uframe here.
>
> I'm not sure of the implications of this typo, but I suspect it
> breaks something on 32-bit systems with 64-bit time (regardless of
> the endianness, since it changes the offset of avail_min).
Right, that's the expected breakage. It seems that the 64bit time on
32bit arch is still rare, so we haven't heard a regression by that, so
far...
In anyway, care to send a formal fix patch?
Thanks for catching this!
Takashi
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-07 10:52 ` Takashi Iwai
0 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2021-10-07 10:52 UTC (permalink / raw)
To: Michael Forney
Cc: alsa-devel, Arnd Bergmann, Baolin Wang, y2038, linux-kernel,
Takashi Iwai, Mark Brown, Baolin Wang
On Wed, 06 Oct 2021 19:49:17 +0200,
Michael Forney wrote:
>
> Arnd Bergmann <arnd@arndb.de> wrote:
> > +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> > +typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > +typedef char __pad_after_uframe[0];
> > +#endif
> > +
> > +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> > +typedef char __pad_before_uframe[0];
> > +typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > +#endif
> > +
> > +struct __snd_pcm_mmap_status64 {
> > + __s32 state; /* RO: state - SNDRV_PCM_STATE_XXXX */
> > + __u32 pad1; /* Needed for 64 bit alignment */
> > + __pad_before_uframe __pad1;
> > + snd_pcm_uframes_t hw_ptr; /* RO: hw ptr (0...boundary-1) */
> > + __pad_after_uframe __pad2;
> > + struct __snd_timespec64 tstamp; /* Timestamp */
> > + __s32 suspended_state; /* RO: suspended stream state */
> > + __u32 pad3; /* Needed for 64 bit alignment */
> > + struct __snd_timespec64 audio_tstamp; /* sample counter or wall clock */
> > +};
> > +
> > +struct __snd_pcm_mmap_control64 {
> > + __pad_before_uframe __pad1;
> > + snd_pcm_uframes_t appl_ptr; /* RW: appl ptr (0...boundary-1) */
> > + __pad_before_uframe __pad2;
>
> I was looking through this header and happened to notice that this
> padding is wrong. I believe it should be __pad_after_uframe here.
>
> I'm not sure of the implications of this typo, but I suspect it
> breaks something on 32-bit systems with 64-bit time (regardless of
> the endianness, since it changes the offset of avail_min).
Right, that's the expected breakage. It seems that the 64bit time on
32bit arch is still rare, so we haven't heard a regression by that, so
far...
In anyway, care to send a formal fix patch?
Thanks for catching this!
Takashi
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-07 10:52 ` Takashi Iwai
@ 2021-10-07 11:48 ` Arnd Bergmann
-1 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2021-10-07 11:48 UTC (permalink / raw)
To: Takashi Iwai
Cc: Michael Forney, Arnd Bergmann, ALSA Development Mailing List,
Takashi Iwai, Baolin Wang, y2038 Mailman List,
Linux Kernel Mailing List, Mark Brown, Baolin Wang
On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai <tiwai@suse.de> wrote:
> On Wed, 06 Oct 2021 19:49:17 +0200, Michael Forney wrote:
> >
> > Arnd Bergmann <arnd@arndb.de> wrote:
> > > +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> > > +typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > +typedef char __pad_after_uframe[0];
> > > +#endif
> > > +
> > > +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> > > +typedef char __pad_before_uframe[0];
> > > +typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > +#endif
> > > +
> > > +struct __snd_pcm_mmap_status64 {
> > > + __s32 state; /* RO: state - SNDRV_PCM_STATE_XXXX */
> > > + __u32 pad1; /* Needed for 64 bit alignment */
> > > + __pad_before_uframe __pad1;
> > > + snd_pcm_uframes_t hw_ptr; /* RO: hw ptr (0...boundary-1) */
> > > + __pad_after_uframe __pad2;
> > > + struct __snd_timespec64 tstamp; /* Timestamp */
> > > + __s32 suspended_state; /* RO: suspended stream state */
> > > + __u32 pad3; /* Needed for 64 bit alignment */
> > > + struct __snd_timespec64 audio_tstamp; /* sample counter or wall clock */
> > > +};
> > > +
> > > +struct __snd_pcm_mmap_control64 {
> > > + __pad_before_uframe __pad1;
> > > + snd_pcm_uframes_t appl_ptr; /* RW: appl ptr (0...boundary-1) */
> > > + __pad_before_uframe __pad2;
> >
> > I was looking through this header and happened to notice that this
> > padding is wrong. I believe it should be __pad_after_uframe here.
> >
> > I'm not sure of the implications of this typo, but I suspect it
> > breaks something on 32-bit systems with 64-bit time (regardless of
> > the endianness, since it changes the offset of avail_min).
Thanks a lot for the report! Yes, this is definitely broken in some ways.
> Right, that's the expected breakage. It seems that the 64bit time on
> 32bit arch is still rare, so we haven't heard a regression by that, so
> far...
It might actually be worse: on a native 32-bit kernel, both user space
and kernel see the same broken definition with a 64-bit time_t, which
would end up actually making it work as expected. However, in
compat mode, the layout seen on the 32-bit user space is now
different from what the 64-bit kernel has, which would in turn not
work, in both the SNDRV_PCM_IOCTL_SYNC_PTR ioctl and in
the mmap() interface.
Fixing the layout to look like the way we had intended would make
newly compiled applications work in compat mode, but would break
applications built against the old header on new kernels and also
newly built applications on old kernels.
I still hope I missed something and it's not quite that bad, but I
fear the best we can do in this case make the broken interface
the normative one and fixing compat mode to write
mmap_control64->avail_min in the wrong location for
SNDRV_PCM_IOCTL_SYNC_PTR, as well as disabling
the mmap() interface again for compat tasks.
As far as I can tell, the broken interface will always result in
user space seeing a zero value for "avail_min". Can you
make a prediction what that would mean for actual
applications? Will they have no audio output, run into
a crash, or be able to use recover and appear to work normally
here?
Arnd
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-07 11:48 ` Arnd Bergmann
0 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2021-10-07 11:48 UTC (permalink / raw)
To: Takashi Iwai
Cc: ALSA Development Mailing List, Arnd Bergmann, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, Takashi Iwai,
Michael Forney, Mark Brown, Baolin Wang
On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai <tiwai@suse.de> wrote:
> On Wed, 06 Oct 2021 19:49:17 +0200, Michael Forney wrote:
> >
> > Arnd Bergmann <arnd@arndb.de> wrote:
> > > +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> > > +typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > +typedef char __pad_after_uframe[0];
> > > +#endif
> > > +
> > > +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> > > +typedef char __pad_before_uframe[0];
> > > +typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > +#endif
> > > +
> > > +struct __snd_pcm_mmap_status64 {
> > > + __s32 state; /* RO: state - SNDRV_PCM_STATE_XXXX */
> > > + __u32 pad1; /* Needed for 64 bit alignment */
> > > + __pad_before_uframe __pad1;
> > > + snd_pcm_uframes_t hw_ptr; /* RO: hw ptr (0...boundary-1) */
> > > + __pad_after_uframe __pad2;
> > > + struct __snd_timespec64 tstamp; /* Timestamp */
> > > + __s32 suspended_state; /* RO: suspended stream state */
> > > + __u32 pad3; /* Needed for 64 bit alignment */
> > > + struct __snd_timespec64 audio_tstamp; /* sample counter or wall clock */
> > > +};
> > > +
> > > +struct __snd_pcm_mmap_control64 {
> > > + __pad_before_uframe __pad1;
> > > + snd_pcm_uframes_t appl_ptr; /* RW: appl ptr (0...boundary-1) */
> > > + __pad_before_uframe __pad2;
> >
> > I was looking through this header and happened to notice that this
> > padding is wrong. I believe it should be __pad_after_uframe here.
> >
> > I'm not sure of the implications of this typo, but I suspect it
> > breaks something on 32-bit systems with 64-bit time (regardless of
> > the endianness, since it changes the offset of avail_min).
Thanks a lot for the report! Yes, this is definitely broken in some ways.
> Right, that's the expected breakage. It seems that the 64bit time on
> 32bit arch is still rare, so we haven't heard a regression by that, so
> far...
It might actually be worse: on a native 32-bit kernel, both user space
and kernel see the same broken definition with a 64-bit time_t, which
would end up actually making it work as expected. However, in
compat mode, the layout seen on the 32-bit user space is now
different from what the 64-bit kernel has, which would in turn not
work, in both the SNDRV_PCM_IOCTL_SYNC_PTR ioctl and in
the mmap() interface.
Fixing the layout to look like the way we had intended would make
newly compiled applications work in compat mode, but would break
applications built against the old header on new kernels and also
newly built applications on old kernels.
I still hope I missed something and it's not quite that bad, but I
fear the best we can do in this case make the broken interface
the normative one and fixing compat mode to write
mmap_control64->avail_min in the wrong location for
SNDRV_PCM_IOCTL_SYNC_PTR, as well as disabling
the mmap() interface again for compat tasks.
As far as I can tell, the broken interface will always result in
user space seeing a zero value for "avail_min". Can you
make a prediction what that would mean for actual
applications? Will they have no audio output, run into
a crash, or be able to use recover and appear to work normally
here?
Arnd
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-07 11:48 ` Arnd Bergmann
@ 2021-10-07 12:43 ` Takashi Iwai
-1 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2021-10-07 12:43 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Michael Forney, ALSA Development Mailing List, Takashi Iwai,
Baolin Wang, y2038 Mailman List, Linux Kernel Mailing List,
Mark Brown, Baolin Wang
On Thu, 07 Oct 2021 13:48:44 +0200,
Arnd Bergmann wrote:
>
> On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai <tiwai@suse.de> wrote:
> > On Wed, 06 Oct 2021 19:49:17 +0200, Michael Forney wrote:
> > >
> > > Arnd Bergmann <arnd@arndb.de> wrote:
> > > > +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> > > > +typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > > +typedef char __pad_after_uframe[0];
> > > > +#endif
> > > > +
> > > > +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> > > > +typedef char __pad_before_uframe[0];
> > > > +typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > > +#endif
> > > > +
> > > > +struct __snd_pcm_mmap_status64 {
> > > > + __s32 state; /* RO: state - SNDRV_PCM_STATE_XXXX */
> > > > + __u32 pad1; /* Needed for 64 bit alignment */
> > > > + __pad_before_uframe __pad1;
> > > > + snd_pcm_uframes_t hw_ptr; /* RO: hw ptr (0...boundary-1) */
> > > > + __pad_after_uframe __pad2;
> > > > + struct __snd_timespec64 tstamp; /* Timestamp */
> > > > + __s32 suspended_state; /* RO: suspended stream state */
> > > > + __u32 pad3; /* Needed for 64 bit alignment */
> > > > + struct __snd_timespec64 audio_tstamp; /* sample counter or wall clock */
> > > > +};
> > > > +
> > > > +struct __snd_pcm_mmap_control64 {
> > > > + __pad_before_uframe __pad1;
> > > > + snd_pcm_uframes_t appl_ptr; /* RW: appl ptr (0...boundary-1) */
> > > > + __pad_before_uframe __pad2;
> > >
> > > I was looking through this header and happened to notice that this
> > > padding is wrong. I believe it should be __pad_after_uframe here.
> > >
> > > I'm not sure of the implications of this typo, but I suspect it
> > > breaks something on 32-bit systems with 64-bit time (regardless of
> > > the endianness, since it changes the offset of avail_min).
>
> Thanks a lot for the report! Yes, this is definitely broken in some ways.
>
> > Right, that's the expected breakage. It seems that the 64bit time on
> > 32bit arch is still rare, so we haven't heard a regression by that, so
> > far...
>
> It might actually be worse: on a native 32-bit kernel, both user space
> and kernel see the same broken definition with a 64-bit time_t, which
> would end up actually making it work as expected. However, in
> compat mode, the layout seen on the 32-bit user space is now
> different from what the 64-bit kernel has, which would in turn not
> work, in both the SNDRV_PCM_IOCTL_SYNC_PTR ioctl and in
> the mmap() interface.
>
> Fixing the layout to look like the way we had intended would make
> newly compiled applications work in compat mode, but would break
> applications built against the old header on new kernels and also
> newly built applications on old kernels.
>
> I still hope I missed something and it's not quite that bad, but I
> fear the best we can do in this case make the broken interface
> the normative one and fixing compat mode to write
> mmap_control64->avail_min in the wrong location for
> SNDRV_PCM_IOCTL_SYNC_PTR, as well as disabling
> the mmap() interface again for compat tasks.
>
> As far as I can tell, the broken interface will always result in
> user space seeing a zero value for "avail_min". Can you
> make a prediction what that would mean for actual
> applications? Will they have no audio output, run into
> a crash, or be able to use recover and appear to work normally
> here?
No, fortunately it's only about control->avail_min, and fiddling this
value can't break severely (otherwise it'd be a security problem ;)
In the buggy condition, it's always zero, and the kernel treated as if
1, i.e. wake up as soon as data is available, which is OK-ish for most
applications. Apps usually don't care about the wake-up condition so
much. There are subtle difference and may influence on the stability
of stream processing, but the stability usually depends more strongly
on the hardware and software configurations.
That being said, the impact by this bug (from the application behavior
POV) is likely quite small, but the contamination is large; as you
pointed out, it's much larger than I thought.
The definition in uapi/sound/asound.h is a bit cryptic, but IIUC,
__snd_pcm_mmap_control64 is used for 64bit archs, right? If so, the
problem rather hits more widely on 64bit archs silently. Then, the
influence by this bug must be almost negligible, as we've had no bug
report about the behavior change.
We may just fix it in kernel and for new library with hoping that no
one sees the actual problem. Or, we may provide a complete new set of
mmap offsets and ioctl to cover both broken and fixed interfaces...
The decision depends on how perfectly we'd like to address the bug.
As of now, I'm inclined to go for the former, but I'm open for more
opinions.
thanks,
Takashi
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-07 12:43 ` Takashi Iwai
0 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2021-10-07 12:43 UTC (permalink / raw)
To: Arnd Bergmann
Cc: ALSA Development Mailing List, Baolin Wang, y2038 Mailman List,
Linux Kernel Mailing List, Takashi Iwai, Mark Brown, Baolin Wang,
Michael Forney
On Thu, 07 Oct 2021 13:48:44 +0200,
Arnd Bergmann wrote:
>
> On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai <tiwai@suse.de> wrote:
> > On Wed, 06 Oct 2021 19:49:17 +0200, Michael Forney wrote:
> > >
> > > Arnd Bergmann <arnd@arndb.de> wrote:
> > > > +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> > > > +typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > > +typedef char __pad_after_uframe[0];
> > > > +#endif
> > > > +
> > > > +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> > > > +typedef char __pad_before_uframe[0];
> > > > +typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > > +#endif
> > > > +
> > > > +struct __snd_pcm_mmap_status64 {
> > > > + __s32 state; /* RO: state - SNDRV_PCM_STATE_XXXX */
> > > > + __u32 pad1; /* Needed for 64 bit alignment */
> > > > + __pad_before_uframe __pad1;
> > > > + snd_pcm_uframes_t hw_ptr; /* RO: hw ptr (0...boundary-1) */
> > > > + __pad_after_uframe __pad2;
> > > > + struct __snd_timespec64 tstamp; /* Timestamp */
> > > > + __s32 suspended_state; /* RO: suspended stream state */
> > > > + __u32 pad3; /* Needed for 64 bit alignment */
> > > > + struct __snd_timespec64 audio_tstamp; /* sample counter or wall clock */
> > > > +};
> > > > +
> > > > +struct __snd_pcm_mmap_control64 {
> > > > + __pad_before_uframe __pad1;
> > > > + snd_pcm_uframes_t appl_ptr; /* RW: appl ptr (0...boundary-1) */
> > > > + __pad_before_uframe __pad2;
> > >
> > > I was looking through this header and happened to notice that this
> > > padding is wrong. I believe it should be __pad_after_uframe here.
> > >
> > > I'm not sure of the implications of this typo, but I suspect it
> > > breaks something on 32-bit systems with 64-bit time (regardless of
> > > the endianness, since it changes the offset of avail_min).
>
> Thanks a lot for the report! Yes, this is definitely broken in some ways.
>
> > Right, that's the expected breakage. It seems that the 64bit time on
> > 32bit arch is still rare, so we haven't heard a regression by that, so
> > far...
>
> It might actually be worse: on a native 32-bit kernel, both user space
> and kernel see the same broken definition with a 64-bit time_t, which
> would end up actually making it work as expected. However, in
> compat mode, the layout seen on the 32-bit user space is now
> different from what the 64-bit kernel has, which would in turn not
> work, in both the SNDRV_PCM_IOCTL_SYNC_PTR ioctl and in
> the mmap() interface.
>
> Fixing the layout to look like the way we had intended would make
> newly compiled applications work in compat mode, but would break
> applications built against the old header on new kernels and also
> newly built applications on old kernels.
>
> I still hope I missed something and it's not quite that bad, but I
> fear the best we can do in this case make the broken interface
> the normative one and fixing compat mode to write
> mmap_control64->avail_min in the wrong location for
> SNDRV_PCM_IOCTL_SYNC_PTR, as well as disabling
> the mmap() interface again for compat tasks.
>
> As far as I can tell, the broken interface will always result in
> user space seeing a zero value for "avail_min". Can you
> make a prediction what that would mean for actual
> applications? Will they have no audio output, run into
> a crash, or be able to use recover and appear to work normally
> here?
No, fortunately it's only about control->avail_min, and fiddling this
value can't break severely (otherwise it'd be a security problem ;)
In the buggy condition, it's always zero, and the kernel treated as if
1, i.e. wake up as soon as data is available, which is OK-ish for most
applications. Apps usually don't care about the wake-up condition so
much. There are subtle difference and may influence on the stability
of stream processing, but the stability usually depends more strongly
on the hardware and software configurations.
That being said, the impact by this bug (from the application behavior
POV) is likely quite small, but the contamination is large; as you
pointed out, it's much larger than I thought.
The definition in uapi/sound/asound.h is a bit cryptic, but IIUC,
__snd_pcm_mmap_control64 is used for 64bit archs, right? If so, the
problem rather hits more widely on 64bit archs silently. Then, the
influence by this bug must be almost negligible, as we've had no bug
report about the behavior change.
We may just fix it in kernel and for new library with hoping that no
one sees the actual problem. Or, we may provide a complete new set of
mmap offsets and ioctl to cover both broken and fixed interfaces...
The decision depends on how perfectly we'd like to address the bug.
As of now, I'm inclined to go for the former, but I'm open for more
opinions.
thanks,
Takashi
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-07 12:43 ` Takashi Iwai
@ 2021-10-07 13:02 ` Takashi Iwai
-1 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2021-10-07 13:02 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Michael Forney, ALSA Development Mailing List, Takashi Iwai,
Baolin Wang, y2038 Mailman List, Linux Kernel Mailing List,
Mark Brown, Baolin Wang
On Thu, 07 Oct 2021 14:43:53 +0200,
Takashi Iwai wrote:
>
> On Thu, 07 Oct 2021 13:48:44 +0200,
> Arnd Bergmann wrote:
> >
> > On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > On Wed, 06 Oct 2021 19:49:17 +0200, Michael Forney wrote:
> > > >
> > > > Arnd Bergmann <arnd@arndb.de> wrote:
> > > > > +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> > > > > +typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > > > +typedef char __pad_after_uframe[0];
> > > > > +#endif
> > > > > +
> > > > > +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> > > > > +typedef char __pad_before_uframe[0];
> > > > > +typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > > > +#endif
> > > > > +
> > > > > +struct __snd_pcm_mmap_status64 {
> > > > > + __s32 state; /* RO: state - SNDRV_PCM_STATE_XXXX */
> > > > > + __u32 pad1; /* Needed for 64 bit alignment */
> > > > > + __pad_before_uframe __pad1;
> > > > > + snd_pcm_uframes_t hw_ptr; /* RO: hw ptr (0...boundary-1) */
> > > > > + __pad_after_uframe __pad2;
> > > > > + struct __snd_timespec64 tstamp; /* Timestamp */
> > > > > + __s32 suspended_state; /* RO: suspended stream state */
> > > > > + __u32 pad3; /* Needed for 64 bit alignment */
> > > > > + struct __snd_timespec64 audio_tstamp; /* sample counter or wall clock */
> > > > > +};
> > > > > +
> > > > > +struct __snd_pcm_mmap_control64 {
> > > > > + __pad_before_uframe __pad1;
> > > > > + snd_pcm_uframes_t appl_ptr; /* RW: appl ptr (0...boundary-1) */
> > > > > + __pad_before_uframe __pad2;
> > > >
> > > > I was looking through this header and happened to notice that this
> > > > padding is wrong. I believe it should be __pad_after_uframe here.
> > > >
> > > > I'm not sure of the implications of this typo, but I suspect it
> > > > breaks something on 32-bit systems with 64-bit time (regardless of
> > > > the endianness, since it changes the offset of avail_min).
> >
> > Thanks a lot for the report! Yes, this is definitely broken in some ways.
> >
> > > Right, that's the expected breakage. It seems that the 64bit time on
> > > 32bit arch is still rare, so we haven't heard a regression by that, so
> > > far...
> >
> > It might actually be worse: on a native 32-bit kernel, both user space
> > and kernel see the same broken definition with a 64-bit time_t, which
> > would end up actually making it work as expected. However, in
> > compat mode, the layout seen on the 32-bit user space is now
> > different from what the 64-bit kernel has, which would in turn not
> > work, in both the SNDRV_PCM_IOCTL_SYNC_PTR ioctl and in
> > the mmap() interface.
> >
> > Fixing the layout to look like the way we had intended would make
> > newly compiled applications work in compat mode, but would break
> > applications built against the old header on new kernels and also
> > newly built applications on old kernels.
> >
> > I still hope I missed something and it's not quite that bad, but I
> > fear the best we can do in this case make the broken interface
> > the normative one and fixing compat mode to write
> > mmap_control64->avail_min in the wrong location for
> > SNDRV_PCM_IOCTL_SYNC_PTR, as well as disabling
> > the mmap() interface again for compat tasks.
> >
> > As far as I can tell, the broken interface will always result in
> > user space seeing a zero value for "avail_min". Can you
> > make a prediction what that would mean for actual
> > applications? Will they have no audio output, run into
> > a crash, or be able to use recover and appear to work normally
> > here?
>
> No, fortunately it's only about control->avail_min, and fiddling this
> value can't break severely (otherwise it'd be a security problem ;)
>
> In the buggy condition, it's always zero, and the kernel treated as if
> 1, i.e. wake up as soon as data is available, which is OK-ish for most
> applications. Apps usually don't care about the wake-up condition so
> much. There are subtle difference and may influence on the stability
> of stream processing, but the stability usually depends more strongly
> on the hardware and software configurations.
>
> That being said, the impact by this bug (from the application behavior
> POV) is likely quite small, but the contamination is large; as you
> pointed out, it's much larger than I thought.
>
> The definition in uapi/sound/asound.h is a bit cryptic, but IIUC,
> __snd_pcm_mmap_control64 is used for 64bit archs, right? If so, the
> problem rather hits more widely on 64bit archs silently. Then, the
> influence by this bug must be almost negligible, as we've had no bug
> report about the behavior change.
Erm, scratch this part: on 64bit arch, both __pad_before_uframe and
__pad_after_uframe is 0-size, so the bug doesn't hit. It's only about
32bit arch.
> We may just fix it in kernel and for new library with hoping that no
> one sees the actual problem. Or, we may provide a complete new set of
> mmap offsets and ioctl to cover both broken and fixed interfaces...
> The decision depends on how perfectly we'd like to address the bug.
> As of now, I'm inclined to go for the former, but I'm open for more
> opinions.
Takashi
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-07 13:02 ` Takashi Iwai
0 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2021-10-07 13:02 UTC (permalink / raw)
To: Arnd Bergmann
Cc: ALSA Development Mailing List, Baolin Wang, y2038 Mailman List,
Linux Kernel Mailing List, Takashi Iwai, Mark Brown, Baolin Wang,
Michael Forney
On Thu, 07 Oct 2021 14:43:53 +0200,
Takashi Iwai wrote:
>
> On Thu, 07 Oct 2021 13:48:44 +0200,
> Arnd Bergmann wrote:
> >
> > On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > On Wed, 06 Oct 2021 19:49:17 +0200, Michael Forney wrote:
> > > >
> > > > Arnd Bergmann <arnd@arndb.de> wrote:
> > > > > +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> > > > > +typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > > > +typedef char __pad_after_uframe[0];
> > > > > +#endif
> > > > > +
> > > > > +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> > > > > +typedef char __pad_before_uframe[0];
> > > > > +typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > > > +#endif
> > > > > +
> > > > > +struct __snd_pcm_mmap_status64 {
> > > > > + __s32 state; /* RO: state - SNDRV_PCM_STATE_XXXX */
> > > > > + __u32 pad1; /* Needed for 64 bit alignment */
> > > > > + __pad_before_uframe __pad1;
> > > > > + snd_pcm_uframes_t hw_ptr; /* RO: hw ptr (0...boundary-1) */
> > > > > + __pad_after_uframe __pad2;
> > > > > + struct __snd_timespec64 tstamp; /* Timestamp */
> > > > > + __s32 suspended_state; /* RO: suspended stream state */
> > > > > + __u32 pad3; /* Needed for 64 bit alignment */
> > > > > + struct __snd_timespec64 audio_tstamp; /* sample counter or wall clock */
> > > > > +};
> > > > > +
> > > > > +struct __snd_pcm_mmap_control64 {
> > > > > + __pad_before_uframe __pad1;
> > > > > + snd_pcm_uframes_t appl_ptr; /* RW: appl ptr (0...boundary-1) */
> > > > > + __pad_before_uframe __pad2;
> > > >
> > > > I was looking through this header and happened to notice that this
> > > > padding is wrong. I believe it should be __pad_after_uframe here.
> > > >
> > > > I'm not sure of the implications of this typo, but I suspect it
> > > > breaks something on 32-bit systems with 64-bit time (regardless of
> > > > the endianness, since it changes the offset of avail_min).
> >
> > Thanks a lot for the report! Yes, this is definitely broken in some ways.
> >
> > > Right, that's the expected breakage. It seems that the 64bit time on
> > > 32bit arch is still rare, so we haven't heard a regression by that, so
> > > far...
> >
> > It might actually be worse: on a native 32-bit kernel, both user space
> > and kernel see the same broken definition with a 64-bit time_t, which
> > would end up actually making it work as expected. However, in
> > compat mode, the layout seen on the 32-bit user space is now
> > different from what the 64-bit kernel has, which would in turn not
> > work, in both the SNDRV_PCM_IOCTL_SYNC_PTR ioctl and in
> > the mmap() interface.
> >
> > Fixing the layout to look like the way we had intended would make
> > newly compiled applications work in compat mode, but would break
> > applications built against the old header on new kernels and also
> > newly built applications on old kernels.
> >
> > I still hope I missed something and it's not quite that bad, but I
> > fear the best we can do in this case make the broken interface
> > the normative one and fixing compat mode to write
> > mmap_control64->avail_min in the wrong location for
> > SNDRV_PCM_IOCTL_SYNC_PTR, as well as disabling
> > the mmap() interface again for compat tasks.
> >
> > As far as I can tell, the broken interface will always result in
> > user space seeing a zero value for "avail_min". Can you
> > make a prediction what that would mean for actual
> > applications? Will they have no audio output, run into
> > a crash, or be able to use recover and appear to work normally
> > here?
>
> No, fortunately it's only about control->avail_min, and fiddling this
> value can't break severely (otherwise it'd be a security problem ;)
>
> In the buggy condition, it's always zero, and the kernel treated as if
> 1, i.e. wake up as soon as data is available, which is OK-ish for most
> applications. Apps usually don't care about the wake-up condition so
> much. There are subtle difference and may influence on the stability
> of stream processing, but the stability usually depends more strongly
> on the hardware and software configurations.
>
> That being said, the impact by this bug (from the application behavior
> POV) is likely quite small, but the contamination is large; as you
> pointed out, it's much larger than I thought.
>
> The definition in uapi/sound/asound.h is a bit cryptic, but IIUC,
> __snd_pcm_mmap_control64 is used for 64bit archs, right? If so, the
> problem rather hits more widely on 64bit archs silently. Then, the
> influence by this bug must be almost negligible, as we've had no bug
> report about the behavior change.
Erm, scratch this part: on 64bit arch, both __pad_before_uframe and
__pad_after_uframe is 0-size, so the bug doesn't hit. It's only about
32bit arch.
> We may just fix it in kernel and for new library with hoping that no
> one sees the actual problem. Or, we may provide a complete new set of
> mmap offsets and ioctl to cover both broken and fixed interfaces...
> The decision depends on how perfectly we'd like to address the bug.
> As of now, I'm inclined to go for the former, but I'm open for more
> opinions.
Takashi
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-07 12:43 ` Takashi Iwai
@ 2021-10-07 13:11 ` Arnd Bergmann
-1 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2021-10-07 13:11 UTC (permalink / raw)
To: Takashi Iwai
Cc: Arnd Bergmann, Michael Forney, ALSA Development Mailing List,
Takashi Iwai, Baolin Wang, y2038 Mailman List,
Linux Kernel Mailing List, Mark Brown, Baolin Wang, musl
On Thu, Oct 7, 2021 at 2:43 PM Takashi Iwai <tiwai@suse.de> wrote:
> On Thu, 07 Oct 2021 13:48:44 +0200, Arnd Bergmann wrote:
> > On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > On Wed, 06 Oct 2021 19:49:17 +0200, Michael Forney wrote:
> >
> > As far as I can tell, the broken interface will always result in
> > user space seeing a zero value for "avail_min". Can you
> > make a prediction what that would mean for actual
> > applications? Will they have no audio output, run into
> > a crash, or be able to use recover and appear to work normally
> > here?
>
> No, fortunately it's only about control->avail_min, and fiddling this
> value can't break severely (otherwise it'd be a security problem ;)
>
> In the buggy condition, it's always zero, and the kernel treated as if
> 1, i.e. wake up as soon as data is available, which is OK-ish for most
> applications. Apps usually don't care about the wake-up condition so
> much. There are subtle difference and may influence on the stability
> of stream processing, but the stability usually depends more strongly
> on the hardware and software configurations.
>
> That being said, the impact by this bug (from the application behavior
> POV) is likely quite small, but the contamination is large; as you
> pointed out, it's much larger than I thought.
Ok, got it.
> The definition in uapi/sound/asound.h is a bit cryptic, but IIUC,
> __snd_pcm_mmap_control64 is used for 64bit archs, right? If so, the
> problem rather hits more widely on 64bit archs silently. Then, the
> influence by this bug must be almost negligible, as we've had no bug
> report about the behavior change.
While __snd_pcm_mmap_control64 is only used on 32-bit
architectures when 64-bit time_t is used. At the moment, this
means all users of musl-1.2.x libc, but not glibc.
On 64-bit architectures, __snd_pcm_mmap_control and
__snd_pcm_mmap_control64 are meant to be identical,
and this is actually true regardless of the bug, since
__pad_before_uframe and __pad_after_uframe both
end up as zero-length arrays here.
> We may just fix it in kernel and for new library with hoping that no
> one sees the actual problem. Or, we may provide a complete new set of
> mmap offsets and ioctl to cover both broken and fixed interfaces...
> The decision depends on how perfectly we'd like to address the bug.
> As of now, I'm inclined to go for the former, but I'm open for more
> opinions.
Adding the musl list to Cc for additional testers, anyone interested
please see [1] for the original report.
It would be good to hear from musl users that are already using
audio support with 32-bit applications on 64-bit kernels, which
is the case that has the problem today. Have you noticed any
problems with audio support here? If not, we can probably
"fix" the kernel here and make the existing binaries behave
the same way on 32-bit kernels. If there are applications that
don't work in that environment today, I think we need to instead
change the kernel to accept the currently broken format on
both 32-bit and 64-bit kernels, possibly introducing yet another
format that works as originally intended but requires a newly
built kernel.
Arnd
[1] https://lore.kernel.org/all/29QBMJU8DE71E.2YZSH8IHT5HMH@mforney.org/
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-07 13:11 ` Arnd Bergmann
0 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2021-10-07 13:11 UTC (permalink / raw)
To: Takashi Iwai
Cc: ALSA Development Mailing List, Arnd Bergmann, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, musl,
Takashi Iwai, Michael Forney, Mark Brown, Baolin Wang
On Thu, Oct 7, 2021 at 2:43 PM Takashi Iwai <tiwai@suse.de> wrote:
> On Thu, 07 Oct 2021 13:48:44 +0200, Arnd Bergmann wrote:
> > On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > On Wed, 06 Oct 2021 19:49:17 +0200, Michael Forney wrote:
> >
> > As far as I can tell, the broken interface will always result in
> > user space seeing a zero value for "avail_min". Can you
> > make a prediction what that would mean for actual
> > applications? Will they have no audio output, run into
> > a crash, or be able to use recover and appear to work normally
> > here?
>
> No, fortunately it's only about control->avail_min, and fiddling this
> value can't break severely (otherwise it'd be a security problem ;)
>
> In the buggy condition, it's always zero, and the kernel treated as if
> 1, i.e. wake up as soon as data is available, which is OK-ish for most
> applications. Apps usually don't care about the wake-up condition so
> much. There are subtle difference and may influence on the stability
> of stream processing, but the stability usually depends more strongly
> on the hardware and software configurations.
>
> That being said, the impact by this bug (from the application behavior
> POV) is likely quite small, but the contamination is large; as you
> pointed out, it's much larger than I thought.
Ok, got it.
> The definition in uapi/sound/asound.h is a bit cryptic, but IIUC,
> __snd_pcm_mmap_control64 is used for 64bit archs, right? If so, the
> problem rather hits more widely on 64bit archs silently. Then, the
> influence by this bug must be almost negligible, as we've had no bug
> report about the behavior change.
While __snd_pcm_mmap_control64 is only used on 32-bit
architectures when 64-bit time_t is used. At the moment, this
means all users of musl-1.2.x libc, but not glibc.
On 64-bit architectures, __snd_pcm_mmap_control and
__snd_pcm_mmap_control64 are meant to be identical,
and this is actually true regardless of the bug, since
__pad_before_uframe and __pad_after_uframe both
end up as zero-length arrays here.
> We may just fix it in kernel and for new library with hoping that no
> one sees the actual problem. Or, we may provide a complete new set of
> mmap offsets and ioctl to cover both broken and fixed interfaces...
> The decision depends on how perfectly we'd like to address the bug.
> As of now, I'm inclined to go for the former, but I'm open for more
> opinions.
Adding the musl list to Cc for additional testers, anyone interested
please see [1] for the original report.
It would be good to hear from musl users that are already using
audio support with 32-bit applications on 64-bit kernels, which
is the case that has the problem today. Have you noticed any
problems with audio support here? If not, we can probably
"fix" the kernel here and make the existing binaries behave
the same way on 32-bit kernels. If there are applications that
don't work in that environment today, I think we need to instead
change the kernel to accept the currently broken format on
both 32-bit and 64-bit kernels, possibly introducing yet another
format that works as originally intended but requires a newly
built kernel.
Arnd
[1] https://lore.kernel.org/all/29QBMJU8DE71E.2YZSH8IHT5HMH@mforney.org/
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-07 13:11 ` Arnd Bergmann
@ 2021-10-07 15:33 ` Takashi Iwai
-1 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2021-10-07 15:33 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Michael Forney, ALSA Development Mailing List, Takashi Iwai,
Baolin Wang, y2038 Mailman List, Linux Kernel Mailing List,
Mark Brown, Baolin Wang, musl
On Thu, 07 Oct 2021 15:11:00 +0200,
Arnd Bergmann wrote:
>
> On Thu, Oct 7, 2021 at 2:43 PM Takashi Iwai <tiwai@suse.de> wrote:
> > On Thu, 07 Oct 2021 13:48:44 +0200, Arnd Bergmann wrote:
> > > On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > On Wed, 06 Oct 2021 19:49:17 +0200, Michael Forney wrote:
> > >
> > > As far as I can tell, the broken interface will always result in
> > > user space seeing a zero value for "avail_min". Can you
> > > make a prediction what that would mean for actual
> > > applications? Will they have no audio output, run into
> > > a crash, or be able to use recover and appear to work normally
> > > here?
> >
> > No, fortunately it's only about control->avail_min, and fiddling this
> > value can't break severely (otherwise it'd be a security problem ;)
> >
> > In the buggy condition, it's always zero, and the kernel treated as if
> > 1, i.e. wake up as soon as data is available, which is OK-ish for most
> > applications. Apps usually don't care about the wake-up condition so
> > much. There are subtle difference and may influence on the stability
> > of stream processing, but the stability usually depends more strongly
> > on the hardware and software configurations.
> >
> > That being said, the impact by this bug (from the application behavior
> > POV) is likely quite small, but the contamination is large; as you
> > pointed out, it's much larger than I thought.
>
> Ok, got it.
>
> > The definition in uapi/sound/asound.h is a bit cryptic, but IIUC,
> > __snd_pcm_mmap_control64 is used for 64bit archs, right? If so, the
> > problem rather hits more widely on 64bit archs silently. Then, the
> > influence by this bug must be almost negligible, as we've had no bug
> > report about the behavior change.
>
> While __snd_pcm_mmap_control64 is only used on 32-bit
> architectures when 64-bit time_t is used. At the moment, this
> means all users of musl-1.2.x libc, but not glibc.
>
> On 64-bit architectures, __snd_pcm_mmap_control and
> __snd_pcm_mmap_control64 are meant to be identical,
> and this is actually true regardless of the bug, since
> __pad_before_uframe and __pad_after_uframe both
> end up as zero-length arrays here.
>
> > We may just fix it in kernel and for new library with hoping that no
> > one sees the actual problem. Or, we may provide a complete new set of
> > mmap offsets and ioctl to cover both broken and fixed interfaces...
> > The decision depends on how perfectly we'd like to address the bug.
> > As of now, I'm inclined to go for the former, but I'm open for more
> > opinions.
>
> Adding the musl list to Cc for additional testers, anyone interested
> please see [1] for the original report.
>
> It would be good to hear from musl users that are already using
> audio support with 32-bit applications on 64-bit kernels, which
> is the case that has the problem today. Have you noticed any
> problems with audio support here? If not, we can probably
> "fix" the kernel here and make the existing binaries behave
> the same way on 32-bit kernels. If there are applications that
> don't work in that environment today, I think we need to instead
> change the kernel to accept the currently broken format on
> both 32-bit and 64-bit kernels, possibly introducing yet another
> format that works as originally intended but requires a newly
> built kernel.
Thanks!
And now, looking more deeply, I feel more desperate.
This bug makes the expected padding gone on little-endian.
On LE 32bit, the buggy definition is:
char __pad1[0];
u32 appl_ptr;
char __pad2[0]; // this should have been [4]
char __pad3[0];
u32 avail_min;
char __pad4[4];
When an application issues SYNC_PTR64 ioctl to submit appl_ptr and
avail_min updates, 64bit kernel (in compat mode) reads directly as:
u64 appl_ptr;
u64 avail_min;
Hence a bogus appl_ptr would be passed if avail_min != 0.
And usually application sets non-zero avail_min.
That is, the bug must hit more severely if the new API were really
used. It wouldn't crash, but some weird streaming behavior can
happen like noise, jumping or underruns.
(Reading back avail_min=0 to user-space is rather harmless. Ditto for
the case of BE, then at least there is no appl_ptr corruption.)
This made me wonder which way to go:
it's certainly possible to fix the new kernel to treat both buggy and
sane formats (disabling compat mmap and re-define ioctls, having the
code for old APIs). The problem is, however, in the case where the
application needs to run on the older kernel that expects the buggy
format. Then apps would still have to send in the old buggy format --
or maybe better in the older 32bit format that won't hit the bug
above. It makes situation more complicated.
Do we know how widely the __USE_TIME_BITS64 is deployed nowadays?
Takashi
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-07 15:33 ` Takashi Iwai
0 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2021-10-07 15:33 UTC (permalink / raw)
To: Arnd Bergmann
Cc: ALSA Development Mailing List, Baolin Wang, y2038 Mailman List,
musl, Linux Kernel Mailing List, Takashi Iwai, Mark Brown,
Baolin Wang, Michael Forney
On Thu, 07 Oct 2021 15:11:00 +0200,
Arnd Bergmann wrote:
>
> On Thu, Oct 7, 2021 at 2:43 PM Takashi Iwai <tiwai@suse.de> wrote:
> > On Thu, 07 Oct 2021 13:48:44 +0200, Arnd Bergmann wrote:
> > > On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > On Wed, 06 Oct 2021 19:49:17 +0200, Michael Forney wrote:
> > >
> > > As far as I can tell, the broken interface will always result in
> > > user space seeing a zero value for "avail_min". Can you
> > > make a prediction what that would mean for actual
> > > applications? Will they have no audio output, run into
> > > a crash, or be able to use recover and appear to work normally
> > > here?
> >
> > No, fortunately it's only about control->avail_min, and fiddling this
> > value can't break severely (otherwise it'd be a security problem ;)
> >
> > In the buggy condition, it's always zero, and the kernel treated as if
> > 1, i.e. wake up as soon as data is available, which is OK-ish for most
> > applications. Apps usually don't care about the wake-up condition so
> > much. There are subtle difference and may influence on the stability
> > of stream processing, but the stability usually depends more strongly
> > on the hardware and software configurations.
> >
> > That being said, the impact by this bug (from the application behavior
> > POV) is likely quite small, but the contamination is large; as you
> > pointed out, it's much larger than I thought.
>
> Ok, got it.
>
> > The definition in uapi/sound/asound.h is a bit cryptic, but IIUC,
> > __snd_pcm_mmap_control64 is used for 64bit archs, right? If so, the
> > problem rather hits more widely on 64bit archs silently. Then, the
> > influence by this bug must be almost negligible, as we've had no bug
> > report about the behavior change.
>
> While __snd_pcm_mmap_control64 is only used on 32-bit
> architectures when 64-bit time_t is used. At the moment, this
> means all users of musl-1.2.x libc, but not glibc.
>
> On 64-bit architectures, __snd_pcm_mmap_control and
> __snd_pcm_mmap_control64 are meant to be identical,
> and this is actually true regardless of the bug, since
> __pad_before_uframe and __pad_after_uframe both
> end up as zero-length arrays here.
>
> > We may just fix it in kernel and for new library with hoping that no
> > one sees the actual problem. Or, we may provide a complete new set of
> > mmap offsets and ioctl to cover both broken and fixed interfaces...
> > The decision depends on how perfectly we'd like to address the bug.
> > As of now, I'm inclined to go for the former, but I'm open for more
> > opinions.
>
> Adding the musl list to Cc for additional testers, anyone interested
> please see [1] for the original report.
>
> It would be good to hear from musl users that are already using
> audio support with 32-bit applications on 64-bit kernels, which
> is the case that has the problem today. Have you noticed any
> problems with audio support here? If not, we can probably
> "fix" the kernel here and make the existing binaries behave
> the same way on 32-bit kernels. If there are applications that
> don't work in that environment today, I think we need to instead
> change the kernel to accept the currently broken format on
> both 32-bit and 64-bit kernels, possibly introducing yet another
> format that works as originally intended but requires a newly
> built kernel.
Thanks!
And now, looking more deeply, I feel more desperate.
This bug makes the expected padding gone on little-endian.
On LE 32bit, the buggy definition is:
char __pad1[0];
u32 appl_ptr;
char __pad2[0]; // this should have been [4]
char __pad3[0];
u32 avail_min;
char __pad4[4];
When an application issues SYNC_PTR64 ioctl to submit appl_ptr and
avail_min updates, 64bit kernel (in compat mode) reads directly as:
u64 appl_ptr;
u64 avail_min;
Hence a bogus appl_ptr would be passed if avail_min != 0.
And usually application sets non-zero avail_min.
That is, the bug must hit more severely if the new API were really
used. It wouldn't crash, but some weird streaming behavior can
happen like noise, jumping or underruns.
(Reading back avail_min=0 to user-space is rather harmless. Ditto for
the case of BE, then at least there is no appl_ptr corruption.)
This made me wonder which way to go:
it's certainly possible to fix the new kernel to treat both buggy and
sane formats (disabling compat mmap and re-define ioctls, having the
code for old APIs). The problem is, however, in the case where the
application needs to run on the older kernel that expects the buggy
format. Then apps would still have to send in the old buggy format --
or maybe better in the older 32bit format that won't hit the bug
above. It makes situation more complicated.
Do we know how widely the __USE_TIME_BITS64 is deployed nowadays?
Takashi
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-07 15:33 ` Takashi Iwai
@ 2021-10-07 16:06 ` Rich Felker
-1 siblings, 0 replies; 94+ messages in thread
From: Rich Felker @ 2021-10-07 16:06 UTC (permalink / raw)
To: Takashi Iwai
Cc: Arnd Bergmann, Michael Forney, ALSA Development Mailing List,
Takashi Iwai, Baolin Wang, y2038 Mailman List,
Linux Kernel Mailing List, Mark Brown, Baolin Wang, musl
On Thu, Oct 07, 2021 at 05:33:19PM +0200, Takashi Iwai wrote:
> On Thu, 07 Oct 2021 15:11:00 +0200,
> Arnd Bergmann wrote:
> >
> > On Thu, Oct 7, 2021 at 2:43 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > On Thu, 07 Oct 2021 13:48:44 +0200, Arnd Bergmann wrote:
> > > > On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > On Wed, 06 Oct 2021 19:49:17 +0200, Michael Forney wrote:
> > > >
> > > > As far as I can tell, the broken interface will always result in
> > > > user space seeing a zero value for "avail_min". Can you
> > > > make a prediction what that would mean for actual
> > > > applications? Will they have no audio output, run into
> > > > a crash, or be able to use recover and appear to work normally
> > > > here?
> > >
> > > No, fortunately it's only about control->avail_min, and fiddling this
> > > value can't break severely (otherwise it'd be a security problem ;)
> > >
> > > In the buggy condition, it's always zero, and the kernel treated as if
> > > 1, i.e. wake up as soon as data is available, which is OK-ish for most
> > > applications. Apps usually don't care about the wake-up condition so
> > > much. There are subtle difference and may influence on the stability
> > > of stream processing, but the stability usually depends more strongly
> > > on the hardware and software configurations.
> > >
> > > That being said, the impact by this bug (from the application behavior
> > > POV) is likely quite small, but the contamination is large; as you
> > > pointed out, it's much larger than I thought.
> >
> > Ok, got it.
> >
> > > The definition in uapi/sound/asound.h is a bit cryptic, but IIUC,
> > > __snd_pcm_mmap_control64 is used for 64bit archs, right? If so, the
> > > problem rather hits more widely on 64bit archs silently. Then, the
> > > influence by this bug must be almost negligible, as we've had no bug
> > > report about the behavior change.
> >
> > While __snd_pcm_mmap_control64 is only used on 32-bit
> > architectures when 64-bit time_t is used. At the moment, this
> > means all users of musl-1.2.x libc, but not glibc.
> >
> > On 64-bit architectures, __snd_pcm_mmap_control and
> > __snd_pcm_mmap_control64 are meant to be identical,
> > and this is actually true regardless of the bug, since
> > __pad_before_uframe and __pad_after_uframe both
> > end up as zero-length arrays here.
> >
> > > We may just fix it in kernel and for new library with hoping that no
> > > one sees the actual problem. Or, we may provide a complete new set of
> > > mmap offsets and ioctl to cover both broken and fixed interfaces...
> > > The decision depends on how perfectly we'd like to address the bug.
> > > As of now, I'm inclined to go for the former, but I'm open for more
> > > opinions.
> >
> > Adding the musl list to Cc for additional testers, anyone interested
> > please see [1] for the original report.
> >
> > It would be good to hear from musl users that are already using
> > audio support with 32-bit applications on 64-bit kernels, which
> > is the case that has the problem today. Have you noticed any
> > problems with audio support here? If not, we can probably
> > "fix" the kernel here and make the existing binaries behave
> > the same way on 32-bit kernels. If there are applications that
> > don't work in that environment today, I think we need to instead
> > change the kernel to accept the currently broken format on
> > both 32-bit and 64-bit kernels, possibly introducing yet another
> > format that works as originally intended but requires a newly
> > built kernel.
>
> Thanks!
>
> And now, looking more deeply, I feel more desperate.
>
> This bug makes the expected padding gone on little-endian.
> On LE 32bit, the buggy definition is:
>
> char __pad1[0];
> u32 appl_ptr;
> char __pad2[0]; // this should have been [4]
> char __pad3[0];
> u32 avail_min;
> char __pad4[4];
>
> When an application issues SYNC_PTR64 ioctl to submit appl_ptr and
> avail_min updates, 64bit kernel (in compat mode) reads directly as:
>
> u64 appl_ptr;
> u64 avail_min;
>
> Hence a bogus appl_ptr would be passed if avail_min != 0.
> And usually application sets non-zero avail_min.
> That is, the bug must hit more severely if the new API were really
> used. It wouldn't crash, but some weird streaming behavior can
> happen like noise, jumping or underruns.
>
> (Reading back avail_min=0 to user-space is rather harmless. Ditto for
> the case of BE, then at least there is no appl_ptr corruption.)
>
> This made me wonder which way to go:
> it's certainly possible to fix the new kernel to treat both buggy and
> sane formats (disabling compat mmap and re-define ioctls, having the
> code for old APIs). The problem is, however, in the case where the
> application needs to run on the older kernel that expects the buggy
> format. Then apps would still have to send in the old buggy format --
> or maybe better in the older 32bit format that won't hit the bug
> above. It makes situation more complicated.
Can't an ioctl number just be redefined so that, on old kernels with
the buggy one, newly built applications get told that mmap is not
available and use the unaffected non-mmap fallback?
> Do we know how widely the __USE_TIME_BITS64 is deployed nowadays?
Anyone using musl on 32-bit archs who's not >=2 years behind current.
Rich
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-07 16:06 ` Rich Felker
0 siblings, 0 replies; 94+ messages in thread
From: Rich Felker @ 2021-10-07 16:06 UTC (permalink / raw)
To: Takashi Iwai
Cc: ALSA Development Mailing List, Arnd Bergmann, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, musl,
Takashi Iwai, Michael Forney, Mark Brown, Baolin Wang
On Thu, Oct 07, 2021 at 05:33:19PM +0200, Takashi Iwai wrote:
> On Thu, 07 Oct 2021 15:11:00 +0200,
> Arnd Bergmann wrote:
> >
> > On Thu, Oct 7, 2021 at 2:43 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > On Thu, 07 Oct 2021 13:48:44 +0200, Arnd Bergmann wrote:
> > > > On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > On Wed, 06 Oct 2021 19:49:17 +0200, Michael Forney wrote:
> > > >
> > > > As far as I can tell, the broken interface will always result in
> > > > user space seeing a zero value for "avail_min". Can you
> > > > make a prediction what that would mean for actual
> > > > applications? Will they have no audio output, run into
> > > > a crash, or be able to use recover and appear to work normally
> > > > here?
> > >
> > > No, fortunately it's only about control->avail_min, and fiddling this
> > > value can't break severely (otherwise it'd be a security problem ;)
> > >
> > > In the buggy condition, it's always zero, and the kernel treated as if
> > > 1, i.e. wake up as soon as data is available, which is OK-ish for most
> > > applications. Apps usually don't care about the wake-up condition so
> > > much. There are subtle difference and may influence on the stability
> > > of stream processing, but the stability usually depends more strongly
> > > on the hardware and software configurations.
> > >
> > > That being said, the impact by this bug (from the application behavior
> > > POV) is likely quite small, but the contamination is large; as you
> > > pointed out, it's much larger than I thought.
> >
> > Ok, got it.
> >
> > > The definition in uapi/sound/asound.h is a bit cryptic, but IIUC,
> > > __snd_pcm_mmap_control64 is used for 64bit archs, right? If so, the
> > > problem rather hits more widely on 64bit archs silently. Then, the
> > > influence by this bug must be almost negligible, as we've had no bug
> > > report about the behavior change.
> >
> > While __snd_pcm_mmap_control64 is only used on 32-bit
> > architectures when 64-bit time_t is used. At the moment, this
> > means all users of musl-1.2.x libc, but not glibc.
> >
> > On 64-bit architectures, __snd_pcm_mmap_control and
> > __snd_pcm_mmap_control64 are meant to be identical,
> > and this is actually true regardless of the bug, since
> > __pad_before_uframe and __pad_after_uframe both
> > end up as zero-length arrays here.
> >
> > > We may just fix it in kernel and for new library with hoping that no
> > > one sees the actual problem. Or, we may provide a complete new set of
> > > mmap offsets and ioctl to cover both broken and fixed interfaces...
> > > The decision depends on how perfectly we'd like to address the bug.
> > > As of now, I'm inclined to go for the former, but I'm open for more
> > > opinions.
> >
> > Adding the musl list to Cc for additional testers, anyone interested
> > please see [1] for the original report.
> >
> > It would be good to hear from musl users that are already using
> > audio support with 32-bit applications on 64-bit kernels, which
> > is the case that has the problem today. Have you noticed any
> > problems with audio support here? If not, we can probably
> > "fix" the kernel here and make the existing binaries behave
> > the same way on 32-bit kernels. If there are applications that
> > don't work in that environment today, I think we need to instead
> > change the kernel to accept the currently broken format on
> > both 32-bit and 64-bit kernels, possibly introducing yet another
> > format that works as originally intended but requires a newly
> > built kernel.
>
> Thanks!
>
> And now, looking more deeply, I feel more desperate.
>
> This bug makes the expected padding gone on little-endian.
> On LE 32bit, the buggy definition is:
>
> char __pad1[0];
> u32 appl_ptr;
> char __pad2[0]; // this should have been [4]
> char __pad3[0];
> u32 avail_min;
> char __pad4[4];
>
> When an application issues SYNC_PTR64 ioctl to submit appl_ptr and
> avail_min updates, 64bit kernel (in compat mode) reads directly as:
>
> u64 appl_ptr;
> u64 avail_min;
>
> Hence a bogus appl_ptr would be passed if avail_min != 0.
> And usually application sets non-zero avail_min.
> That is, the bug must hit more severely if the new API were really
> used. It wouldn't crash, but some weird streaming behavior can
> happen like noise, jumping or underruns.
>
> (Reading back avail_min=0 to user-space is rather harmless. Ditto for
> the case of BE, then at least there is no appl_ptr corruption.)
>
> This made me wonder which way to go:
> it's certainly possible to fix the new kernel to treat both buggy and
> sane formats (disabling compat mmap and re-define ioctls, having the
> code for old APIs). The problem is, however, in the case where the
> application needs to run on the older kernel that expects the buggy
> format. Then apps would still have to send in the old buggy format --
> or maybe better in the older 32bit format that won't hit the bug
> above. It makes situation more complicated.
Can't an ioctl number just be redefined so that, on old kernels with
the buggy one, newly built applications get told that mmap is not
available and use the unaffected non-mmap fallback?
> Do we know how widely the __USE_TIME_BITS64 is deployed nowadays?
Anyone using musl on 32-bit archs who's not >=2 years behind current.
Rich
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-07 16:06 ` Rich Felker
@ 2021-10-07 16:18 ` Takashi Iwai
-1 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2021-10-07 16:18 UTC (permalink / raw)
To: Rich Felker
Cc: Arnd Bergmann, Michael Forney, ALSA Development Mailing List,
Takashi Iwai, Baolin Wang, y2038 Mailman List,
Linux Kernel Mailing List, Mark Brown, Baolin Wang, musl
On Thu, 07 Oct 2021 18:06:36 +0200,
Rich Felker wrote:
>
> On Thu, Oct 07, 2021 at 05:33:19PM +0200, Takashi Iwai wrote:
> > On Thu, 07 Oct 2021 15:11:00 +0200,
> > Arnd Bergmann wrote:
> > >
> > > On Thu, Oct 7, 2021 at 2:43 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > On Thu, 07 Oct 2021 13:48:44 +0200, Arnd Bergmann wrote:
> > > > > On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > On Wed, 06 Oct 2021 19:49:17 +0200, Michael Forney wrote:
> > > > >
> > > > > As far as I can tell, the broken interface will always result in
> > > > > user space seeing a zero value for "avail_min". Can you
> > > > > make a prediction what that would mean for actual
> > > > > applications? Will they have no audio output, run into
> > > > > a crash, or be able to use recover and appear to work normally
> > > > > here?
> > > >
> > > > No, fortunately it's only about control->avail_min, and fiddling this
> > > > value can't break severely (otherwise it'd be a security problem ;)
> > > >
> > > > In the buggy condition, it's always zero, and the kernel treated as if
> > > > 1, i.e. wake up as soon as data is available, which is OK-ish for most
> > > > applications. Apps usually don't care about the wake-up condition so
> > > > much. There are subtle difference and may influence on the stability
> > > > of stream processing, but the stability usually depends more strongly
> > > > on the hardware and software configurations.
> > > >
> > > > That being said, the impact by this bug (from the application behavior
> > > > POV) is likely quite small, but the contamination is large; as you
> > > > pointed out, it's much larger than I thought.
> > >
> > > Ok, got it.
> > >
> > > > The definition in uapi/sound/asound.h is a bit cryptic, but IIUC,
> > > > __snd_pcm_mmap_control64 is used for 64bit archs, right? If so, the
> > > > problem rather hits more widely on 64bit archs silently. Then, the
> > > > influence by this bug must be almost negligible, as we've had no bug
> > > > report about the behavior change.
> > >
> > > While __snd_pcm_mmap_control64 is only used on 32-bit
> > > architectures when 64-bit time_t is used. At the moment, this
> > > means all users of musl-1.2.x libc, but not glibc.
> > >
> > > On 64-bit architectures, __snd_pcm_mmap_control and
> > > __snd_pcm_mmap_control64 are meant to be identical,
> > > and this is actually true regardless of the bug, since
> > > __pad_before_uframe and __pad_after_uframe both
> > > end up as zero-length arrays here.
> > >
> > > > We may just fix it in kernel and for new library with hoping that no
> > > > one sees the actual problem. Or, we may provide a complete new set of
> > > > mmap offsets and ioctl to cover both broken and fixed interfaces...
> > > > The decision depends on how perfectly we'd like to address the bug.
> > > > As of now, I'm inclined to go for the former, but I'm open for more
> > > > opinions.
> > >
> > > Adding the musl list to Cc for additional testers, anyone interested
> > > please see [1] for the original report.
> > >
> > > It would be good to hear from musl users that are already using
> > > audio support with 32-bit applications on 64-bit kernels, which
> > > is the case that has the problem today. Have you noticed any
> > > problems with audio support here? If not, we can probably
> > > "fix" the kernel here and make the existing binaries behave
> > > the same way on 32-bit kernels. If there are applications that
> > > don't work in that environment today, I think we need to instead
> > > change the kernel to accept the currently broken format on
> > > both 32-bit and 64-bit kernels, possibly introducing yet another
> > > format that works as originally intended but requires a newly
> > > built kernel.
> >
> > Thanks!
> >
> > And now, looking more deeply, I feel more desperate.
> >
> > This bug makes the expected padding gone on little-endian.
> > On LE 32bit, the buggy definition is:
> >
> > char __pad1[0];
> > u32 appl_ptr;
> > char __pad2[0]; // this should have been [4]
> > char __pad3[0];
> > u32 avail_min;
> > char __pad4[4];
> >
> > When an application issues SYNC_PTR64 ioctl to submit appl_ptr and
> > avail_min updates, 64bit kernel (in compat mode) reads directly as:
> >
> > u64 appl_ptr;
> > u64 avail_min;
> >
> > Hence a bogus appl_ptr would be passed if avail_min != 0.
> > And usually application sets non-zero avail_min.
> > That is, the bug must hit more severely if the new API were really
> > used. It wouldn't crash, but some weird streaming behavior can
> > happen like noise, jumping or underruns.
> >
> > (Reading back avail_min=0 to user-space is rather harmless. Ditto for
> > the case of BE, then at least there is no appl_ptr corruption.)
> >
> > This made me wonder which way to go:
> > it's certainly possible to fix the new kernel to treat both buggy and
> > sane formats (disabling compat mmap and re-define ioctls, having the
> > code for old APIs). The problem is, however, in the case where the
> > application needs to run on the older kernel that expects the buggy
> > format. Then apps would still have to send in the old buggy format --
> > or maybe better in the older 32bit format that won't hit the bug
> > above. It makes situation more complicated.
>
> Can't an ioctl number just be redefined so that, on old kernels with
> the buggy one, newly built applications get told that mmap is not
> available and use the unaffected non-mmap fallback?
The problem is that the SYNC_PTR64 ioctl itself for non-mmap fallback
is equally buggy due to this bug, too. So disabling mmap doesn't help
alone.
And, yes, we can redefine ioctl numbers. But, then, application would
have to be bilingual, as well as the kernel; it'll have to switch back
to old API when running on older kernel, while the same binary would
need to run in a new API for a newer kernel.
Maybe we can implement it in alsa-lib, if it really worth for it.
> > Do we know how widely the __USE_TIME_BITS64 is deployed nowadays?
>
> Anyone using musl on 32-bit archs who's not >=2 years behind current.
OK.
Takashi
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-07 16:18 ` Takashi Iwai
0 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2021-10-07 16:18 UTC (permalink / raw)
To: Rich Felker
Cc: ALSA Development Mailing List, Arnd Bergmann, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, musl,
Takashi Iwai, Michael Forney, Mark Brown, Baolin Wang
On Thu, 07 Oct 2021 18:06:36 +0200,
Rich Felker wrote:
>
> On Thu, Oct 07, 2021 at 05:33:19PM +0200, Takashi Iwai wrote:
> > On Thu, 07 Oct 2021 15:11:00 +0200,
> > Arnd Bergmann wrote:
> > >
> > > On Thu, Oct 7, 2021 at 2:43 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > On Thu, 07 Oct 2021 13:48:44 +0200, Arnd Bergmann wrote:
> > > > > On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > On Wed, 06 Oct 2021 19:49:17 +0200, Michael Forney wrote:
> > > > >
> > > > > As far as I can tell, the broken interface will always result in
> > > > > user space seeing a zero value for "avail_min". Can you
> > > > > make a prediction what that would mean for actual
> > > > > applications? Will they have no audio output, run into
> > > > > a crash, or be able to use recover and appear to work normally
> > > > > here?
> > > >
> > > > No, fortunately it's only about control->avail_min, and fiddling this
> > > > value can't break severely (otherwise it'd be a security problem ;)
> > > >
> > > > In the buggy condition, it's always zero, and the kernel treated as if
> > > > 1, i.e. wake up as soon as data is available, which is OK-ish for most
> > > > applications. Apps usually don't care about the wake-up condition so
> > > > much. There are subtle difference and may influence on the stability
> > > > of stream processing, but the stability usually depends more strongly
> > > > on the hardware and software configurations.
> > > >
> > > > That being said, the impact by this bug (from the application behavior
> > > > POV) is likely quite small, but the contamination is large; as you
> > > > pointed out, it's much larger than I thought.
> > >
> > > Ok, got it.
> > >
> > > > The definition in uapi/sound/asound.h is a bit cryptic, but IIUC,
> > > > __snd_pcm_mmap_control64 is used for 64bit archs, right? If so, the
> > > > problem rather hits more widely on 64bit archs silently. Then, the
> > > > influence by this bug must be almost negligible, as we've had no bug
> > > > report about the behavior change.
> > >
> > > While __snd_pcm_mmap_control64 is only used on 32-bit
> > > architectures when 64-bit time_t is used. At the moment, this
> > > means all users of musl-1.2.x libc, but not glibc.
> > >
> > > On 64-bit architectures, __snd_pcm_mmap_control and
> > > __snd_pcm_mmap_control64 are meant to be identical,
> > > and this is actually true regardless of the bug, since
> > > __pad_before_uframe and __pad_after_uframe both
> > > end up as zero-length arrays here.
> > >
> > > > We may just fix it in kernel and for new library with hoping that no
> > > > one sees the actual problem. Or, we may provide a complete new set of
> > > > mmap offsets and ioctl to cover both broken and fixed interfaces...
> > > > The decision depends on how perfectly we'd like to address the bug.
> > > > As of now, I'm inclined to go for the former, but I'm open for more
> > > > opinions.
> > >
> > > Adding the musl list to Cc for additional testers, anyone interested
> > > please see [1] for the original report.
> > >
> > > It would be good to hear from musl users that are already using
> > > audio support with 32-bit applications on 64-bit kernels, which
> > > is the case that has the problem today. Have you noticed any
> > > problems with audio support here? If not, we can probably
> > > "fix" the kernel here and make the existing binaries behave
> > > the same way on 32-bit kernels. If there are applications that
> > > don't work in that environment today, I think we need to instead
> > > change the kernel to accept the currently broken format on
> > > both 32-bit and 64-bit kernels, possibly introducing yet another
> > > format that works as originally intended but requires a newly
> > > built kernel.
> >
> > Thanks!
> >
> > And now, looking more deeply, I feel more desperate.
> >
> > This bug makes the expected padding gone on little-endian.
> > On LE 32bit, the buggy definition is:
> >
> > char __pad1[0];
> > u32 appl_ptr;
> > char __pad2[0]; // this should have been [4]
> > char __pad3[0];
> > u32 avail_min;
> > char __pad4[4];
> >
> > When an application issues SYNC_PTR64 ioctl to submit appl_ptr and
> > avail_min updates, 64bit kernel (in compat mode) reads directly as:
> >
> > u64 appl_ptr;
> > u64 avail_min;
> >
> > Hence a bogus appl_ptr would be passed if avail_min != 0.
> > And usually application sets non-zero avail_min.
> > That is, the bug must hit more severely if the new API were really
> > used. It wouldn't crash, but some weird streaming behavior can
> > happen like noise, jumping or underruns.
> >
> > (Reading back avail_min=0 to user-space is rather harmless. Ditto for
> > the case of BE, then at least there is no appl_ptr corruption.)
> >
> > This made me wonder which way to go:
> > it's certainly possible to fix the new kernel to treat both buggy and
> > sane formats (disabling compat mmap and re-define ioctls, having the
> > code for old APIs). The problem is, however, in the case where the
> > application needs to run on the older kernel that expects the buggy
> > format. Then apps would still have to send in the old buggy format --
> > or maybe better in the older 32bit format that won't hit the bug
> > above. It makes situation more complicated.
>
> Can't an ioctl number just be redefined so that, on old kernels with
> the buggy one, newly built applications get told that mmap is not
> available and use the unaffected non-mmap fallback?
The problem is that the SYNC_PTR64 ioctl itself for non-mmap fallback
is equally buggy due to this bug, too. So disabling mmap doesn't help
alone.
And, yes, we can redefine ioctl numbers. But, then, application would
have to be bilingual, as well as the kernel; it'll have to switch back
to old API when running on older kernel, while the same binary would
need to run in a new API for a newer kernel.
Maybe we can implement it in alsa-lib, if it really worth for it.
> > Do we know how widely the __USE_TIME_BITS64 is deployed nowadays?
>
> Anyone using musl on 32-bit archs who's not >=2 years behind current.
OK.
Takashi
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-07 16:18 ` Takashi Iwai
@ 2021-10-07 16:51 ` Rich Felker
-1 siblings, 0 replies; 94+ messages in thread
From: Rich Felker @ 2021-10-07 16:51 UTC (permalink / raw)
To: Takashi Iwai
Cc: Arnd Bergmann, Michael Forney, ALSA Development Mailing List,
Takashi Iwai, Baolin Wang, y2038 Mailman List,
Linux Kernel Mailing List, Mark Brown, Baolin Wang, musl
On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> On Thu, 07 Oct 2021 18:06:36 +0200,
> Rich Felker wrote:
> >
> > On Thu, Oct 07, 2021 at 05:33:19PM +0200, Takashi Iwai wrote:
> > > On Thu, 07 Oct 2021 15:11:00 +0200,
> > > Arnd Bergmann wrote:
> > > >
> > > > On Thu, Oct 7, 2021 at 2:43 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > On Thu, 07 Oct 2021 13:48:44 +0200, Arnd Bergmann wrote:
> > > > > > On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > On Wed, 06 Oct 2021 19:49:17 +0200, Michael Forney wrote:
> > > > > >
> > > > > > As far as I can tell, the broken interface will always result in
> > > > > > user space seeing a zero value for "avail_min". Can you
> > > > > > make a prediction what that would mean for actual
> > > > > > applications? Will they have no audio output, run into
> > > > > > a crash, or be able to use recover and appear to work normally
> > > > > > here?
> > > > >
> > > > > No, fortunately it's only about control->avail_min, and fiddling this
> > > > > value can't break severely (otherwise it'd be a security problem ;)
> > > > >
> > > > > In the buggy condition, it's always zero, and the kernel treated as if
> > > > > 1, i.e. wake up as soon as data is available, which is OK-ish for most
> > > > > applications. Apps usually don't care about the wake-up condition so
> > > > > much. There are subtle difference and may influence on the stability
> > > > > of stream processing, but the stability usually depends more strongly
> > > > > on the hardware and software configurations.
> > > > >
> > > > > That being said, the impact by this bug (from the application behavior
> > > > > POV) is likely quite small, but the contamination is large; as you
> > > > > pointed out, it's much larger than I thought.
> > > >
> > > > Ok, got it.
> > > >
> > > > > The definition in uapi/sound/asound.h is a bit cryptic, but IIUC,
> > > > > __snd_pcm_mmap_control64 is used for 64bit archs, right? If so, the
> > > > > problem rather hits more widely on 64bit archs silently. Then, the
> > > > > influence by this bug must be almost negligible, as we've had no bug
> > > > > report about the behavior change.
> > > >
> > > > While __snd_pcm_mmap_control64 is only used on 32-bit
> > > > architectures when 64-bit time_t is used. At the moment, this
> > > > means all users of musl-1.2.x libc, but not glibc.
> > > >
> > > > On 64-bit architectures, __snd_pcm_mmap_control and
> > > > __snd_pcm_mmap_control64 are meant to be identical,
> > > > and this is actually true regardless of the bug, since
> > > > __pad_before_uframe and __pad_after_uframe both
> > > > end up as zero-length arrays here.
> > > >
> > > > > We may just fix it in kernel and for new library with hoping that no
> > > > > one sees the actual problem. Or, we may provide a complete new set of
> > > > > mmap offsets and ioctl to cover both broken and fixed interfaces...
> > > > > The decision depends on how perfectly we'd like to address the bug.
> > > > > As of now, I'm inclined to go for the former, but I'm open for more
> > > > > opinions.
> > > >
> > > > Adding the musl list to Cc for additional testers, anyone interested
> > > > please see [1] for the original report.
> > > >
> > > > It would be good to hear from musl users that are already using
> > > > audio support with 32-bit applications on 64-bit kernels, which
> > > > is the case that has the problem today. Have you noticed any
> > > > problems with audio support here? If not, we can probably
> > > > "fix" the kernel here and make the existing binaries behave
> > > > the same way on 32-bit kernels. If there are applications that
> > > > don't work in that environment today, I think we need to instead
> > > > change the kernel to accept the currently broken format on
> > > > both 32-bit and 64-bit kernels, possibly introducing yet another
> > > > format that works as originally intended but requires a newly
> > > > built kernel.
> > >
> > > Thanks!
> > >
> > > And now, looking more deeply, I feel more desperate.
> > >
> > > This bug makes the expected padding gone on little-endian.
> > > On LE 32bit, the buggy definition is:
> > >
> > > char __pad1[0];
> > > u32 appl_ptr;
> > > char __pad2[0]; // this should have been [4]
> > > char __pad3[0];
> > > u32 avail_min;
> > > char __pad4[4];
> > >
> > > When an application issues SYNC_PTR64 ioctl to submit appl_ptr and
> > > avail_min updates, 64bit kernel (in compat mode) reads directly as:
> > >
> > > u64 appl_ptr;
> > > u64 avail_min;
> > >
> > > Hence a bogus appl_ptr would be passed if avail_min != 0.
> > > And usually application sets non-zero avail_min.
> > > That is, the bug must hit more severely if the new API were really
> > > used. It wouldn't crash, but some weird streaming behavior can
> > > happen like noise, jumping or underruns.
> > >
> > > (Reading back avail_min=0 to user-space is rather harmless. Ditto for
> > > the case of BE, then at least there is no appl_ptr corruption.)
> > >
> > > This made me wonder which way to go:
> > > it's certainly possible to fix the new kernel to treat both buggy and
> > > sane formats (disabling compat mmap and re-define ioctls, having the
> > > code for old APIs). The problem is, however, in the case where the
> > > application needs to run on the older kernel that expects the buggy
> > > format. Then apps would still have to send in the old buggy format --
> > > or maybe better in the older 32bit format that won't hit the bug
> > > above. It makes situation more complicated.
> >
> > Can't an ioctl number just be redefined so that, on old kernels with
> > the buggy one, newly built applications get told that mmap is not
> > available and use the unaffected non-mmap fallback?
>
> The problem is that the SYNC_PTR64 ioctl itself for non-mmap fallback
> is equally buggy due to this bug, too. So disabling mmap doesn't help
> alone.
>
> And, yes, we can redefine ioctl numbers. But, then, application would
> have to be bilingual, as well as the kernel; it'll have to switch back
> to old API when running on older kernel, while the same binary would
> need to run in a new API for a newer kernel.
>
> Maybe we can implement it in alsa-lib, if it really worth for it.
In musl we already have ioctl struct conversion for running on
time32-only kernels. So it may be practical to convert this too if
needed.
Rich
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-07 16:51 ` Rich Felker
0 siblings, 0 replies; 94+ messages in thread
From: Rich Felker @ 2021-10-07 16:51 UTC (permalink / raw)
To: Takashi Iwai
Cc: ALSA Development Mailing List, Arnd Bergmann, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, musl,
Takashi Iwai, Michael Forney, Mark Brown, Baolin Wang
On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> On Thu, 07 Oct 2021 18:06:36 +0200,
> Rich Felker wrote:
> >
> > On Thu, Oct 07, 2021 at 05:33:19PM +0200, Takashi Iwai wrote:
> > > On Thu, 07 Oct 2021 15:11:00 +0200,
> > > Arnd Bergmann wrote:
> > > >
> > > > On Thu, Oct 7, 2021 at 2:43 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > On Thu, 07 Oct 2021 13:48:44 +0200, Arnd Bergmann wrote:
> > > > > > On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > On Wed, 06 Oct 2021 19:49:17 +0200, Michael Forney wrote:
> > > > > >
> > > > > > As far as I can tell, the broken interface will always result in
> > > > > > user space seeing a zero value for "avail_min". Can you
> > > > > > make a prediction what that would mean for actual
> > > > > > applications? Will they have no audio output, run into
> > > > > > a crash, or be able to use recover and appear to work normally
> > > > > > here?
> > > > >
> > > > > No, fortunately it's only about control->avail_min, and fiddling this
> > > > > value can't break severely (otherwise it'd be a security problem ;)
> > > > >
> > > > > In the buggy condition, it's always zero, and the kernel treated as if
> > > > > 1, i.e. wake up as soon as data is available, which is OK-ish for most
> > > > > applications. Apps usually don't care about the wake-up condition so
> > > > > much. There are subtle difference and may influence on the stability
> > > > > of stream processing, but the stability usually depends more strongly
> > > > > on the hardware and software configurations.
> > > > >
> > > > > That being said, the impact by this bug (from the application behavior
> > > > > POV) is likely quite small, but the contamination is large; as you
> > > > > pointed out, it's much larger than I thought.
> > > >
> > > > Ok, got it.
> > > >
> > > > > The definition in uapi/sound/asound.h is a bit cryptic, but IIUC,
> > > > > __snd_pcm_mmap_control64 is used for 64bit archs, right? If so, the
> > > > > problem rather hits more widely on 64bit archs silently. Then, the
> > > > > influence by this bug must be almost negligible, as we've had no bug
> > > > > report about the behavior change.
> > > >
> > > > While __snd_pcm_mmap_control64 is only used on 32-bit
> > > > architectures when 64-bit time_t is used. At the moment, this
> > > > means all users of musl-1.2.x libc, but not glibc.
> > > >
> > > > On 64-bit architectures, __snd_pcm_mmap_control and
> > > > __snd_pcm_mmap_control64 are meant to be identical,
> > > > and this is actually true regardless of the bug, since
> > > > __pad_before_uframe and __pad_after_uframe both
> > > > end up as zero-length arrays here.
> > > >
> > > > > We may just fix it in kernel and for new library with hoping that no
> > > > > one sees the actual problem. Or, we may provide a complete new set of
> > > > > mmap offsets and ioctl to cover both broken and fixed interfaces...
> > > > > The decision depends on how perfectly we'd like to address the bug.
> > > > > As of now, I'm inclined to go for the former, but I'm open for more
> > > > > opinions.
> > > >
> > > > Adding the musl list to Cc for additional testers, anyone interested
> > > > please see [1] for the original report.
> > > >
> > > > It would be good to hear from musl users that are already using
> > > > audio support with 32-bit applications on 64-bit kernels, which
> > > > is the case that has the problem today. Have you noticed any
> > > > problems with audio support here? If not, we can probably
> > > > "fix" the kernel here and make the existing binaries behave
> > > > the same way on 32-bit kernels. If there are applications that
> > > > don't work in that environment today, I think we need to instead
> > > > change the kernel to accept the currently broken format on
> > > > both 32-bit and 64-bit kernels, possibly introducing yet another
> > > > format that works as originally intended but requires a newly
> > > > built kernel.
> > >
> > > Thanks!
> > >
> > > And now, looking more deeply, I feel more desperate.
> > >
> > > This bug makes the expected padding gone on little-endian.
> > > On LE 32bit, the buggy definition is:
> > >
> > > char __pad1[0];
> > > u32 appl_ptr;
> > > char __pad2[0]; // this should have been [4]
> > > char __pad3[0];
> > > u32 avail_min;
> > > char __pad4[4];
> > >
> > > When an application issues SYNC_PTR64 ioctl to submit appl_ptr and
> > > avail_min updates, 64bit kernel (in compat mode) reads directly as:
> > >
> > > u64 appl_ptr;
> > > u64 avail_min;
> > >
> > > Hence a bogus appl_ptr would be passed if avail_min != 0.
> > > And usually application sets non-zero avail_min.
> > > That is, the bug must hit more severely if the new API were really
> > > used. It wouldn't crash, but some weird streaming behavior can
> > > happen like noise, jumping or underruns.
> > >
> > > (Reading back avail_min=0 to user-space is rather harmless. Ditto for
> > > the case of BE, then at least there is no appl_ptr corruption.)
> > >
> > > This made me wonder which way to go:
> > > it's certainly possible to fix the new kernel to treat both buggy and
> > > sane formats (disabling compat mmap and re-define ioctls, having the
> > > code for old APIs). The problem is, however, in the case where the
> > > application needs to run on the older kernel that expects the buggy
> > > format. Then apps would still have to send in the old buggy format --
> > > or maybe better in the older 32bit format that won't hit the bug
> > > above. It makes situation more complicated.
> >
> > Can't an ioctl number just be redefined so that, on old kernels with
> > the buggy one, newly built applications get told that mmap is not
> > available and use the unaffected non-mmap fallback?
>
> The problem is that the SYNC_PTR64 ioctl itself for non-mmap fallback
> is equally buggy due to this bug, too. So disabling mmap doesn't help
> alone.
>
> And, yes, we can redefine ioctl numbers. But, then, application would
> have to be bilingual, as well as the kernel; it'll have to switch back
> to old API when running on older kernel, while the same binary would
> need to run in a new API for a newer kernel.
>
> Maybe we can implement it in alsa-lib, if it really worth for it.
In musl we already have ioctl struct conversion for running on
time32-only kernels. So it may be practical to convert this too if
needed.
Rich
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-07 16:51 ` Rich Felker
@ 2021-10-08 8:43 ` Takashi Iwai
-1 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2021-10-08 8:43 UTC (permalink / raw)
To: Rich Felker
Cc: Arnd Bergmann, Michael Forney, ALSA Development Mailing List,
Takashi Iwai, Baolin Wang, y2038 Mailman List,
Linux Kernel Mailing List, Mark Brown, Baolin Wang, musl
On Thu, 07 Oct 2021 18:51:58 +0200,
Rich Felker wrote:
>
> On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> > On Thu, 07 Oct 2021 18:06:36 +0200,
> > Rich Felker wrote:
> > >
> > > On Thu, Oct 07, 2021 at 05:33:19PM +0200, Takashi Iwai wrote:
> > > > On Thu, 07 Oct 2021 15:11:00 +0200,
> > > > Arnd Bergmann wrote:
> > > > >
> > > > > On Thu, Oct 7, 2021 at 2:43 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > On Thu, 07 Oct 2021 13:48:44 +0200, Arnd Bergmann wrote:
> > > > > > > On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > > On Wed, 06 Oct 2021 19:49:17 +0200, Michael Forney wrote:
> > > > > > >
> > > > > > > As far as I can tell, the broken interface will always result in
> > > > > > > user space seeing a zero value for "avail_min". Can you
> > > > > > > make a prediction what that would mean for actual
> > > > > > > applications? Will they have no audio output, run into
> > > > > > > a crash, or be able to use recover and appear to work normally
> > > > > > > here?
> > > > > >
> > > > > > No, fortunately it's only about control->avail_min, and fiddling this
> > > > > > value can't break severely (otherwise it'd be a security problem ;)
> > > > > >
> > > > > > In the buggy condition, it's always zero, and the kernel treated as if
> > > > > > 1, i.e. wake up as soon as data is available, which is OK-ish for most
> > > > > > applications. Apps usually don't care about the wake-up condition so
> > > > > > much. There are subtle difference and may influence on the stability
> > > > > > of stream processing, but the stability usually depends more strongly
> > > > > > on the hardware and software configurations.
> > > > > >
> > > > > > That being said, the impact by this bug (from the application behavior
> > > > > > POV) is likely quite small, but the contamination is large; as you
> > > > > > pointed out, it's much larger than I thought.
> > > > >
> > > > > Ok, got it.
> > > > >
> > > > > > The definition in uapi/sound/asound.h is a bit cryptic, but IIUC,
> > > > > > __snd_pcm_mmap_control64 is used for 64bit archs, right? If so, the
> > > > > > problem rather hits more widely on 64bit archs silently. Then, the
> > > > > > influence by this bug must be almost negligible, as we've had no bug
> > > > > > report about the behavior change.
> > > > >
> > > > > While __snd_pcm_mmap_control64 is only used on 32-bit
> > > > > architectures when 64-bit time_t is used. At the moment, this
> > > > > means all users of musl-1.2.x libc, but not glibc.
> > > > >
> > > > > On 64-bit architectures, __snd_pcm_mmap_control and
> > > > > __snd_pcm_mmap_control64 are meant to be identical,
> > > > > and this is actually true regardless of the bug, since
> > > > > __pad_before_uframe and __pad_after_uframe both
> > > > > end up as zero-length arrays here.
> > > > >
> > > > > > We may just fix it in kernel and for new library with hoping that no
> > > > > > one sees the actual problem. Or, we may provide a complete new set of
> > > > > > mmap offsets and ioctl to cover both broken and fixed interfaces...
> > > > > > The decision depends on how perfectly we'd like to address the bug.
> > > > > > As of now, I'm inclined to go for the former, but I'm open for more
> > > > > > opinions.
> > > > >
> > > > > Adding the musl list to Cc for additional testers, anyone interested
> > > > > please see [1] for the original report.
> > > > >
> > > > > It would be good to hear from musl users that are already using
> > > > > audio support with 32-bit applications on 64-bit kernels, which
> > > > > is the case that has the problem today. Have you noticed any
> > > > > problems with audio support here? If not, we can probably
> > > > > "fix" the kernel here and make the existing binaries behave
> > > > > the same way on 32-bit kernels. If there are applications that
> > > > > don't work in that environment today, I think we need to instead
> > > > > change the kernel to accept the currently broken format on
> > > > > both 32-bit and 64-bit kernels, possibly introducing yet another
> > > > > format that works as originally intended but requires a newly
> > > > > built kernel.
> > > >
> > > > Thanks!
> > > >
> > > > And now, looking more deeply, I feel more desperate.
> > > >
> > > > This bug makes the expected padding gone on little-endian.
> > > > On LE 32bit, the buggy definition is:
> > > >
> > > > char __pad1[0];
> > > > u32 appl_ptr;
> > > > char __pad2[0]; // this should have been [4]
> > > > char __pad3[0];
> > > > u32 avail_min;
> > > > char __pad4[4];
> > > >
> > > > When an application issues SYNC_PTR64 ioctl to submit appl_ptr and
> > > > avail_min updates, 64bit kernel (in compat mode) reads directly as:
> > > >
> > > > u64 appl_ptr;
> > > > u64 avail_min;
> > > >
> > > > Hence a bogus appl_ptr would be passed if avail_min != 0.
> > > > And usually application sets non-zero avail_min.
> > > > That is, the bug must hit more severely if the new API were really
> > > > used. It wouldn't crash, but some weird streaming behavior can
> > > > happen like noise, jumping or underruns.
> > > >
> > > > (Reading back avail_min=0 to user-space is rather harmless. Ditto for
> > > > the case of BE, then at least there is no appl_ptr corruption.)
> > > >
> > > > This made me wonder which way to go:
> > > > it's certainly possible to fix the new kernel to treat both buggy and
> > > > sane formats (disabling compat mmap and re-define ioctls, having the
> > > > code for old APIs). The problem is, however, in the case where the
> > > > application needs to run on the older kernel that expects the buggy
> > > > format. Then apps would still have to send in the old buggy format --
> > > > or maybe better in the older 32bit format that won't hit the bug
> > > > above. It makes situation more complicated.
> > >
> > > Can't an ioctl number just be redefined so that, on old kernels with
> > > the buggy one, newly built applications get told that mmap is not
> > > available and use the unaffected non-mmap fallback?
> >
> > The problem is that the SYNC_PTR64 ioctl itself for non-mmap fallback
> > is equally buggy due to this bug, too. So disabling mmap doesn't help
> > alone.
> >
> > And, yes, we can redefine ioctl numbers. But, then, application would
> > have to be bilingual, as well as the kernel; it'll have to switch back
> > to old API when running on older kernel, while the same binary would
> > need to run in a new API for a newer kernel.
> >
> > Maybe we can implement it in alsa-lib, if it really worth for it.
>
> In musl we already have ioctl struct conversion for running on
> time32-only kernels. So it may be practical to convert this too if
> needed.
I guess we can work around without ioctl renumbering. The PCM API has
a protocol version handshaking, and user-space is supposed to tell its
API version to kernel. So the kernel can know in what version
user-space is talking with.
Below is the PoC fix in the kernel side (totally untested).
The fix for alsa-lib will follow.
thanks,
Takashi
---
diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
index 5859ca0a1439..dbdbf0c794d8 100644
--- a/include/uapi/sound/asound.h
+++ b/include/uapi/sound/asound.h
@@ -156,7 +156,7 @@ struct snd_hwdep_dsp_image {
* *
*****************************************************************************/
-#define SNDRV_PCM_VERSION SNDRV_PROTOCOL_VERSION(2, 0, 15)
+#define SNDRV_PCM_VERSION SNDRV_PROTOCOL_VERSION(2, 0, 16)
typedef unsigned long snd_pcm_uframes_t;
typedef signed long snd_pcm_sframes_t;
@@ -550,6 +550,7 @@ struct __snd_pcm_sync_ptr {
} s;
union {
struct __snd_pcm_mmap_control control;
+ struct __snd_pcm_mmap_control control_api_2_0_15; /* no bug in 32bit mode */
unsigned char reserved[64];
} c;
};
@@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
typedef char __pad_after_uframe[0];
+typedef char __pad_before_u32[4];
+typedef char __pad_after_u32[0];
#endif
#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
typedef char __pad_before_uframe[0];
typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
+typedef char __pad_before_u32[0];
+typedef char __pad_after_u32[4];
#endif
struct __snd_pcm_mmap_status64 {
@@ -579,13 +584,23 @@ struct __snd_pcm_mmap_status64 {
struct __snd_pcm_mmap_control64 {
__pad_before_uframe __pad1;
snd_pcm_uframes_t appl_ptr; /* RW: appl ptr (0...boundary-1) */
- __pad_before_uframe __pad2;
+ __pad_after_uframe __pad2;
__pad_before_uframe __pad3;
snd_pcm_uframes_t avail_min; /* RW: min available frames for wakeup */
__pad_after_uframe __pad4;
};
+/* buggy mmap control definition for 2.0.15 PCM API on 32bit mode */
+struct __snd_pcm_mmap_control64_api_2_0_15 {
+ __pad_before_u32 __pad1;
+ __u32 appl_ptr;
+ __pad_before_u32 __pad2; /* SiC! here is the bug */
+ __pad_before_u32 __pad3;
+ __u32 avail_min;
+ __pad_after_uframe __pad4;
+};
+
struct __snd_pcm_sync_ptr64 {
__u32 flags;
__u32 pad1;
@@ -595,6 +610,7 @@ struct __snd_pcm_sync_ptr64 {
} s;
union {
struct __snd_pcm_mmap_control64 control;
+ struct __snd_pcm_mmap_control64_api_2_0_15 control_api_2_0_15;
unsigned char reserved[64];
} c;
};
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index 46c643db18eb..1f26dd2a2525 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -2958,8 +2958,19 @@ static int snd_pcm_delay(struct snd_pcm_substream *substream,
return err;
}
+/* PCM 2.0.15 API definition had a bug in mmap control; it puts the avail_min
+ * at the wrong offset due to a typo in padding type.
+ * The bug hits only on 32bit, either on 32bit arch or in 32bit compat mode.
+ */
+static bool is_buggy_control(struct snd_pcm_file *pcm_file)
+{
+ return pcm_file->user_pversion == SNDRV_PROTOCOL_VERSION(2, 0, 15) &&
+ (in_compat_syscall() || !IS_ENABLED(CONFIG_64BIT));
+}
+
static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
- struct snd_pcm_sync_ptr __user *_sync_ptr)
+ struct snd_pcm_sync_ptr __user *_sync_ptr,
+ bool buggy_control)
{
struct snd_pcm_runtime *runtime = substream->runtime;
struct snd_pcm_sync_ptr sync_ptr;
@@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
memset(&sync_ptr, 0, sizeof(sync_ptr));
if (get_user(sync_ptr.flags, (unsigned __user *)&(_sync_ptr->flags)))
return -EFAULT;
- if (copy_from_user(&sync_ptr.c.control, &(_sync_ptr->c.control), sizeof(struct snd_pcm_mmap_control)))
- return -EFAULT;
+ if (buggy_control) {
+ if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
+ &(_sync_ptr->c.control_api_2_0_15),
+ sizeof(sync_ptr.c.control_api_2_0_15)))
+ return -EFAULT;
+ } else {
+ if (copy_from_user(&sync_ptr.c.control,
+ &(_sync_ptr->c.control),
+ sizeof(sync_ptr.c.control)))
+ return -EFAULT;
+ }
status = runtime->status;
control = runtime->control;
if (sync_ptr.flags & SNDRV_PCM_SYNC_PTR_HWSYNC) {
@@ -2981,19 +3001,34 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
}
snd_pcm_stream_lock_irq(substream);
if (!(sync_ptr.flags & SNDRV_PCM_SYNC_PTR_APPL)) {
- err = pcm_lib_apply_appl_ptr(substream,
- sync_ptr.c.control.appl_ptr);
+ if (buggy_control) {
+ err = pcm_lib_apply_appl_ptr(substream,
+ sync_ptr.c.control_api_2_0_15.appl_ptr);
+ } else {
+ err = pcm_lib_apply_appl_ptr(substream,
+ sync_ptr.c.control.appl_ptr);
+ }
if (err < 0) {
snd_pcm_stream_unlock_irq(substream);
return err;
}
} else {
- sync_ptr.c.control.appl_ptr = control->appl_ptr;
+ if (buggy_control)
+ sync_ptr.c.control_api_2_0_15.appl_ptr = control->appl_ptr;
+ else
+ sync_ptr.c.control.appl_ptr = control->appl_ptr;
+ }
+ if (!(sync_ptr.flags & SNDRV_PCM_SYNC_PTR_AVAIL_MIN)) {
+ if (buggy_control)
+ control->avail_min = sync_ptr.c.control_api_2_0_15.avail_min;
+ else
+ control->avail_min = sync_ptr.c.control.avail_min;
+ } else {
+ if (buggy_control)
+ sync_ptr.c.control_api_2_0_15.avail_min = control->avail_min;
+ else
+ sync_ptr.c.control.avail_min = control->avail_min;
}
- if (!(sync_ptr.flags & SNDRV_PCM_SYNC_PTR_AVAIL_MIN))
- control->avail_min = sync_ptr.c.control.avail_min;
- else
- sync_ptr.c.control.avail_min = control->avail_min;
sync_ptr.s.status.state = status->state;
sync_ptr.s.status.hw_ptr = status->hw_ptr;
sync_ptr.s.status.tstamp = status->tstamp;
@@ -3289,7 +3324,8 @@ static int snd_pcm_common_ioctl(struct file *file,
case __SNDRV_PCM_IOCTL_SYNC_PTR32:
return snd_pcm_ioctl_sync_ptr_compat(substream, arg);
case __SNDRV_PCM_IOCTL_SYNC_PTR64:
- return snd_pcm_sync_ptr(substream, arg);
+ return snd_pcm_sync_ptr(substream, arg,
+ is_buggy_control(pcm_file));
#ifdef CONFIG_SND_SUPPORT_OLD_API
case SNDRV_PCM_IOCTL_HW_REFINE_OLD:
return snd_pcm_hw_refine_old_user(substream, arg);
@@ -3851,6 +3887,8 @@ static int snd_pcm_mmap(struct file *file, struct vm_area_struct *area)
return -ENXIO;
fallthrough;
case SNDRV_PCM_MMAP_OFFSET_CONTROL_NEW:
+ if (is_buggy_control(pcm_file))
+ return -ENXIO;
if (!pcm_control_mmap_allowed(pcm_file))
return -ENXIO;
return snd_pcm_mmap_control(substream, file, area);
^ permalink raw reply related [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-08 8:43 ` Takashi Iwai
0 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2021-10-08 8:43 UTC (permalink / raw)
To: Rich Felker
Cc: ALSA Development Mailing List, Arnd Bergmann, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, musl,
Takashi Iwai, Michael Forney, Mark Brown, Baolin Wang
On Thu, 07 Oct 2021 18:51:58 +0200,
Rich Felker wrote:
>
> On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> > On Thu, 07 Oct 2021 18:06:36 +0200,
> > Rich Felker wrote:
> > >
> > > On Thu, Oct 07, 2021 at 05:33:19PM +0200, Takashi Iwai wrote:
> > > > On Thu, 07 Oct 2021 15:11:00 +0200,
> > > > Arnd Bergmann wrote:
> > > > >
> > > > > On Thu, Oct 7, 2021 at 2:43 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > On Thu, 07 Oct 2021 13:48:44 +0200, Arnd Bergmann wrote:
> > > > > > > On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > > On Wed, 06 Oct 2021 19:49:17 +0200, Michael Forney wrote:
> > > > > > >
> > > > > > > As far as I can tell, the broken interface will always result in
> > > > > > > user space seeing a zero value for "avail_min". Can you
> > > > > > > make a prediction what that would mean for actual
> > > > > > > applications? Will they have no audio output, run into
> > > > > > > a crash, or be able to use recover and appear to work normally
> > > > > > > here?
> > > > > >
> > > > > > No, fortunately it's only about control->avail_min, and fiddling this
> > > > > > value can't break severely (otherwise it'd be a security problem ;)
> > > > > >
> > > > > > In the buggy condition, it's always zero, and the kernel treated as if
> > > > > > 1, i.e. wake up as soon as data is available, which is OK-ish for most
> > > > > > applications. Apps usually don't care about the wake-up condition so
> > > > > > much. There are subtle difference and may influence on the stability
> > > > > > of stream processing, but the stability usually depends more strongly
> > > > > > on the hardware and software configurations.
> > > > > >
> > > > > > That being said, the impact by this bug (from the application behavior
> > > > > > POV) is likely quite small, but the contamination is large; as you
> > > > > > pointed out, it's much larger than I thought.
> > > > >
> > > > > Ok, got it.
> > > > >
> > > > > > The definition in uapi/sound/asound.h is a bit cryptic, but IIUC,
> > > > > > __snd_pcm_mmap_control64 is used for 64bit archs, right? If so, the
> > > > > > problem rather hits more widely on 64bit archs silently. Then, the
> > > > > > influence by this bug must be almost negligible, as we've had no bug
> > > > > > report about the behavior change.
> > > > >
> > > > > While __snd_pcm_mmap_control64 is only used on 32-bit
> > > > > architectures when 64-bit time_t is used. At the moment, this
> > > > > means all users of musl-1.2.x libc, but not glibc.
> > > > >
> > > > > On 64-bit architectures, __snd_pcm_mmap_control and
> > > > > __snd_pcm_mmap_control64 are meant to be identical,
> > > > > and this is actually true regardless of the bug, since
> > > > > __pad_before_uframe and __pad_after_uframe both
> > > > > end up as zero-length arrays here.
> > > > >
> > > > > > We may just fix it in kernel and for new library with hoping that no
> > > > > > one sees the actual problem. Or, we may provide a complete new set of
> > > > > > mmap offsets and ioctl to cover both broken and fixed interfaces...
> > > > > > The decision depends on how perfectly we'd like to address the bug.
> > > > > > As of now, I'm inclined to go for the former, but I'm open for more
> > > > > > opinions.
> > > > >
> > > > > Adding the musl list to Cc for additional testers, anyone interested
> > > > > please see [1] for the original report.
> > > > >
> > > > > It would be good to hear from musl users that are already using
> > > > > audio support with 32-bit applications on 64-bit kernels, which
> > > > > is the case that has the problem today. Have you noticed any
> > > > > problems with audio support here? If not, we can probably
> > > > > "fix" the kernel here and make the existing binaries behave
> > > > > the same way on 32-bit kernels. If there are applications that
> > > > > don't work in that environment today, I think we need to instead
> > > > > change the kernel to accept the currently broken format on
> > > > > both 32-bit and 64-bit kernels, possibly introducing yet another
> > > > > format that works as originally intended but requires a newly
> > > > > built kernel.
> > > >
> > > > Thanks!
> > > >
> > > > And now, looking more deeply, I feel more desperate.
> > > >
> > > > This bug makes the expected padding gone on little-endian.
> > > > On LE 32bit, the buggy definition is:
> > > >
> > > > char __pad1[0];
> > > > u32 appl_ptr;
> > > > char __pad2[0]; // this should have been [4]
> > > > char __pad3[0];
> > > > u32 avail_min;
> > > > char __pad4[4];
> > > >
> > > > When an application issues SYNC_PTR64 ioctl to submit appl_ptr and
> > > > avail_min updates, 64bit kernel (in compat mode) reads directly as:
> > > >
> > > > u64 appl_ptr;
> > > > u64 avail_min;
> > > >
> > > > Hence a bogus appl_ptr would be passed if avail_min != 0.
> > > > And usually application sets non-zero avail_min.
> > > > That is, the bug must hit more severely if the new API were really
> > > > used. It wouldn't crash, but some weird streaming behavior can
> > > > happen like noise, jumping or underruns.
> > > >
> > > > (Reading back avail_min=0 to user-space is rather harmless. Ditto for
> > > > the case of BE, then at least there is no appl_ptr corruption.)
> > > >
> > > > This made me wonder which way to go:
> > > > it's certainly possible to fix the new kernel to treat both buggy and
> > > > sane formats (disabling compat mmap and re-define ioctls, having the
> > > > code for old APIs). The problem is, however, in the case where the
> > > > application needs to run on the older kernel that expects the buggy
> > > > format. Then apps would still have to send in the old buggy format --
> > > > or maybe better in the older 32bit format that won't hit the bug
> > > > above. It makes situation more complicated.
> > >
> > > Can't an ioctl number just be redefined so that, on old kernels with
> > > the buggy one, newly built applications get told that mmap is not
> > > available and use the unaffected non-mmap fallback?
> >
> > The problem is that the SYNC_PTR64 ioctl itself for non-mmap fallback
> > is equally buggy due to this bug, too. So disabling mmap doesn't help
> > alone.
> >
> > And, yes, we can redefine ioctl numbers. But, then, application would
> > have to be bilingual, as well as the kernel; it'll have to switch back
> > to old API when running on older kernel, while the same binary would
> > need to run in a new API for a newer kernel.
> >
> > Maybe we can implement it in alsa-lib, if it really worth for it.
>
> In musl we already have ioctl struct conversion for running on
> time32-only kernels. So it may be practical to convert this too if
> needed.
I guess we can work around without ioctl renumbering. The PCM API has
a protocol version handshaking, and user-space is supposed to tell its
API version to kernel. So the kernel can know in what version
user-space is talking with.
Below is the PoC fix in the kernel side (totally untested).
The fix for alsa-lib will follow.
thanks,
Takashi
---
diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
index 5859ca0a1439..dbdbf0c794d8 100644
--- a/include/uapi/sound/asound.h
+++ b/include/uapi/sound/asound.h
@@ -156,7 +156,7 @@ struct snd_hwdep_dsp_image {
* *
*****************************************************************************/
-#define SNDRV_PCM_VERSION SNDRV_PROTOCOL_VERSION(2, 0, 15)
+#define SNDRV_PCM_VERSION SNDRV_PROTOCOL_VERSION(2, 0, 16)
typedef unsigned long snd_pcm_uframes_t;
typedef signed long snd_pcm_sframes_t;
@@ -550,6 +550,7 @@ struct __snd_pcm_sync_ptr {
} s;
union {
struct __snd_pcm_mmap_control control;
+ struct __snd_pcm_mmap_control control_api_2_0_15; /* no bug in 32bit mode */
unsigned char reserved[64];
} c;
};
@@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
typedef char __pad_after_uframe[0];
+typedef char __pad_before_u32[4];
+typedef char __pad_after_u32[0];
#endif
#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
typedef char __pad_before_uframe[0];
typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
+typedef char __pad_before_u32[0];
+typedef char __pad_after_u32[4];
#endif
struct __snd_pcm_mmap_status64 {
@@ -579,13 +584,23 @@ struct __snd_pcm_mmap_status64 {
struct __snd_pcm_mmap_control64 {
__pad_before_uframe __pad1;
snd_pcm_uframes_t appl_ptr; /* RW: appl ptr (0...boundary-1) */
- __pad_before_uframe __pad2;
+ __pad_after_uframe __pad2;
__pad_before_uframe __pad3;
snd_pcm_uframes_t avail_min; /* RW: min available frames for wakeup */
__pad_after_uframe __pad4;
};
+/* buggy mmap control definition for 2.0.15 PCM API on 32bit mode */
+struct __snd_pcm_mmap_control64_api_2_0_15 {
+ __pad_before_u32 __pad1;
+ __u32 appl_ptr;
+ __pad_before_u32 __pad2; /* SiC! here is the bug */
+ __pad_before_u32 __pad3;
+ __u32 avail_min;
+ __pad_after_uframe __pad4;
+};
+
struct __snd_pcm_sync_ptr64 {
__u32 flags;
__u32 pad1;
@@ -595,6 +610,7 @@ struct __snd_pcm_sync_ptr64 {
} s;
union {
struct __snd_pcm_mmap_control64 control;
+ struct __snd_pcm_mmap_control64_api_2_0_15 control_api_2_0_15;
unsigned char reserved[64];
} c;
};
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index 46c643db18eb..1f26dd2a2525 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -2958,8 +2958,19 @@ static int snd_pcm_delay(struct snd_pcm_substream *substream,
return err;
}
+/* PCM 2.0.15 API definition had a bug in mmap control; it puts the avail_min
+ * at the wrong offset due to a typo in padding type.
+ * The bug hits only on 32bit, either on 32bit arch or in 32bit compat mode.
+ */
+static bool is_buggy_control(struct snd_pcm_file *pcm_file)
+{
+ return pcm_file->user_pversion == SNDRV_PROTOCOL_VERSION(2, 0, 15) &&
+ (in_compat_syscall() || !IS_ENABLED(CONFIG_64BIT));
+}
+
static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
- struct snd_pcm_sync_ptr __user *_sync_ptr)
+ struct snd_pcm_sync_ptr __user *_sync_ptr,
+ bool buggy_control)
{
struct snd_pcm_runtime *runtime = substream->runtime;
struct snd_pcm_sync_ptr sync_ptr;
@@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
memset(&sync_ptr, 0, sizeof(sync_ptr));
if (get_user(sync_ptr.flags, (unsigned __user *)&(_sync_ptr->flags)))
return -EFAULT;
- if (copy_from_user(&sync_ptr.c.control, &(_sync_ptr->c.control), sizeof(struct snd_pcm_mmap_control)))
- return -EFAULT;
+ if (buggy_control) {
+ if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
+ &(_sync_ptr->c.control_api_2_0_15),
+ sizeof(sync_ptr.c.control_api_2_0_15)))
+ return -EFAULT;
+ } else {
+ if (copy_from_user(&sync_ptr.c.control,
+ &(_sync_ptr->c.control),
+ sizeof(sync_ptr.c.control)))
+ return -EFAULT;
+ }
status = runtime->status;
control = runtime->control;
if (sync_ptr.flags & SNDRV_PCM_SYNC_PTR_HWSYNC) {
@@ -2981,19 +3001,34 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
}
snd_pcm_stream_lock_irq(substream);
if (!(sync_ptr.flags & SNDRV_PCM_SYNC_PTR_APPL)) {
- err = pcm_lib_apply_appl_ptr(substream,
- sync_ptr.c.control.appl_ptr);
+ if (buggy_control) {
+ err = pcm_lib_apply_appl_ptr(substream,
+ sync_ptr.c.control_api_2_0_15.appl_ptr);
+ } else {
+ err = pcm_lib_apply_appl_ptr(substream,
+ sync_ptr.c.control.appl_ptr);
+ }
if (err < 0) {
snd_pcm_stream_unlock_irq(substream);
return err;
}
} else {
- sync_ptr.c.control.appl_ptr = control->appl_ptr;
+ if (buggy_control)
+ sync_ptr.c.control_api_2_0_15.appl_ptr = control->appl_ptr;
+ else
+ sync_ptr.c.control.appl_ptr = control->appl_ptr;
+ }
+ if (!(sync_ptr.flags & SNDRV_PCM_SYNC_PTR_AVAIL_MIN)) {
+ if (buggy_control)
+ control->avail_min = sync_ptr.c.control_api_2_0_15.avail_min;
+ else
+ control->avail_min = sync_ptr.c.control.avail_min;
+ } else {
+ if (buggy_control)
+ sync_ptr.c.control_api_2_0_15.avail_min = control->avail_min;
+ else
+ sync_ptr.c.control.avail_min = control->avail_min;
}
- if (!(sync_ptr.flags & SNDRV_PCM_SYNC_PTR_AVAIL_MIN))
- control->avail_min = sync_ptr.c.control.avail_min;
- else
- sync_ptr.c.control.avail_min = control->avail_min;
sync_ptr.s.status.state = status->state;
sync_ptr.s.status.hw_ptr = status->hw_ptr;
sync_ptr.s.status.tstamp = status->tstamp;
@@ -3289,7 +3324,8 @@ static int snd_pcm_common_ioctl(struct file *file,
case __SNDRV_PCM_IOCTL_SYNC_PTR32:
return snd_pcm_ioctl_sync_ptr_compat(substream, arg);
case __SNDRV_PCM_IOCTL_SYNC_PTR64:
- return snd_pcm_sync_ptr(substream, arg);
+ return snd_pcm_sync_ptr(substream, arg,
+ is_buggy_control(pcm_file));
#ifdef CONFIG_SND_SUPPORT_OLD_API
case SNDRV_PCM_IOCTL_HW_REFINE_OLD:
return snd_pcm_hw_refine_old_user(substream, arg);
@@ -3851,6 +3887,8 @@ static int snd_pcm_mmap(struct file *file, struct vm_area_struct *area)
return -ENXIO;
fallthrough;
case SNDRV_PCM_MMAP_OFFSET_CONTROL_NEW:
+ if (is_buggy_control(pcm_file))
+ return -ENXIO;
if (!pcm_control_mmap_allowed(pcm_file))
return -ENXIO;
return snd_pcm_mmap_control(substream, file, area);
^ permalink raw reply related [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-08 8:43 ` Takashi Iwai
@ 2021-10-08 8:44 ` Takashi Iwai
-1 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2021-10-08 8:44 UTC (permalink / raw)
To: Rich Felker
Cc: Arnd Bergmann, Michael Forney, ALSA Development Mailing List,
Takashi Iwai, Baolin Wang, y2038 Mailman List,
Linux Kernel Mailing List, Mark Brown, Baolin Wang, musl
On Fri, 08 Oct 2021 10:43:24 +0200,
Takashi Iwai wrote:
>
> On Thu, 07 Oct 2021 18:51:58 +0200,
> Rich Felker wrote:
> >
> > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> > > On Thu, 07 Oct 2021 18:06:36 +0200,
> > > Rich Felker wrote:
> > > >
> > > > On Thu, Oct 07, 2021 at 05:33:19PM +0200, Takashi Iwai wrote:
> > > > > On Thu, 07 Oct 2021 15:11:00 +0200,
> > > > > Arnd Bergmann wrote:
> > > > > >
> > > > > > On Thu, Oct 7, 2021 at 2:43 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > On Thu, 07 Oct 2021 13:48:44 +0200, Arnd Bergmann wrote:
> > > > > > > > On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > > > On Wed, 06 Oct 2021 19:49:17 +0200, Michael Forney wrote:
> > > > > > > >
> > > > > > > > As far as I can tell, the broken interface will always result in
> > > > > > > > user space seeing a zero value for "avail_min". Can you
> > > > > > > > make a prediction what that would mean for actual
> > > > > > > > applications? Will they have no audio output, run into
> > > > > > > > a crash, or be able to use recover and appear to work normally
> > > > > > > > here?
> > > > > > >
> > > > > > > No, fortunately it's only about control->avail_min, and fiddling this
> > > > > > > value can't break severely (otherwise it'd be a security problem ;)
> > > > > > >
> > > > > > > In the buggy condition, it's always zero, and the kernel treated as if
> > > > > > > 1, i.e. wake up as soon as data is available, which is OK-ish for most
> > > > > > > applications. Apps usually don't care about the wake-up condition so
> > > > > > > much. There are subtle difference and may influence on the stability
> > > > > > > of stream processing, but the stability usually depends more strongly
> > > > > > > on the hardware and software configurations.
> > > > > > >
> > > > > > > That being said, the impact by this bug (from the application behavior
> > > > > > > POV) is likely quite small, but the contamination is large; as you
> > > > > > > pointed out, it's much larger than I thought.
> > > > > >
> > > > > > Ok, got it.
> > > > > >
> > > > > > > The definition in uapi/sound/asound.h is a bit cryptic, but IIUC,
> > > > > > > __snd_pcm_mmap_control64 is used for 64bit archs, right? If so, the
> > > > > > > problem rather hits more widely on 64bit archs silently. Then, the
> > > > > > > influence by this bug must be almost negligible, as we've had no bug
> > > > > > > report about the behavior change.
> > > > > >
> > > > > > While __snd_pcm_mmap_control64 is only used on 32-bit
> > > > > > architectures when 64-bit time_t is used. At the moment, this
> > > > > > means all users of musl-1.2.x libc, but not glibc.
> > > > > >
> > > > > > On 64-bit architectures, __snd_pcm_mmap_control and
> > > > > > __snd_pcm_mmap_control64 are meant to be identical,
> > > > > > and this is actually true regardless of the bug, since
> > > > > > __pad_before_uframe and __pad_after_uframe both
> > > > > > end up as zero-length arrays here.
> > > > > >
> > > > > > > We may just fix it in kernel and for new library with hoping that no
> > > > > > > one sees the actual problem. Or, we may provide a complete new set of
> > > > > > > mmap offsets and ioctl to cover both broken and fixed interfaces...
> > > > > > > The decision depends on how perfectly we'd like to address the bug.
> > > > > > > As of now, I'm inclined to go for the former, but I'm open for more
> > > > > > > opinions.
> > > > > >
> > > > > > Adding the musl list to Cc for additional testers, anyone interested
> > > > > > please see [1] for the original report.
> > > > > >
> > > > > > It would be good to hear from musl users that are already using
> > > > > > audio support with 32-bit applications on 64-bit kernels, which
> > > > > > is the case that has the problem today. Have you noticed any
> > > > > > problems with audio support here? If not, we can probably
> > > > > > "fix" the kernel here and make the existing binaries behave
> > > > > > the same way on 32-bit kernels. If there are applications that
> > > > > > don't work in that environment today, I think we need to instead
> > > > > > change the kernel to accept the currently broken format on
> > > > > > both 32-bit and 64-bit kernels, possibly introducing yet another
> > > > > > format that works as originally intended but requires a newly
> > > > > > built kernel.
> > > > >
> > > > > Thanks!
> > > > >
> > > > > And now, looking more deeply, I feel more desperate.
> > > > >
> > > > > This bug makes the expected padding gone on little-endian.
> > > > > On LE 32bit, the buggy definition is:
> > > > >
> > > > > char __pad1[0];
> > > > > u32 appl_ptr;
> > > > > char __pad2[0]; // this should have been [4]
> > > > > char __pad3[0];
> > > > > u32 avail_min;
> > > > > char __pad4[4];
> > > > >
> > > > > When an application issues SYNC_PTR64 ioctl to submit appl_ptr and
> > > > > avail_min updates, 64bit kernel (in compat mode) reads directly as:
> > > > >
> > > > > u64 appl_ptr;
> > > > > u64 avail_min;
> > > > >
> > > > > Hence a bogus appl_ptr would be passed if avail_min != 0.
> > > > > And usually application sets non-zero avail_min.
> > > > > That is, the bug must hit more severely if the new API were really
> > > > > used. It wouldn't crash, but some weird streaming behavior can
> > > > > happen like noise, jumping or underruns.
> > > > >
> > > > > (Reading back avail_min=0 to user-space is rather harmless. Ditto for
> > > > > the case of BE, then at least there is no appl_ptr corruption.)
> > > > >
> > > > > This made me wonder which way to go:
> > > > > it's certainly possible to fix the new kernel to treat both buggy and
> > > > > sane formats (disabling compat mmap and re-define ioctls, having the
> > > > > code for old APIs). The problem is, however, in the case where the
> > > > > application needs to run on the older kernel that expects the buggy
> > > > > format. Then apps would still have to send in the old buggy format --
> > > > > or maybe better in the older 32bit format that won't hit the bug
> > > > > above. It makes situation more complicated.
> > > >
> > > > Can't an ioctl number just be redefined so that, on old kernels with
> > > > the buggy one, newly built applications get told that mmap is not
> > > > available and use the unaffected non-mmap fallback?
> > >
> > > The problem is that the SYNC_PTR64 ioctl itself for non-mmap fallback
> > > is equally buggy due to this bug, too. So disabling mmap doesn't help
> > > alone.
> > >
> > > And, yes, we can redefine ioctl numbers. But, then, application would
> > > have to be bilingual, as well as the kernel; it'll have to switch back
> > > to old API when running on older kernel, while the same binary would
> > > need to run in a new API for a newer kernel.
> > >
> > > Maybe we can implement it in alsa-lib, if it really worth for it.
> >
> > In musl we already have ioctl struct conversion for running on
> > time32-only kernels. So it may be practical to convert this too if
> > needed.
>
> I guess we can work around without ioctl renumbering. The PCM API has
> a protocol version handshaking, and user-space is supposed to tell its
> API version to kernel. So the kernel can know in what version
> user-space is talking with.
>
> Below is the PoC fix in the kernel side (totally untested).
> The fix for alsa-lib will follow.
And below is the PoC fix for alsa-lib.
Takashi
---
diff --git a/include/sound/uapi/asound.h b/include/sound/uapi/asound.h
index 9fe3943f5fbb..ee91fe1f881f 100644
--- a/include/sound/uapi/asound.h
+++ b/include/sound/uapi/asound.h
@@ -154,7 +154,7 @@ struct snd_hwdep_dsp_image {
* *
*****************************************************************************/
-#define SNDRV_PCM_VERSION SNDRV_PROTOCOL_VERSION(2, 0, 15)
+#define SNDRV_PCM_VERSION SNDRV_PROTOCOL_VERSION(2, 0, 16)
typedef unsigned long snd_pcm_uframes_t;
typedef signed long snd_pcm_sframes_t;
@@ -541,6 +541,7 @@ struct __snd_pcm_sync_ptr {
} s;
union {
struct __snd_pcm_mmap_control control;
+ struct __snd_pcm_mmap_control control_api_2_0_15; /* no bug in 32bit mode */
unsigned char reserved[64];
} c;
};
@@ -548,11 +549,15 @@ struct __snd_pcm_sync_ptr {
#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
typedef char __pad_after_uframe[0];
+typedef char __pad_before_u32[4];
+typedef char __pad_after_u32[0];
#endif
#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
typedef char __pad_before_uframe[0];
typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
+typedef char __pad_before_u32[0];
+typedef char __pad_after_u32[4];
#endif
struct __snd_pcm_mmap_status64 {
@@ -570,13 +575,23 @@ struct __snd_pcm_mmap_status64 {
struct __snd_pcm_mmap_control64 {
__pad_before_uframe __pad1;
snd_pcm_uframes_t appl_ptr; /* RW: appl ptr (0...boundary-1) */
- __pad_before_uframe __pad2;
+ __pad_after_uframe __pad2;
__pad_before_uframe __pad3;
snd_pcm_uframes_t avail_min; /* RW: min available frames for wakeup */
__pad_after_uframe __pad4;
};
+/* buggy mmap control definition for 2.0.15 PCM API on 32bit mode */
+struct __snd_pcm_mmap_control64_api_2_0_15 {
+ __pad_before_u32 __pad1;
+ __u32 appl_ptr;
+ __pad_before_u32 __pad2; /* SiC! here is the bug */
+ __pad_before_u32 __pad3;
+ __u32 avail_min;
+ __pad_after_uframe __pad4;
+};
+
struct __snd_pcm_sync_ptr64 {
__u32 flags;
__u32 pad1;
@@ -586,6 +601,7 @@ struct __snd_pcm_sync_ptr64 {
} s;
union {
struct __snd_pcm_mmap_control64 control;
+ struct __snd_pcm_mmap_control64_api_2_0_15 control_api_2_0_15;
unsigned char reserved[64];
} c;
};
diff --git a/src/pcm/pcm_hw.c b/src/pcm/pcm_hw.c
index b3f9d1579d29..bb97b7ecf5ca 100644
--- a/src/pcm/pcm_hw.c
+++ b/src/pcm/pcm_hw.c
@@ -94,6 +94,7 @@ typedef struct {
volatile struct snd_pcm_mmap_status * mmap_status;
struct snd_pcm_mmap_control *mmap_control;
+ snd_pcm_uframes_t *avail_min_p;
bool mmap_status_fallbacked;
bool mmap_control_fallbacked;
struct snd_pcm_sync_ptr *sync_ptr;
@@ -507,7 +508,7 @@ static int snd_pcm_hw_sw_params(snd_pcm_t *pcm, snd_pcm_sw_params_t * params)
params->silence_threshold == pcm->silence_threshold &&
params->silence_size == pcm->silence_size &&
old_period_event == hw->period_event) {
- hw->mmap_control->avail_min = params->avail_min;
+ *hw->avail_min_p = params->avail_min;
err = issue_avail_min(hw);
goto out;
}
@@ -540,7 +541,7 @@ static int snd_pcm_hw_sw_params(snd_pcm_t *pcm, snd_pcm_sw_params_t * params)
}
pcm->tstamp_type = params->tstamp_type;
}
- hw->mmap_control->avail_min = params->avail_min;
+ *hw->avail_min_p = params->avail_min;
if (hw->period_event != old_period_event) {
err = snd_pcm_hw_change_timer(pcm, old_period_event);
if (err < 0)
@@ -980,6 +981,14 @@ static bool map_control_data(snd_pcm_hw_t *hw,
}
hw->mmap_control = mmap_control;
+ hw->avail_min_p = &mmap_control->avail_min;
+#ifdef __SND_STRUCT_TIME64
+ if (hw->version == SNDRV_PROTOCOL_VERSION(2, 0, 15)) {
+ struct __snd_pcm_mmap_control64_api_2_0_15 *buggy_control =
+ (struct __snd_pcm_mmap_control64_api_2_0_15 *)mmap_control;
+ hw->avail_min_p = &buggy_control->avail_min;
+ }
+#endif
return fallbacked;
}
@@ -1015,7 +1024,7 @@ static int map_status_and_control_data(snd_pcm_t *pcm, bool force_fallback)
if (!(pcm->mode & SND_PCM_APPEND)) {
/* Initialize the data. */
hw->mmap_control->appl_ptr = 0;
- hw->mmap_control->avail_min = 1;
+ *hw->avail_min_p = 1;
}
snd_pcm_set_hw_ptr(pcm, &hw->mmap_status->hw_ptr, hw->fd,
SNDRV_PCM_MMAP_OFFSET_STATUS +
^ permalink raw reply related [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-08 8:44 ` Takashi Iwai
0 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2021-10-08 8:44 UTC (permalink / raw)
To: Rich Felker
Cc: ALSA Development Mailing List, Arnd Bergmann, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, musl,
Takashi Iwai, Michael Forney, Mark Brown, Baolin Wang
On Fri, 08 Oct 2021 10:43:24 +0200,
Takashi Iwai wrote:
>
> On Thu, 07 Oct 2021 18:51:58 +0200,
> Rich Felker wrote:
> >
> > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> > > On Thu, 07 Oct 2021 18:06:36 +0200,
> > > Rich Felker wrote:
> > > >
> > > > On Thu, Oct 07, 2021 at 05:33:19PM +0200, Takashi Iwai wrote:
> > > > > On Thu, 07 Oct 2021 15:11:00 +0200,
> > > > > Arnd Bergmann wrote:
> > > > > >
> > > > > > On Thu, Oct 7, 2021 at 2:43 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > On Thu, 07 Oct 2021 13:48:44 +0200, Arnd Bergmann wrote:
> > > > > > > > On Thu, Oct 7, 2021 at 12:53 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > > > On Wed, 06 Oct 2021 19:49:17 +0200, Michael Forney wrote:
> > > > > > > >
> > > > > > > > As far as I can tell, the broken interface will always result in
> > > > > > > > user space seeing a zero value for "avail_min". Can you
> > > > > > > > make a prediction what that would mean for actual
> > > > > > > > applications? Will they have no audio output, run into
> > > > > > > > a crash, or be able to use recover and appear to work normally
> > > > > > > > here?
> > > > > > >
> > > > > > > No, fortunately it's only about control->avail_min, and fiddling this
> > > > > > > value can't break severely (otherwise it'd be a security problem ;)
> > > > > > >
> > > > > > > In the buggy condition, it's always zero, and the kernel treated as if
> > > > > > > 1, i.e. wake up as soon as data is available, which is OK-ish for most
> > > > > > > applications. Apps usually don't care about the wake-up condition so
> > > > > > > much. There are subtle difference and may influence on the stability
> > > > > > > of stream processing, but the stability usually depends more strongly
> > > > > > > on the hardware and software configurations.
> > > > > > >
> > > > > > > That being said, the impact by this bug (from the application behavior
> > > > > > > POV) is likely quite small, but the contamination is large; as you
> > > > > > > pointed out, it's much larger than I thought.
> > > > > >
> > > > > > Ok, got it.
> > > > > >
> > > > > > > The definition in uapi/sound/asound.h is a bit cryptic, but IIUC,
> > > > > > > __snd_pcm_mmap_control64 is used for 64bit archs, right? If so, the
> > > > > > > problem rather hits more widely on 64bit archs silently. Then, the
> > > > > > > influence by this bug must be almost negligible, as we've had no bug
> > > > > > > report about the behavior change.
> > > > > >
> > > > > > While __snd_pcm_mmap_control64 is only used on 32-bit
> > > > > > architectures when 64-bit time_t is used. At the moment, this
> > > > > > means all users of musl-1.2.x libc, but not glibc.
> > > > > >
> > > > > > On 64-bit architectures, __snd_pcm_mmap_control and
> > > > > > __snd_pcm_mmap_control64 are meant to be identical,
> > > > > > and this is actually true regardless of the bug, since
> > > > > > __pad_before_uframe and __pad_after_uframe both
> > > > > > end up as zero-length arrays here.
> > > > > >
> > > > > > > We may just fix it in kernel and for new library with hoping that no
> > > > > > > one sees the actual problem. Or, we may provide a complete new set of
> > > > > > > mmap offsets and ioctl to cover both broken and fixed interfaces...
> > > > > > > The decision depends on how perfectly we'd like to address the bug.
> > > > > > > As of now, I'm inclined to go for the former, but I'm open for more
> > > > > > > opinions.
> > > > > >
> > > > > > Adding the musl list to Cc for additional testers, anyone interested
> > > > > > please see [1] for the original report.
> > > > > >
> > > > > > It would be good to hear from musl users that are already using
> > > > > > audio support with 32-bit applications on 64-bit kernels, which
> > > > > > is the case that has the problem today. Have you noticed any
> > > > > > problems with audio support here? If not, we can probably
> > > > > > "fix" the kernel here and make the existing binaries behave
> > > > > > the same way on 32-bit kernels. If there are applications that
> > > > > > don't work in that environment today, I think we need to instead
> > > > > > change the kernel to accept the currently broken format on
> > > > > > both 32-bit and 64-bit kernels, possibly introducing yet another
> > > > > > format that works as originally intended but requires a newly
> > > > > > built kernel.
> > > > >
> > > > > Thanks!
> > > > >
> > > > > And now, looking more deeply, I feel more desperate.
> > > > >
> > > > > This bug makes the expected padding gone on little-endian.
> > > > > On LE 32bit, the buggy definition is:
> > > > >
> > > > > char __pad1[0];
> > > > > u32 appl_ptr;
> > > > > char __pad2[0]; // this should have been [4]
> > > > > char __pad3[0];
> > > > > u32 avail_min;
> > > > > char __pad4[4];
> > > > >
> > > > > When an application issues SYNC_PTR64 ioctl to submit appl_ptr and
> > > > > avail_min updates, 64bit kernel (in compat mode) reads directly as:
> > > > >
> > > > > u64 appl_ptr;
> > > > > u64 avail_min;
> > > > >
> > > > > Hence a bogus appl_ptr would be passed if avail_min != 0.
> > > > > And usually application sets non-zero avail_min.
> > > > > That is, the bug must hit more severely if the new API were really
> > > > > used. It wouldn't crash, but some weird streaming behavior can
> > > > > happen like noise, jumping or underruns.
> > > > >
> > > > > (Reading back avail_min=0 to user-space is rather harmless. Ditto for
> > > > > the case of BE, then at least there is no appl_ptr corruption.)
> > > > >
> > > > > This made me wonder which way to go:
> > > > > it's certainly possible to fix the new kernel to treat both buggy and
> > > > > sane formats (disabling compat mmap and re-define ioctls, having the
> > > > > code for old APIs). The problem is, however, in the case where the
> > > > > application needs to run on the older kernel that expects the buggy
> > > > > format. Then apps would still have to send in the old buggy format --
> > > > > or maybe better in the older 32bit format that won't hit the bug
> > > > > above. It makes situation more complicated.
> > > >
> > > > Can't an ioctl number just be redefined so that, on old kernels with
> > > > the buggy one, newly built applications get told that mmap is not
> > > > available and use the unaffected non-mmap fallback?
> > >
> > > The problem is that the SYNC_PTR64 ioctl itself for non-mmap fallback
> > > is equally buggy due to this bug, too. So disabling mmap doesn't help
> > > alone.
> > >
> > > And, yes, we can redefine ioctl numbers. But, then, application would
> > > have to be bilingual, as well as the kernel; it'll have to switch back
> > > to old API when running on older kernel, while the same binary would
> > > need to run in a new API for a newer kernel.
> > >
> > > Maybe we can implement it in alsa-lib, if it really worth for it.
> >
> > In musl we already have ioctl struct conversion for running on
> > time32-only kernels. So it may be practical to convert this too if
> > needed.
>
> I guess we can work around without ioctl renumbering. The PCM API has
> a protocol version handshaking, and user-space is supposed to tell its
> API version to kernel. So the kernel can know in what version
> user-space is talking with.
>
> Below is the PoC fix in the kernel side (totally untested).
> The fix for alsa-lib will follow.
And below is the PoC fix for alsa-lib.
Takashi
---
diff --git a/include/sound/uapi/asound.h b/include/sound/uapi/asound.h
index 9fe3943f5fbb..ee91fe1f881f 100644
--- a/include/sound/uapi/asound.h
+++ b/include/sound/uapi/asound.h
@@ -154,7 +154,7 @@ struct snd_hwdep_dsp_image {
* *
*****************************************************************************/
-#define SNDRV_PCM_VERSION SNDRV_PROTOCOL_VERSION(2, 0, 15)
+#define SNDRV_PCM_VERSION SNDRV_PROTOCOL_VERSION(2, 0, 16)
typedef unsigned long snd_pcm_uframes_t;
typedef signed long snd_pcm_sframes_t;
@@ -541,6 +541,7 @@ struct __snd_pcm_sync_ptr {
} s;
union {
struct __snd_pcm_mmap_control control;
+ struct __snd_pcm_mmap_control control_api_2_0_15; /* no bug in 32bit mode */
unsigned char reserved[64];
} c;
};
@@ -548,11 +549,15 @@ struct __snd_pcm_sync_ptr {
#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
typedef char __pad_after_uframe[0];
+typedef char __pad_before_u32[4];
+typedef char __pad_after_u32[0];
#endif
#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
typedef char __pad_before_uframe[0];
typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
+typedef char __pad_before_u32[0];
+typedef char __pad_after_u32[4];
#endif
struct __snd_pcm_mmap_status64 {
@@ -570,13 +575,23 @@ struct __snd_pcm_mmap_status64 {
struct __snd_pcm_mmap_control64 {
__pad_before_uframe __pad1;
snd_pcm_uframes_t appl_ptr; /* RW: appl ptr (0...boundary-1) */
- __pad_before_uframe __pad2;
+ __pad_after_uframe __pad2;
__pad_before_uframe __pad3;
snd_pcm_uframes_t avail_min; /* RW: min available frames for wakeup */
__pad_after_uframe __pad4;
};
+/* buggy mmap control definition for 2.0.15 PCM API on 32bit mode */
+struct __snd_pcm_mmap_control64_api_2_0_15 {
+ __pad_before_u32 __pad1;
+ __u32 appl_ptr;
+ __pad_before_u32 __pad2; /* SiC! here is the bug */
+ __pad_before_u32 __pad3;
+ __u32 avail_min;
+ __pad_after_uframe __pad4;
+};
+
struct __snd_pcm_sync_ptr64 {
__u32 flags;
__u32 pad1;
@@ -586,6 +601,7 @@ struct __snd_pcm_sync_ptr64 {
} s;
union {
struct __snd_pcm_mmap_control64 control;
+ struct __snd_pcm_mmap_control64_api_2_0_15 control_api_2_0_15;
unsigned char reserved[64];
} c;
};
diff --git a/src/pcm/pcm_hw.c b/src/pcm/pcm_hw.c
index b3f9d1579d29..bb97b7ecf5ca 100644
--- a/src/pcm/pcm_hw.c
+++ b/src/pcm/pcm_hw.c
@@ -94,6 +94,7 @@ typedef struct {
volatile struct snd_pcm_mmap_status * mmap_status;
struct snd_pcm_mmap_control *mmap_control;
+ snd_pcm_uframes_t *avail_min_p;
bool mmap_status_fallbacked;
bool mmap_control_fallbacked;
struct snd_pcm_sync_ptr *sync_ptr;
@@ -507,7 +508,7 @@ static int snd_pcm_hw_sw_params(snd_pcm_t *pcm, snd_pcm_sw_params_t * params)
params->silence_threshold == pcm->silence_threshold &&
params->silence_size == pcm->silence_size &&
old_period_event == hw->period_event) {
- hw->mmap_control->avail_min = params->avail_min;
+ *hw->avail_min_p = params->avail_min;
err = issue_avail_min(hw);
goto out;
}
@@ -540,7 +541,7 @@ static int snd_pcm_hw_sw_params(snd_pcm_t *pcm, snd_pcm_sw_params_t * params)
}
pcm->tstamp_type = params->tstamp_type;
}
- hw->mmap_control->avail_min = params->avail_min;
+ *hw->avail_min_p = params->avail_min;
if (hw->period_event != old_period_event) {
err = snd_pcm_hw_change_timer(pcm, old_period_event);
if (err < 0)
@@ -980,6 +981,14 @@ static bool map_control_data(snd_pcm_hw_t *hw,
}
hw->mmap_control = mmap_control;
+ hw->avail_min_p = &mmap_control->avail_min;
+#ifdef __SND_STRUCT_TIME64
+ if (hw->version == SNDRV_PROTOCOL_VERSION(2, 0, 15)) {
+ struct __snd_pcm_mmap_control64_api_2_0_15 *buggy_control =
+ (struct __snd_pcm_mmap_control64_api_2_0_15 *)mmap_control;
+ hw->avail_min_p = &buggy_control->avail_min;
+ }
+#endif
return fallbacked;
}
@@ -1015,7 +1024,7 @@ static int map_status_and_control_data(snd_pcm_t *pcm, bool force_fallback)
if (!(pcm->mode & SND_PCM_APPEND)) {
/* Initialize the data. */
hw->mmap_control->appl_ptr = 0;
- hw->mmap_control->avail_min = 1;
+ *hw->avail_min_p = 1;
}
snd_pcm_set_hw_ptr(pcm, &hw->mmap_status->hw_ptr, hw->fd,
SNDRV_PCM_MMAP_OFFSET_STATUS +
^ permalink raw reply related [flat|nested] 94+ messages in thread
* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-08 8:43 ` Takashi Iwai
@ 2021-10-08 9:24 ` Arnd Bergmann
-1 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2021-10-08 9:24 UTC (permalink / raw)
To: musl
Cc: Rich Felker, Arnd Bergmann, Michael Forney,
ALSA Development Mailing List, Takashi Iwai, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, Mark Brown,
Baolin Wang
On Fri, Oct 8, 2021 at 10:43 AM Takashi Iwai <tiwai@suse.de> wrote:
> On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote:
> > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
>
> @@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
> #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> typedef char __pad_after_uframe[0];
> +typedef char __pad_before_u32[4];
> +typedef char __pad_after_u32[0];
> #endif
>
> #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> typedef char __pad_before_uframe[0];
> typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> +typedef char __pad_before_u32[0];
> +typedef char __pad_after_u32[4];
> #endif
I think these should remain unchanged, the complex expression was intentionally
done so the structures are laid out the same way on 64-bit
architectures, so that
the kernel can use the __SND_STRUCT_TIME64 path internally on both 32-bit
and 64-bit architectures.
> @@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
> memset(&sync_ptr, 0, sizeof(sync_ptr));
> if (get_user(sync_ptr.flags, (unsigned __user *)&(_sync_ptr->flags)))
> return -EFAULT;
> - if (copy_from_user(&sync_ptr.c.control, &(_sync_ptr->c.control), sizeof(struct snd_pcm_mmap_control)))
> - return -EFAULT;
> + if (buggy_control) {
> + if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
> + &(_sync_ptr->c.control_api_2_0_15),
> + sizeof(sync_ptr.c.control_api_2_0_15)))
> + return -EFAULT;
> + } else {
> + if (copy_from_user(&sync_ptr.c.control,
> + &(_sync_ptr->c.control),
> + sizeof(sync_ptr.c.control)))
> + return -EFAULT;
> + }
The problem I see with this is that it might break musl's ability to
emulate the new
interface on top of the old (time32) one for linux-4.x and older
kernels, as the conversion
function is no longer stateless but has to know the negotiated
interface version.
It's probably fine as long as we can be sure that the 2.0.16+ API
version only gets
negotiated if both the kernel and user sides support it, and musl only emulates
the 2.0.15 API version from the current kernels.
I've tried to understand this part of musl's convert_ioctl_struct(), but I just
can't figure out whether it does the conversion based the on the layout that
is currently used in the kernel, or based on the layout we should have been
using, and would use with the above fix. Rich, can you help me here?
Arnd
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-08 9:24 ` Arnd Bergmann
0 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2021-10-08 9:24 UTC (permalink / raw)
To: musl
Cc: ALSA Development Mailing List, Rich Felker, Arnd Bergmann,
Baolin Wang, y2038 Mailman List, Linux Kernel Mailing List,
Takashi Iwai, Michael Forney, Mark Brown, Baolin Wang
On Fri, Oct 8, 2021 at 10:43 AM Takashi Iwai <tiwai@suse.de> wrote:
> On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote:
> > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
>
> @@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
> #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> typedef char __pad_after_uframe[0];
> +typedef char __pad_before_u32[4];
> +typedef char __pad_after_u32[0];
> #endif
>
> #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> typedef char __pad_before_uframe[0];
> typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> +typedef char __pad_before_u32[0];
> +typedef char __pad_after_u32[4];
> #endif
I think these should remain unchanged, the complex expression was intentionally
done so the structures are laid out the same way on 64-bit
architectures, so that
the kernel can use the __SND_STRUCT_TIME64 path internally on both 32-bit
and 64-bit architectures.
> @@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
> memset(&sync_ptr, 0, sizeof(sync_ptr));
> if (get_user(sync_ptr.flags, (unsigned __user *)&(_sync_ptr->flags)))
> return -EFAULT;
> - if (copy_from_user(&sync_ptr.c.control, &(_sync_ptr->c.control), sizeof(struct snd_pcm_mmap_control)))
> - return -EFAULT;
> + if (buggy_control) {
> + if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
> + &(_sync_ptr->c.control_api_2_0_15),
> + sizeof(sync_ptr.c.control_api_2_0_15)))
> + return -EFAULT;
> + } else {
> + if (copy_from_user(&sync_ptr.c.control,
> + &(_sync_ptr->c.control),
> + sizeof(sync_ptr.c.control)))
> + return -EFAULT;
> + }
The problem I see with this is that it might break musl's ability to
emulate the new
interface on top of the old (time32) one for linux-4.x and older
kernels, as the conversion
function is no longer stateless but has to know the negotiated
interface version.
It's probably fine as long as we can be sure that the 2.0.16+ API
version only gets
negotiated if both the kernel and user sides support it, and musl only emulates
the 2.0.15 API version from the current kernels.
I've tried to understand this part of musl's convert_ioctl_struct(), but I just
can't figure out whether it does the conversion based the on the layout that
is currently used in the kernel, or based on the layout we should have been
using, and would use with the above fix. Rich, can you help me here?
Arnd
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-08 9:24 ` Arnd Bergmann
@ 2021-10-08 11:11 ` Takashi Iwai
-1 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2021-10-08 11:11 UTC (permalink / raw)
To: Arnd Bergmann
Cc: musl, Rich Felker, Michael Forney, ALSA Development Mailing List,
Takashi Iwai, Baolin Wang, y2038 Mailman List,
Linux Kernel Mailing List, Mark Brown, Baolin Wang
On Fri, 08 Oct 2021 11:24:39 +0200,
Arnd Bergmann wrote:
>
> On Fri, Oct 8, 2021 at 10:43 AM Takashi Iwai <tiwai@suse.de> wrote:
> > On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote:
> > > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> >
> > @@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
> > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> > typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > typedef char __pad_after_uframe[0];
> > +typedef char __pad_before_u32[4];
> > +typedef char __pad_after_u32[0];
> > #endif
> >
> > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> > typedef char __pad_before_uframe[0];
> > typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > +typedef char __pad_before_u32[0];
> > +typedef char __pad_after_u32[4];
> > #endif
>
> I think these should remain unchanged, the complex expression was intentionally
> done so the structures are laid out the same way on 64-bit
> architectures, so that
> the kernel can use the __SND_STRUCT_TIME64 path internally on both 32-bit
> and 64-bit architectures.
That was explicitly defined, but OK, this isn't necessarily defined
here.
> > @@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
> > memset(&sync_ptr, 0, sizeof(sync_ptr));
> > if (get_user(sync_ptr.flags, (unsigned __user *)&(_sync_ptr->flags)))
> > return -EFAULT;
> > - if (copy_from_user(&sync_ptr.c.control, &(_sync_ptr->c.control), sizeof(struct snd_pcm_mmap_control)))
> > - return -EFAULT;
> > + if (buggy_control) {
> > + if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
> > + &(_sync_ptr->c.control_api_2_0_15),
> > + sizeof(sync_ptr.c.control_api_2_0_15)))
> > + return -EFAULT;
> > + } else {
> > + if (copy_from_user(&sync_ptr.c.control,
> > + &(_sync_ptr->c.control),
> > + sizeof(sync_ptr.c.control)))
> > + return -EFAULT;
> > + }
>
> The problem I see with this is that it might break musl's ability to
> emulate the new
> interface on top of the old (time32) one for linux-4.x and older
> kernels, as the conversion
> function is no longer stateless but has to know the negotiated
> interface version.
>
> It's probably fine as long as we can be sure that the 2.0.16+ API
> version only gets
> negotiated if both the kernel and user sides support it, and musl only emulates
> the 2.0.15 API version from the current kernels.
>
> I've tried to understand this part of musl's convert_ioctl_struct(), but I just
> can't figure out whether it does the conversion based the on the layout that
> is currently used in the kernel, or based on the layout we should have been
> using, and would use with the above fix. Rich, can you help me here?
So, at this moment, I'm not sure whether we should correct the struct
at all. This will lead to yet more breakage, and basically the struct
itself *works* -- the only bug is in 32bit compat handling in the
kernel (again).
The below is a revised kernel patch (again untested), just correcting
the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
fine as is, as well as 64bit apps on 64bit kernel.
Takashi
--- a/sound/core/pcm_compat.c
+++ b/sound/core/pcm_compat.c
@@ -468,6 +468,75 @@ static int snd_pcm_ioctl_sync_ptr_x32(struct snd_pcm_substream *substream,
}
#endif /* CONFIG_X86_X32 */
+#ifdef __BIG_ENDIAN
+typedef char __pad_before_u32[4];
+typedef char __pad_after_u32[0];
+#else
+typedef char __pad_before_u32[0];
+typedef char __pad_after_u32[4];
+#endif
+
+/* PCM 2.0.15 API definition had a bug in mmap control; it puts the avail_min
+ * at the wrong offset due to a typo in padding type, hitting only on 32bit.
+ * Workaround for incorrect read/write is needed only in 32bit compat mode.
+ */
+struct __snd_pcm_mmap_control64_buggy {
+ __pad_before_u32 __pad1;
+ __u32 appl_ptr;
+ __pad_before_u32 __pad2; /* SiC! here is the bug */
+ __pad_before_u32 __pad3;
+ __u32 avail_min;
+ __pad_after_uframe __pad4;
+};
+
+static int snd_pcm_ioctl_sync_ptr_buggy(struct snd_pcm_substream *substream,
+ struct snd_pcm_sync_ptr __user *_sync_ptr)
+{
+ struct snd_pcm_runtime *runtime = substream->runtime;
+ struct snd_pcm_sync_ptr sync_ptr;
+ struct __snd_pcm_mmap_control64_buggy *sync_cp;
+ volatile struct snd_pcm_mmap_status *status;
+ volatile struct snd_pcm_mmap_control *control;
+ int err;
+
+ memset(&sync_ptr, 0, sizeof(sync_ptr));
+ sync_cp = (struct __snd_pcm_mmap_control64_buggy *)&sync_ptr.c.control;
+ if (get_user(sync_ptr.flags, (unsigned __user *)&(_sync_ptr->flags)))
+ return -EFAULT;
+ if (copy_from_user(sync_cp, &(_sync_ptr->c.control), sizeof(*sync_cp)))
+ return -EFAULT;
+ status = runtime->status;
+ control = runtime->control;
+ if (sync_ptr.flags & SNDRV_PCM_SYNC_PTR_HWSYNC) {
+ err = snd_pcm_hwsync(substream);
+ if (err < 0)
+ return err;
+ }
+ snd_pcm_stream_lock_irq(substream);
+ if (!(sync_ptr.flags & SNDRV_PCM_SYNC_PTR_APPL)) {
+ err = pcm_lib_apply_appl_ptr(substream, sync_cp->appl_ptr);
+ if (err < 0) {
+ snd_pcm_stream_unlock_irq(substream);
+ return err;
+ }
+ } else {
+ sync_cp->appl_ptr = control->appl_ptr;
+ }
+ if (!(sync_ptr.flags & SNDRV_PCM_SYNC_PTR_AVAIL_MIN))
+ control->avail_min = sync_cp->avail_min;
+ else
+ sync_cp->avail_min = control->avail_min;
+ sync_ptr.s.status.state = status->state;
+ sync_ptr.s.status.hw_ptr = status->hw_ptr;
+ sync_ptr.s.status.tstamp = status->tstamp;
+ sync_ptr.s.status.suspended_state = status->suspended_state;
+ sync_ptr.s.status.audio_tstamp = status->audio_tstamp;
+ snd_pcm_stream_unlock_irq(substream);
+ if (copy_to_user(_sync_ptr, &sync_ptr, sizeof(sync_ptr)))
+ return -EFAULT;
+ return 0;
+}
+
/*
*/
enum {
@@ -537,7 +606,7 @@ static long snd_pcm_ioctl_compat(struct file *file, unsigned int cmd, unsigned l
if (in_x32_syscall())
return snd_pcm_ioctl_sync_ptr_x32(substream, argp);
#endif /* CONFIG_X86_X32 */
- return snd_pcm_common_ioctl(file, substream, cmd, argp);
+ return snd_pcm_ioctl_sync_ptr_buggy(substream, argp);
case SNDRV_PCM_IOCTL_HW_REFINE32:
return snd_pcm_ioctl_hw_params_compat(substream, 1, argp);
case SNDRV_PCM_IOCTL_HW_PARAMS32:
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-08 11:11 ` Takashi Iwai
0 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2021-10-08 11:11 UTC (permalink / raw)
To: Arnd Bergmann
Cc: ALSA Development Mailing List, Rich Felker, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, musl,
Takashi Iwai, Michael Forney, Mark Brown, Baolin Wang
On Fri, 08 Oct 2021 11:24:39 +0200,
Arnd Bergmann wrote:
>
> On Fri, Oct 8, 2021 at 10:43 AM Takashi Iwai <tiwai@suse.de> wrote:
> > On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote:
> > > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> >
> > @@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
> > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> > typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > typedef char __pad_after_uframe[0];
> > +typedef char __pad_before_u32[4];
> > +typedef char __pad_after_u32[0];
> > #endif
> >
> > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> > typedef char __pad_before_uframe[0];
> > typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > +typedef char __pad_before_u32[0];
> > +typedef char __pad_after_u32[4];
> > #endif
>
> I think these should remain unchanged, the complex expression was intentionally
> done so the structures are laid out the same way on 64-bit
> architectures, so that
> the kernel can use the __SND_STRUCT_TIME64 path internally on both 32-bit
> and 64-bit architectures.
That was explicitly defined, but OK, this isn't necessarily defined
here.
> > @@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
> > memset(&sync_ptr, 0, sizeof(sync_ptr));
> > if (get_user(sync_ptr.flags, (unsigned __user *)&(_sync_ptr->flags)))
> > return -EFAULT;
> > - if (copy_from_user(&sync_ptr.c.control, &(_sync_ptr->c.control), sizeof(struct snd_pcm_mmap_control)))
> > - return -EFAULT;
> > + if (buggy_control) {
> > + if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
> > + &(_sync_ptr->c.control_api_2_0_15),
> > + sizeof(sync_ptr.c.control_api_2_0_15)))
> > + return -EFAULT;
> > + } else {
> > + if (copy_from_user(&sync_ptr.c.control,
> > + &(_sync_ptr->c.control),
> > + sizeof(sync_ptr.c.control)))
> > + return -EFAULT;
> > + }
>
> The problem I see with this is that it might break musl's ability to
> emulate the new
> interface on top of the old (time32) one for linux-4.x and older
> kernels, as the conversion
> function is no longer stateless but has to know the negotiated
> interface version.
>
> It's probably fine as long as we can be sure that the 2.0.16+ API
> version only gets
> negotiated if both the kernel and user sides support it, and musl only emulates
> the 2.0.15 API version from the current kernels.
>
> I've tried to understand this part of musl's convert_ioctl_struct(), but I just
> can't figure out whether it does the conversion based the on the layout that
> is currently used in the kernel, or based on the layout we should have been
> using, and would use with the above fix. Rich, can you help me here?
So, at this moment, I'm not sure whether we should correct the struct
at all. This will lead to yet more breakage, and basically the struct
itself *works* -- the only bug is in 32bit compat handling in the
kernel (again).
The below is a revised kernel patch (again untested), just correcting
the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
fine as is, as well as 64bit apps on 64bit kernel.
Takashi
--- a/sound/core/pcm_compat.c
+++ b/sound/core/pcm_compat.c
@@ -468,6 +468,75 @@ static int snd_pcm_ioctl_sync_ptr_x32(struct snd_pcm_substream *substream,
}
#endif /* CONFIG_X86_X32 */
+#ifdef __BIG_ENDIAN
+typedef char __pad_before_u32[4];
+typedef char __pad_after_u32[0];
+#else
+typedef char __pad_before_u32[0];
+typedef char __pad_after_u32[4];
+#endif
+
+/* PCM 2.0.15 API definition had a bug in mmap control; it puts the avail_min
+ * at the wrong offset due to a typo in padding type, hitting only on 32bit.
+ * Workaround for incorrect read/write is needed only in 32bit compat mode.
+ */
+struct __snd_pcm_mmap_control64_buggy {
+ __pad_before_u32 __pad1;
+ __u32 appl_ptr;
+ __pad_before_u32 __pad2; /* SiC! here is the bug */
+ __pad_before_u32 __pad3;
+ __u32 avail_min;
+ __pad_after_uframe __pad4;
+};
+
+static int snd_pcm_ioctl_sync_ptr_buggy(struct snd_pcm_substream *substream,
+ struct snd_pcm_sync_ptr __user *_sync_ptr)
+{
+ struct snd_pcm_runtime *runtime = substream->runtime;
+ struct snd_pcm_sync_ptr sync_ptr;
+ struct __snd_pcm_mmap_control64_buggy *sync_cp;
+ volatile struct snd_pcm_mmap_status *status;
+ volatile struct snd_pcm_mmap_control *control;
+ int err;
+
+ memset(&sync_ptr, 0, sizeof(sync_ptr));
+ sync_cp = (struct __snd_pcm_mmap_control64_buggy *)&sync_ptr.c.control;
+ if (get_user(sync_ptr.flags, (unsigned __user *)&(_sync_ptr->flags)))
+ return -EFAULT;
+ if (copy_from_user(sync_cp, &(_sync_ptr->c.control), sizeof(*sync_cp)))
+ return -EFAULT;
+ status = runtime->status;
+ control = runtime->control;
+ if (sync_ptr.flags & SNDRV_PCM_SYNC_PTR_HWSYNC) {
+ err = snd_pcm_hwsync(substream);
+ if (err < 0)
+ return err;
+ }
+ snd_pcm_stream_lock_irq(substream);
+ if (!(sync_ptr.flags & SNDRV_PCM_SYNC_PTR_APPL)) {
+ err = pcm_lib_apply_appl_ptr(substream, sync_cp->appl_ptr);
+ if (err < 0) {
+ snd_pcm_stream_unlock_irq(substream);
+ return err;
+ }
+ } else {
+ sync_cp->appl_ptr = control->appl_ptr;
+ }
+ if (!(sync_ptr.flags & SNDRV_PCM_SYNC_PTR_AVAIL_MIN))
+ control->avail_min = sync_cp->avail_min;
+ else
+ sync_cp->avail_min = control->avail_min;
+ sync_ptr.s.status.state = status->state;
+ sync_ptr.s.status.hw_ptr = status->hw_ptr;
+ sync_ptr.s.status.tstamp = status->tstamp;
+ sync_ptr.s.status.suspended_state = status->suspended_state;
+ sync_ptr.s.status.audio_tstamp = status->audio_tstamp;
+ snd_pcm_stream_unlock_irq(substream);
+ if (copy_to_user(_sync_ptr, &sync_ptr, sizeof(sync_ptr)))
+ return -EFAULT;
+ return 0;
+}
+
/*
*/
enum {
@@ -537,7 +606,7 @@ static long snd_pcm_ioctl_compat(struct file *file, unsigned int cmd, unsigned l
if (in_x32_syscall())
return snd_pcm_ioctl_sync_ptr_x32(substream, argp);
#endif /* CONFIG_X86_X32 */
- return snd_pcm_common_ioctl(file, substream, cmd, argp);
+ return snd_pcm_ioctl_sync_ptr_buggy(substream, argp);
case SNDRV_PCM_IOCTL_HW_REFINE32:
return snd_pcm_ioctl_hw_params_compat(substream, 1, argp);
case SNDRV_PCM_IOCTL_HW_PARAMS32:
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-08 11:11 ` Takashi Iwai
@ 2021-10-08 11:45 ` Arnd Bergmann
-1 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2021-10-08 11:45 UTC (permalink / raw)
To: musl
Cc: ALSA Development Mailing List, Rich Felker, Arnd Bergmann,
Baolin Wang, y2038 Mailman List, Linux Kernel Mailing List,
Takashi Iwai, Michael Forney, Mark Brown, Baolin Wang
On Fri, Oct 8, 2021 at 1:11 PM Takashi Iwai <tiwai@suse.de> wrote:
> On Fri, 08 Oct 2021 11:24:39 +0200, Arnd Bergmann wrote:
> >
> > I've tried to understand this part of musl's convert_ioctl_struct(), but I just
> > can't figure out whether it does the conversion based the on the layout that
> > is currently used in the kernel, or based on the layout we should have been
> > using, and would use with the above fix. Rich, can you help me here?
>
> So, at this moment, I'm not sure whether we should correct the struct
> at all. This will lead to yet more breakage, and basically the struct
> itself *works* -- the only bug is in 32bit compat handling in the
> kernel (again).
I'm still unsure if the musl fallback code is correct or not.
> The below is a revised kernel patch (again untested), just correcting
> the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
> fine as is, as well as 64bit apps on 64bit kernel.
Right, this should cover all cases of the ioctl itself misbehaving.
In addition, we still need to disallow the mmap() interface on compat
kernels then. Strictly speaking, we could allow the snd_pcm_mmap_status
but not snd_pcm_mmap_control to be mapped, but I'm not sure if
that's better than disallowing both.
Arnd
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-08 11:45 ` Arnd Bergmann
0 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2021-10-08 11:45 UTC (permalink / raw)
To: musl
Cc: Arnd Bergmann, Rich Felker, Michael Forney,
ALSA Development Mailing List, Takashi Iwai, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, Mark Brown,
Baolin Wang
On Fri, Oct 8, 2021 at 1:11 PM Takashi Iwai <tiwai@suse.de> wrote:
> On Fri, 08 Oct 2021 11:24:39 +0200, Arnd Bergmann wrote:
> >
> > I've tried to understand this part of musl's convert_ioctl_struct(), but I just
> > can't figure out whether it does the conversion based the on the layout that
> > is currently used in the kernel, or based on the layout we should have been
> > using, and would use with the above fix. Rich, can you help me here?
>
> So, at this moment, I'm not sure whether we should correct the struct
> at all. This will lead to yet more breakage, and basically the struct
> itself *works* -- the only bug is in 32bit compat handling in the
> kernel (again).
I'm still unsure if the musl fallback code is correct or not.
> The below is a revised kernel patch (again untested), just correcting
> the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
> fine as is, as well as 64bit apps on 64bit kernel.
Right, this should cover all cases of the ioctl itself misbehaving.
In addition, we still need to disallow the mmap() interface on compat
kernels then. Strictly speaking, we could allow the snd_pcm_mmap_status
but not snd_pcm_mmap_control to be mapped, but I'm not sure if
that's better than disallowing both.
Arnd
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-08 11:45 ` Arnd Bergmann
@ 2021-10-08 11:53 ` Takashi Iwai
-1 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2021-10-08 11:53 UTC (permalink / raw)
To: Arnd Bergmann
Cc: musl, Rich Felker, Michael Forney, ALSA Development Mailing List,
Takashi Iwai, Baolin Wang, y2038 Mailman List,
Linux Kernel Mailing List, Mark Brown, Baolin Wang
On Fri, 08 Oct 2021 13:45:45 +0200,
Arnd Bergmann wrote:
>
> On Fri, Oct 8, 2021 at 1:11 PM Takashi Iwai <tiwai@suse.de> wrote:
> > On Fri, 08 Oct 2021 11:24:39 +0200, Arnd Bergmann wrote:
>
> > >
> > > I've tried to understand this part of musl's convert_ioctl_struct(), but I just
> > > can't figure out whether it does the conversion based the on the layout that
> > > is currently used in the kernel, or based on the layout we should have been
> > > using, and would use with the above fix. Rich, can you help me here?
> >
> > So, at this moment, I'm not sure whether we should correct the struct
> > at all. This will lead to yet more breakage, and basically the struct
> > itself *works* -- the only bug is in 32bit compat handling in the
> > kernel (again).
>
> I'm still unsure if the musl fallback code is correct or not.
We need to verify the current behavior in anyway...
> > The below is a revised kernel patch (again untested), just correcting
> > the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
> > fine as is, as well as 64bit apps on 64bit kernel.
>
> Right, this should cover all cases of the ioctl itself misbehaving.
> In addition, we still need to disallow the mmap() interface on compat
> kernels then. Strictly speaking, we could allow the snd_pcm_mmap_status
> but not snd_pcm_mmap_control to be mapped, but I'm not sure if
> that's better than disallowing both.
IIRC, the compat mmap is already disallowed even for the
SNDRV_PCM_MMAP_OFFSET_CONTROL_NEW (in pcm_control_mmap_allowed()), so
no need to change around that.
thanks,
Takashi
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-08 11:53 ` Takashi Iwai
0 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2021-10-08 11:53 UTC (permalink / raw)
To: Arnd Bergmann
Cc: ALSA Development Mailing List, Rich Felker, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, musl,
Takashi Iwai, Michael Forney, Mark Brown, Baolin Wang
On Fri, 08 Oct 2021 13:45:45 +0200,
Arnd Bergmann wrote:
>
> On Fri, Oct 8, 2021 at 1:11 PM Takashi Iwai <tiwai@suse.de> wrote:
> > On Fri, 08 Oct 2021 11:24:39 +0200, Arnd Bergmann wrote:
>
> > >
> > > I've tried to understand this part of musl's convert_ioctl_struct(), but I just
> > > can't figure out whether it does the conversion based the on the layout that
> > > is currently used in the kernel, or based on the layout we should have been
> > > using, and would use with the above fix. Rich, can you help me here?
> >
> > So, at this moment, I'm not sure whether we should correct the struct
> > at all. This will lead to yet more breakage, and basically the struct
> > itself *works* -- the only bug is in 32bit compat handling in the
> > kernel (again).
>
> I'm still unsure if the musl fallback code is correct or not.
We need to verify the current behavior in anyway...
> > The below is a revised kernel patch (again untested), just correcting
> > the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
> > fine as is, as well as 64bit apps on 64bit kernel.
>
> Right, this should cover all cases of the ioctl itself misbehaving.
> In addition, we still need to disallow the mmap() interface on compat
> kernels then. Strictly speaking, we could allow the snd_pcm_mmap_status
> but not snd_pcm_mmap_control to be mapped, but I'm not sure if
> that's better than disallowing both.
IIRC, the compat mmap is already disallowed even for the
SNDRV_PCM_MMAP_OFFSET_CONTROL_NEW (in pcm_control_mmap_allowed()), so
no need to change around that.
thanks,
Takashi
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-08 11:53 ` Takashi Iwai
@ 2021-10-08 12:13 ` Arnd Bergmann
-1 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2021-10-08 12:13 UTC (permalink / raw)
To: musl
Cc: Arnd Bergmann, Rich Felker, Michael Forney,
ALSA Development Mailing List, Takashi Iwai, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, Mark Brown,
Baolin Wang
On Fri, Oct 8, 2021 at 1:53 PM Takashi Iwai <tiwai@suse.de> wrote:
> On Fri, 08 Oct 2021 13:45:45 +0200, Arnd Bergmann wrote:
> > On Fri, Oct 8, 2021 at 1:11 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > On Fri, 08 Oct 2021 11:24:39 +0200, Arnd Bergmann wrote:
> > > The below is a revised kernel patch (again untested), just correcting
> > > the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
> > > fine as is, as well as 64bit apps on 64bit kernel.
> >
> > Right, this should cover all cases of the ioctl itself misbehaving.
> > In addition, we still need to disallow the mmap() interface on compat
> > kernels then. Strictly speaking, we could allow the snd_pcm_mmap_status
> > but not snd_pcm_mmap_control to be mapped, but I'm not sure if
> > that's better than disallowing both.
>
> IIRC, the compat mmap is already disallowed even for the
> SNDRV_PCM_MMAP_OFFSET_CONTROL_NEW (in pcm_control_mmap_allowed()), so
> no need to change around that.
Ah, right. I think it was meant to become allowed as part of commit
80fe7430c708 ("ALSA: add new 32-bit layout for snd_pcm_mmap_status/control"),
which did allow the snd_pcm_mmap_status to be mmap()ed, but it appears
to be the rare case where two mistakes cancel out and we don't have to
change the mmap code.
Arnd
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-08 12:13 ` Arnd Bergmann
0 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2021-10-08 12:13 UTC (permalink / raw)
To: musl
Cc: ALSA Development Mailing List, Rich Felker, Arnd Bergmann,
Baolin Wang, y2038 Mailman List, Linux Kernel Mailing List,
Takashi Iwai, Michael Forney, Mark Brown, Baolin Wang
On Fri, Oct 8, 2021 at 1:53 PM Takashi Iwai <tiwai@suse.de> wrote:
> On Fri, 08 Oct 2021 13:45:45 +0200, Arnd Bergmann wrote:
> > On Fri, Oct 8, 2021 at 1:11 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > On Fri, 08 Oct 2021 11:24:39 +0200, Arnd Bergmann wrote:
> > > The below is a revised kernel patch (again untested), just correcting
> > > the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
> > > fine as is, as well as 64bit apps on 64bit kernel.
> >
> > Right, this should cover all cases of the ioctl itself misbehaving.
> > In addition, we still need to disallow the mmap() interface on compat
> > kernels then. Strictly speaking, we could allow the snd_pcm_mmap_status
> > but not snd_pcm_mmap_control to be mapped, but I'm not sure if
> > that's better than disallowing both.
>
> IIRC, the compat mmap is already disallowed even for the
> SNDRV_PCM_MMAP_OFFSET_CONTROL_NEW (in pcm_control_mmap_allowed()), so
> no need to change around that.
Ah, right. I think it was meant to become allowed as part of commit
80fe7430c708 ("ALSA: add new 32-bit layout for snd_pcm_mmap_status/control"),
which did allow the snd_pcm_mmap_status to be mmap()ed, but it appears
to be the rare case where two mistakes cancel out and we don't have to
change the mmap code.
Arnd
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-08 11:11 ` Takashi Iwai
@ 2021-10-08 12:07 ` Rich Felker
-1 siblings, 0 replies; 94+ messages in thread
From: Rich Felker @ 2021-10-08 12:07 UTC (permalink / raw)
To: Takashi Iwai
Cc: Arnd Bergmann, musl, Michael Forney,
ALSA Development Mailing List, Takashi Iwai, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, Mark Brown,
Baolin Wang
On Fri, Oct 08, 2021 at 01:11:34PM +0200, Takashi Iwai wrote:
> On Fri, 08 Oct 2021 11:24:39 +0200,
> Arnd Bergmann wrote:
> >
> > On Fri, Oct 8, 2021 at 10:43 AM Takashi Iwai <tiwai@suse.de> wrote:
> > > On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote:
> > > > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> > >
> > > @@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
> > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> > > typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > typedef char __pad_after_uframe[0];
> > > +typedef char __pad_before_u32[4];
> > > +typedef char __pad_after_u32[0];
> > > #endif
> > >
> > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> > > typedef char __pad_before_uframe[0];
> > > typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > +typedef char __pad_before_u32[0];
> > > +typedef char __pad_after_u32[4];
> > > #endif
> >
> > I think these should remain unchanged, the complex expression was intentionally
> > done so the structures are laid out the same way on 64-bit
> > architectures, so that
> > the kernel can use the __SND_STRUCT_TIME64 path internally on both 32-bit
> > and 64-bit architectures.
>
> That was explicitly defined, but OK, this isn't necessarily defined
> here.
>
> > > @@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
> > > memset(&sync_ptr, 0, sizeof(sync_ptr));
> > > if (get_user(sync_ptr.flags, (unsigned __user *)&(_sync_ptr->flags)))
> > > return -EFAULT;
> > > - if (copy_from_user(&sync_ptr.c.control, &(_sync_ptr->c.control), sizeof(struct snd_pcm_mmap_control)))
> > > - return -EFAULT;
> > > + if (buggy_control) {
> > > + if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
> > > + &(_sync_ptr->c.control_api_2_0_15),
> > > + sizeof(sync_ptr.c.control_api_2_0_15)))
> > > + return -EFAULT;
> > > + } else {
> > > + if (copy_from_user(&sync_ptr.c.control,
> > > + &(_sync_ptr->c.control),
> > > + sizeof(sync_ptr.c.control)))
> > > + return -EFAULT;
> > > + }
> >
> > The problem I see with this is that it might break musl's ability to
> > emulate the new
> > interface on top of the old (time32) one for linux-4.x and older
> > kernels, as the conversion
> > function is no longer stateless but has to know the negotiated
> > interface version.
> >
> > It's probably fine as long as we can be sure that the 2.0.16+ API
> > version only gets
> > negotiated if both the kernel and user sides support it, and musl only emulates
> > the 2.0.15 API version from the current kernels.
> >
> > I've tried to understand this part of musl's convert_ioctl_struct(), but I just
> > can't figure out whether it does the conversion based the on the layout that
> > is currently used in the kernel, or based on the layout we should have been
> > using, and would use with the above fix. Rich, can you help me here?
>
> So, at this moment, I'm not sure whether we should correct the struct
> at all. This will lead to yet more breakage, and basically the struct
> itself *works* -- the only bug is in 32bit compat handling in the
> kernel (again).
>
> The below is a revised kernel patch (again untested), just correcting
> the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
> fine as is, as well as 64bit apps on 64bit kernel.
I'm perfectly okay with this if Arnd is! It's probably the least
invasive and has the least long-term maintenance cost and fallout on
other projects.
Rich
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-08 12:07 ` Rich Felker
0 siblings, 0 replies; 94+ messages in thread
From: Rich Felker @ 2021-10-08 12:07 UTC (permalink / raw)
To: Takashi Iwai
Cc: ALSA Development Mailing List, Arnd Bergmann, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, musl,
Takashi Iwai, Michael Forney, Mark Brown, Baolin Wang
On Fri, Oct 08, 2021 at 01:11:34PM +0200, Takashi Iwai wrote:
> On Fri, 08 Oct 2021 11:24:39 +0200,
> Arnd Bergmann wrote:
> >
> > On Fri, Oct 8, 2021 at 10:43 AM Takashi Iwai <tiwai@suse.de> wrote:
> > > On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote:
> > > > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> > >
> > > @@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
> > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> > > typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > typedef char __pad_after_uframe[0];
> > > +typedef char __pad_before_u32[4];
> > > +typedef char __pad_after_u32[0];
> > > #endif
> > >
> > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> > > typedef char __pad_before_uframe[0];
> > > typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > +typedef char __pad_before_u32[0];
> > > +typedef char __pad_after_u32[4];
> > > #endif
> >
> > I think these should remain unchanged, the complex expression was intentionally
> > done so the structures are laid out the same way on 64-bit
> > architectures, so that
> > the kernel can use the __SND_STRUCT_TIME64 path internally on both 32-bit
> > and 64-bit architectures.
>
> That was explicitly defined, but OK, this isn't necessarily defined
> here.
>
> > > @@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
> > > memset(&sync_ptr, 0, sizeof(sync_ptr));
> > > if (get_user(sync_ptr.flags, (unsigned __user *)&(_sync_ptr->flags)))
> > > return -EFAULT;
> > > - if (copy_from_user(&sync_ptr.c.control, &(_sync_ptr->c.control), sizeof(struct snd_pcm_mmap_control)))
> > > - return -EFAULT;
> > > + if (buggy_control) {
> > > + if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
> > > + &(_sync_ptr->c.control_api_2_0_15),
> > > + sizeof(sync_ptr.c.control_api_2_0_15)))
> > > + return -EFAULT;
> > > + } else {
> > > + if (copy_from_user(&sync_ptr.c.control,
> > > + &(_sync_ptr->c.control),
> > > + sizeof(sync_ptr.c.control)))
> > > + return -EFAULT;
> > > + }
> >
> > The problem I see with this is that it might break musl's ability to
> > emulate the new
> > interface on top of the old (time32) one for linux-4.x and older
> > kernels, as the conversion
> > function is no longer stateless but has to know the negotiated
> > interface version.
> >
> > It's probably fine as long as we can be sure that the 2.0.16+ API
> > version only gets
> > negotiated if both the kernel and user sides support it, and musl only emulates
> > the 2.0.15 API version from the current kernels.
> >
> > I've tried to understand this part of musl's convert_ioctl_struct(), but I just
> > can't figure out whether it does the conversion based the on the layout that
> > is currently used in the kernel, or based on the layout we should have been
> > using, and would use with the above fix. Rich, can you help me here?
>
> So, at this moment, I'm not sure whether we should correct the struct
> at all. This will lead to yet more breakage, and basically the struct
> itself *works* -- the only bug is in 32bit compat handling in the
> kernel (again).
>
> The below is a revised kernel patch (again untested), just correcting
> the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
> fine as is, as well as 64bit apps on 64bit kernel.
I'm perfectly okay with this if Arnd is! It's probably the least
invasive and has the least long-term maintenance cost and fallout on
other projects.
Rich
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-08 12:07 ` Rich Felker
@ 2021-10-10 7:53 ` Takashi Iwai
-1 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2021-10-10 7:53 UTC (permalink / raw)
To: Rich Felker
Cc: ALSA Development Mailing List, Arnd Bergmann, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, musl,
Takashi Iwai, Michael Forney, Mark Brown, Baolin Wang
On Fri, 08 Oct 2021 14:07:39 +0200,
Rich Felker wrote:
>
> On Fri, Oct 08, 2021 at 01:11:34PM +0200, Takashi Iwai wrote:
> > On Fri, 08 Oct 2021 11:24:39 +0200,
> > Arnd Bergmann wrote:
> > >
> > > On Fri, Oct 8, 2021 at 10:43 AM Takashi Iwai <tiwai@suse.de> wrote:
> > > > On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote:
> > > > > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> > > >
> > > > @@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
> > > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> > > > typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > > typedef char __pad_after_uframe[0];
> > > > +typedef char __pad_before_u32[4];
> > > > +typedef char __pad_after_u32[0];
> > > > #endif
> > > >
> > > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> > > > typedef char __pad_before_uframe[0];
> > > > typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > > +typedef char __pad_before_u32[0];
> > > > +typedef char __pad_after_u32[4];
> > > > #endif
> > >
> > > I think these should remain unchanged, the complex expression was intentionally
> > > done so the structures are laid out the same way on 64-bit
> > > architectures, so that
> > > the kernel can use the __SND_STRUCT_TIME64 path internally on both 32-bit
> > > and 64-bit architectures.
> >
> > That was explicitly defined, but OK, this isn't necessarily defined
> > here.
> >
> > > > @@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
> > > > memset(&sync_ptr, 0, sizeof(sync_ptr));
> > > > if (get_user(sync_ptr.flags, (unsigned __user *)&(_sync_ptr->flags)))
> > > > return -EFAULT;
> > > > - if (copy_from_user(&sync_ptr.c.control, &(_sync_ptr->c.control), sizeof(struct snd_pcm_mmap_control)))
> > > > - return -EFAULT;
> > > > + if (buggy_control) {
> > > > + if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
> > > > + &(_sync_ptr->c.control_api_2_0_15),
> > > > + sizeof(sync_ptr.c.control_api_2_0_15)))
> > > > + return -EFAULT;
> > > > + } else {
> > > > + if (copy_from_user(&sync_ptr.c.control,
> > > > + &(_sync_ptr->c.control),
> > > > + sizeof(sync_ptr.c.control)))
> > > > + return -EFAULT;
> > > > + }
> > >
> > > The problem I see with this is that it might break musl's ability to
> > > emulate the new
> > > interface on top of the old (time32) one for linux-4.x and older
> > > kernels, as the conversion
> > > function is no longer stateless but has to know the negotiated
> > > interface version.
> > >
> > > It's probably fine as long as we can be sure that the 2.0.16+ API
> > > version only gets
> > > negotiated if both the kernel and user sides support it, and musl only emulates
> > > the 2.0.15 API version from the current kernels.
> > >
> > > I've tried to understand this part of musl's convert_ioctl_struct(), but I just
> > > can't figure out whether it does the conversion based the on the layout that
> > > is currently used in the kernel, or based on the layout we should have been
> > > using, and would use with the above fix. Rich, can you help me here?
> >
> > So, at this moment, I'm not sure whether we should correct the struct
> > at all. This will lead to yet more breakage, and basically the struct
> > itself *works* -- the only bug is in 32bit compat handling in the
> > kernel (again).
> >
> > The below is a revised kernel patch (again untested), just correcting
> > the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
> > fine as is, as well as 64bit apps on 64bit kernel.
>
> I'm perfectly okay with this if Arnd is! It's probably the least
> invasive and has the least long-term maintenance cost and fallout on
> other projects.
OK, I'll submit a proper patch now, to be included in the next PR for
5.15-rc. For further fixes, let's think carefully.
thanks,
Takashi
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-10 7:53 ` Takashi Iwai
0 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2021-10-10 7:53 UTC (permalink / raw)
To: Rich Felker
Cc: Arnd Bergmann, musl, Michael Forney,
ALSA Development Mailing List, Takashi Iwai, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, Mark Brown,
Baolin Wang
On Fri, 08 Oct 2021 14:07:39 +0200,
Rich Felker wrote:
>
> On Fri, Oct 08, 2021 at 01:11:34PM +0200, Takashi Iwai wrote:
> > On Fri, 08 Oct 2021 11:24:39 +0200,
> > Arnd Bergmann wrote:
> > >
> > > On Fri, Oct 8, 2021 at 10:43 AM Takashi Iwai <tiwai@suse.de> wrote:
> > > > On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote:
> > > > > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> > > >
> > > > @@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
> > > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> > > > typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > > typedef char __pad_after_uframe[0];
> > > > +typedef char __pad_before_u32[4];
> > > > +typedef char __pad_after_u32[0];
> > > > #endif
> > > >
> > > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> > > > typedef char __pad_before_uframe[0];
> > > > typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > > +typedef char __pad_before_u32[0];
> > > > +typedef char __pad_after_u32[4];
> > > > #endif
> > >
> > > I think these should remain unchanged, the complex expression was intentionally
> > > done so the structures are laid out the same way on 64-bit
> > > architectures, so that
> > > the kernel can use the __SND_STRUCT_TIME64 path internally on both 32-bit
> > > and 64-bit architectures.
> >
> > That was explicitly defined, but OK, this isn't necessarily defined
> > here.
> >
> > > > @@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
> > > > memset(&sync_ptr, 0, sizeof(sync_ptr));
> > > > if (get_user(sync_ptr.flags, (unsigned __user *)&(_sync_ptr->flags)))
> > > > return -EFAULT;
> > > > - if (copy_from_user(&sync_ptr.c.control, &(_sync_ptr->c.control), sizeof(struct snd_pcm_mmap_control)))
> > > > - return -EFAULT;
> > > > + if (buggy_control) {
> > > > + if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
> > > > + &(_sync_ptr->c.control_api_2_0_15),
> > > > + sizeof(sync_ptr.c.control_api_2_0_15)))
> > > > + return -EFAULT;
> > > > + } else {
> > > > + if (copy_from_user(&sync_ptr.c.control,
> > > > + &(_sync_ptr->c.control),
> > > > + sizeof(sync_ptr.c.control)))
> > > > + return -EFAULT;
> > > > + }
> > >
> > > The problem I see with this is that it might break musl's ability to
> > > emulate the new
> > > interface on top of the old (time32) one for linux-4.x and older
> > > kernels, as the conversion
> > > function is no longer stateless but has to know the negotiated
> > > interface version.
> > >
> > > It's probably fine as long as we can be sure that the 2.0.16+ API
> > > version only gets
> > > negotiated if both the kernel and user sides support it, and musl only emulates
> > > the 2.0.15 API version from the current kernels.
> > >
> > > I've tried to understand this part of musl's convert_ioctl_struct(), but I just
> > > can't figure out whether it does the conversion based the on the layout that
> > > is currently used in the kernel, or based on the layout we should have been
> > > using, and would use with the above fix. Rich, can you help me here?
> >
> > So, at this moment, I'm not sure whether we should correct the struct
> > at all. This will lead to yet more breakage, and basically the struct
> > itself *works* -- the only bug is in 32bit compat handling in the
> > kernel (again).
> >
> > The below is a revised kernel patch (again untested), just correcting
> > the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
> > fine as is, as well as 64bit apps on 64bit kernel.
>
> I'm perfectly okay with this if Arnd is! It's probably the least
> invasive and has the least long-term maintenance cost and fallout on
> other projects.
OK, I'll submit a proper patch now, to be included in the next PR for
5.15-rc. For further fixes, let's think carefully.
thanks,
Takashi
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-10 7:53 ` Takashi Iwai
@ 2021-10-18 14:43 ` Rich Felker
-1 siblings, 0 replies; 94+ messages in thread
From: Rich Felker @ 2021-10-18 14:43 UTC (permalink / raw)
To: Takashi Iwai
Cc: Arnd Bergmann, musl, Michael Forney,
ALSA Development Mailing List, Takashi Iwai, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, Mark Brown,
Baolin Wang
On Sun, Oct 10, 2021 at 09:53:38AM +0200, Takashi Iwai wrote:
> On Fri, 08 Oct 2021 14:07:39 +0200,
> Rich Felker wrote:
> >
> > On Fri, Oct 08, 2021 at 01:11:34PM +0200, Takashi Iwai wrote:
> > > On Fri, 08 Oct 2021 11:24:39 +0200,
> > > Arnd Bergmann wrote:
> > > >
> > > > On Fri, Oct 8, 2021 at 10:43 AM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote:
> > > > > > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> > > > >
> > > > > @@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
> > > > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> > > > > typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > > > typedef char __pad_after_uframe[0];
> > > > > +typedef char __pad_before_u32[4];
> > > > > +typedef char __pad_after_u32[0];
> > > > > #endif
> > > > >
> > > > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> > > > > typedef char __pad_before_uframe[0];
> > > > > typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > > > +typedef char __pad_before_u32[0];
> > > > > +typedef char __pad_after_u32[4];
> > > > > #endif
> > > >
> > > > I think these should remain unchanged, the complex expression was intentionally
> > > > done so the structures are laid out the same way on 64-bit
> > > > architectures, so that
> > > > the kernel can use the __SND_STRUCT_TIME64 path internally on both 32-bit
> > > > and 64-bit architectures.
> > >
> > > That was explicitly defined, but OK, this isn't necessarily defined
> > > here.
> > >
> > > > > @@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
> > > > > memset(&sync_ptr, 0, sizeof(sync_ptr));
> > > > > if (get_user(sync_ptr.flags, (unsigned __user *)&(_sync_ptr->flags)))
> > > > > return -EFAULT;
> > > > > - if (copy_from_user(&sync_ptr.c.control, &(_sync_ptr->c.control), sizeof(struct snd_pcm_mmap_control)))
> > > > > - return -EFAULT;
> > > > > + if (buggy_control) {
> > > > > + if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
> > > > > + &(_sync_ptr->c.control_api_2_0_15),
> > > > > + sizeof(sync_ptr.c.control_api_2_0_15)))
> > > > > + return -EFAULT;
> > > > > + } else {
> > > > > + if (copy_from_user(&sync_ptr.c.control,
> > > > > + &(_sync_ptr->c.control),
> > > > > + sizeof(sync_ptr.c.control)))
> > > > > + return -EFAULT;
> > > > > + }
> > > >
> > > > The problem I see with this is that it might break musl's ability to
> > > > emulate the new
> > > > interface on top of the old (time32) one for linux-4.x and older
> > > > kernels, as the conversion
> > > > function is no longer stateless but has to know the negotiated
> > > > interface version.
> > > >
> > > > It's probably fine as long as we can be sure that the 2.0.16+ API
> > > > version only gets
> > > > negotiated if both the kernel and user sides support it, and musl only emulates
> > > > the 2.0.15 API version from the current kernels.
> > > >
> > > > I've tried to understand this part of musl's convert_ioctl_struct(), but I just
> > > > can't figure out whether it does the conversion based the on the layout that
> > > > is currently used in the kernel, or based on the layout we should have been
> > > > using, and would use with the above fix. Rich, can you help me here?
> > >
> > > So, at this moment, I'm not sure whether we should correct the struct
> > > at all. This will lead to yet more breakage, and basically the struct
> > > itself *works* -- the only bug is in 32bit compat handling in the
> > > kernel (again).
> > >
> > > The below is a revised kernel patch (again untested), just correcting
> > > the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
> > > fine as is, as well as 64bit apps on 64bit kernel.
> >
> > I'm perfectly okay with this if Arnd is! It's probably the least
> > invasive and has the least long-term maintenance cost and fallout on
> > other projects.
>
> OK, I'll submit a proper patch now, to be included in the next PR for
> 5.15-rc. For further fixes, let's think carefully.
Am I correct in my understanding that the fix of keeping the "broken"
definition (and having the 64-bit kernel honor it for 32-bit binaries)
has been accepted? Since musl's translation for pre-time64 kernels
seems to have been using the "non-broken" definition, I think
completing the fix requires a change in musl too.
Rich
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-18 14:43 ` Rich Felker
0 siblings, 0 replies; 94+ messages in thread
From: Rich Felker @ 2021-10-18 14:43 UTC (permalink / raw)
To: Takashi Iwai
Cc: ALSA Development Mailing List, Arnd Bergmann, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, musl,
Takashi Iwai, Michael Forney, Mark Brown, Baolin Wang
On Sun, Oct 10, 2021 at 09:53:38AM +0200, Takashi Iwai wrote:
> On Fri, 08 Oct 2021 14:07:39 +0200,
> Rich Felker wrote:
> >
> > On Fri, Oct 08, 2021 at 01:11:34PM +0200, Takashi Iwai wrote:
> > > On Fri, 08 Oct 2021 11:24:39 +0200,
> > > Arnd Bergmann wrote:
> > > >
> > > > On Fri, Oct 8, 2021 at 10:43 AM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote:
> > > > > > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> > > > >
> > > > > @@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
> > > > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> > > > > typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > > > typedef char __pad_after_uframe[0];
> > > > > +typedef char __pad_before_u32[4];
> > > > > +typedef char __pad_after_u32[0];
> > > > > #endif
> > > > >
> > > > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> > > > > typedef char __pad_before_uframe[0];
> > > > > typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > > > +typedef char __pad_before_u32[0];
> > > > > +typedef char __pad_after_u32[4];
> > > > > #endif
> > > >
> > > > I think these should remain unchanged, the complex expression was intentionally
> > > > done so the structures are laid out the same way on 64-bit
> > > > architectures, so that
> > > > the kernel can use the __SND_STRUCT_TIME64 path internally on both 32-bit
> > > > and 64-bit architectures.
> > >
> > > That was explicitly defined, but OK, this isn't necessarily defined
> > > here.
> > >
> > > > > @@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
> > > > > memset(&sync_ptr, 0, sizeof(sync_ptr));
> > > > > if (get_user(sync_ptr.flags, (unsigned __user *)&(_sync_ptr->flags)))
> > > > > return -EFAULT;
> > > > > - if (copy_from_user(&sync_ptr.c.control, &(_sync_ptr->c.control), sizeof(struct snd_pcm_mmap_control)))
> > > > > - return -EFAULT;
> > > > > + if (buggy_control) {
> > > > > + if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
> > > > > + &(_sync_ptr->c.control_api_2_0_15),
> > > > > + sizeof(sync_ptr.c.control_api_2_0_15)))
> > > > > + return -EFAULT;
> > > > > + } else {
> > > > > + if (copy_from_user(&sync_ptr.c.control,
> > > > > + &(_sync_ptr->c.control),
> > > > > + sizeof(sync_ptr.c.control)))
> > > > > + return -EFAULT;
> > > > > + }
> > > >
> > > > The problem I see with this is that it might break musl's ability to
> > > > emulate the new
> > > > interface on top of the old (time32) one for linux-4.x and older
> > > > kernels, as the conversion
> > > > function is no longer stateless but has to know the negotiated
> > > > interface version.
> > > >
> > > > It's probably fine as long as we can be sure that the 2.0.16+ API
> > > > version only gets
> > > > negotiated if both the kernel and user sides support it, and musl only emulates
> > > > the 2.0.15 API version from the current kernels.
> > > >
> > > > I've tried to understand this part of musl's convert_ioctl_struct(), but I just
> > > > can't figure out whether it does the conversion based the on the layout that
> > > > is currently used in the kernel, or based on the layout we should have been
> > > > using, and would use with the above fix. Rich, can you help me here?
> > >
> > > So, at this moment, I'm not sure whether we should correct the struct
> > > at all. This will lead to yet more breakage, and basically the struct
> > > itself *works* -- the only bug is in 32bit compat handling in the
> > > kernel (again).
> > >
> > > The below is a revised kernel patch (again untested), just correcting
> > > the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
> > > fine as is, as well as 64bit apps on 64bit kernel.
> >
> > I'm perfectly okay with this if Arnd is! It's probably the least
> > invasive and has the least long-term maintenance cost and fallout on
> > other projects.
>
> OK, I'll submit a proper patch now, to be included in the next PR for
> 5.15-rc. For further fixes, let's think carefully.
Am I correct in my understanding that the fix of keeping the "broken"
definition (and having the 64-bit kernel honor it for 32-bit binaries)
has been accepted? Since musl's translation for pre-time64 kernels
seems to have been using the "non-broken" definition, I think
completing the fix requires a change in musl too.
Rich
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-18 14:43 ` Rich Felker
@ 2021-10-18 14:58 ` Takashi Iwai
-1 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2021-10-18 14:58 UTC (permalink / raw)
To: Rich Felker
Cc: Arnd Bergmann, musl, Michael Forney,
ALSA Development Mailing List, Takashi Iwai, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, Mark Brown,
Baolin Wang
On Mon, 18 Oct 2021 16:43:00 +0200,
Rich Felker wrote:
>
> On Sun, Oct 10, 2021 at 09:53:38AM +0200, Takashi Iwai wrote:
> > On Fri, 08 Oct 2021 14:07:39 +0200,
> > Rich Felker wrote:
> > >
> > > On Fri, Oct 08, 2021 at 01:11:34PM +0200, Takashi Iwai wrote:
> > > > On Fri, 08 Oct 2021 11:24:39 +0200,
> > > > Arnd Bergmann wrote:
> > > > >
> > > > > On Fri, Oct 8, 2021 at 10:43 AM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote:
> > > > > > > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> > > > > >
> > > > > > @@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
> > > > > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> > > > > > typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > > > > typedef char __pad_after_uframe[0];
> > > > > > +typedef char __pad_before_u32[4];
> > > > > > +typedef char __pad_after_u32[0];
> > > > > > #endif
> > > > > >
> > > > > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> > > > > > typedef char __pad_before_uframe[0];
> > > > > > typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > > > > +typedef char __pad_before_u32[0];
> > > > > > +typedef char __pad_after_u32[4];
> > > > > > #endif
> > > > >
> > > > > I think these should remain unchanged, the complex expression was intentionally
> > > > > done so the structures are laid out the same way on 64-bit
> > > > > architectures, so that
> > > > > the kernel can use the __SND_STRUCT_TIME64 path internally on both 32-bit
> > > > > and 64-bit architectures.
> > > >
> > > > That was explicitly defined, but OK, this isn't necessarily defined
> > > > here.
> > > >
> > > > > > @@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
> > > > > > memset(&sync_ptr, 0, sizeof(sync_ptr));
> > > > > > if (get_user(sync_ptr.flags, (unsigned __user *)&(_sync_ptr->flags)))
> > > > > > return -EFAULT;
> > > > > > - if (copy_from_user(&sync_ptr.c.control, &(_sync_ptr->c.control), sizeof(struct snd_pcm_mmap_control)))
> > > > > > - return -EFAULT;
> > > > > > + if (buggy_control) {
> > > > > > + if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
> > > > > > + &(_sync_ptr->c.control_api_2_0_15),
> > > > > > + sizeof(sync_ptr.c.control_api_2_0_15)))
> > > > > > + return -EFAULT;
> > > > > > + } else {
> > > > > > + if (copy_from_user(&sync_ptr.c.control,
> > > > > > + &(_sync_ptr->c.control),
> > > > > > + sizeof(sync_ptr.c.control)))
> > > > > > + return -EFAULT;
> > > > > > + }
> > > > >
> > > > > The problem I see with this is that it might break musl's ability to
> > > > > emulate the new
> > > > > interface on top of the old (time32) one for linux-4.x and older
> > > > > kernels, as the conversion
> > > > > function is no longer stateless but has to know the negotiated
> > > > > interface version.
> > > > >
> > > > > It's probably fine as long as we can be sure that the 2.0.16+ API
> > > > > version only gets
> > > > > negotiated if both the kernel and user sides support it, and musl only emulates
> > > > > the 2.0.15 API version from the current kernels.
> > > > >
> > > > > I've tried to understand this part of musl's convert_ioctl_struct(), but I just
> > > > > can't figure out whether it does the conversion based the on the layout that
> > > > > is currently used in the kernel, or based on the layout we should have been
> > > > > using, and would use with the above fix. Rich, can you help me here?
> > > >
> > > > So, at this moment, I'm not sure whether we should correct the struct
> > > > at all. This will lead to yet more breakage, and basically the struct
> > > > itself *works* -- the only bug is in 32bit compat handling in the
> > > > kernel (again).
> > > >
> > > > The below is a revised kernel patch (again untested), just correcting
> > > > the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
> > > > fine as is, as well as 64bit apps on 64bit kernel.
> > >
> > > I'm perfectly okay with this if Arnd is! It's probably the least
> > > invasive and has the least long-term maintenance cost and fallout on
> > > other projects.
> >
> > OK, I'll submit a proper patch now, to be included in the next PR for
> > 5.15-rc. For further fixes, let's think carefully.
>
> Am I correct in my understanding that the fix of keeping the "broken"
> definition (and having the 64-bit kernel honor it for 32-bit binaries)
> has been accepted?
Yes, as it was already set in stone, we accept the broken definition
as is.
> Since musl's translation for pre-time64 kernels
> seems to have been using the "non-broken" definition, I think
> completing the fix requires a change in musl too.
Hm, musl translator contains the own definition of ioctl?
If so, we may reconsider about renumbering ioctls altogether.
Suppose musl having a fallback to the old ioctl, the possible breakage
by old kernels (that don't support renewed ioctls) would be minimal,
right?
Takashi
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-18 14:58 ` Takashi Iwai
0 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2021-10-18 14:58 UTC (permalink / raw)
To: Rich Felker
Cc: ALSA Development Mailing List, Arnd Bergmann, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, musl,
Takashi Iwai, Michael Forney, Mark Brown, Baolin Wang
On Mon, 18 Oct 2021 16:43:00 +0200,
Rich Felker wrote:
>
> On Sun, Oct 10, 2021 at 09:53:38AM +0200, Takashi Iwai wrote:
> > On Fri, 08 Oct 2021 14:07:39 +0200,
> > Rich Felker wrote:
> > >
> > > On Fri, Oct 08, 2021 at 01:11:34PM +0200, Takashi Iwai wrote:
> > > > On Fri, 08 Oct 2021 11:24:39 +0200,
> > > > Arnd Bergmann wrote:
> > > > >
> > > > > On Fri, Oct 8, 2021 at 10:43 AM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote:
> > > > > > > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> > > > > >
> > > > > > @@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
> > > > > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> > > > > > typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > > > > typedef char __pad_after_uframe[0];
> > > > > > +typedef char __pad_before_u32[4];
> > > > > > +typedef char __pad_after_u32[0];
> > > > > > #endif
> > > > > >
> > > > > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> > > > > > typedef char __pad_before_uframe[0];
> > > > > > typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > > > > +typedef char __pad_before_u32[0];
> > > > > > +typedef char __pad_after_u32[4];
> > > > > > #endif
> > > > >
> > > > > I think these should remain unchanged, the complex expression was intentionally
> > > > > done so the structures are laid out the same way on 64-bit
> > > > > architectures, so that
> > > > > the kernel can use the __SND_STRUCT_TIME64 path internally on both 32-bit
> > > > > and 64-bit architectures.
> > > >
> > > > That was explicitly defined, but OK, this isn't necessarily defined
> > > > here.
> > > >
> > > > > > @@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
> > > > > > memset(&sync_ptr, 0, sizeof(sync_ptr));
> > > > > > if (get_user(sync_ptr.flags, (unsigned __user *)&(_sync_ptr->flags)))
> > > > > > return -EFAULT;
> > > > > > - if (copy_from_user(&sync_ptr.c.control, &(_sync_ptr->c.control), sizeof(struct snd_pcm_mmap_control)))
> > > > > > - return -EFAULT;
> > > > > > + if (buggy_control) {
> > > > > > + if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
> > > > > > + &(_sync_ptr->c.control_api_2_0_15),
> > > > > > + sizeof(sync_ptr.c.control_api_2_0_15)))
> > > > > > + return -EFAULT;
> > > > > > + } else {
> > > > > > + if (copy_from_user(&sync_ptr.c.control,
> > > > > > + &(_sync_ptr->c.control),
> > > > > > + sizeof(sync_ptr.c.control)))
> > > > > > + return -EFAULT;
> > > > > > + }
> > > > >
> > > > > The problem I see with this is that it might break musl's ability to
> > > > > emulate the new
> > > > > interface on top of the old (time32) one for linux-4.x and older
> > > > > kernels, as the conversion
> > > > > function is no longer stateless but has to know the negotiated
> > > > > interface version.
> > > > >
> > > > > It's probably fine as long as we can be sure that the 2.0.16+ API
> > > > > version only gets
> > > > > negotiated if both the kernel and user sides support it, and musl only emulates
> > > > > the 2.0.15 API version from the current kernels.
> > > > >
> > > > > I've tried to understand this part of musl's convert_ioctl_struct(), but I just
> > > > > can't figure out whether it does the conversion based the on the layout that
> > > > > is currently used in the kernel, or based on the layout we should have been
> > > > > using, and would use with the above fix. Rich, can you help me here?
> > > >
> > > > So, at this moment, I'm not sure whether we should correct the struct
> > > > at all. This will lead to yet more breakage, and basically the struct
> > > > itself *works* -- the only bug is in 32bit compat handling in the
> > > > kernel (again).
> > > >
> > > > The below is a revised kernel patch (again untested), just correcting
> > > > the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
> > > > fine as is, as well as 64bit apps on 64bit kernel.
> > >
> > > I'm perfectly okay with this if Arnd is! It's probably the least
> > > invasive and has the least long-term maintenance cost and fallout on
> > > other projects.
> >
> > OK, I'll submit a proper patch now, to be included in the next PR for
> > 5.15-rc. For further fixes, let's think carefully.
>
> Am I correct in my understanding that the fix of keeping the "broken"
> definition (and having the 64-bit kernel honor it for 32-bit binaries)
> has been accepted?
Yes, as it was already set in stone, we accept the broken definition
as is.
> Since musl's translation for pre-time64 kernels
> seems to have been using the "non-broken" definition, I think
> completing the fix requires a change in musl too.
Hm, musl translator contains the own definition of ioctl?
If so, we may reconsider about renumbering ioctls altogether.
Suppose musl having a fallback to the old ioctl, the possible breakage
by old kernels (that don't support renewed ioctls) would be minimal,
right?
Takashi
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-18 14:58 ` Takashi Iwai
@ 2021-10-18 15:08 ` Rich Felker
-1 siblings, 0 replies; 94+ messages in thread
From: Rich Felker @ 2021-10-18 15:08 UTC (permalink / raw)
To: Takashi Iwai
Cc: Arnd Bergmann, musl, Michael Forney,
ALSA Development Mailing List, Takashi Iwai, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, Mark Brown,
Baolin Wang
[-- Attachment #1: Type: text/plain, Size: 6154 bytes --]
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:
> >
> > On Sun, Oct 10, 2021 at 09:53:38AM +0200, Takashi Iwai wrote:
> > > On Fri, 08 Oct 2021 14:07:39 +0200,
> > > Rich Felker wrote:
> > > >
> > > > On Fri, Oct 08, 2021 at 01:11:34PM +0200, Takashi Iwai wrote:
> > > > > On Fri, 08 Oct 2021 11:24:39 +0200,
> > > > > Arnd Bergmann wrote:
> > > > > >
> > > > > > On Fri, Oct 8, 2021 at 10:43 AM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote:
> > > > > > > > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> > > > > > >
> > > > > > > @@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
> > > > > > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> > > > > > > typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > > > > > typedef char __pad_after_uframe[0];
> > > > > > > +typedef char __pad_before_u32[4];
> > > > > > > +typedef char __pad_after_u32[0];
> > > > > > > #endif
> > > > > > >
> > > > > > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> > > > > > > typedef char __pad_before_uframe[0];
> > > > > > > typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > > > > > +typedef char __pad_before_u32[0];
> > > > > > > +typedef char __pad_after_u32[4];
> > > > > > > #endif
> > > > > >
> > > > > > I think these should remain unchanged, the complex expression was intentionally
> > > > > > done so the structures are laid out the same way on 64-bit
> > > > > > architectures, so that
> > > > > > the kernel can use the __SND_STRUCT_TIME64 path internally on both 32-bit
> > > > > > and 64-bit architectures.
> > > > >
> > > > > That was explicitly defined, but OK, this isn't necessarily defined
> > > > > here.
> > > > >
> > > > > > > @@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
> > > > > > > memset(&sync_ptr, 0, sizeof(sync_ptr));
> > > > > > > if (get_user(sync_ptr.flags, (unsigned __user *)&(_sync_ptr->flags)))
> > > > > > > return -EFAULT;
> > > > > > > - if (copy_from_user(&sync_ptr.c.control, &(_sync_ptr->c.control), sizeof(struct snd_pcm_mmap_control)))
> > > > > > > - return -EFAULT;
> > > > > > > + if (buggy_control) {
> > > > > > > + if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
> > > > > > > + &(_sync_ptr->c.control_api_2_0_15),
> > > > > > > + sizeof(sync_ptr.c.control_api_2_0_15)))
> > > > > > > + return -EFAULT;
> > > > > > > + } else {
> > > > > > > + if (copy_from_user(&sync_ptr.c.control,
> > > > > > > + &(_sync_ptr->c.control),
> > > > > > > + sizeof(sync_ptr.c.control)))
> > > > > > > + return -EFAULT;
> > > > > > > + }
> > > > > >
> > > > > > The problem I see with this is that it might break musl's ability to
> > > > > > emulate the new
> > > > > > interface on top of the old (time32) one for linux-4.x and older
> > > > > > kernels, as the conversion
> > > > > > function is no longer stateless but has to know the negotiated
> > > > > > interface version.
> > > > > >
> > > > > > It's probably fine as long as we can be sure that the 2.0.16+ API
> > > > > > version only gets
> > > > > > negotiated if both the kernel and user sides support it, and musl only emulates
> > > > > > the 2.0.15 API version from the current kernels.
> > > > > >
> > > > > > I've tried to understand this part of musl's convert_ioctl_struct(), but I just
> > > > > > can't figure out whether it does the conversion based the on the layout that
> > > > > > is currently used in the kernel, or based on the layout we should have been
> > > > > > using, and would use with the above fix. Rich, can you help me here?
> > > > >
> > > > > So, at this moment, I'm not sure whether we should correct the struct
> > > > > at all. This will lead to yet more breakage, and basically the struct
> > > > > itself *works* -- the only bug is in 32bit compat handling in the
> > > > > kernel (again).
> > > > >
> > > > > The below is a revised kernel patch (again untested), just correcting
> > > > > the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
> > > > > fine as is, as well as 64bit apps on 64bit kernel.
> > > >
> > > > I'm perfectly okay with this if Arnd is! It's probably the least
> > > > invasive and has the least long-term maintenance cost and fallout on
> > > > other projects.
> > >
> > > OK, I'll submit a proper patch now, to be included in the next PR for
> > > 5.15-rc. For further fixes, let's think carefully.
> >
> > Am I correct in my understanding that the fix of keeping the "broken"
> > definition (and having the 64-bit kernel honor it for 32-bit binaries)
> > has been accepted?
>
> Yes, as it was already set in stone, we accept the broken definition
> as is.
>
> > Since musl's translation for pre-time64 kernels
> > seems to have been using the "non-broken" definition, I think
> > completing the fix requires a change in musl too.
>
> Hm, musl translator contains the own definition of ioctl?
>
> If so, we may reconsider about renumbering ioctls altogether.
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.
Rich
[-- Attachment #2: musl_snd_pcm_mmap_control.diff --]
[-- Type: text/plain, Size: 898 bytes --]
diff --git a/src/misc/ioctl.c b/src/misc/ioctl.c
index 49282811..6d3e5095 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)
@@ -90,7 +91,14 @@ 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);
+ 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);
+ } else {
+ memcpy(new+72+adj, old+68, 4);
+ memcpy(new+72+4+2*adj, old+72, 4);
+ }
return;
}
for (int i=0; i < map->noffs; i++) {
^ permalink raw reply related [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-18 15:08 ` Rich Felker
0 siblings, 0 replies; 94+ messages in thread
From: Rich Felker @ 2021-10-18 15:08 UTC (permalink / raw)
To: Takashi Iwai
Cc: ALSA Development Mailing List, Arnd Bergmann, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, musl,
Takashi Iwai, Michael Forney, Mark Brown, Baolin Wang
[-- Attachment #1: Type: text/plain, Size: 6154 bytes --]
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:
> >
> > On Sun, Oct 10, 2021 at 09:53:38AM +0200, Takashi Iwai wrote:
> > > On Fri, 08 Oct 2021 14:07:39 +0200,
> > > Rich Felker wrote:
> > > >
> > > > On Fri, Oct 08, 2021 at 01:11:34PM +0200, Takashi Iwai wrote:
> > > > > On Fri, 08 Oct 2021 11:24:39 +0200,
> > > > > Arnd Bergmann wrote:
> > > > > >
> > > > > > On Fri, Oct 8, 2021 at 10:43 AM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote:
> > > > > > > > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> > > > > > >
> > > > > > > @@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
> > > > > > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> > > > > > > typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > > > > > typedef char __pad_after_uframe[0];
> > > > > > > +typedef char __pad_before_u32[4];
> > > > > > > +typedef char __pad_after_u32[0];
> > > > > > > #endif
> > > > > > >
> > > > > > > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> > > > > > > typedef char __pad_before_uframe[0];
> > > > > > > typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > > > > > > +typedef char __pad_before_u32[0];
> > > > > > > +typedef char __pad_after_u32[4];
> > > > > > > #endif
> > > > > >
> > > > > > I think these should remain unchanged, the complex expression was intentionally
> > > > > > done so the structures are laid out the same way on 64-bit
> > > > > > architectures, so that
> > > > > > the kernel can use the __SND_STRUCT_TIME64 path internally on both 32-bit
> > > > > > and 64-bit architectures.
> > > > >
> > > > > That was explicitly defined, but OK, this isn't necessarily defined
> > > > > here.
> > > > >
> > > > > > > @@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
> > > > > > > memset(&sync_ptr, 0, sizeof(sync_ptr));
> > > > > > > if (get_user(sync_ptr.flags, (unsigned __user *)&(_sync_ptr->flags)))
> > > > > > > return -EFAULT;
> > > > > > > - if (copy_from_user(&sync_ptr.c.control, &(_sync_ptr->c.control), sizeof(struct snd_pcm_mmap_control)))
> > > > > > > - return -EFAULT;
> > > > > > > + if (buggy_control) {
> > > > > > > + if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
> > > > > > > + &(_sync_ptr->c.control_api_2_0_15),
> > > > > > > + sizeof(sync_ptr.c.control_api_2_0_15)))
> > > > > > > + return -EFAULT;
> > > > > > > + } else {
> > > > > > > + if (copy_from_user(&sync_ptr.c.control,
> > > > > > > + &(_sync_ptr->c.control),
> > > > > > > + sizeof(sync_ptr.c.control)))
> > > > > > > + return -EFAULT;
> > > > > > > + }
> > > > > >
> > > > > > The problem I see with this is that it might break musl's ability to
> > > > > > emulate the new
> > > > > > interface on top of the old (time32) one for linux-4.x and older
> > > > > > kernels, as the conversion
> > > > > > function is no longer stateless but has to know the negotiated
> > > > > > interface version.
> > > > > >
> > > > > > It's probably fine as long as we can be sure that the 2.0.16+ API
> > > > > > version only gets
> > > > > > negotiated if both the kernel and user sides support it, and musl only emulates
> > > > > > the 2.0.15 API version from the current kernels.
> > > > > >
> > > > > > I've tried to understand this part of musl's convert_ioctl_struct(), but I just
> > > > > > can't figure out whether it does the conversion based the on the layout that
> > > > > > is currently used in the kernel, or based on the layout we should have been
> > > > > > using, and would use with the above fix. Rich, can you help me here?
> > > > >
> > > > > So, at this moment, I'm not sure whether we should correct the struct
> > > > > at all. This will lead to yet more breakage, and basically the struct
> > > > > itself *works* -- the only bug is in 32bit compat handling in the
> > > > > kernel (again).
> > > > >
> > > > > The below is a revised kernel patch (again untested), just correcting
> > > > > the behavior of 32bit compat mode. 32bit apps on 32bit kernel work
> > > > > fine as is, as well as 64bit apps on 64bit kernel.
> > > >
> > > > I'm perfectly okay with this if Arnd is! It's probably the least
> > > > invasive and has the least long-term maintenance cost and fallout on
> > > > other projects.
> > >
> > > OK, I'll submit a proper patch now, to be included in the next PR for
> > > 5.15-rc. For further fixes, let's think carefully.
> >
> > Am I correct in my understanding that the fix of keeping the "broken"
> > definition (and having the 64-bit kernel honor it for 32-bit binaries)
> > has been accepted?
>
> Yes, as it was already set in stone, we accept the broken definition
> as is.
>
> > Since musl's translation for pre-time64 kernels
> > seems to have been using the "non-broken" definition, I think
> > completing the fix requires a change in musl too.
>
> Hm, musl translator contains the own definition of ioctl?
>
> If so, we may reconsider about renumbering ioctls altogether.
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.
Rich
[-- Attachment #2: musl_snd_pcm_mmap_control.diff --]
[-- Type: text/plain, Size: 898 bytes --]
diff --git a/src/misc/ioctl.c b/src/misc/ioctl.c
index 49282811..6d3e5095 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)
@@ -90,7 +91,14 @@ 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);
+ 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);
+ } else {
+ memcpy(new+72+adj, old+68, 4);
+ memcpy(new+72+4+2*adj, old+72, 4);
+ }
return;
}
for (int i=0; i < map->noffs; i++) {
^ permalink raw reply related [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-18 15:08 ` Rich Felker
@ 2021-10-18 15:26 ` Arnd Bergmann
-1 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2021-10-18 15:26 UTC (permalink / raw)
To: musl
Cc: Takashi Iwai, Arnd Bergmann, Michael Forney,
ALSA Development Mailing List, Takashi Iwai, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, Mark Brown,
Baolin Wang
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.
Arnd
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-18 15:26 ` Arnd Bergmann
0 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2021-10-18 15:26 UTC (permalink / raw)
To: musl
Cc: ALSA Development Mailing List, Arnd Bergmann, Baolin Wang,
Takashi Iwai, Linux Kernel Mailing List, Takashi Iwai,
Michael Forney, y2038 Mailman List, Mark Brown, Baolin Wang
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.
Arnd
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-18 15:26 ` Arnd Bergmann
@ 2021-10-18 20:42 ` Rich Felker
-1 siblings, 0 replies; 94+ messages in thread
From: Rich Felker @ 2021-10-18 20:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: musl, Takashi Iwai, Michael Forney,
ALSA Development Mailing List, Takashi Iwai, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, Mark Brown,
Baolin Wang
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.
Rich
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-18 20:42 ` Rich Felker
0 siblings, 0 replies; 94+ messages in thread
From: Rich Felker @ 2021-10-18 20:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: ALSA Development Mailing List, Baolin Wang, Takashi Iwai,
Linux Kernel Mailing List, musl, Takashi Iwai, Michael Forney,
y2038 Mailman List, Mark Brown, Baolin Wang
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.
Rich
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-18 20:42 ` Rich Felker
@ 2021-10-19 14:16 ` Rich Felker
-1 siblings, 0 replies; 94+ messages in thread
From: Rich Felker @ 2021-10-19 14:16 UTC (permalink / raw)
To: Arnd Bergmann
Cc: musl, Takashi Iwai, Michael Forney,
ALSA Development Mailing List, Takashi Iwai, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, Mark Brown,
Baolin Wang
[-- 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++) {
^ permalink raw reply related [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-19 14:16 ` Rich Felker
0 siblings, 0 replies; 94+ messages in thread
From: Rich Felker @ 2021-10-19 14:16 UTC (permalink / raw)
To: Arnd Bergmann
Cc: ALSA Development Mailing List, Baolin Wang, Takashi Iwai,
Linux Kernel Mailing List, musl, Takashi Iwai, Michael Forney,
y2038 Mailman List, Mark Brown, Baolin Wang
[-- 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++) {
^ permalink raw reply related [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-19 14:16 ` Rich Felker
@ 2021-10-19 14:23 ` Arnd Bergmann
-1 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2021-10-19 14:23 UTC (permalink / raw)
To: musl
Cc: Arnd Bergmann, Takashi Iwai, Michael Forney,
ALSA Development Mailing List, Takashi Iwai, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, Mark Brown,
Baolin Wang
On Tue, Oct 19, 2021 at 4:16 PM Rich Felker <dalias@libc.org> wrote:
> On Mon, Oct 18, 2021 at 04:42:04PM -0400, Rich Felker wrote:
> >
> > 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.
Looks good to me.
Arnd
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-19 14:23 ` Arnd Bergmann
0 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2021-10-19 14:23 UTC (permalink / raw)
To: musl
Cc: ALSA Development Mailing List, Arnd Bergmann, Baolin Wang,
Takashi Iwai, Linux Kernel Mailing List, Takashi Iwai,
Michael Forney, y2038 Mailman List, Mark Brown, Baolin Wang
On Tue, Oct 19, 2021 at 4:16 PM Rich Felker <dalias@libc.org> wrote:
> On Mon, Oct 18, 2021 at 04:42:04PM -0400, Rich Felker wrote:
> >
> > 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.
Looks good to me.
Arnd
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-08 9:24 ` Arnd Bergmann
@ 2021-10-08 12:06 ` Rich Felker
-1 siblings, 0 replies; 94+ messages in thread
From: Rich Felker @ 2021-10-08 12:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: musl, Michael Forney, ALSA Development Mailing List,
Takashi Iwai, Baolin Wang, y2038 Mailman List,
Linux Kernel Mailing List, Mark Brown, Baolin Wang
On Fri, Oct 08, 2021 at 11:24:39AM +0200, Arnd Bergmann wrote:
> On Fri, Oct 8, 2021 at 10:43 AM Takashi Iwai <tiwai@suse.de> wrote:
> > On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote:
> > > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> >
> > @@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
> > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> > typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > typedef char __pad_after_uframe[0];
> > +typedef char __pad_before_u32[4];
> > +typedef char __pad_after_u32[0];
> > #endif
> >
> > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> > typedef char __pad_before_uframe[0];
> > typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > +typedef char __pad_before_u32[0];
> > +typedef char __pad_after_u32[4];
> > #endif
>
> I think these should remain unchanged, the complex expression was intentionally
> done so the structures are laid out the same way on 64-bit
> architectures, so that
> the kernel can use the __SND_STRUCT_TIME64 path internally on both 32-bit
> and 64-bit architectures.
>
> > @@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
> > memset(&sync_ptr, 0, sizeof(sync_ptr));
> > if (get_user(sync_ptr.flags, (unsigned __user *)&(_sync_ptr->flags)))
> > return -EFAULT;
> > - if (copy_from_user(&sync_ptr.c.control, &(_sync_ptr->c.control), sizeof(struct snd_pcm_mmap_control)))
> > - return -EFAULT;
> > + if (buggy_control) {
> > + if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
> > + &(_sync_ptr->c.control_api_2_0_15),
> > + sizeof(sync_ptr.c.control_api_2_0_15)))
> > + return -EFAULT;
> > + } else {
> > + if (copy_from_user(&sync_ptr.c.control,
> > + &(_sync_ptr->c.control),
> > + sizeof(sync_ptr.c.control)))
> > + return -EFAULT;
> > + }
>
> The problem I see with this is that it might break musl's ability to
> emulate the new
> interface on top of the old (time32) one for linux-4.x and older
> kernels, as the conversion
> function is no longer stateless but has to know the negotiated
> interface version.
>
> It's probably fine as long as we can be sure that the 2.0.16+ API
> version only gets
> negotiated if both the kernel and user sides support it, and musl only emulates
> the 2.0.15 API version from the current kernels.
>
> I've tried to understand this part of musl's convert_ioctl_struct(), but I just
> can't figure out whether it does the conversion based the on the layout that
> is currently used in the kernel, or based on the layout we should have been
> using, and would use with the above fix. Rich, can you help me here?
If the attempted 64-bit ioctl is missing (ENOTTY), it does the
conversion to the legacy 32-bit one and retries with that, then
converts the results back to the 64-bit form.
Not only do I fail to see how the proposed fix is workable with this
framework; I also don't see how the proposed fix would let new
applications (compiled without the buggy type) run on old kernels. I'm
pretty sure there really should be a new ioctl number for this...
Rich
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-08 12:06 ` Rich Felker
0 siblings, 0 replies; 94+ messages in thread
From: Rich Felker @ 2021-10-08 12:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: ALSA Development Mailing List, Baolin Wang, y2038 Mailman List,
Linux Kernel Mailing List, musl, Takashi Iwai, Michael Forney,
Mark Brown, Baolin Wang
On Fri, Oct 08, 2021 at 11:24:39AM +0200, Arnd Bergmann wrote:
> On Fri, Oct 8, 2021 at 10:43 AM Takashi Iwai <tiwai@suse.de> wrote:
> > On Thu, 07 Oct 2021 18:51:58 +0200, Rich Felker wrote:
> > > On Thu, Oct 07, 2021 at 06:18:52PM +0200, Takashi Iwai wrote:
> >
> > @@ -557,11 +558,15 @@ struct __snd_pcm_sync_ptr {
> > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> > typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > typedef char __pad_after_uframe[0];
> > +typedef char __pad_before_u32[4];
> > +typedef char __pad_after_u32[0];
> > #endif
> >
> > #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> > typedef char __pad_before_uframe[0];
> > typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > +typedef char __pad_before_u32[0];
> > +typedef char __pad_after_u32[4];
> > #endif
>
> I think these should remain unchanged, the complex expression was intentionally
> done so the structures are laid out the same way on 64-bit
> architectures, so that
> the kernel can use the __SND_STRUCT_TIME64 path internally on both 32-bit
> and 64-bit architectures.
>
> > @@ -2970,8 +2981,17 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
> > memset(&sync_ptr, 0, sizeof(sync_ptr));
> > if (get_user(sync_ptr.flags, (unsigned __user *)&(_sync_ptr->flags)))
> > return -EFAULT;
> > - if (copy_from_user(&sync_ptr.c.control, &(_sync_ptr->c.control), sizeof(struct snd_pcm_mmap_control)))
> > - return -EFAULT;
> > + if (buggy_control) {
> > + if (copy_from_user(&sync_ptr.c.control_api_2_0_15,
> > + &(_sync_ptr->c.control_api_2_0_15),
> > + sizeof(sync_ptr.c.control_api_2_0_15)))
> > + return -EFAULT;
> > + } else {
> > + if (copy_from_user(&sync_ptr.c.control,
> > + &(_sync_ptr->c.control),
> > + sizeof(sync_ptr.c.control)))
> > + return -EFAULT;
> > + }
>
> The problem I see with this is that it might break musl's ability to
> emulate the new
> interface on top of the old (time32) one for linux-4.x and older
> kernels, as the conversion
> function is no longer stateless but has to know the negotiated
> interface version.
>
> It's probably fine as long as we can be sure that the 2.0.16+ API
> version only gets
> negotiated if both the kernel and user sides support it, and musl only emulates
> the 2.0.15 API version from the current kernels.
>
> I've tried to understand this part of musl's convert_ioctl_struct(), but I just
> can't figure out whether it does the conversion based the on the layout that
> is currently used in the kernel, or based on the layout we should have been
> using, and would use with the above fix. Rich, can you help me here?
If the attempted 64-bit ioctl is missing (ENOTTY), it does the
conversion to the legacy 32-bit one and retries with that, then
converts the results back to the 64-bit form.
Not only do I fail to see how the proposed fix is workable with this
framework; I also don't see how the proposed fix would let new
applications (compiled without the buggy type) run on old kernels. I'm
pretty sure there really should be a new ioctl number for this...
Rich
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-08 12:06 ` Rich Felker
@ 2021-10-08 12:37 ` Arnd Bergmann
-1 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2021-10-08 12:37 UTC (permalink / raw)
To: musl
Cc: Arnd Bergmann, Michael Forney, ALSA Development Mailing List,
Takashi Iwai, Baolin Wang, y2038 Mailman List,
Linux Kernel Mailing List, Mark Brown, Baolin Wang
On Fri, Oct 8, 2021 at 2:06 PM Rich Felker <dalias@libc.org> wrote:
> On Fri, Oct 08, 2021 at 11:24:39AM +0200, Arnd Bergmann wrote:
> >
> > I've tried to understand this part of musl's convert_ioctl_struct(), but I just
> > can't figure out whether it does the conversion based the on the layout that
> > is currently used in the kernel, or based on the layout we should have been
> > using, and would use with the above fix. Rich, can you help me here?
>
> If the attempted 64-bit ioctl is missing (ENOTTY), it does the
> conversion to the legacy 32-bit one and retries with that, then
> converts the results back to the 64-bit form.
I understand that it tries to do that.
The part that I'm not sure about is which of the two possible
64-bit forms it's using -- the broken one we have defined in the
kernel headers, or the one we were trying to define but failed.
Arnd
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-08 12:37 ` Arnd Bergmann
0 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2021-10-08 12:37 UTC (permalink / raw)
To: musl
Cc: ALSA Development Mailing List, Arnd Bergmann, Baolin Wang,
y2038 Mailman List, Linux Kernel Mailing List, Takashi Iwai,
Michael Forney, Mark Brown, Baolin Wang
On Fri, Oct 8, 2021 at 2:06 PM Rich Felker <dalias@libc.org> wrote:
> On Fri, Oct 08, 2021 at 11:24:39AM +0200, Arnd Bergmann wrote:
> >
> > I've tried to understand this part of musl's convert_ioctl_struct(), but I just
> > can't figure out whether it does the conversion based the on the layout that
> > is currently used in the kernel, or based on the layout we should have been
> > using, and would use with the above fix. Rich, can you help me here?
>
> If the attempted 64-bit ioctl is missing (ENOTTY), it does the
> conversion to the legacy 32-bit one and retries with that, then
> converts the results back to the 64-bit form.
I understand that it tries to do that.
The part that I'm not sure about is which of the two possible
64-bit forms it's using -- the broken one we have defined in the
kernel headers, or the one we were trying to define but failed.
Arnd
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
2021-10-08 12:37 ` Arnd Bergmann
@ 2021-10-08 17:20 ` Rich Felker
-1 siblings, 0 replies; 94+ messages in thread
From: Rich Felker @ 2021-10-08 17:20 UTC (permalink / raw)
To: Arnd Bergmann
Cc: musl, Michael Forney, ALSA Development Mailing List,
Takashi Iwai, Baolin Wang, y2038 Mailman List,
Linux Kernel Mailing List, Mark Brown, Baolin Wang
On Fri, Oct 08, 2021 at 02:37:12PM +0200, Arnd Bergmann wrote:
> On Fri, Oct 8, 2021 at 2:06 PM Rich Felker <dalias@libc.org> wrote:
> > On Fri, Oct 08, 2021 at 11:24:39AM +0200, Arnd Bergmann wrote:
> > >
> > > I've tried to understand this part of musl's convert_ioctl_struct(), but I just
> > > can't figure out whether it does the conversion based the on the layout that
> > > is currently used in the kernel, or based on the layout we should have been
> > > using, and would use with the above fix. Rich, can you help me here?
> >
> > If the attempted 64-bit ioctl is missing (ENOTTY), it does the
> > conversion to the legacy 32-bit one and retries with that, then
> > converts the results back to the 64-bit form.
>
> I understand that it tries to do that.
>
> The part that I'm not sure about is which of the two possible
> 64-bit forms it's using -- the broken one we have defined in the
> kernel headers, or the one we were trying to define but failed.
It's attempting to convert the intended format, not the one that the
uapi headers defined. That is, it's taking padded-to-64-bit values at
offsets 0 and 8 in __snd_pcm_mmap_control64, putting them at offsets 0
and 4 in the 32-bit struct, and padding them back to 64-bit in the
result.
Since applications would have been compiled with the buggy
(unintended) version of the uapi headers, this will not match the
application's layout of the struct. I haven't worked through what all
the consequences of that are, but I think some fix is needed here in
musl regardless of what happens on the kernel side.
Rich
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
@ 2021-10-08 17:20 ` Rich Felker
0 siblings, 0 replies; 94+ messages in thread
From: Rich Felker @ 2021-10-08 17:20 UTC (permalink / raw)
To: Arnd Bergmann
Cc: ALSA Development Mailing List, Baolin Wang, y2038 Mailman List,
Linux Kernel Mailing List, musl, Takashi Iwai, Michael Forney,
Mark Brown, Baolin Wang
On Fri, Oct 08, 2021 at 02:37:12PM +0200, Arnd Bergmann wrote:
> On Fri, Oct 8, 2021 at 2:06 PM Rich Felker <dalias@libc.org> wrote:
> > On Fri, Oct 08, 2021 at 11:24:39AM +0200, Arnd Bergmann wrote:
> > >
> > > I've tried to understand this part of musl's convert_ioctl_struct(), but I just
> > > can't figure out whether it does the conversion based the on the layout that
> > > is currently used in the kernel, or based on the layout we should have been
> > > using, and would use with the above fix. Rich, can you help me here?
> >
> > If the attempted 64-bit ioctl is missing (ENOTTY), it does the
> > conversion to the legacy 32-bit one and retries with that, then
> > converts the results back to the 64-bit form.
>
> I understand that it tries to do that.
>
> The part that I'm not sure about is which of the two possible
> 64-bit forms it's using -- the broken one we have defined in the
> kernel headers, or the one we were trying to define but failed.
It's attempting to convert the intended format, not the one that the
uapi headers defined. That is, it's taking padded-to-64-bit values at
offsets 0 and 8 in __snd_pcm_mmap_control64, putting them at offsets 0
and 4 in the 32-bit struct, and padding them back to 64-bit in the
result.
Since applications would have been compiled with the buggy
(unintended) version of the uapi headers, this will not match the
application's layout of the struct. I haven't worked through what all
the consequences of that are, but I think some fix is needed here in
musl regardless of what happens on the kernel side.
Rich
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH v7 9/9] ALSA: bump uapi version numbers
2019-12-11 21:20 ` [alsa-devel] " Arnd Bergmann
@ 2019-12-11 21:20 ` Arnd Bergmann
-1 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-11 21:20 UTC (permalink / raw)
To: alsa-devel, Takashi Iwai
Cc: Baolin Wang, y2038, linux-kernel, Jaroslav Kysela, Mark Brown,
Arnd Bergmann
Change SNDRV_PCM_VERSION, SNDRV_RAWMIDI_VERSION and SNDRV_TIMER_VERSION
to indicate the addition of the time64 version of the mmap interface and
these ioctl commands:
SNDRV_PCM_IOCTL_SYNC
SNDRV_RAWMIDI_IOCTL_STATUS
SNDRV_PCM_IOCTL_STATUS
SNDRV_PCM_IOCTL_STATUS_EXT
SNDRV_TIMER_IOCTL_TREAD
SNDRV_TIMER_IOCTL_STATUS
32-bit applications built with 64-bit time_t require both the headers
and the running kernel to support at least the new API version. When
built with earlier kernel headers, some of these may not work
correctly, so applications are encouraged to fail compilation like
#if SNDRV_PCM_VERSION < SNDRV_PROTOCOL_VERSION(2, 0, 15)
extern int __fail_build_for_time_64[sizeof(long) - sizeof(time_t)];
#endif
or provide their own updated copy of the header file.
At runtime, the interface is unchanged for 32-bit time_t, but new
kernels are required to work with user compiled with 64-bit time_t.
A runtime check can be used to detect old kernel versions and
warn about those.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/uapi/sound/asound.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
index df9983e7ead5..e6a958b8aff1 100644
--- a/include/uapi/sound/asound.h
+++ b/include/uapi/sound/asound.h
@@ -156,7 +156,7 @@ struct snd_hwdep_dsp_image {
* *
*****************************************************************************/
-#define SNDRV_PCM_VERSION SNDRV_PROTOCOL_VERSION(2, 0, 14)
+#define SNDRV_PCM_VERSION SNDRV_PROTOCOL_VERSION(2, 0, 15)
typedef unsigned long snd_pcm_uframes_t;
typedef signed long snd_pcm_sframes_t;
@@ -710,7 +710,7 @@ enum {
* Raw MIDI section - /dev/snd/midi??
*/
-#define SNDRV_RAWMIDI_VERSION SNDRV_PROTOCOL_VERSION(2, 0, 0)
+#define SNDRV_RAWMIDI_VERSION SNDRV_PROTOCOL_VERSION(2, 0, 1)
enum {
SNDRV_RAWMIDI_STREAM_OUTPUT = 0,
@@ -766,7 +766,7 @@ struct snd_rawmidi_status {
* Timer section - /dev/snd/timer
*/
-#define SNDRV_TIMER_VERSION SNDRV_PROTOCOL_VERSION(2, 0, 6)
+#define SNDRV_TIMER_VERSION SNDRV_PROTOCOL_VERSION(2, 0, 7)
enum {
SNDRV_TIMER_CLASS_NONE = -1,
--
2.20.0
^ permalink raw reply related [flat|nested] 94+ messages in thread* [alsa-devel] [PATCH v7 9/9] ALSA: bump uapi version numbers
@ 2019-12-11 21:20 ` Arnd Bergmann
0 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-11 21:20 UTC (permalink / raw)
To: alsa-devel, Takashi Iwai
Cc: Arnd Bergmann, y2038, linux-kernel, Mark Brown, Baolin Wang
Change SNDRV_PCM_VERSION, SNDRV_RAWMIDI_VERSION and SNDRV_TIMER_VERSION
to indicate the addition of the time64 version of the mmap interface and
these ioctl commands:
SNDRV_PCM_IOCTL_SYNC
SNDRV_RAWMIDI_IOCTL_STATUS
SNDRV_PCM_IOCTL_STATUS
SNDRV_PCM_IOCTL_STATUS_EXT
SNDRV_TIMER_IOCTL_TREAD
SNDRV_TIMER_IOCTL_STATUS
32-bit applications built with 64-bit time_t require both the headers
and the running kernel to support at least the new API version. When
built with earlier kernel headers, some of these may not work
correctly, so applications are encouraged to fail compilation like
#if SNDRV_PCM_VERSION < SNDRV_PROTOCOL_VERSION(2, 0, 15)
extern int __fail_build_for_time_64[sizeof(long) - sizeof(time_t)];
#endif
or provide their own updated copy of the header file.
At runtime, the interface is unchanged for 32-bit time_t, but new
kernels are required to work with user compiled with 64-bit time_t.
A runtime check can be used to detect old kernel versions and
warn about those.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/uapi/sound/asound.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
index df9983e7ead5..e6a958b8aff1 100644
--- a/include/uapi/sound/asound.h
+++ b/include/uapi/sound/asound.h
@@ -156,7 +156,7 @@ struct snd_hwdep_dsp_image {
* *
*****************************************************************************/
-#define SNDRV_PCM_VERSION SNDRV_PROTOCOL_VERSION(2, 0, 14)
+#define SNDRV_PCM_VERSION SNDRV_PROTOCOL_VERSION(2, 0, 15)
typedef unsigned long snd_pcm_uframes_t;
typedef signed long snd_pcm_sframes_t;
@@ -710,7 +710,7 @@ enum {
* Raw MIDI section - /dev/snd/midi??
*/
-#define SNDRV_RAWMIDI_VERSION SNDRV_PROTOCOL_VERSION(2, 0, 0)
+#define SNDRV_RAWMIDI_VERSION SNDRV_PROTOCOL_VERSION(2, 0, 1)
enum {
SNDRV_RAWMIDI_STREAM_OUTPUT = 0,
@@ -766,7 +766,7 @@ struct snd_rawmidi_status {
* Timer section - /dev/snd/timer
*/
-#define SNDRV_TIMER_VERSION SNDRV_PROTOCOL_VERSION(2, 0, 6)
+#define SNDRV_TIMER_VERSION SNDRV_PROTOCOL_VERSION(2, 0, 7)
enum {
SNDRV_TIMER_CLASS_NONE = -1,
--
2.20.0
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply related [flat|nested] 94+ messages in thread
* Re: [PATCH v7 0/8] Fix year 2038 issue for sound subsystem
2019-12-11 21:20 ` [alsa-devel] " Arnd Bergmann
@ 2019-12-17 10:42 ` Takashi Iwai
-1 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2019-12-17 10:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: alsa-devel, Takashi Iwai, Baolin Wang, y2038, linux-kernel,
Jaroslav Kysela, Mark Brown
On Wed, 11 Dec 2019 22:20:16 +0100,
Arnd Bergmann wrote:
>
> This is a series I worked on with Baolin in 2017 and 2018, but we
> never quite managed to finish up the last pieces. During the
> ALSA developer meetup at ELC-E 2018 in Edinburgh, a decision was
> made to go with this approach for keeping best compatibility
> with existing source code, and then I failed to follow up by
> resending the patches.
>
> Now I have patches for all remaining time_t uses in the kernel,
> so it's absolutely time to revisit them. I have done more
> review of the patches myself and found a couple of minor issues
> that I have fixed up, otherwise the series is still the same as
> before.
>
> Conceptually, the idea of these patches is:
>
> - 64-bit applications should see no changes at all, neither
> compile-time nor run-time.
>
> - 32-bit code compiled with a 64-bit time_t currently
> does not work with ALSA, and requires kernel changes and/or
> sound/asound.h changes
>
> - Most 32-bit code using these interfaces will work correctly
> on a modified kernel, with or without the uapi header changes.
>
> - 32-bit code using SNDRV_TIMER_IOCTL_TREAD requires the
> updated header file for 64-bit time_t support
>
> - 32-bit i386 user space with 64-bit time_t is broken for
> SNDRV_PCM_IOCTL_STATUS, SNDRV_RAWMIDI_IOCTL_STATUS and
> SNDRV_PCM_IOCTL_SYNC_PTR because of i386 alignment. This is also
> addressed by the updated uapi header.
>
> - PCM mmap is currently supported on native x86 kernels
> (both 32-bit and 64-bit) but not for compat mode. This series breaks
> the 32-bit native mmap support for 32-bit time_t, but instead allows
> it for 64-bit time_t on both native and compat kernels. This seems to
> be the best trade-off, as mmap support is optional already, and most
> 32-bit code runs in compat mode anyway.
>
> - I've tried to avoid breaking compilation of 32-bit code
> as much as possible. Anything that does break however is likely code
> that is already broken on 64-bit time_t and needs source changes to
> fix them.
>
> I hope I addressed all review comments by now, so please pull this
> for linux-5.6.
>
> A git branch with the same contents is available for testing at [1].
>
> Arnd
I see no issue other than the timer API patch Ben pointed.
Could you resubmit that patch? Or just submit the whole as v8, I
don't mind either way. Then we'll get this done for 5.6.
Thanks!
Takashi
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git y2038-alsa-v7
> [2] https://lore.kernel.org/lkml/CAK8P3a2Os66+iwQYf97qh05W2JP8rmWao8zmKoHiXqVHvyYAJA@mail.gmail.com/T/#m6519cb07cfda08adf1dedea6596bb98892b4d5dc
>
> Changes since v6: (Arnd):
> - Add a patch to update the API versions
> - Hide a timespec reference in #ifndef __KERNEL__ to remove the
> last reference to time_t
> - Use a more readable way to do padding and describe it in the
> changelog
> - Rebase to linux-5.5-rc1, changing include/sound/soc-component.h
> and sound/drivers/aloop.c as needed.
>
> Changes since v5 (Arnd):
> - Rebased to linux-5.4-rc4
> - Updated to completely remove timespec and time_t references from alsa
> - found and fixed a few bugs
>
> Changes since v4 (Baolin):
> - Add patch 5 to change trigger_tstamp member of struct snd_pcm_runtime.
> - Add patch 8 to change internal timespec.
> - Add more explanation in commit message.
> - Use ktime_get_real_ts64() in patch 6.
> - Split common code out into a separate function in patch 6.
> - Fix tu->tread bug in patch 6 and remove #if __BITS_PER_LONG == 64 macro.
>
> Changes since v3:
> - Move struct snd_pcm_status32 to pcm.h file.
> - Modify comments and commit message.
> - Add new patch2 ~ patch6.
>
> Changes since v2:
> - Renamed all structures to make clear.
> - Remove CONFIG_X86_X32 macro and introduced new compat_snd_pcm_status64_x86_32.
>
> Changes since v1:
> - Add one macro for struct snd_pcm_status_32 which only active in 32bits kernel.
> - Convert pcm_compat.c to use struct snd_pcm_status_64.
> - Convert pcm_native.c to use struct snd_pcm_status_64.
> ---
>
> Arnd Bergmann (3):
> ALSA: move snd_pcm_ioctl_sync_ptr_compat into pcm_native.c
> ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
> ALSA: bump uapi version numbers
>
> Baolin Wang (6):
> ALSA: Replace timespec with timespec64
> ALSA: Avoid using timespec for struct snd_timer_status
> ALSA: Avoid using timespec for struct snd_ctl_elem_value
> ALSA: Avoid using timespec for struct snd_pcm_status
> ALSA: Avoid using timespec for struct snd_rawmidi_status
> ALSA: Avoid using timespec for struct snd_timer_tread
>
> include/sound/pcm.h | 74 ++++++--
> include/sound/soc-component.h | 4 +-
> include/sound/timer.h | 4 +-
> include/uapi/sound/asound.h | 145 +++++++++++++--
> sound/core/pcm.c | 12 +-
> sound/core/pcm_compat.c | 282 ++++++++----------------------
> sound/core/pcm_lib.c | 38 ++--
> sound/core/pcm_native.c | 226 +++++++++++++++++++++---
> sound/core/rawmidi.c | 132 +++++++++++---
> sound/core/rawmidi_compat.c | 87 +++------
> sound/core/timer.c | 229 ++++++++++++++++++------
> sound/core/timer_compat.c | 62 +------
> sound/drivers/aloop.c | 2 +-
> sound/pci/hda/hda_controller.c | 10 +-
> sound/soc/intel/skylake/skl-pcm.c | 4 +-
> 15 files changed, 817 insertions(+), 494 deletions(-)
>
> --
> 2.20.0
>
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [alsa-devel] [PATCH v7 0/8] Fix year 2038 issue for sound subsystem
@ 2019-12-17 10:42 ` Takashi Iwai
0 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2019-12-17 10:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: alsa-devel, y2038, linux-kernel, Takashi Iwai, Mark Brown, Baolin Wang
On Wed, 11 Dec 2019 22:20:16 +0100,
Arnd Bergmann wrote:
>
> This is a series I worked on with Baolin in 2017 and 2018, but we
> never quite managed to finish up the last pieces. During the
> ALSA developer meetup at ELC-E 2018 in Edinburgh, a decision was
> made to go with this approach for keeping best compatibility
> with existing source code, and then I failed to follow up by
> resending the patches.
>
> Now I have patches for all remaining time_t uses in the kernel,
> so it's absolutely time to revisit them. I have done more
> review of the patches myself and found a couple of minor issues
> that I have fixed up, otherwise the series is still the same as
> before.
>
> Conceptually, the idea of these patches is:
>
> - 64-bit applications should see no changes at all, neither
> compile-time nor run-time.
>
> - 32-bit code compiled with a 64-bit time_t currently
> does not work with ALSA, and requires kernel changes and/or
> sound/asound.h changes
>
> - Most 32-bit code using these interfaces will work correctly
> on a modified kernel, with or without the uapi header changes.
>
> - 32-bit code using SNDRV_TIMER_IOCTL_TREAD requires the
> updated header file for 64-bit time_t support
>
> - 32-bit i386 user space with 64-bit time_t is broken for
> SNDRV_PCM_IOCTL_STATUS, SNDRV_RAWMIDI_IOCTL_STATUS and
> SNDRV_PCM_IOCTL_SYNC_PTR because of i386 alignment. This is also
> addressed by the updated uapi header.
>
> - PCM mmap is currently supported on native x86 kernels
> (both 32-bit and 64-bit) but not for compat mode. This series breaks
> the 32-bit native mmap support for 32-bit time_t, but instead allows
> it for 64-bit time_t on both native and compat kernels. This seems to
> be the best trade-off, as mmap support is optional already, and most
> 32-bit code runs in compat mode anyway.
>
> - I've tried to avoid breaking compilation of 32-bit code
> as much as possible. Anything that does break however is likely code
> that is already broken on 64-bit time_t and needs source changes to
> fix them.
>
> I hope I addressed all review comments by now, so please pull this
> for linux-5.6.
>
> A git branch with the same contents is available for testing at [1].
>
> Arnd
I see no issue other than the timer API patch Ben pointed.
Could you resubmit that patch? Or just submit the whole as v8, I
don't mind either way. Then we'll get this done for 5.6.
Thanks!
Takashi
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git y2038-alsa-v7
> [2] https://lore.kernel.org/lkml/CAK8P3a2Os66+iwQYf97qh05W2JP8rmWao8zmKoHiXqVHvyYAJA@mail.gmail.com/T/#m6519cb07cfda08adf1dedea6596bb98892b4d5dc
>
> Changes since v6: (Arnd):
> - Add a patch to update the API versions
> - Hide a timespec reference in #ifndef __KERNEL__ to remove the
> last reference to time_t
> - Use a more readable way to do padding and describe it in the
> changelog
> - Rebase to linux-5.5-rc1, changing include/sound/soc-component.h
> and sound/drivers/aloop.c as needed.
>
> Changes since v5 (Arnd):
> - Rebased to linux-5.4-rc4
> - Updated to completely remove timespec and time_t references from alsa
> - found and fixed a few bugs
>
> Changes since v4 (Baolin):
> - Add patch 5 to change trigger_tstamp member of struct snd_pcm_runtime.
> - Add patch 8 to change internal timespec.
> - Add more explanation in commit message.
> - Use ktime_get_real_ts64() in patch 6.
> - Split common code out into a separate function in patch 6.
> - Fix tu->tread bug in patch 6 and remove #if __BITS_PER_LONG == 64 macro.
>
> Changes since v3:
> - Move struct snd_pcm_status32 to pcm.h file.
> - Modify comments and commit message.
> - Add new patch2 ~ patch6.
>
> Changes since v2:
> - Renamed all structures to make clear.
> - Remove CONFIG_X86_X32 macro and introduced new compat_snd_pcm_status64_x86_32.
>
> Changes since v1:
> - Add one macro for struct snd_pcm_status_32 which only active in 32bits kernel.
> - Convert pcm_compat.c to use struct snd_pcm_status_64.
> - Convert pcm_native.c to use struct snd_pcm_status_64.
> ---
>
> Arnd Bergmann (3):
> ALSA: move snd_pcm_ioctl_sync_ptr_compat into pcm_native.c
> ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
> ALSA: bump uapi version numbers
>
> Baolin Wang (6):
> ALSA: Replace timespec with timespec64
> ALSA: Avoid using timespec for struct snd_timer_status
> ALSA: Avoid using timespec for struct snd_ctl_elem_value
> ALSA: Avoid using timespec for struct snd_pcm_status
> ALSA: Avoid using timespec for struct snd_rawmidi_status
> ALSA: Avoid using timespec for struct snd_timer_tread
>
> include/sound/pcm.h | 74 ++++++--
> include/sound/soc-component.h | 4 +-
> include/sound/timer.h | 4 +-
> include/uapi/sound/asound.h | 145 +++++++++++++--
> sound/core/pcm.c | 12 +-
> sound/core/pcm_compat.c | 282 ++++++++----------------------
> sound/core/pcm_lib.c | 38 ++--
> sound/core/pcm_native.c | 226 +++++++++++++++++++++---
> sound/core/rawmidi.c | 132 +++++++++++---
> sound/core/rawmidi_compat.c | 87 +++------
> sound/core/timer.c | 229 ++++++++++++++++++------
> sound/core/timer_compat.c | 62 +------
> sound/drivers/aloop.c | 2 +-
> sound/pci/hda/hda_controller.c | 10 +-
> sound/soc/intel/skylake/skl-pcm.c | 4 +-
> 15 files changed, 817 insertions(+), 494 deletions(-)
>
> --
> 2.20.0
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH v7 0/8] Fix year 2038 issue for sound subsystem
2019-12-17 10:42 ` [alsa-devel] " Takashi Iwai
@ 2019-12-17 21:15 ` Arnd Bergmann
-1 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-17 21:15 UTC (permalink / raw)
To: Takashi Iwai
Cc: ALSA Development Mailing List, Takashi Iwai, Baolin Wang,
y2038 Mailman List, linux-kernel, Jaroslav Kysela, Mark Brown
On Tue, Dec 17, 2019 at 11:42 AM Takashi Iwai <tiwai@suse.de> wrote:
> On Wed, 11 Dec 2019 22:20:16 +0100,
> Arnd Bergmann wrote:
> >
> > I hope I addressed all review comments by now, so please pull this
> > for linux-5.6.
> >
> > A git branch with the same contents is available for testing at [1].
> >
> > Arnd
>
> I see no issue other than the timer API patch Ben pointed.
>
> Could you resubmit that patch? Or just submit the whole as v8, I
> don't mind either way. Then we'll get this done for 5.6.
Can you take this as a pull request? That would be ideal for me,
as I can then use it as a parent for a shared branch with additional
cleanups on top (removing time_t etc) in linux-next. It also provides
a nice place to preserve the series cover letter.
I'm sending you the pull request now, and the last modified patch,
in case you prefer the patch over a git tag.
Thanks,
Arnd
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [alsa-devel] [PATCH v7 0/8] Fix year 2038 issue for sound subsystem
@ 2019-12-17 21:15 ` Arnd Bergmann
0 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-17 21:15 UTC (permalink / raw)
To: Takashi Iwai
Cc: ALSA Development Mailing List, y2038 Mailman List, linux-kernel,
Takashi Iwai, Mark Brown, Baolin Wang
On Tue, Dec 17, 2019 at 11:42 AM Takashi Iwai <tiwai@suse.de> wrote:
> On Wed, 11 Dec 2019 22:20:16 +0100,
> Arnd Bergmann wrote:
> >
> > I hope I addressed all review comments by now, so please pull this
> > for linux-5.6.
> >
> > A git branch with the same contents is available for testing at [1].
> >
> > Arnd
>
> I see no issue other than the timer API patch Ben pointed.
>
> Could you resubmit that patch? Or just submit the whole as v8, I
> don't mind either way. Then we'll get this done for 5.6.
Can you take this as a pull request? That would be ideal for me,
as I can then use it as a parent for a shared branch with additional
cleanups on top (removing time_t etc) in linux-next. It also provides
a nice place to preserve the series cover letter.
I'm sending you the pull request now, and the last modified patch,
in case you prefer the patch over a git tag.
Thanks,
Arnd
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 94+ messages in thread* [GIT PULL, v8] Fix year 2038 issue for sound subsystem
2019-12-17 21:15 ` [alsa-devel] " Arnd Bergmann
@ 2019-12-17 21:16 ` Arnd Bergmann
-1 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-17 21:16 UTC (permalink / raw)
To: Takashi Iwai
Cc: ALSA Development Mailing List, Takashi Iwai, Baolin Wang,
y2038 Mailman List, linux-kernel, Jaroslav Kysela, Mark Brown
The following changes since commit e42617b825f8073569da76dc4510bfa019b1c35a:
Linux 5.5-rc1 (2019-12-08 14:57:55 -0800)
are available in the Git repository at:
git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground.git
tags/y2038-alsa-v8-signed
for you to fetch changes up to 1cfaef9617033f38eba9cc725809ed32bcdb3dc5:
ALSA: bump uapi version numbers (2019-12-13 11:25:58 +0100)
----------------------------------------------------------------
ALSA: Fix year 2038 issue for sound subsystem
This is a series I worked on with Baolin in 2017 and 2018, but we
never quite managed to finish up the last pieces. During the
ALSA developer meetup at ELC-E 2018 in Edinburgh, a decision was
made to go with this approach for keeping best compatibility
with existing source code, and then I failed to follow up by
resending the patches.
Now I have patches for all remaining time_t uses in the kernel,
so it's absolutely time to revisit them. I have done more
review of the patches myself and found a couple of minor issues
that I have fixed up, otherwise the series is still the same as
before.
Conceptually, the idea of these patches is:
- 64-bit applications should see no changes at all, neither
compile-time nor run-time.
- 32-bit code compiled with a 64-bit time_t currently
does not work with ALSA, and requires kernel changes and/or
sound/asound.h changes
- Most 32-bit code using these interfaces will work correctly
on a modified kernel, with or without the uapi header changes.
- 32-bit code using SNDRV_TIMER_IOCTL_TREAD requires the
updated header file for 64-bit time_t support
- 32-bit i386 user space with 64-bit time_t is broken for
SNDRV_PCM_IOCTL_STATUS, SNDRV_RAWMIDI_IOCTL_STATUS and
SNDRV_PCM_IOCTL_SYNC_PTR because of i386 alignment. This is also
addressed by the updated uapi header.
- PCM mmap is currently supported on native x86 kernels
(both 32-bit and 64-bit) but not for compat mode. This series breaks
the 32-bit native mmap support for 32-bit time_t, but instead allows
it for 64-bit time_t on both native and compat kernels. This seems to
be the best trade-off, as mmap support is optional already, and most
32-bit code runs in compat mode anyway.
- I've tried to avoid breaking compilation of 32-bit code
as much as possible. Anything that does break however is likely code
that is already broken on 64-bit time_t and needs source changes to
fix them.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git
y2038-alsa-v8
[2] https://lore.kernel.org/lkml/CAK8P3a2Os66+iwQYf97qh05W2JP8rmWao8zmKoHiXqVHvyYAJA@mail.gmail.com/T/#m6519cb07cfda08adf1dedea6596bb98892b4d5dc
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Changes since v7: (Arnd):
- Fix a typo found by Ben Hutchings
Changes since v6: (Arnd):
- Add a patch to update the API versions
- Hide a timespec reference in #ifndef __KERNEL__ to remove the
last reference to time_t
- Use a more readable way to do padding and describe it in the
changelog
- Rebase to linux-5.5-rc1, changing include/sound/soc-component.h
and sound/drivers/aloop.c as needed.
Changes since v5 (Arnd):
- Rebased to linux-5.4-rc4
- Updated to completely remove timespec and time_t references from alsa
- found and fixed a few bugs
Changes since v4 (Baolin):
- Add patch 5 to change trigger_tstamp member of struct snd_pcm_runtime.
- Add patch 8 to change internal timespec.
- Add more explanation in commit message.
- Use ktime_get_real_ts64() in patch 6.
- Split common code out into a separate function in patch 6.
- Fix tu->tread bug in patch 6 and remove #if __BITS_PER_LONG == 64 macro.
Changes since v3:
- Move struct snd_pcm_status32 to pcm.h file.
- Modify comments and commit message.
- Add new patch2 ~ patch6.
Changes since v2:
- Renamed all structures to make clear.
- Remove CONFIG_X86_X32 macro and introduced new
compat_snd_pcm_status64_x86_32.
Changes since v1:
- Add one macro for struct snd_pcm_status_32 which only active in
32bits kernel.
- Convert pcm_compat.c to use struct snd_pcm_status_64.
- Convert pcm_native.c to use struct snd_pcm_status_64.
----------------------------------------------------------------
Arnd Bergmann (3):
ALSA: move snd_pcm_ioctl_sync_ptr_compat into pcm_native.c
ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
ALSA: bump uapi version numbers
Baolin Wang (6):
ALSA: Replace timespec with timespec64
ALSA: Avoid using timespec for struct snd_timer_status
ALSA: Avoid using timespec for struct snd_ctl_elem_value
ALSA: Avoid using timespec for struct snd_pcm_status
ALSA: Avoid using timespec for struct snd_rawmidi_status
ALSA: Avoid using timespec for struct snd_timer_tread
include/sound/pcm.h | 74 +++++++++++++++++----
include/sound/soc-component.h | 4 +-
include/sound/timer.h | 4 +-
include/uapi/sound/asound.h | 145
++++++++++++++++++++++++++++++++++++-----
sound/core/pcm.c | 12 ++--
sound/core/pcm_compat.c | 282
++++++++++++++++++++------------------------------------------------------------
sound/core/pcm_lib.c | 38 +++++++----
sound/core/pcm_native.c | 226
++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------
sound/core/rawmidi.c | 132 ++++++++++++++++++++++++++++---------
sound/core/rawmidi_compat.c | 87 +++++++------------------
sound/core/timer.c | 230
++++++++++++++++++++++++++++++++++++++++++++++++++---------------
sound/core/timer_compat.c | 62 +++---------------
sound/drivers/aloop.c | 2 +-
sound/pci/hda/hda_controller.c | 10 +--
sound/soc/intel/skylake/skl-pcm.c | 4 +-
15 files changed, 818 insertions(+), 494 deletions(-)
^ permalink raw reply [flat|nested] 94+ messages in thread* [alsa-devel] [GIT PULL, v8] Fix year 2038 issue for sound subsystem
@ 2019-12-17 21:16 ` Arnd Bergmann
0 siblings, 0 replies; 94+ messages in thread
From: Arnd Bergmann @ 2019-12-17 21:16 UTC (permalink / raw)
To: Takashi Iwai
Cc: ALSA Development Mailing List, y2038 Mailman List, linux-kernel,
Takashi Iwai, Mark Brown, Baolin Wang
The following changes since commit e42617b825f8073569da76dc4510bfa019b1c35a:
Linux 5.5-rc1 (2019-12-08 14:57:55 -0800)
are available in the Git repository at:
git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground.git
tags/y2038-alsa-v8-signed
for you to fetch changes up to 1cfaef9617033f38eba9cc725809ed32bcdb3dc5:
ALSA: bump uapi version numbers (2019-12-13 11:25:58 +0100)
----------------------------------------------------------------
ALSA: Fix year 2038 issue for sound subsystem
This is a series I worked on with Baolin in 2017 and 2018, but we
never quite managed to finish up the last pieces. During the
ALSA developer meetup at ELC-E 2018 in Edinburgh, a decision was
made to go with this approach for keeping best compatibility
with existing source code, and then I failed to follow up by
resending the patches.
Now I have patches for all remaining time_t uses in the kernel,
so it's absolutely time to revisit them. I have done more
review of the patches myself and found a couple of minor issues
that I have fixed up, otherwise the series is still the same as
before.
Conceptually, the idea of these patches is:
- 64-bit applications should see no changes at all, neither
compile-time nor run-time.
- 32-bit code compiled with a 64-bit time_t currently
does not work with ALSA, and requires kernel changes and/or
sound/asound.h changes
- Most 32-bit code using these interfaces will work correctly
on a modified kernel, with or without the uapi header changes.
- 32-bit code using SNDRV_TIMER_IOCTL_TREAD requires the
updated header file for 64-bit time_t support
- 32-bit i386 user space with 64-bit time_t is broken for
SNDRV_PCM_IOCTL_STATUS, SNDRV_RAWMIDI_IOCTL_STATUS and
SNDRV_PCM_IOCTL_SYNC_PTR because of i386 alignment. This is also
addressed by the updated uapi header.
- PCM mmap is currently supported on native x86 kernels
(both 32-bit and 64-bit) but not for compat mode. This series breaks
the 32-bit native mmap support for 32-bit time_t, but instead allows
it for 64-bit time_t on both native and compat kernels. This seems to
be the best trade-off, as mmap support is optional already, and most
32-bit code runs in compat mode anyway.
- I've tried to avoid breaking compilation of 32-bit code
as much as possible. Anything that does break however is likely code
that is already broken on 64-bit time_t and needs source changes to
fix them.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git
y2038-alsa-v8
[2] https://lore.kernel.org/lkml/CAK8P3a2Os66+iwQYf97qh05W2JP8rmWao8zmKoHiXqVHvyYAJA@mail.gmail.com/T/#m6519cb07cfda08adf1dedea6596bb98892b4d5dc
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Changes since v7: (Arnd):
- Fix a typo found by Ben Hutchings
Changes since v6: (Arnd):
- Add a patch to update the API versions
- Hide a timespec reference in #ifndef __KERNEL__ to remove the
last reference to time_t
- Use a more readable way to do padding and describe it in the
changelog
- Rebase to linux-5.5-rc1, changing include/sound/soc-component.h
and sound/drivers/aloop.c as needed.
Changes since v5 (Arnd):
- Rebased to linux-5.4-rc4
- Updated to completely remove timespec and time_t references from alsa
- found and fixed a few bugs
Changes since v4 (Baolin):
- Add patch 5 to change trigger_tstamp member of struct snd_pcm_runtime.
- Add patch 8 to change internal timespec.
- Add more explanation in commit message.
- Use ktime_get_real_ts64() in patch 6.
- Split common code out into a separate function in patch 6.
- Fix tu->tread bug in patch 6 and remove #if __BITS_PER_LONG == 64 macro.
Changes since v3:
- Move struct snd_pcm_status32 to pcm.h file.
- Modify comments and commit message.
- Add new patch2 ~ patch6.
Changes since v2:
- Renamed all structures to make clear.
- Remove CONFIG_X86_X32 macro and introduced new
compat_snd_pcm_status64_x86_32.
Changes since v1:
- Add one macro for struct snd_pcm_status_32 which only active in
32bits kernel.
- Convert pcm_compat.c to use struct snd_pcm_status_64.
- Convert pcm_native.c to use struct snd_pcm_status_64.
----------------------------------------------------------------
Arnd Bergmann (3):
ALSA: move snd_pcm_ioctl_sync_ptr_compat into pcm_native.c
ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
ALSA: bump uapi version numbers
Baolin Wang (6):
ALSA: Replace timespec with timespec64
ALSA: Avoid using timespec for struct snd_timer_status
ALSA: Avoid using timespec for struct snd_ctl_elem_value
ALSA: Avoid using timespec for struct snd_pcm_status
ALSA: Avoid using timespec for struct snd_rawmidi_status
ALSA: Avoid using timespec for struct snd_timer_tread
include/sound/pcm.h | 74 +++++++++++++++++----
include/sound/soc-component.h | 4 +-
include/sound/timer.h | 4 +-
include/uapi/sound/asound.h | 145
++++++++++++++++++++++++++++++++++++-----
sound/core/pcm.c | 12 ++--
sound/core/pcm_compat.c | 282
++++++++++++++++++++------------------------------------------------------------
sound/core/pcm_lib.c | 38 +++++++----
sound/core/pcm_native.c | 226
++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------
sound/core/rawmidi.c | 132 ++++++++++++++++++++++++++++---------
sound/core/rawmidi_compat.c | 87 +++++++------------------
sound/core/timer.c | 230
++++++++++++++++++++++++++++++++++++++++++++++++++---------------
sound/core/timer_compat.c | 62 +++---------------
sound/drivers/aloop.c | 2 +-
sound/pci/hda/hda_controller.c | 10 +--
sound/soc/intel/skylake/skl-pcm.c | 4 +-
15 files changed, 818 insertions(+), 494 deletions(-)
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH v7 0/8] Fix year 2038 issue for sound subsystem
2019-12-17 21:15 ` [alsa-devel] " Arnd Bergmann
@ 2019-12-17 22:22 ` Takashi Iwai
-1 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2019-12-17 22:22 UTC (permalink / raw)
To: Arnd Bergmann
Cc: ALSA Development Mailing List, Takashi Iwai, Baolin Wang,
y2038 Mailman List, linux-kernel, Jaroslav Kysela, Mark Brown
On Tue, 17 Dec 2019 22:15:32 +0100,
Arnd Bergmann wrote:
>
> On Tue, Dec 17, 2019 at 11:42 AM Takashi Iwai <tiwai@suse.de> wrote:
> > On Wed, 11 Dec 2019 22:20:16 +0100,
> > Arnd Bergmann wrote:
>
> > >
> > > I hope I addressed all review comments by now, so please pull this
> > > for linux-5.6.
> > >
> > > A git branch with the same contents is available for testing at [1].
> > >
> > > Arnd
> >
> > I see no issue other than the timer API patch Ben pointed.
> >
> > Could you resubmit that patch? Or just submit the whole as v8, I
> > don't mind either way. Then we'll get this done for 5.6.
>
> Can you take this as a pull request? That would be ideal for me,
> as I can then use it as a parent for a shared branch with additional
> cleanups on top (removing time_t etc) in linux-next. It also provides
> a nice place to preserve the series cover letter.
>
> I'm sending you the pull request now, and the last modified patch,
> in case you prefer the patch over a git tag.
That's fine for me. Now I pulled it to a branch for 5.6 kernel.
Thanks for your patient works!
Takashi
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [alsa-devel] [PATCH v7 0/8] Fix year 2038 issue for sound subsystem
@ 2019-12-17 22:22 ` Takashi Iwai
0 siblings, 0 replies; 94+ messages in thread
From: Takashi Iwai @ 2019-12-17 22:22 UTC (permalink / raw)
To: Arnd Bergmann
Cc: ALSA Development Mailing List, y2038 Mailman List, linux-kernel,
Takashi Iwai, Mark Brown, Baolin Wang
On Tue, 17 Dec 2019 22:15:32 +0100,
Arnd Bergmann wrote:
>
> On Tue, Dec 17, 2019 at 11:42 AM Takashi Iwai <tiwai@suse.de> wrote:
> > On Wed, 11 Dec 2019 22:20:16 +0100,
> > Arnd Bergmann wrote:
>
> > >
> > > I hope I addressed all review comments by now, so please pull this
> > > for linux-5.6.
> > >
> > > A git branch with the same contents is available for testing at [1].
> > >
> > > Arnd
> >
> > I see no issue other than the timer API patch Ben pointed.
> >
> > Could you resubmit that patch? Or just submit the whole as v8, I
> > don't mind either way. Then we'll get this done for 5.6.
>
> Can you take this as a pull request? That would be ideal for me,
> as I can then use it as a parent for a shared branch with additional
> cleanups on top (removing time_t etc) in linux-next. It also provides
> a nice place to preserve the series cover letter.
>
> I'm sending you the pull request now, and the last modified patch,
> in case you prefer the patch over a git tag.
That's fine for me. Now I pulled it to a branch for 5.6 kernel.
Thanks for your patient works!
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 94+ messages in thread