On Thu, Aug 8, 2024 at 2:34 AM Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
On 8/7/24 16:43, Paul Moore wrote:
On Wed, Aug 7, 2024 at 6:45 PM KP Singh <kpsingh@xxxxxxxxxx> wrote:
On Wed, Aug 7, 2024 at 10:45 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
On Tue, Aug 6, 2024 at 5:41 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
On Mon, Aug 5, 2024 at 10:20 PM Nathan Chancellor <nathan@xxxxxxxxxx> wrote:
...
For what it's worth, I have not noticed any issues in my -next testing
with this patch applied but I only build architectures that build with
LLVM due to the nature of my work. If exposure to more architectures is
desirable, perhaps Guenter Roeck would not mind testing it with his
matrix?
Thanks Nathan.
I think the additional testing would be great, KP can you please work
with Guenter to set this up?
Adding Guenter directly to this thread.
Is that something you can do KP? I'm asking because I'm looking at
merging some other patches into lsm/dev and I need to make a decision
about the static call patches (hold off on merging the other patches
until the static call testing is complete, or yank the static call
patches until testing is complete and then re-merge). Understanding
your ability to do the additional testing, and a rough idea of how
I have done the best of the testing I could do here. I think we should
let this run its normal course and see if this breaks anything. I am
not sure how testing is done before patches are merged and what else
you expect me to do?
That is why I was asking you to get in touch with Guenter to try and
sort out what needs to be done to test this across different
architectures.
With all due respect, this patchset has a history of not being as
tested as well as I would like; we had the compilation warning on gcc
and then the linux-next breakage. The gcc problem wasn't a major
problem (although it was disappointing, especially considering the
context around it), but I consider the linux-next breakage fairly
serious and would like to have some assurance beyond your "it's okay,
trust me" this time around. If there really is no way to practically
test this patchset across multiple arches prior to throwing it into
linux-next, so be it, but I want to see at least some effort towards
trying to make that happen.
Happy to run whatever patchset there is through my testbed. Just send me
a pointer to it.
Note that it should be based on mainline; linux-next is typically too broken
to provide any useful signals. I can handle a patchset either on top of v6.10
or v6.11-rc2 (meaning 6.10 passes through all my tests, and I can apply and
revert patches to/from 6.11-rc2 to get it to pass).
Question of course is if that really helps: I don't specifically test features
such as LSM or BPF.
The changes would not be specific to BPF LSM, we just want to check if
our init/main.c refactoring breaks some arch stuff.
I rebased my patches and pushed a branch based on v6.11-rc2:
https://git.kernel.org/pub/scm/linux/kernel/git/kpsingh/linux.git/log/?h=static_calls