diff mbox series

arm: flush: check if the folio is reserved for IMO addresses

Message ID 20240222140147.1880357-1-liuyongqiang13@huawei.com (mailing list archive)
State New, archived
Headers show
Series arm: flush: check if the folio is reserved for IMO addresses | expand

Commit Message

Yongqiang Liu Feb. 22, 2024, 2:01 p.m. UTC 
Since commit a4d5613c4dc6 ("arm: extend pfn_valid to take into account
freed memory map alignment") changes the semantics of pfn_valid() to check
presence of the memory map for a PFN. A valid page for an address which
is reserved but not mapped by the kernel[1].In Some uio case we will get
a crash on a system with the following memory layout:

 node   0: [mem 0x00000000c0a00000-0x00000000cc8fffff]
 node   0: [mem 0x00000000d0000000-0x00000000da1fffff]
 the uio layout is：0xc0900000, 0x100000

the crash backtrace like:

  Unable to handle kernel paging request at virtual address bff00000
  [...]
  CPU: 1 PID: 465 Comm: startapp.bin Tainted: G           O      5.10.0 #1
  Hardware name: Generic DT based system
  PC is at b15_flush_kern_dcache_area+0x24/0x3c
  LR is at __sync_icache_dcache+0x6c/0x98
  [...]
   (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98)
   (__sync_icache_dcache) from (set_pte_at+0x28/0x54)
   (set_pte_at) from (remap_pfn_range+0x1a0/0x274)
   (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio])
   (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4)
   (__mmap_region) from (__do_mmap_mm+0x3ec/0x440)
   (__do_mmap_mm) from (do_mmap+0x50/0x58)
   (do_mmap) from (vm_mmap_pgoff+0xfc/0x188)
   (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4)
   (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c)
  Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e)
  ---[ end trace 09cf0734c3805d52 ]---
  Kernel panic - not syncing: Fatal exception

So check if PG_reserved was set to solve this issue.

