From: Mirsad Todorovac <mtodorovac69@gmail.com>
To: NeilBrown <neilb@suse.de>
Cc: linux-nfs@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
Chuck Lever <chuck.lever@oracle.com>,
Jeff Layton <jlayton@kernel.org>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
Trond Myklebust <trondmy@kernel.org>,
Anna Schumaker <anna@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
Subject: Re: [PATCH v1 1/1] SUNRPC: Make enough room in servername[] for AF_UNIX addresses
Date: Tue, 24 Sep 2024 07:38:21 +0200 [thread overview]
Message-ID: <b4435709-e112-4667-b458-411856a28389@gmail.com> (raw)
In-Reply-To: <172712665050.17050.14126694149839508223@noble.neil.brown.name>
Hi, Neil,
Apparently I was duplicating work.
However, using
char servername[UNIX_PATH_MAX];
has some advantages when compared to hard-coded integer?
Correct me if I'm wrong.
Best regards,
Mirsad Todorovac
On 9/23/24 23:24, NeilBrown wrote:
> On Tue, 24 Sep 2024, Mirsad Todorovac wrote:
>> GCC 13.2.0 reported with W=1 build option the following warning:
>
> See
> https://lore.kernel.org/all/20240814093853.48657-1-kunwu.chan@linux.dev/
>
> I don't think anyone really cares about this one.
>
> NeilBrown
>
>
>>
>> net/sunrpc/clnt.c: In function ‘rpc_create’:
>> net/sunrpc/clnt.c:582:75: warning: ‘%s’ directive output may be truncated writing up to 107 bytes into \
>> a region of size 48 [-Wformat-truncation=]
>> 582 | snprintf(servername, sizeof(servername), "%s",
>> | ^~
>> net/sunrpc/clnt.c:582:33: note: ‘snprintf’ output between 1 and 108 bytes into a destination of size 48
>> 582 | snprintf(servername, sizeof(servername), "%s",
>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> 583 | sun->sun_path);
>> | ~~~~~~~~~~~~~~
>>
>> 548 };
>> → 549 char servername[48];
>> 550 struct rpc_clnt *clnt;
>> 551 int i;
>> 552
>> 553 if (args->bc_xprt) {
>> 554 WARN_ON_ONCE(!(args->protocol & XPRT_TRANSPORT_BC));
>> 555 xprt = args->bc_xprt->xpt_bc_xprt;
>> 556 if (xprt) {
>> 557 xprt_get(xprt);
>> 558 return rpc_create_xprt(args, xprt);
>> 559 }
>> 560 }
>> 561
>> 562 if (args->flags & RPC_CLNT_CREATE_INFINITE_SLOTS)
>> 563 xprtargs.flags |= XPRT_CREATE_INFINITE_SLOTS;
>> 564 if (args->flags & RPC_CLNT_CREATE_NO_IDLE_TIMEOUT)
>> 565 xprtargs.flags |= XPRT_CREATE_NO_IDLE_TIMEOUT;
>> 566 /*
>> 567 * If the caller chooses not to specify a hostname, whip
>> 568 * up a string representation of the passed-in address.
>> 569 */
>> 570 if (xprtargs.servername == NULL) {
>> 571 struct sockaddr_un *sun =
>> 572 (struct sockaddr_un *)args->address;
>> 573 struct sockaddr_in *sin =
>> 574 (struct sockaddr_in *)args->address;
>> 575 struct sockaddr_in6 *sin6 =
>> 576 (struct sockaddr_in6 *)args->address;
>> 577
>> 578 servername[0] = '\0';
>> 579 switch (args->address->sa_family) {
>> → 580 case AF_LOCAL:
>> → 581 if (sun->sun_path[0])
>> → 582 snprintf(servername, sizeof(servername), "%s",
>> → 583 sun->sun_path);
>> → 584 else
>> → 585 snprintf(servername, sizeof(servername), "@%s",
>> → 586 sun->sun_path+1);
>> → 587 break;
>> 588 case AF_INET:
>> 589 snprintf(servername, sizeof(servername), "%pI4",
>> 590 &sin->sin_addr.s_addr);
>> 591 break;
>> 592 case AF_INET6:
>> 593 snprintf(servername, sizeof(servername), "%pI6",
>> 594 &sin6->sin6_addr);
>> 595 break;
>> 596 default:
>> 597 /* caller wants default server name, but
>> 598 * address family isn't recognized. */
>> 599 return ERR_PTR(-EINVAL);
>> 600 }
>> 601 xprtargs.servername = servername;
>> 602 }
>> 603
>> 604 xprt = xprt_create_transport(&xprtargs);
>> 605 if (IS_ERR(xprt))
>> 606 return (struct rpc_clnt *)xprt;
>>
>> After the address family AF_LOCAL was added in the commit 176e21ee2ec89, the old hard-coded
>> size for servername of char servername[48] no longer fits. The maximum AF_UNIX address size
>> has now grown to UNIX_PATH_MAX defined as 108 in "include/uapi/linux/un.h" .
>>
>> The lines 580-587 were added later, addressing the leading zero byte '\0', but did not fix
>> the hard-coded servername limit.
>>
>> The AF_UNIX address was truncated to 47 bytes + terminating null byte. This patch will fix the
>> servername in AF_UNIX family to the maximum permitted by the system:
>>
>> 548 };
>> → 549 char servername[UNIX_PATH_MAX];
>> 550 struct rpc_clnt *clnt;
>>
>> Fixes: 4388ce05fa38b ("SUNRPC: support abstract unix socket addresses")
>> Fixes: 510deb0d7035d ("SUNRPC: rpc_create() default hostname should support AF_INET6 addresses")
>> Fixes: 176e21ee2ec89 ("SUNRPC: Support for RPC over AF_LOCAL transports")
>> Cc: Neil Brown <neilb@suse.de>
>> Cc: Chuck Lever <chuck.lever@oracle.com>
>> Cc: Trond Myklebust <trondmy@kernel.org>
>> Cc: Anna Schumaker <anna@kernel.org>
>> Cc: Jeff Layton <jlayton@kernel.org>
>> Cc: Olga Kornievskaia <okorniev@redhat.com>
>> Cc: Dai Ngo <Dai.Ngo@oracle.com>
>> Cc: Tom Talpey <tom@talpey.com>
>> Cc: "David S. Miller" <davem@davemloft.net>
>> Cc: Eric Dumazet <edumazet@google.com>
>> Cc: Jakub Kicinski <kuba@kernel.org>
>> Cc: Paolo Abeni <pabeni@redhat.com>
>> Cc: linux-nfs@vger.kernel.org
>> Cc: netdev@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Mirsad Todorovac <mtodorovac69@gmail.com>
>> ---
>> v1:
>> initial version.
>>
>> net/sunrpc/clnt.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
>> index 09f29a95f2bc..67099719893e 100644
>> --- a/net/sunrpc/clnt.c
>> +++ b/net/sunrpc/clnt.c
>> @@ -546,7 +546,7 @@ struct rpc_clnt *rpc_create(struct rpc_create_args *args)
>> .connect_timeout = args->connect_timeout,
>> .reconnect_timeout = args->reconnect_timeout,
>> };
>> - char servername[48];
>> + char servername[UNIX_PATH_MAX];
>> struct rpc_clnt *clnt;
>> int i;
>>
>> --
>> 2.43.0
>>
>>
>
next prev parent reply other threads:[~2024-09-24 5:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-23 20:55 [PATCH v1 1/1] SUNRPC: Make enough room in servername[] for AF_UNIX addresses Mirsad Todorovac
2024-09-23 21:24 ` NeilBrown
2024-09-24 5:38 ` Mirsad Todorovac [this message]
2024-09-24 10:43 ` NeilBrown
2024-09-25 17:51 ` Mirsad Todorovac
2024-09-25 21:42 ` NeilBrown
2024-09-26 19:58 ` Mirsad Todorovac
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=b4435709-e112-4667-b458-411856a28389@gmail.com \
--to=mtodorovac69@gmail.com \
--cc=Dai.Ngo@oracle.com \
--cc=anna@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jlayton@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=netdev@vger.kernel.org \
--cc=okorniev@redhat.com \
--cc=pabeni@redhat.com \
--cc=tom@talpey.com \
--cc=trondmy@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.