(added Eric, kexec mailing likst, and linux-pm mailing list
into CC because we touch their code)
On Mon 2017-03-06 21:45:53, Sergey Senozhatsky wrote:
> It's not always possible/safe to wake_up() printk kernel
> thread. For example, late suspend/early resume may printk()
> while timekeeping is not
On Wed 2018-01-17 12:50:57, Dave Young wrote:
> It is useful to print kdump kernel loaded status in dump_stack()
> especially when panic happens so that we can differenciate
> kdump kernel early hang and a normal panic in a bug report.
>
> Signed-off-by: Dave Young
> ---
> kernel/printk/printk
On Wed 2018-01-17 20:32:44, Dave Young wrote:
> Hi,
>
> Thanks for your comments.
> On 01/17/18 at 09:57am, Petr Mladek wrote:
> > On Wed 2018-01-17 12:50:57, Dave Young wrote:
> > > It is useful to print kdump kernel loaded status in dump_stack()
> > > espe
On Fri 2018-01-26 15:37:24, Dave Young wrote:
> On 01/19/18 at 12:47pm, Dave Young wrote:
> > On 01/18/18 at 01:57pm, Steven Rostedt wrote:
> > > On Thu, 18 Jan 2018 10:02:17 -0800
> > > Andi Kleen wrote:
> > >
> > > > Dave Young writes:
> > > > > printk("%sHardware name: %s\n",
>
enciate
> > > kdump kernel early hang and a normal panic in a bug report.
> > >
> > > Signed-off-by: Dave Young
> >
> > Looks OK to me.
> >
> > Reviewed-by: Sergey Senozhatsky
Same here:
Reviewed-by: Petr Mladek
> > I agree with St
Hi,
I have seen few prelimitary versions before this public one.
I am either happy with it or blind to see new problems[*].
It would be great if anyone else could look at it. Especially
I am intreseted:
+ Whether the algorithm can be understood by people who
see it for the "first" time.
On Mon 2019-12-02 16:48:41, Petr Mladek wrote:
> > +/* Reserve a new descriptor, invalidating the oldest if necessary. */
> > +static bool desc_reserve(struct printk_ringbuffer *rb, u32 *id_out)
> > +{
> > + struct prb_desc_ring *desc_ring = &rb->desc_ring
On Mon 2019-12-02 17:37:26, John Ogness wrote:
> On 2019-12-02, Petr Mladek wrote:
> >> > +/* Reserve a new descriptor, invalidating the oldest if necessary. */
> >> > +static bool desc_reserve(struct printk_ringbuffer *rb, u32 *id_out)
> >> > +{
> >
On Thu 2019-11-28 02:58:34, John Ogness wrote:
> Add the reader implementation for the new ringbuffer.
>
> Signed-off-by: John Ogness
> ---
> kernel/printk/printk_ringbuffer.c | 234 ++
> kernel/printk/printk_ringbuffer.h | 12 +-
> 2 files changed, 245 insertions(+)
On Tue 2019-12-03 15:13:36, John Ogness wrote:
> On 2019-12-02, Petr Mladek wrote:
> >> +/*
> >> + * Sanity checker for reserve size. The ringbuffer code assumes that a
> >> data
> >> + * block does not exceed the maximum possible size that could fit wit
On Tue 2019-12-03 14:46:07, John Ogness wrote:
> On 2019-12-03, Petr Mladek wrote:
> >> Add the reader implementation for the new ringbuffer.
> >>
> >> Signed-off-by: John Ogness
> >> ---
> >> kernel/printk/printk_ringbuffer.c | 234 ++
On Mon 2019-12-23 17:01:00, John Ogness wrote:
> Hi Andrea,
>
> On 2019-12-21, Andrea Parri wrote:
> >> + *desc_out = READ_ONCE(*desc);
> >> +
> >> + /* Load data before re-checking state. */
> >> + smp_rmb(); /* matches LMM_REF(desc_reserve:A) */
> >
> > I looked for a matching WRITE_ONCE() o
On Wed 2020-02-05 17:12:12, John Ogness wrote:
> On 2020-02-05, lijiang wrote:
> > Do you have any suggestions about the size of CONFIG_LOG_* and
> > CONFIG_PRINTK_* options by default?
>
> The new printk implementation consumes more than double the memory that
> the current printk implementation
booted a system
with this patch. But I guess that I actually did not use the
record_print_text_inline(). So, it might be buggy.
Anyway, I wonder what you think about it:
>From 383e608f41a2f44898e4cd0751c5ccc18c82f71e Mon Sep 17 00:00:00 2001
From: Petr Mladek
Date: Fri, 14 Feb 2020 16:1
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
On Mon 2020-02-17 12:13:25, John Ogness wrote:
> On 2020-02-14, Petr Mladek wrote:
> >> I oversaw that devkmsg_open() setup a printk_record and so I did not
> >> see to add the extra NULL initialization of text_line_count. There
> >> should be be an initializer funct
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 +928,16
Hi,
the new full barrier in desc_reserve() made me to think more about
the existing ones.
If I get it correctly, the used cmpxchg_relaxed() variants does
not provide full barriers. They are just able to prevent parallel
manipulation of the modified variable.
Because of this, I think that we need
Hi,
there are few more small things that catched my eyes during review.
They are from the nits deparment.
On Tue 2020-01-28 17:25:47, John Ogness wrote:
> Introduce a multi-reader multi-writer lockless ringbuffer for storing
> the kernel log messages. Readers and writers may use their API from
>
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 recor
On Mon 2020-03-02 11:38:42, John Ogness wrote:
> On 2020-02-21, Petr Mladek wrote:
> >> diff --git a/kernel/printk/printk_ringbuffer.c
> >> b/kernel/printk/printk_ringbuffer.c
> >> new file mode 100644
> >> index ..796257f226ee
>
On Mon 2020-03-02 14:43:41, John Ogness wrote:
> On 2020-03-02, Petr Mladek wrote:
> >>>> diff --git a/kernel/printk/printk_ringbuffer.c
> >>>> b/kernel/printk/printk_ringbuffer.c
> >>>> new file mode 100644
> >>>> index 000
On Mon 2020-03-02 14:43:41, John Ogness wrote:
> On 2020-03-02, Petr Mladek wrote:
> >>>> diff --git a/kernel/printk/printk_ringbuffer.c
> >>>> b/kernel/printk/printk_ringbuffer.c
> >>>> new file mode 100644
> >>>> index 000
On Tue 2020-03-03 16:42:07, John Ogness wrote:
> On 2020-03-03, Petr Mladek wrote:
> >>>>>> diff --git a/kernel/printk/printk_ringbuffer.c
> >>>>>> b/kernel/printk/printk_ringbuffer.c
> >>>>>> new file mode 100644
> >>
On Thu 2020-02-27 13:04:09, John Ogness wrote:
> On 2020-02-21, Petr Mladek wrote:
> > If I get it correctly, the used cmpxchg_relaxed() variants does not
> > provide full barriers. They are just able to prevent parallel
> > manipulation of the modified variable.
>
>
On Fri 2020-05-01 11:46:08, John Ogness wrote:
> Some structs are not named and are only available via their typedef.
> Add a VMCOREINFO macro to export field offsets for such structs.
Honestly, I did not get the meaning until I looked at the sample
usage added by the 2nd patch.
The term "anonymo
5>[ 70.921642] CPU7: shutdown
> <6>[ 70.922650] psci: CPU7 killed (polled 0 ms)
>
> Signed-off-by: Pavel Tatashin
Reviewed-by: Petr Mladek
Best Regards,
Petr
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On Fri 2020-05-01 11:46:09, John Ogness wrote:
> Introduce a multi-reader multi-writer lockless ringbuffer for storing
> the kernel log messages. Readers and writers may use their API from
> any context (including scheduler and NMI). This ringbuffer will make
> it possible to decouple printk() call
On Fri 2020-05-01 11:46:09, John Ogness wrote:
> Introduce a multi-reader multi-writer lockless ringbuffer for storing
> the kernel log messages. Readers and writers may use their API from
> any context (including scheduler and NMI). This ringbuffer will make
> it possible to decouple printk() call
On Fri 2020-05-01 11:46:09, John Ogness wrote:
> Introduce a multi-reader multi-writer lockless ringbuffer for storing
> the kernel log messages. Readers and writers may use their API from
> any context (including scheduler and NMI). This ringbuffer will make
> it possible to decouple printk() call
On Fri 2020-05-01 11:46:09, John Ogness wrote:
> Introduce a multi-reader multi-writer lockless ringbuffer for storing
> the kernel log messages. Readers and writers may use their API from
> any context (including scheduler and NMI). This ringbuffer will make
> it possible to decouple printk() call
On Fri 2020-05-01 11:46:09, John Ogness wrote:
> Introduce a multi-reader multi-writer lockless ringbuffer for storing
> the kernel log messages. Readers and writers may use their API from
> any context (including scheduler and NMI). This ringbuffer will make
> it possible to decouple printk() call
On Tue 2020-06-09 16:18:35, John Ogness wrote:
> On 2020-06-09, Petr Mladek wrote:
> >> --- /dev/null
> >> +++ b/kernel/printk/printk_ringbuffer.c
> >> +/*
> >> + * Given a data ring (text or dict), put the associated descriptor of each
> >> + *
On Tue 2020-06-09 16:48:30, John Ogness wrote:
> On 2020-06-09, Petr Mladek wrote:
> >> --- /dev/null
> >> +++ b/kernel/printk/printk_ringbuffer.c
> >> +/*
> >> + * Given a data ring (text or dict), put the associated descriptor of each
> >> + *
On Tue 2020-06-09 17:56:03, John Ogness wrote:
> On 2020-06-09, Petr Mladek wrote:
> >> --- /dev/null
> >> +++ b/kernel/printk/printk_ringbuffer.c
> >> +/*
> >> + * Advance the desc ring tail. This function advances the tail by one
> >> + * des
On Wed 2020-06-10 12:24:01, John Ogness wrote:
> On 2020-06-10, Petr Mladek wrote:
> >> >> --- /dev/null
> >> >> +++ b/kernel/printk/printk_ringbuffer.c
> >> >> +/*
> >> >> + * Given a data ring (text or dict), put the associated desc
On Thu 2020-06-18 16:55:17, John Ogness wrote:
> The existing macro VMCOREINFO_OFFSET() can't be used for structures
> declared via typedef because "struct" is not part of type definition.
>
> Create another macro for this purpose.
>
> Signed-off-by: John Ogness
On Thu 2020-06-18 16:55:19, 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
On Thu 2020-06-18 16:55:19, 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
On Thu 2020-06-18 16:55:19, 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
On Thu 2020-06-18 16:55:19, 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
On Thu 2020-06-18 16:55:19, 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
On Thu 2020-06-25 14:09:46, Petr Mladek wrote:
> On Thu 2020-06-18 16:55:19, 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 loc
On Fri 2020-06-26 17:02:48, John Ogness wrote:
> On 2020-06-25, Petr Mladek wrote:
> >> --- a/kernel/printk/printk.c
> >> +++ b/kernel/printk/printk.c
> >> + free = __LOG_BUF_LEN;
> >> + prb_for_each_record(0, &printk_rb_static, seq, &r)
> >
eventual problems at this stage.
Feel free to use:
Reviewed-by: Petr Mladek
[*] I have pretty good feeling about the code. And I really like the extensive
comments. The remaining ideas are mostly from the nits department.
[**] We are getting close to push this into linux-next. I think tha
On Mon 2020-06-29 23:57:59, John Ogness wrote:
> On 2020-06-29, Petr Mladek wrote:
> >> @@ @@ void __init setup_log_buf(int early)
> >> + prb_init(&printk_rb_dynamic,
> >> + new_log_buf, order_base_2(new_log_buf_len),
> >> +
On Thu 2020-07-02 17:43:22, lijiang wrote:
> 在 2020年07月02日 17:02, John Ogness 写道:
> > On 2020-07-02, lijiang wrote:
> >> About the VMCOREINFO part, I made some tests based on the kernel patch
> >> v3, the makedumpfile and crash-utility can work as expected with your
> >> patch(userspace patch), bu
it anyway, just revert it now to
> simplify the transition.
>
> Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
Best Regards,
Petr
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
cord meta-data is now stored in a separate array of descriptors.
> This is an additional 72 * (2 ^ (CONFIG_LOG_BUF_SHIFT - 5)) bytes
> for the static array and 72 * (log_buf_len >> 5) bytes for the
> dynamic array.
>
> Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
B
On Tue 2020-07-07 17:05:28, John Ogness wrote:
> Hello,
>
> Here is a v4 for the first series to rework the printk
> subsystem. The v3 is here [0]. This first series
> only replaces the existing ringbuffer implementation. No locking
> is removed. The semantics/behavior of printk are kept the same
On Thu 2020-07-09 12:20:35, John Ogness wrote:
> On 2020-07-09, Sergey Senozhatsky wrote:
> > On (20/07/09 15:14), kernel test robot wrote:
> > [..]
> >
> > Took me a while to find the FAIL-ed test:
> >
> >> kmsg01.c:393: INFO: TEST: read returns EPIPE when messages get overwritten
> >> kmsg01.c:3
On Thu 2020-07-09 12:59:06, Petr Mladek wrote:
> On Thu 2020-07-09 12:20:35, John Ogness wrote:
> > On 2020-07-09, Sergey Senozhatsky wrote:
> > > On (20/07/09 15:14), kernel test robot wrote:
> > > [..]
> > >
> > > Took me a while to find the FAIL-e
On Thu 2020-07-09 13:23:07, John Ogness wrote:
> On 2020-07-09, Petr Mladek wrote:
> > I though more about it. IMHO, it will be better to modify
> > prb_first_seq() to do the same cycle as prb_next_seq()
> > and return seq number of the first valid entry.
>
> Exactly
On Thu 2020-07-09 22:07:58, Sergey Senozhatsky wrote:
> On (20/07/09 14:25), Petr Mladek wrote:
> > On Thu 2020-07-09 13:23:07, John Ogness wrote:
> > > On 2020-07-09, Petr Mladek wrote:
> > > > I though more about it. IMHO, it will be better to modify
> > >
On Thu 2020-07-09 15:29:40, John Ogness wrote:
> Hello,
>
> Here is a v5 for the first series to rework the printk
> subsystem. The v4 is here [0]. This first series
> only replaces the existing ringbuffer implementation. No locking
> is removed. The semantics/behavior of printk are kept the same
On Thu 2020-07-09 09:09:31, John Ogness wrote:
> On 2020-07-08, Petr Mladek wrote:
> > OK, I think that we are ready to try this in linux-next.
> > I am going to push it there via printk/linux.git.
> >
> > [...]
> >
> > Of course, there are still many
On Fri 2020-07-10 11:58:34, John Ogness wrote:
> On 2020-07-10, Petr Mladek wrote:
> >> The next series in the printk-rework (move LOG_CONT handling from
> >> writers to readers) makes some further changes that, while not
> >> incompatible, could affect the output
d. While at it, remove a useless header
> and encompass a macro inside the sole ifdef block it is used.
>
> Cc: Borislav Petkov
> Cc: Petr Mladek
> Cc: Tony Luck
> Acked-by: Dinh Nguyen
> Signed-off-by: Guilherme G. Piccoli
>
> ---
>
> V3:
> - added the ac
scripts/gdb/linux/dmesg.py already
> does this correctly.
>
> Fixes: e60768311af8 ("scripts/gdb: update for lockless printk ringbuffer")
> Cc: sta...@vger.kernel.org
> Signed-off-by: John Ogness
Great catch!
Reviewed-by: Petr Mladek
Best Regards,
Petr
___
On Thu 2022-12-29 14:49:39, John Ogness wrote:
> @head_id points to the newest record, but the printing loop
> exits when it increments to this value (before printing).
>
> Exit the printing loop after the newest record has been printed.
>
> The python-based function in scripts/gdb/linux/dmesg.py
On Fri 2023-02-10 17:35:10, Guilherme G. Piccoli wrote:
> Commit 8d470a45d1a6 ("panic: add option to dump all CPUs backtraces in
> panic_print")
> introduced a setting for the "panic_print" kernel parameter to allow
> users to request a NMI backtrace on panic. Problem is that the panic_print
> han
On Wed 2023-06-21 11:09:57, Joel Granados wrote:
> In order to remove the end element from the ctl_table struct arrays, we
> explicitly define the size when registering the targes. We add a size
> argument to the register_sysctl_init call and pass an ARRAY_SIZE for all
> the callers.
This does not
On Thu 2023-06-22 16:00:21, Joel Granados wrote:
> On Thu, Jun 22, 2023 at 06:21:48AM +0200, Jiri Slaby wrote:
> > On 21. 06. 23, 15:15, Joel Granados wrote:
> > > On Wed, Jun 21, 2023 at 12:47:58PM +0200, Greg Kroah-Hartman wrote:
> > > > On Wed, Jun 21, 2023 at 11:09:57AM +0200, Joel Granados wro
On Tue 2020-07-21 15:31:28, John Ogness wrote:
> With commit ("printk: use the lockless ringbuffer"), printk()
> started silently dropping messages without text because such
> records are not supported by the new printk ringbuffer.
>
> Add support for such records.
>
> Currently dataless records
On Tue 2020-08-11 12:40:22, Orson Zhai wrote:
> From: Thomas Gleixner
>
> Timestamps printed in kernel log are retrieved by local_clock which reads
> jiffies as a referrence clock source.
> But it is diffcult to be synchronized with logs generated out of kernel,
> say some remote processors (Mode
On Tue 2020-08-11 14:05:12, Thomas Gleixner wrote:
> Petr Mladek writes:
> > At least "crash" tool would need an update anyway. AFAIK, it checks
> > the size of struct printk_log and refuses to read it when it changes.
> >
> > It means that the hack with VM
On Sat 2020-07-18 16:48:55, John Ogness wrote:
> On 2020-07-17, Linus Torvalds wrote:
> > Make sure you test the case of "fast concurrent readers". The last
> > time we did things like this, it was a disaster, because a concurrent
> > reader would see and return the _incomplete_ line, and the next
On Tue 2020-08-11 18:05:51, Petr Mladek wrote:
> On Sat 2020-07-18 16:48:55, John Ogness wrote:
> > On 2020-07-17, Linus Torvalds wrote:
> > > Make sure you test the case of "fast concurrent readers". The last
> > > time we did things like this, it
On Thu 2020-08-13 02:30:02, John Ogness wrote:
> On 2020-08-12, Petr Mladek wrote:
> > So, I have one crazy idea to add one more state bit so that we
> > could have:
> >
> > + committed: set when the data are written into the data ring.
> > + final: set whe
On Thu 2020-08-13 14:18:53, Sergey Senozhatsky wrote:
> On (20/08/13 02:30), John Ogness wrote:
> > 2. I haven't yet figured out how to preserve calling context when a
> > newline appears. For example:
> >
> > pr_info("text");
> > pr_cont(" 1");
> > pr_cont(" 2\n");
> > pr_cont("3");
> > pr_cont("
On Thu 2020-08-13 09:50:25, John Ogness wrote:
> On 2020-08-13, Sergey Senozhatsky wrote:
> > This is not an unseen pattern, I'm afraid. And the problem here can
> > be more general:
> >
> > pr_info("text");
> > pr_cont("1");
> > exception/IRQ/NMI
> > pr_alert("text\n");
>
On Thu 2020-08-13 10:55:00, Sergey Senozhatsky wrote:
> On (20/08/11 15:02), Petr Mladek wrote:
> > On Tue 2020-08-11 14:05:12, Thomas Gleixner wrote:
> > > Petr Mladek writes:
> > > > At least "crash" tool would need an update anyway. AFAIK, it checks
&
On Thu 2020-08-13 12:35:47, John Ogness wrote:
> On 2020-08-13, Petr Mladek wrote:
> > On Thu 2020-08-13 09:50:25, John Ogness wrote:
> >> On 2020-08-13, Sergey Senozhatsky wrote:
> >> > This is not an unseen pattern, I'm afraid. And the prob
On Thu 2020-08-13 20:54:35, Sergey Senozhatsky wrote:
> On (20/08/13 10:41), Petr Mladek wrote:
> > > My concerns about this idea:
> > >
> > > - What if the printk user does not correctly terminate the cont message?
> > > There is no mechanism to allow
On Fri 2020-08-14 10:22:35, John Ogness wrote:
> On 2020-08-14, Sergey Senozhatsky wrote:
> > One thing that we need to handle here, I believe, is that the context
> > which crashes the kernel should flush its cont buffer, because the
> > information there is relevant to the crash:
> >
> > pr_
On Thu 2020-08-13 20:31:55, Sergey Senozhatsky wrote:
> On (20/08/13 12:22), Petr Mladek wrote:
> >
> > + would take more space (prefix + text vs. binary representation)
>
> Dict buffer is allocated regardless of how we use it, and only printks
> from drivers/* (dev_p
or both patches:
Tested-by: Petr Mladek
I am not familiar with the timekeeping code so that I could not
provide a valuable review. Anyway, the patches seem to work
as expected.
The interface is perfectly fine for printk() needs.
I tested them with the patch below. The first timestamps appear
as
On Thu 2020-08-20 12:30:55, Thomas Gleixner wrote:
> Petr,
>
> On Thu, Aug 20 2020 at 10:47, Petr Mladek wrote:
> > The interface is perfectly fine for printk() needs.
>
> Good. So I suggest that I apply that on top of rc1 somewhere in tip and
> tag the top commit. So yo
t;)
> Signed-off-by: John Ogness
> Reported-by: Nick Desaulniers
Looks nice.
Reviewed-by: Petr Mladek
Thanks a lot for taking care of the crashdump related stuff.
It helps a lot.
Best Regards,
Petr
___
kexec mailing list
kexec@lists.infradead
onfusion when more
> state flags are available.
>
> Change the representation of the reusable queried state to just
> the DESC_REUSE_MASK flag.
>
> Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
Best Regards,
Petr
___
kexec mailing
bout something like?
"A comming support for continuous lines will allow to reopen records
with DESC_COMMITTED_MASK set. As a result, the flag will not longer
describe the final committed state. Rename it to DESC_COMMIT_MASK
as a preparation step."
With the updated commit message:
Rev
On Mon 2020-08-24 12:41:34, John Ogness wrote:
> Move the internal get_data() function as-is above prb_reserve() so
> that a later change can make use of the static function.
>
> Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
Best R
On Mon 2020-08-24 12:41:35, John Ogness wrote:
> Rather than continually needing to explicitly check @begin and @next
> to identify a dataless block, introduce and use a BLK_DATALESS()
> macro.
>
> Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
Bes
On Wed 2020-08-26 14:43:22, John Ogness wrote:
> On 2020-08-26, Sergey Senozhatsky wrote:
> >>> @@ -1157,6 +1431,14 @@ bool prb_reserve(struct prb_reserved_entry *e,
> >>> struct printk_ringbuffer *rb,
> >>> goto fail;
> >>> }
> >>>
> >>> + /*
> >>> + * New data is about to be rese
Hi,
this mail is based on my review that I did last two days. I haven't
seen the last code that tried to handle the finalize issues.
Anyway, this feedback might give some clueue as well.
IMPORTANT: It seems that we both had different understanding of
the DESC_FINAL_MASK behavior. It might explain
On Thu 2020-08-27 12:04:58, John Ogness wrote:
> On 2020-08-26, Petr Mladek wrote:
> >> This series makes a very naive assumption that the previous
> >> descriptor is either in the reserved or committed queried states. The
> >> fact is, it can be in any of the 4 quer
On Thu 2020-08-27 12:04:58, John Ogness wrote:
> On 2020-08-26, Petr Mladek wrote:
> >> This series makes a very naive assumption that the previous
> >> descriptor is either in the reserved or committed queried states. The
> >> fact is, it can be in any of the 4 quer
On Fri 2020-08-14 23:39:16, John Ogness wrote:
> With the introduction of the lockless printk ringbuffer, the
> VMCOREINFO relating to the kernel log buffer was changed. Update the
> documentation to match those changes.
>
> Fixes: ("printk: use the lockless ringbuffer")
> Signed-off-by: John Ogne
On Mon 2020-08-31 03:16:55, John Ogness wrote:
> prb_reserve() will set some meta data values and leave others
> uninitialized (or rather, containing the values of the previous
> wrap). Simplify the API by always clearing out all the fields.
> Only the sequence number is filled in. The caller is no
On Mon 2020-08-31 03:16:56, John Ogness wrote:
> Add support for extending the newest data block. For this, introduce
> a new finalization state flag (DESC_FINAL_MASK) that denotes when a
> descriptor may not be extended, i.e. is finalized.
> --- a/kernel/printk/printk_ringbuffer.c
> +++ b/kernel
On Mon 2020-08-31 03:16:56, John Ogness wrote:
> Add support for extending the newest data block. For this, introduce
> a new finalization state flag (DESC_FINAL_MASK) that denotes when a
> descriptor may not be extended, i.e. is finalized.
>
> --- a/kernel/printk/printk_ringbuffer.c
> +++ b/kerne
On Mon 2020-08-31 03:16:56, John Ogness wrote:
> Add support for extending the newest data block. For this, introduce
> a new finalization state flag (DESC_FINAL_MASK) that denotes when a
> descriptor may not be extended, i.e. is finalized.
>
> Three new memory barrier pairs are introduced. Two of
On Wed 2020-09-02 13:26:14, John Ogness wrote:
> On 2020-09-02, Petr Mladek wrote:
> >> +static struct prb_desc *desc_reopen_last(struct prb_desc_ring *desc_ring,
> >> + u32 caller_id, unsigned long *id_out)
> >> +{
> &
/printk/printk.c | 98 +-
> 1 file changed, 20 insertions(+), 78 deletions(-)
It looks simple from the printk() side ;-)
Reviewed-by: Petr Mladek
Best Regards,
Petr
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
he caller is now
> responsible for filling in the rest of the meta data fields.
> In particular, for correctly filling in text and dict lengths.
>
> Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
Best Regards,
Petr
___
lues for the state variable.
>
> Although the functionality is preserved, the binary representation
> for the states is changed.
>
> Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
Best Regards,
Petr
___
kexec mailing list
kex
On Tue 2020-09-08 22:34:58, John Ogness wrote:
> Add support for extending the newest data block. For this, introduce
> a new finalization state (desc_finalized) denoting a committed
> descriptor that cannot be extended.
>
> Until a record is finalized, a writer can reopen that record to
> append
On Mon 2020-09-14 14:39:53, John Ogness wrote:
> Add support for extending the newest data block. For this, introduce
> a new finalization state (desc_finalized) denoting a committed
> descriptor that cannot be extended.
>
> Signed-off-by: John Ogness
Looks good to me:
Reviewed-
On Mon 2020-09-14 14:39:48, John Ogness wrote:
> Hello,
>
> Here is v5 for the second series to rework the printk subsystem.
> (The v4 is here [0].) This series implements a new ringbuffer
> feature that allows the last record to be extended. Petr Mladek
> provided the initial p
On Thu 2020-09-17 15:22:42, John Ogness wrote:
> The majority of the size of a descriptor is taken up by meta data,
> which is often not of interest to the ringbuffer (for example,
> when performing state checks). Since descriptors are often
> temporarily stored on the stack, keeping their size min
1 - 100 of 145 matches
Mail list logo
