Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp6763695ybf; Fri, 6 Mar 2020 04:09:56 -0800 (PST) X-Google-Smtp-Source: ADFU+vvi99NVkeos2oynOGeSswrMaL/MDU68GI1KNuB1F/ZDuZ3cgKAoYT6H+njmgT3gGb7Ekuw5 X-Received: by 2002:a9d:75d7:: with SMTP id c23mr2024694otl.73.1583496596123; Fri, 06 Mar 2020 04:09:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583496596; cv=none; d=google.com; s=arc-20160816; b=VPFuK9U1h31NO2bh5cOYb5guoloHvEA/gquDGsrl4pxDP8/SC9FVNAT7rgGhCzlYeK IlfjT5Ruf9yHYGfGOgQ2Y6rrA+G1+SD4XcFIEcEmINzOhkCuWRmcfAnYzXCCes8SJxJM 8MDdYC3DTok4KZpga1JyrJlQEtIJl6ys4zewYdv8Dtktla5PRdDhBafWzJLProloh/dm 0+1SHTpS5aDajBGRo46G2EjfGHvue0jWSzPAWGnalK45MntGOmmpea+NGnPi8tUcNSbj cvP4LbpkhhwOYYArF9B+ojp2Ibb4LLL0Zun5TbJFxaH5cYkBL1F28vTsFsIBJUXHNwto 59Xw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:in-reply-to:date:references:subject:cc:to:from; bh=GvVsIzs5GgWqQbtFam2fCqWZldFPKuPRHldrDew8kjY=; b=v9JapSRmoMCfwYhjOAMx9egepFelJaCmK6S9FcJXX8RosIM8K9bKKFWBEwr2I76+XT bjVP17XlEmKPnN/RG5O3oLcH6beO2MDOvWR2vSNzGsrvDBfIndWzYanzR5FppcgwpLIO vMbz9z9wuGSClFV9KP5o19m9aLXyEVEBV9JoBtx6r0Wn8sDooexq84c1ZB3661fQapy6 ZrZrmLBX1DQd/TpIs2Lraorh1qt70lqrAyD5EusxDrnuKoG52yu+MKmxEzsE+OXIrY2X wPsGNDhJEWvjPPQaHaRcbUgFE704TMX+mJmPjtOsi2hnYAzFAn/ygWflfd6xAbn0EmLf lZjw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z23si1097725oti.34.2020.03.06.04.09.43; Fri, 06 Mar 2020 04:09:56 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726579AbgCFMJW convert rfc822-to-8bit (ORCPT + 99 others); Fri, 6 Mar 2020 07:09:22 -0500 Received: from albireo.enyo.de ([37.24.231.21]:58366 "EHLO albireo.enyo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726300AbgCFMJW (ORCPT ); Fri, 6 Mar 2020 07:09:22 -0500 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1jABmy-0002N2-LF; Fri, 06 Mar 2020 12:09:12 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1jABlN-0005No-Ln; Fri, 06 Mar 2020 13:07:33 +0100 From: Florian Weimer To: YunQiang Su Cc: Laurent Vivier , torvalds@linux-foundation.org, Greg KH , akpm@linux-foundation.org, Al Viro , James Bottomley , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, libc-alpha@sourceware.org Subject: Re: [PATCH] binfmt_misc: pass binfmt_misc P flag to the interpreter References: <20200306080905.173466-1-syq@debian.org> <87r1y53npd.fsf@mid.deneb.enyo.de> <8441f497-61eb-5c14-bf1e-c90a464105a7@vivier.eu> <87mu8t3mlw.fsf@mid.deneb.enyo.de> <40da389d-4e74-2644-2e7c-04d988fcc26f@vivier.eu> <87v9nhzp6w.fsf@mid.deneb.enyo.de> Date: Fri, 06 Mar 2020 13:07:33 +0100 In-Reply-To: (YunQiang Su's message of "Fri, 6 Mar 2020 19:48:35 +0800") Message-ID: <87r1y5zny2.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * YunQiang Su: > Florian Weimer 于2020年3月6日周五 下午7:42写道: >> >> * YunQiang Su: >> >> > AT_* only has 32 slot and now. I was afraid that maybe we shouldn't take one. >> > /* AT_* values 18 through 22 are reserved */ >> > 27,28,29,30 are not used now. >> > Which should we use? >> >> Where does this limit of 32 tags come from? I don't see it from a >> userspace perspective. > > Sorry it is my mistake: In linux/auxvec.h, I saw > > #define AT_RANDOM 25 /* address of 16 random bytes */ > #define AT_HWCAP2 26 /* extension of AT_HWCAP */ > > #define AT_EXECFN 31 /* filename of program */ > > The number jump to 31 from 26. > > It is my fault: in x86_64-linux-gnu/bits/auxv.h, the max number is 47 now. So AT_* tags aren't a scarce resource after all?