From: David Hildenbrand <david@redhat.com>
To: Qi Zheng <zhengqi.arch@bytedance.com>
Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>,
Ezra Buehler <ezra@easyb.ch>,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
Muchun Song <muchun.song@linux.dev>,
Vlastimil Babka <vbabka@suse.cz>,
Ryan Roberts <ryan.roberts@arm.com>,
"Vishal Moola (Oracle)" <vishal.moola@gmail.com>,
Hugh Dickins <hughd@google.com>,
Matthew Wilcox <willy@infradead.org>,
Peter Xu <peterx@redhat.com>,
Nicolas Ferre <nicolas.ferre@microchip.com>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Claudiu Beznea <claudiu.beznea@tuxon.dev>,
open list <linux-kernel@vger.kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [REGRESSION] NULL pointer dereference on ARM (AT91SAM9G25) during compaction
Date: Tue, 11 Feb 2025 13:09:37 +0100 [thread overview]
Message-ID: <bad8e013-3d01-4fe5-8783-c6d7e0e32a74@redhat.com> (raw)
In-Reply-To: <4e298f68-36ff-496a-81d2-7124f792180d@bytedance.com>
On 11.02.25 10:43, Qi Zheng wrote:
>
>
> On 2025/2/11 17:37, David Hildenbrand wrote:
>> On 11.02.25 10:29, Qi Zheng wrote:
>>>
>>>
>>> On 2025/2/11 17:14, David Hildenbrand wrote:
>>>> On 11.02.25 04:45, Qi Zheng wrote:
>>>>> Hi Russell,
>>>>>
>>>>> On 2025/2/11 01:03, Russell King (Oracle) wrote:
>>>>>> On Mon, Feb 10, 2025 at 05:49:38PM +0100, Ezra Buehler wrote:
>>>>>>> When running vanilla Linux 6.13 or newer (6.14-rc2) on the
>>>>>>> AT91SAM9G25-based GARDENA smart Gateway, we are seeing a NULL pointer
>>>>>>> dereference resulting in a kernel panic. The culprit seems to be
>>>>>>> commit
>>>>>>> fc9c45b71f43 ("arm: adjust_pte() usepte_offset_map_rw_nolock()").
>>>>>>> Reverting the commit apparently fixes the issue.
>>>>>>
>>>>>> The blamed commit is buggy:
>>>>>>
>>>>>> arch/arm/include/asm/tlbflush.h:
>>>>>> #define update_mmu_cache(vma, addr, ptep) \
>>>>>> update_mmu_cache_range(NULL, vma, addr, ptep, 1)
>>>>>>
>>>>>> So vmf can be NULL. This didn't used to matter before this commit,
>>>>>> because vmf was not used by ARM's update_mmu_cache_range(). However,
>>>>>> the commit introduced a dereference of it, which now causes a NULL
>>>>>> point dereference.
>>>>>>
>>>>>> Not sure what the correct solution is, but at a guess, both:
>>>>>>
>>>>>> if (ptl != vmf->ptl)
>>>>>>
>>>>>> need to become:
>>>>>>
>>>>>> if (!vmf || ptl != vmf->ptl)
>>>>>
>>>>> No, we can't do that, because without using split PTE locks, we would
>>>>> use shared mm->page_table_lock, which would create a deadlock.
>>>>
>>>> Maybe we can simply special-case on CONFIG_SPLIT_PTE_PTLOCKS ?
>>>>
>>>> if (IS_ENABLED(CONFIG_SPLIT_PTE_PTLOCKS)) {
>>>
>>> In this case, if two vmas map the same PTE page, then the same PTE lock
>>> will be held repeatedly. Right?
>>
>> Hmm, the comment says:
>>
>> /*
>> * This is called while another page table is mapped, so we
>> * must use the nested version. This also means we need to
>> * open-code the spin-locking.
>> */
>>
>> "another page table" implies that it cannot be the same. But maybe that
>> comment was also wrong?
>
> I don't see make_coherent() ensuring this when traversing vma.
Right, we could just have the same file range mapped MAP_SHARED into the
same page table using two VMAs ... I suspect writing a reproducer for
the deadlock should be easy.
I therefore propose the following changes:
>
> diff --git a/arch/arm/mm/fault-armv.c b/arch/arm/mm/fault-armv.c
> index 2bec87c3327d2..dddbca9a2597e 100644
> --- a/arch/arm/mm/fault-armv.c
> +++ b/arch/arm/mm/fault-armv.c
> @@ -61,8 +61,41 @@ static int do_adjust_pte(struct vm_area_struct *vma,
> unsigned long address,
> return ret;
> }
>
> +#if defined(CONFIG_SPLIT_PTE_PTLOCKS)
> +/*
> + * If we are using split PTE locks, then we need to take the pte
> + * lock here. Otherwise we are using shared mm->page_table_lock
> + * which is already locked, thus cannot take it.
> + */
> +static inline bool do_pte_lock(spinlock_t *ptl, pmd_t pmdval, pmd_t *pmd)
> +{
> + /*
> + * Use nested version here to indicate that we are already
> + * holding one similar spinlock.
> + */
> + spin_lock_nested(ptl, SINGLE_DEPTH_NESTING);
> + if (unlikely(!pmd_same(pmdval, pmdp_get_lockless(pmd)))) {
> + spin_unlock(ptl);
> + return false;
> + }
> +
> + return true;
> +}
> +
> +static inline void do_pte_unlock(spinlock_t *ptl)
> +{
> + spin_unlock(ptl);
> +}
> +#else /* !defined(CONFIG_SPLIT_PTE_PTLOCKS) */
> +static inline bool do_pte_lock(spinlock_t *ptl)
> +{
> + return true;
> +}
> +static inline void do_pte_unlock(spinlock_t *ptl) {}
> +#endif /* defined(CONFIG_SPLIT_PTE_PTLOCKS) */
> +
> static int adjust_pte(struct vm_area_struct *vma, unsigned long address,
> - unsigned long pfn, struct vm_fault *vmf)
> + unsigned long pfn)
> {
> spinlock_t *ptl;
> pgd_t *pgd;
> @@ -99,23 +132,14 @@ static int adjust_pte(struct vm_area_struct *vma,
> unsigned long address,
> if (!pte)
> return 0;
>
> - /*
> - * If we are using split PTE locks, then we need to take the page
> - * lock here. Otherwise we are using shared mm->page_table_lock
> - * which is already locked, thus cannot take it.
> - */
> - if (ptl != vmf->ptl) {
> - spin_lock_nested(ptl, SINGLE_DEPTH_NESTING);
> - if (unlikely(!pmd_same(pmdval, pmdp_get_lockless(pmd)))) {
> - pte_unmap_unlock(pte, ptl);
> - goto again;
> - }
> + if (!do_pte_lock(ptl, pmdval, pmd)) {
> + pte_unmap(pte);
> + goto again;
> }
>
> ret = do_adjust_pte(vma, address, pfn, pte);
>
> - if (ptl != vmf->ptl)
> - spin_unlock(ptl);
> + do_pte_unlock(ptl);
> pte_unmap(pte);
>
> return ret;
> @@ -123,16 +147,17 @@ static int adjust_pte(struct vm_area_struct *vma,
> unsigned long address,
>
> static void
> make_coherent(struct address_space *mapping, struct vm_area_struct *vma,
> - unsigned long addr, pte_t *ptep, unsigned long pfn,
> - struct vm_fault *vmf)
> + unsigned long addr, pte_t *ptep, unsigned long pfn)
> {
> struct mm_struct *mm = vma->vm_mm;
> struct vm_area_struct *mpnt;
> unsigned long offset;
> + unsigned long start;
> pgoff_t pgoff;
> int aliases = 0;
>
> pgoff = vma->vm_pgoff + ((addr - vma->vm_start) >> PAGE_SHIFT);
> + start = ALIGN_DOWN(addr, PMD_SIZE);
>
> /*
> * If we have any shared mappings that are in the same mm
> @@ -141,6 +166,8 @@ make_coherent(struct address_space *mapping, struct
> vm_area_struct *vma,
> */
> flush_dcache_mmap_lock(mapping);
> vma_interval_tree_foreach(mpnt, &mapping->i_mmap, pgoff, pgoff) {
> + unsigned long mpnt_addr;
> +
> /*
> * If this VMA is not in our MM, we can ignore it.
> * Note that we intentionally mask out the VMA
> @@ -151,7 +178,14 @@ make_coherent(struct address_space *mapping, struct
> vm_area_struct *vma,
> if (!(mpnt->vm_flags & VM_MAYSHARE))
> continue;
> offset = (pgoff - mpnt->vm_pgoff) << PAGE_SHIFT;
> - aliases += adjust_pte(mpnt, mpnt->vm_start + offset,
> pfn, vmf);
> + mpnt_addr = mpnt->vm_start + offset;
> + /*
> + * If mpnt_addr and addr are mapped to the same PTE page,
> + * also skip this vma.
> + */
> + if (mpnt_addr >= start && mpnt_addr - start < PMD_SIZE)
> + continue;
Hmm, but is skipping the right thing to do? Maybe you would want to
indicate to adjust_pte() whether it must take the PTL or not.
I did not study that code in detail, though ...
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2025-02-11 12:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-10 16:49 Ezra Buehler
2025-02-10 17:03 ` Russell King (Oracle)
2025-02-11 3:45 ` Qi Zheng
2025-02-11 9:14 ` David Hildenbrand
2025-02-11 9:29 ` Qi Zheng
2025-02-11 9:37 ` David Hildenbrand
2025-02-11 9:43 ` Qi Zheng
2025-02-11 12:09 ` David Hildenbrand [this message]
2025-02-11 12:41 ` Qi Zheng
2025-02-12 6:40 ` [PATCH] arm: pgtable: fix NULL pointer dereference issue Qi Zheng
2025-02-12 7:27 ` Ezra Buehler
2025-02-12 7:32 ` Qi Zheng
2025-02-12 8:20 ` David Hildenbrand
2025-02-12 8:28 ` Qi Zheng
2025-02-12 8:30 ` David Hildenbrand
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=bad8e013-3d01-4fe5-8783-c6d7e0e32a74@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alexandre.belloni@bootlin.com \
--cc=claudiu.beznea@tuxon.dev \
--cc=ezra@easyb.ch \
--cc=hughd@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@armlinux.org.uk \
--cc=muchun.song@linux.dev \
--cc=nicolas.ferre@microchip.com \
--cc=peterx@redhat.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=vbabka@suse.cz \
--cc=vishal.moola@gmail.com \
--cc=willy@infradead.org \
--cc=zhengqi.arch@bytedance.com \
/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