Re: [PATCH V6] panic: Move panic_print before kmsg dumpers

On (22/02/25 13:16), Petr Mladek wrote: > > The result looks good to me. We could do it as a followup patch. > Yup, sounds good to me. Thanks. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH V6] panic: Move panic_print before kmsg dumpers

Correction: On (22/02/25 14:18), Sergey Senozhatsky wrote: > > > > Or just split panic_printk_sys_info() into these two functions. > > Agreed. I also tend to think that panic_printk_sys_info() is needed anyway,

Re: [PATCH V6] panic: Move panic_print before kmsg dumpers

On (22/02/24 15:33), Petr Mladek wrote: > > My bad! I did not spot the `return` at the end of the new branch. > > > > + if (console_flush) { > > + if (panic_print & PANIC_PRINT_ALL_PRINTK_MSG) > > + console_flush_on_panic(CONSOLE_REPLAY_ALL); > > +

Re: [PATCH V6] panic: Move panic_print before kmsg dumpers

Hi, On (22/02/23 10:15), Guilherme G. Piccoli wrote: > On 22/02/2022 22:27, Sergey Senozhatsky wrote: > > [...] > > Hmm. Yeah, well, that's a bit of a tricky interface now > > > > panic() > > // everything (if correspo

Re: [PATCH V6] panic: Move panic_print before kmsg dumpers

On (22/02/15 17:14), Petr Mladek wrote: > Makes sense and looks good to me. > > Reviewed-by: Petr Mladek FWIW Reviewed-by: Sergey Senozhatsky ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH V6] panic: Move panic_print before kmsg dumpers

On (22/02/22 11:08), Guilherme G. Piccoli wrote: > Hi Sergey, thanks for your feedback. So, personally I prefer having the > flag - for me it's clear, it's just a matter of reading the prototype - > either we print the info _or_ we console_flush. > > But let's see if others have a preference - if

Re: [PATCH V6] panic: Move panic_print before kmsg dumpers

