From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14906 invoked from network); 8 Oct 2021 09:25:11 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 8 Oct 2021 09:25:11 -0000 Received: (qmail 5923 invoked by uid 550); 8 Oct 2021 09:25:09 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 5905 invoked from network); 8 Oct 2021 09:25:08 -0000 X-Gm-Message-State: AOAM532qgvfKhBFwggdt6WOWsd5I4ellcxutbncVMLPmGeam6O9dsJSP usx1e6FeaWSHFzcQ3gbcn1FlNYjMKmpQ4/vQh4I= X-Google-Smtp-Source: ABdhPJxbI9FlI5wrrkveY0OcRvKfdHT6ALl6Zio9wUi7opJy24FK9gPvC5um/n8zfpgrtkT+TFtW3m/pBAMoS+zbbfg= X-Received: by 2002:adf:a3da:: with SMTP id m26mr2544913wrb.336.1633685096034; Fri, 08 Oct 2021 02:24:56 -0700 (PDT) MIME-Version: 1.0 References: <20191211212025.1981822-1-arnd@arndb.de> <20191211212025.1981822-9-arnd@arndb.de> <29QBMJU8DE71E.2YZSH8IHT5HMH@mforney.org> <20211007160634.GB7074@brightrain.aerifal.cx> <20211007165158.GC7074@brightrain.aerifal.cx> In-Reply-To: From: Arnd Bergmann Date: Fri, 8 Oct 2021 11:24:39 +0200 X-Gmail-Original-Message-ID: Message-ID: To: musl@lists.openwall.com 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 Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:iqJneCG/bmaZQYhvgHS2ugHL9gtskYIzPKK0d6Fwaa3aBtGK1Zf k6io8pjytcuhSlxSBWt9WM+lb7eC8ZOoYoLIhkTtggCKPTH25TDlsjLVujk20W2o6Hdleyx In+qqufhm508w0fHI4SqodezxnR6NuM4/4BA5gfLLaWXbYlXqPZuw82witbEHi03+dOD+zP F9wN7NCfYWyDYEwyDBmWg== X-UI-Out-Filterresults: notjunk:1;V03:K0:Cjhv85kVEbs=:uOMCccUz6ERcTWOQXpW7VS BtePwiyr6/3C9Eoihd6HtY5zGnnuI/IHgpXR8+YAULsEactI9L8zWES4CbgBjmR2ViV8C8GxE hipWDHpJY4TcYjPbSe2IY3BjdEBTYkSUrtqaXQdgLmmETmCz771s+7Z7FYWS9oalD37hrdxHw hjW34nPfSAfpxEOgTsg50aQ4PaaBEhPrEtXMkgchqZdwV/9TAqcSRYIIuPmYldefkAN0QF4F3 +1aq4S+9sLWmMfYVwTnEtbE01cZybJMBBRHO+L/jCbJO1CnD08DmqdvhAojpkFQ0meScl4nbu AVMvedGnDUXkE/2Vkb8Pz5H+xqJRkV2EuX987RngxLyQ3UhmJezcNXCs9gNx4wjfFko43Bkkr CadDJRUiPCUmBA0Bgy687+sKgg+zxLfQHxMY1NgGs2ihktaPZnLZ3q/zvC9eXI6bWADfsTUUa 9/dTV8QvI9d95PZfeVVcFxPG+0u35emtzqiyYo0Q1j/QEDja/cqeIDMiEzMl6NjsIO1beB/4X 0TahWiCH0Vw8h2K/C2NNlrQXUjNHHUkCPwv3mAMuGrSC0k18p0fHQIQU/xqMdeZ9FEDYovCBh Iji2cJjYJtonSISjtNo1KRvsuIN+GodjTaZWizNEUyuDw+INqQBfXa0QxKZepw9VoQPpG0AHy 75tlRFF8iTyFH2Z0GwmLgcZAP9AKnEMYh6aCqTAXkQlPHyQccCUxvlX7OynOlp7AG7wjbK0Y2 X6gNMzdNAz0JUmb+PepTlriDlsqxKxPo9GQuTPMQbCOUBrvaVL77/puBLqY/mU/Hyb/wdYOe5 6PKiau4OBUUqNG+7aaygkffH7+Q4jTE3WoZ2Xmp48dqbkqvryX9g4iN0teGWB3bscAMc7jiK1 Ct5aAhdvwPEw1eBaXGPg== Subject: Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control On Fri, Oct 8, 2021 at 10:43 AM 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: > > @@ -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