From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
To: Vincent Brillault <vincent.brillault@cern.ch>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Petr Mladek <pmladek@suse.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Kees Cook <keescook@chromium.org>,
Thierry Reding <treding@nvidia.com>,
Geliang Tang <geliangtang@163.com>, Tejun Heo <tj@kernel.org>,
Ivan Delalande <colona@arista.com>,
linux-kernel@vger.kernel.org
Subject: Re: kernel/printk/printk.c: Invalid access when buffer wraps around?
Date: Sun, 31 Jul 2016 17:41:08 +0900 [thread overview]
Message-ID: <20160731084108.GA538@swordfish> (raw)
In-Reply-To: <89c15437-5a97-68b1-d83f-097f3b047559@cern.ch>
Hello,
sorry for long reply. do you see this in practice?
On (07/25/16 11:22), Vincent Brillault wrote:
[..]
> To be specific, these circonstances are:
> - The buffer is almost full and the `log_next_seq` is closed to the end,
> but there is still place for small messages
> - A reader updates its index and sequence to log_next_*
> - The next message is too large, resulting in the buffer wrapping-around and
> a zeroed header to be added at the reader index position
> - The buffer is completely filled with new messages but without wrapping:
> + The last message must not wrap around (thus log_first_seq will be equal to
> the readers's index)
> + The last message must override the zeroed header (Trigerring the bug)
> - The reader starts reading again, finding random data instead of the zero
> 'len' it was supposed to read...
the first printk()->console_unlock() to notice `seen_seq != log_next_seq`
will wakeup a task from log_wait, sleeping on
wait_event_interruptible(seq != log_next_seq)
so I believe your assumption here is that we wrap around and then fill up
the log_buf again without waking up the klogd even once, correct?
CPU0 CPU1
console_lock();
printk();
... devkmsg_read();
printk();
console_unlock();
like the above?
-ss
next prev parent reply other threads:[~2016-07-31 8:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-25 9:22 kernel/printk/printk.c: Invalid access when buffer wraps around? Vincent Brillault
2016-07-31 8:41 ` Sergey Senozhatsky [this message]
2016-07-31 13:26 ` Vincent Brillault
2016-08-01 16:33 ` Ivan Delalande
2016-08-05 5:14 ` Vincent Brillault
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=20160731084108.GA538@swordfish \
--to=sergey.senozhatsky@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=aryabinin@virtuozzo.com \
--cc=colona@arista.com \
--cc=geliangtang@163.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=tj@kernel.org \
--cc=treding@nvidia.com \
--cc=vincent.brillault@cern.ch \
/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.