From: Latchesar Ionkov <lucho@ionkov.net>
To: Russ Cox <rsc@swtch.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org,
v9fs-developer@lists.sourceforge.net
Subject: Re: [V9fs-developer] [PATCH 3/3] v9fs: zero copy implementation
Date: Thu, 5 Jan 2006 21:05:59 -0500 [thread overview]
Message-ID: <20060106020559.GA13804@ionkov.net> (raw)
In-Reply-To: <ee9e417a0601050713k3c778142k430c5329bbd8e841@mail.gmail.com>
On Thu, Jan 05, 2006 at 10:13:52AM -0500, Russ Cox said:
> > +char *v9fs_str_copy(char *buf, int buflen, struct v9fs_str *str)
> > +{
> > + int n;
> > +
> > + if (buflen < str->len)
> > + n = buflen;
> > + else
> > + n = str->len;
> > +
> > + memmove(buf, str->str, n - 1);
> > +
> > + return buf;
> > +}
>
>
> The above is wrong. You'll chop the end of the string off
> when str->len <= buflen.
You are right.
>
> n = str->len;
> if (n > buflen-1)
> n = buflen-1;
> memmove(buf, str->str, n);
> buf[n] = 0;
>
> > +int v9fs_str_compare(char *buf, struct v9fs_str *str)
> > +{
> > + int n, ret;
> > +
> > + ret = strncmp(buf, str->str, str->len);
> > +
> > + if (!ret) {
> > + n = strlen(buf);
> > + if (n < str->len)
> > + ret = -1;
> > + else if (n > str->len)
> > + ret = 1;
> > + }
> > +
> > + return ret;
> > +}
>
> You go through all this work to avoid copying the strings,
> which has questionable benefit, and then this routine
> walks the length of the string twice, unnecessarily.
> Also if strlen(buf) < str->len, then strncmp can't return 0.
I avoid copying the strings not because of the copy itself, but to not
bother freeing them when v9fs_fcall structure is freed. You are right, the
logic is wrong. I was trying (obviously unsuccessfully) to match strcmp
semantics, although I only use the function to check for equality of the
strings.
>
> ret = strncmp(buf, str->str, str->len);
> if (!ret && buf[str->len])
> ret = 1;
> return ret;
>
> > static inline int buf_check_size(struct cbuf *buf, int len)
> > {
> [snip deleted lines]
> > + if (buf->p + len > buf->ep && buf->p < buf->ep) {
> > + eprintk(KERN_ERR, "buffer overflow: want %d has %d\n",
> > + len, (int)(buf->ep - buf->p));
> > + dump_stack();
> > + buf->p = buf->ep + 1;
> > + return 0;
> > }
> >
> > return 1;
>
> I think it's weird that you return 1 when you've already overflowed.
> It's fine that you don't print more than once, but what's the harm
> in returning 0 always when buf->p + len > buf->ep?
It is not just weird, it is wrong and can lead to writing outside of the
buffer.
Thanks for reviewing the code.
Lucho
prev parent reply other threads:[~2006-01-06 2:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-05 0:57 [PATCH 3/3] v9fs: zero copy implementation Latchesar Ionkov
2006-01-05 1:18 ` Andrew Morton
2006-01-05 13:02 ` Pekka Enberg
2006-01-05 15:13 ` [V9fs-developer] " Russ Cox
2006-01-06 2:05 ` Latchesar Ionkov [this message]
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=20060106020559.GA13804@ionkov.net \
--to=lucho@ionkov.net \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rsc@swtch.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox