After receiving some feedback about the patches
I had sumbmitted yeasterday, I decided to go
back and resubmit them so they don't create
so much churn(just focus on typos).
security/selinux/avc.c | 6 +++---
security/selinux/hooks.c | 4 ++--
security/selinux/netlabel.c | 4 ++--
3 files changed, 7 insertions(+), 7 deletions(-)
Signed-off-by: Justin P. Mattock <[email protected]>
Fix some typos in some comments.
---
security/selinux/avc.c | 6 +++---
security/selinux/hooks.c | 4 ++--
security/selinux/netlabel.c | 4 ++--
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/security/selinux/avc.c b/security/selinux/avc.c
index b2ab608..6e15206 100644
--- a/security/selinux/avc.c
+++ b/security/selinux/avc.c
@@ -397,7 +397,7 @@ static inline struct avc_node *avc_search_node(u32 ssid, u32 tsid, u16 tclass)
* Look up an AVC entry that is valid for the
* (@ssid, @tsid), interpreting the permissions
* based on @tclass. If a valid AVC entry exists,
- * then this function return the avc_node.
+ * then this function returns the avc_node.
* Otherwise, this function returns NULL.
*/
static struct avc_node *avc_lookup(u32 ssid, u32 tsid, u16 tclass)
@@ -702,7 +702,7 @@ void avc_audit(u32 ssid, u32 tsid,
*
* Register a callback function for events in the set @events
* related to the SID pair (@ssid, @tsid) and
- * and the permissions @perms, interpreting
+ * the permissions @perms, interpreting
* @perms based on @tclass. Returns %0 on success or
* -%ENOMEM if insufficient memory exists to add the callback.
*/
@@ -745,7 +745,7 @@ static inline int avc_sidcmp(u32 x, u32 y)
* @seqno : sequence number when decision was made
*
* if a valid AVC entry doesn't exist,this function returns -ENOENT.
- * if kmalloc() called internal returns NULL, this function returns -ENOMEM.
+ * If kmalloc() is called internally and returns NULL, this function returns -ENOMEM.
* otherwise, this function update the AVC entry. The original AVC-entry object
* will release later by RCU.
*/
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 15c2a08..8640902 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -328,7 +328,7 @@ static void sk_free_security(struct sock *sk)
any labeling or access decisions can be provided. */
extern int ss_initialized;
-/* The file system's label must be initialized prior to use. */
+/* The filesystems label must be initialized prior to use. */
static char *labeling_behaviors[6] = {
"uses xattr",
@@ -2345,7 +2345,7 @@ static void selinux_bprm_committing_creds(struct linux_binprm *bprm)
* SID. If not, reset all soft limits to the lower of the current
* task's hard limit and the init task's soft limit.
*
- * Note that the setting of hard limits (even to lower them) can be
+ * Note: That the setting of hard limits (even to lower them) can be
* controlled by the setrlimit check. The inclusion of the init task's
* soft limit into the computation is to avoid resetting soft limits
* higher than the default soft limit for cases where the default is
diff --git a/security/selinux/netlabel.c b/security/selinux/netlabel.c
index 2e98441..c49b4fb 100644
--- a/security/selinux/netlabel.c
+++ b/security/selinux/netlabel.c
@@ -167,8 +167,8 @@ void selinux_netlbl_sk_security_reset(struct sk_security_struct *ssec)
*
* Description:
* Call the NetLabel mechanism to get the security attributes of the given
- * packet and use those attributes to determine the correct context/SID to
- * assign to the packet. Returns zero on success, negative values on failure.
+ * packet and use those attributes to determine the correct context/SID to be
+ * assigned to the packet. Returns zero on success, negative values on failure.
*
*/
int selinux_netlbl_skbuff_getsid(struct sk_buff *skb,
--
1.6.3.2
On Thu, 2 Jul 2009, Justin P. Mattock wrote:
> Signed-off-by: Justin P. Mattock <[email protected]>
>
> Fix some typos in some comments.
> -/* The file system's label must be initialized prior to use. */
> +/* The filesystems label must be initialized prior to use. */
Your adding grammertical error's.
> - * Note that the setting of hard limits (even to lower them) can be
> + * Note: That the setting of hard limits (even to lower them) can be
Please get this patch reviewed by an English speaker.
> * Description:
> * Call the NetLabel mechanism to get the security attributes of the given
> - * packet and use those attributes to determine the correct context/SID to
> - * assign to the packet. Returns zero on success, negative values on failure.
> + * packet and use those attributes to determine the correct context/SID to be
> + * assigned to the packet. Returns zero on success, negative values on failure.
Eschew the active voice?
- James
--
James Morris
<[email protected]>
James Morris wrote:
> On Thu, 2 Jul 2009, Justin P. Mattock wrote:
>
>
>> Signed-off-by: Justin P. Mattock<[email protected]>
>>
>> Fix some typos in some comments.
>>
>
>
>> -/* The file system's label must be initialized prior to use. */
>> +/* The filesystems label must be initialized prior to use. */
>>
>
> Your adding grammertical error's.
>
>
well, after figuring out how to have git send -email functioning correctly,
I needed something to send. : ^ )
(but after doing a quick google filesystem did show up).
>> - * Note that the setting of hard limits (even to lower them) can be
>> + * Note: That the setting of hard limits (even to lower them) can be
>>
>
> Please get this patch reviewed by an English speaker.
>
>
That seems viable to me.
>> * Description:
>> * Call the NetLabel mechanism to get the security attributes of the given
>> - * packet and use those attributes to determine the correct context/SID to
>> - * assign to the packet. Returns zero on success, negative values on failure.
>> + * packet and use those attributes to determine the correct context/SID to be
>> + * assigned to the packet. Returns zero on success, negative values on failure.
>>
>
> Eschew the active voice?
>
>
> - James
>
wast ist das?
No I will not be afraid of submitting patches, and having them be rejected.
all part of the learning curve.
Justin P. Mattock
On Thu, 2 Jul 2009, Justin P. Mattock wrote:
> No I will not be afraid of submitting patches, and having them be rejected.
> all part of the learning curve.
I'd suggest generally not starting out with spelling, grammatical and
formatting patches. It eats reviewer bandwidth, perturbs the codebase
(causing people working on it to have to update their code) and does not
give you as much opportunity to to learn about the code.
Try fixing smaller, known bugs or adding small useful changes.
The TODO list for the SELinux kernel code is here:
http://selinuxproject.org/page/Kernel_Development
You can also email the maintainers and ask for suggestions on what to
tackle.
- James
--
James Morris
<[email protected]>
James Morris wrote:
> On Thu, 2 Jul 2009, Justin P. Mattock wrote:
>
>
>> No I will not be afraid of submitting patches, and having them be rejected.
>> all part of the learning curve.
>>
>
> I'd suggest generally not starting out with spelling, grammatical and
> formatting patches. It eats reviewer bandwidth, perturbs the codebase
> (causing people working on it to have to update their code) and does not
> give you as much opportunity to to learn about the code.
>
>
No my intentions were not to eat reviewer bandwidth, or get in the way.
just turned out as I was going through(for example) hooks.c I noticed a
portion of it
had proper grammar, and then a portion of it seemed as if the author was too
much in a hurry to worry about that.(so I figured hey why not, that's all).
> Try fixing smaller, known bugs or adding small useful changes.
>
> The TODO list for the SELinux kernel code is here:
> http://selinuxproject.org/page/Kernel_Development
>
>
Thanks for this, Ill have to give this a look and see.
> You can also email the maintainers and ask for suggestions on what to
> tackle.
>
>
> - James
>
alright James,
Thanks for taking the time
next time I decide to have a major case of
OCD, I'll remember that creating churn is not
a good idea.
Justin P. Mattock