Re: [PATCH v2 25/44] printk: Remove trace_.*_rcuidle() usage

the case. > > Signed-off-by: Peter Zijlstra (Intel) > Reviewed-by: Sergey Senozhatsky > Acked-by: Petr Mladek Acked-by: Sergey Senozhatsky ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH 24/36] printk: Remove trace_.*_rcuidle() usage

On Thu, Jun 9, 2022 at 10:02 PM Petr Mladek wrote: > > On Thu 2022-06-09 20:30:58, Sergey Senozhatsky wrote: > > My emails are getting rejected... Let me try web-interface > > Bad day for mail sending. I have problems as well ;-) For me the problem is still there and apparently

Re: [PATCH 24/36] printk: Remove trace_.*_rcuidle() usage

On Thu, Jun 9, 2022 at 10:06 PM Petr Mladek wrote: > > Makes sense. Feel free to use for this patch: > > Acked-by: Petr Mladek Reviewed-by: Sergey Senozhatsky ___ linux-snps-arc mailing list linux-snps-arc@lists.infrad

Re: [PATCH 24/36] printk: Remove trace_.*_rcuidle() usage

My emails are getting rejected... Let me try web-interface Kudos to Petr for the questions and thanks to PeterZ for the answers. On Thu, Jun 9, 2022 at 7:02 PM Peter Zijlstra wrote: > This is the tracepoint used to spool all of printk into ftrace, I > suspect there's users, but I haven't used

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

On (21/01/07 09:58), Vineet Gupta wrote: > On 1/7/21 9:04 AM, Petr Mladek wrote: > > On Thu 2021-01-07 08:43:16, Vineet Gupta wrote: > > > Hi John, > > > > > > On 1/7/21 1:02 AM, John Ogness wrote: > > > > Hi Vineet, > > > > > > > > On 2021-01-06, Vineet Gupta wrote: > > > > > This breaks ARC

Re: [PATCH 00/50] Add log level to show_stack()

On (19/11/13 10:39), Steven Rostedt wrote: [..] > > void show_stack(struct task_struct *task, unsigned long *sp, int log_level) > > { > > printk_emergency_enter(log_level); > > __show_stack(task, sp); > > printk_emergency_exit(); > > } > > // - - - - - - - - - - - - - - - - - - - - - -

Re: [PATCH 00/50] Add log level to show_stack()

On (19/11/13 16:40), Dmitry Safonov wrote: > It's also not very fun for me to create those patches. > But they fix console_loglevel issues (I hope we could un-export it in > the end) and also I need it for my other patches those will produce > warnings with debug loglevel when configured through

Re: [PATCH 00/50] Add log level to show_stack()

