From owner-svn-src-all@freebsd.org Tue Dec 12 20:49:59 2017 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22EA3E84871; Tue, 12 Dec 2017 20:49:59 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D3844725AA; Tue, 12 Dec 2017 20:49:58 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vBCKnSmr088418; Tue, 12 Dec 2017 12:49:28 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vBCKnSoE088417; Tue, 12 Dec 2017 12:49:28 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201712122049.vBCKnSoE088417@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r326758 - in head/sys/i386: conf include In-Reply-To: <5A302C50.4000709@grosbein.net> To: Eugene Grosbein Date: Tue, 12 Dec 2017 12:49:28 -0800 (PST) CC: rgrimes@freebsd.org, Don Lewis , Alexey Dokuchaev , Konstantin Belousov , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Conrad Meyer Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 20:49:59 -0000 > 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 : > 3312 in6_proto.o : > 2232 sctp_pcb.o : ... 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