On (22/02/22 11:10), Guilherme G. Piccoli wrote: > On 21/02/2022 23:06, Sergey Senozhatsky wrote: > > On (22/02/14 11:13), Guilherme G. Piccoli wrote: > > [...] > > By additional panic_print messages you mean that panic_print_sys_info() > > will print everything (except

Re: [PATCH V6] panic: Move panic_print before kmsg dumpers

A trivial typo: On (22/02/22 11:06), Sergey Senozhatsky wrote: > @@ -286,6 +289,8 @@ void panic(const char *fmt, ...) >*/ > atomic_notifier_call_chain(_notifier_list, 0, buf); > > > + panic_print_sys_info(panic_print & ~PANIC_PRINT_ALL_PRINTK_MSG); &

Re: [PATCH V6] panic: Move panic_print before kmsg dumpers

On (22/02/14 11:13), Guilherme G. Piccoli wrote: > > The additional messages from panic_print could overwrite the oldest > messages when the buffer is full. The only reasonable solution is to > use a large enough log buffer, hence we added an advice into the kernel > parameters documentation

Re: [PATCH V6] panic: Move panic_print before kmsg dumpers

On (22/02/14 11:13), Guilherme G. Piccoli wrote: > -static void panic_print_sys_info(void) > +static void panic_print_sys_info(bool console_flush) > { > - if (panic_print & PANIC_PRINT_ALL_PRINTK_MSG) > - console_flush_on_panic(CONSOLE_REPLAY_ALL); > + if (console_flush) { > +

Re: [PATCH printk v2 2/5] printk: remove safe buffers

On (21/04/01 16:17), Petr Mladek wrote: > > For the long term, we should introduce a printk-context API that allows > > callers to perfectly pack their multi-line output into a single > > entry. We discussed [0][1] this back in August 2020. > > We need a "short" term solution. There are currently

Re: [PATCH next v1 2/3] printk: remove safe buffers

On (21/03/17 00:33), John Ogness wrote: [..] > void printk_nmi_direct_enter(void) > { > @@ -324,27 +44,8 @@ void printk_nmi_direct_exit(void) > this_cpu_and(printk_context, ~PRINTK_NMI_DIRECT_CONTEXT_MASK); > } > > -#else > - > -static __printf(1, 0) int vprintk_nmi(const char *fmt,

Re: [PATCH v2 5/7][next] printk: ringbuffer: add finalization/extension support

On (20/08/26 10:45), John Ogness wrote: > On 2020-08-24, John Ogness 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 reserved. Once that

Re: POC: Alternative solution: Re: [PATCH 0/4] printk: reimplement LOG_CONT handling

On (20/08/14 15:46), Linus Torvalds wrote: > On Thu, Aug 13, 2020 at 4:54 AM Sergey Senozhatsky > wrote: > > > > I think what Linus said a long time ago was that the initial purpose of > > pr_cont was > > > > pr_info("Initialize feature foo...&q

Re: POC: Alternative solution: Re: [PATCH 0/4] printk: reimplement LOG_CONT handling

On (20/08/13 12:35), John Ogness wrote: > I believe I failed to recognize the fundamental problem. The fundamental > problem is that the pr_cont() semantics are very poor. The semantics is pretty clear - use it only in UP early bootup, anything else is broken :) /* * Annotation for a

Re: POC: Alternative solution: Re: [PATCH 0/4] printk: reimplement LOG_CONT handling

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 that open record to be force-finalized > > so that readers can read newer records. > > This is a real

Re: [RFC PATCH] printk: Change timestamp to triplet as mono, boot and real

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_printk*) add dict payload. It might be the case that on some (if not most) systems dict pages

Re: POC: Alternative solution: Re: [PATCH 0/4] printk: reimplement LOG_CONT handling

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(" 4\n"); > > For "3" the calling context (info, timestamp) is lost

Re: [RFC PATCH] printk: Change timestamp to triplet as mono, boot and real

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 > > > the size of struct printk_log and refuses to read it when it changes. > > > > > > It means that the

Re: [PATCH 2/4] printk: store instead of processing cont parts

On (20/07/21 17:03), John Ogness wrote: > On 2020-07-21, Sergey Senozhatsky wrote: > >> That said, we have traditionally used not just "current process", but > >> also "last irq-level" as the context information, so I do think it > >> would be goo

Re: [PATCH 2/4] printk: store instead of processing cont parts

On (20/07/21 08:40), Linus Torvalds wrote: > On Tue, Jul 21, 2020 at 7:42 AM Sergey Senozhatsky > wrote: > > > > OK, so basically, extending printk_caller_id() so that for IRQ/NMI > > we will have more info than just "0x8000 + raw_smp_processor_id()". >

Re: [PATCH v2][next] printk: ringbuffer: support dataless records

On (20/07/21 15:31), 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 are

Re: [PATCH 2/4] printk: store instead of processing cont parts

On (20/07/20 11:30), Linus Torvalds wrote: > > Do I get it right, what you are saying is - when we process a PR_CONT > > message the cont buffer should already contain previous non-LOG_NEWLINE > > and non-PR_CONT message, otherwise it's a bug? > > No. > > I'm saying that the code that does

Re: [PATCH][next] printk: ringbuffer: support dataless records

/* Report an error if there should have been data. */ > + if (desc.info.text_len != 0) > + return -ENOENT; > } If this is a dataless record then should copy_data() return error? Otherwise, looks good to me Acked-by: Sergey Senozhatsky -ss __

Re: [PATCH v5 4/4] printk: use the lockless ringbuffer

On (20/07/20 08:43), Marco Elver wrote: > On Sun, Jul 19, 2020 at 12:43PM +0900, Sergey Senozhatsky wrote: > > As I said, a number of debugging tools use them to format reports to be > more readable (visually separate title and report body, and separate > parts of the report). Als

Re: [PATCH v5 4/4] printk: use the lockless ringbuffer

On (20/07/20 08:43), Marco Elver wrote: [..] > please see a full list of newline-print users below. [..] > $> git grep -En '\<(printk|pr_err|pr_warn|pr_info)\>\("\\n"\)' > arch/alpha/kernel/core_wildfire.c:650:printk("\n"); > arch/alpha/kernel/core_wildfire.c:658:printk("\n"); >

Re: [PATCH 2/4] printk: store instead of processing cont parts

On (20/07/19 11:27), Linus Torvalds wrote: > On Sun, Jul 19, 2020 at 7:35 AM Sergey Senozhatsky > wrote: > > > > Can we merge lines that we don't want to merge? > > > >pr_cont() -> IRQ -> pr_cont() -> NMI -> pr_cont() > > That pr_cont in ei

Re: [PATCH 2/4] printk: store instead of processing cont parts

On (20/07/18 01:54), John Ogness wrote: > --- > kernel/printk/printk.c | 114 - > 1 file changed, 11 insertions(+), 103 deletions(-) > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c > index fec71229169e..c4274c867771 100644 > ---

Re: [PATCH v5 4/4] printk: use the lockless ringbuffer

Hi Marco, On (20/07/18 14:10), Marco Elver wrote: > > It seems this causes a regression observed at least with newline-only > printks. I noticed this during -next testing because various debugging > tools (K*SAN, lockdep, etc.) use e.g. pr_{err,warn,info}("\n") to format > reports. > > Without

Re: [PATCH v4 0/4] printk: replace ringbuffer

On (20/07/10 11:58), John Ogness wrote: > > IMHO users of these sequence number interfaces need to see all the > records individually and reassemble the LOG_CONT messages themselves if > they want to. I believe that is the only sane path forward. To do this, > the caller id will no longer be

Re: [PATCH v5 0/4] printk: replace ringbuffer

edef > > printk: add lockless ringbuffer > > Revert "printk: lock/unlock console only for new logbuf entries" > > printk: use the lockless ringbuffer > > The patchset is committed in printk/linux.git, branch printk-rework. FWIW, Acked-by: Sergey Senozhat

Re: [PATCH v5 2/4] printk: add lockless ringbuffer

On (20/07/10 17:43), Sergey Senozhatsky wrote: > [..] > > > +void prb_init(struct printk_ringbuffer *rb, > > + char *text_buf, unsigned int textbits, > > + char *dict_buf, unsigned int dictbits, > > + struct prb_desc *descs, unsigned int d

Re: [PATCH v5 2/4] printk: add lockless ringbuffer

On (20/07/09 15:29), John Ogness wrote: [..] > +/* > + * A data block: mapped directly to the beginning of the data block area > + * specified as a logical position within the data ring. > + * > + * @id: the ID of the associated descriptor > + * @data: the writer data > + * > + * Note that the

Re: [printk] 18a2dc6982: ltp.kmsg01.fail

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 > > > prb_first_seq() to do the same cycle as prb_next_seq() > > > and return seq number of the first

Re: [printk] 18a2dc6982: ltp.kmsg01.fail

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:398: INFO: first seqno: 0 > kmsg01.c:411: INFO: first seqno now: 881 > kmsg01.c:425: FAIL: read returned: 77:

Re: [PATCH v4 3/4] Revert "printk: lock/unlock console only for new logbuf entries"

ay, just revert it now to > simplify the transition. > > Signed-off-by: John Ogness Acked-by: Sergey Senozhatsky -ss ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v2 0/3] printk: replace ringbuffer

ing LPC2019 in Lisbon, with 1 exception: support for dictionaries > will not be discontinued [4]. Dictionaries are stored in a separate > buffer so that they cannot interfere with the human-readable buffer. I'm willing to bless this. The code looks good to me, nice job guys

Re: [PATCH 2/2] printk: use the lockless ringbuffer

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 al

Re: [PATCH 2/2] printk: use the lockless ringbuffer

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; > >

Re: [PATCH 0/2] printk: replace ringbuffer

On (20/02/13 14:07), Petr Mladek wrote: > 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

Re: [PATCH 2/2] printk: use the lockless ringbuffer

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_NONBLO

Re: [PATCH 2/2] printk: use the lockless ringbuffer

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 @@

Re: [PATCH 0/2] printk: replace ringbuffer

On (20/02/05 16:48), John Ogness wrote: > On 2020-02-05, Sergey Senozhatsky wrote: > > 3BUG: KASAN: wild-memory-access in copy_data+0x129/0x220> > > 3Write of size 4 at addr 5a5a5a5a5a5a5a5a by task cat/474> > > The problem was due to an uninitialized pointer. >

Re: [PATCH 0/2] printk: replace ringbuffer

On (20/02/05 10:00), John Ogness wrote: > On 2020-02-05, Sergey Senozhatsky wrote: > >>>> So there is a General protection fault. That's the type of a > >>>> problem that kills the boot for me as well (different backtrace, > >>>> t

Re: [PATCH 0/2] printk: replace ringbuffer

On (20/02/05 10:00), John Ogness wrote: > On 2020-02-05, Sergey Senozhatsky wrote: > >>>> So there is a General protection fault. That's the type of a > >>>> problem that kills the boot for me as well (different backtrace, > >>>> t

Re: [PATCH 0/2] printk: replace ringbuffer

On (20/02/05 13:38), lijiang wrote: > > On (20/02/05 13:48), Sergey Senozhatsky wrote: > >> On (20/02/05 12:25), lijiang wrote: [..] > >> > >> So there is a General protection fault. That's the type of a problem that > >> kills the boot for me as well (

Re: [PATCH 0/2] printk: replace ringbuffer

On (20/02/05 13:48), Sergey Senozhatsky wrote: > On (20/02/05 12:25), lijiang wrote: > [..] > > [ 42.111004] Kernel Offset: 0x1f00 from 0x8100 > > (relocation range: 0x8000-0xbfff) > > [ 42.111005] general protection

Re: [PATCH 0/2] printk: replace ringbuffer

On (20/02/05 12:25), lijiang wrote: [..] > [ 42.111004] Kernel Offset: 0x1f00 from 0x8100 (relocation > range: 0x8000-0xbfff) > [ 42.111005] general protection fault: [#1] SMP PTI > [ 42.111005] CPU: 15 PID: 1395 Comm: systemd-journal Not tainted

Re: [PATCH 0/2] printk: replace ringbuffer

On (20/02/05 12:25), lijiang wrote: > Hi, John Ogness > > Thank you for improving the patch series and making great efforts. > > I'm not sure if I missed anything else. Or are there any other related > patches to be applied? > > After applying this patch series, NMI watchdog detected a hard

Re: [RFC PATCH v5 1/3] printk-rb: new printk ringbuffer implementation (writer)

On (19/11/28 02:58), John Ogness wrote: > + * Sample reader code:: > + * > + * struct printk_info info; > + * char text_buf[32]; > + * char dict_buf[32]; > + * u64 next_seq = 0; > + * struct printk_record r = { > + * .info = , > + * .text_buf =

Re: [RFC PATCH v5 1/3] printk-rb: new printk ringbuffer implementation (writer)

On (19/12/02 16:48), Petr Mladek wrote: > Hi, > > I have seen few prelimitary versions before this public one. > I am either happy with it or blind to see new problems[*]. I guess I'm happy with it. -ss ___ kexec mailing list

Re: [RFC PATCH v5 2/3] printk-rb: new printk ringbuffer implementation (reader)

On (19/12/09 17:43), Sergey Senozhatsky wrote: > > +static int desc_read_committed(struct prb_desc_ring *desc_ring, u32 id, > > + u64 seq, struct prb_desc *desc) > > +{ > > + enum desc_state d_state; > > + > > + d_s

Re: [RFC PATCH v5 3/3] printk-rb: add test module

On (19/11/28 02:58), John Ogness wrote: > + * This is a test module that starts "num_online_cpus()" writer threads > + * that each write data of varying length. They do this as fast as > + * they can. Can we also add some IRQ (hard or soft) writers and (if possible) some NMI writers? -ss

Re: [RFC PATCH v5 2/3] printk-rb: new printk ringbuffer implementation (reader)

On (19/11/28 02:58), John Ogness wrote: > +/* Given @blk_lpos, copy an expected @len of data into the provided buffer. > */ > +static bool copy_data(struct prb_data_ring *data_ring, > + struct prb_data_blk_lpos *blk_lpos, u16 len, char *buf, > + unsigned int

Re: [RFC PATCH v5 1/3] printk-rb: new printk ringbuffer implementation (writer)

On (19/11/28 02:58), John Ogness wrote: [..] > + > +#define _DATA_SIZE(sz_bits) (1UL << (sz_bits)) > +#define _DESCS_COUNT(ct_bits)(1U << (ct_bits)) > +#define DESC_SV_BITS (sizeof(int) * 8) > +#define DESC_COMMITTED_MASK (1U << (DESC_SV_BITS - 1))

Re: [RFC PATCH v5 1/3] printk-rb: new printk ringbuffer implementation (writer)

On (19/12/02 17:37), 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) > >> > +{ > >> > +struct prb_desc_ring *desc_ring =

Re: [PATCH V2] print kdump kernel loaded status in stack dump

m> Looks OK to me. Reviewed-by: Sergey Senozhatsky <sergey.senozhat...@gmail.com> I agree with Steven, would be better to move the whole thing to lib/dump_stack.c -ss ___ kexec mailing list kexec@lists.infradead.org http://lists.inf

Re: [PATCH] print kdump kernel loaded status in stack dump

On (01/19/18 16:42), Dave Young wrote: [..] > > [I'm not entirely sure I see why do we have printk_delay() in > >vprintk_emit()... I mean I probably can see some reasoning behind > >it, but at the same it makes sense to slow down console_unlock() > >as well] > > Looks like I am the

Re: [PATCH] print kdump kernel loaded status in stack dump

On (01/19/18 16:16), Dave Young wrote: > I thought about adding an option to improve printk_delay so it can > delay every n lines, eg. 25 rows. Maybe that idea works for this > issue? /* sent the message too soon */ printk_delay() has no effect there. it limits only printk()->vprintk_emit() and

Re: [PATCH] print kdump kernel loaded status in stack dump

On (01/19/18 16:16), Dave Young wrote: > On 01/19/18 at 02:45pm, Sergey Senozhatsky wrote: > > On (01/18/18 10:02), Andi Kleen wrote: > > > Dave Young <dyo...@redhat.com> writes: > > > > printk("%sHardware name: %s\n

Re: [PATCH] print kdump kernel loaded status in stack dump

On (01/18/18 10:02), Andi Kleen wrote: > Dave Young writes: > > printk("%sHardware name: %s\n", > >log_lvl, dump_stack_arch_desc_str); > > + if (kexec_crash_loaded()) > > + printk("%skdump kernel loaded\n", log_lvl); > >