From patchwork Wed Mar 23 23:06:17 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12790220 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 795CEC43217 for ; Wed, 23 Mar 2022 23:06:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 126C88D000B; Wed, 23 Mar 2022 19:06:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A8EF6B0083; Wed, 23 Mar 2022 19:06:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB2E28D000B; Wed, 23 Mar 2022 19:06:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id DCB966B0082 for ; Wed, 23 Mar 2022 19:06:19 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id B2E3781D60 for ; Wed, 23 Mar 2022 23:06:19 +0000 (UTC) X-FDA: 79277186478.05.8079923 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf09.hostedemail.com (Postfix) with ESMTP id 2B761140025 for ; Wed, 23 Mar 2022 23:06:19 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8BCC6617F0; Wed, 23 Mar 2022 23:06:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E818C36AE7; Wed, 23 Mar 2022 23:06:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1648076778; bh=4hNNHxiVyfteaC8NEM+kjhvExFaE8Bhlb1AV9KeKdeY=; h=Date:To:From:In-Reply-To:Subject:From; b=bWw+flDnUcPt/agnl/uqsZAVR72bp2KE0fa8Rf7u0H9p446bqhRT+pTwVzn90AWbv QomyPHzvgwuiAC80R5lR+fGtitL7c1SwfWRjesqYXCZYd2X8r6Nty2ZBFgNQPMnpbS agoGS5KaIMKYPgnyvI3tJ/aV3JtL3JApfmE+1ZOo= Date: Wed, 23 Mar 2022 16:06:17 -0700 To: viro@zeniv.linux.org.uk,0x7f454c46@gmail.com,avagin@gmail.com,akpm@linux-foundation.org,patches@lists.linux.dev,linux-mm@kvack.org,mm-commits@vger.kernel.org,torvalds@linux-foundation.org,akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220323160453.65922ced539cbf445b191555@linux-foundation.org> Subject: [patch 20/41] fs/pipe: use kvcalloc to allocate a pipe_buffer array Message-Id: <20220323230618.4E818C36AE7@smtp.kernel.org> X-Rspam-User: Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=bWw+flDn; spf=pass (imf09.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 2B761140025 X-Stat-Signature: 9j867xru9y9sjrm1h4gnijer85p4hp68 X-HE-Tag: 1648076779-203083 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: From: Andrei Vagin Subject: fs/pipe: use kvcalloc to allocate a pipe_buffer array Right now, kcalloc is used to allocate a pipe_buffer array. The size of the pipe_buffer struct is 40 bytes. kcalloc allows allocating reliably chunks with sizes less or equal to PAGE_ALLOC_COSTLY_ORDER (3). It means that the maximum pipe size is 3.2MB in this case. In CRIU, we use pipes to dump processes memory. CRIU freezes a target process, injects a parasite code into it and then this code splices memory into pipes. If a maximum pipe size is small, we need to do many iterations or create many pipes. kvcalloc attempt to allocate physically contiguous memory, but upon failure, fall back to non-contiguous (vmalloc) allocation and so it isn't limited by PAGE_ALLOC_COSTLY_ORDER. The maximum pipe size for non-root users is limited by the /proc/sys/fs/pipe-max-size sysctl that is 1MB by default, so only the root user will be able to trigger vmalloc allocations. Link: https://lkml.kernel.org/r/20220104171058.22580-1-avagin@gmail.com Signed-off-by: Andrei Vagin Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com> Cc: Alexander Viro Signed-off-by: Andrew Morton --- fs/pipe.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) --- a/fs/pipe.c~fs-pipe-use-kvcalloc-to-allocate-a-pipe_buffer-array +++ a/fs/pipe.c @@ -804,7 +804,7 @@ struct pipe_inode_info *alloc_pipe_info( if (too_many_pipe_buffers_hard(user_bufs) && pipe_is_unprivileged_user()) goto out_revert_acct; - pipe->bufs = kcalloc(pipe_bufs, sizeof(struct pipe_buffer), + pipe->bufs = kvcalloc(pipe_bufs, sizeof(struct pipe_buffer), GFP_KERNEL_ACCOUNT); if (pipe->bufs) { @@ -849,7 +849,7 @@ void free_pipe_info(struct pipe_inode_in #endif if (pipe->tmp_page) __free_page(pipe->tmp_page); - kfree(pipe->bufs); + kvfree(pipe->bufs); kfree(pipe); } @@ -1264,8 +1264,7 @@ int pipe_resize_ring(struct pipe_inode_i if (nr_slots < n) return -EBUSY; - bufs = kcalloc(nr_slots, sizeof(*bufs), - GFP_KERNEL_ACCOUNT | __GFP_NOWARN); + bufs = kvcalloc(nr_slots, sizeof(*bufs), GFP_KERNEL_ACCOUNT); if (unlikely(!bufs)) return -ENOMEM; @@ -1292,7 +1291,7 @@ int pipe_resize_ring(struct pipe_inode_i head = n; tail = 0; - kfree(pipe->bufs); + kvfree(pipe->bufs); pipe->bufs = bufs; pipe->ring_size = nr_slots; if (pipe->max_usage > nr_slots)