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 good to continue to do that.
> >
> > OK, so
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()".
>
> I think it's really preempt_count()
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()".
I think it's really preempt_count() that we want to have there.
That has the
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 good to continue to do that.
>
> OK, so basically, extending printk_caller_id() so that for IRQ/NMI
>
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
On Mon, 2020-07-20 at 11:30 -0700, Linus Torvalds wrote:
> On Sun, Jul 19, 2020 at 6:51 PM Sergey Senozhatsky
> 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,
On Sun, Jul 19, 2020 at 6:51 PM Sergey Senozhatsky
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
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 either IRQ or NMI context would be a bug.
>
> You
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 either IRQ or NMI context would be a bug.
You can't validly have a PR_CONT without the non-cont that precedes
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
> ---
Instead of buffering continuous line parts before storing the full
line into the ringbuffer, store each part as its own record.
Signed-off-by: John Ogness
---
kernel/printk/printk.c | 114 -
1 file changed, 11 insertions(+), 103 deletions(-)
diff --git
11 matches
Mail list logo
