Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Dec 2017 12:49:28 -0800 (PST)
From:      "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net>
To:        Eugene Grosbein <eugen@grosbein.net>
Cc:        rgrimes@freebsd.org, Don Lewis <truckman@freebsd.org>, Alexey Dokuchaev <danfe@freebsd.org>, Konstantin Belousov <kostikbel@gmail.com>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Conrad Meyer <cem@freebsd.org>
Subject:   Re: svn commit: r326758 - in head/sys/i386: conf include
Message-ID:  <201712122049.vBCKnSoE088417@pdx.rh.CN85.dnsmgr.net>
In-Reply-To: <5A302C50.4000709@grosbein.net>

next in thread | previous in thread | raw e-mail | index | archive | help
> On 13.12.2017 00:01, Rodney W. Grimes wrote:
> 
> >> But many other parts of kernel think it's OK to allocate big arrays or
> >> structures on stack.
> > 
> > We should probably start looking for those, something someone who is
> > offerring help but doesnt know what they might be good at, but can
> > read C code.  They could be utililized t simply scan through the
> > code looking for this type of thing and bring it to the attention
> > of a area of expertise commiter.
> 
> These can be found with simple script:
> 
> cd /usr/src
> make TARGET_ARCH=i386 KERNCONF=GENERIC buildkernel
> 
> cd /usr/obj/i386.i386/home/src/sys/GENERIC
> for o in *.o
> do
>   objdump -d $o | awk -vn=$o '/sub .*,%esp/ {split ($NF,a,/[,$]/); printf "%u %s %s\n", a[2], a[2], n}'
> done | sort -rn > top.sub
> 
> head -50 top.sub | while read d h o
> do
>   objdump -d $o | fgrep -B7 "$h,%esp" | awk -vo=$o -vd=$d '/>:$/ {print d, o, $2}'
> done > top2.sub
> 
> Here is what do we get in top2.sub:
> 
> 4328 in6_proto.o <icmp6stat_sysctl>:
> 3312 in6_proto.o <ip6stat_sysctl>:
> 2232 sctp_pcb.o <sctp_load_addresses_from_init>:
...

Thank you Thank you THANK YOU!  And imp has already removed one of these.
I wonder if fxing some of these sctp*.o would lead to the removal of the complaints
about that feature filling the stack.

> ...
> 
> First column is total stack usage of kernel function (decimal),
> second is module name and third contains function name it question.

Can we get this put into a CI job?
Output anything that gets added to the list of things with a stack
usage greater than some N to an email sent.  That way new violators
get flagged quickly and can be cleaned up by the commiter, then
slowly work down this list until things are stable again.

-- 
Rod Grimes                                                 rgrimes@freebsd.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201712122049.vBCKnSoE088417>