Skip to contentSkip to conversation

staging: Replace kzalloc and memcpy by kmemdup

PATCH In review Dumbre, Nitesh Dilip (N.) 4 participants 5 messages May 20, 2015 – May 31, 2015 Staging

lore
Share & tools
lore

Dumbre, Nitesh Dilip (N.)

author
#0 lore raw

PATCH 1/1 staging: Replace kzalloc and memcpy by kmemdup

This patch was generated by coccicheck and replaces kzalloc followed by memcpy with kmemdup

Signed-off-by Nitesh Dumbre <[email protected]>
drivers/staging/lustre/lustre/obdclass/lprocfs_status.c +1 -2
index 57c6ddd..c988be4 100644
@@ -1711,13 +1711,12 @@ int lprocfs_exp_setup(struct obd_export *exp, lnet_nid_t *nid, int *newnid)
 		goto destroy_new;
 	}
 	/* not found - create */
-	buffer = kzalloc(LNET_NIDSTR_SIZE, GFP_NOFS);
+	buffer = kmemdup(libcfs_nid2str(*nid), LNET_NIDSTR_SIZE, GFP_NOFS);
 	if (buffer == NULL) {
 		rc = -ENOMEM;
 		goto destroy_new;
 	}
 
-	memcpy(buffer, libcfs_nid2str(*nid), LNET_NIDSTR_SIZE);
 	new_stat->nid_proc = lprocfs_register(buffer,
 					      obd->obd_proc_exports_entry,
 					      NULL, NULL);
Signature · 1 line
1.7.9.5
#1 lore raw

Thanks!
But rather than that, this whole function (lprocfs_exp_setup) needs to go, since it's not used by anything on the client. The removal is sitting in my queue of "stop using procfs in lustre" patches that I am going to submit real soon now and this patch would just create an unnecessary conflict.

Quoted 26 lines · Nitesh Dilip (N.)

This patch was generated by coccicheck and replaces kzalloc followed by memcpy with kmemdup

Signed-off-by Nitesh Dumbre <[email protected]>
drivers/staging/lustre/lustre/obdclass/lprocfs_status.c +1 -2
index 57c6ddd..c988be4 100644
@@ -1711,13 +1711,12 @@ int lprocfs_exp_setup(struct obd_export *exp, lnet_nid_t *nid, int *newnid)
 		goto destroy_new;
 	}
 	/* not found - create */
-	buffer = kzalloc(LNET_NIDSTR_SIZE, GFP_NOFS);
+	buffer = kmemdup(libcfs_nid2str(*nid), LNET_NIDSTR_SIZE, GFP_NOFS);
 	if (buffer == NULL) {
 		rc = -ENOMEM;
 		goto destroy_new;
 	}
 
-	memcpy(buffer, libcfs_nid2str(*nid), LNET_NIDSTR_SIZE);
 	new_stat->nid_proc = lprocfs_register(buffer,
 					      obd->obd_proc_exports_entry,
 					      NULL, NULL);
Signature · 1 line
1.7.9.5
#3 lore raw
Quoted 10 lines · On Sun, 2015-05-31 at 11:35 +0900, [email protected] wrote:
Quoted 4 lines · Nitesh Dilip (N.)

This patch was generated by coccicheck and replaces kzalloc followed by memcpy with kmemdup

Signed-off-by Nitesh Dumbre <[email protected]>

Name doesn't match the From: line, please fix your broken email client.

WHat is up with this company's email, there is a bunch of patches from different people, all of them broken like this.

Greg you are being a bit silly here.

The names match, but the company's email naming policy is not "first last" but "last, first".

People generally sign their names "first last".

Nothing is broken but your desire for exact name matching.

If this was an actual "From:" line in the body of the email, you'd be more likely correct that the names don't match, but this is not that case.

maintainer
#4 lore raw
Quoted 14 lines · Joe Perches
Quoted 10 lines · On Sun, 2015-05-31 at 11:35 +0900, [email protected] wrote:
Quoted 4 lines · Nitesh Dilip (N.)

This patch was generated by coccicheck and replaces kzalloc followed by memcpy with kmemdup

Signed-off-by Nitesh Dumbre <[email protected]>

Name doesn't match the From: line, please fix your broken email client.

WHat is up with this company's email, there is a bunch of patches from different people, all of them broken like this.

Greg you are being a bit silly here.

Quoted 7 lines

The names match, but the company's email naming
policy is not "first last" but "last, first".

People generally sign their names "first last".

Nothing is broken but your desire for exact name
matching.

There's also an odd "(H)." in the From line as well.

And yes, I do desire that as I know all about the tools we have that try to check these things (numbers of developers, etc.) and some of them don't like mismatched names.

Also, it's good for people to learn about "From:" in the body of the email, that's what it is there for :)

thanks,

greg k-h