[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YxguwCpBEKAJJDU6@kroah.com>
Date: Wed, 7 Sep 2022 07:40:16 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: linux-kernel@...r.kernel.org, stable@...r.kernel.org,
Jiri Olsa <jolsa@...nel.org>,
Andrii Nakryiko <andrii@...nel.org>
Subject: Re: [PATCH 5.15 101/107] kbuild: Unify options for BTF generation
for vmlinux and modules
On Tue, Sep 06, 2022 at 11:45:00AM -0700, Florian Fainelli wrote:
>
>
> On 9/6/2022 6:31 AM, Greg Kroah-Hartman wrote:
> > From: Jiri Olsa <jolsa@...hat.com>
> >
> > commit e27f05147bff21408c1b8410ad8e90cd286e7952 upstream.
> >
> > Using new PAHOLE_FLAGS variable to pass extra arguments to
> > pahole for both vmlinux and modules BTF data generation.
> >
> > Adding new scripts/pahole-flags.sh script that detect and
> > prints pahole options.
> >
> > [ fixed issues found by kernel test robot ]
> >
> > Signed-off-by: Jiri Olsa <jolsa@...nel.org>
> > Signed-off-by: Andrii Nakryiko <andrii@...nel.org>
> > Acked-by: Andrii Nakryiko <andrii@...nel.org>
> > Link: https://lore.kernel.org/bpf/20211029125729.70002-1-jolsa@kernel.org
> > Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > ---
> > Makefile | 3 +++
> > scripts/Makefile.modfinal | 2 +-
> > scripts/link-vmlinux.sh | 11 +----------
> > scripts/pahole-flags.sh | 20 ++++++++++++++++++++
> > 4 files changed, 25 insertions(+), 11 deletions(-)
> > create mode 100755 scripts/pahole-flags.sh
>
> My linux-stable-rc/linux-5.15.y checkout shows that scripts/pahole-flags.sh
> does not have an executable permission and commit
> 128e3cc0beffc92154d9af6bd8c107f46e830000 ("kbuild: Unify options for BTF
> generation for vmlinux and modules") does have:
>
> diff --git a/scripts/pahole-flags.sh b/scripts/pahole-flags.sh
> new file mode 100644
> index 000000000000..e6093adf4c06
>
> whereas your email does have the proper 100755 permission set on the file,
> any idea what happened here?
Yeah, quilt does not like dealing with file permissions at all :(
We have over time, not required executable permissions on kernel files
because of this issue. Is it required here? If so, I'll try to
remember to fix it up "by hand".
thanks,
greg k-h
Powered by blists - more mailing lists