All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <olsajiri@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org, bpf@vger.kernel.org,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>
Subject: Re: Fix build ID parsing logic in stable trees
Date: Tue, 5 Nov 2024 10:15:04 +0100	[thread overview]
Message-ID: <ZyniGMz5QLhGVWSY@krava> (raw)
In-Reply-To: <2024110536-agonizing-campus-21f0@gregkh>

On Tue, Nov 05, 2024 at 07:54:48AM +0100, Greg KH wrote:
> On Mon, Nov 04, 2024 at 06:52:52PM +0100, Jiri Olsa wrote:
> > 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

jirka

  reply	other threads:[~2024-11-05  9:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-04 17:52 Fix build ID parsing logic in stable trees Jiri Olsa
2024-11-04 17:52 ` [PATCH stable 5.15] lib/buildid: Fix build ID parsing logic Jiri Olsa
2024-11-04 17:52 ` [PATCH stable 6.1 ] " Jiri Olsa
2024-11-04 17:52 ` [PATCH stable 6.6 " Jiri Olsa
2024-11-04 17:52 ` [PATCH stable 6.11] " Jiri Olsa
2024-11-05  6:54 ` Fix build ID parsing logic in stable trees Greg KH
2024-11-05  9:15   ` Jiri Olsa [this message]
2024-11-06  6:12     ` Greg KH
2024-11-06 11:57       ` Jiri Olsa
2024-11-07 20:04         ` Omar Sandoval
2024-11-08  8:35           ` Jiri Olsa
2024-11-08 23:26             ` Jiri Olsa
2024-11-13 20:07               ` Andrii Nakryiko
2024-11-13 21:12                 ` Jiri Olsa
2024-11-15 18:19                   ` Omar Sandoval
2024-11-19 11:58                     ` Greg KH
2024-11-19 15:22                       ` Jiri Olsa
2024-11-08 17:55           ` Andrii Nakryiko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZyniGMz5QLhGVWSY@krava \
    --to=olsajiri@gmail.com \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.