From: Jiri Olsa <olsajiri@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Omar Sandoval <osandov@osandov.com>,
stable@vger.kernel.org, Jiri Olsa <olsajiri@gmail.com>,
Andrii Nakryiko <andrii.nakryiko@gmail.com>,
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, 19 Nov 2024 16:22:58 +0100 [thread overview]
Message-ID: <ZzytUhGqbCMZtS7T@krava> (raw)
In-Reply-To: <2024111955-excursion-diaper-2675@gregkh>
On Tue, Nov 19, 2024 at 12:58:21PM +0100, Greg KH wrote:
SNIP
> > > > >
> > > > > 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
> > > >
> > > > 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
> > >
> > > 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...
no worries, will help with that
thanks,
jirka
next prev parent reply other threads:[~2024-11-19 15:23 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
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 [this message]
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=ZzytUhGqbCMZtS7T@krava \
--to=olsajiri@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=gregkh@linuxfoundation.org \
--cc=osandov@osandov.com \
--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.