2014-03-13 0:50 GMT+08:00 Kees Cook <keesc...@chromium.org>: > On Wed, Mar 12, 2014 at 6:24 AM, Liu Shuo <shuox....@gmail.com> wrote: >> From: Liu ShuoX <shuox....@intel.com> >> >> In case new offset is equal to prz->buffer_size, it won't wrap at this >> time and will return old(overflow) value next time. >> >> Signed-off-by: Liu ShuoX <shuox....@intel.com> > > This seems correct; good catch. Have you seen this problem happen, or > is this just from reading the code? Thanks. We indeed hit it when we enhanced the ramoops tracing.
> > Acked-by: Kees Cook <keesc...@chromium.org> > > -Kees > >> --- >> fs/pstore/ram_core.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c >> index de272d4..ff7e3d4 100644 >> --- a/fs/pstore/ram_core.c >> +++ b/fs/pstore/ram_core.c >> @@ -54,7 +54,7 @@ static size_t buffer_start_add_atomic(struct >> persistent_ram_zone *prz, size_t a) >> do { >> old = atomic_read(&prz->buffer->start); >> new = old + a; >> - while (unlikely(new > prz->buffer_size)) >> + while (unlikely(new >= prz->buffer_size)) >> new -= prz->buffer_size; >> } while (atomic_cmpxchg(&prz->buffer->start, old, new) != old); >> >> @@ -91,7 +91,7 @@ static size_t buffer_start_add_locked(struct >> persistent_ram_zone *prz, size_t a) >> >> old = atomic_read(&prz->buffer->start); >> new = old + a; >> - while (unlikely(new > prz->buffer_size)) >> + while (unlikely(new >= prz->buffer_size)) >> new -= prz->buffer_size; >> atomic_set(&prz->buffer->start, new); >> >> -- >> 1.8.3.2 >> >> >> > > > > -- > Kees Cook > Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/