[PATCH v3 00/14] audit: log all six syscall arguments in the SYSCALL record

Ricardo Robaina rrobaina at redhat.com
Wed Nov 4 05:42:46 PST 2026


On Tue, Nov 3, 2026 at 9:41 PM Paul Moore <paul at paul-moore.com> wrote:
>
> On Fri, Oct 23, 2026 at 8:45 AM Ricardo Robaina <rrobaina at redhat.com> wrote:
> > On Tue, Oct 20, 2026 at 1:39 PM Paul Moore <paul at paul-moore.com> wrote:
> > > On Tue, Oct 13, 2026 at 8:36 AM Ricardo Robaina <rrobaina at redhat.com> wrote:
> > > > On Thu, Oct 1, 2026 at 6:06 PM Paul Moore <paul at paul-moore.com> wrote:
> > > > > On Tue, Sep 22, 2026 at 3:21 PM Ricardo Robaina <rrobaina at redhat.com> wrote:
> > >
> > > ...
> > >
> > > > > * As pointed out by Sashiko, when you were converting all of the
> > > > > arches, it looks like you missed alpha.  I took a quick look and it
> > > > > appears that it should be a pretty straightforward conversion like
> > > > > most of the others.
> > > >
> > > > I've actually dropped the alpha patch as per Magnus's request [1].
> > > >
> > > > [1] https://lore.kernel.org/audit/CA+=Fv5T4826T2sd0Gbh-nfZsqcWK_phdBKy4BLWOvDTt92t5Eg@mail.gmail.com/
> > >
> > > The problem is that as things stand, this patchset breaks the build on
> > > Alpha.  Perhaps this gets resolved during the current merge window,
> > > but as you know we can't break the kernel build ...
> > >
> > > https://lore.kernel.org/oe-kbuild-all/202610041836.6TatRQSm-lkp@intel.com
> >
> > Of course, you're absolutely right that we can't break the build. I
> > was afraid that this dependency might cause trouble.
> >
> > I noticed Magnus posted a pull request a few days ago containing the
> > "alpha: enable GENERIC_ENTRY" series [1]. It seems this will get
> > resolved during the current merge window.
>
> ... and it has, or at least it appears to me to be resolved.  I
> rebased the audit/dev-staging branch against v7.4-rc1 and Alpha does
> indeed appear to be using the generic syscall entry/exit code in v7.4.
> I think we should be all set here wrt Alpha, thanks.

I'm happy to hear it.

>
> > For future reference, what's the best way to handle dependencies on
> > other subsystem changes like this?
>
> Generally speaking communication and coordination :)  Talk with the
> subsystem devs/maintainers to understand what they are doing, let them
> know what you want to do, and find the best way to order things so
> that it all lands in Linus' tree without making a mess.  In this
> particular case, with the syscall arg audit patchset not being ready
> (missing maintainer ACKs) and the Alpha changes going into v7.4 it
> turns out to be quite easy, which is an important lesson: sometimes it
> is better to defer a new feature for a release just to ease the
> coordination burden, enable better testing, etc.
>
> --
> paul-moore.com
>

Thanks, Paul!




More information about the linux-um mailing list