From: Tom Zanussi <tzanussi@gmail.com>
To: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
Cc: penberg@cs.helsinki.fi, akpm@linux-foundation.org,
compudj@krystal.dyndns.org, linux-kernel@vger.kernel.org,
righi.andrea@gmail.com
Subject: Re: [PATCH 1/3] relay: Fix 4 off-by-one errors occuring when writing to a CPU buffer.
Date: Fri, 13 Jun 2008 23:40:37 -0500 [thread overview]
Message-ID: <1213418437.8237.51.camel@charm-linux> (raw)
In-Reply-To: <20080613040947.7465b9a5@linux360.ro>
Hi,
On Fri, 2008-06-13 at 04:09 +0300, Eduard - Gabriel Munteanu wrote:
> Semantically, start + offset is always lower than the total size in bytes,
> so the code should check against equality to size, not size + 1. When
> userspace did read() (but not necessarily restricted to this), this
> resulted in all-zeros data at the end of the buffer.
>
I'm wondering if the all-zeroes at the end of the buffer might be
another case of the all-zeroes you were seeing due to cross-cpu reading
you decribed in the other patch. In any case, I'm pretty sure this
patch isn't doing what you think it is, and don't see how it could have
fixed the problem (see below). There may still be a bug somewhere, but
it would be good to be able to reproduce it. Does it happen even when
running on a single cpu?
> Signed-off-by: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
> ---
> include/linux/relay.h | 4 ++--
> kernel/relay.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/relay.h b/include/linux/relay.h
> index 6cd8c44..8593ca1 100644
> --- a/include/linux/relay.h
> +++ b/include/linux/relay.h
> @@ -202,7 +202,7 @@ static inline void relay_write(struct rchan *chan,
>
> local_irq_save(flags);
> buf = chan->buf[smp_processor_id()];
> - if (unlikely(buf->offset + length > chan->subbuf_size))
> + if (unlikely(buf->offset + length >= chan->subbuf_size))
The original code basically says, "if the current write won't fit in the
remaining space in current subbuffer, move on to the next sub-buffer".
Your change makes it "if the current write won't fit in the current
subbuffer or if it exactly fits, move on to the next sub-buffer", which
isn't what we want.
> length = relay_switch_subbuf(buf, length);
> memcpy(buf->data + buf->offset, data, length);
> buf->offset += length;
> @@ -228,7 +228,7 @@ static inline void __relay_write(struct rchan *chan,
> struct rchan_buf *buf;
>
> buf = chan->buf[get_cpu()];
> - if (unlikely(buf->offset + length > buf->chan->subbuf_size))
Same thing here.
> + if (unlikely(buf->offset + length >= buf->chan->subbuf_size))
> length = relay_switch_subbuf(buf, length);
> memcpy(buf->data + buf->offset, data, length);
> buf->offset += length;
> diff --git a/kernel/relay.c b/kernel/relay.c
> index 7de644c..07f25e7 100644
> --- a/kernel/relay.c
> +++ b/kernel/relay.c
> @@ -622,7 +622,7 @@ size_t relay_switch_subbuf(struct rchan_buf *buf, size_t length)
> if (unlikely(length > buf->chan->subbuf_size))
> goto toobig;
>
> - if (buf->offset != buf->chan->subbuf_size + 1) {
> + if (buf->offset != buf->chan->subbuf_size) {
This case, offset being 1 larger than the subbuf size, is how we note a
full sub-buffer, so changing this will break full-subbuffer cases.
> buf->prev_padding = buf->chan->subbuf_size - buf->offset;
> old_subbuf = buf->subbufs_produced % buf->chan->n_subbufs;
> buf->padding[old_subbuf] = buf->prev_padding;
> @@ -645,7 +645,7 @@ size_t relay_switch_subbuf(struct rchan_buf *buf, size_t length)
> new = buf->start + new_subbuf * buf->chan->subbuf_size;
> buf->offset = 0;
> if (!buf->chan->cb->subbuf_start(buf, new, old, buf->prev_padding)) {
> - buf->offset = buf->chan->subbuf_size + 1;
> + buf->offset = buf->chan->subbuf_size;
Same here.
Tom
> return 0;
> }
> buf->data = new;
next prev parent reply other threads:[~2008-06-14 4:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-13 1:09 [PATCH 1/3] relay: Fix 4 off-by-one errors occuring when writing to a CPU buffer Eduard - Gabriel Munteanu
2008-06-14 4:40 ` Tom Zanussi [this message]
2008-06-14 14:52 ` Eduard - Gabriel Munteanu
2008-06-16 5:22 ` Tom Zanussi
2008-06-21 2:06 ` Eduard - Gabriel Munteanu
2008-07-24 5:09 ` Tom Zanussi
2008-07-30 17:48 ` Eduard - Gabriel Munteanu
2008-08-13 6:16 ` Tom Zanussi
2008-08-14 16:35 ` Eduard - Gabriel Munteanu
2008-08-15 4:31 ` Tom Zanussi
-- strict thread matches above, loose matches on Subject: below --
2008-06-12 20:26 Eduard - Gabriel Munteanu
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=1213418437.8237.51.camel@charm-linux \
--to=tzanussi@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=compudj@krystal.dyndns.org \
--cc=eduard.munteanu@linux360.ro \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@cs.helsinki.fi \
--cc=righi.andrea@gmail.com \
/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