Received-SPF: pass (google.com: domain of linux-kernel+bounces-36837-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
From: Sven Schnelle <svens@linux.ibm.com>
To: Ryan Roberts <ryan.roberts@arm.com>
Cc: Jiri Olsa <olsajiri@gmail.com>, David Hildenbrand <david@redhat.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Matthew Wilcox
 <willy@infradead.org>,
        Yin Fengwei <fengwei.yin@intel.com>, Yu Zhao
 <yuzhao@google.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Anshuman
 Khandual <anshuman.khandual@arm.com>,
        Yang Shi <shy828301@gmail.com>, "Huang, Ying" <ying.huang@intel.com>,
        Zi Yan <ziy@nvidia.com>, Luis
 Chamberlain <mcgrof@kernel.org>,
        Itaru Kitayama
 <itaru.kitayama@gmail.com>,
        "Kirill A. Shutemov"
 <kirill.shutemov@linux.intel.com>,
        John Hubbard <jhubbard@nvidia.com>,
        David Rientjes <rientjes@google.com>, Vlastimil Babka <vbabka@suse.cz>,
        Hugh Dickins <hughd@google.com>,
        Kefeng Wang
 <wangkefeng.wang@huawei.com>,
        Barry Song <21cnbao@gmail.com>, Alistair
 Popple <apopple@nvidia.com>,
        linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org,
        linux-kernel@vger.kernel.org, Barry Song <v-songbaohua@oppo.com>,
        linux-s390@vger.kernel.org
Subject: Re: [PATCH v9 02/10] mm: Non-pmd-mappable, large folios for
 folio_add_new_anon_rmap()
In-Reply-To: <1188e67e-5c04-4bb5-b242-78d92c3fc85c@arm.com> (Ryan Roberts's
	message of "Mon, 15 Jan 2024 08:50:19 +0000")
References: <20231207161211.2374093-1-ryan.roberts@arm.com>
	<20231207161211.2374093-3-ryan.roberts@arm.com>
	<ZaMR2EWN-HvlCfUl@krava>
	<41dc7dff-1ea8-4894-a487-88d46ec2b2d8@redhat.com>
	<ZaRKMwKJIBmh8-lD@krava>
	<1188e67e-5c04-4bb5-b242-78d92c3fc85c@arm.com>
Date: Wed, 24 Jan 2024 12:15:52 +0100
Message-ID: <yt9d1qa7x9qv.fsf@linux.ibm.com>
User-Agent: Gnus/5.13 (Gnus v5.13)
Content-Type: text/plain
Precedence: bulk
MIME-Version: 1.0

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