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 4679 invoked from network); 18 Oct 2021 15:27:08 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 18 Oct 2021 15:27:08 -0000 Received: (qmail 9872 invoked by uid 550); 18 Oct 2021 15:27:04 -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 9839 invoked from network); 18 Oct 2021 15:27:03 -0000 X-Gm-Message-State: AOAM531rOr6LTMSAPuaHFHL+9wDRBkquWM/noLszmY33WdMLDyBO/xf+ Jl2si0YC8LImXAwCuUwf/mRpfl+RaykjlaFKUp8= X-Google-Smtp-Source: ABdhPJwZTryrYp+pNKyx1vAYwOjs14JDwumKgWlVCbFtT0ihV++n2REC55gSAlRYQLZatyLWyLhfYAzetvIOnch0TxY= X-Received: by 2002:adf:f481:: with SMTP id l1mr35106062wro.411.1634570811678; Mon, 18 Oct 2021 08:26:51 -0700 (PDT) MIME-Version: 1.0 References: <20211007160634.GB7074@brightrain.aerifal.cx> <20211007165158.GC7074@brightrain.aerifal.cx> <20211008120736.GF7074@brightrain.aerifal.cx> <20211018144259.GK7074@brightrain.aerifal.cx> <20211018150824.GL7074@brightrain.aerifal.cx> In-Reply-To: <20211018150824.GL7074@brightrain.aerifal.cx> From: Arnd Bergmann Date: Mon, 18 Oct 2021 17:26:35 +0200 X-Gmail-Original-Message-ID: Message-ID: To: musl@lists.openwall.com 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 Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:hKcwD1ObgreF18mBllQbc9jYk4SaC11g8fbOVMIyyCICnIoDEXR rwjMnJwOwXXaYP4IimDaza1FKk05V1TjfeHv89/aiKTTQUgYYSureYRaUVJ0sO09ExhMckk EOn4CGjaOXCWodk6V7CGHVgQG4IMveL2+fK0RF1HNMnUPamvaZFfrZTpXNWT9bXawSTd/Oo tteNU4vGhjaHxfvB6vz6w== X-UI-Out-Filterresults: notjunk:1;V03:K0:QrJ3cAUGmPA=:8xdR4Tg9iZpBThitm0am7g n6DEv0PCX70nGZneTDuyeP6lMn5f0a8EuRHEEzaboRD/QN6CxLLMndbGEunXSUwFPtbm7uraU CfUZ8CCA0RCm98Vma1yV80LqhWhe5AQyfvyG7+Fnk9fghy7mkX6RQsFrZIRw830orBDvcgcLy DIYBLFAKUOcY8VrfeKxS7qYoXR0DqM76i/2g5r+SdRSim7RFD/gn+tiMGB8DGRcit1D5DZwDe 8GczzRufDdNQzaTWawdkrJMxvxlxeNZcD4Wmi1h5dEbI3lrix4GAVjEYgcyGHcjUHdm6eDUS2 syAjFr3rOJjUDnJaSnJG25pgq1Ai4BtyNLzS5VsRnv7LTE19qbfxu3rbzF59/pA/IYVagyeFK ePQKEInbDzoorMHkr4WXCtq7MPI8EwgqDSMqEUhTulm/TNfQP7pF9MzRyQB93FWO5xEpdWcPF tC1KJAxAP+/US54zyNhkv1/o1PJI8hE/4+1igbwK9fMKnrWR+toMvSjZN1t5JmKErCCAnhHIQ jXUS7QB+glR4NgzAa5r36qdpYwRBbfcpZFZVvv4ul91qPLkW8fUGxqYdor36lRmmHQpDp4STm LtIg++o2wsjl+/K8/w3Jw6z1zZXtpa/YVGOdMf5EkdtBQihPJGae2F8Lu6gR5vEbRNygZ9VeH 4qxgmp9iLD0c7FIGkmlwhQlQPLxFwy2hO+VjvZxPIHji7cvwNyUA2vHzd9ePIkyhQ8uAGs1xj mTrW2cWmXzxVFrzR9IfVUGbrnMRb5n60zq10K5POtHqaFGe3tUG6/QNRJ5kjBcl4jV1swMkz2 kVa5KFZZE3watM1bWqMnkMyz4fp5NqwJ3jNi7RTeJUEFUopen5j3rAktv9F9M55nSowwa0n+Q Jj7ITypBPlT/rmpbjyVQ== Subject: Re: [musl] Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control On Mon, Oct 18, 2021 at 5:08 PM Rich Felker 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