Re: [PATCH v9 02/10] mm: Non-pmd-mappable, large folios for folio_add_new_anon_rmap()

Re: [PATCH v9 02/10] mm: Non-pmd-mappable, large folios for folio_add_new_anon_rmap()

[Sven Schnelle]

Ryan Roberts <ryan.roberts@arm.com> writes:

> On 14/01/2024 20:55, Jiri Olsa wrote:
>> On Sun, Jan 14, 2024 at 06:33:56PM +0100, David Hildenbrand wrote:
>>> On 13.01.24 23:42, Jiri Olsa wrote:
>>>> On Thu, Dec 07, 2023 at 04:12:03PM +0000, Ryan Roberts wrote:
>>>>> In preparation for supporting anonymous multi-size THP, improve
>>>>> folio_add_new_anon_rmap() to allow a non-pmd-mappable, large folio to be
>>>>> passed to it. In this case, all contained pages are accounted using the
>>>>> order-0 folio (or base page) scheme.
>>>>>
>>>>> Reviewed-by: Yu Zhao <yuzhao@google.com>
>>>>> Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
>>>>> Reviewed-by: David Hildenbrand <david@redhat.com>
>>>>> Reviewed-by: Barry Song <v-songbaohua@oppo.com>
>>>>> Tested-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>>>>> Tested-by: John Hubbard <jhubbard@nvidia.com>
>>>>> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
>>>>> ---
>>>>>   mm/rmap.c | 28 ++++++++++++++++++++--------
>>>>>   1 file changed, 20 insertions(+), 8 deletions(-)
>>>>>
>>>>> diff --git a/mm/rmap.c b/mm/rmap.c
>>>>> index 2a1e45e6419f..846fc79f3ca9 100644
>>>>> --- a/mm/rmap.c
>>>>> +++ b/mm/rmap.c
>>>>> @@ -1335,32 +1335,44 @@ void page_add_anon_rmap(struct page *page, struct vm_area_struct *vma,
>>>>>    * This means the inc-and-test can be bypassed.
>>>>>    * The folio does not have to be locked.
>>>>>    *
>>>>> - * If the folio is large, it is accounted as a THP.  As the folio
>>>>> + * If the folio is pmd-mappable, it is accounted as a THP.  As the folio
>>>>>    * is new, it's assumed to be mapped exclusively by a single process.
>>>>>    */
>>>>>   void folio_add_new_anon_rmap(struct folio *folio, struct vm_area_struct *vma,
>>>>>   		unsigned long address)
>>>>>   {
>>>>> -	int nr;
>>>>> +	int nr = folio_nr_pages(folio);
>>>>> -	VM_BUG_ON_VMA(address < vma->vm_start || address >= vma->vm_end, vma);
>>>>> +	VM_BUG_ON_VMA(address < vma->vm_start ||
>>>>> +			address + (nr << PAGE_SHIFT) > vma->vm_end, vma);
>>>>
>>>> hi,
>>>> I'm hitting this bug (console output below) with adding uprobe
>>>> on simple program like:
>>>>
>>>>    $ cat up.c
>>>>    int main(void)
>>>>    {
>>>>       return 0;
>>>>    }
>>>>
>>>>    # bpftrace -e 'uprobe:/home/jolsa/up:_start {}'
>>>>
>>>>    $ ./up
>>>>
>>>> it's on top of current linus tree master:
>>>>    052d534373b7 Merge tag 'exfat-for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat
>>>>
>>>> before this patch it seems to work, I can send my .config if needed
>
> Thanks for the bug report!

I just hit the same bug in our CI, but can't find the fix in -next. Is
this in the queue somewhere?

Thanks
Sven

Re: [PATCH v9 02/10] mm: Non-pmd-mappable, large folios for folio_add_new_anon_rmap()

[Jiri Olsa]

On Wed, Jan 24, 2024 at 12:15:52PM +0100, Sven Schnelle wrote:
> Ryan Roberts <ryan.roberts@arm.com> writes:
> 
> > On 14/01/2024 20:55, Jiri Olsa wrote:
> >> On Sun, Jan 14, 2024 at 06:33:56PM +0100, David Hildenbrand wrote:
> >>> On 13.01.24 23:42, Jiri Olsa wrote:
> >>>> On Thu, Dec 07, 2023 at 04:12:03PM +0000, Ryan Roberts wrote:
> >>>>> In preparation for supporting anonymous multi-size THP, improve
> >>>>> folio_add_new_anon_rmap() to allow a non-pmd-mappable, large folio to be
> >>>>> passed to it. In this case, all contained pages are accounted using the
> >>>>> order-0 folio (or base page) scheme.
> >>>>>
> >>>>> Reviewed-by: Yu Zhao <yuzhao@google.com>
> >>>>> Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
> >>>>> Reviewed-by: David Hildenbrand <david@redhat.com>
> >>>>> Reviewed-by: Barry Song <v-songbaohua@oppo.com>
> >>>>> Tested-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> >>>>> Tested-by: John Hubbard <jhubbard@nvidia.com>
> >>>>> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
> >>>>> ---
> >>>>>   mm/rmap.c | 28 ++++++++++++++++++++--------
> >>>>>   1 file changed, 20 insertions(+), 8 deletions(-)
> >>>>>
> >>>>> diff --git a/mm/rmap.c b/mm/rmap.c
> >>>>> index 2a1e45e6419f..846fc79f3ca9 100644
> >>>>> --- a/mm/rmap.c
> >>>>> +++ b/mm/rmap.c
> >>>>> @@ -1335,32 +1335,44 @@ void page_add_anon_rmap(struct page *page, struct vm_area_struct *vma,
> >>>>>    * This means the inc-and-test can be bypassed.
> >>>>>    * The folio does not have to be locked.
> >>>>>    *
> >>>>> - * If the folio is large, it is accounted as a THP.  As the folio
> >>>>> + * If the folio is pmd-mappable, it is accounted as a THP.  As the folio
> >>>>>    * is new, it's assumed to be mapped exclusively by a single process.
> >>>>>    */
> >>>>>   void folio_add_new_anon_rmap(struct folio *folio, struct vm_area_struct *vma,
> >>>>>   		unsigned long address)
> >>>>>   {
> >>>>> -	int nr;
> >>>>> +	int nr = folio_nr_pages(folio);
> >>>>> -	VM_BUG_ON_VMA(address < vma->vm_start || address >= vma->vm_end, vma);
> >>>>> +	VM_BUG_ON_VMA(address < vma->vm_start ||
> >>>>> +			address + (nr << PAGE_SHIFT) > vma->vm_end, vma);
> >>>>
> >>>> hi,
> >>>> I'm hitting this bug (console output below) with adding uprobe
> >>>> on simple program like:
> >>>>
> >>>>    $ cat up.c
> >>>>    int main(void)
> >>>>    {
> >>>>       return 0;
> >>>>    }
> >>>>
> >>>>    # bpftrace -e 'uprobe:/home/jolsa/up:_start {}'
> >>>>
> >>>>    $ ./up
> >>>>
> >>>> it's on top of current linus tree master:
> >>>>    052d534373b7 Merge tag 'exfat-for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat
> >>>>
> >>>> before this patch it seems to work, I can send my .config if needed
> >
> > Thanks for the bug report!
> 
> I just hit the same bug in our CI, but can't find the fix in -next. Is
> this in the queue somewhere?

we hit it as well, but I can see the fix in linux-next/master

  4c137bc28064 uprobes: use pagesize-aligned virtual address when replacing pages

jirka

Re: [PATCH v9 02/10] mm: Non-pmd-mappable, large folios for folio_add_new_anon_rmap()

[Ryan Roberts]

On 24/01/2024 11:19, Jiri Olsa wrote:
> On Wed, Jan 24, 2024 at 12:15:52PM +0100, Sven Schnelle wrote:
>> Ryan Roberts <ryan.roberts@arm.com> writes:
>>
>>> On 14/01/2024 20:55, Jiri Olsa wrote:
>>>> On Sun, Jan 14, 2024 at 06:33:56PM +0100, David Hildenbrand wrote:
>>>>> On 13.01.24 23:42, Jiri Olsa wrote:
>>>>>> On Thu, Dec 07, 2023 at 04:12:03PM +0000, Ryan Roberts wrote:
>>>>>>> In preparation for supporting anonymous multi-size THP, improve
>>>>>>> folio_add_new_anon_rmap() to allow a non-pmd-mappable, large folio to be
>>>>>>> passed to it. In this case, all contained pages are accounted using the
>>>>>>> order-0 folio (or base page) scheme.
>>>>>>>
>>>>>>> Reviewed-by: Yu Zhao <yuzhao@google.com>
>>>>>>> Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
>>>>>>> Reviewed-by: David Hildenbrand <david@redhat.com>
>>>>>>> Reviewed-by: Barry Song <v-songbaohua@oppo.com>
>>>>>>> Tested-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>>>>>>> Tested-by: John Hubbard <jhubbard@nvidia.com>
>>>>>>> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
>>>>>>> ---
>>>>>>>   mm/rmap.c | 28 ++++++++++++++++++++--------
>>>>>>>   1 file changed, 20 insertions(+), 8 deletions(-)
>>>>>>>
>>>>>>> diff --git a/mm/rmap.c b/mm/rmap.c
>>>>>>> index 2a1e45e6419f..846fc79f3ca9 100644
>>>>>>> --- a/mm/rmap.c
>>>>>>> +++ b/mm/rmap.c
>>>>>>> @@ -1335,32 +1335,44 @@ void page_add_anon_rmap(struct page *page, struct vm_area_struct *vma,
>>>>>>>    * This means the inc-and-test can be bypassed.
>>>>>>>    * The folio does not have to be locked.
>>>>>>>    *
>>>>>>> - * If the folio is large, it is accounted as a THP.  As the folio
>>>>>>> + * If the folio is pmd-mappable, it is accounted as a THP.  As the folio
>>>>>>>    * is new, it's assumed to be mapped exclusively by a single process.
>>>>>>>    */
>>>>>>>   void folio_add_new_anon_rmap(struct folio *folio, struct vm_area_struct *vma,
>>>>>>>   		unsigned long address)
>>>>>>>   {
>>>>>>> -	int nr;
>>>>>>> +	int nr = folio_nr_pages(folio);
>>>>>>> -	VM_BUG_ON_VMA(address < vma->vm_start || address >= vma->vm_end, vma);
>>>>>>> +	VM_BUG_ON_VMA(address < vma->vm_start ||
>>>>>>> +			address + (nr << PAGE_SHIFT) > vma->vm_end, vma);
>>>>>>
>>>>>> hi,
>>>>>> I'm hitting this bug (console output below) with adding uprobe
>>>>>> on simple program like:
>>>>>>
>>>>>>    $ cat up.c
>>>>>>    int main(void)
>>>>>>    {
>>>>>>       return 0;
>>>>>>    }
>>>>>>
>>>>>>    # bpftrace -e 'uprobe:/home/jolsa/up:_start {}'
>>>>>>
>>>>>>    $ ./up
>>>>>>
>>>>>> it's on top of current linus tree master:
>>>>>>    052d534373b7 Merge tag 'exfat-for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat
>>>>>>
>>>>>> before this patch it seems to work, I can send my .config if needed
>>>
>>> Thanks for the bug report!
>>
>> I just hit the same bug in our CI, but can't find the fix in -next. Is
>> this in the queue somewhere?
> 
> we hit it as well, but I can see the fix in linux-next/master
> 
>   4c137bc28064 uprobes: use pagesize-aligned virtual address when replacing pages

Yes that's the one. Just to confirm: you are still hitting the VM_BUG_ON despite
having this change in your kernel? Could you please send over the full bug log?

> 
> jirka

Re: [PATCH v9 02/10] mm: Non-pmd-mappable, large folios for folio_add_new_anon_rmap()

[Jiri Olsa]

On Wed, Jan 24, 2024 at 12:02:53PM +0000, Ryan Roberts wrote:
> On 24/01/2024 11:19, Jiri Olsa wrote:
> > On Wed, Jan 24, 2024 at 12:15:52PM +0100, Sven Schnelle wrote:
> >> Ryan Roberts <ryan.roberts@arm.com> writes:
> >>
> >>> On 14/01/2024 20:55, Jiri Olsa wrote:
> >>>> On Sun, Jan 14, 2024 at 06:33:56PM +0100, David Hildenbrand wrote:
> >>>>> On 13.01.24 23:42, Jiri Olsa wrote:
> >>>>>> On Thu, Dec 07, 2023 at 04:12:03PM +0000, Ryan Roberts wrote:
> >>>>>>> In preparation for supporting anonymous multi-size THP, improve
> >>>>>>> folio_add_new_anon_rmap() to allow a non-pmd-mappable, large folio to be
> >>>>>>> passed to it. In this case, all contained pages are accounted using the
> >>>>>>> order-0 folio (or base page) scheme.
> >>>>>>>
> >>>>>>> Reviewed-by: Yu Zhao <yuzhao@google.com>
> >>>>>>> Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
> >>>>>>> Reviewed-by: David Hildenbrand <david@redhat.com>
> >>>>>>> Reviewed-by: Barry Song <v-songbaohua@oppo.com>
> >>>>>>> Tested-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> >>>>>>> Tested-by: John Hubbard <jhubbard@nvidia.com>
> >>>>>>> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
> >>>>>>> ---
> >>>>>>>   mm/rmap.c | 28 ++++++++++++++++++++--------
> >>>>>>>   1 file changed, 20 insertions(+), 8 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/mm/rmap.c b/mm/rmap.c
> >>>>>>> index 2a1e45e6419f..846fc79f3ca9 100644
> >>>>>>> --- a/mm/rmap.c
> >>>>>>> +++ b/mm/rmap.c
> >>>>>>> @@ -1335,32 +1335,44 @@ void page_add_anon_rmap(struct page *page, struct vm_area_struct *vma,
> >>>>>>>    * This means the inc-and-test can be bypassed.
> >>>>>>>    * The folio does not have to be locked.
> >>>>>>>    *
> >>>>>>> - * If the folio is large, it is accounted as a THP.  As the folio
> >>>>>>> + * If the folio is pmd-mappable, it is accounted as a THP.  As the folio
> >>>>>>>    * is new, it's assumed to be mapped exclusively by a single process.
> >>>>>>>    */
> >>>>>>>   void folio_add_new_anon_rmap(struct folio *folio, struct vm_area_struct *vma,
> >>>>>>>   		unsigned long address)
> >>>>>>>   {
> >>>>>>> -	int nr;
> >>>>>>> +	int nr = folio_nr_pages(folio);
> >>>>>>> -	VM_BUG_ON_VMA(address < vma->vm_start || address >= vma->vm_end, vma);
> >>>>>>> +	VM_BUG_ON_VMA(address < vma->vm_start ||
> >>>>>>> +			address + (nr << PAGE_SHIFT) > vma->vm_end, vma);
> >>>>>>
> >>>>>> hi,
> >>>>>> I'm hitting this bug (console output below) with adding uprobe
> >>>>>> on simple program like:
> >>>>>>
> >>>>>>    $ cat up.c
> >>>>>>    int main(void)
> >>>>>>    {
> >>>>>>       return 0;
> >>>>>>    }
> >>>>>>
> >>>>>>    # bpftrace -e 'uprobe:/home/jolsa/up:_start {}'
> >>>>>>
> >>>>>>    $ ./up
> >>>>>>
> >>>>>> it's on top of current linus tree master:
> >>>>>>    052d534373b7 Merge tag 'exfat-for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat
> >>>>>>
> >>>>>> before this patch it seems to work, I can send my .config if needed
> >>>
> >>> Thanks for the bug report!
> >>
> >> I just hit the same bug in our CI, but can't find the fix in -next. Is
> >> this in the queue somewhere?
> > 
> > we hit it as well, but I can see the fix in linux-next/master
> > 
> >   4c137bc28064 uprobes: use pagesize-aligned virtual address when replacing pages
> 
> Yes that's the one. Just to confirm: you are still hitting the VM_BUG_ON despite
> having this change in your kernel? Could you please send over the full bug log?

ah sorry.. I meant the change fixes the problem for us, it just did not
yet propagate through the merge cycle into bpf trees.. but I can see it
in linux-next tree, so it's probably just matter of time

jirka

Re: [PATCH v9 02/10] mm: Non-pmd-mappable, large folios for folio_add_new_anon_rmap()

[Ryan Roberts]

On 24/01/2024 12:06, Jiri Olsa wrote:
> On Wed, Jan 24, 2024 at 12:02:53PM +0000, Ryan Roberts wrote:
>> On 24/01/2024 11:19, Jiri Olsa wrote:
>>> On Wed, Jan 24, 2024 at 12:15:52PM +0100, Sven Schnelle wrote:
>>>> Ryan Roberts <ryan.roberts@arm.com> writes:
>>>>
>>>>> On 14/01/2024 20:55, Jiri Olsa wrote:
>>>>>> On Sun, Jan 14, 2024 at 06:33:56PM +0100, David Hildenbrand wrote:
>>>>>>> On 13.01.24 23:42, Jiri Olsa wrote:
>>>>>>>> On Thu, Dec 07, 2023 at 04:12:03PM +0000, Ryan Roberts wrote:
>>>>>>>>> In preparation for supporting anonymous multi-size THP, improve
>>>>>>>>> folio_add_new_anon_rmap() to allow a non-pmd-mappable, large folio to be
>>>>>>>>> passed to it. In this case, all contained pages are accounted using the
>>>>>>>>> order-0 folio (or base page) scheme.
>>>>>>>>>
>>>>>>>>> Reviewed-by: Yu Zhao <yuzhao@google.com>
>>>>>>>>> Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
>>>>>>>>> Reviewed-by: David Hildenbrand <david@redhat.com>
>>>>>>>>> Reviewed-by: Barry Song <v-songbaohua@oppo.com>
>>>>>>>>> Tested-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>>>>>>>>> Tested-by: John Hubbard <jhubbard@nvidia.com>
>>>>>>>>> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
>>>>>>>>> ---
>>>>>>>>>   mm/rmap.c | 28 ++++++++++++++++++++--------
>>>>>>>>>   1 file changed, 20 insertions(+), 8 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/mm/rmap.c b/mm/rmap.c
>>>>>>>>> index 2a1e45e6419f..846fc79f3ca9 100644
>>>>>>>>> --- a/mm/rmap.c
>>>>>>>>> +++ b/mm/rmap.c
>>>>>>>>> @@ -1335,32 +1335,44 @@ void page_add_anon_rmap(struct page *page, struct vm_area_struct *vma,
>>>>>>>>>    * This means the inc-and-test can be bypassed.
>>>>>>>>>    * The folio does not have to be locked.
>>>>>>>>>    *
>>>>>>>>> - * If the folio is large, it is accounted as a THP.  As the folio
>>>>>>>>> + * If the folio is pmd-mappable, it is accounted as a THP.  As the folio
>>>>>>>>>    * is new, it's assumed to be mapped exclusively by a single process.
>>>>>>>>>    */
>>>>>>>>>   void folio_add_new_anon_rmap(struct folio *folio, struct vm_area_struct *vma,
>>>>>>>>>   		unsigned long address)
>>>>>>>>>   {
>>>>>>>>> -	int nr;
>>>>>>>>> +	int nr = folio_nr_pages(folio);
>>>>>>>>> -	VM_BUG_ON_VMA(address < vma->vm_start || address >= vma->vm_end, vma);
>>>>>>>>> +	VM_BUG_ON_VMA(address < vma->vm_start ||
>>>>>>>>> +			address + (nr << PAGE_SHIFT) > vma->vm_end, vma);
>>>>>>>>
>>>>>>>> hi,
>>>>>>>> I'm hitting this bug (console output below) with adding uprobe
>>>>>>>> on simple program like:
>>>>>>>>
>>>>>>>>    $ cat up.c
>>>>>>>>    int main(void)
>>>>>>>>    {
>>>>>>>>       return 0;
>>>>>>>>    }
>>>>>>>>
>>>>>>>>    # bpftrace -e 'uprobe:/home/jolsa/up:_start {}'
>>>>>>>>
>>>>>>>>    $ ./up
>>>>>>>>
>>>>>>>> it's on top of current linus tree master:
>>>>>>>>    052d534373b7 Merge tag 'exfat-for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat
>>>>>>>>
>>>>>>>> before this patch it seems to work, I can send my .config if needed
>>>>>
>>>>> Thanks for the bug report!
>>>>
>>>> I just hit the same bug in our CI, but can't find the fix in -next. Is
>>>> this in the queue somewhere?
>>>
>>> we hit it as well, but I can see the fix in linux-next/master
>>>
>>>   4c137bc28064 uprobes: use pagesize-aligned virtual address when replacing pages
>>
>> Yes that's the one. Just to confirm: you are still hitting the VM_BUG_ON despite
>> having this change in your kernel? Could you please send over the full bug log?
> 
> ah sorry.. I meant the change fixes the problem for us, it just did not
> yet propagate through the merge cycle into bpf trees.. but I can see it
> in linux-next tree, so it's probably just matter of time

OK great! How about you, Sven? Do you have this change in your kernel? Hopefully
it should fix your problem.

> 
> jirka

Re: [PATCH v9 02/10] mm: Non-pmd-mappable, large folios for folio_add_new_anon_rmap()

[Sven Schnelle]

Hi Ryan,

Ryan Roberts <ryan.roberts@arm.com> writes:

>>>>>>>>> I'm hitting this bug (console output below) with adding uprobe
>>>>>>>>> on simple program like:
>>>>>>>>>
>>>>>>>>>    $ cat up.c
>>>>>>>>>    int main(void)
>>>>>>>>>    {
>>>>>>>>>       return 0;
>>>>>>>>>    }
>>>>>>>>>
>>>>>>>>>    # bpftrace -e 'uprobe:/home/jolsa/up:_start {}'
>>>>>>>>>
>>>>>>>>>    $ ./up
>>>>>>>>>
>>>>>>>>> it's on top of current linus tree master:
>>>>>>>>>    052d534373b7 Merge tag 'exfat-for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat
>>>>>>>>>
>>>>>>>>> before this patch it seems to work, I can send my .config if needed
>>>>>>
>>>>>> Thanks for the bug report!
>>>>>
>>>>> I just hit the same bug in our CI, but can't find the fix in -next. Is
>>>>> this in the queue somewhere?
>>>>
>>>> we hit it as well, but I can see the fix in linux-next/master
>>>>
>>>>   4c137bc28064 uprobes: use pagesize-aligned virtual address when replacing pages
>>>
>>> Yes that's the one. Just to confirm: you are still hitting the VM_BUG_ON despite
>>> having this change in your kernel? Could you please send over the full bug log?
>> 
>> ah sorry.. I meant the change fixes the problem for us, it just did not
>> yet propagate through the merge cycle into bpf trees.. but I can see it
>> in linux-next tree, so it's probably just matter of time
>
> OK great! How about you, Sven? Do you have this change in your kernel? Hopefully
> it should fix your problem.

Same here - the fix makes uprobes work again, i just didn't see it in
torvalds-master and neither in todays linux-next. But Jiri is right,
it's in linux-next/master. I just missed to find it there. So everything
should be ok.

Re: [PATCH v9 02/10] mm: Non-pmd-mappable, large folios for folio_add_new_anon_rmap()

[Ryan Roberts]

On 24/01/2024 12:28, Sven Schnelle wrote:
> Hi Ryan,
> 
> Ryan Roberts <ryan.roberts@arm.com> writes:
> 
>>>>>>>>>> I'm hitting this bug (console output below) with adding uprobe
>>>>>>>>>> on simple program like:
>>>>>>>>>>
>>>>>>>>>>    $ cat up.c
>>>>>>>>>>    int main(void)
>>>>>>>>>>    {
>>>>>>>>>>       return 0;
>>>>>>>>>>    }
>>>>>>>>>>
>>>>>>>>>>    # bpftrace -e 'uprobe:/home/jolsa/up:_start {}'
>>>>>>>>>>
>>>>>>>>>>    $ ./up
>>>>>>>>>>
>>>>>>>>>> it's on top of current linus tree master:
>>>>>>>>>>    052d534373b7 Merge tag 'exfat-for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat
>>>>>>>>>>
>>>>>>>>>> before this patch it seems to work, I can send my .config if needed
>>>>>>>
>>>>>>> Thanks for the bug report!
>>>>>>
>>>>>> I just hit the same bug in our CI, but can't find the fix in -next. Is
>>>>>> this in the queue somewhere?
>>>>>
>>>>> we hit it as well, but I can see the fix in linux-next/master
>>>>>
>>>>>   4c137bc28064 uprobes: use pagesize-aligned virtual address when replacing pages
>>>>
>>>> Yes that's the one. Just to confirm: you are still hitting the VM_BUG_ON despite
>>>> having this change in your kernel? Could you please send over the full bug log?
>>>
>>> ah sorry.. I meant the change fixes the problem for us, it just did not
>>> yet propagate through the merge cycle into bpf trees.. but I can see it
>>> in linux-next tree, so it's probably just matter of time
>>
>> OK great! How about you, Sven? Do you have this change in your kernel? Hopefully
>> it should fix your problem.
> 
> Same here - the fix makes uprobes work again, i just didn't see it in
> torvalds-master and neither in todays linux-next. But Jiri is right,
> it's in linux-next/master. I just missed to find it there. So everything
> should be ok.

Great!