[-next PATCH] security: use octal not symbolic permissions
Paul Moore
paul at paul-moore.com
Wed Jun 13 15:49:33 UTC 2018
On Tue, Jun 12, 2018 at 8:29 PM, Joe Perches <joe at perches.com> wrote:
> On Tue, 2018-06-12 at 17:12 -0400, Paul Moore wrote:
>> Joe, in general I really appreciate the fixes you send, but these
>> patches that cross a lot of subsystem boundaries (this isn't the first
>> one that does this) causes unnecessary conflicts in -next and during
>> the merge window. Could you split your patches up from now on please?
>
> Sorry. No. Merge conflicts are inherent in this system.
Yes, merge conflicts are inherent in this system when one makes a
single change which impacts multiple subsystems, e.g. changing a core
kernel function which is called by multiple subsystems. However, that
isn't what this patch does, it makes a number of self-contained
changes across multiple subsystems; there are no cross-subsystem
dependencies in this patch. You are increasing the likelihood of
conflicts for no good reason; that is why I'm asking you to split this
patch and others like it.
> There is just no good way to do this as sending a set
> of per subsystem patches guarantees partial application
> of the entire set.
Please explain why all of these changes need to be made at the same
time? Looking quickly at the patch it would appear that each chunk of
the patch could be applied independently and the kernel would still
build and operate correctly. I'm not suggesting that you decompose
this patch with that level of granularity, that would be silly, but
splitting this patch (and many of the others you tend to submit) at
subsystem boundaries should be possible.
Further, as one could see from the responses of the other LSM
maintainers, splitting this patch is not just possible, it is
desirable.
> If you prefer, each sub-subsystem maintainer, at
> whatever granularity desired, could apply the patch
> to the appropriate subsystem by using
> "git am --include=<subsystem_path>".
Or you could split the patch up by subsystem before posting, like so
many other developers do already.
--
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
More information about the Linux-security-module-archive
mailing list