On 10/21/2015 01:23 PM, Paul Moore wrote: > On Sunday, October 18, 2015 12:50:45 PM Scott Matheina wrote: >> On 10/14/2015 04:54 PM, Paul Moore wrote: >>> On Saturday, October 10, 2015 08:57:55 PM Scott Matheina wrote: >>>> Signed-off-by: Scott Matheina <sc...@matheina.com> >>>> --- >>>> >>>> kernel/auditfilter.c | 17 ++++++++++------- >>>> 1 file changed, 10 insertions(+), 7 deletions(-) >>> Sorry for the delay in reviewing this, comments inline ... >>> >>>> diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c >>>> index 7714d93..774f9ad 100644 >>>> --- a/kernel/auditfilter.c >>>> +++ b/kernel/auditfilter.c >>>> @@ -39,13 +39,13 @@ >>>> >>>> * Locking model: >>>> * >>>> >>>> * audit_filter_mutex: >>>> - * Synchronizes writes and blocking reads of audit's >>>> filterlist >>>> - * data. Rcu is used to traverse the filterlist and access >>>> - * contents of structs audit_entry, audit_watch and opaque >>>> - * LSM rules during filtering. If modified, these >>>> structures >>>> - * must be copied and replace their counterparts in the >>>> filterlist. >>>> - * An audit_parent struct is not accessed during >>>> filtering, so may >>>> - * be written directly provided audit_filter_mutex is held. >>>> + * Synchronizes writes and blocking reads of audit's >>>> filterlist >>>> + * data. Rcu is used to traverse the filterlist and access >>>> + * contents of structs audit_entry, audit_watch and opaque >>>> + * LSM rules during filtering. If modified, these >>>> structures >>>> + * must be copied and replace their counterparts in the >>>> filterlist. >>>> + * An audit_parent struct is not accessed during >>>> filtering, so may >>>> + * be written directly provided audit_filter_mutex is held. >>>> >>>> */ >>> Okay, that's fine. > ... > >> As you might have guessed, this is one of my first patches. I wasn't sure if >> a patch like this would even get reviewed, and responded to. I'm subscribed >> to the linux-kernel mail group, and seeing what is acceptable. >> >> Thanks for the review. I don't plan on making a habit of submitting such >> incredibly trivial patches, but you have to start somewhere, and I thought >> it'd be hard to screw up by fixing a couple of trivial style errors. > We all start somewhere, and with that in mind, if you want to resubmit this > patch with only the fix above (fixing the whitespace in the comment block), > I'll apply it. While the patch is trivial, it is does fix a minor nit with > near-zero risk. > > I would encourage you to try something a bit more substantial next time, as > they say, bug fixes are the quickest way to a maintainer's heart. > Thanks for the feedback. I'll resubmit. Now I get to figure out how to resubmit a patch with changes, so a good learning experience for me. Pure Hobbyist at this time, but I love to learn.
Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
