On Fri, Nov 22, 2019 at 8:04 AM Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > On 11/22/19 5:40 AM, Ondrej Mosnacek wrote: > > When trying this on RHEL-7, I realized there is a missing kernel > > version check here (module_load kernel support was introduced in v4.7 > > [1]): > > > > ifneq ($(shell ./kvercmp $$(uname -r) 4.7),-1) > > ... > > endif > > > > It is quite a corner case to have a policy that supports module_load > > and a kernel that does not, but there is at least one distro that hits > > it, so I think it's worth it to add the explicit check. > > > > Stephen/Paul, is it trivial enough to add when merging the patch or > > should Richard repost it? > > > > [1] https://github.com/torvalds/linux/commit/61d612ea731e57dc510472fb746b55cdc017f371 > > Alternatively, you could exclude it on RHEL7 by adding it to the > filter-out line under ifeq ($(DISTRO),RHEL7). Regardless, it is > entirely up to you as to whether you want to fix it up on merge yourself > or request a re-spin. Yes, each project and maintainer handle this differently. I personally try to have the original submitter make the change(s) whenever possible (assuming they are not merge related); I do this for a few reasons: 1) it is their name on the code, and I don't want to cause them problems by others mistaking my changes for the submitters changes (aside, this is why I try to mark my edits in the commit metadata) 2) changes made during the merge don't go through the normal mailing list review 3) the mailing list feedback loop is a Very Good Thing in my opinion and we should do what we can to keep it going. That said, there are cases where the change is mindlessly trivial (e.g. misspellings, nonconformant whitespace, etc.) and I don't have a problem making that edit. I'll also consider making larger changes if I know the original submitter to be unreliable and we want/need to get the commit into the tree soon. -- paul moore www.paul-moore.com
