On Thu, 11 Oct 2018 19:20:34 +0900
Tetsuo Handa wrote:
> Thus, here is v4.
>
> >From a65f018d563928c7b7e4a9bec1d1a564dd8b4635 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Thu, 11 Oct 2018 14:21:22 +0900
> Subject: [PATCH v4] printk: Add line-buffered printk() API.
Hi Tetsuo,
Can yo
On 2018/10/10 19:14, Tetsuo Handa wrote:
> On 2018/10/10 6:19, Tetsuo Handa wrote:
>> Do you think that adding cmpxchg() & retry logic to this API generates better
>> result than simple fallback? buffered_printk() does not add a new locking
>> dependency
>> is a good point of this API. Showing the
On 2018/10/10 6:19, Tetsuo Handa wrote:
> Do you think that adding cmpxchg() & retry logic to this API generates better
> result than simple fallback? buffered_printk() does not add a new locking
> dependency
> is a good point of this API. Showing the backtrace (by enabling a debug
> kernel confi
On 2018/10/09 23:52, Petr Mladek wrote:
> On Tue 2018-10-09 05:48:33, Tetsuo Handa wrote:
>> On 2018/10/09 1:03, Petr Mladek wrote:
>>> On Mon 2018-10-08 19:31:58, Tetsuo Handa wrote:
A structure named "struct printk_buffer" is introduced for buffering
up to LOG_LINE_MAX bytes of prin
On Tue 2018-10-09 05:48:33, Tetsuo Handa wrote:
> On 2018/10/09 1:03, Petr Mladek wrote:
> > On Mon 2018-10-08 19:31:58, Tetsuo Handa wrote:
> >> A structure named "struct printk_buffer" is introduced for buffering
> >> up to LOG_LINE_MAX bytes of printk() output which did not end with '\n'.
>
On 2018/10/09 1:03, Petr Mladek wrote:
> On Mon 2018-10-08 19:31:58, Tetsuo Handa wrote:
>> A structure named "struct printk_buffer" is introduced for buffering
>> up to LOG_LINE_MAX bytes of printk() output which did not end with '\n'.
>>
>> A caller is allowed to allocate/free "struct print
On Mon 2018-10-08 19:31:58, Tetsuo Handa wrote:
> On 2018/10/02 15:38, Sergey Senozhatsky wrote:
> > I have sketched a very silly, quick-and-dirty implementation using
> > struct cont. It derives all the good features of the existing pr_cont.
> > I didn't spend enough time on this. It's just a sket
On Tue 2018-10-02 15:38:51, Sergey Senozhatsky wrote:
> On (10/01/18 20:21), Tetsuo Handa wrote:
> > Maybe "struct printk_buffer" after all becomes identical to "struct cont".
> > But
> > I guess that even 16 printk_buffer-s is practically sufficient for 1024 CPUs
> > system, and allocating NR_CPU
On 2018/10/02 15:38, Sergey Senozhatsky wrote:
> I have sketched a very silly, quick-and-dirty implementation using
> struct cont. It derives all the good features of the existing pr_cont.
> I didn't spend enough time on this. It's just a sketch... which compiles
> and that's it.
Sergey and I had
On (10/01/18 20:21), Tetsuo Handa wrote:
> >> Because there is no guarantee that memory information is dumped under the
> >> oom_lock mutex. The oom_lock is held when calling out_of_memory(), and it
> >> cannot be held when reporting GFP_ATOMIC memory allocation failures.
> >
> > IOW, static pr_li
On Sat, 29 Sep 2018 20:13:17 +0900
Sergey Senozhatsky wrote:
> On (09/28/18 20:21), Tetsuo Handa wrote:
> > On 2018/09/28 17:56, Sergey Senozhatsky wrote:
> > > The good thing about cont buffer is that we flush it on panic. E.g.
> > > core/arch early boot stage can do:
> > >
> > > pr_cont("g
On 2018/10/01 11:37, Sergey Senozhatsky wrote:
> On (09/29/18 20:15), Tetsuo Handa wrote:
>>
>> Because there is no guarantee that memory information is dumped under the
>> oom_lock mutex. The oom_lock is held when calling out_of_memory(), and it
>> cannot be held when reporting GFP_ATOMIC memory a
On (10/01/18 14:52), Sergey Senozhatsky wrote:
> On (09/29/18 20:13), Sergey Senozhatsky wrote:
> > We used to flush "incomplete" cont lines (fragments) from console_unlock().
> >
> > void console_unlock(void)
> > {
> > ...
> > /* flush buffered message fragment immediately to console */
>
On (09/29/18 20:13), Sergey Senozhatsky wrote:
> We used to flush "incomplete" cont lines (fragments) from console_unlock().
>
> void console_unlock(void)
> {
> ...
> /* flush buffered message fragment immediately to console */
> console_cont_flush(text, sizeof(text));
> again:
>
On (10/01/18 11:37), Sergey Senozhatsky wrote:
> If we are about to have a list of printk buffers then we probably can
> define a list of NR_CPUS cont buffers. And we probably can reuse the
> existing struct cont for buffered printk, having 2 different struct-s
> for the same thing - struct cont an
On (09/29/18 20:15), Tetsuo Handa wrote:
>
> Because there is no guarantee that memory information is dumped under the
> oom_lock mutex. The oom_lock is held when calling out_of_memory(), and it
> cannot be held when reporting GFP_ATOMIC memory allocation failures.
IOW, static pr_line buffer need
On 2018/09/29 20:13, Sergey Senozhatsky wrote:
> On (09/28/18 20:21), Tetsuo Handa wrote:
>> On 2018/09/28 17:56, Sergey Senozhatsky wrote:
>>> The good thing about cont buffer is that we flush it on panic. E.g.
>>> core/arch early boot stage can do:
>>>
>>> pr_cont("going to call early_init_fo
On 2018/09/29 19:51, Sergey Senozhatsky wrote:
> On (09/28/18 20:01), Tetsuo Handa wrote:
>>> Yes, this makes sense. At the same time we can keep pr_line buffer
>>> in .bss
>>>
>>> static char buffer[1024];
>>> static DEFINE_PR_LINE_BUF(..., buffer);
>>>
>>> just like you have already menti
On (09/28/18 20:21), Tetsuo Handa wrote:
> On 2018/09/28 17:56, Sergey Senozhatsky wrote:
> > The good thing about cont buffer is that we flush it on panic. E.g.
> > core/arch early boot stage can do:
> >
> > pr_cont("going to call early_init_foo()...");
> > early_init_foo();
> > pr_co
On (09/28/18 20:01), Tetsuo Handa wrote:
> > Yes, this makes sense. At the same time we can keep pr_line buffer
> > in .bss
> >
> > static char buffer[1024];
> > static DEFINE_PR_LINE_BUF(..., buffer);
> >
> > just like you have already mentioned. But that's going to require a
> > case-by
On 2018/09/28 17:56, Sergey Senozhatsky wrote:
> The good thing about cont buffer is that we flush it on panic. E.g.
> core/arch early boot stage can do:
>
> pr_cont("going to call early_init_foo()...");
> early_init_foo();
> pr_cont("OK\n");
>
Is printing
going to call earl
On 2018/09/28 18:09, Sergey Senozhatsky wrote:
> On (09/24/18 17:11), Tetsuo Handa wrote:
>> The reason of using statically preallocated global buffers is that I think
>> that it is inconvenient for KERN_CONT users to calculate necessary bytes
>> only for avoiding message truncation. The pr_line mi
On (09/24/18 17:11), Tetsuo Handa wrote:
> The reason of using statically preallocated global buffers is that I think
> that it is inconvenient for KERN_CONT users to calculate necessary bytes
> only for avoiding message truncation. The pr_line might be passed to deep
> into the callchain and adjus
On (09/28/18 01:10), Tetsuo Handa wrote:
>
> Therefore, I think that "Either we need to require synchronization - umm...
> and
> document it - or to provide some means of synchronization in pr_line()." is a
> pointless worry. It is only existing printk() API which needs
> synchronization. I
> th
On (09/19/18 20:02), Tetsuo Handa wrote:
> I'm inclined to propose a simple one shown below, similar to just having
> several "struct cont" for concurrent printk() users.
Tetsuo, thanks for the patch.
> What Linus has commented is that implicit context is bad, and below one
> uses explicit contex
On 2018/09/24 17:11, Tetsuo Handa wrote:
> On 2018/09/19 20:02, Tetsuo Handa wrote:
>> On 2018/09/14 21:22, Sergey Senozhatsky wrote:
>>> The "SMP-safe" comment becomes a bit tricky when pr_line is used with a
>>> static buffer. Either we need to require synchronization - umm... and
>>> document it
On 2018/09/19 20:02, Tetsuo Handa wrote:
> On 2018/09/14 21:22, Sergey Senozhatsky wrote:
>> The "SMP-safe" comment becomes a bit tricky when pr_line is used with a
>> static buffer. Either we need to require synchronization - umm... and
>> document it - or to provide some means of synchronization
On 2018/09/14 21:22, Sergey Senozhatsky wrote:
> The "SMP-safe" comment becomes a bit tricky when pr_line is used with a
> static buffer. Either we need to require synchronization - umm... and
> document it - or to provide some means of synchronization in pr_line().
> Let's think what pr_line API s
On (09/14/18 21:03), Tetsuo Handa wrote:
> > 80 bytes is quite short for OOM, agreed.
> >
> >> static char oom_print_buf[1024];
> >> DEFINE_PR_LINE_BUF(level, oom_print_buf);
> >
> > Do I get it right that you suggest to drop the "size" param?
>
> No. I just forgot to add params. ;-)
>
> >
On 2018/09/14 20:50, Sergey Senozhatsky wrote:
>>> +#define DEFINE_PR_LINE_BUF(lev, name, buf, sz) \
>>> + struct pr_line name = {\
>>> + .sb = __SEQ_BUF_INITIALIZER(buf, (sz)), \
>>> + .level = lev,
On (09/14/18 19:37), Tetsuo Handa wrote:
> > @@ -20,6 +20,9 @@
> > * Annotation for a "continued" line of log printout (only done after a
> > * line that had no enclosing \n). Only to be used by core/arch code
> > * during early bootup (a continued line is not SMP-safe otherwise).
> > + *
> >
On 2018/09/14 15:57, Sergey Senozhatsky wrote:
> On (09/13/18 23:28), Sergey Senozhatsky wrote:
>> Not that I see any problems with pr_line_flush(). But can drop it, sure.
>> pr_line() is a replacement for pr_cont() and as such it's not for multi-line
>> buffering.
>
> OK, attached.
> Let me know
On (09/13/18 23:28), Sergey Senozhatsky wrote:
> Not that I see any problems with pr_line_flush(). But can drop it, sure.
> pr_line() is a replacement for pr_cont() and as such it's not for multi-line
> buffering.
OK, attached.
Let me know if anything needs to improved (including broken English).
On (09/13/18 21:22), Steven Rostedt wrote:
> > Good call. It was a fast path for pr_cont("\n").
> > But it made me wondering and I did some grepping
> >
>
> [..]
>
> > kernel/trace/ftrace.c: pr_cont("\n expected tramp: %lx\n", ip);
>
> Note, looking at the history of that, I was just c
On (09/13/18 21:12), Steven Rostedt wrote:
> >
> > +#define __SEQ_BUF_INITIALIZER(buf, length) {
> > \
> > + .buffer = (buf),\
> > + .size = (length), \
> > + .len
On Thu, 13 Sep 2018 23:28:02 +0900
Sergey Senozhatsky wrote:
> Good call. It was a fast path for pr_cont("\n").
> But it made me wondering and I did some grepping
>
[..]
> kernel/trace/ftrace.c: pr_cont("\n expected tramp: %lx\n", ip);
Note, looking at the history of that, I was just
On Thu, 13 Sep 2018 16:12:54 +0900
Sergey Senozhatsky wrote:
Signed-off-by: Sergey Senozhatsky
> ---
> include/linux/seq_buf.h | 35 +++
> lib/seq_buf.c | 46 +
> 2 files changed, 81 insertions(+)
>
> diff --git a/inc
On (09/13/18 14:26), Petr Mladek wrote:
> > +
> > +int vpr_line(struct pr_line *pl, const char *fmt, va_list args)
> > +{
> > + struct seq_buf *s = &pl->sb;
> > + int ret, len;
> > +
> > + if (fmt[0] == '\n') {
> > + pr_line_flush(pl);
> > + return 0;
> > + }
>
> You wo
On Thu 2018-09-13 16:12:54, Sergey Senozhatsky wrote:
> On (09/12/18 12:05), Steven Rostedt wrote:
> > > : Introduce a few helper functions for it:
> > > :
> > > : init_line_buffer(&buf);
> > > : print_line(&buf, fmt, args);
> > > : vprint_line(&buf, fmt, vararg);
> > > : finish_line(&buf);
>
Hi, Steven
On (09/12/18 12:05), Steven Rostedt wrote:
> > : Introduce a few helper functions for it:
> > :
> > : init_line_buffer(&buf);
> > : print_line(&buf, fmt, args);
> > : vprint_line(&buf, fmt, vararg);
> > : finish_line(&buf);
> > :
>
> This sounds like seq_buf to me.
Correct.
> >
On Wed, 12 Sep 2018 15:53:07 +0900
Sergey Senozhatsky wrote:
> I scanned some of Linus' emails, and skimmed through previous discussions
> on this topic. Let me quote Linus:
>
> :
> : My preference as a user is actually to just have a dynamically
> : re-sizable buffer (that's pretty much what I
On (09/10/18 13:20), Alexander Potapenko wrote:
> > Awesome. If you and Fengguang can combine forces and lead the
> > whole thing towards "we couldn't care of pr_cont() less", it
> > would be really huge. Go for it!
>
> Sorry, folks, am I understanding right that pr_cont() and flushing the
> b
On Wed, Jun 20, 2018 at 3:06 PM Sergey Senozhatsky
wrote:
>
> On (06/20/18 13:32), Dmitry Vyukov wrote:
> > > So, if we could get rid of pr_cont() from the most important parts
> > > (instruction dumps, etc) then I would just vote to leave pr_cont()
> > > alone and avoid any handling of it in prin
On 2018/06/25 18:36, Dmitry Vyukov wrote:
> On Mon, Jun 25, 2018 at 3:41 AM, Sergey Senozhatsky
> wrote:
>> On (06/22/18 22:06), Tetsuo Handa wrote:
Awesome. If you and Fengguang can combine forces and lead the
whole thing towards "we couldn't care of pr_cont() less", it
would
On Mon, Jun 25, 2018 at 3:41 AM, Sergey Senozhatsky
wrote:
> On (06/22/18 22:06), Tetsuo Handa wrote:
>> >
>> > Awesome. If you and Fengguang can combine forces and lead the
>> > whole thing towards "we couldn't care of pr_cont() less", it
>> > would be really huge. Go for it!
>>
>> Can't we h
On (06/22/18 22:06), Tetsuo Handa wrote:
> >
> > Awesome. If you and Fengguang can combine forces and lead the
> > whole thing towards "we couldn't care of pr_cont() less", it
> > would be really huge. Go for it!
>
> Can't we have seq_printf()-like one which flushes automatically upon seeing
On 2018/06/20 22:06, Sergey Senozhatsky wrote:
> On (06/20/18 13:32), Dmitry Vyukov wrote:
>>> So, if we could get rid of pr_cont() from the most important parts
>>> (instruction dumps, etc) then I would just vote to leave pr_cont()
>>> alone and avoid any handling of it in printk context tracking.
On (06/20/18 13:32), Dmitry Vyukov wrote:
> >>
> >> So this is another reason to get rid of pr_cont entirely, right?
> >
> > Getting rid of pr_cont() from important output would be totally cool.
> > Quoting Linus:
> >
> > Only acceptable use of continuations is basically boot-time testing,
> >
On (06/20/18 13:32), Dmitry Vyukov wrote:
> > So, if we could get rid of pr_cont() from the most important parts
> > (instruction dumps, etc) then I would just vote to leave pr_cont()
> > alone and avoid any handling of it in printk context tracking. Simply
> > because we wouldn't care about pr_con
On Wed, Jun 20, 2018 at 02:45:25PM +0200, Dmitry Vyukov wrote:
On Wed, Jun 20, 2018 at 2:41 PM, Fengguang Wu wrote:
On Wed, Jun 20, 2018 at 02:31:51PM +0200, Dmitry Vyukov wrote:
On Wed, Jun 20, 2018 at 1:37 PM, Fengguang Wu
wrote:
On Wed, Jun 20, 2018 at 11:30:05AM +0200, Dmitry Vyukov wr
On Wed, Jun 20, 2018 at 2:41 PM, Fengguang Wu wrote:
> On Wed, Jun 20, 2018 at 02:31:51PM +0200, Dmitry Vyukov wrote:
>>
>> On Wed, Jun 20, 2018 at 1:37 PM, Fengguang Wu
>> wrote:
>>>
>>> On Wed, Jun 20, 2018 at 11:30:05AM +0200, Dmitry Vyukov wrote:
On Wed, Jun 20, 2018 at 11:06 A
On Wed, Jun 20, 2018 at 02:31:51PM +0200, Dmitry Vyukov wrote:
On Wed, Jun 20, 2018 at 1:37 PM, Fengguang Wu wrote:
On Wed, Jun 20, 2018 at 11:30:05AM +0200, Dmitry Vyukov wrote:
On Wed, Jun 20, 2018 at 11:06 AM, Sergey Senozhatsky
wrote:
Hi Dmitry,
On (06/20/18 10:45), Dmitry Vyukov wrot
On Wed, Jun 20, 2018 at 1:37 PM, Fengguang Wu wrote:
> On Wed, Jun 20, 2018 at 11:30:05AM +0200, Dmitry Vyukov wrote:
>>
>> On Wed, Jun 20, 2018 at 11:06 AM, Sergey Senozhatsky
>> wrote:
>>>
>>> Hi Dmitry,
>>>
>>> On (06/20/18 10:45), Dmitry Vyukov wrote:
Hi Sergey,
What are t
On Wed, Jun 20, 2018 at 11:30:05AM +0200, Dmitry Vyukov wrote:
On Wed, Jun 20, 2018 at 11:06 AM, Sergey Senozhatsky
wrote:
Hi Dmitry,
On (06/20/18 10:45), Dmitry Vyukov wrote:
Hi Sergey,
What are the visible differences between this patch and Tetsuo's
patch?
I guess none, and looking at yo
On Wed, Jun 20, 2018 at 1:07 PM, Sergey Senozhatsky
wrote:
> On (06/20/18 11:31), Dmitry Vyukov wrote:
>> > BTW, pr_cont() handling is not so simple when we are in printk_safe()
>> > context. Unlike vprintk_emit() [normal printk], we don't use any
>> > dedicated pr_cont() buffer in printk_safe. So
On Wed, Jun 20, 2018 at 1:19 PM, Sergey Senozhatsky
wrote:
> On (06/20/18 11:30), Dmitry Vyukov wrote:
>>
>> https://gist.githubusercontent.com/dvyukov/1528e86e5139f2fd1bf9902398d48298/raw/3b42148554eefed210f1e626d5befd50405c5487/gistfile1.txt
>> https://gist.githubusercontent.com/dvyukov/6e08ac52
On (06/20/18 11:30), Dmitry Vyukov wrote:
>
> https://gist.githubusercontent.com/dvyukov/1528e86e5139f2fd1bf9902398d48298/raw/3b42148554eefed210f1e626d5befd50405c5487/gistfile1.txt
> https://gist.githubusercontent.com/dvyukov/6e08ac521f3e19534970ed97aeee1603/raw/0f0bb361902de94e7ee331ac500a3ceebf8
On (06/20/18 11:31), Dmitry Vyukov wrote:
> > BTW, pr_cont() handling is not so simple when we are in printk_safe()
> > context. Unlike vprintk_emit() [normal printk], we don't use any
> > dedicated pr_cont() buffer in printk_safe. So, at a glance, I suspect
> > that injecting context info at every
On Wed, Jun 20, 2018 at 11:18 AM, Sergey Senozhatsky
wrote:
> On (06/20/18 18:06), Sergey Senozhatsky wrote:
>>
>> b) printk_safe output is quite uncommon. And we flush per-CPU buffer
>>from the same CPU which has caused printk_safe output [except for
>>panic() flush] therefore logging the
On Wed, Jun 20, 2018 at 11:06 AM, Sergey Senozhatsky
wrote:
> Hi Dmitry,
>
> On (06/20/18 10:45), Dmitry Vyukov wrote:
>> Hi Sergey,
>>
>> What are the visible differences between this patch and Tetsuo's
>> patch?
>
> I guess none, and looking at your requirements below I tend to agree
> that Tets
On (06/20/18 18:06), Sergey Senozhatsky wrote:
>
> b) printk_safe output is quite uncommon. And we flush per-CPU buffer
>from the same CPU which has caused printk_safe output [except for
>panic() flush] therefore logging the info available to log_store()
>seemed enough. IOW, once again
Hi Dmitry,
On (06/20/18 10:45), Dmitry Vyukov wrote:
> Hi Sergey,
>
> What are the visible differences between this patch and Tetsuo's
> patch?
I guess none, and looking at your requirements below I tend to agree
that Tetsuo's approach is probably what you need at the end of the day.
> The only
On Wed, Jun 20, 2018 at 10:31 AM, Sergey Senozhatsky
wrote:
> On (06/20/18 07:44), Dmitry Vyukov wrote:
>> BUG: unable to handle kernel NULL pointer dereference at
>> sysfs: cannot create duplicate filename '/class/ieee80211/!'
>> PGD 1cae7e067 P4D 1cae7e067 PUD 1b4da6067 PMD 0
>>
On (06/20/18 07:44), Dmitry Vyukov wrote:
> BUG: unable to handle kernel NULL pointer dereference at
> sysfs: cannot create duplicate filename '/class/ieee80211/!'
> PGD 1cae7e067 P4D 1cae7e067 PUD 1b4da6067 PMD 0
> Oops: 0010 [#1] SMP KASAN
> CPU: 1 PID: 1728 Comm: syz-executor4 N
On Sat, May 26, 2018 at 8:36 AM, Dmitry Vyukov wrote:
> On Thu, May 24, 2018 at 4:14 AM, Sergey Senozhatsky
> wrote:
>>> First, we should ask what we expect from this feature.
>>
>> Yeah. Can't really comment on this, it's up to Tetsuo and Dmitry to
>> decide. So far I've seen slightly different
On Thu, May 24, 2018 at 4:14 AM, Sergey Senozhatsky
wrote:
>> First, we should ask what we expect from this feature.
>
> Yeah. Can't really comment on this, it's up to Tetsuo and Dmitry to
> decide. So far I've seen slightly different requirements/expectations.
The root problem is that it's not p
On (05/18/18 15:08), Dmitry Vyukov wrote:
[..]
> >> What consoles do support it?
> >> We are interested at least in qemu console, GCE console and Android
> >> phone consoles. But it would be pity if this can't be used on various
> >> development boards too.
> >
> > Only the netconsole is able to sh
On (05/18/18 14:15), Petr Mladek wrote:
> > Dunno...
> > For instance, can we store context tracking info as a extended record
> > data? We have that dict/dict_len thing. So may we can store tracking
> > info there? Extended records will appear on the serial console /* if
> > console supports exten
Sergey Senozhatsky wrote:
> On (05/17/18 20:21), Sergey Senozhatsky wrote:
> > Dunno...
> > For instance, can we store context tracking info as a extended record
> > data? We have that dict/dict_len thing. So may we can store tracking
> > info there? Extended records will appear on the serial conso
On Fri, May 18, 2018 at 2:54 PM, Petr Mladek wrote:
> On Fri 2018-05-18 14:25:57, Dmitry Vyukov wrote:
>> > On Thu 2018-05-17 20:21:35, Sergey Senozhatsky wrote:
>> >> Dunno...
>> >> For instance, can we store context tracking info as a extended record
>> >> data? We have that dict/dict_len thing.
On Fri 2018-05-18 14:25:57, Dmitry Vyukov wrote:
> > On Thu 2018-05-17 20:21:35, Sergey Senozhatsky wrote:
> >> Dunno...
> >> For instance, can we store context tracking info as a extended record
> >> data? We have that dict/dict_len thing. So may we can store tracking
> >> info there? Extended rec
On Fri, May 18, 2018 at 2:15 PM, Petr Mladek wrote:
> On Thu 2018-05-17 20:21:35, Sergey Senozhatsky wrote:
>> On (05/11/18 20:58), Tetsuo Handa wrote:
>> > @@ -1820,6 +1860,9 @@ static size_t log_output(int facility, int level,
>> > enum log_flags lflags, const c
>> > return
On Thu 2018-05-17 20:21:35, Sergey Senozhatsky wrote:
> On (05/11/18 20:58), Tetsuo Handa wrote:
> > @@ -1820,6 +1860,9 @@ static size_t log_output(int facility, int level,
> > enum log_flags lflags, const c
> > return text_len;
> > }
> >
> > + /* Inject caller info. */
On (05/17/18 20:21), Sergey Senozhatsky wrote:
> Dunno...
> For instance, can we store context tracking info as a extended record
> data? We have that dict/dict_len thing. So may we can store tracking
> info there? Extended records will appear on the serial console /* if
> console supports extended
On (05/11/18 20:58), Tetsuo Handa wrote:
[..]
> - if (nr_ext_console_drivers || cont.len + len > sizeof(cont.buf)) {
> + if (nr_ext_console_drivers) {
> + cont_flush();
> + return false;
> + }
> +
> + /* Inject before memcpy() in order to avoid overflow. */
>
>From b7b0e56e06db1107f781b4cb5178fbdc99240901 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Fri, 11 May 2018 20:45:31 +0900
Subject: [PATCH] printk: inject caller information into the body of message
Since syzbot frequently makes printk() flooding (e.g. memory allocation
fault inject
76 matches
Mail list logo
