From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 2CC07C433EF for ; Fri, 3 Sep 2021 07:18:03 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id ECB2461056 for ; Fri, 3 Sep 2021 07:18:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org ECB2461056 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:Cc:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=kksdxo5/CaaqnwUnFXUJxC+/9JYv/Tiyyf7SLca9yac=; b=Lx48yV8UIx5xNS W5USqGfaA/IywJ1bvde8PM9zsceAzGzgMy8weMWJrKaeb2zTXuMQKaiTsOLXpP4k173jkrHRreY3o bw9dqPnn5/9FQqwIdZf28nEFJYYIXsJcGJbJsP9hK0FYYtke6flMjFXL4uGRZiq1vOCnxjLwM+2FR F6hZS3BR0KwsH4NN4R1dueSkfAiIjSXHHu6cs63wSLrAxzSKa7MOn4k6sIVB3id3PumsJczCapwpc BjAgV9qxe4+zHTINraudpQb3VFYK1ibVs+U2A0YIcGQRpsbllPvqIZLU0jSP0wNpOUjnQwL7lHsD/ MY8q+KM40afwzxkPxiUA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mM3QS-00B9Fp-FI; Fri, 03 Sep 2021 07:15:48 +0000 Received: from gate.crashing.org ([63.228.1.57]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mM3QO-00B9FO-CH for linux-arm-kernel@lists.infradead.org; Fri, 03 Sep 2021 07:15:46 +0000 Received: from ip6-localhost (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 1837ETo3007333; Fri, 3 Sep 2021 02:14:29 -0500 Message-ID: Subject: Re: ucontext, kernel vs. userspace (glibc) From: Benjamin Herrenschmidt To: Mark Brown Cc: linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , Szabolcs Nagy , benh@amazon.com Date: Fri, 03 Sep 2021 17:14:28 +1000 In-Reply-To: <20210902124236.GA4402@sirena.org.uk> References: <131d684ea46de6330ab90532ab73729d6c0690bd.camel@kernel.crashing.org> <20210902124236.GA4402@sirena.org.uk> User-Agent: Evolution 3.36.5-0ubuntu1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210903_001544_718357_67AEFDCF X-CRM114-Status: GOOD ( 31.44 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 2021-09-02 at 13:42 +0100, Mark Brown wrote: > On Mon, Aug 30, 2021 at 08:40:03PM +1000, Benjamin Herrenschmidt wrote: > > > So I'm discovering arm64 intricacies and today, as I was looking at SVE > > support (in the context of distro glibc backports.. don't ask), I > > noticed that glibc has no provision for dealing with kernel generated > > ucontext's in its {get,set,swap}_context functions... > > (It says so explicitly in the code unless I misunderstood). > > So one thing we did to "solve" this on ppc64 a while ago was to create > > a swapcontext syscall which can operate as all 3 operations (you can > > have NULL arguments), which also handles the sigprocmask (bonus: > > atomically with the context get/set from a userspace perspective). > > Would it make sense to do something similar on aarch64 ? (And have > > glibc then exploit it). > > I think the usefulness of such an interface is mainly a question for > userspace - I don't immediately see any issue with implementing it if > it's useful to people. Well, the problem as far as I can tell is that the glibc implementation of these today. They support "FPSIMD" but that's about it (so no SVE or anything else) along with a comment: /* Check for FP SIMD context. We don't support restoring contexts created by the kernel, so this context must have been created by getcontext. Hence we can rely on the first extension block being the FP SIMD context. */ That said, a bit of reading around seems to indicate that the expecation of being able to setcontext() back to a signal handler generated context has been deprecated by the standard and broken on x86 for a while in Linux, so I suppose that is less of an issue. That said, there is still some advantage in letting the kernel implement these as it would allow the kernel to support various "extensions" such as SVE (as long as there is room) transparently without having to change glibc. In fact, isn't it possible for glibc to define its own ucontext structure for applications to use that can potentially have a larger reserved area ? By passing that size to the syscall, you can essentially get userspace ready for future extensions... within limits. > > The hard-to-solve thing is the case where the SVE context spills > > outside of the ucontext itself, in the extra room on the stack, since > > programs that "now" about ucontext will not have allocated space for > > that, so that's more/less a lost cause already. > > You can figure out the maximum possible size for a context so it would > be possible to define a mechanism for pointing to extra data I guess but > yeah, it's going to be a problem when we start seeing systems with large > enough register state. Extra data for userspace generated ucontext's isn't going to fly much, there's really no "place" to put it (those things can be part of structures etc...) and no "hook" to allocate/free sub structures. So you need whatever struct ucontext is used in userspace to be big enough. That said, I think the current one might be enough for sve512 (I need to check) and we could have glibc define something much bigger (16KB ?) without much damage I suspect. Nagyu ? What do you think ? Cheers, Ben. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel