Re: [PATCH 1/1] audit: Add new syscalls to the perm=w filter
On Mon, Oct 16, 2017 at 4:47 PM, Steve Grubb <sgrubb(a)redhat.com> wrote:
On Monday, October 16, 2017 3:15:03 PM EDT Paul Moore wrote:
> >> > The audit subsystem allows selecting audit events based on watches for
> >> > a particular behavior like writing to a file. A lot of syscalls have
> >> > been added without updating the list. This patch adds 2 syscalls to
the
> >> > write filters: fallocate and renameat2.
> >> >
> >> > Signed-off-by: sgrubb <sgrubb(a)redhat.com>
> >>
> >> Reviewed-by: Richard Guy Briggs <rgb(a)redhat.com>
> >
> > Please add a link to the issue number in the body of the patch
> > description:
> >
> > See: https://github.com/linux-audit/audit-kernel/issues/67
>
> FWIW, I don't really care if the upstream issue is included in the
> submitted patch; if you want to include it - great, if you don't -
> that's fine too. The commit description needs to stand on its own,
> regardless of any external issue trackers, mailing lists, etc.
I honestly don't know what the protocol is here. Should I resend the patch
with that or is that fixed up in the merge process? The reason I ask is on the
user space side I never make anyone resend a patch unless its grossly wrong or
incomplete. I just fix it. But that's what I do and not everyone works that
way.
It really depends on the situation, there is no strict rule to follow,
although if I'm expecting you to respin a patch I'll let you know. In
the comment above I said that I didn't care either way (about the GH
issue), that means you don't need to worry about it. I also said I'd
fixup your sign-off line when I apply the patch, there is no need to
respin, although you do need to fix that from this point on (future
new patches as well as any I ask you to respin).
In general, heavy editing by the maintainer is discouraged; exceptions
are made for merge fuzz, trivial fixes, agreed upon tweaks, etc.
There is also a bit of a human factor if we are truly honest, but I
try to minimize that as much as possible (am I in a good mood and
wiling to fix the code? has the contributor annoyed me lately?
etc.). At the end of the day, every maintainer is a bit different.
--
paul moore
www.paul-moore.com