From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12914 Path: news.gmane.org!.POSTED!not-for-mail From: Natanael Copa Newsgroups: gmane.linux.lib.musl.general Subject: Re: broken __kernel_mode_t affecting some big endian archs Date: Thu, 14 Jun 2018 13:19:31 +0200 Message-ID: <20180614131931.1a7a768a@ncopa-desktop.copa.dup.pw> References: <20180614005442.GK1392@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1528975067 27858 195.159.176.226 (14 Jun 2018 11:17:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 14 Jun 2018 11:17:47 +0000 (UTC) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-12930-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jun 14 13:17:43 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1fTQG4-00077l-PL for gllmg-musl@m.gmane.org; Thu, 14 Jun 2018 13:17:40 +0200 Original-Received: (qmail 3273 invoked by uid 550); 14 Jun 2018 11:19:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 3244 invoked from network); 14 Jun 2018 11:19:47 -0000 In-Reply-To: <20180614005442.GK1392@brightrain.aerifal.cx> X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-alpine-linux-musl) Xref: news.gmane.org gmane.linux.lib.musl.general:12914 Archived-At: On Wed, 13 Jun 2018 20:54:42 -0400 Rich Felker wrote: > It's been semi-known for a long time (I say semi-, because nobody's > had the setup to test most of them well, or at least nobody I'm > communicating with regularly) that some archs are failing libc-test > sysvipc tests. I think I've tracked down the root cause. > > Linux defined __kernel_mode_t as short on some old archs, and used it > in place of mode_t in the ipc_perm structure. The field is padded out > to 32 bits, so on little endian archs it's no problem for us to just > (as we do) ignore the incorrect type and declare the structure with > mode_t, as POSIX requires. However on big-endian archs, the padding is > on the wrong side and this trick doesn't work. > > On MIPS we fixed a similar issue in struct stat, where dev_t was > incorrectly padded, with a fixup in syscall_arch.h. However this time > a large number of archs are affected, and patching them all up > individually seems nasty. > > My leaning is to have syscall_arch.h expose a macro indicating the > bug, and have msgctl, semctl, and shmctl each do the fixup if it's > set. > > FWIW the affected archs seem to be (only in big endian variants): > - ARM > - M68k (in-progress port) > - Microblaze > - SH > - Sparc (future port) Is s390s affected too? -nc > Thoughts? > > Rich