All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kurz <groug@kaod.org>
To: piaojun <piaojun@huawei.com>
Cc: Dominique Martinet <asmadeus@codewreck.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	<v9fs-developer@lists.sourceforge.net>
Subject: Re: [PATCH] net/9p/trans_virtio.c: add a terminal char for mount tag
Date: Wed, 1 Aug 2018 12:52:22 +0200	[thread overview]
Message-ID: <20180801125222.3ba39416@bahia.lan> (raw)
In-Reply-To: <5B616E3B.4050205@huawei.com>

On Wed, 1 Aug 2018 16:24:27 +0800
piaojun <piaojun@huawei.com> wrote:

> Hi Dominique,
> 
> On 2018/8/1 16:11, Dominique Martinet wrote:
> > piaojun wrote on Wed, Aug 01, 2018:  
> >> chan->tag has no terminal char at last which will result in printing messy
> >> code when debugging code. So we should add '\0' for tag.  
> > 
> > 9p is full of non null-terminated string so I'm not sure how I feel
> > about it, is there anything wrong with how this is used or was this just
> > when you tried to printf it?  
> 

The mount tag isn't a 9P thingy actually. It is provided by the server
in the device config space, and it is never used in any 9P message.
It could have been a nul terminated string from the beginning. Not
sure why people opted to store it that way.

> There is nothing wrong at the places using tag, as they calculated the
> tag_len carefully. Adding '\0' for it will make the code more robust. And
> I'm glad to hear others' opinions.
> 

So this patch basically turns chan->tag into a nul terminated string,
which is indeed more convenient and robust. Maybe you can update the
rest of the code accordingly and drop chan->tag_len then ?

> Thanks,
> Jun
> 
> > 
> > If it's just for debugging I'd suggest using the printf format "%.*s"
> > with "chan->tag_len, chan->tag" arguments,

FWIW, 9P strings received from the client are also converted to
nul terminated strings:

static int
p9pdu_vreadf(struct p9_fcall *pdu, int proto_version, const char *fmt,
	va_list ap)
{
[...]
		case 's':{
[...]
				*sptr = kmalloc(len + 1, GFP_NOFS);
[...]
					(*sptr)[len] = 0;
			}


Cheers,

--
Greg

> > 
> > 
> > That said it's not like this is costly, so I'll take it if someone else
> > thinks this is helpful
> >   
> >>
> >> Signed-off-by: Jun Piao <piaojun@huawei.com>
> >> ---
> >>  net/9p/trans_virtio.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
> >> index d422bfc..49d71d6 100644
> >> --- a/net/9p/trans_virtio.c
> >> +++ b/net/9p/trans_virtio.c
> >> @@ -585,7 +585,7 @@ static int p9_virtio_probe(struct virtio_device *vdev)
> >>  		err = -EINVAL;
> >>  		goto out_free_vq;
> >>  	}
> >> -	tag = kmalloc(tag_len, GFP_KERNEL);
> >> +	tag = kzalloc(tag_len + 1, GFP_KERNEL);
> >>  	if (!tag) {
> >>  		err = -ENOMEM;
> >>  		goto out_free_vq;
> >> --   


  reply	other threads:[~2018-08-01 11:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-01  7:44 [PATCH] net/9p/trans_virtio.c: add a terminal char for mount tag piaojun
2018-08-01  8:11 ` Dominique Martinet
2018-08-01  8:24   ` piaojun
2018-08-01 10:52     ` Greg Kurz [this message]
2018-08-01 12:09       ` Dominique Martinet
2018-08-02  1:18         ` piaojun

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=20180801125222.3ba39416@bahia.lan \
    --to=groug@kaod.org \
    --cc=akpm@linux-foundation.org \
    --cc=asmadeus@codewreck.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=piaojun@huawei.com \
    --cc=v9fs-developer@lists.sourceforge.net \
    /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.