Fix build ID parsing logic in stable trees

hi,
sending fix for buildid parsing that affects only stable trees after merging upstream fix [1].

Upstream then factored out the whole buildid parsing code, so it does not have the problem.

Quoted 6 lines · Jiri Olsa

hi,
sending fix for buildid parsing that affects only stable trees after merging upstream fix [1].

Upstream then factored out the whole buildid parsing code, so it does not have the problem.

Why not just take those patches instead?

Quoted 9 lines · Greg KH

Quoted 6 lines · Jiri Olsa

hi,
sending fix for buildid parsing that affects only stable trees after merging upstream fix [1].

Upstream then factored out the whole buildid parsing code, so it does not have the problem.

Why not just take those patches instead?

I guess we could, but I thought it's too big for stable

we'd need following 2 changes to fix the issue:
de3ec364c3c3 lib/buildid: add single folio-based file reader abstraction 60c845b4896b lib/buildid: take into account e_phoff when fetching program headers

and there's also few other follow ups:
5ac9b4e935df lib/buildid: Handle memfd_secret() files in build_id_parse() cdbb44f9a74f lib/buildid: don't limit .note.gnu.build-id to the first page in ELF ad41251c290d lib/buildid: implement sleepable build_id_parse() API 45b8fc309654 lib/buildid: rename build_id_parse() into build_id_parse_nofault() 4e9d360c4cdf lib/buildid: remove single-page limit for PHDR search

which I guess are not strictly needed

Quoted 24 lines · Jiri Olsa

Quoted 9 lines · Greg KH

Quoted 6 lines · Jiri Olsa

hi,
sending fix for buildid parsing that affects only stable trees after merging upstream fix [1].

Upstream then factored out the whole buildid parsing code, so it does not have the problem.

Why not just take those patches instead?

I guess we could, but I thought it's too big for stable

we'd need following 2 changes to fix the issue:
de3ec364c3c3 lib/buildid: add single folio-based file reader abstraction 60c845b4896b lib/buildid: take into account e_phoff when fetching program headers

and there's also few other follow ups:
5ac9b4e935df lib/buildid: Handle memfd_secret() files in build_id_parse() cdbb44f9a74f lib/buildid: don't limit .note.gnu.build-id to the first page in ELF ad41251c290d lib/buildid: implement sleepable build_id_parse() API 45b8fc309654 lib/buildid: rename build_id_parse() into build_id_parse_nofault() 4e9d360c4cdf lib/buildid: remove single-page limit for PHDR search

Quoted 1 line

which I guess are not strictly needed

Can you verify what exact ones are needed here? We'll be glad to take them if you can verify that they work properly.

Quoted 25 lines · Greg KH

Quoted 24 lines · Jiri Olsa

Quoted 9 lines · Greg KH

Quoted 6 lines · Jiri Olsa

hi,
sending fix for buildid parsing that affects only stable trees after merging upstream fix [1].

Upstream then factored out the whole buildid parsing code, so it does not have the problem.

Why not just take those patches instead?

I guess we could, but I thought it's too big for stable

we'd need following 2 changes to fix the issue:
de3ec364c3c3 lib/buildid: add single folio-based file reader abstraction 60c845b4896b lib/buildid: take into account e_phoff when fetching program headers

and there's also few other follow ups:
5ac9b4e935df lib/buildid: Handle memfd_secret() files in build_id_parse() cdbb44f9a74f lib/buildid: don't limit .note.gnu.build-id to the first page in ELF ad41251c290d lib/buildid: implement sleepable build_id_parse() API 45b8fc309654 lib/buildid: rename build_id_parse() into build_id_parse_nofault() 4e9d360c4cdf lib/buildid: remove single-page limit for PHDR search

Quoted 4 lines

Quoted 1 line

which I guess are not strictly needed

Can you verify what exact ones are needed here? We'll be glad to take them if you can verify that they work properly.

ok, will check

Quoted 26 lines · Jiri Olsa

Quoted 25 lines · Greg KH

Quoted 24 lines · Jiri Olsa

Quoted 9 lines · Greg KH

Quoted 6 lines · Jiri Olsa

hi,
sending fix for buildid parsing that affects only stable trees after merging upstream fix [1].

Upstream then factored out the whole buildid parsing code, so it does not have the problem.

