On Tue 2020-02-25 21:11:31, John Ogness wrote:
> >> --- a/kernel/printk/printk.c
> >> +++ b/kernel/printk/printk.c
> >> - * Every record carries the monotonic timestamp in microseconds, as well
> >> as
> >> - * the standard userspace syslog level and syslog facility. The usual
> >> + * Every
>> - Record meta-data is now stored in a separate array of descriptors.
>> This is an additional 72 * (2 ^ ((CONFIG_LOG_BUF_SHIFT - 6))) bytes
>> for the static array and 72 * (2 ^ ((log_buf_len - 6))) bytes for
>> the dynamic array.
>
> It might help to show some examples. I mean to mention
在 2020年01月29日 00:19, John Ogness 写道:
> Replace the existing ringbuffer usage and implementation with
> lockless ringbuffer usage. Even though the new ringbuffer does not
> require locking, all existing locking is left in place. Therefore,
> this change is purely replacing the underlining
On 2020-02-17, Petr Mladek wrote:
>>> Should the "prb"(printk tb static) symbol be exported into
>>> vmcoreinfo? Otherwise, do you happen to know how to walk through
>>> the log_buf and get all kernel logs from vmcore?
>>
>> You are correct. This will need to be exported as well so that the
>>
On Fri 2020-02-14 14:50:02, John Ogness wrote:
> Hi Lianbo,
>
> On 2020-02-14, lijiang wrote:
> >> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> >> index 1ef6f75d92f1..d0d24ee1d1f4 100644
> >> --- a/kernel/printk/printk.c
> >> +++ b/kernel/printk/printk.c
> >> @@ -1062,21
On Tue 2020-01-28 17:25:48, John Ogness wrote:
> Replace the existing ringbuffer usage and implementation with
> lockless ringbuffer usage. Even though the new ringbuffer does not
> require locking, all existing locking is left in place. Therefore,
> this change is purely replacing the underlining
在 2020年02月14日 21:50, John Ogness 写道:
> Hi Lianbo,
>
> On 2020-02-14, lijiang wrote:
>>> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
>>> index 1ef6f75d92f1..d0d24ee1d1f4 100644
>>> --- a/kernel/printk/printk.c
>>> +++ b/kernel/printk/printk.c
>>> @@ -1062,21 +928,16 @@ void
Hi Lianbo,
On 2020-02-14, lijiang wrote:
>> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
>> index 1ef6f75d92f1..d0d24ee1d1f4 100644
>> --- a/kernel/printk/printk.c
>> +++ b/kernel/printk/printk.c
>> @@ -1062,21 +928,16 @@ void log_buf_vmcoreinfo_setup(void)
>> {
>>
On 2020-02-14, Sergey Senozhatsky wrote:
>>> cat /dev/kmsg
>>> cat: /dev/kmsg: Broken pipe
>>
>> In mainline you can have this "problem" as well. Once the ringbuffer
>> has wrapped, any read to a newly opened /dev/kmsg when a new message
>> arrived will result in an EPIPE. This happens quite
On (20/02/14 10:41), Sergey Senozhatsky wrote:
> On (20/02/13 23:36), John Ogness wrote:
[..]
> > We could implement it such that devkmsg_read() will skip over data-less
> > records instead of issuing an EPIPE. (That is what dmesg does.) But then
> > do we need EPIPE at all? The reader can see
On (20/02/13 23:36), John Ogness wrote:
> >> Here prb_read_valid() was successful, so a record _was_ read. The
> >> kerneldoc for the prb_read_valid() says:
> >
> > Hmm, yeah. That's true.
> >
> > OK, something weird...
> >
> > I ran some random printk-pressure test (mostly printks from IRQs;
> >
On 2020-02-13, Sergey Senozhatsky wrote:
@@ -890,30 +758,26 @@ static ssize_t devkmsg_read(struct file *file, char
__user *buf,
logbuf_unlock_irq();
ret = wait_event_interruptible(log_wait,
- user->seq
On (20/02/13 10:42), John Ogness wrote:
> On 2020-02-13, Sergey Senozhatsky wrote:
> >> - while (user->seq == log_next_seq) {
> >> + if (!prb_read_valid(prb, user->seq, r)) {
> >>if (file->f_flags & O_NONBLOCK) {
> >>ret = -EAGAIN;
> >>
On 2020-02-13, Sergey Senozhatsky wrote:
>> -while (user->seq == log_next_seq) {
>> +if (!prb_read_valid(prb, user->seq, r)) {
>> if (file->f_flags & O_NONBLOCK) {
>> ret = -EAGAIN;
>> logbuf_unlock_irq();
>> @@ -890,30 +758,26 @@
On (20/01/28 17:25), John Ogness wrote:
[..]
> - while (user->seq == log_next_seq) {
> + if (!prb_read_valid(prb, user->seq, r)) {
> if (file->f_flags & O_NONBLOCK) {
> ret = -EAGAIN;
> logbuf_unlock_irq();
> @@ -890,30 +758,26 @@
15 matches
Mail list logo
