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 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.