[PATCH 0/3] ALSA: firewire-motu: fix message parser and refine UAPI
Hi,
This patchset is to fix message parser and refine UAPI added in below patchset. https://lore.kernel.org/alsa-devel/20211015080826.34847-1-o-takashi@sakamocc...
Current implementation of message parser for register DSP models has a bug to cause invalid memory access in the other type of models. I attempted to fix it in my previous patch[1] but got a comment for simpler solution. The first patch in the patchset is revised version of the previous one.
After working for libhinawa(g-i binding)[2], Rust bindings[3], and service program[4] as application of the new features in UAPI, I found that the number of input meters is greater than current structure in UAPI for some models. The second patch is to refine the structure and message parser. I note that the other part of UAPI is pretty good, and the service program now supports control notification in register DSP mdoels as well as command DSP models.
After discussion about usage of float type in UAPI, it shall be allowed in some cases. The third patch is to interpret the UAPI for float type in userspace and u32 type in kernel space.
[1] https://lore.kernel.org/alsa-devel/20211020042555.40866-1-o-takashi@sakamocc... [2] https://github.com/alsa-project/libhinawa/tree/topic/motu-mixer-ioctl [3] https://github.com/alsa-project/hinawa-rs/tree/topic/v0.5.0 [4] https://github.com/alsa-project/snd-firewire-ctl-services/tree/topic/motu-mi...
Takashi Sakamoto (3): ALSA: firewire-motu: fix null pointer dereference when polling hwdep character device ALSA: firewire-motu: refine parser for meter information in register DSP models ALSA: firewire-motu: export mete information to userspace as float value
include/uapi/sound/firewire.h | 13 +++++++++---- .../motu/motu-command-dsp-message-parser.c | 7 +++++-- sound/firewire/motu/motu-hwdep.c | 16 +++++++++++----- .../motu/motu-register-dsp-message-parser.c | 14 +++++++++----- 4 files changed, 34 insertions(+), 16 deletions(-)
ALSA firewire-motu driver recently got support for event notification via ALSA HwDep interface for register DSP models. However, when polling ALSA HwDep cdev, the driver can cause null pointer dereference for the other models due to accessing to unallocated memory or uninitialized memory.
This commit fixes the bug by check the type of model before accessing to the memory.
Reported-by: kernel test robot lkp@intel.com Suggested-by: Takashi Iwai tiwai@suse.de Fixes: 634ec0b2906e ("ALSA: firewire-motu: notify event for parameter change in register DSP model") Signed-off-by: Takashi Sakamoto o-takashi@sakamocchi.jp --- sound/firewire/motu/motu-hwdep.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/sound/firewire/motu/motu-hwdep.c b/sound/firewire/motu/motu-hwdep.c index 9c2e457ce692..a900fc0e7644 100644 --- a/sound/firewire/motu/motu-hwdep.c +++ b/sound/firewire/motu/motu-hwdep.c @@ -16,6 +16,14 @@
#include "motu.h"
+static bool has_dsp_event(struct snd_motu *motu) +{ + if (motu->spec->flags & SND_MOTU_SPEC_REGISTER_DSP) + return (snd_motu_register_dsp_message_parser_count_event(motu) > 0); + else + return false; +} + static long hwdep_read(struct snd_hwdep *hwdep, char __user *buf, long count, loff_t *offset) { @@ -25,8 +33,7 @@ static long hwdep_read(struct snd_hwdep *hwdep, char __user *buf, long count,
spin_lock_irq(&motu->lock);
- while (!motu->dev_lock_changed && motu->msg == 0 && - snd_motu_register_dsp_message_parser_count_event(motu) == 0) { + while (!motu->dev_lock_changed && motu->msg == 0 && !has_dsp_event(motu)) { prepare_to_wait(&motu->hwdep_wait, &wait, TASK_INTERRUPTIBLE); spin_unlock_irq(&motu->lock); schedule(); @@ -55,7 +62,7 @@ static long hwdep_read(struct snd_hwdep *hwdep, char __user *buf, long count, count = min_t(long, count, sizeof(event)); if (copy_to_user(buf, &event, count)) return -EFAULT; - } else if (snd_motu_register_dsp_message_parser_count_event(motu) > 0) { + } else if (has_dsp_event(motu)) { size_t consumed = 0; u32 __user *ptr; u32 ev; @@ -94,8 +101,7 @@ static __poll_t hwdep_poll(struct snd_hwdep *hwdep, struct file *file, poll_wait(file, &motu->hwdep_wait, wait);
spin_lock_irq(&motu->lock); - if (motu->dev_lock_changed || motu->msg || - snd_motu_register_dsp_message_parser_count_event(motu) > 0) + if (motu->dev_lock_changed || motu->msg || has_dsp_event(motu)) events = EPOLLIN | EPOLLRDNORM; else events = 0;
After further investigation, I realize that the total number of elements in array is not enough to store all of related messages from device. This commit refines meter array and message parser.
In terms of channel identifier, register DSP models are classified to two categories:
1. the target of output is selectable
828mk2, 896hd, and Traveler are in the category. They transfer messages with channel identifier between 0x00 and 0x13 for input meters, therefore 20 elements are needed to store.
On the other hand, they transfer messages with channel identifier for one pair of output meters. The selection is done by asynchronous write transaction to offset 0x'ffff'f000'0b2c. The table for relationship between written value and available identifiers is below:
============= =============== written value identifier pair ============= =============== 0x00000b00 0x80/0x81 0x00000b01 0x82/0x83 ... ... 0x00000b0b 0x96/0x97 ... ... 0x00000b10 0xa0/0xa1 ... ... 0x00000b3f 0xfe/0xff ... ... greater 0xfe/0xff ============= ===============
Actually in the above three models, 0x96/0x97 pair is the maximum. Thus the number of available output meter is 24.
2. all of output is available
8 pre, Ultralite, Audio Express, and 4 pre are in the category. They transfer messages for output meters without any selection. The table for available identifier for each direction is below:
============== ========= ========== model input output ============== ========= ========== 8 pre 0x00-0x0f 0x82-0x8d Ultralite 0x00-0x09 0x82-0x8f Audio Express 0x00-0x09 0x80-0x8d 4 pre 0x00-0x09 0x80-0x8d ============== ========= ==========
Some of available identifiers might not be used for actual output meters.
Anyway, 24 plus 24 elements accommodate the input/output meters.
I note that isochronous packet from V3HD/V4HD deliver no message. Notification by asynchronous transaction to registered address seems to be used for the purpose as well as for change of mixer parameter.
Signed-off-by: Takashi Sakamoto o-takashi@sakamocchi.jp --- include/uapi/sound/firewire.h | 5 ++++- .../motu/motu-register-dsp-message-parser.c | 14 +++++++++----- 2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/include/uapi/sound/firewire.h b/include/uapi/sound/firewire.h index e52a97b3ceaa..68eb0e43c052 100644 --- a/include/uapi/sound/firewire.h +++ b/include/uapi/sound/firewire.h @@ -141,7 +141,10 @@ struct snd_firewire_tascam_state { * up to 12. */
-#define SNDRV_FIREWIRE_MOTU_REGISTER_DSP_METER_COUNT 40 +#define SNDRV_FIREWIRE_MOTU_REGISTER_DSP_METER_INPUT_COUNT 24 +#define SNDRV_FIREWIRE_MOTU_REGISTER_DSP_METER_OUTPUT_COUNT 24 +#define SNDRV_FIREWIRE_MOTU_REGISTER_DSP_METER_COUNT \ + (SNDRV_FIREWIRE_MOTU_REGISTER_DSP_METER_INPUT_COUNT + SNDRV_FIREWIRE_MOTU_REGISTER_DSP_METER_OUTPUT_COUNT)
/** * struct snd_firewire_motu_register_dsp_meter - the container for meter information in DSP diff --git a/sound/firewire/motu/motu-register-dsp-message-parser.c b/sound/firewire/motu/motu-register-dsp-message-parser.c index cbc06b3b70f6..0c587567540f 100644 --- a/sound/firewire/motu/motu-register-dsp-message-parser.c +++ b/sound/firewire/motu/motu-register-dsp-message-parser.c @@ -335,11 +335,15 @@ void snd_motu_register_dsp_message_parser_parse(struct snd_motu *motu, const str else pos = b[MSG_METER_IDX_POS_4PRE_AE];
- if (pos < 0x80) - pos &= 0x1f; - else - pos = (pos & 0x1f) + 20; - parser->meter.data[pos] = val; + if (pos < SNDRV_FIREWIRE_MOTU_REGISTER_DSP_METER_INPUT_COUNT) { + parser->meter.data[pos] = val; + } else if (pos >= 0x80) { + pos -= (0x80 - SNDRV_FIREWIRE_MOTU_REGISTER_DSP_METER_INPUT_COUNT); + + if (pos < SNDRV_FIREWIRE_MOTU_REGISTER_DSP_METER_COUNT) + parser->meter.data[pos] = val; + } + // The message for meter is interruptible to the series of other // types of messages. Don't cache it. fallthrough;
In command DSP models, one meter information consists of 4 bytes for IEEE 764 floating point (binary32). In previous patch, it is exported to userspace as 32 bit storage since the storage is also handled in ALSA firewire-motu driver as well in kernel space in which floating point arithmetic is not preferable. On the other hand, ALSA firewire-motu driver doesn't perform floating point calculation. The driver just gather meter information from isochronous packets and fill structure fields for userspace.
In 'header' target of Kbuild, UAPI headers are processed before installed. In this timing, #ifdef macro with __KERNEL__ is removed. This mechanism is useful in the case so that the 32 bit storage can be accessible as u32 type in kernel space and float type in user space. We can see the same usage in ''struct acct_v3' in 'include/uapi/linux/acct.h'.
This commit is for the above idea. Additionally, due to message protocol, meter information is filled with 0xffffffff in the end of period but 0xffffffff is invalid as binary32. To avoid confusion in userspace application, the last two elements are left without any assignment.
Suggested-by: Takashi Iwai tiwai@suse.de Signed-off-by: Takashi Sakamoto o-takashi@sakamocchi.jp --- include/uapi/sound/firewire.h | 8 +++++--- sound/firewire/motu/motu-command-dsp-message-parser.c | 7 +++++-- 2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/include/uapi/sound/firewire.h b/include/uapi/sound/firewire.h index 68eb0e43c052..39cf6eb75940 100644 --- a/include/uapi/sound/firewire.h +++ b/include/uapi/sound/firewire.h @@ -248,12 +248,14 @@ struct snd_firewire_motu_register_dsp_parameter { * * The structure expresses the part of DSP status for hardware meter. The 32 bit storage is * estimated to include IEEE 764 32 bit single precision floating point (binary32) value. It is - * expected to be linear value (not logarithm) for audio signal level between 0.0 and +1.0. However, - * the last two quadlets (data[398] and data[399]) are filled with 0xffffffff since they are the - * marker of one period. + * expected to be linear value (not logarithm) for audio signal level between 0.0 and +1.0. */ struct snd_firewire_motu_command_dsp_meter { +#ifdef __KERNEL__ __u32 data[SNDRV_FIREWIRE_MOTU_COMMAND_DSP_METER_COUNT]; +#else + float data[SNDRV_FIREWIRE_MOTU_COMMAND_DSP_METER_COUNT]; +#endif };
#endif /* _UAPI_SOUND_FIREWIRE_H_INCLUDED */ diff --git a/sound/firewire/motu/motu-command-dsp-message-parser.c b/sound/firewire/motu/motu-command-dsp-message-parser.c index 18689fcfb288..9efe4d364baf 100644 --- a/sound/firewire/motu/motu-command-dsp-message-parser.c +++ b/sound/firewire/motu/motu-command-dsp-message-parser.c @@ -141,12 +141,15 @@ void snd_motu_command_dsp_message_parser_parse(struct snd_motu *motu, const stru ++parser->fragment_pos;
if (parser->fragment_pos == 4) { + // Skip the last two quadlets since they could be + // invalid value (0xffffffff) as floating point + // number. if (parser->value_index < - SNDRV_FIREWIRE_MOTU_COMMAND_DSP_METER_COUNT) { + SNDRV_FIREWIRE_MOTU_COMMAND_DSP_METER_COUNT - 2) { u32 val = (u32)(parser->value >> 32); parser->meter.data[parser->value_index] = val; - ++parser->value_index; } + ++parser->value_index; parser->fragment_pos = 0; }
participants (1)
-
Takashi Sakamoto