Why not just take those patches instead?

I guess we could, but I thought it's too big for stable

we'd need following 2 changes to fix the issue:
de3ec364c3c3 lib/buildid: add single folio-based file reader abstraction 60c845b4896b lib/buildid: take into account e_phoff when fetching program headers

and there's also few other follow ups:
5ac9b4e935df lib/buildid: Handle memfd_secret() files in build_id_parse() cdbb44f9a74f lib/buildid: don't limit .note.gnu.build-id to the first page in ELF ad41251c290d lib/buildid: implement sleepable build_id_parse() API 45b8fc309654 lib/buildid: rename build_id_parse() into build_id_parse_nofault() 4e9d360c4cdf lib/buildid: remove single-page limit for PHDR search

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

which I guess are not strictly needed

Can you verify what exact ones are needed here? We'll be glad to take them if you can verify that they work properly.

ok, will check

Hello,

I noticed that the BUILD-ID field in vmcoreinfo is broken on stable/longterm kernels and found this thread. Can we please get this fixed soon?

I tried cherry-picking the patches mentioned above ("lib/buildid: add single folio-based file reader abstraction" and "lib/buildid: take into account e_phoff when fetching program headers"), but they don't apply cleanly before 6.11, and they'd need to be reworked for 5.15, which was before folios were introduced. Jiri's minimal fix works for me and seems like a much safer option.

Tested-by Omar Sandoval <[email protected]>

Thanks,
Omar

Quoted 40 lines · Omar Sandoval

Quoted 26 lines · Jiri Olsa

Quoted 25 lines · Greg KH

Quoted 24 lines · Jiri Olsa

Quoted 9 lines · Greg KH

Quoted 6 lines · Jiri Olsa

hi,
sending fix for buildid parsing that affects only stable trees after merging upstream fix [1].

Upstream then factored out the whole buildid parsing code, so it does not have the problem.

Why not just take those patches instead?

I guess we could, but I thought it's too big for stable

we'd need following 2 changes to fix the issue:
de3ec364c3c3 lib/buildid: add single folio-based file reader abstraction 60c845b4896b lib/buildid: take into account e_phoff when fetching program headers

and there's also few other follow ups:
5ac9b4e935df lib/buildid: Handle memfd_secret() files in build_id_parse() cdbb44f9a74f lib/buildid: don't limit .note.gnu.build-id to the first page in ELF ad41251c290d lib/buildid: implement sleepable build_id_parse() API 45b8fc309654 lib/buildid: rename build_id_parse() into build_id_parse_nofault() 4e9d360c4cdf lib/buildid: remove single-page limit for PHDR search

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

which I guess are not strictly needed

Can you verify what exact ones are needed here? We'll be glad to take them if you can verify that they work properly.

ok, will check

Hello,

I noticed that the BUILD-ID field in vmcoreinfo is broken on stable/longterm kernels and found this thread. Can we please get this fixed soon?

Quoted 6 lines

I tried cherry-picking the patches mentioned above ("lib/buildid: add single folio-based file reader abstraction" and "lib/buildid: take into account e_phoff when fetching program headers"), but they don't apply cleanly before 6.11, and they'd need to be reworked for 5.15, which was before folios were introduced. Jiri's minimal fix works for me and seems like a much safer option.

hi,
thanks for testing

I think for 6.11 we could go with backport of:
de3ec364c3c3 lib/buildid: add single folio-based file reader abstraction 60c845b4896b lib/buildid: take into account e_phoff when fetching program headers

and with the small fix for the rest

but I still need to figure out why also 60c845b4896b is needed to fix the issue on 6.11.. hopefully today

Quoted 51 lines · Jiri Olsa

Quoted 40 lines · Omar Sandoval

Quoted 26 lines · Jiri Olsa

Quoted 25 lines · Greg KH

Quoted 24 lines · Jiri Olsa

Quoted 9 lines · Greg KH

Quoted 6 lines · Jiri Olsa

hi,
sending fix for buildid parsing that affects only stable trees after merging upstream fix [1].

Upstream then factored out the whole buildid parsing code, so it does not have the problem.

Why not just take those patches instead?

I guess we could, but I thought it's too big for stable

we'd need following 2 changes to fix the issue:
de3ec364c3c3 lib/buildid: add single folio-based file reader abstraction 60c845b4896b lib/buildid: take into account e_phoff when fetching program headers

