Re: pull-request: bpf-next 2022-03-21

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Mar 21, 2022 at 4:59 PM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Mon, Mar 21, 2022 at 4:11 PM Alexei Starovoitov
> <alexei.starovoitov@xxxxxxxxx> wrote:
> >
> > Did you look at the code?
> > In particular:
> > https://lore.kernel.org/bpf/164735286243.1084943.7477055110527046644.stgit@devnote2/
> >
> > it's a copy paste of arch/x86/kernel/kprobes/core.c
> >
> > How is it "bad architecture code" ?
>
> It's "bad architecture code" because the architecture maintainers have
> made changes to check ENDBR in the meantime.
>
> So it used to be perfectly fine. It's not any longer - and the
> architecture maintainers were clearly never actually cc'd on the
> changes, so they didn't find out until much too late.

Not denying that missing cc was an issue.

We can drop just arch patches:
      rethook: x86: Add rethook x86 implementation
      arm64: rethook: Add arm64 rethook implementation
      powerpc: Add rethook support
      ARM: rethook: Add rethook arm implementation

or everything including Jiri's work on top of it.
Which would be a massive 27 patches.

We'd prefer the former, of course.
Later during the merge window we can add a single
'rethook: x86' patch that takes endbr into account,
so that multi-kprobe feature will work on x86.
For the next merge window we can add other archs.
Would that work?



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux