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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 88A42C48286 for ; Fri, 2 Feb 2024 03:04:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CD4A46B0075; Thu, 1 Feb 2024 22:04:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C84B76B0078; Thu, 1 Feb 2024 22:04:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B4CC96B007B; Thu, 1 Feb 2024 22:04:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A65836B0075 for ; Thu, 1 Feb 2024 22:04:54 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 7386516048A for ; Fri, 2 Feb 2024 03:04:54 +0000 (UTC) X-FDA: 81745371708.07.04E4F20 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) by imf26.hostedemail.com (Postfix) with ESMTP id 8438D140004 for ; Fri, 2 Feb 2024 03:04:52 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b="b/aMu8Jo"; dmarc=pass (policy=none) header.from=zeniv.linux.org.uk; spf=none (imf26.hostedemail.com: domain of viro@ftp.linux.org.uk has no SPF policy when checking 62.89.141.173) smtp.mailfrom=viro@ftp.linux.org.uk ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706843092; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=skwCDGnLP4ByDSOBblEedQL0pq1fFuzhc2BhN7e3aHY=; b=Lf9DaWlzygWFtY/c5ahAzyRRXDGhPdGv9TkEP2q4VgHm7EL1QFXa2ooF39GUbUAT/cztNQ s+yyZNcdWNoksLVoNdBsitvfKylP8xhqld0xGBCdD/f8I3OMqWWCaV2PBmq30WSk3dHN+j au5TGbVNvNjXseprJdIJzoqIhEFREUc= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b="b/aMu8Jo"; dmarc=pass (policy=none) header.from=zeniv.linux.org.uk; spf=none (imf26.hostedemail.com: domain of viro@ftp.linux.org.uk has no SPF policy when checking 62.89.141.173) smtp.mailfrom=viro@ftp.linux.org.uk ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706843092; a=rsa-sha256; cv=none; b=ohHD41eGrt94ISdI14pEZeOAmCic/WDyCwNo4edtsRHiV3yWLGs8WitIBpDYUutnkyqKgh 7tEujOWQTKzBAir1hJXuIvmXnbGNxGJmGtYjQo1oAZWOqSt5EI0LooHDOxz93lPvja2i5t t5JvLhaJ4W2xngadpe18VKpvRBDjors= 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=skwCDGnLP4ByDSOBblEedQL0pq1fFuzhc2BhN7e3aHY=; b=b/aMu8JoyIi6pJYBgWcGXN8/UL ZV4PD80UgkfKr6pNS8JG1V4UccwxSlYwrgseJJPFEZpuLwVa38MCxyhgHRo5KdncYIge1WN+dpbqS B/1lOpLFqm2CKapZ6zJ4X5rP0E9ppzecAfULowIMwbcSNmIT80kFFjW7GDT8mdZxu2xyQ6l1D7XGF q3PGSLF044jinUnnTJjlThb6VV31oS8mUd7z1EJSenxFA0Nq06FvNXOzOSdMQeFNFZPGacvJ9byOz qyKNcOnAu5QzJoxF27mka7u/ZWgwVBgWf1BJ7vQL6+knhEqc/KZTEmNMsvHBDB7ucfRKXsAyn6ihr 8MIH4/Rg==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.96 #2 (Red Hat Linux)) id 1rVjr4-003cIj-1h; Fri, 02 Feb 2024 03:04:38 +0000 Date: Fri, 2 Feb 2024 03:04:38 +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 Subject: Re: [PATCH] regset: use vmalloc() for regset_get_alloc() Message-ID: <20240202030438.GV2087318@ZenIV> References: <20240201171159.1.Id9ad163b60d21c9e56c2d686b0cc9083a8ba7924@changeid> <20240202012249.GU2087318@ZenIV> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 8438D140004 X-Stat-Signature: e5pztys7ejfj8zbk18aaee8u1hdx8t6c X-HE-Tag: 1706843092-672942 X-HE-Meta: U2FsdGVkX194OeNoUdemcknkGL86pJIuIJcbJy4Dixhbaq2Lnmhsg0G51Ha1UF1Dc/FLhW1pjORBkpPU/SUvbxXI06qQbUcpPV60phTrMyHO6av2lr7RaZPUWiOGbI2OD9IklLlmCNZAlBoiIuK0iRx0CAsQoyWVmexTSefTkeH84nSlBGERgtxuErEogz4fNSojvGrwVO5+D3PCsIVjyY9NKicJ2tjRiqvqUwJTOohZwvxoCWHEPJ/6jxDHkP8R6UlDldxmNTtDqX4yWccLqNi81+OZukzVY6mOLW/WqVaK+f4hQjHlT/Xz1VK+UAGYg1XrrrQ2NaaALNy/VbfgqwM5xVe6TDaH8ify4u+WpvwQv1sxRU9GsGZb1HdBAumvSIh8qQHOTHCiQqyeynIfWZqXeBSxhFnBeo/nxKBDWc6gxv6+RWq/kYuFwD91XMUeb9OgKLSJIrdTrVxiQvEK1c6TV2QmKYoF3nWN6eNlcN3rxc5LmHQY/BUjjOlgVK1RMjyfoPqSKxUbnOk5wyvzXKbbyqZTMMfnZQPPBOdCJYdbxjFXS/3GhtdKQdyZ5blnCtaqX7R+OLxCg7ZCRUgc6Fy+nKmfZgtMNBHYE4/h46/I/8/ide1F+/8wgzjCgOGIfW7YSwEIJsLVuzUcD4ejagtN10ketfW4eQOk7TJSPWi2LJPp1/7ZzDvGQoZySf6DHvAHVwetMETFPS1r+iKV4wZHCHLBneBoXHVgvqbayDHU9Jr2mmGptg+cChN7RdozkUo2dNJNM51jVmwiHp/u7GjSeOkT2D9fVrnFfLiB6iVnqYKz1982B/1yIsxMDrxk9t9OFw8l2G89HfkDbl7/62V4Xt7bortRK+fEo8HD95VZn1Lc88tsJnEcevb8DnXe+OGik2eGfdCm3F6Rs8Mmf0QiVl6FoNXV900pzuhdwWEYlKuNiWatGJLcMTfVutvFvi5JY+Of1xyqb71FVq8 I7p89xJH KNEXfg9XEHMU57sc3+ihavWWq05kd+6E1QBujm2Wkiy9f/9MFVbd5jVJj6ee6V/72vWdkynK+nixppP0aQ/zD1vwj3cB2Zi8ERCF9wjIOOlQJAYhvm99c3JzWWZDvXnKLPEpzKg33VFHXvc9Ur78bstxVmsQExl/yFaA3mdnfA7wywGY2ULkBHYfdU9PXLHi8jcjxLbL8SL0hnvrIBBuaebLXzkdHEAqKCTIFGnQjmxMs9KUeFKYrCGIbZvjdY1JBZG0LTGyGRfJFU8RHPIOH+uu8pPoC2FUdXWPEWzl9p0Q+xzt3FC/NaE89mVM7MghjIjdIAM7V4Gl6c2KxaMgNL8FuOZn8mWN3jJdf3+hYvaVIA2a5WR28Hk3jNBo9YSu5EmNSglYRiV2YIUA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Feb 01, 2024 at 06:54:51PM -0800, Doug Anderson wrote: > > What the hell? Which regset could have lead to that? > > It would need to have the total size of register in excess of > > 256K. Seriously, which regset is that about? Note that we > > have just made sure that size is not greater than that product. > > size is unsigned int, so it's not as if a negative value passed > > to function could get through that test only to be interpreted > > as large positive later... > > > > Details, please. > > I can continue to dig more, but it is easy for me to reproduce this. > On the stack is elf_core_dump() and it seems like we're getting a core > dump of the chrome process. So I just arbitrarily look for the chrome > GPU process: > > $ ps aux | grep gpu-process > chronos 2075 3.0 1.1 34075552 95372 ? S /opt/google/chrome/chrome --type=gpu-process ... > > Then I send it a quit: > > $ kill -quit 2075 > > I added some printouts for this allocation and there are a ton. Here's > all of them, some of which are over 256K: Well, the next step would be to see which regset it is - if you see that kind of allocation, print regset->n, regset->size and regset->core_note_type.