From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12918 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: broken __kernel_mode_t affecting some big endian archs Date: Thu, 14 Jun 2018 22:00:23 -0400 Message-ID: <20180615020023.GM1392@brightrain.aerifal.cx> References: <20180614005442.GK1392@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="/2994txjAzEdQwm5" X-Trace: blaine.gmane.org 1529027919 8850 195.159.176.226 (15 Jun 2018 01:58:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 15 Jun 2018 01:58:39 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12934-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jun 15 03:58:35 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 1fTe0T-00022s-7m for gllmg-musl@m.gmane.org; Fri, 15 Jun 2018 03:58:29 +0200 Original-Received: (qmail 24102 invoked by uid 550); 15 Jun 2018 02:00:36 -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 24079 invoked from network); 15 Jun 2018 02:00:35 -0000 Content-Disposition: inline In-Reply-To: <20180614005442.GK1392@brightrain.aerifal.cx> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12918 Archived-At: --/2994txjAzEdQwm5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jun 13, 2018 at 08:54:42PM -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) > > Thoughts? Here's a draft of the fix, just for shmctl and not including the SHM_STAT or SHM_STAT_ALL operations. Rich --/2994txjAzEdQwm5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="shmfix.diff" diff --git a/src/ipc/shmctl.c b/src/ipc/shmctl.c index e2879f2..3659807 100644 --- a/src/ipc/shmctl.c +++ b/src/ipc/shmctl.c @@ -4,9 +4,24 @@ int shmctl(int id, int cmd, struct shmid_ds *buf) { +#ifdef SYSCALL_IPC_BROKEN_MODE + struct shmid_ds tmp; + if (cmd == IPC_SET) { + tmp = *buf; + tmp.shm_perm.mode *= 0x10000U; + buf = &tmp; + } +#endif #ifdef SYS_shmctl - return syscall(SYS_shmctl, id, cmd | IPC_64, buf); + int r = __syscall(SYS_shmctl, id, cmd | IPC_64, buf); #else - return syscall(SYS_ipc, IPCOP_shmctl, id, cmd | IPC_64, 0, buf, 0); + int r = __syscall(SYS_ipc, IPCOP_shmctl, id, cmd | IPC_64, 0, buf, 0); +#endif +#ifdef SYSCALL_IPC_BROKEN_MODE + if (r < 0) return __syscall_ret(r); + if (cmd == IPC_STAT) { + buf->shm_perm.mode >>= 16; + } + return r; #endif } --/2994txjAzEdQwm5--