Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp6598859ybf; Fri, 6 Mar 2020 00:40:41 -0800 (PST) X-Google-Smtp-Source: ADFU+vuLqj1YkVkP/iwGy9Jy0zS+WPwVoxOhb5Dg5MvRITkwYusFuCA2bKQXhXQCfLmC+ho3t4BV X-Received: by 2002:a05:6830:1e85:: with SMTP id n5mr1576498otr.113.1583484040957; Fri, 06 Mar 2020 00:40:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583484040; cv=none; d=google.com; s=arc-20160816; b=aSzehf1jyNIyU0fyDhmjkFLO5N+fpxQOILU3084ByU/j94pobeEzVlXoqpt2Q56Ala gp23r3UJr80Ps3hafQpzBeCM9YUMvScVH1KkhlgefaEot+/aZEevVtAwN+XqZRheeOHC Of0t5WzH5w/dk4eAWKn1iTO3zo+qXZ3+QGMO7rJiMg+/vUpyNcAwtAB9JQG3sueT3Ym+ 4OOK2v9dLNoEaYKReP0OXJAvUutnQrxq0ERLujVWFYKKiKvs0KBZMzwE2iHBiMWKB8LF fIOSaYctsWoLn683J90Upv5jwqBu1Sqg0k0l5x+B6mGGr6eDBBMA6tuXLeyW5knrHZmM kYfg== 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=NIMvXog4KPNplMXZwXxxLLBPC5WGqufBeY8OsZoTcZQ=; b=ARPg7Sj5cafOaEQ3BALeGukyyI7frTja+9KVlZsTUUmqdeC7j9Va5qTtDsTh2J6/dY UWkGtDCmEEf1yNrYVSy1Bw/wrIf3tGiKCFGhE6Espz4qoULq7vaNC4YgFNf5ZXNwdFqa qE0i2jcmtD+UbwWEitjKqcPFC4iWizZnGm9ZYRD/lmxcxT2gAFv8i/6Otm293bc3Vjq/ V4ZX81zASPjiGNBW5WIqsMGQ2t+yWMsFziE+pcZriC5QSGTKS7QvLqsIsM6GeKOmdfbr +v5TTXFBSFZNh3QLFOvvZnug10pzmSpI2YYf24JcpLXBApgJw4Op3ZSETcCTu6/iyECI RJEw== 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 i8si935142otr.227.2020.03.06.00.40.27; Fri, 06 Mar 2020 00:40:40 -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 S1726299AbgCFIjT convert rfc822-to-8bit (ORCPT + 99 others); Fri, 6 Mar 2020 03:39:19 -0500 Received: from albireo.enyo.de ([37.24.231.21]:54812 "EHLO albireo.enyo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725873AbgCFIjS (ORCPT ); Fri, 6 Mar 2020 03:39:18 -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 1jA8Vi-0000GF-K5; Fri, 06 Mar 2020 08:39:10 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1jA8U7-00026r-DL; Fri, 06 Mar 2020 09:37:31 +0100 From: Florian Weimer To: Laurent Vivier Cc: YunQiang Su , torvalds@linux-foundation.org, gregkh@linuxfoundation.org, akpm@linux-foundation.org, viro@zeniv.linux.org.uk, 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> Date: Fri, 06 Mar 2020 09:37:31 +0100 In-Reply-To: <8441f497-61eb-5c14-bf1e-c90a464105a7@vivier.eu> (Laurent Vivier's message of "Fri, 6 Mar 2020 09:21:46 +0100") Message-ID: <87mu8t3mlw.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Laurent Vivier: > Le 06/03/2020 ? 09:13, Florian Weimer a ?crit?: >> * YunQiang Su: >> >>> + if (bprm->interp_flags & BINPRM_FLAGS_PRESERVE_ARGV0) >>> + flags |= AT_FLAGS_PRESERVE_ARGV0; >>> + NEW_AUX_ENT(AT_FLAGS, flags); >> >> Is it necessary to reuse AT_FLAGS? I think it's cleaner to define a >> separate AT_ tag dedicated to binfmt_misc. > > Not necessary, but it seemed simpler and cleaner to re-use a flag that > is marked as unused and with a name matching the new role. It avoids to > patch other packages (like glibc) to add it as it is already defined. You still need to define AT_FLAGS_PRESERVE_ARGV0. At that point, you might as well define AT_BINFMT and AT_BINFMT_PRESERVE_ARGV0.