Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1719966ybt; Mon, 15 Jun 2020 07:45:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwNxWb62Dq5Jj26Jpo4DOH+XI7swKffaibCH92JecI4S8qps9eWpbVGwkS6DVgl/oDGKSJe X-Received: by 2002:a17:906:3483:: with SMTP id g3mr25554538ejb.373.1592232339595; Mon, 15 Jun 2020 07:45:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592232339; cv=none; d=google.com; s=arc-20160816; b=x4pgNkIqJIgazJBxuJN7wdy4uq6xELZB97CjR/l3epODPPet2fQ0FU2LGdBzQKTlZ6 LZFUjoNLbIKMd6Iu/Q94pz2wX6pAImj4npS6tkojp5uiUWZ3YQAWy3vX5mKS2fwx3pSe s+QC3XA7awA5qrWBwDMinJt4GtwbUkO5AiDN+wEx0NTbxFzrIqSFb2OZ0WQTJJEKuQqS g1+5qJ2fb33PActDvuyNB9jMR+9IIUs6Mg8iq4+4ZmZAaER3EbuOJJT9CTH52JNCFLd8 Y4RJ7HdBhpN/yd0YmmoftXIzgXnIw4+jyrQyIVd+/qaihcSRbOy+Ibufzf6ogAls/r4t DfDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=1guws3K5uVRzygOwXT+kMdJiPYoHgq0AMd5yMeBAj4c=; b=p9y4tw73xx/BneVdLlO2sHbtYB0GW4q8/MZgns1stq45rQ0i3zfv+WNMTdFH0AZ8w2 af7cRulCOh6qSBz03Ub7NkrXs8eBDlzBx9Q7ws0KrtdbH9tf7FPBXLWsUGEoED3U/Ecu GbqX+2Yob67BmvT7mYysCOVXJ6JAFyqkKAbhfVrE6yJ4MdtrCeol8qp0FtCAdEMI9qx1 OiAmFimTsfpTg2HcSOYXwzMA9bUSzWo0dGgXghK5QIANmjAfVDNjuB0ODQUR0n2l+rvA Jk8DVrn2T+ysEYtR/hbdR/4WC2a/033BN5SVIRb0HSRTjoGb6C8JtK1dUm79DjwVcVz2 4AwQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e2si8452611edy.212.2020.06.15.07.45.16; Mon, 15 Jun 2020 07:45:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730721AbgFOOnO (ORCPT + 99 others); Mon, 15 Jun 2020 10:43:14 -0400 Received: from verein.lst.de ([213.95.11.211]:33796 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730405AbgFOOnO (ORCPT ); Mon, 15 Jun 2020 10:43:14 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id D8AE268AFE; Mon, 15 Jun 2020 16:43:10 +0200 (CEST) Date: Mon, 15 Jun 2020 16:43:10 +0200 From: Christoph Hellwig To: Arnd Bergmann Cc: Christoph Hellwig , Al Viro , Luis Chamberlain , Linux ARM , the arch/x86 maintainers , "open list:BROADCOM NVRAM DRIVER" , Parisc List , linuxppc-dev , linux-s390 , sparclinux , Linux FS-devel Mailing List , linux-arch , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 2/6] exec: simplify the compat syscall handling Message-ID: <20200615144310.GA15101@lst.de> References: <20200615130032.931285-1-hch@lst.de> <20200615130032.931285-3-hch@lst.de> <20200615141239.GA12951@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 15, 2020 at 04:40:28PM +0200, Arnd Bergmann wrote: > > ld: arch/x86/entry/syscall_x32.o:(.rodata+0x1040): undefined reference to > > `__x32_sys_execve' > > ld: arch/x86/entry/syscall_x32.o:(.rodata+0x1108): undefined reference to > > `__x32_sys_execveat' > > make: *** [Makefile:1139: vmlinux] Error 1 > > Ah, I see: it's marked x32-only, so arch/x86/entry/syscall_x32.c > uses the __x32 prefix instead of the __x64 one. Marking it 'common' > instead would make it work, but also create an extra entry point > for native processes, something that commit > 6365b842aae4 ("x86/syscalls: Split the x32 syscalls into their own table") > was trying to avoid. Marking it common also doesn't compile at all because __NR_execve and __NR_execveat get redefined in unistd_64.h. I then tried to rename the x32 versions, which failed in yet another way. At that point I gave up instead of digging myself into a deeper hole..