and there's also few other follow ups:
5ac9b4e935df lib/buildid: Handle memfd_secret() files in build_id_parse() cdbb44f9a74f lib/buildid: don't limit .note.gnu.build-id to the first page in ELF ad41251c290d lib/buildid: implement sleepable build_id_parse() API 45b8fc309654 lib/buildid: rename build_id_parse() into build_id_parse_nofault() 4e9d360c4cdf lib/buildid: remove single-page limit for PHDR search

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

which I guess are not strictly needed

Can you verify what exact ones are needed here? We'll be glad to take them if you can verify that they work properly.

ok, will check

Hello,

I noticed that the BUILD-ID field in vmcoreinfo is broken on stable/longterm kernels and found this thread. Can we please get this fixed soon?

Quoted 6 lines

I tried cherry-picking the patches mentioned above ("lib/buildid: add single folio-based file reader abstraction" and "lib/buildid: take into account e_phoff when fetching program headers"), but they don't apply cleanly before 6.11, and they'd need to be reworked for 5.15, which was before folios were introduced. Jiri's minimal fix works for me and seems like a much safer option.

hi,
thanks for testing

Quoted 8 lines

I think for 6.11 we could go with backport of:
de3ec364c3c3 lib/buildid: add single folio-based file reader abstraction 60c845b4896b lib/buildid: take into account e_phoff when fetching program headers

and with the small fix for the rest

but I still need to figure out why also 60c845b4896b is needed to fix the issue on 6.11.. hopefully today

ok, so the fix the issue in 6.11 with upstream backports we'd need both:

1) de3ec364c3c3 lib/buildid: add single folio-based file reader abstraction
2) 60c845b4896b lib/buildid: take into account e_phoff when fetching program headers

2) is needed because 1) seems to omit ehdr->e_phoff addition (patch below) which is added back in 2)

IMO 6.11 is close to upstream and by taking above upstream fixes it will be easier to backport other possible fixes in the future, for other trees I'd take the original one line fix I posted

jirka

---

lib/buildid.c +2 -2

index bfe00b66b1e8..19d9a0f6ce99 100644
@@ -234,7 +234,7 @@ static int get_build_id_32(struct freader *r, unsigned char *build_id, __u32 *si
                return -EINVAL;
 
        for (i = 0; i < phnum; ++i) {
-               phdr = freader_fetch(r, i * sizeof(Elf32_Phdr), sizeof(Elf32_Phdr));
+               phdr = freader_fetch(r, sizeof(Elf32_Ehdr) + i * sizeof(Elf32_Phdr), sizeof(Elf32_Phdr));
                if (!phdr)
                        return r->err;
 

@@ -272,7 +272,7 @@ static int get_build_id_64(struct freader *r, unsigned char *build_id, __u32 *si
                return -EINVAL;
 
        for (i = 0; i < phnum; ++i) {
-               phdr = freader_fetch(r, i * sizeof(Elf64_Phdr), sizeof(Elf64_Phdr));
+               phdr = freader_fetch(r, sizeof(Elf64_Ehdr) + i * sizeof(Elf64_Phdr), sizeof(Elf64_Phdr));
                if (!phdr)
                        return r->err;
 

Quoted 67 lines · Jiri Olsa

Quoted 51 lines · Jiri Olsa

Quoted 40 lines · Omar Sandoval

Quoted 26 lines · Jiri Olsa

Quoted 25 lines · Greg KH

Quoted 24 lines · Jiri Olsa

Quoted 9 lines · Greg KH

Quoted 6 lines · Jiri Olsa

hi,
sending fix for buildid parsing that affects only stable trees after merging upstream fix [1].

Upstream then factored out the whole buildid parsing code, so it does not have the problem.

Why not just take those patches instead?

I guess we could, but I thought it's too big for stable

we'd need following 2 changes to fix the issue:
de3ec364c3c3 lib/buildid: add single folio-based file reader abstraction 60c845b4896b lib/buildid: take into account e_phoff when fetching program headers

and there's also few other follow ups:
5ac9b4e935df lib/buildid: Handle memfd_secret() files in build_id_parse() cdbb44f9a74f lib/buildid: don't limit .note.gnu.build-id to the first page in ELF ad41251c290d lib/buildid: implement sleepable build_id_parse() API 45b8fc309654 lib/buildid: rename build_id_parse() into build_id_parse_nofault() 4e9d360c4cdf lib/buildid: remove single-page limit for PHDR search

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

which I guess are not strictly needed

Can you verify what exact ones are needed here? We'll be glad to take them if you can verify that they work properly.

ok, will check

Hello,

I noticed that the BUILD-ID field in vmcoreinfo is broken on stable/longterm kernels and found this thread. Can we please get this fixed soon?

Quoted 6 lines

I tried cherry-picking the patches mentioned above ("lib/buildid: add single folio-based file reader abstraction" and "lib/buildid: take into account e_phoff when fetching program headers"), but they don't apply cleanly before 6.11, and they'd need to be reworked for 5.15, which was before folios were introduced. Jiri's minimal fix works for me and seems like a much safer option.

hi,
thanks for testing

Quoted 8 lines

I think for 6.11 we could go with backport of:
de3ec364c3c3 lib/buildid: add single folio-based file reader abstraction 60c845b4896b lib/buildid: take into account e_phoff when fetching program headers

and with the small fix for the rest

but I still need to figure out why also 60c845b4896b is needed to fix the issue on 6.11.. hopefully today

ok, so the fix the issue in 6.11 with upstream backports we'd need both:

1) de3ec364c3c3 lib/buildid: add single folio-based file reader abstraction
2) 60c845b4896b lib/buildid: take into account e_phoff when fetching program headers

Quoted 6 lines

2) is needed because 1) seems to omit ehdr->e_phoff addition (patch below) which is added back in 2)

