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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id E128EC48291 for ; Fri, 2 Feb 2024 16:56:00 +0000 (UTC) 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:In-Reply-To:MIME-Version: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=5fb0ClprmaQE2gmKjLaEvnGqG2kmOET/1f4J3FSqwPI=; b=2u+ySKjHreSdNM D205gkve+vlhMxmzPiMJw+VvALp76Mdc7NpHDziGYqDYzbVdLfbkdLPOPvX8vmNDr7aeK7aNPOVZW e6QqeB1OkdycrlWEgIvFzHjF5ZLpJe1f3gKAshc0vmD6odH3b76vCF6/4sNt2fKjoR/llzyo1VMR/ dGywalXloNZu4iWOOEsuCh4AcywSKG71JIhZARHq446pwvhc3A5UKES6EeKQotYYRpYS994f9BMMu v18WQ56wcH2SGe9SMrzMlOqYdFw3H27T635e/eGVeyAJ0j2Ik+c/zKUb1L/2Jqbektzhxy1JiAJfe UnUSmL6WK68NNzkkdKYQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rVwpT-0000000CRZZ-373L; Fri, 02 Feb 2024 16:55:51 +0000 Received: from zeniv.linux.org.uk ([62.89.141.173]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rVwpN-0000000CRXa-0EWO for linux-arm-kernel@lists.infradead.org; Fri, 02 Feb 2024 16:55:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=lSJi26KMQtWNTXdO5n2y84QWyqfEb23C7fuvP06Fx8s=; b=hKtBENpsrGynNte5dX952n+ZuY aRo940bIAb2jQgA9ZxKeu+UqAKuufrXVtdmrDf4gkJmMBS2TJ2+qCsUN3L1HV9/G170PxklkQgSCP Toh9yNZsP8GXC0z8AMim/QG21kPhSIs82WkNsvrZbWxcjDuQBibkhYhbXnsqZA9o8fqlu6oOjQOgM E77m2Ll91RDdeA61/Cfd+pJqbtpQ/mX2QvTvs8CkCZVi+nONaRXVeuOGp4+PrsrPBT38sBEZC30Zi fw1t0oUUvRGvmylFARPv4b6DQL3bNXfdG++uJQOBVRt2NzJ+QPh0VqS+5s87o2qtOVJIVhqnNT/69 dmdneH3w==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.96 #2 (Red Hat Linux)) id 1rVwp2-0048AR-0P; Fri, 02 Feb 2024 16:55:24 +0000 Date: Fri, 2 Feb 2024 16:55:24 +0000 From: Al Viro To: Doug Anderson Cc: Christian Brauner , Eric Biederman , Jan Kara , Kees Cook , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Oleg Nesterov , Catalin Marinas , Will Deacon , Linux ARM Subject: Re: [PATCH] regset: use vmalloc() for regset_get_alloc() Message-ID: <20240202165524.GD2087318@ZenIV> References: <20240201171159.1.Id9ad163b60d21c9e56c2d686b0cc9083a8ba7924@changeid> <20240202012249.GU2087318@ZenIV> <20240202030438.GV2087318@ZenIV> <20240202034925.GW2087318@ZenIV> <20240202040503.GX2087318@ZenIV> <20240202164947.GC2087318@ZenIV> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240202164947.GC2087318@ZenIV> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240202_085545_124398_B3253C5B X-CRM114-Status: GOOD ( 21.50 ) 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 Fri, Feb 02, 2024 at 04:49:47PM +0000, Al Viro wrote: > > +folks from `./scripts/get_maintainer.pl -f arch/arm64/kernel/ptrace.c` > > > > Trying to follow the macros to see where "n" comes from is a maze of > > twisty little passages, all alike. Hopefully someone from the ARM > > world can help tell if the value of 17474 for n here is correct or if > > something is wonky. > > It might be interesting to have it print the return value of __regset_get() > in those cases; if *that* is huge, we really have a problem. If it ends up > small enough to fit into few pages, OTOH... > > SVE_VQ_MAX is defined as 255; is that really in units of 128 bits? IOW, > do we really expect to support 32Kbit registers? That would drive the > size into that range, all right, but it would really suck on context > switches. > > I could be misreading it, though - the macros in there are not easy to > follow and I've never dealt with SVE before, so take the above with > a cartload of salt. Worse - it's SVE_VQ_MAX is 512; sorry about the confusion. OK, that would certainly explain the size (header + 32 registers, each up to 512 * 16 bytes), but... ouch. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel