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 9C940C4828D for ; Fri, 2 Feb 2024 01:23:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2B8EE6B007E; Thu, 1 Feb 2024 20:23:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 269076B0080; Thu, 1 Feb 2024 20:23:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 158186B0081; Thu, 1 Feb 2024 20:23:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 055EE6B007E for ; Thu, 1 Feb 2024 20:23:11 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C55AA80265 for ; Fri, 2 Feb 2024 01:23:10 +0000 (UTC) X-FDA: 81745115340.19.957D26A Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) by imf08.hostedemail.com (Postfix) with ESMTP id D5F0616000C for ; Fri, 2 Feb 2024 01:23:08 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b=OQS32+5B; dmarc=pass (policy=none) header.from=zeniv.linux.org.uk; spf=none (imf08.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=1706836989; 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=1ZIT6+l1ZLIkY5DXwfFbHPuAQNZOi2QWA8dkeqdsXTE=; b=lSG2LzJQkjnLxq2fIh2z03/2otD+UAObdgWgKwpWYQp6/gVmtCfx9zt4F2UJQCv1RQv/tu exhFeKRD3bfcAmEkqatSBIrO28jxVmG+OT75Z0I6g8TwRnsVPnIL33VExWr/4T7zN8OdmI LMWwFsVrpZHiIW1CXfU8fmKbLErsRLc= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b=OQS32+5B; dmarc=pass (policy=none) header.from=zeniv.linux.org.uk; spf=none (imf08.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=1706836989; a=rsa-sha256; cv=none; b=fnJmTd4w6ER3D9qVAOpmggbLYyg9/AyrkAGOXAy9KSU2YuxOGNDKvEZHXCmagaVepNxCgl UXa6DCTUOMhFrc/copM+V4VlX7S4TfyS0FXP920NtHSwgx6EAGyxYM19XOlm09aci+qShY 7krnMh3WqEUwrnECtXCSimN4TvPJvLs= 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=1ZIT6+l1ZLIkY5DXwfFbHPuAQNZOi2QWA8dkeqdsXTE=; b=OQS32+5BonAVyWJcUHPZSA5zMj yAAE0gK6PYd+tHz2jwUuSHy92NNPK2K9DbV+9Sh6royxClCGX4mVVvXT5eLxdG0/7dlCp48LxhoCN Y6ndewMOQBTphwOv7nJkvq6T9AD0sjFS0OqKThpdB2IBUc8lCQ9g8aOIdEJMBoT65LBWV9PlcY8WN cmgit1qgAOiF2QFtF8qh4mRRt/ZP5oT24GvVTzNIpzLiQyo7OPSr5njQgBc5Hw6JLDU1bvMjZ9Inb rv6qFIXFx/8kC4FSSDV3NmuvW4HNdlnosd5BEUoXOHexAcpo7Y6+jr0Urv8YCJcwLf+76bMsXIyrx irhwq4jw==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.96 #2 (Red Hat Linux)) id 1rViGX-003Z4R-1L; Fri, 02 Feb 2024 01:22:49 +0000 Date: Fri, 2 Feb 2024 01:22:49 +0000 From: Al Viro To: Douglas 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: <20240202012249.GU2087318@ZenIV> References: <20240201171159.1.Id9ad163b60d21c9e56c2d686b0cc9083a8ba7924@changeid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240201171159.1.Id9ad163b60d21c9e56c2d686b0cc9083a8ba7924@changeid> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: D5F0616000C X-Stat-Signature: o64n9gmjc8f4gghoswtibkwsa77pddrk X-HE-Tag: 1706836988-655860 X-HE-Meta: U2FsdGVkX1+XEIBgJi476lIK/440UAdPrkAVt/TJgjKCFfKvJobN5gsy6uWreQb0y3mdh5ZFYiTH75l0SnjzdRUkiFgwDuGaqUmz+LoFDMZTfAiV2f7Jd14U1SI66HgvPHoNmJkqSv2aZuSr/UAfq8WC7eG1I23L4ZUq0y+gVXbDOT08G3jjxYQ6lMe70x34TIYKpBec7Fy4mLSiqMqYxrEXVxTlaGjOPtdzNXsPyHiNVhg9u8U1iCtiDvYSwVk+wUfmZXRV+L9+AL4YvwO1f1Vi2zs7KYTUfaWz8Z3Np9jvLIKIpEOI4ZzlNSws25ao86TRDSNyOknCkHt5YE1bn/uwSoQoMp+UJ9+ZJT4QXyyvDWFKIrzXQJQv1TZX+oD/N66/M4CGt4MRhFATVyYbbOPpHx9zOMLk9mB0DDRMN43F5WgAi/A1nnipK8fLn6vp8KBoP2lN5RZ4uPmuPV6Gp09DvM8amrClF1PqBG9JkRNZAw2k5gsSFKunHTQl/ZTRvME8PYTWnITXLAoTwbiC3zVlBtILuamrKU6MvtxP5IdIsEFlNlpFl2CTeaeCttwuqPu2n2he+TegPhPeAmtVc+9d19DiCdX2EJqpzdKXhv+MeQp23oyf0EOpylBMvRUiaYkOPEM9ptKTsZ70F2lOCCYysP6ldAdn+YVV+QIteeXB0i4PvsLTvgOLXdzd2UrCQzaISc9mIE+bm6yMBf8f34Is901GQws3OL2S9Z2byspAju25+Cx0eQ3NkDjvq3RX5QZ+w2TKcecIMp+5QWA4hc38O/TIirVAUAXpEuG7aheBGc/EHNylKk/cYNf15tdcnPOd0zr2JLUYnevR8MePjj4GEdPl+i2kM4n5UOEZpfVbzIUgv9rn08SqV0Q8zSYM+GoYnopczV7etNp0tT1Q97O9c/BQm37OF9PN9a3cFHhwnKtwIq4/gxFn5nCMO7BKglw0oIcvlqlREo3feUR G6er2tsn 1ZtnCD56nom/ynH4YShzcOuCkJOuecM1Ez84n/aE+0w1ldfPRQjjh88qVMGZ5aFgcTHxktP+G8Tn1gWBoORMmJm1U1dyyxBsJqr0VK23esiq9LImMQFS3JQu3jB7y5vmjIYt//Dl0Kf0xqgRsK9bmVXPvjed0sJXQbGmjhlO5xdbBRROLNBKnCsPoK4shhsjZ2HvZ6WEgovsVoJuXR/J4+dw04KnI+zPWFf7d31HL7OzhkiM7rfYNaw43/rratEDnlLgPeGHNqn/6sRHHzPSVXNzHxDe9t5OGtqbTzkoyv5w0BMJe0m/Pga/4F/+bbGGIeQdjM29ebDcROTihATlfeXJmLnljLVXLYFWIB6qELsXDcN5iN1n48uzHo8GAFbPncd2Xu2p6k9WVfaA= 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 05:12:03PM -0800, Douglas Anderson wrote: > While browsing through ChromeOS crash reports, I found one with an > allocation failure that looked like this: > An order 7 allocation is (1 << 7) contiguous pages, or 512K. It's not > a surprise that this allocation failed on a system that's been running > for a while. > if (size > regset->n * regset->size) > size = regset->n * regset->size; > if (!p) { > - to_free = p = kzalloc(size, GFP_KERNEL); > + to_free = p = vmalloc(size); 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.