linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
	linux-kernel@vger.kernel.org
Cc: linux-nfs@vger.kernel.org, kernel-janitors@vger.kernel.org,
	linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH 2/2] SUNRPC: Optimize 'svc_print_xprts()'
Date: Thu, 26 Mar 2020 09:53:19 +1100	[thread overview]
Message-ID: <87wo786o80.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <42afbf1f-19e1-a05c-e70c-1d46eaba3a71@wanadoo.fr>

[-- Attachment #1: Type: text/plain, Size: 3715 bytes --]

On Wed, Mar 25 2020, Christophe JAILLET wrote:

> Le 25/03/2020 à 15:52, Chuck Lever a écrit :
>> Hi Christophe,
>>
>>
>>> On Mar 25, 2020, at 3:04 AM, Christophe JAILLET <christophe.jaillet@wanadoo.fr> wrote:
>>>
>>> Using 'snprintf' is safer than 'sprintf' because it can avoid a buffer
>>> overflow.
>> That's true as a general statement, but how likely is such an
>> overflow to occur here?
>>
> I guess, that it us unlikely and that the 80 chars buffer is big enough.
> That is the exact reason of why I've proposed 2 patches. The first one 
> could happen in RL. The 2nd is more like a clean-up and is less 
> relevant, IMHO.
>>
>>> The return value can also be used to avoid a strlen a call.
>> That's also true of sprintf, isn't it?
>
> Sure.
>
>
>>
>>> Finally, we know where we need to copy and the length to copy, so, we
>>> can save a few cycles by rearraging the code and using a memcpy instead of
>>> a strcat.
>> I would be OK with squashing these two patches together. I don't
>> see the need to keep the two changes separated.
>
> NP, I can resend as a V2 with your comments.
> As said above, the first fixes something that could, IMHO, happen and 
> the 2nd is more a matter of taste and a clean-up.
>
>
>>
>>> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>>> ---
>>> This patch should have no functionnal change.
>>> We could go further, use scnprintf and write directly in the destination
>>> buffer. However, this could lead to a truncated last line.
>> That's exactly what this function is trying to avoid. As part of any
>> change in this area, it would be good to replace the current block
>> comment before this function with a Doxygen-format comment that
>> documents that goal.
>
> I'll take care of it.
>
>
>>> ---
>>> net/sunrpc/svc_xprt.c | 8 ++++----
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
>>> index df39e7b8b06c..6df861650040 100644
>>> --- a/net/sunrpc/svc_xprt.c
>>> +++ b/net/sunrpc/svc_xprt.c
>>> @@ -118,12 +118,12 @@ int svc_print_xprts(char *buf, int maxlen)
>>> 	list_for_each_entry(xcl, &svc_xprt_class_list, xcl_list) {
>>> 		int slen;
>>>
>>> -		sprintf(tmpstr, "%s %d\n", xcl->xcl_name, xcl->xcl_max_payload);
>>> -		slen = strlen(tmpstr);
>>> -		if (len + slen >= maxlen)
>>> +		slen = snprintf(tmpstr, sizeof(tmpstr), "%s %d\n",
>>> +				xcl->xcl_name, xcl->xcl_max_payload);
>>> +		if (slen >= sizeof(tmpstr) || len + slen >= maxlen)
>>> 			break;
>>> +		memcpy(buf + len, tmpstr, slen + 1);
>>> 		len += slen;
>>> -		strcat(buf, tmpstr);
>> IMO replacing the strcat makes the code harder to read, and this
>> is certainly not a performance path. Can you drop that part of the
>> patch?
>
> Ok
>
>
>>
>>> 	}
>>> 	spin_unlock(&svc_xprt_class_lock);
>>>
>>> -- 

Can I suggest something more like this:

diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
index de3c077733a7..0292f45b70f6 100644
--- a/net/sunrpc/svc_xprt.c
+++ b/net/sunrpc/svc_xprt.c
@@ -115,16 +115,9 @@ int svc_print_xprts(char *buf, int maxlen)
 	buf[0] = '\0';
 
 	spin_lock(&svc_xprt_class_lock);
-	list_for_each_entry(xcl, &svc_xprt_class_list, xcl_list) {
-		int slen;
-
-		sprintf(tmpstr, "%s %d\n", xcl->xcl_name, xcl->xcl_max_payload);
-		slen = strlen(tmpstr);
-		if (len + slen > maxlen)
-			break;
-		len += slen;
-		strcat(buf, tmpstr);
-	}
+	list_for_each_entry(xcl, &svc_xprt_class_list, xcl_list)
+		len += scnprintf(buf + len, maxlen - len, "%s %d\n",
+				 xcl->xcl_name, xcl->xcl_max_payload);
 	spin_unlock(&svc_xprt_class_lock);
 
 	return len;

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  parent reply	other threads:[~2020-03-25 22:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-25  7:04 [PATCH 2/2] SUNRPC: Optimize 'svc_print_xprts()' Christophe JAILLET
2020-03-25 14:52 ` Chuck Lever
     [not found]   ` <42afbf1f-19e1-a05c-e70c-1d46eaba3a71@wanadoo.fr>
2020-03-25 22:53     ` NeilBrown [this message]
     [not found]       ` <2e2d1293-c978-3f1d-5a1e-dc43dc2ad06b@wanadoo.fr>
2020-03-26 21:44         ` NeilBrown
2020-03-26 22:29           ` Chuck Lever

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wo786o80.fsf@notabene.neil.brown.name \
    --to=neilb@suse.de \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).