IMO 6.11 is close to upstream and by taking above upstream fixes it will be easier to backport other possible fixes in the future, for other trees I'd take the original one line fix I posted

I still maintain that very minimal is the way to go instead of risking bringing new potential regressions by partially backporting folio rework patchset.

Jiri, there is no point in risking this, best to fix this quickly and minimally. If we ever need to backport further fixes, *then* we can think about folio-based implementation backport.

Quoted 28 lines

jirka

---

lib/buildid.c +2 -2

index bfe00b66b1e8..19d9a0f6ce99 100644
@@ -234,7 +234,7 @@ static int get_build_id_32(struct freader *r, unsigned char *build_id, __u32 *si
                return -EINVAL;
 
        for (i = 0; i < phnum; ++i) {
-               phdr = freader_fetch(r, i * sizeof(Elf32_Phdr), sizeof(Elf32_Phdr));
+               phdr = freader_fetch(r, sizeof(Elf32_Ehdr) + i * sizeof(Elf32_Phdr), sizeof(Elf32_Phdr));
                if (!phdr)
                        return r->err;
 

@@ -272,7 +272,7 @@ static int get_build_id_64(struct freader *r, unsigned char *build_id, __u32 *si
                return -EINVAL;
 
        for (i = 0; i < phnum; ++i) {
-               phdr = freader_fetch(r, i * sizeof(Elf64_Phdr), sizeof(Elf64_Phdr));
+               phdr = freader_fetch(r, sizeof(Elf64_Ehdr) + i * sizeof(Elf64_Phdr), sizeof(Elf64_Phdr));
                if (!phdr)
                        return r->err;
 

Quoted 79 lines · Andrii Nakryiko

Quoted 67 lines · Jiri Olsa

Quoted 51 lines · Jiri Olsa

Quoted 40 lines · Omar Sandoval

Quoted 26 lines · Jiri Olsa

Quoted 25 lines · Greg KH

Quoted 24 lines · Jiri Olsa

Quoted 9 lines · Greg KH

Quoted 6 lines · Jiri Olsa

hi,
sending fix for buildid parsing that affects only stable trees after merging upstream fix [1].

Upstream then factored out the whole buildid parsing code, so it does not have the problem.

Why not just take those patches instead?

I guess we could, but I thought it's too big for stable

we'd need following 2 changes to fix the issue:
de3ec364c3c3 lib/buildid: add single folio-based file reader abstraction 60c845b4896b lib/buildid: take into account e_phoff when fetching program headers

and there's also few other follow ups:
5ac9b4e935df lib/buildid: Handle memfd_secret() files in build_id_parse() cdbb44f9a74f lib/buildid: don't limit .note.gnu.build-id to the first page in ELF ad41251c290d lib/buildid: implement sleepable build_id_parse() API 45b8fc309654 lib/buildid: rename build_id_parse() into build_id_parse_nofault() 4e9d360c4cdf lib/buildid: remove single-page limit for PHDR search

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

which I guess are not strictly needed

Can you verify what exact ones are needed here? We'll be glad to take them if you can verify that they work properly.

ok, will check

Hello,

I noticed that the BUILD-ID field in vmcoreinfo is broken on stable/longterm kernels and found this thread. Can we please get this fixed soon?

Quoted 6 lines

I tried cherry-picking the patches mentioned above ("lib/buildid: add single folio-based file reader abstraction" and "lib/buildid: take into account e_phoff when fetching program headers"), but they don't apply cleanly before 6.11, and they'd need to be reworked for 5.15, which was before folios were introduced. Jiri's minimal fix works for me and seems like a much safer option.

hi,
thanks for testing

Quoted 8 lines

I think for 6.11 we could go with backport of:
de3ec364c3c3 lib/buildid: add single folio-based file reader abstraction 60c845b4896b lib/buildid: take into account e_phoff when fetching program headers

and with the small fix for the rest

but I still need to figure out why also 60c845b4896b is needed to fix the issue on 6.11.. hopefully today

ok, so the fix the issue in 6.11 with upstream backports we'd need both:

1) de3ec364c3c3 lib/buildid: add single folio-based file reader abstraction
2) 60c845b4896b lib/buildid: take into account e_phoff when fetching program headers

Quoted 6 lines

2) is needed because 1) seems to omit ehdr->e_phoff addition (patch below) which is added back in 2)

