Re: String literals in __init functions

[Andrew Morton]

On Thu, 26 Mar 2015 14:58:40 -0700 Joe Perches  wrote:

> > I'd have thought that a function-wide
> > __attribute__((__string_section__(foo))
> > wouldn't be a ton of work to implement.
> 
> Maybe not.
> 
> Could some future version of gcc move string constants
> in a function to a specific section marked in a manner
> similar to what Andrew described above?

One thing which might complexicate this is

void foo()
{
p("bar");
}

void  __attribute__((__string_section__(.init.rodata)) zot()
{
p("bar");
}

It would be silly to create two instances of "bar".

Change it thusly:


#define __mark_str(str) \
({ static const char var[] __attribute__((__section__(".init.string"))) 
= str; var; })

void foo()
{
p("bar");
}

void zot()
{
p(__mark_str("bar"));
}


and we indeed get two copies of "bar".

It would be nice not to do that, but I guess that losing this
optimization is a reasonable compromise.

Re: cc1plus invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0

[Andrew Morton]

On Mon, 2 Nov 2009 13:29:29 -0800 Justin Mattock  
wrote:

> Hello,
> I'm not sure how to handle this,
> while compiling firefox-3.6b1.source
> I get this with the default compiling options,
> as well as custom:
> 
> ...
>
> active_anon:2360492kB inactive_anon:590196kB active_file:84kB

2.8GB of anonymous memory

> [  532.942508] Free swap  = 0kB
> [  532.942510] Total swap = 431632kB

430MB of swap, all used up.

That's a genuine OOM.  Something (presumably cc1plus) has consumed
wy too much memory, quite possibly leaked it.

It would help if the oom-killer were to print some information about
the oom-killed process's memory footprint.

Re: cc1plus invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0

[Andrew Morton]

On Wed,  4 Nov 2009 18:32:16 +0900 (JST) KOSAKI Motohiro 
 wrote:

> > It would help if the oom-killer were to print some information about
> > the oom-killed process's memory footprint.
> > 
> 
> 
> How about this?

looks good, thanks.

> 
> Subject: [PATCH] oom: show vsz and rss information of the killed process
> 
> In typical oom anylysis scenario, we frequently want to know the killed
> process has memory leak or not at first step.
> This patch add vsz and rss information to oom log for helping its
> analysis. It save much times of debugging guys.
> 
> example:
> ===
> rsyslogd invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
> Pid: 1308, comm: rsyslogd Not tainted 2.6.32-rc6 #24
> Call Trace:
> [] ?_spin_unlock+0x2b/0x40
> [] oom_kill_process+0xbe/0x2b0
> 
> (snip)
> 
> 492283 pages non-shared
> Out of memory: kill process 2341 (memhog) score 527276 or a child
> Killed process 2341 (memhog) vsz:1054552kB, anon-rss:970588kB, file-rss:4kB
> ===
>  ^
>  |
> here
> ...
>
> + if (verbose) {
> + task_lock(p);

We need to be careful with which locks we take on the oom-killer path,
because it can be called by code which already holds locks.  But I
expect task_lock() will be OK.

> + printk(KERN_ERR "Killed process %d (%s) "
> +"vsz:%lukB, anon-rss:%lukB, file-rss:%lukB\n",
> +task_pid_nr(p), p->comm,
> +K(p->mm->total_vm),
> +K(get_mm_counter(p->mm, anon_rss)),
> +K(get_mm_counter(p->mm, file_rss)));
> + task_unlock(p);
> + }

Re: [PATCH] panic: suppress gnu_printf warning

[Andrew Morton]

On Sun,  7 Jan 2024 17:16:41 +0800 Baoquan He  wrote:

> with GCC 13.2.1 and W=1, there's compiling warning like this:
> 
> kernel/panic.c: In function ‘__warn’:
> kernel/panic.c:676:17: warning: function ‘__warn’ might be a candidate for 
> ‘gnu_printf’ format attribute [-Wsuggest-attribute=format]
>   676 | vprintk(args->fmt, args->args);
>   | ^~~
> 
> The normal __printf(x,y) adding can't fix it. So add workaround which
> disables -Wsuggest-attribute=format to mute it.
> 
> ...
>
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -666,8 +666,13 @@ void __warn(const char *file, int line, void *caller, 
> unsigned taint,
>   pr_warn("WARNING: CPU: %d PID: %d at %pS\n",
>   raw_smp_processor_id(), current->pid, caller);
>  
> +#pragma GCC diagnostic push
> +#ifndef __clang__
> +#pragma GCC diagnostic ignored "-Wsuggest-attribute=format"
> +#endif
>   if (args)
>   vprintk(args->fmt, args->args);
> +#pragma GCC diagnostic pop
>  
>   print_modules();

__warn() clearly isn't such a candidate.  I'm suspecting that gcc's
implementation of this warning is pretty crude.  Is it a new thing in
gcc-13.2?  

A bit of context for gcc@gcc.gnu.org:

struct warn_args {
const char *fmt;
va_list args;
};

...

void __warn(const char *file, int line, void *caller, unsigned taint,
struct pt_regs *regs, struct warn_args *args)
{
disable_trace_on_warning();

if (file)
pr_warn("WARNING: CPU: %d PID: %d at %s:%d %pS\n",
raw_smp_processor_id(), current->pid, file, line,
caller);
else
pr_warn("WARNING: CPU: %d PID: %d at %pS\n",
raw_smp_processor_id(), current->pid, caller);

if (args)
vprintk(args->fmt, args->args);

print_modules();

if (regs)
show_regs(regs);

check_panic_on_warn("kernel");

if (!regs)
dump_stack();

print_irqtrace_events(current);

print_oops_end_marker();
trace_error_report_end(ERROR_DETECTOR_WARN, (unsigned long)caller);

/* Just a warning, don't kill lockdep. */
add_taint(taint, LOCKDEP_STILL_OK);
}