[1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/

Fixes: a4d5613c4dc6 ("arm: extend pfn_valid to take into account freed memory map alignment")
Suggested-by: Mike Rapoport <rppt@linux.ibm.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>
---
 arch/arm/mm/flush.c | 4 ++++
 1 file changed, 4 insertions(+)

Comments

Matthew Wilcox Feb. 22, 2024, 2:05 p.m. UTC | #1 
On Thu, Feb 22, 2024 at 10:01:47PM +0800, Yongqiang Liu wrote:
> @@ -296,6 +297,9 @@ void __sync_icache_dcache(pte_t pteval)
>  		return;
>  
>  	folio = page_folio(pfn_to_page(pfn));
> +	if (test_bit(PG_reserved, &folio->flags))
> +		return;

Why are you using PG_foo directly instead of the helpers?

	if (folio_test_reserved(folio))
Kefeng Wang Feb. 22, 2024, 2:06 p.m. UTC | #2 
On 2024/2/22 22:01, Yongqiang Liu wrote:
> Since commit a4d5613c4dc6 ("arm: extend pfn_valid to take into account
> freed memory map alignment") changes the semantics of pfn_valid() to check
> presence of the memory map for a PFN. A valid page for an address which
> is reserved but not mapped by the kernel[1].In Some uio case we will get
> a crash on a system with the following memory layout:
> 
>   node   0: [mem 0x00000000c0a00000-0x00000000cc8fffff]
>   node   0: [mem 0x00000000d0000000-0x00000000da1fffff]
>   the uio layout is：0xc0900000, 0x100000
> 
> the crash backtrace like:
> 
>    Unable to handle kernel paging request at virtual address bff00000
>    [...]
>    CPU: 1 PID: 465 Comm: startapp.bin Tainted: G           O      5.10.0 #1
>    Hardware name: Generic DT based system
>    PC is at b15_flush_kern_dcache_area+0x24/0x3c
>    LR is at __sync_icache_dcache+0x6c/0x98
>    [...]
>     (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98)
>     (__sync_icache_dcache) from (set_pte_at+0x28/0x54)
>     (set_pte_at) from (remap_pfn_range+0x1a0/0x274)
>     (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio])
>     (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4)
>     (__mmap_region) from (__do_mmap_mm+0x3ec/0x440)
>     (__do_mmap_mm) from (do_mmap+0x50/0x58)
>     (do_mmap) from (vm_mmap_pgoff+0xfc/0x188)
>     (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4)
>     (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c)
>    Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e)
>    ---[ end trace 09cf0734c3805d52 ]---
>    Kernel panic - not syncing: Fatal exception
> 
> So check if PG_reserved was set to solve this issue.
> 
> [1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/
> 
> Fixes: a4d5613c4dc6 ("arm: extend pfn_valid to take into account freed memory map alignment")
> Suggested-by: Mike Rapoport <rppt@linux.ibm.com>
> Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>
> ---
>   arch/arm/mm/flush.c | 4 ++++
>   1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/mm/flush.c b/arch/arm/mm/flush.c
> index d19d140a10c7..f2b99223a0ab 100644
> --- a/arch/arm/mm/flush.c
> +++ b/arch/arm/mm/flush.c
> @@ -15,6 +15,7 @@
>   #include <asm/smp_plat.h>
>   #include <asm/tlbflush.h>
>   #include <linux/hugetlb.h>
> +#include <linux/memblock.h>
这个删掉吧然后发出去
>   
>   #include "mm.h"
>   
> @@ -296,6 +297,9 @@ void __sync_icache_dcache(pte_t pteval)
>   		return;
>   
>   	folio = page_folio(pfn_to_page(pfn));
> +	if (test_bit(PG_reserved, &folio->flags))
> +		return;
> +
>   	if (cache_is_vipt_aliasing())
>   		mapping = folio_flush_mapping(folio);
>   	else
Russell King (Oracle) Feb. 22, 2024, 2:38 p.m. UTC | #3 
On Thu, Feb 22, 2024 at 10:06:04PM +0800, Kefeng Wang wrote:
> 
> 
> On 2024/2/22 22:01, Yongqiang Liu wrote:
> > Since commit a4d5613c4dc6 ("arm: extend pfn_valid to take into account
> > freed memory map alignment") changes the semantics of pfn_valid() to check
> > presence of the memory map for a PFN. A valid page for an address which
> > is reserved but not mapped by the kernel[1].In Some uio case we will get
> > a crash on a system with the following memory layout:
> > 
> >   node   0: [mem 0x00000000c0a00000-0x00000000cc8fffff]
> >   node   0: [mem 0x00000000d0000000-0x00000000da1fffff]
> >   the uio layout is：0xc0900000, 0x100000
> > 
> > the crash backtrace like:
> > 
> >    Unable to handle kernel paging request at virtual address bff00000
> >    [...]
> >    CPU: 1 PID: 465 Comm: startapp.bin Tainted: G           O      5.10.0 #1
> >    Hardware name: Generic DT based system
> >    PC is at b15_flush_kern_dcache_area+0x24/0x3c
> >    LR is at __sync_icache_dcache+0x6c/0x98
> >    [...]
> >     (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98)
> >     (__sync_icache_dcache) from (set_pte_at+0x28/0x54)
> >     (set_pte_at) from (remap_pfn_range+0x1a0/0x274)
> >     (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio])
> >     (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4)
> >     (__mmap_region) from (__do_mmap_mm+0x3ec/0x440)
> >     (__do_mmap_mm) from (do_mmap+0x50/0x58)
> >     (do_mmap) from (vm_mmap_pgoff+0xfc/0x188)
> >     (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4)
> >     (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c)
> >    Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e)
> >    ---[ end trace 09cf0734c3805d52 ]---
> >    Kernel panic - not syncing: Fatal exception
> > 
> > So check if PG_reserved was set to solve this issue.
> > 
> > [1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/
> > 
> > Fixes: a4d5613c4dc6 ("arm: extend pfn_valid to take into account freed memory map alignment")
> > Suggested-by: Mike Rapoport <rppt@linux.ibm.com>
> > Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>
> > ---
> >   arch/arm/mm/flush.c | 4 ++++
> >   1 file changed, 4 insertions(+)
> > 
> > diff --git a/arch/arm/mm/flush.c b/arch/arm/mm/flush.c
> > index d19d140a10c7..f2b99223a0ab 100644
> > --- a/arch/arm/mm/flush.c
> > +++ b/arch/arm/mm/flush.c
> > @@ -15,6 +15,7 @@
> >   #include <asm/smp_plat.h>
> >   #include <asm/tlbflush.h>
> >   #include <linux/hugetlb.h>
> > +#include <linux/memblock.h>
> 这个删掉吧然后发出去

Speak English so that everyone knows what you are saying. You are
participating in an international community where English is the
language that we use to communicate between ourselves.

Thanks.
Kefeng Wang Feb. 22, 2024, 2:47 p.m. UTC | #4 
On 2024/2/22 22:38, Russell King (Oracle) wrote:
> On Thu, Feb 22, 2024 at 10:06:04PM +0800, Kefeng Wang wrote:
>>
>>
>> On 2024/2/22 22:01, Yongqiang Liu wrote:
>>> Since commit a4d5613c4dc6 ("arm: extend pfn_valid to take into account
>>> freed memory map alignment") changes the semantics of pfn_valid() to check
>>> presence of the memory map for a PFN. A valid page for an address which
>>> is reserved but not mapped by the kernel[1].In Some uio case we will get
>>> a crash on a system with the following memory layout:
>>>
>>>    node   0: [mem 0x00000000c0a00000-0x00000000cc8fffff]
>>>    node   0: [mem 0x00000000d0000000-0x00000000da1fffff]
>>>    the uio layout is：0xc0900000, 0x100000
>>>
>>> the crash backtrace like:
>>>
>>>     Unable to handle kernel paging request at virtual address bff00000
>>>     [...]
>>>     CPU: 1 PID: 465 Comm: startapp.bin Tainted: G           O      5.10.0 #1
>>>     Hardware name: Generic DT based system
>>>     PC is at b15_flush_kern_dcache_area+0x24/0x3c
>>>     LR is at __sync_icache_dcache+0x6c/0x98
>>>     [...]
>>>      (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98)
>>>      (__sync_icache_dcache) from (set_pte_at+0x28/0x54)
>>>      (set_pte_at) from (remap_pfn_range+0x1a0/0x274)
>>>      (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio])
>>>      (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4)
>>>      (__mmap_region) from (__do_mmap_mm+0x3ec/0x440)
>>>      (__do_mmap_mm) from (do_mmap+0x50/0x58)
>>>      (do_mmap) from (vm_mmap_pgoff+0xfc/0x188)
>>>      (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4)
>>>      (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c)
>>>     Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e)
>>>     ---[ end trace 09cf0734c3805d52 ]---
>>>     Kernel panic - not syncing: Fatal exception
>>>
>>> So check if PG_reserved was set to solve this issue.
>>>
>>> [1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/
>>>
>>> Fixes: a4d5613c4dc6 ("arm: extend pfn_valid to take into account freed memory map alignment")
>>> Suggested-by: Mike Rapoport <rppt@linux.ibm.com>
>>> Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>
>>> ---
>>>    arch/arm/mm/flush.c | 4 ++++
>>>    1 file changed, 4 insertions(+)
>>>
>>> diff --git a/arch/arm/mm/flush.c b/arch/arm/mm/flush.c
>>> index d19d140a10c7..f2b99223a0ab 100644
>>> --- a/arch/arm/mm/flush.c
>>> +++ b/arch/arm/mm/flush.c
>>> @@ -15,6 +15,7 @@
>>>    #include <asm/smp_plat.h>
>>>    #include <asm/tlbflush.h>
>>>    #include <linux/hugetlb.h>
>>> +#include <linux/memblock.h>
>> 这个删掉吧然后发出去
> 
> Speak English so that everyone knows what you are saying. You are
> participating in an international community where English is the
> language that we use to communicate between ourselves.
> 
Sorry, I mistake for a internal mail

To Yongqiang, please drop the unnecessary include and as Matthew said,
please consider to use folio helper.

> Thanks.
>
Yongqiang Liu Feb. 23, 2024, 1:57 a.m. UTC | #5 
在 2024/2/22 22:05, Matthew Wilcox 写道:
> On Thu, Feb 22, 2024 at 10:01:47PM +0800, Yongqiang Liu wrote:
>> @@ -296,6 +297,9 @@ void __sync_icache_dcache(pte_t pteval)
>>   		return;
>>   
>>   	folio = page_folio(pfn_to_page(pfn));
>> +	if (test_bit(PG_reserved, &folio->flags))
>> +		return;
> Why are you using PG_foo directly instead of the helpers?
>
> 	if (folio_test_reserved(folio))
> .
Sorry, I will send v2.
diff mbox series

Patch

diff --git a/arch/arm/mm/flush.c b/arch/arm/mm/flush.c
index d19d140a10c7..f2b99223a0ab 100644
--- a/arch/arm/mm/flush.c
+++ b/arch/arm/mm/flush.c
@@ -15,6 +15,7 @@ 
 #include <asm/smp_plat.h>
 #include <asm/tlbflush.h>
 #include <linux/hugetlb.h>
+#include <linux/memblock.h>
 
 #include "mm.h"
 
@@ -296,6 +297,9 @@  void __sync_icache_dcache(pte_t pteval)
 		return;
 
 	folio = page_folio(pfn_to_page(pfn));
+	if (test_bit(PG_reserved, &folio->flags))
+		return;
+
 	if (cache_is_vipt_aliasing())
 		mapping = folio_flush_mapping(folio);
 	else