IMO 6.11 is close to upstream and by taking above upstream fixes it will be easier to backport other possible fixes in the future, for other trees I'd take the original one line fix I posted

I still maintain that very minimal is the way to go instead of risking bringing new potential regressions by partially backporting folio rework patchset.

Quoted 3 lines

Jiri, there is no point in risking this, best to fix this quickly and minimally. If we ever need to backport further fixes, *then* we can think about folio-based implementation backport.

ok, make sense, the original plan works for me as well

jirka

Quoted 84 lines · Jiri Olsa

Quoted 82 lines · Andrii Nakryiko

Quoted 67 lines · Jiri Olsa

Quoted 51 lines · Jiri Olsa

Quoted 40 lines · Omar Sandoval

Quoted 26 lines · Jiri Olsa

Quoted 25 lines · Greg KH

Quoted 24 lines · Jiri Olsa

Quoted 9 lines · Greg KH

Quoted 6 lines · Jiri Olsa

hi,
sending fix for buildid parsing that affects only stable trees after merging upstream fix [1].

Upstream then factored out the whole buildid parsing code, so it does not have the problem.

Why not just take those patches instead?

I guess we could, but I thought it's too big for stable

we'd need following 2 changes to fix the issue:
de3ec364c3c3 lib/buildid: add single folio-based file reader abstraction 60c845b4896b lib/buildid: take into account e_phoff when fetching program headers

and there's also few other follow ups:
5ac9b4e935df lib/buildid: Handle memfd_secret() files in build_id_parse() cdbb44f9a74f lib/buildid: don't limit .note.gnu.build-id to the first page in ELF ad41251c290d lib/buildid: implement sleepable build_id_parse() API 45b8fc309654 lib/buildid: rename build_id_parse() into build_id_parse_nofault() 4e9d360c4cdf lib/buildid: remove single-page limit for PHDR search

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

which I guess are not strictly needed

Can you verify what exact ones are needed here? We'll be glad to take them if you can verify that they work properly.

ok, will check

Hello,

I noticed that the BUILD-ID field in vmcoreinfo is broken on stable/longterm kernels and found this thread. Can we please get this fixed soon?

Quoted 6 lines

I tried cherry-picking the patches mentioned above ("lib/buildid: add single folio-based file reader abstraction" and "lib/buildid: take into account e_phoff when fetching program headers"), but they don't apply cleanly before 6.11, and they'd need to be reworked for 5.15, which was before folios were introduced. Jiri's minimal fix works for me and seems like a much safer option.

hi,
thanks for testing

Quoted 8 lines

