Messages in this thread | | | Subject | Re: [-next PATCH] security: use octal not symbolic permissions | From | Joe Perches <> | Date | Wed, 13 Jun 2018 12:30:17 -0700 |
| |
On Wed, 2018-06-13 at 12:19 -0400, Paul Moore wrote: > On Wed, Jun 13, 2018 at 12:04 PM, Joe Perches <joe@perches.com> wrote: > > On Wed, 2018-06-13 at 11:49 -0400, Paul Moore wrote: > > > On Tue, Jun 12, 2018 at 8:29 PM, Joe Perches <joe@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. > > > > No. History shows with high certainty that splitting > > patches like this across multiple subsystems of a primary > > subsystem means that the entire patchset is not completely > > applied. > > I think that is due more to a lack of effort on the part of the patch > author to keep pushing the individual patches.
Nope. Try again.
Resistance to change and desire for status quo occurs in many subsystems.
> > It's _much_ simpler and provides a generic mechanism to > > get the entire patch applied to send a single patch to the > > top level subsystem maintainer. > > I understand it is simpler for you, but it is more difficult for everyone else.
Not true.
It's simply a matter of merge resolution being pushed down where and when necessary.
See changes like the additions of the SPDX license tags.
> Further, where the LSMs are concerned, there is no "top level > subsystem maintainer" anymore. SELinux and AppArmor send pull > requests directly to Linus.
MAINTAINERS-SECURITY SUBSYSTEM MAINTAINERS-M: James Morris <jmorris@namei.org> MAINTAINERS-M: "Serge E. Hallyn" <serge@hallyn.com> MAINTAINERS-L: linux-security-module@vger.kernel.org (suggested Cc:) MAINTAINERS-T: git git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git MAINTAINERS-W: http://kernsec.org/ MAINTAINERS-S: Supported MAINTAINERS:F: security/ MAINTAINERS-
If James is not approving or merging security/selinux or security/tomoyo then perhaps the F: entries could be augmented with appropriate X: entries or made specific by using specific entries like:
F: security/* F: security/integrity/ F: security/keys/
| |