From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=glOU=4X=vger.kernel.org=linux-kernel-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no
	version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 0431CC10DCE
	for <linux-kernel@archiver.kernel.org>; Fri,  6 Mar 2020 11:42:28 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by mail.kernel.org (Postfix) with ESMTP id D2D062072A
	for <linux-kernel@archiver.kernel.org>; Fri,  6 Mar 2020 11:42:27 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1726650AbgCFLm1 (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Fri, 6 Mar 2020 06:42:27 -0500
Received: from albireo.enyo.de ([37.24.231.21]:57960 "EHLO albireo.enyo.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1725827AbgCFLm0 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 6 Mar 2020 06:42:26 -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 1jABMw-00028i-VZ; Fri, 06 Mar 2020 11:42:18 +0000
Received: from fw by deneb.enyo.de with local (Exim 4.92)
        (envelope-from <fw@deneb.enyo.de>)
        id 1jABLL-00050q-TL; Fri, 06 Mar 2020 12:40:39 +0100
From:   Florian Weimer <fw@deneb.enyo.de>
To:     YunQiang Su <syq@debian.org>
Cc:     Laurent Vivier <laurent@vivier.eu>, torvalds@linux-foundation.org,
        Greg KH <gregkh@linuxfoundation.org>,
        akpm@linux-foundation.org, Al Viro <viro@zeniv.linux.org.uk>,
        James Bottomley <James.Bottomley@hansenpartnership.com>,
        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>
        <CAKcpw6WEO5Rmsv+WFkOMrkH+0jwtFKKy7b2n3U9xgv-xGC0UUQ@mail.gmail.com>
Date:   Fri, 06 Mar 2020 12:40:39 +0100
In-Reply-To: <CAKcpw6WEO5Rmsv+WFkOMrkH+0jwtFKKy7b2n3U9xgv-xGC0UUQ@mail.gmail.com>
        (YunQiang Su's message of "Fri, 6 Mar 2020 19:29:57 +0800")
Message-ID: <87v9nhzp6w.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

* 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.