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=-5.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MSGID_FROM_MTA_HEADER,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED, USER_AGENT_SANE_1 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 6BB5DC433EF for ; Fri, 3 Sep 2021 11:06: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 3392760234 for ; Fri, 3 Sep 2021 11:06:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3392760234 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com 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:In-Reply-To:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=1G1KN3xPg65evPGbkwUSOiN4OVpN5lJ1gTStM5da0I8=; b=0xFxnXghr9iKZS gGfmWhFVWLgx5iMJc+e10xuMZXM2BBmDUV6Z0qQdXVHvDcErPsOZ/77Ovi/l83N0PY1vdWzZ2CI8w FB+iVph/ZRWWEC0A3bEiN6Rdj0RlMcfQ2Ar6r1vANfBTdnHGLkiGgivLDA91KI+tO1Q5/x5hpvSEb gJ3usvyMExVi9/2KwGnE/bIGjf8GUt3h2VBSkXPIp854a/yFr4UMKMStzKPg0ZBUaj0QqMA4UuF/l 9WQNkrPVSukd4gvBrCrCczHA6EZThEW+wYgK2+Z5OPFRqf1GP7bwobsbqoQ6kuptebh1B4v6tGu9D +8a5iwTZTcqWoc/F8Hpw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mM6yp-00BjBw-LN; Fri, 03 Sep 2021 11:03:32 +0000 Received: from mail-db8eur05on2055.outbound.protection.outlook.com ([40.107.20.55] helo=EUR05-DB8-obe.outbound.protection.outlook.com) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mM6yk-00BjAT-Ox for linux-arm-kernel@lists.infradead.org; Fri, 03 Sep 2021 11:03:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3ruFkWVDBAYgSNlv6Kp8KxM2GQBp43y2kHfY1y7U37Y=; b=sUTmVorqM3rMJQ0iRL5T/tO1nuNu5OF7aj73TxvUotIYL+qVX/C4Ilx9ESG61+AGFdFUsUYZtSLyfD8otMHgEfFQmwUqC6PcewnQ/dAORAp1B0kdqvSx1Wf2OI91Y5nokwgxx0FYcFVuOZhiks3hcIEqy1iMN6BA9IazsOsxoqA= Received: from DU2PR04CA0312.eurprd04.prod.outlook.com (2603:10a6:10:2b5::17) by AM9PR08MB6275.eurprd08.prod.outlook.com (2603:10a6:20b:286::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.21; Fri, 3 Sep 2021 11:03:11 +0000 Received: from DB5EUR03FT022.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:2b5:cafe::e8) by DU2PR04CA0312.outlook.office365.com (2603:10a6:10:2b5::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.19 via Frontend Transport; Fri, 3 Sep 2021 11:03:11 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.infradead.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.infradead.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT022.mail.protection.outlook.com (10.152.20.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.19 via Frontend Transport; Fri, 3 Sep 2021 11:03:11 +0000 Received: ("Tessian outbound f11f34576ce3:v103"); Fri, 03 Sep 2021 11:03:11 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: e2a59c3ff161a816 X-CR-MTA-TID: 64aa7808 Received: from f0fba480dd45.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id D39EE2F7-C005-4947-A5BD-17AEBBA29016.1; Fri, 03 Sep 2021 11:02:55 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id f0fba480dd45.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 03 Sep 2021 11:02:55 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QzcSHsThVP6vGMUaYyc2QDtsJynM5NwtYSRoKwbTj4FGqUJz1/zr19TS66PYV539CsiWXMq9AURUcLlDyOBChCkcIoyo4ENd2S0LJPV3R2xTr2oeL8+/dSlSpFBqVk0tMog+ZmLpfGV1gVKyCIxKft2RwhXlhu7oEfBrlJKqxUxYs12a7YavCha1Ql5OA1hETRWl8w5IWZ5j2HTgSggyVD5n1bjWLGEhnBP21Iss/Jf5ArwhcBGBtcaijXoI5GeNC/H/LPquX3tMelt2YhLksFuPGacOgfI7Z5+nHQW5QNunE4xFTuG/mYpCimlvW4Di1yP0rktpbZhdTMA1aga41w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3ruFkWVDBAYgSNlv6Kp8KxM2GQBp43y2kHfY1y7U37Y=; b=d0+B/xzEEz90z8QyXTepwC9+v7VdhkDAs7VcHq2m/wlobXudU7U0FtTOTR8P4pyGZjaePoxGoH9FwNO8JQqOMTWL2g78lj6Imcep8KoBEOEFZXYkYLMK5uHdQ4tKRbCHHelIP9T8Vy+DWCKfQYel7bKnJGKtykXstvJWkQwtF8dryYE1NkQlrW+iq9+A4VQajCraKjbpLgugydE80Akg6fx1qM3+ZBMmCoR30bXXfggmLeqFtX9wiKwYPXRV5RDV4rpV2HyWZxsS0T0XrKVhbWQsw1U7jsZTQ5vP7IWnULLmEeAVQxVr53kS0tOD2vH86y95xA31FOocdP0iTkY3iQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3ruFkWVDBAYgSNlv6Kp8KxM2GQBp43y2kHfY1y7U37Y=; b=sUTmVorqM3rMJQ0iRL5T/tO1nuNu5OF7aj73TxvUotIYL+qVX/C4Ilx9ESG61+AGFdFUsUYZtSLyfD8otMHgEfFQmwUqC6PcewnQ/dAORAp1B0kdqvSx1Wf2OI91Y5nokwgxx0FYcFVuOZhiks3hcIEqy1iMN6BA9IazsOsxoqA= Authentication-Results-Original: kernel.crashing.org; dkim=none (message not signed) header.d=none;kernel.crashing.org; dmarc=none action=none header.from=arm.com; Received: from AM9PR08MB6306.eurprd08.prod.outlook.com (2603:10a6:20b:2d6::17) by AM0PR08MB3075.eurprd08.prod.outlook.com (2603:10a6:208:5a::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.23; Fri, 3 Sep 2021 11:02:52 +0000 Received: from AM9PR08MB6306.eurprd08.prod.outlook.com ([fe80::795e:a0ad:961b:898d]) by AM9PR08MB6306.eurprd08.prod.outlook.com ([fe80::795e:a0ad:961b:898d%6]) with mapi id 15.20.4478.022; Fri, 3 Sep 2021 11:02:52 +0000 Date: Fri, 3 Sep 2021 12:02:50 +0100 From: Szabolcs Nagy To: Benjamin Herrenschmidt Cc: Mark Brown , linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , benh@amazon.com Subject: Re: ucontext, kernel vs. userspace (glibc) Message-ID: <20210903110250.GE21740@arm.com> References: <131d684ea46de6330ab90532ab73729d6c0690bd.camel@kernel.crashing.org> <20210902124236.GA4402@sirena.org.uk> Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-ClientProxiedBy: LO4P123CA0294.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:196::11) To AM9PR08MB6306.eurprd08.prod.outlook.com (2603:10a6:20b:2d6::17) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from arm.com (217.140.106.55) by LO4P123CA0294.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:196::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.19 via Frontend Transport; Fri, 3 Sep 2021 11:02:52 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9be7ffac-2167-4936-5e5f-08d96eca6b48 X-MS-TrafficTypeDiagnostic: AM0PR08MB3075:|AM9PR08MB6275: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:10000;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: zlLMvq1M8vbbQ57yXScUcthCkNUREx6vSZRp7DQ0+D4POg3YvcXFu7h24/o6vy0oBQRIm68sNKfD2KEefmgAE8sCPPczeMH8IV9irJGvhgfvnPxRNm7bLLFlBw3fB8OOU+x6sPdPAdqZMNcv1mCS9zRaeTZzOVhFs97fPO4tz84WcglmQ+0wAK1D08jxqp3qcEC37NF+uAL3PQC24bLu3Az+XwKMJ0WyGTl24IJwkWPbQ7RJ+UBqZSdszwqImRxgmXZR+sY5j68URxp3CdHpvtI6BLoT5XUdpj8HMm+pnc/Vz0Xq/+vK9nEmL5Y1S+152HU8D3sD4ucxFkLR3Lep2IdfpWl7VK/gWY5mFCVNMRqVau+mM/J2HeHn+XvLdcMbBdyrfh1rdQtwy/5s0WSSlz4a8va1RQeJV1VTx0HySzwBKOjHlEREki+hQoszjtBTc1AU2ytUrnnD8+SeMmUhnRUO2zM4U41gKM1b9oEcsJbAPPnKQZvWv+DhdLOLW3smg3jxjSn9z4Rjb282+wvsyM3JXJYC7KjDLALZgRvmjJBPRFlYdAEpZsQB6RuO6rqClG1d1kUc4oEzVpiC4xzNoXIxiXLnZtTNi7J9PRvRGZ+m4XRAoRgcT+ihiScvQkRTGrceKeUv/yztPY+iyjp628J/bT/j/sKWagNrALHxbbl6MN+0oBh7Y5gWC0gR5VLP9CfEhhfyq7GKLQPFmwUamA== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM9PR08MB6306.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(396003)(39860400002)(136003)(346002)(6916009)(5660300002)(8676002)(8886007)(38100700002)(956004)(36756003)(86362001)(2616005)(38350700002)(316002)(7696005)(52116002)(66556008)(2906002)(8936002)(4326008)(26005)(44832011)(54906003)(478600001)(83380400001)(55016002)(1076003)(66476007)(66946007)(186003)(33656002); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3075 Original-Authentication-Results: kernel.crashing.org; dkim=none (message not signed) header.d=none;kernel.crashing.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT022.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: e3b148c4-ace5-4dd8-fa2b-08d96eca5fe9 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: rAptH8NRq0XS+cIYOGmC9d9ZPY3+ylz6bE/djUMfdJknzXpT/81n+yyPpmTBplmrqagoG3cAEZ76ce2tMi0+3FEpgLFIXBgYN2Mc0lqWAItbNn9CGLczbGffetclv1B5WqtzcusWgmuVWq5aRoQrlqoUVCXRRRUIBfU0B7rwAqBVAQa3gSDog61oQyR4tu8yQ7azwIZDII1B2sVpYNZnwXpkbw7AFwfWkehKriykqvW8fuO6xdVnBWWIUDTHluqm88xq2GeGCnSOoMbNUFUbK54Ukn8F/HJ/XMwGIBMPYpjU7JKXvdCcYy1PshVqqujFR6D+m0xHuEwGb/5koanmODHhSj3hrxxQ1MpNAQfa6jQOmvlKQL07LqCSjsImOcSzO/YaNBTCPllOxSesw2QLE8Ap7FafEM+6sFKWjuIM+5dP350BET1zB9xuSZRPYg7UHSgsO9oOWJ03f0QTcR/q2VhOc0RdVHCPgOD363YEnzYxaLqiEPM8RZr7/VOcTSg5T1rKIABoTphkSR6x8jD07ZGzfDg3RFiCRk5varPPVRS0YQ3+W28vzNnqITojUjS9BstjzmQwDjHbA+/L+cqWHDd9A1gHdZjLHmdssQ7eLhS0Bhm0qjnylAGkaBsTTP49197PDaij3gBLQx1KAldOWlXAk4dPbsSj3a9N6z+aXaVNaaNHm8vSPf8/fyLTOZzWy0P5ru8PQcyC4J+WmXzWYw== X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(36840700001)(46966006)(86362001)(8936002)(70586007)(47076005)(55016002)(186003)(8676002)(7696005)(70206006)(54906003)(8886007)(356005)(508600001)(107886003)(2906002)(81166007)(5660300002)(956004)(2616005)(83380400001)(33656002)(26005)(316002)(36756003)(1076003)(82310400003)(336012)(6862004)(44832011)(36860700001)(4326008); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2021 11:03:11.1919 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9be7ffac-2167-4936-5e5f-08d96eca6b48 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT022.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB6275 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210903_040326_866685_94645042 X-CRM114-Status: GOOD ( 45.10 ) 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 The 09/03/2021 17:14, Benjamin Herrenschmidt wrote: > 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. yes, setcontext is not expected to work with kernel context. > > 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. i think this can be a discussion for libc-alpha, but i don't think there is interest in using the libc context functions with kernel signal contexts, that turned out to be problematic historically. but if there is a use-case that can be discussed. > > > > 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 ? i think we only want to change set/get/swapcontext if there is a use-case for this. currently only a small bit of fp state has to be saved/restored. and there can be security concerns since we have features like bti that limits where one can jump (arbitrary pc in setcontext does not work). > > Cheers, > Ben. > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel