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 DF918C4828D for ; Fri, 2 Feb 2024 02:59:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3CE756B0071; Thu, 1 Feb 2024 21:59:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 37E886B0072; Thu, 1 Feb 2024 21:59:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2472A6B0075; Thu, 1 Feb 2024 21:59:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 17A7A6B0071 for ; Thu, 1 Feb 2024 21:59:14 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9FDEF40DFD for ; Fri, 2 Feb 2024 02:59:13 +0000 (UTC) X-FDA: 81745357386.28.FFCB02B Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) by imf06.hostedemail.com (Postfix) with ESMTP id B0BBA180004 for ; Fri, 2 Feb 2024 02:59:11 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=cz69y+rN; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf06.hostedemail.com: domain of dianders@chromium.org designates 209.85.218.54 as permitted sender) smtp.mailfrom=dianders@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706842751; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=y3A/r4oKTDxJsFL1Anlh777Z6f2eiMJhC1iris26H3M=; b=og7vLWwPaIct9PFQjzTEn04W29qq/y8vL0wM/kDPcSLgVNbqhMW2i4tvqFJ0d0iQheWIpy QdA/GJ6RJLayE5q+eXecnymqCajJW0yGONKcc1HkSoCkMun5nfdN5K+yRlZnFRCiPjxsuC +hNOglGuGR5FgnaYkeyQ1tz+A3ffSes= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=cz69y+rN; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf06.hostedemail.com: domain of dianders@chromium.org designates 209.85.218.54 as permitted sender) smtp.mailfrom=dianders@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706842751; a=rsa-sha256; cv=none; b=uIdNt6bnYvdkREEN8elEPp2yDLPmj5KTeoFZzAhS77X1kRmWHCELAKpjvAVV9ONpXdx6T0 q7LYB9p4hUA2MvLHyfZn0oh804QNzO5SFJr03aHZBdraJAoCRkgVFfllxSgmHnAWsmb9IL w46WC5eeU9W178G77zFwSuFITWFnlgU= Received: by mail-ej1-f54.google.com with SMTP id a640c23a62f3a-a318ccfe412so178083566b.1 for ; Thu, 01 Feb 2024 18:59:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1706842749; x=1707447549; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=y3A/r4oKTDxJsFL1Anlh777Z6f2eiMJhC1iris26H3M=; b=cz69y+rNpB3s+wZKgvMXBe9DSj1ocyvmUPUoXuPW3p7DgvGqAPtm4+chnZ5YstJos8 nHewtx5H+J5mCEgdhvctJL43bdpCiCXe7oz87SC6oALPB1xyUFlqPbXHrEvdDUTgR4FV eyQmz85Nf88KKhapCdDSScvx1fAmTxF7kWjfM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706842749; x=1707447549; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=y3A/r4oKTDxJsFL1Anlh777Z6f2eiMJhC1iris26H3M=; b=Tj7zRREiwRTvke0Kw8QHLBwlXHaiTZk3irdbpsD8ORL65vm2EuBcZbWlis0YNQ9ixM iuGcwc5azUlo68pqKOoSqz1xnL0vKo5rxmgBqN3JfF5VS7zTAgX97p8WakIAWCjfdJKM CjJbpC7v8YHUN2K7P9kZDwZVOL7wvm/RihruKKXS0MC4SaPy3caBPBCgnsmNZ3eOrl1X V+jpwqqBq3+bSKCI/5YIq4JIZKkiU0kbQXMR3Edhf58saW1imnSKmeI07X5x7hYkpX/E deWbb2qAakHWa8CXuyuZCAMqTvtQ0DGfB9yPCd6vJ5shA/hChEwuhyiSL/pW7NtrBct8 UZ6g== X-Gm-Message-State: AOJu0Yz5tqllzluX3x82FZMqXVF+nlccfqwHGma/L9MLgnFgQQxul5Fq egwhjhmE1XKYq+1y+uMJTlpSVa2Ccy4q7c3hp4jBt90gcIq7aVRjZ6X83MDa12gaAG0yc2N6dCM mqg== X-Google-Smtp-Source: AGHT+IEZTCk9FZML99lbhUgtGzYWhsPLNQndqDdrSjfRrM3rusruf6sTnbiEv8OY2djqvekTSEdoHw== X-Received: by 2002:a17:906:538f:b0:a35:e26c:e80a with SMTP id g15-20020a170906538f00b00a35e26ce80amr546060ejo.3.1706842748990; Thu, 01 Feb 2024 18:59:08 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCW3qyMrtpJlZLFNxOkKnnYo/dSjmw6sp1qflADYGe3a2BxRj3HO1VEuV2xLUGM4VUjHk4BiPxlnYqkD2JAnswYiYec= Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com. [209.85.128.50]) by smtp.gmail.com with ESMTPSA id j22-20020a170906411600b00a3677eee12bsm383497ejk.182.2024.02.01.18.59.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 18:59:08 -0800 (PST) Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-40f00adacfeso15805e9.1 for ; Thu, 01 Feb 2024 18:59:08 -0800 (PST) X-Received: by 2002:a05:600c:3d92:b0:40f:c436:3982 with SMTP id bi18-20020a05600c3d9200b0040fc4363982mr62363wmb.2.1706842747629; Thu, 01 Feb 2024 18:59:07 -0800 (PST) MIME-Version: 1.0 References: <20240201171159.1.Id9ad163b60d21c9e56c2d686b0cc9083a8ba7924@changeid> In-Reply-To: From: Doug Anderson Date: Thu, 1 Feb 2024 18:58:51 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] regset: use vmalloc() for regset_get_alloc() To: Matthew Wilcox Cc: Alexander Viro , Christian Brauner , Eric Biederman , Jan Kara , Kees Cook , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: B0BBA180004 X-Stat-Signature: ukkmtwxg8pu63n3jm3o8unbo4s4oapgz X-Rspam-User: X-HE-Tag: 1706842751-674691 X-HE-Meta: U2FsdGVkX1/hlq+3Z5M2eI+ug5JIQmzCgP0yLwDPEkvvBCdXW0xpdl6Kl7a/1QXUHrbRJBXA76hpj8qgQq8TbFcSxd6fhA+s9MRkKkAd0RsfsPtkgAAUAeOzc/HErAaWqxSTQuDaTyrUHlIX9NETrsYfk+Bz+3TwFYDjVJLn8KTAmK5rO2Tzeze6oN/5899e5vPQrBDEWVaHY7CeAPo6YBjf9/9FJd9wfs8FrbKTG6aslfEsg667UDlIMiavBltb58C3JIGE4aIeuHXY4BiXgWcS2Ca8gul9c5g2Gn/u6vxvi1fRk7OBfYaqARGcUlfeL91D4RUmVHt/Dj6yB4lHxQsowJdrn/kkMU7ZIQ2LgHMlQQNih/kodXKjjSexAMTqy98D50hguI79xj46ah1pj8FpF9p+GNCWkSwVkHFUWNZBX1Dxr4F4omvVWSLjd0V5LPqliI863ozdvp9dJdRg/baFM9gQUBoBQpyoM9dRxpiRs4PfaxQKggatzj4N7iFJrvEHV8WbWWWLv+z+waCq+p8xiCj1dG6iPIRtdRFkrfo66Bp9NXOWYvJzLYXLWVmeEqlj/FjENn1ETie3GEVRnQDO9/GT5cBiCQOgVukFdMcm7e1S9SA2Q34iCUC7O2VIfvkpCGH1946v16Z5pqmQc5oi6B+FCWw1nggWXpkV9D06T57WRHycUmp+VllQX15AnNKAdi6ygvPz6NtqA/dBNo9kzEGrBmxt4QO75OPw8sI+khnKgr0OUJ4n+rNjnt0jtLgPJ0D9BTzRJAB3JL4le3N4QhHrT+qhWg8w4d+d2fn8mVp+tI2+/IddF1Zow2MHV1Ch2lbeW5QCh1FHxT/4hk/kKuTzshANEE/1B6u/T2ViiH3u+Gk4s/XLrJeIRqhLA9WfSc4xqhsvGt3ukHOpULvq/baTlBWp/j5sRRVblt/GY+vVxMVpptDckkYJSDdTLwybpJX/74FuvnjzEpI HX3MnnT6 WCPiGgloZpQ57IQ0snwGFD+kGUdDtV9BWCjwiXz2yA0YyGMzST52rxQRZAPLM10qhSVvYwOpTj1I8I3zduCto+q7JKFulPYZD5R6qURhHR3MLA9faI5yURnoEdA== 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: Hi, On Thu, Feb 1, 2024 at 5:24=E2=80=AFPM Matthew Wilcox = wrote: > > 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: > > > > chrome: page allocation failure: order:7, > > mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), > > nodemask=3D(null),cpuset=3Durgent,mems_allowed=3D0 > > That does seem bad ... > > > @@ -16,14 +17,14 @@ static int __regset_get(struct task_struct *target, > > if (size > regset->n * regset->size) > > size =3D regset->n * regset->size; > > if (!p) { > > - to_free =3D p =3D kzalloc(size, GFP_KERNEL); > > + to_free =3D p =3D vmalloc(size); > > It's my impression that sometimes this size might be relatively small? > Perhaps we should make this kvmalloc so that we can satisfy it from the > slab allocator if it is small? Right. Sometimes it's small. It feels sad to me that somehow vmalloc() of small sizes would be much less efficient than kvmalloc() of small sizes, but I can change it to that if you want. It feels like we should use kmalloc() if we need it to be contiguous, kvmalloc() if we know that there will be big efficiency gains with things being contiguous but we can get by with non-contiguous, and vmalloc() if we just don't care. ;-) ...anyway, I'll spin v2 with kvmalloc(). > Also, I assume that we don't rely on this memory being physically > contiguous; we don't, for example, do I/O on it? As far as I can tell we don't. I had never looked at or thought about this code before today and so all I have is ~an hour of code analysis behind me, so if someone tells me I'm wrong then I'll believe them. -Doug