From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.3 required=3.0 tests=AWL,BAYES_00,BODY_8BITS, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 77AE21F461 for ; Thu, 16 May 2019 20:56:42 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type :content-transfer-encoding; q=dns; s=default; b=fxS1fqj1hG08vucq mA3x+MXJ6n2zlywTWvgZVIMmZRP7hAMxRXw9e6jq9ArykgrlFx/1n0QebSAc751X LpG8+Jsk6vaJqiKSf23PE7mo9lnBx2lE2Pcxq6y3byUO1ITh4GzCdT4l7h/leof+ 3hJoF5zLGi+RqPxNd1NKyatzrZ0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type :content-transfer-encoding; s=default; bh=vrIqXBgG328lvvceqyuTuQ 5dCMY=; b=pG42fRSuYRziCOK4FJgBNJLBlf6kSxKRHLd1TkcO04xn1rs3jslKWC TV7L3dqggKBOqUdTom6uqRaGdU38ryybODDZdKZg7pPB72uoq8KDKfbZIWC15yxp q0r+R6QAOFzRO/DXCEI9TKpKpzRC/oFTJlPvJ9+8SbHK2mkLDlVN0= Received: (qmail 37889 invoked by alias); 16 May 2019 20:56:40 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 37779 invoked by uid 89); 16 May 2019 20:56:40 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-qk1-f196.google.com MIME-Version: 1.0 References: <20190510102713.udgjb6ilygibgd5x@sghpc.golosunov.pp.ru> <20190510131938.fonlmcf3mzs6qypr@sghpc.golosunov.pp.ru> <20190516194147.b662wrsv4jco3wt6@sghpc.golosunov.pp.ru> In-Reply-To: <20190516194147.b662wrsv4jco3wt6@sghpc.golosunov.pp.ru> From: Arnd Bergmann Date: Thu, 16 May 2019 22:56:20 +0200 Message-ID: Subject: Re: Update kernel-features.h files for Linux 5.1 To: Stepan Golosunov Cc: Joseph Myers , GNU C Library , Thomas Gleixner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 16, 2019 at 9:41 PM Stepan Golosunov w= rote: > > 16.05.2019 =D0=B2 09:59:40 +0200 Arnd Bergmann =D0=BD=D0=B0=D0=BF=D0=B8= =D1=81=D0=B0=D0=BB: > > On Fri, May 10, 2019 at 3:19 PM Stepan Golosunov wrote: > > > > (I also think that ipc with IPCOP_semtimedop was accidentally made = to > > > > behave like semtimedop_time64 in 32-bit builds of linux 5.1. But t= hat > > > > would be a kernel bug.) > > > > Can you elaborate? The code I see in mainline is > > > > case SEMTIMEDOP: > > if (IS_ENABLED(CONFIG_64BIT) || !IS_ENABLED(CONFIG_64BI= T_TIME)) > > return ksys_semtimedop(first, ptr, second, > > (const struct __kernel_timespec __user = *)fifth); > > else if (IS_ENABLED(CONFIG_COMPAT_32BIT_TIME)) > > return compat_ksys_semtimedop(first, ptr, secon= d, > > (const struct old_timespec32 __user *)f= ifth); > > else > > return -ENOSYS; > > > > Since both CONFIG_64BIT_TIME and CONFIG_COMPAT_32BIT_TIME > > are always set on 32-bit architectures, SEMTIMEDOP passes > > an old_timespec32 argument here. Am I missing something? > > If CONFIG_64BIT_TIME is set then there is no problem. But I do not > see where it is set. (The patch to set it to y was merged only now > and is not in 5.1.) And if it's not set, then ipc and socketcall are > broken. Oh, I see it now. So the bug was actually much worse than I thought, since we did not enable CONFIG_64BIT_TIME at all, only CONFIG_COMPAT_32BIT_TIME. I assumed that only the nanosecond mangling in compat mode was broken. The problem is that in commit 00bf25d693e7 ("y2038: use time32 syscall names on 32-bit"), I turned on CONFIG_COMPAT_32BIT_TIME unconditionally, when I should have turned on CONFIG_64BIT_TIME or ARCH_HAS_64BIT_TIME instead. So indeed both ipc(SEMTIMEDOP, ...) and socketcall(SYS_RECVMMSG, ...) are broken in linux-5.1 with 32-bit architectures. My testing failed to catch those because I used a musl libc as a base that was already using semtimedop() and recvmmsg() as direct syscalls, and those are not affected. The fix has made it into mainline now for v5.2-rc1, but not yet v5.1.y. Greg, can you add this commit for the next v5.1.y stable kernel to fix the regression? f3d964673b2f ("y2038: Make CONFIG_64BIT_TIME unconditional") Arnd