From: John David Anglin <dave@parisc-linux.org>
To: linux-parisc@vger.kernel.org
Cc: Helge Deller <deller@gmx.de>
Subject: [PATCH] parisc: Try to fix random segmentation faults in package builds
Date: Sun, 5 May 2024 16:58:51 +0000 [thread overview]
Message-ID: <Zje6ywzNAltbG3R2@mx3210.localdomain> (raw)
[-- Attachment #1: Type: text/plain, Size: 3573 bytes --]
The majority of random segmentation faults that I have looked at
appear to be memory corruption in memory allocated using mmap and
malloc. This got me thinking that there might be issues with the
parisc implementation of flush_anon_page.
On PA8800/PA8900 CPUs, we use flush_user_cache_page to flush anonymous
pages. I modified flush_user_cache_page to leave interrupts disabled
for the entire flush just to be sure the context didn't get modified
mid flush.
In looking at the implementation of flush_anon_page on other architectures,
I noticed that they all invalidate the kernel mapping as well as flush
the user page. I added code to invalidate the kernel mapping to this
page in the PA8800/PA8900 path. It's possible this is also needed for
other processors but I don't have a way to test.
I removed using flush_data_cache when the mapping is shared. In theory,
shared mappings are all equivalent, so flush_user_cache_page should
flush all shared mappings. It is much faster.
Lightly tested on rp3440 and c8000.
Signed-off-by: John David Anglin <dave.anglin@bell.net>
---
diff --git a/arch/parisc/kernel/cache.c b/arch/parisc/kernel/cache.c
index ca4a302d4365..8d14a8a5d4d6 100644
--- a/arch/parisc/kernel/cache.c
+++ b/arch/parisc/kernel/cache.c
@@ -333,8 +333,6 @@ static void flush_user_cache_page(struct vm_area_struct *vma, unsigned long vmad
vmaddr &= PAGE_MASK;
- preempt_disable();
-
/* Set context for flush */
local_irq_save(flags);
prot = mfctl(8);
@@ -344,7 +342,6 @@ static void flush_user_cache_page(struct vm_area_struct *vma, unsigned long vmad
pgd_lock = mfctl(28);
#endif
switch_mm_irqs_off(NULL, vma->vm_mm, NULL);
- local_irq_restore(flags);
flush_user_dcache_range_asm(vmaddr, vmaddr + PAGE_SIZE);
if (vma->vm_flags & VM_EXEC)
@@ -352,7 +349,6 @@ static void flush_user_cache_page(struct vm_area_struct *vma, unsigned long vmad
flush_tlb_page(vma, vmaddr);
/* Restore previous context */
- local_irq_save(flags);
#ifdef CONFIG_TLB_PTLOCK
mtctl(pgd_lock, 28);
#endif
@@ -360,8 +356,6 @@ static void flush_user_cache_page(struct vm_area_struct *vma, unsigned long vmad
mtsp(space, SR_USER);
mtctl(prot, 8);
local_irq_restore(flags);
-
- preempt_enable();
}
static inline pte_t *get_ptep(struct mm_struct *mm, unsigned long addr)
@@ -543,7 +537,7 @@ void __init parisc_setup_cache_timing(void)
parisc_tlb_flush_threshold/1024);
}
-extern void purge_kernel_dcache_page_asm(unsigned long);
+extern void purge_kernel_dcache_page_asm(const void *addr);
extern void clear_user_page_asm(void *, unsigned long);
extern void copy_user_page_asm(void *, void *, unsigned long);
@@ -558,6 +552,16 @@ void flush_kernel_dcache_page_addr(const void *addr)
}
EXPORT_SYMBOL(flush_kernel_dcache_page_addr);
+static void purge_kernel_dcache_page_addr(const void *addr)
+{
+ unsigned long flags;
+
+ purge_kernel_dcache_page_asm(addr);
+ purge_tlb_start(flags);
+ pdtlb(SR_KERNEL, addr);
+ purge_tlb_end(flags);
+}
+
static void flush_cache_page_if_present(struct vm_area_struct *vma,
unsigned long vmaddr, unsigned long pfn)
{
@@ -725,10 +729,8 @@ void flush_anon_page(struct vm_area_struct *vma, struct page *page, unsigned lon
return;
if (parisc_requires_coherency()) {
- if (vma->vm_flags & VM_SHARED)
- flush_data_cache();
- else
- flush_user_cache_page(vma, vmaddr);
+ flush_user_cache_page(vma, vmaddr);
+ purge_kernel_dcache_page_addr(page_address(page));
return;
}
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next reply other threads:[~2024-05-05 17:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-05 16:58 John David Anglin [this message]
2024-05-08 8:54 ` [PATCH] parisc: Try to fix random segmentation faults in package builds Vidra.Jonas
2024-05-08 15:23 ` John David Anglin
2024-05-08 19:18 ` matoro
2024-05-08 20:52 ` John David Anglin
2024-05-08 23:51 ` matoro
2024-05-09 1:21 ` John David Anglin
2024-05-09 17:10 ` John David Anglin
2024-05-12 6:57 ` Vidra.Jonas
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=Zje6ywzNAltbG3R2@mx3210.localdomain \
--to=dave@parisc-linux.org \
--cc=deller@gmx.de \
--cc=linux-parisc@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 read-only IMAP folder(s) and NNTP newsgroup(s).