From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104820 invoked by alias); 16 Jan 2017 12:28:17 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 104801 invoked by uid 89); 16 Jan 2017 12:28:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=H*r:AES128-SHA, =e5=b0=a7, H*MI:sk:1484220?= X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-lf0-f66.google.com Received: from mail-lf0-f66.google.com (HELO mail-lf0-f66.google.com) (209.85.215.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 16 Jan 2017 12:28:15 +0000 Received: by mail-lf0-f66.google.com with SMTP id x1so7078601lff.0; Mon, 16 Jan 2017 04:28:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=+K8LLQlZr5sxK1i6sgqMuYajYjhJSN9KaYupmSfaTqc=; b=qejGbd+iCIoI2HHmGXs3GWdA6Ls1dYXKiCGlm8yhGWm3GOveArJqEogIRjVMVxX7Or TqVReZoIFcYc4FYgza2aDLIOYtGOixtWw29YCQuwVuPWJTztdYnK0SxJFssoJfBdD0kX 2eTEJII5Zm7fFH9M1SvX8Ap8rGpWLmxfa7/VQSxpU/D3VpizlwvsZxUI4VmCdp0tEK5H 8Rml6/TzRS6H65234VH+jqZcRhLKPrGEcvTeBzrcRqYkIkfPCQqkdLSnUOXUz17GWtf2 l53wpDzw5lhj61r9ZxiV/26OcKauomet5vB2jGGL3vADZa8XbXD5n5n+bfZ2Koh2WPXQ UcaQ== X-Gm-Message-State: AIkVDXI1laVQAUZ5Ddf670JhE9l1CSIcQ/E4BkY33twAYbBdDof7gdkFwuB1vHbeemTimw== X-Received: by 10.46.75.18 with SMTP id y18mr13717548lja.68.1484569693659; Mon, 16 Jan 2017 04:28:13 -0800 (PST) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id u18sm7072414ljd.4.2017.01.16.04.28.08 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 16 Jan 2017 04:28:13 -0800 (PST) Date: Mon, 16 Jan 2017 12:28:00 -0000 From: Yao Qi To: Dave Martin Cc: linux-arm-kernel@lists.infradead.org, Ard Biesheuvel , Marc Zyngier , Alan Hayward , Christoffer Dall , linux-arch@vger.kernel.org, libc-alpha@sourceware.org, Florian Weimer , Joseph Myers , Szabolcs Nagy , Torvald Riegel , gdb@sourceware.org Subject: Re: [RFC PATCH 07/10] arm64/sve: Add vector length inheritance control Message-ID: <20170116122755.GH28060@E107787-LIN> References: <1484220369-23970-1-git-send-email-Dave.Martin@arm.com> <1484220369-23970-8-git-send-email-Dave.Martin@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1484220369-23970-8-git-send-email-Dave.Martin@arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00020.txt.bz2 On 17-01-12 11:26:06, Dave Martin wrote: > Currently the vector length is inherited across both fork() and > exec(). > > Inheritance across fork() is desirable both for creating a copy of > a process (traditional fork) or creating a thread (where we want > all threads to share the same VL by default). > > Inheritance across exec() is less desirable, because of the ABI > impact of large vector lengths on the size of the signal frame -- > when running a new binary, there is no guarantee that the new > binary is compatible with these ABI changes. > > This flag makes the vector length non-inherited by default. Can we make vector length inherited across fork but non-inherited across exec by default? > Instead, the vector length is reset to a system default value, > unless the THREAD_VL_INHERIT flag has been set for the thread. > > THREAD_VL_INHERIT is currently sticky: i.e., if set, it gets > inherited too. This behaviour may be refined in future if it is > not flexible enough. > -- Yao (齐尧)