From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
patches@lists.linux.dev, Helge Deller <deller@gmx.de>,
Vidra.Jonas@seznam.cz, Sam James <sam@gentoo.org>,
John David Anglin <dave.anglin@bell.net>,
Jens Axboe <axboe@kernel.dk>
Subject: [PATCH 6.1 09/10] io_uring/parisc: Adjust pgoff in io_uring mmap() for parisc
Date: Thu, 31 Aug 2023 13:10:49 +0200 [thread overview]
Message-ID: <20230831110831.423681984@linuxfoundation.org> (raw)
In-Reply-To: <20230831110831.079963475@linuxfoundation.org>
6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Helge Deller <deller@gmx.de>
Vidra Jonas reported issues on parisc with libuv which then triggers
build errors with cmake. Debugging shows that those issues stem from
io_uring().
I was not able to easily pull in upstream commits directly, so here
is IMHO the least invasive manual backport of the following upstream
commits to fix the cache aliasing issues on parisc on kernel 6.1
with io_uring:
56675f8b9f9b ("io_uring/parisc: Adjust pgoff in io_uring mmap() for parisc")
32832a407a71 ("io_uring: Fix io_uring mmap() by using architecture-provided get_unmapped_area()")
d808459b2e31 ("io_uring: Adjust mapping wrt architecture aliasing requirements")
With this patch kernel 6.1 has all relevant mmap changes and is
identical to kernel 6.5 with regard to mmap() in io_uring.
Signed-off-by: Helge Deller <deller@gmx.de>
Reported-by: Vidra.Jonas@seznam.cz
Link: https://lore.kernel.org/linux-parisc/520.NvTX.6mXZpmfh4Ju.1awpAS@seznam.cz/
Cc: Sam James <sam@gentoo.org>
Cc: John David Anglin <dave.anglin@bell.net>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
io_uring/io_uring.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
--- a/io_uring/io_uring.c
+++ b/io_uring/io_uring.c
@@ -72,6 +72,7 @@
#include <linux/io_uring.h>
#include <linux/audit.h>
#include <linux/security.h>
+#include <asm/shmparam.h>
#define CREATE_TRACE_POINTS
#include <trace/events/io_uring.h>
@@ -3110,6 +3111,49 @@ static __cold int io_uring_mmap(struct f
return remap_pfn_range(vma, vma->vm_start, pfn, sz, vma->vm_page_prot);
}
+static unsigned long io_uring_mmu_get_unmapped_area(struct file *filp,
+ unsigned long addr, unsigned long len,
+ unsigned long pgoff, unsigned long flags)
+{
+ void *ptr;
+
+ /*
+ * Do not allow to map to user-provided address to avoid breaking the
+ * aliasing rules. Userspace is not able to guess the offset address of
+ * kernel kmalloc()ed memory area.
+ */
+ if (addr)
+ return -EINVAL;
+
+ ptr = io_uring_validate_mmap_request(filp, pgoff, len);
+ if (IS_ERR(ptr))
+ return -ENOMEM;
+
+ /*
+ * Some architectures have strong cache aliasing requirements.
+ * For such architectures we need a coherent mapping which aliases
+ * kernel memory *and* userspace memory. To achieve that:
+ * - use a NULL file pointer to reference physical memory, and
+ * - use the kernel virtual address of the shared io_uring context
+ * (instead of the userspace-provided address, which has to be 0UL
+ * anyway).
+ * - use the same pgoff which the get_unmapped_area() uses to
+ * calculate the page colouring.
+ * For architectures without such aliasing requirements, the
+ * architecture will return any suitable mapping because addr is 0.
+ */
+ filp = NULL;
+ flags |= MAP_SHARED;
+ pgoff = 0; /* has been translated to ptr above */
+#ifdef SHM_COLOUR
+ addr = (uintptr_t) ptr;
+ pgoff = addr >> PAGE_SHIFT;
+#else
+ addr = 0UL;
+#endif
+ return current->mm->get_unmapped_area(filp, addr, len, pgoff, flags);
+}
+
#else /* !CONFIG_MMU */
static int io_uring_mmap(struct file *file, struct vm_area_struct *vma)
@@ -3324,6 +3368,8 @@ static const struct file_operations io_u
#ifndef CONFIG_MMU
.get_unmapped_area = io_uring_nommu_get_unmapped_area,
.mmap_capabilities = io_uring_nommu_mmap_capabilities,
+#else
+ .get_unmapped_area = io_uring_mmu_get_unmapped_area,
#endif
.poll = io_uring_poll,
#ifdef CONFIG_PROC_FS
next prev parent reply other threads:[~2023-08-31 11:12 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-31 11:10 [PATCH 6.1 00/10] 6.1.51-rc1 review Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 6.1 01/10] ACPI: thermal: Drop nocrt parameter Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 6.1 02/10] module: Expose module_init_layout_section() Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 6.1 03/10] arm64: module-plts: inline linux/moduleloader.h Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 6.1 04/10] arm64: module: Use module_init_layout_section() to spot init sections Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 6.1 05/10] ARM: " Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 6.1 06/10] lockdep: fix static memory detection even more Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 6.1 07/10] parisc: Cleanup mmap implementation regarding color alignment Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 6.1 08/10] parisc: sys_parisc: parisc_personality() is called from asm code Greg Kroah-Hartman
2023-08-31 11:10 ` Greg Kroah-Hartman [this message]
2023-08-31 11:10 ` [PATCH 6.1 10/10] kallsyms: Fix kallsyms_selftest failure Greg Kroah-Hartman
2023-08-31 21:14 ` [PATCH 6.1 00/10] 6.1.51-rc1 review Florian Fainelli
2023-09-01 1:03 ` SeongJae Park
2023-09-01 6:15 ` Ron Economos
2023-09-01 8:17 ` Naresh Kamboju
2023-09-01 8:47 ` Bagas Sanjaya
2023-09-01 9:41 ` Sudip Mukherjee (Codethink)
2023-09-01 15:30 ` Shuah Khan
2023-09-01 15:42 ` Takeshi Ogasawara
2023-09-01 18:46 ` Jon Hunter
2023-09-02 4:19 ` Guenter Roeck
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=20230831110831.423681984@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=Vidra.Jonas@seznam.cz \
--cc=axboe@kernel.dk \
--cc=dave.anglin@bell.net \
--cc=deller@gmx.de \
--cc=patches@lists.linux.dev \
--cc=sam@gentoo.org \
--cc=stable@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).