[PATCH] buildid: validate page-backed file before parsing build ID

[PATCH] buildid: validate page-backed file before parsing build ID

[Jinchao Wang]

__build_id_parse() only works on page-backed storage.  Its helper paths
eventually call mapping->a_ops->read_folio(), so explicitly reject VMAs
that do not map a regular file or lack valid address_space operations.

Reported-by: syzbot+e008db2ac01e282550ee@syzkaller.appspotmail.com
Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>
---
 lib/buildid.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lib/buildid.c b/lib/buildid.c
index aaf61dfc0919..7131594cb071 100644
--- a/lib/buildid.c
+++ b/lib/buildid.c
@@ -280,7 +280,10 @@ static int __build_id_parse(struct vm_area_struct *vma, unsigned char *build_id,
 	int ret;
 
 	/* only works for page backed storage  */
-	if (!vma->vm_file)
+	if (!vma->vm_file ||
+	    !S_ISREG(file_inode(vma->vm_file)->i_mode) ||
+	    !vma->vm_file->f_mapping->a_ops ||
+	    !vma->vm_file->f_mapping->a_ops->read_folio)
 		return -EINVAL;
 
 	freader_init_from_file(&r, buf, sizeof(buf), vma->vm_file, may_fault);
-- 
2.43.0

Re: [PATCH] buildid: validate page-backed file before parsing build ID

[Andrew Morton]

On Tue, 23 Dec 2025 18:32:07 +0800 Jinchao Wang <wangjinchao600@gmail.com> wrote:

> __build_id_parse() only works on page-backed storage.  Its helper paths
> eventually call mapping->a_ops->read_folio(), so explicitly reject VMAs
> that do not map a regular file or lack valid address_space operations.
> 
> Reported-by: syzbot+e008db2ac01e282550ee@syzkaller.appspotmail.com
> Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>
>
> ...
>
> --- a/lib/buildid.c
> +++ b/lib/buildid.c
> @@ -280,7 +280,10 @@ static int __build_id_parse(struct vm_area_struct *vma, unsigned char *build_id,
>  	int ret;
>  
>  	/* only works for page backed storage  */
> -	if (!vma->vm_file)
> +	if (!vma->vm_file ||
> +	    !S_ISREG(file_inode(vma->vm_file)->i_mode) ||
> +	    !vma->vm_file->f_mapping->a_ops ||
> +	    !vma->vm_file->f_mapping->a_ops->read_folio)
>  		return -EINVAL;
>  
>  	freader_init_from_file(&r, buf, sizeof(buf), vma->vm_file, may_fault);

Thanks.  Seems this one needs additional paperwork.

I added the below:

Fixes: ad41251c290d ("lib/buildid: implement sleepable build_id_parse() API")
Tested-by: <syzbot+e008db2ac01e282550ee@syzkaller.appspotmail.com>
  Link: https://lkml.kernel.org/r/694a67ab.050a0220.19928e.001c.GAE@google.com
Closes: https://lkml.kernel.org/r/693540fe.a70a0220.38f243.004c.GAE@google.com
Cc: <stable@vger.kernel.org>

and a large number of cc's which I scraped together from various
emails.

Could people please eyeball all of this and verify that everything is
good?



From: Jinchao Wang <wangjinchao600@gmail.com>
Subject: buildid: validate page-backed file before parsing build ID
Date: Tue, 23 Dec 2025 18:32:07 +0800

__build_id_parse() only works on page-backed storage.  Its helper paths
eventually call mapping->a_ops->read_folio(), so explicitly reject VMAs
that do not map a regular file or lack valid address_space operations.

Link: https://lkml.kernel.org/r/20251223103214.2412446-1-wangjinchao600@gmail.com
Fixes: ad41251c290d ("lib/buildid: implement sleepable build_id_parse() API")
Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>
Reported-by: <syzbot+e008db2ac01e282550ee@syzkaller.appspotmail.com>
Tested-by: <syzbot+e008db2ac01e282550ee@syzkaller.appspotmail.com>
  Link: https://lkml.kernel.org/r/694a67ab.050a0220.19928e.001c.GAE@google.com
Closes: https://lkml.kernel.org/r/693540fe.a70a0220.38f243.004c.GAE@google.com
Cc: Axel Rasmussen <axelrasmussen@google.com>
Cc: David Hildenbrand (Red Hat) <david@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Qi Zheng <zhengqi.arch@bytedance.com>
Cc: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Wei Xu <weixugc@google.com>
Cc: Yuanchu Xie <yuanchu@google.com>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Eduard Zingerman <eddyz87@gmail.com>
Cc: Omar Sandoval <osandov@fb.com>
Cc: Deepanshu Kartikey <kartikey406@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkman <daniel@iogearbox.net>
Cc: Hao Luo <haoluo@google.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: John Fastabend <john.fastabend@gmail.com>
Cc: KP Singh <kpsingh@kernel.org>
Cc: Martin KaFai Lau <martin.lau@linux.dev>
Cc: Song Liu <song@kernel.org>
Cc: Stanislav Fomichev <sdf@fomichev.me>
Cc: Yonghong Song <yonghong.song@linux.dev>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 lib/buildid.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/lib/buildid.c~buildid-validate-page-backed-file-before-parsing-build-id
+++ a/lib/buildid.c
@@ -288,7 +288,10 @@ static int __build_id_parse(struct vm_ar
 	int ret;
 
 	/* only works for page backed storage  */
-	if (!vma->vm_file)
+	if (!vma->vm_file ||
+	    !S_ISREG(file_inode(vma->vm_file)->i_mode) ||
+	    !vma->vm_file->f_mapping->a_ops ||
+	    !vma->vm_file->f_mapping->a_ops->read_folio)
 		return -EINVAL;
 
 	freader_init_from_file(&r, buf, sizeof(buf), vma->vm_file, may_fault);
_

Re: [PATCH] buildid: validate page-backed file before parsing build ID

[Shakeel Butt]

Hi Jinchao,

On Tue, Dec 23, 2025 at 06:32:07PM +0800, Jinchao Wang wrote:
> __build_id_parse() only works on page-backed storage.  Its helper paths
> eventually call mapping->a_ops->read_folio(), so explicitly reject VMAs
> that do not map a regular file or lack valid address_space operations.
> 
> Reported-by: syzbot+e008db2ac01e282550ee@syzkaller.appspotmail.com
> Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>

Check the previous discussion on this at
https://lore.kernel.org/all/20251114193729.251892-1-ssranevjti@gmail.com/

The preferred solution was to use kernel_read() call instead of adding
more such checks. Please check and test the patch at
https://lore.kernel.org/20251222205859.3968077-1-shakeel.butt@linux.dev/

Re: [PATCH] buildid: validate page-backed file before parsing build ID

[Jinchao Wang]

On Tue, Dec 23, 2025 at 11:05:49AM -0800, Shakeel Butt wrote:
> Hi Jinchao,
> 
> On Tue, Dec 23, 2025 at 06:32:07PM +0800, Jinchao Wang wrote:
> > __build_id_parse() only works on page-backed storage.  Its helper paths
> > eventually call mapping->a_ops->read_folio(), so explicitly reject VMAs
> > that do not map a regular file or lack valid address_space operations.
> > 
> > Reported-by: syzbot+e008db2ac01e282550ee@syzkaller.appspotmail.com
> > Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>
> 
> Check the previous discussion on this at
> https://lore.kernel.org/all/20251114193729.251892-1-ssranevjti@gmail.com/
> 
> The preferred solution was to use kernel_read() call instead of adding
> more such checks. Please check and test the patch at
> https://lore.kernel.org/20251222205859.3968077-1-shakeel.butt@linux.dev/
> 

Thanks for the pointer.

After reading the discussion and the patch, I agree with you.
I also tested your patch, it fixes:
https://syzkaller.appspot.com/bug?extid=e008db2ac01e282550ee

Re: [PATCH] buildid: validate page-backed file before parsing build ID

[David Hildenbrand (Red Hat)]

On 12/23/25 18:29, Andrew Morton wrote:
> On Tue, 23 Dec 2025 18:32:07 +0800 Jinchao Wang <wangjinchao600@gmail.com> wrote:
> 
>> __build_id_parse() only works on page-backed storage.  Its helper paths
>> eventually call mapping->a_ops->read_folio(), so explicitly reject VMAs
>> that do not map a regular file or lack valid address_space operations.
>>
>> Reported-by: syzbot+e008db2ac01e282550ee@syzkaller.appspotmail.com
>> Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>
>>
>> ...
>>
>> --- a/lib/buildid.c
>> +++ b/lib/buildid.c
>> @@ -280,7 +280,10 @@ static int __build_id_parse(struct vm_area_struct *vma, unsigned char *build_id,
>>   	int ret;
>>   
>>   	/* only works for page backed storage  */
>> -	if (!vma->vm_file)
>> +	if (!vma->vm_file ||
>> +	    !S_ISREG(file_inode(vma->vm_file)->i_mode) ||
>> +	    !vma->vm_file->f_mapping->a_ops ||
>> +	    !vma->vm_file->f_mapping->a_ops->read_folio)
>>   		return -EINVAL;

Just wondering, we are fine with MAP_PRIVATE files, right? I guess it's 
not about the actual content in the VMA (which might be different for a 
MAP_PRIVATE VMA), but only about the content of the mapped file.


LGTM, although I wonder whether some of these these checks should be 
exposed as part of the read_cache_folio()/do_read_cache_folio() API.

Like, having a helper function that tells us whether we can use 
do_read_cache_folio() against a given mapping+file.

-- 
Cheers

David

Re: [PATCH] buildid: validate page-backed file before parsing build ID

[Andrii Nakryiko]

On Tue, Dec 30, 2025 at 2:11 PM David Hildenbrand (Red Hat)
<david@kernel.org> wrote:
>
> On 12/23/25 18:29, Andrew Morton wrote:
> > On Tue, 23 Dec 2025 18:32:07 +0800 Jinchao Wang <wangjinchao600@gmail.com> wrote:
> >
> >> __build_id_parse() only works on page-backed storage.  Its helper paths
> >> eventually call mapping->a_ops->read_folio(), so explicitly reject VMAs
> >> that do not map a regular file or lack valid address_space operations.
> >>
> >> Reported-by: syzbot+e008db2ac01e282550ee@syzkaller.appspotmail.com
> >> Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>
> >>
> >> ...
> >>
> >> --- a/lib/buildid.c
> >> +++ b/lib/buildid.c
> >> @@ -280,7 +280,10 @@ static int __build_id_parse(struct vm_area_struct *vma, unsigned char *build_id,
> >>      int ret;
> >>
> >>      /* only works for page backed storage  */
> >> -    if (!vma->vm_file)
> >> +    if (!vma->vm_file ||
> >> +        !S_ISREG(file_inode(vma->vm_file)->i_mode) ||
> >> +        !vma->vm_file->f_mapping->a_ops ||
> >> +        !vma->vm_file->f_mapping->a_ops->read_folio)
> >>              return -EINVAL;
>
> Just wondering, we are fine with MAP_PRIVATE files, right? I guess it's
> not about the actual content in the VMA (which might be different for a
> MAP_PRIVATE VMA), but only about the content of the mapped file.

Yep, this code is fetching contents of a file that backs given VMA.

>
>
> LGTM, although I wonder whether some of these these checks should be
> exposed as part of the read_cache_folio()/do_read_cache_folio() API.
>
> Like, having a helper function that tells us whether we can use
> do_read_cache_folio() against a given mapping+file.

I agree, this seems to be leaking a lot of internal mm details into
higher-level caller (__build_id_parse). Right now we try to fetch
folio with filemap_get_folio() and if that succeeds, then we do
read_cache_folio. Would it be possible for filemap_get_folio() to
return error if the folio cannot be read using read_cache_folio()? Or
maybe have a variant of filemap_get_folio() that would have this
semantic?

>
> --
> Cheers
>
> David

Re: [PATCH] buildid: validate page-backed file before parsing build ID

[David Hildenbrand (Red Hat)]

On 1/5/26 23:52, Andrii Nakryiko wrote:
> On Tue, Dec 30, 2025 at 2:11 PM David Hildenbrand (Red Hat)
> <david@kernel.org> wrote:
>>
>> On 12/23/25 18:29, Andrew Morton wrote:
>>> On Tue, 23 Dec 2025 18:32:07 +0800 Jinchao Wang <wangjinchao600@gmail.com> wrote:
>>>
>>>> __build_id_parse() only works on page-backed storage.  Its helper paths
>>>> eventually call mapping->a_ops->read_folio(), so explicitly reject VMAs
>>>> that do not map a regular file or lack valid address_space operations.
>>>>
>>>> Reported-by: syzbot+e008db2ac01e282550ee@syzkaller.appspotmail.com
>>>> Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>
>>>>
>>>> ...
>>>>
>>>> --- a/lib/buildid.c
>>>> +++ b/lib/buildid.c
>>>> @@ -280,7 +280,10 @@ static int __build_id_parse(struct vm_area_struct *vma, unsigned char *build_id,
>>>>       int ret;
>>>>
>>>>       /* only works for page backed storage  */
>>>> -    if (!vma->vm_file)
>>>> +    if (!vma->vm_file ||
>>>> +        !S_ISREG(file_inode(vma->vm_file)->i_mode) ||
>>>> +        !vma->vm_file->f_mapping->a_ops ||
>>>> +        !vma->vm_file->f_mapping->a_ops->read_folio)
>>>>               return -EINVAL;
>>
>> Just wondering, we are fine with MAP_PRIVATE files, right? I guess it's
>> not about the actual content in the VMA (which might be different for a
>> MAP_PRIVATE VMA), but only about the content of the mapped file.
> 
> Yep, this code is fetching contents of a file that backs given VMA.

Good!

> 
>>
>>
>> LGTM, although I wonder whether some of these these checks should be
>> exposed as part of the read_cache_folio()/do_read_cache_folio() API.
>>
>> Like, having a helper function that tells us whether we can use
>> do_read_cache_folio() against a given mapping+file.
> 
> I agree, this seems to be leaking a lot of internal mm details into
> higher-level caller (__build_id_parse). Right now we try to fetch
> folio with filemap_get_folio() and if that succeeds, then we do
> read_cache_folio. Would it be possible for filemap_get_folio() to
> return error if the folio cannot be read using read_cache_folio()? Or
> maybe have a variant of filemap_get_folio() that would have this
> semantic?

Good question. But really, for files that always have everything in the pagecache,
there would not be a problem, right? I'm thinking about hugetlb, for example.

There, we never expect to fallback to do_read_cache_folio().

So maybe we could just teach do_read_cache_folio() to fail properly?

diff --git a/mm/filemap.c b/mm/filemap.c
index ebd75684cb0a7..3f81b8481af4c 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -4051,8 +4051,11 @@ static struct folio *do_read_cache_folio(struct address_space *mapping,
         struct folio *folio;
         int err;
  
-       if (!filler)
+       if (!filler) {
+               if (!mapping->a_ops || !mapping->a_ops->read_folio)
+                       return ERR_PTR(-EINVAL);
                 filler = mapping->a_ops->read_folio;
+       }
  repeat:
         folio = filemap_get_folio(mapping, index);
         if (IS_ERR(folio)) {

Then __build_id_parse() would only check for the existence of vma->vm_file and maybe
the !S_ISREG(file_inode(vma->vm_file)->i_mode).


-- 
Cheers

David

Re: [PATCH] buildid: validate page-backed file before parsing build ID

[Andrii Nakryiko]

On Tue, Jan 6, 2026 at 11:16 AM David Hildenbrand (Red Hat)
<david@kernel.org> wrote:
>
> On 1/5/26 23:52, Andrii Nakryiko wrote:
> > On Tue, Dec 30, 2025 at 2:11 PM David Hildenbrand (Red Hat)
> > <david@kernel.org> wrote:
> >>
> >> On 12/23/25 18:29, Andrew Morton wrote:
> >>> On Tue, 23 Dec 2025 18:32:07 +0800 Jinchao Wang <wangjinchao600@gmail.com> wrote:
> >>>
> >>>> __build_id_parse() only works on page-backed storage.  Its helper paths
> >>>> eventually call mapping->a_ops->read_folio(), so explicitly reject VMAs
> >>>> that do not map a regular file or lack valid address_space operations.
> >>>>
> >>>> Reported-by: syzbot+e008db2ac01e282550ee@syzkaller.appspotmail.com
> >>>> Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>
> >>>>
> >>>> ...
> >>>>
> >>>> --- a/lib/buildid.c
> >>>> +++ b/lib/buildid.c
> >>>> @@ -280,7 +280,10 @@ static int __build_id_parse(struct vm_area_struct *vma, unsigned char *build_id,
> >>>>       int ret;
> >>>>
> >>>>       /* only works for page backed storage  */
> >>>> -    if (!vma->vm_file)
> >>>> +    if (!vma->vm_file ||
> >>>> +        !S_ISREG(file_inode(vma->vm_file)->i_mode) ||
> >>>> +        !vma->vm_file->f_mapping->a_ops ||
> >>>> +        !vma->vm_file->f_mapping->a_ops->read_folio)
> >>>>               return -EINVAL;
> >>
> >> Just wondering, we are fine with MAP_PRIVATE files, right? I guess it's
> >> not about the actual content in the VMA (which might be different for a
> >> MAP_PRIVATE VMA), but only about the content of the mapped file.
> >
> > Yep, this code is fetching contents of a file that backs given VMA.
>
> Good!
>
> >
> >>
> >>
> >> LGTM, although I wonder whether some of these these checks should be
> >> exposed as part of the read_cache_folio()/do_read_cache_folio() API.
> >>
> >> Like, having a helper function that tells us whether we can use
> >> do_read_cache_folio() against a given mapping+file.
> >
> > I agree, this seems to be leaking a lot of internal mm details into
> > higher-level caller (__build_id_parse). Right now we try to fetch
> > folio with filemap_get_folio() and if that succeeds, then we do
> > read_cache_folio. Would it be possible for filemap_get_folio() to
> > return error if the folio cannot be read using read_cache_folio()? Or
> > maybe have a variant of filemap_get_folio() that would have this
> > semantic?
>
> Good question. But really, for files that always have everything in the pagecache,
> there would not be a problem, right? I'm thinking about hugetlb, for example.
>
> There, we never expect to fallback to do_read_cache_folio().
>
> So maybe we could just teach do_read_cache_folio() to fail properly?
>
> diff --git a/mm/filemap.c b/mm/filemap.c
> index ebd75684cb0a7..3f81b8481af4c 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -4051,8 +4051,11 @@ static struct folio *do_read_cache_folio(struct address_space *mapping,
>          struct folio *folio;
>          int err;
>
> -       if (!filler)
> +       if (!filler) {
> +               if (!mapping->a_ops || !mapping->a_ops->read_folio)
> +                       return ERR_PTR(-EINVAL);
>                  filler = mapping->a_ops->read_folio;
> +       }
>   repeat:
>          folio = filemap_get_folio(mapping, index);
>          if (IS_ERR(folio)) {
>
> Then __build_id_parse() would only check for the existence of vma->vm_file and maybe
> the !S_ISREG(file_inode(vma->vm_file)->i_mode).
>

That would be great. But something like this was proposed earlier and
Matthew didn't particularly like this approach ([0]).

  [0] https://lore.kernel.org/all/aReUv1kVACh3UKv-@casper.infradead.org/

>
> --
> Cheers
>
> David

Re: [PATCH] buildid: validate page-backed file before parsing build ID

[David Hildenbrand (Red Hat)]

On 1/10/26 00:43, Andrii Nakryiko wrote:
> On Tue, Jan 6, 2026 at 11:16 AM David Hildenbrand (Red Hat)
> <david@kernel.org> wrote:
>>
>> On 1/5/26 23:52, Andrii Nakryiko wrote:
>>> On Tue, Dec 30, 2025 at 2:11 PM David Hildenbrand (Red Hat)
>>> <david@kernel.org> wrote:
>>>>
>>>> On 12/23/25 18:29, Andrew Morton wrote:
>>>>> On Tue, 23 Dec 2025 18:32:07 +0800 Jinchao Wang <wangjinchao600@gmail.com> wrote:
>>>>>
>>>>>> __build_id_parse() only works on page-backed storage.  Its helper paths
>>>>>> eventually call mapping->a_ops->read_folio(), so explicitly reject VMAs
>>>>>> that do not map a regular file or lack valid address_space operations.
>>>>>>
>>>>>> Reported-by: syzbot+e008db2ac01e282550ee@syzkaller.appspotmail.com
>>>>>> Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> --- a/lib/buildid.c
>>>>>> +++ b/lib/buildid.c
>>>>>> @@ -280,7 +280,10 @@ static int __build_id_parse(struct vm_area_struct *vma, unsigned char *build_id,
>>>>>>        int ret;
>>>>>>
>>>>>>        /* only works for page backed storage  */
>>>>>> -    if (!vma->vm_file)
>>>>>> +    if (!vma->vm_file ||
>>>>>> +        !S_ISREG(file_inode(vma->vm_file)->i_mode) ||
>>>>>> +        !vma->vm_file->f_mapping->a_ops ||
>>>>>> +        !vma->vm_file->f_mapping->a_ops->read_folio)
>>>>>>                return -EINVAL;
>>>>
>>>> Just wondering, we are fine with MAP_PRIVATE files, right? I guess it's
>>>> not about the actual content in the VMA (which might be different for a
>>>> MAP_PRIVATE VMA), but only about the content of the mapped file.
>>>
>>> Yep, this code is fetching contents of a file that backs given VMA.
>>
>> Good!
>>
>>>
>>>>
>>>>
>>>> LGTM, although I wonder whether some of these these checks should be
>>>> exposed as part of the read_cache_folio()/do_read_cache_folio() API.
>>>>
>>>> Like, having a helper function that tells us whether we can use
>>>> do_read_cache_folio() against a given mapping+file.
>>>
>>> I agree, this seems to be leaking a lot of internal mm details into
>>> higher-level caller (__build_id_parse). Right now we try to fetch
>>> folio with filemap_get_folio() and if that succeeds, then we do
>>> read_cache_folio. Would it be possible for filemap_get_folio() to
>>> return error if the folio cannot be read using read_cache_folio()? Or
>>> maybe have a variant of filemap_get_folio() that would have this
>>> semantic?
>>
>> Good question. But really, for files that always have everything in the pagecache,
>> there would not be a problem, right? I'm thinking about hugetlb, for example.
>>
>> There, we never expect to fallback to do_read_cache_folio().
>>
>> So maybe we could just teach do_read_cache_folio() to fail properly?
>>
>> diff --git a/mm/filemap.c b/mm/filemap.c
>> index ebd75684cb0a7..3f81b8481af4c 100644
>> --- a/mm/filemap.c
>> +++ b/mm/filemap.c
>> @@ -4051,8 +4051,11 @@ static struct folio *do_read_cache_folio(struct address_space *mapping,
>>           struct folio *folio;
>>           int err;
>>
>> -       if (!filler)
>> +       if (!filler) {
>> +               if (!mapping->a_ops || !mapping->a_ops->read_folio)
>> +                       return ERR_PTR(-EINVAL);
>>                   filler = mapping->a_ops->read_folio;
>> +       }
>>    repeat:
>>           folio = filemap_get_folio(mapping, index);
>>           if (IS_ERR(folio)) {
>>
>> Then __build_id_parse() would only check for the existence of vma->vm_file and maybe
>> the !S_ISREG(file_inode(vma->vm_file)->i_mode).
>>
> 
> That would be great. But something like this was proposed earlier and
> Matthew didn't particularly like this approach ([0]).
> 
>    [0] https://lore.kernel.org/all/aReUv1kVACh3UKv-@casper.infradead.org/

Well, but on the higher level we don't know whether we have to even call 
into read_cache_folio().

Again, hugetlb. Might be worth reproducing with hugetlb/shmem, and 
making sure it keeps working even with your changes.

-- 
Cheers

David