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 29675 invoked from network); 8 Oct 2021 11:46:16 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 8 Oct 2021 11:46:16 -0000 Received: (qmail 28508 invoked by uid 550); 8 Oct 2021 11:46:14 -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 28487 invoked from network); 8 Oct 2021 11:46:14 -0000 X-Gm-Message-State: AOAM5318vOEO5H9MwX16oVH5uow3Fgp3WvhvYKsnYblWdZPD4P4YR1tJ J7PgJVXudywBMtQkdSlh139BWG94D5ZqzJ6aoxA= X-Google-Smtp-Source: ABdhPJyHo72NGMxQuQyxjtT+5nQCpXx6NLGzNhCQiYTfEj1ygK3qKqvFSanv94vqY7Xo8TEpIVxc2neyx1BN+BCLKCI= X-Received: by 2002:a05:6000:1561:: with SMTP id 1mr3318468wrz.369.1633693561692; Fri, 08 Oct 2021 04:46:01 -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 13:45:45 +0200 X-Gmail-Original-Message-ID: Message-ID: To: musl@lists.openwall.com 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 Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:heGSKwrID13WbxecLZktL2HrfQTM+5hfAGgDDtg60LLcWlyA4+3 y+tUNep5/tMjPb8iCNg2HZwa21auA+uoSWlBbCjbJUXuTVtRGEt7s6BqlnyTRqzf2+MUYzn DpEjdz2fQhY5uxJEVLZxN9NDYg02OBg46vTOJhItnEmsU2m42zV8CaSF9WTFIcgOB2MEn7A YBUWTTN/nGXd5EGZqqp5g== X-UI-Out-Filterresults: notjunk:1;V03:K0:b9ws2eSVO9Q=:+uYjYzJAJHOd1wWoOaoYpO 9AzSY9JZm0uSZI9zHQRAG20iR3LYeBqT01gE6U4xRaft5bSJzH+S+WP3LTgJ/2yptlERTxYBz wydg/C5EfT+0SPUoeVZSzt53Y54PY75013h716cpo2U6H4dNrXBq/+26vQopYNE6YORersMx5 viQ6UTqlGJbsykTIX2QH8HQD6SYDnNlOmf/wUsmRd9DJ3j+fPrSi8LnGUR08cqvIfPON3C0+b tXSo5Id54J0WB5QWEinUNukk0ngFyjeTb8NyzuXAyLZYYVgidxVdAeFeNEKK0kBfxo3dY9Mit D1/9aE9CnjR+riDa/3y4U8WNF4EmXxSGIrScizKq25zNV3CuuRvDXCKplqfIDzNSf8I3+qSkG J0DsVxBYXLCWVGt3OGjI6XnzahDbGFnbXIsW6hYN0AswLa0y845ZK/2dGoOp1eWiMnXjsh9dL 8f7miEsqYVlVYClSRB+nuhfPFpPKEq6OAJ1ilgHduAGD9JkGOe/Tw1LeOihgxlalP/GKHvQ62 Nt+2uvNB4PTBkLOndqZvwlVf34Q3L9nsXRXLasYdBkGTNpZWeUbBaaiaRD4PnTghysnWyodqn 5NqHKun8sQ/Nv/IIuN3B+yoX30FjXsN7nvbJJ25D+ebhPzLralklPLtlK4J2e+qX4tcn+f/gl BzbvplDc9GpyRUjxN+aMYdq0kZugj7wO/Yob43zCZi8V9jTHPe2CM8f9DveJdTtLbW0nhldaA k7Do7ztc+LwDQIlUT7Xa9SpSdK8DohukE9HPwhvpPAKWCFT0lCwp7JZDbzbxLwjfkrAt0kDhs X+JAqV66FF5XBJEbPLqxMI8Fai6Ox3TijADDV4p77ADnHaPNf2CxCmFTP5AEL8O2pzRX8rHLD ChvInmiHjGRutjYjA1lA== 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 1:11 PM Takashi Iwai 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