I think for 6.11 we could go with backport of:
de3ec364c3c3 lib/buildid: add single folio-based file reader abstraction 60c845b4896b lib/buildid: take into account e_phoff when fetching program headers

and with the small fix for the rest

but I still need to figure out why also 60c845b4896b is needed to fix the issue on 6.11.. hopefully today

ok, so the fix the issue in 6.11 with upstream backports we'd need both:

1) de3ec364c3c3 lib/buildid: add single folio-based file reader abstraction
2) 60c845b4896b lib/buildid: take into account e_phoff when fetching program headers

Quoted 6 lines

2) is needed because 1) seems to omit ehdr->e_phoff addition (patch below) which is added back in 2)

IMO 6.11 is close to upstream and by taking above upstream fixes it will be easier to backport other possible fixes in the future, for other trees I'd take the original one line fix I posted

I still maintain that very minimal is the way to go instead of risking bringing new potential regressions by partially backporting folio rework patchset.

Jiri, there is no point in risking this, best to fix this quickly and minimally. If we ever need to backport further fixes, *then* we can think about folio-based implementation backport.

Quoted 3 lines

ok, make sense, the original plan works for me as well

jirka

Greg, could you please queue up Jiri's one line fixes for 5.15, 6.1, 6.6, and 6.11?

Quoted 23 lines

Quoted 23 lines

Quoted 13 lines

Quoted 6 lines

ok, so the fix the issue in 6.11 with upstream backports we'd need both:

1) de3ec364c3c3 lib/buildid: add single folio-based file reader abstraction
2) 60c845b4896b lib/buildid: take into account e_phoff when fetching program headers

Quoted 6 lines

2) is needed because 1) seems to omit ehdr->e_phoff addition (patch below) which is added back in 2)

IMO 6.11 is close to upstream and by taking above upstream fixes it will be easier to backport other possible fixes in the future, for other trees I'd take the original one line fix I posted

Quoted 7 lines

I still maintain that very minimal is the way to go instead of risking bringing new potential regressions by partially backporting folio rework patchset.

Jiri, there is no point in risking this, best to fix this quickly and minimally. If we ever need to backport further fixes, *then* we can think about folio-based implementation backport.

ok, make sense, the original plan works for me as well

Quoted 4 lines

Quoted 1 line

jirka

Greg, could you please queue up Jiri's one line fixes for 5.15, 6.1, 6.6, and 6.11?

Ok, will do, but hopefully you all will help out if there's any problems with the change going forward...

Quoted 26 lines · Jiri Olsa

Quoted 25 lines · Greg KH

Quoted 24 lines · Jiri Olsa

Quoted 9 lines · Greg KH

Quoted 6 lines · Jiri Olsa

hi,
sending fix for buildid parsing that affects only stable trees after merging upstream fix [1].

Upstream then factored out the whole buildid parsing code, so it does not have the problem.

Why not just take those patches instead?

I guess we could, but I thought it's too big for stable

we'd need following 2 changes to fix the issue:
de3ec364c3c3 lib/buildid: add single folio-based file reader abstraction 60c845b4896b lib/buildid: take into account e_phoff when fetching program headers

and there's also few other follow ups:
5ac9b4e935df lib/buildid: Handle memfd_secret() files in build_id_parse() cdbb44f9a74f lib/buildid: don't limit .note.gnu.build-id to the first page in ELF ad41251c290d lib/buildid: implement sleepable build_id_parse() API 45b8fc309654 lib/buildid: rename build_id_parse() into build_id_parse_nofault() 4e9d360c4cdf lib/buildid: remove single-page limit for PHDR search

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

which I guess are not strictly needed

Can you verify what exact ones are needed here? We'll be glad to take them if you can verify that they work properly.

ok, will check

Hello,

I noticed that the BUILD-ID field in vmcoreinfo is broken on stable/longterm kernels and found this thread. Can we please get this fixed soon?

I tried cherry-picking the patches mentioned above ("lib/buildid: add single folio-based file reader abstraction" and "lib/buildid: take into account e_phoff when fetching program headers"), but they don't apply cleanly before 6.11, and they'd need to be reworked for 5.15, which was before folios were introduced. Jiri's minimal fix works for me and seems like a much safer option.

Tested-by Omar Sandoval <[email protected]>

Thanks,
Omar