From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>,
Brad Warrum <bwarrum@linux.ibm.com>,
Eli Billauer <eli.billauer@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Michal Simek <michal.simek@amd.com>,
Ritu Agarwal <rituagar@linux.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Matthew Wilcox <willy@infradead.org>,
Mike Rapoport <rppt@kernel.org>,
Vlastimil Babka <vbabka@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linuxppc-dev@lists.ozlabs.org
Subject: [PATCH 4/4] platform: goldfish: pipe: replace __get_free_page() with kmalloc()
Date: Sun, 30 Aug 2026 10:48:01 +0300 [thread overview]
Message-ID: <20260830-char-misc-v1-4-05e2ce44f291@kernel.org> (raw)
In-Reply-To: <20260830-char-misc-v1-0-05e2ce44f291@kernel.org>
goldfish_pipe_open() allocates the per-pipe command buffer and
goldfish_pipe_device_init() allocates the buffers the device shares with
the host. Both are passed to the host as physical addresses and must be
physically contiguous, which kmalloc() guarantees.
These buffers can be allocated with kmalloc() as there's nothing special
about them to go directly to the page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
While on it, size both allocations after the structures they hold instead
of always taking a full page.
Replace use of __get_free_page() with kmalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Assisted-by: copilot:claude-opus
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
---
drivers/platform/goldfish/goldfish_pipe.c | 22 ++++++++++------------
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c b/drivers/platform/goldfish/goldfish_pipe.c
index fa241ca8feb0..3f34db896ece 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -708,12 +708,11 @@ static int goldfish_pipe_open(struct inode *inode, struct file *file)
init_waitqueue_head(&pipe->wake_queue);
/*
- * Command buffer needs to be allocated on its own page to make sure
- * it is physically contiguous in host's address space.
+ * The command buffer is passed to the host as a physical address, so
+ * it must be physically contiguous, which kmalloc() guarantees.
*/
BUILD_BUG_ON(sizeof(struct goldfish_pipe_command) > PAGE_SIZE);
- pipe->command_buffer =
- (struct goldfish_pipe_command *)__get_free_page(GFP_KERNEL);
+ pipe->command_buffer = kmalloc_obj(*pipe->command_buffer);
if (!pipe->command_buffer) {
status = -ENOMEM;
goto err_pipe;
@@ -749,7 +748,7 @@ static int goldfish_pipe_open(struct inode *inode, struct file *file)
dev->pipes[id] = NULL;
err_id_locked:
spin_unlock_irqrestore(&dev->lock, flags);
- free_page((unsigned long)pipe->command_buffer);
+ kfree(pipe->command_buffer);
err_pipe:
kfree(pipe);
return status;
@@ -770,7 +769,7 @@ static int goldfish_pipe_release(struct inode *inode, struct file *filp)
spin_unlock_irqrestore(&dev->lock, flags);
filp->private_data = NULL;
- free_page((unsigned long)pipe->command_buffer);
+ kfree(pipe->command_buffer);
kfree(pipe);
return 0;
}
@@ -833,13 +832,12 @@ static int goldfish_pipe_device_init(struct platform_device *pdev,
/*
* We're going to pass two buffers, open_command_params and
- * signalled_pipe_buffers, to the host. This means each of those buffers
- * needs to be contained in a single physical page. The easiest choice
- * is to just allocate a page and place the buffers in it.
+ * signalled_pipe_buffers, to the host as physical addresses. This means
+ * each of those buffers needs to be physically contiguous, which
+ * kmalloc() guarantees.
*/
BUILD_BUG_ON(sizeof(struct goldfish_pipe_dev_buffers) > PAGE_SIZE);
- dev->buffers = (struct goldfish_pipe_dev_buffers *)
- __get_free_page(GFP_KERNEL);
+ dev->buffers = kmalloc_obj(*dev->buffers);
if (!dev->buffers) {
kfree(dev->pipes);
misc_deregister(&dev->miscdev);
@@ -867,7 +865,7 @@ static void goldfish_pipe_device_deinit(struct platform_device *pdev,
{
misc_deregister(&dev->miscdev);
kfree(dev->pipes);
- free_page((unsigned long)dev->buffers);
+ kfree(dev->buffers);
}
static int goldfish_pipe_probe(struct platform_device *pdev)
--
2.53.0
prev parent reply other threads:[~2026-08-30 7:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-30 7:47 [PATCH 0/4] char/misc: replace page allocator calls with k[mz]alloc() Mike Rapoport (Microsoft)
2026-08-30 7:47 ` [PATCH 1/4] char: xilinx_hwicap: " Mike Rapoport (Microsoft)
2026-08-30 7:47 ` [PATCH 2/4] char: xillybus: replace __get_free_pages() with kmalloc() Mike Rapoport (Microsoft)
2026-08-30 7:48 ` [PATCH 3/4] misc: ibmvmc: replace get_zeroed_page() with kzalloc() Mike Rapoport (Microsoft)
2026-08-30 7:48 ` Mike Rapoport (Microsoft) [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260830-char-misc-v1-4-05e2ce44f291@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=bwarrum@linux.ibm.com \
--cc=david@kernel.org \
--cc=eli.billauer@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=michal.simek@amd.com \
--cc=rituagar@linux.ibm.com \
--cc=vbabka@kernel.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®