On (19/11/13 02:41), Dmitry Safonov wrote: [..] > > I don't strongly disagree, but if you look at those results: > git grep 'printk("%s.*", \(lvl\|level\)' > > it seems to be used in quite a few places. Yes, you are right, it is used in some places. That's why I said that I'd prefer to keep

Re: [PATCH 00/50] Add log level to show_stack()

On (19/11/12 19:12), Sergey Senozhatsky wrote: > On (19/11/12 09:35), Petr Mladek wrote: > [..] > > This is getting too complicated. It would introduce too many > > hidden rules. While the explicitly passed loglevel parameter > > is straightforward and clear. > > If

Re: [PATCH 00/50] Add log level to show_stack()

On (19/11/12 09:35), Petr Mladek wrote: [..] > This is getting too complicated. It would introduce too many > hidden rules. While the explicitly passed loglevel parameter > is straightforward and clear. If loglevel is DEFAULT or NOTICE or INFO then we can overwrite it (either downgrade or

Re: [PATCH 00/50] Add log level to show_stack()

On (19/11/12 13:44), Sergey Senozhatsky wrote: [..] > > But yes, this per-code-section loglevel is problematic. The feedback > > against the patchset shows that people want it also the other way. > > I mean to keep pr_debug() as pr_debug(). > > Hmm. Right. > >

Re: [PATCH 00/50] Add log level to show_stack()

On (19/11/11 10:12), Petr Mladek wrote: [..] > > I do recall that we talked about per-CPU printk state bit which would > > start/end "just print it" section. We probably can extend it to "just > > log_store" type of functionality. Doesn't look like a very bad idea. > > The problem with per-CPU

Re: [PATCH 00/50] Add log level to show_stack()

On (19/11/12 02:40), Dmitry Safonov wrote: [..] > In my point of view the cost of one-time [mostly build] testing every > architecture is cheaper than introducing some new smart code that will > live forever. Well, there may be the need to pass loglevel deeper due to "hey __show_stack() on that

Re: [PATCH 00/50] Add log level to show_stack()

On (19/11/11 19:47), Dmitry Safonov wrote: [..] > I don't see how bits on task_struct or in per-cpu are easier than > supplying a log level parameter down the stack. > How would it work if sysrq_handle_crash() called by key-press? > How would that interact with deferred printing? > How would it

Re: [PATCH 00/50] Add log level to show_stack()

On (19/11/08 14:04), Petr Mladek wrote: [..] > I agree that it is complicated to pass the loglevel as > a parameter. It would be better define the default > log level for a given code section. It might be stored > in task_struct for the normal context and in per-CPU > variables for interrupt

Re: [PATCH 00/50] Add log level to show_stack()

On (19/11/06 09:35), Petr Mladek wrote: > I agree with all the other justification. > > I would add. The backtrace is really useful for debugging. It should > be possible to print it even in less critical situations. Hmm, I don't know. Do we really need debug/info level backtraces? May be all

Re: [PATCH 00/13] replace print_symbol() with printk()-s

On (01/16/18 17:33), Petr Mladek wrote: [..] > > JFI, the patch is in Linus's tree as of now (d0729bc6bee797fb). > > Great. I have pushed the patch that removes printk_symbol() > into printk.git, branch for-4.16-print-symbol. > > Note that I have updated the commit message similar way > like I

Re: [PATCH 00/13] replace print_symbol() with printk()-s

On (01/05/18 15:42), Petr Mladek wrote: > > I am all for it. But I would postpone this removal to 4.17. > The reason is rather ugly. 13th patch is already in arc tree. > We would need to shuffle the patch or coordinate pull requests. JFI, the patch is in Linus's tree as of now

Re: [PATCH 00/13] replace print_symbol() with printk()-s

On (01/05/18 15:42), Petr Mladek wrote: [..] > > oh, one more thing. one extra patch, which gets rid of > > print_symbol()/__print_symbol(). > > I am all for it. But I would postpone this removal to 4.17. > The reason is rather ugly. 13th patch is already in arc tree. > We would need to shuffle

Re: [PATCH 00/13] replace print_symbol() with printk()-s

On (01/05/18 21:01), Sergey Senozhatsky wrote: [..] > but, print_symbol() is compiled out on !CONFIG_KALLSYMS systems. so, > basically, we compile out some of errors print outs; even more, on ia64 > ia64_do_show_stack() does nothing when there is no CONFIG_KALLSYMS [all > ia64 def

Re: [PATCH 00/13] replace print_symbol() with printk()-s

On (01/05/18 19:21), Sergey Senozhatsky wrote: > > print_symbol() is an old weird API. It has been > > obsoleted by printk() and %pS format specifier. > > I wouldn't. let's drop the "weird" part. hm... you are right, it is weird. and the weird part here is

Re: [PATCH 00/13] replace print_symbol() with printk()-s

On (01/05/18 19:21), Sergey Senozhatsky wrote: > On (01/05/18 11:03), Petr Mladek wrote: > [..] > > Anyway, print_symbol() is an old weird API and it would be nice > > to eventually get rid of it. I could take this patches into > > printk.git. > > no objections

Re: [PATCH 00/13] replace print_symbol() with printk()-s

On (01/05/18 11:03), Petr Mladek wrote: [..] > Anyway, print_symbol() is an old weird API and it would be nice > to eventually get rid of it. I could take this patches into > printk.git. no objections from my side if the patch set will go through the printk tree. shall we wait for ACKs or can we

Re: [PATCH 00/13] replace print_symbol() with printk()-s

On (12/11/17 19:10), Joe Perches wrote: [..] > As far as I'm concerned, as soon as there is > no longer a single user in the kernel tree, > better to delete it instead. sounds good to me. can drop it, once the series upstreamed. 8< --- From: Sergey Senozhatsky <sergey.senozh

Re: [PATCH 00/13] replace print_symbol() with printk()-s

On (12/11/17 21:50), Sergey Senozhatsky wrote: > > A rather automatic replacement of print_symbol() > with direct printk() calls. print_symbol() uses extra stack > buffer (KSYM_SYMBOL_LEN 128 bytes) and, basically, should > be identical to printk(%pS). > >

Re: [PATCH 11/13] irq debug: do not use print_symbol()

On (12/11/17 12:55), David Laight wrote: > > kernel/irq/debug.h | 8 +++- > > 1 file changed, 3 insertions(+), 5 deletions(-) > > > > diff --git a/kernel/irq/debug.h b/kernel/irq/debug.h > > index 17f05ef8f575..5766e15c1160 100644 > > --- a/kernel/irq/debug.h > > +++ b/kernel/irq/debug.h >

Re: [PATCH 00/13] replace print_symbol() with printk()-s

On (12/11/17 08:26), Joe Perches wrote: > On Mon, 2017-12-11 at 21:50 +0900, Sergey Senozhatsky wrote: > > print_symbol > > Yay. > > Just about exactly 5 years earlier... > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137121.html indeed :) ho

Re: [PATCH 08/13] x86: do not use print_symbol()

On (12/11/17 18:45), Borislav Petkov wrote: > For the mce.c bit above: > > Acked-by: Borislav Petkov thanks. -ss ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org

Re: [PATCH 13/13] arc: do not use __print_symbol()

On (12/11/17 08:28), Vineet Gupta wrote: > On 12/11/2017 04:53 AM, Sergey Senozhatsky wrote: > > __print_symbol() uses extra stack space to sprintf() symbol > > information and then to feed that buffer to printk() > > > >char buffer[KSYM_SYMBOL_LEN]; > > >

[PATCH 08/13] x86: do not use print_symbol()

print_symbol() uses extra stack space to sprintf() symbol information and then to feed that buffer to printk() char buffer[KSYM_SYMBOL_LEN]; sprint_symbol(buffer, address); printk(fmt, buffer); Replace print_symbol() with a direct printk("%pS") call. Signed-off-by: Sergey S

[PATCH 10/13] sysfs: do not use print_symbol()

print_symbol() uses extra stack space to sprintf() symbol information and then to feed that buffer to printk() char buffer[KSYM_SYMBOL_LEN]; sprint_symbol(buffer, address); printk(fmt, buffer); Replace print_symbol() with a direct printk("%pS") call. Signed-off-by: Sergey S

[PATCH 12/13] lib: do not use print_symbol()

print_symbol() uses extra stack space to sprintf() symbol information and then to feed that buffer to printk() char buffer[KSYM_SYMBOL_LEN]; sprint_symbol(buffer, address); printk(fmt, buffer); Replace print_symbol() with a direct printk("%pS") call. Signed-off-by: Sergey S

[PATCH 13/13] arc: do not use __print_symbol()

__print_symbol() uses extra stack space to sprintf() symbol information and then to feed that buffer to printk() char buffer[KSYM_SYMBOL_LEN]; sprint_symbol(buffer, address); printk(fmt, buffer); Replace __print_symbol() with a direct printk("%pS") call. Signed-off-by: Sergey S

[PATCH 11/13] irq debug: do not use print_symbol()

print_symbol() uses extra stack space to sprintf() symbol information and then to feed that buffer to printk() char buffer[KSYM_SYMBOL_LEN]; sprint_symbol(buffer, address); printk(fmt, buffer); Replace print_symbol() with a direct printk("%pS") call. Signed-off-by: Sergey S

[PATCH 09/13] drivers: do not use print_symbol()

print_symbol() uses extra stack space to sprintf() symbol information and then to feed that buffer to printk() char buffer[KSYM_SYMBOL_LEN]; sprint_symbol(buffer, address); printk(fmt, buffer); Replace print_symbol() with a direct printk("%pS") call. Signed-off-by: Sergey S

[PATCH 07/13] unicore32: do not use print_symbol()

print_symbol() uses extra stack space to sprintf() symbol information and then to feed that buffer to printk() char buffer[KSYM_SYMBOL_LEN]; sprint_symbol(buffer, address); printk(fmt, buffer); Replace print_symbol() with a direct printk("%pS") call. Signed-off-by: Sergey S

[PATCH 06/13] sh: do not use print_symbol()

print_symbol() uses extra stack space to sprintf() symbol information and then to feed that buffer to printk() char buffer[KSYM_SYMBOL_LEN]; sprint_symbol(buffer, address); printk(fmt, buffer); Replace print_symbol() with a direct printk("%pS") call. Signed-off-by: Sergey S

[PATCH 03/13] c6x: do not use print_symbol()

print_symbol() uses extra stack space to sprintf() symbol information and then to feed that buffer to printk() char buffer[KSYM_SYMBOL_LEN]; sprint_symbol(buffer, address); printk(fmt, buffer); Replace print_symbol() with a direct printk("%pS") call. Signed-off-by: Sergey S

[PATCH 04/13] ia64: do not use print_symbol()

tack() had extra buffer [128 bytes on stack], which we also can drop now. Signed-off-by: Sergey Senozhatsky <sergey.senozhat...@gmail.com> Cc: Tony Luck <tony.l...@intel.com> Cc: Fenghua Yu <fenghua...@intel.com> --- arch/ia64/kernel/process.c | 10 +++--- 1 file changed,

[PATCH 02/13] arm64: do not use print_symbol()

print_symbol() uses extra stack space to sprintf() symbol information and then to feed that buffer to printk() char buffer[KSYM_SYMBOL_LEN]; sprint_symbol(buffer, address); printk(fmt, buffer); Replace print_symbol() with a direct printk("%pS") call. Signed-off-by: Sergey S

[PATCH 01/13] arm: do not use print_symbol()

print_symbol() uses extra stack space to sprintf() symbol information and then to feed that buffer to printk() char buffer[KSYM_SYMBOL_LEN]; sprint_symbol(buffer, address); printk(fmt, buffer); Replace print_symbol() with a direct printk("%pS") call. Signed-off-by: Sergey S

[PATCH 00/13] replace print_symbol() with printk()-s

exotic arch-s. Sorry for the inconvenience. Sergey Senozhatsky (13): arm: do not use print_symbol() arm64: do not use print_symbol() c6x: do not use print_symbol() ia64: do not use print_symbol() mn10300: do not use print_symbol() sh: do not use print_symbol() unicore32: do not use