Re: kernel stack usage
On 04.07.2020 15:51, Jaromír Doleček wrote: > Le sam. 4 juil. 2020 à 15:30, Kamil Rytarowski a écrit : >>> Kamil - what's the difference in gcc between -Wframe-larger-than= and >>> -Wstack-size= ? >>> >> >> -Wstack-size doesn't exist? > > Sorry, meant -Wstack-usage= > It looks like WStack-usage is GCC specific (absent in Clang) and it includes alloca + vla. Both are not welcome in the kernel anyway so both should give in most cases the same result. >>> I see according to gcc documentation -Wframe-larger-than doesn't count >>> size for alloca() and variable-length arrays, which makes it much less >>> useful than -Wstack-usage. >>> >> >> It's not a problem. >> >> Whenever alloca or VLA is in use, it's already breaking the stack >> protector. There are a few exceptions registered in sys/conf/ssp.mk. >> >> We could add -Walloca -Wvla for USE_SSP=yes builds to catch quickly >> inappropriate usage (frequently violated by code optimizer). > > It's already not used in our kernel code, I checked and I found it > used only in some arch-specific stand/ code. So -Walloca should be > safe to turn on unconditionally, regardless of SSP. Unless the > compiler emits alloca() calls itself. > Sounds good. I'm for adding -Walloca and ideally -Wvla wherever possible in the kernel. > Jaromir > signature.asc Description: OpenPGP digital signature
Re: kernel stack usage
Le sam. 4 juil. 2020 à 15:30, Kamil Rytarowski a écrit : > > Kamil - what's the difference in gcc between -Wframe-larger-than= and > > -Wstack-size= ? > > > > -Wstack-size doesn't exist? Sorry, meant -Wstack-usage= > > I see according to gcc documentation -Wframe-larger-than doesn't count > > size for alloca() and variable-length arrays, which makes it much less > > useful than -Wstack-usage. > > > > It's not a problem. > > Whenever alloca or VLA is in use, it's already breaking the stack > protector. There are a few exceptions registered in sys/conf/ssp.mk. > > We could add -Walloca -Wvla for USE_SSP=yes builds to catch quickly > inappropriate usage (frequently violated by code optimizer). It's already not used in our kernel code, I checked and I found it used only in some arch-specific stand/ code. So -Walloca should be safe to turn on unconditionally, regardless of SSP. Unless the compiler emits alloca() calls itself. Jaromir
Re: kernel stack usage
On 04.07.2020 14:00, Jaromír Doleček wrote: > Can anybody using clang please confirm kernel build with > -Wframe-larger-than=3584? > NetBSD-current from today, amd64 GENERIC builds for me. > Kamil - what's the difference in gcc between -Wframe-larger-than= and > -Wstack-size= ? > -Wstack-size doesn't exist? > I see according to gcc documentation -Wframe-larger-than doesn't count > size for alloca() and variable-length arrays, which makes it much less > useful than -Wstack-usage. > It's not a problem. Whenever alloca or VLA is in use, it's already breaking the stack protector. There are a few exceptions registered in sys/conf/ssp.mk. We could add -Walloca -Wvla for USE_SSP=yes builds to catch quickly inappropriate usage (frequently violated by code optimizer). On 04.07.2020 14:10, Martin Husemann wrote: > On Sat, Jul 04, 2020 at 02:00:04PM +0200, Jaromír Dole?ek wrote: >> Can anybody using clang please confirm kernel build with >> -Wframe-larger-than=3584? > > Side note: 3584 is inacceptably large, we need to trim it down to ~1k. > Setting it to 3584 is a good start, it can be lowered later to 1024. signature.asc Description: OpenPGP digital signature
Re: kernel stack usage
On Sat, Jul 04, 2020 at 02:00:04PM +0200, Jaromír Dole?ek wrote: > Can anybody using clang please confirm kernel build with > -Wframe-larger-than=3584? Side note: 3584 is inacceptably large, we need to trim it down to ~1k. Martin
Re: kernel stack usage
Can anybody using clang please confirm kernel build with
-Wframe-larger-than=3584?
Kamil - what's the difference in gcc between -Wframe-larger-than= and
-Wstack-size= ?
I see according to gcc documentation -Wframe-larger-than doesn't count
size for alloca() and variable-length arrays, which makes it much less
useful than -Wstack-usage.
Jaromir
Le dim. 31 mai 2020 à 16:39, Kamil Rytarowski a écrit :
>
> Can we adopt -Wframe-larger-than=1024 and mark it fatal?
>
> This option is supported by GCC and Clang.
>
> On 31.05.2020 15:55, Jaromír Doleček wrote:
> > I think it would make sense to add -Wstack-usage=X to kernel builds.
> >
> > Either 2KB or 1KB seems to be good limit, not too many offenders
> > between 1KB and 2KB so maybe worth it to use 1KB and change them.
> >
> > I'm sure there would be something similar for LLVM too.
> >
> > Jaromir
> >
> > Le dim. 31 mai 2020 à 15:39, Simon Burge a écrit :
> >>
> >> matthew green wrote:
> >>
> >>> glad to see this effort and the clean up already!
> >>>
> >>> ideally, we can break the kernel build if large stack consumers
> >>> are added to the kernel. i'd be OK with it being default on,
> >>> with of course a way to skip it, and if necessary it can have
> >>> a whitelist of "OK large users."
> >>
> >> I started to look at -fstack-usage which gives a nice MI way of getting
> >> the data instead of parsing MD objdump output, but didn't get any
> >> further than the below patch. The find(1) command referenced in the
> >> patch gives the following
> >>
> >> 1008 nfs_serv.c:2181:1:nfsrv_link
> >> 1056 procfs_linux.c:422:1:procfs_do_pid_stat
> >> 1056 vfs_subr.c:1521:1:vfs_buf_print
> >> 1072 dl_print.c:80:1:sdl_print
> >> 1104 core_elf32.c:300:1:coredump_getseghdrs_elf32
> >> 1104 core_elf32.c:300:1:coredump_getseghdrs_elf64
> >> 1104 sys_ptrace_common.c:1595:1:proc_regio
> >> 1120 subr_bufq.c:131:1:bufq_alloc
> >> 1136 db_lwp.c:64:1:db_lwp_whatis
> >> 1152 kern_ktrace.c:1269:1:ktrwrite
> >> 1168 uvm_swap.c:768:1:uvm_swap_stats.part.1
> >> 1312 nfs_serv.c:1905:1:nfsrv_rename
> >> 2112 tty_60.c:68:1:compat_60_ptmget_ioctl
> >> 2144 memmem.c:83:14:twoway_memmem
> >>
> >> Anyone else want to run with adding a bit more to this to do some build
> >> failure as mrg@ suggests and documenting for options(4)?
> >>
> >> Cheers,
> >> Simon.
> >> --
> >> Index: Makefile.kern.inc
> >> ===
> >> RCS file: /cvsroot/src/sys/conf/Makefile.kern.inc,v
> >> retrieving revision 1.270
> >> diff -d -p -u -r1.270 Makefile.kern.inc
> >> --- Makefile.kern.inc 21 May 2020 18:44:19 - 1.270
> >> +++ Makefile.kern.inc 31 May 2020 13:34:13 -
> >> @@ -104,6 +104,11 @@ CFLAGS+= -ffreestanding -fno-zero-initia
> >> CFLAGS+= ${${ACTIVE_CC} == "gcc":? -fno-delete-null-pointer-checks
> >> :}
> >> CFLAGS+= ${DEBUG} ${COPTS}
> >> AFLAGS+= -D_LOCORE -Wa,--fatal-warnings
> >> +.if defined(KERN_STACK_USAGE)
> >> +# example usage to find largest stack users in kernel compile directory:
> >> +#find . -name \*.su | xargs awk '{ printf "%6d %s\n", $2, $1 }' |
> >> sort +1n
> >> +CFLAGS+= -fstack-usage
> >> +.endif
> >>
> >> # XXX
> >> .if defined(HAVE_GCC) || defined(HAVE_LLVM)
> >> @@ -338,8 +343,8 @@ ${_s:T:R}.o: ${_s}
> >> .if !target(__CLEANKERNEL)
> >> __CLEANKERNEL: .USE
> >> ${_MKMSG} "${.TARGET}ing the kernel objects"
> >> - rm -f ${KERNELS} *.map eddep tags *.[io] *.ko *.ln [a-z]*.s vers.c
> >> \
> >> - [Ee]rrs linterrs makelinks assym.h.tmp assym.h \
> >> + rm -f ${KERNELS} *.map *.[io] *.ko *.ln [a-z]*.s *.su vers.c \
> >> + eddep tags [Ee]rrs linterrs makelinks assym.h.tmp assym.h \
> >> ${EXTRA_KERNELS} ${EXTRA_CLEAN}
> >> .endif
> >>
>
>
Re: kernel stack usage
Can we adopt -Wframe-larger-than=1024 and mark it fatal?
This option is supported by GCC and Clang.
On 31.05.2020 15:55, Jaromír Doleček wrote:
> I think it would make sense to add -Wstack-usage=X to kernel builds.
>
> Either 2KB or 1KB seems to be good limit, not too many offenders
> between 1KB and 2KB so maybe worth it to use 1KB and change them.
>
> I'm sure there would be something similar for LLVM too.
>
> Jaromir
>
> Le dim. 31 mai 2020 à 15:39, Simon Burge a écrit :
>>
>> matthew green wrote:
>>
>>> glad to see this effort and the clean up already!
>>>
>>> ideally, we can break the kernel build if large stack consumers
>>> are added to the kernel. i'd be OK with it being default on,
>>> with of course a way to skip it, and if necessary it can have
>>> a whitelist of "OK large users."
>>
>> I started to look at -fstack-usage which gives a nice MI way of getting
>> the data instead of parsing MD objdump output, but didn't get any
>> further than the below patch. The find(1) command referenced in the
>> patch gives the following
>>
>> 1008 nfs_serv.c:2181:1:nfsrv_link
>> 1056 procfs_linux.c:422:1:procfs_do_pid_stat
>> 1056 vfs_subr.c:1521:1:vfs_buf_print
>> 1072 dl_print.c:80:1:sdl_print
>> 1104 core_elf32.c:300:1:coredump_getseghdrs_elf32
>> 1104 core_elf32.c:300:1:coredump_getseghdrs_elf64
>> 1104 sys_ptrace_common.c:1595:1:proc_regio
>> 1120 subr_bufq.c:131:1:bufq_alloc
>> 1136 db_lwp.c:64:1:db_lwp_whatis
>> 1152 kern_ktrace.c:1269:1:ktrwrite
>> 1168 uvm_swap.c:768:1:uvm_swap_stats.part.1
>> 1312 nfs_serv.c:1905:1:nfsrv_rename
>> 2112 tty_60.c:68:1:compat_60_ptmget_ioctl
>> 2144 memmem.c:83:14:twoway_memmem
>>
>> Anyone else want to run with adding a bit more to this to do some build
>> failure as mrg@ suggests and documenting for options(4)?
>>
>> Cheers,
>> Simon.
>> --
>> Index: Makefile.kern.inc
>> ===
>> RCS file: /cvsroot/src/sys/conf/Makefile.kern.inc,v
>> retrieving revision 1.270
>> diff -d -p -u -r1.270 Makefile.kern.inc
>> --- Makefile.kern.inc 21 May 2020 18:44:19 - 1.270
>> +++ Makefile.kern.inc 31 May 2020 13:34:13 -
>> @@ -104,6 +104,11 @@ CFLAGS+= -ffreestanding -fno-zero-initia
>> CFLAGS+= ${${ACTIVE_CC} == "gcc":? -fno-delete-null-pointer-checks :}
>> CFLAGS+= ${DEBUG} ${COPTS}
>> AFLAGS+= -D_LOCORE -Wa,--fatal-warnings
>> +.if defined(KERN_STACK_USAGE)
>> +# example usage to find largest stack users in kernel compile directory:
>> +#find . -name \*.su | xargs awk '{ printf "%6d %s\n", $2, $1 }' | sort
>> +1n
>> +CFLAGS+= -fstack-usage
>> +.endif
>>
>> # XXX
>> .if defined(HAVE_GCC) || defined(HAVE_LLVM)
>> @@ -338,8 +343,8 @@ ${_s:T:R}.o: ${_s}
>> .if !target(__CLEANKERNEL)
>> __CLEANKERNEL: .USE
>> ${_MKMSG} "${.TARGET}ing the kernel objects"
>> - rm -f ${KERNELS} *.map eddep tags *.[io] *.ko *.ln [a-z]*.s vers.c \
>> - [Ee]rrs linterrs makelinks assym.h.tmp assym.h \
>> + rm -f ${KERNELS} *.map *.[io] *.ko *.ln [a-z]*.s *.su vers.c \
>> + eddep tags [Ee]rrs linterrs makelinks assym.h.tmp assym.h \
>> ${EXTRA_KERNELS} ${EXTRA_CLEAN}
>> .endif
>>
signature.asc
Description: OpenPGP digital signature
Re: kernel stack usage
I think it would make sense to add -Wstack-usage=X to kernel builds.
Either 2KB or 1KB seems to be good limit, not too many offenders
between 1KB and 2KB so maybe worth it to use 1KB and change them.
I'm sure there would be something similar for LLVM too.
Jaromir
Le dim. 31 mai 2020 à 15:39, Simon Burge a écrit :
>
> matthew green wrote:
>
> > glad to see this effort and the clean up already!
> >
> > ideally, we can break the kernel build if large stack consumers
> > are added to the kernel. i'd be OK with it being default on,
> > with of course a way to skip it, and if necessary it can have
> > a whitelist of "OK large users."
>
> I started to look at -fstack-usage which gives a nice MI way of getting
> the data instead of parsing MD objdump output, but didn't get any
> further than the below patch. The find(1) command referenced in the
> patch gives the following
>
> 1008 nfs_serv.c:2181:1:nfsrv_link
> 1056 procfs_linux.c:422:1:procfs_do_pid_stat
> 1056 vfs_subr.c:1521:1:vfs_buf_print
> 1072 dl_print.c:80:1:sdl_print
> 1104 core_elf32.c:300:1:coredump_getseghdrs_elf32
> 1104 core_elf32.c:300:1:coredump_getseghdrs_elf64
> 1104 sys_ptrace_common.c:1595:1:proc_regio
> 1120 subr_bufq.c:131:1:bufq_alloc
> 1136 db_lwp.c:64:1:db_lwp_whatis
> 1152 kern_ktrace.c:1269:1:ktrwrite
> 1168 uvm_swap.c:768:1:uvm_swap_stats.part.1
> 1312 nfs_serv.c:1905:1:nfsrv_rename
> 2112 tty_60.c:68:1:compat_60_ptmget_ioctl
> 2144 memmem.c:83:14:twoway_memmem
>
> Anyone else want to run with adding a bit more to this to do some build
> failure as mrg@ suggests and documenting for options(4)?
>
> Cheers,
> Simon.
> --
> Index: Makefile.kern.inc
> ===
> RCS file: /cvsroot/src/sys/conf/Makefile.kern.inc,v
> retrieving revision 1.270
> diff -d -p -u -r1.270 Makefile.kern.inc
> --- Makefile.kern.inc 21 May 2020 18:44:19 - 1.270
> +++ Makefile.kern.inc 31 May 2020 13:34:13 -
> @@ -104,6 +104,11 @@ CFLAGS+= -ffreestanding -fno-zero-initia
> CFLAGS+= ${${ACTIVE_CC} == "gcc":? -fno-delete-null-pointer-checks :}
> CFLAGS+= ${DEBUG} ${COPTS}
> AFLAGS+= -D_LOCORE -Wa,--fatal-warnings
> +.if defined(KERN_STACK_USAGE)
> +# example usage to find largest stack users in kernel compile directory:
> +#find . -name \*.su | xargs awk '{ printf "%6d %s\n", $2, $1 }' | sort
> +1n
> +CFLAGS+= -fstack-usage
> +.endif
>
> # XXX
> .if defined(HAVE_GCC) || defined(HAVE_LLVM)
> @@ -338,8 +343,8 @@ ${_s:T:R}.o: ${_s}
> .if !target(__CLEANKERNEL)
> __CLEANKERNEL: .USE
> ${_MKMSG} "${.TARGET}ing the kernel objects"
> - rm -f ${KERNELS} *.map eddep tags *.[io] *.ko *.ln [a-z]*.s vers.c \
> - [Ee]rrs linterrs makelinks assym.h.tmp assym.h \
> + rm -f ${KERNELS} *.map *.[io] *.ko *.ln [a-z]*.s *.su vers.c \
> + eddep tags [Ee]rrs linterrs makelinks assym.h.tmp assym.h \
> ${EXTRA_KERNELS} ${EXTRA_CLEAN}
> .endif
>
Re: kernel stack usage
matthew green wrote:
> glad to see this effort and the clean up already!
>
> ideally, we can break the kernel build if large stack consumers
> are added to the kernel. i'd be OK with it being default on,
> with of course a way to skip it, and if necessary it can have
> a whitelist of "OK large users."
I started to look at -fstack-usage which gives a nice MI way of getting
the data instead of parsing MD objdump output, but didn't get any
further than the below patch. The find(1) command referenced in the
patch gives the following
1008 nfs_serv.c:2181:1:nfsrv_link
1056 procfs_linux.c:422:1:procfs_do_pid_stat
1056 vfs_subr.c:1521:1:vfs_buf_print
1072 dl_print.c:80:1:sdl_print
1104 core_elf32.c:300:1:coredump_getseghdrs_elf32
1104 core_elf32.c:300:1:coredump_getseghdrs_elf64
1104 sys_ptrace_common.c:1595:1:proc_regio
1120 subr_bufq.c:131:1:bufq_alloc
1136 db_lwp.c:64:1:db_lwp_whatis
1152 kern_ktrace.c:1269:1:ktrwrite
1168 uvm_swap.c:768:1:uvm_swap_stats.part.1
1312 nfs_serv.c:1905:1:nfsrv_rename
2112 tty_60.c:68:1:compat_60_ptmget_ioctl
2144 memmem.c:83:14:twoway_memmem
Anyone else want to run with adding a bit more to this to do some build
failure as mrg@ suggests and documenting for options(4)?
Cheers,
Simon.
--
Index: Makefile.kern.inc
===
RCS file: /cvsroot/src/sys/conf/Makefile.kern.inc,v
retrieving revision 1.270
diff -d -p -u -r1.270 Makefile.kern.inc
--- Makefile.kern.inc 21 May 2020 18:44:19 - 1.270
+++ Makefile.kern.inc 31 May 2020 13:34:13 -
@@ -104,6 +104,11 @@ CFLAGS+= -ffreestanding -fno-zero-initia
CFLAGS+= ${${ACTIVE_CC} == "gcc":? -fno-delete-null-pointer-checks :}
CFLAGS+= ${DEBUG} ${COPTS}
AFLAGS+= -D_LOCORE -Wa,--fatal-warnings
+.if defined(KERN_STACK_USAGE)
+# example usage to find largest stack users in kernel compile directory:
+#find . -name \*.su | xargs awk '{ printf "%6d %s\n", $2, $1 }' | sort +1n
+CFLAGS+= -fstack-usage
+.endif
# XXX
.if defined(HAVE_GCC) || defined(HAVE_LLVM)
@@ -338,8 +343,8 @@ ${_s:T:R}.o: ${_s}
.if !target(__CLEANKERNEL)
__CLEANKERNEL: .USE
${_MKMSG} "${.TARGET}ing the kernel objects"
- rm -f ${KERNELS} *.map eddep tags *.[io] *.ko *.ln [a-z]*.s vers.c \
- [Ee]rrs linterrs makelinks assym.h.tmp assym.h \
+ rm -f ${KERNELS} *.map *.[io] *.ko *.ln [a-z]*.s *.su vers.c \
+ eddep tags [Ee]rrs linterrs makelinks assym.h.tmp assym.h \
${EXTRA_KERNELS} ${EXTRA_CLEAN}
.endif
Re: kernel stack usage
On Sun, May 31, 2020 at 07:48:57AM -0400, Michael wrote: > > 3248radeonfb_pickres at radeonfb.c:4127 > > 2304radeonfb_set_cursor at radeonfb.c:3690 > > I'll deal with these unless someone wants to beat me to it. Great! I wonder what to do about twoway_memmem() - the memmem() function seems to have a single caller looking for golang specific sections in linux elf binaries - should we just use a naive implementation for the kernel case? Martin
Re: kernel stack usage
Hello, On Sat, 30 May 2020 11:52:18 +0200 Martin Husemann wrote: > Hey folks, > > triggered by some experiments simonb did on mips I wrote a script to find > the functions using the bigest stack frame in my current sparc64 kernel. > > The top 15 list is: > > Frame/b Function ... > 3248radeonfb_pickres at radeonfb.c:4127 > 2304radeonfb_set_cursor at radeonfb.c:3690 I'll deal with these unless someone wants to beat me to it. have fun Michael
re: kernel stack usage
glad to see this effort and the clean up already! ideally, we can break the kernel build if large stack consumers are added to the kernel. i'd be OK with it being default on, with of course a way to skip it, and if necessary it can have a whitelist of "OK large users." > 1264cdioctl at cd.c:1204 > 1248uvm_swap_stats at uvm_swap.c:726 i think we can ignore these two. they're both going to be early in the stack so very unlikely to be problematic. .mrg.
Re: kernel stack usage
On Sat, May 30, 2020 at 11:52:18AM +0200, Martin Husemann wrote: > 1248aubtfwl_attach_hook at aubtfwl.c:273 > I took care of this. It was placing MAXPATHLEN+1 chars on the stack. While PNBUF_GET/PUT() seemed like a possible choice, I decided on kmem_asprintf()/kmem_strfree(), as in reality it needs nowhere near a MAXPATHLEN.
Re: kernel stack usage
Le sam. 30 mai 2020 à 18:41, Jason Thorpe a écrit : > These two seem slightly bogus. coredump_note_elf64() was storing register > state not the stack, but not nearly 3K worth. procfs_domounts() has nearly > nothing on the stack as far as I can tell, and the one function that could be > auto-inlined that it calls doesn't have much either. > struct statvfs is certainly over 3 KB - line 619 Jaromir
Re: kernel stack usage
> On May 30, 2020, at 7:18 AM, Christos Zoulas wrote: > > 3352 80b940bb:procfs_domounts+0xd > 3264 80c677da:coredump_note_elf64+0xb These two seem slightly bogus. coredump_note_elf64() was storing register state not the stack, but not nearly 3K worth. procfs_domounts() has nearly nothing on the stack as far as I can tell, and the one function that could be auto-inlined that it calls doesn't have much either. -- thorpej
Re: kernel stack usage
I've fixed several where I felt comfortable, feel free to do more: 4096pci_conf_print at pci_subr.c:4812 4096dtv_demux_read at dtv_demux.c:493 3408genfb_calc_hsize at genfb.c:630 2240bwfm_rx_event_cb at bwfm.c:2099 1664wdcprobe_with_reset at wdc.c:491 Jaromir Le sam. 30 mai 2020 à 16:18, Christos Zoulas a écrit : > > In article <20200530095218.gb28...@mail.duskware.de>, > Martin Husemann wrote: > >Hey folks, > > > >triggered by some experiments simonb did on mips I wrote a script to find > >the functions using the bigest stack frame in my current sparc64 kernel. > > > >The top 15 list is: > > > >Frame/b Function > >4096pci_conf_print at pci_subr.c:4812 > >4096dtv_demux_read at dtv_demux.c:493 > >3536SHA3_Selftest at sha3.c:430 > >3408genfb_calc_hsize at genfb.c:630 > >3248radeonfb_pickres at radeonfb.c:4127 > >2304radeonfb_set_cursor at radeonfb.c:3690 > >2272gem_pci_attach at if_gem_pci.c:147 > >2256twoway_memmem at memmem.c:84 > >2240bwfm_rx_event_cb at bwfm.c:2099 > >2240compat_60_ptmget_ioctl at tty_60.c:70 > >2112db_stack_trace_print at db_trace.c:77 > >1664wdcprobe_with_reset at wdc.c:491 > >1424nfsrv_rename at nfs_serv.c:1906 > >1408OF_mapintr at ofw_machdep.c:728 > >1344sysctl_hw_firmware_path at firmload.c:81 > >1280fw_bmr at firewire.c:2296 > >1264cdioctl at cd.c:1204 > >1248cpu_reset_fpustate at cpu.c:400 > >1248aubtfwl_attach_hook at aubtfwl.c:273 > >1248uvm_swap_stats at uvm_swap.c:726 > > > >(left column is size of the frame on sparc64 in bytes) > > > >I think anything > 1k is dubious and should be checked. > > I agree, here is the same for x86_64/GENERIC... > > 4408 8027af14:pci_conf_print+0xd > 4128 80a8dca0:dtv_demux_read+0xb > 3352 80b940bb:procfs_domounts+0xd > 3272 80e36b4b:SHA3_Selftest+0xd > 3264 80c677da:coredump_note_elf64+0xb > 3240 80b537c6:genfb_calc_hsize.isra.0+0x5 > 2704 80c66a88:coredump_note_elf32+0xb > 2408 80227a71:process_machdep_doxstate+0xd > 2184 804381fd:linux_ioctl_termios+0xd > 2168 80440b2d:linux32_ioctl_termios+0xd > 2112 802c5579:gem_pci_attach+0xb > 2104 80e465c3:twoway_memmem+0xd > 2088 806b5c18:bwfm_rx_event_cb+0xd > 2072 8097e221:compat_60_ptmget_ioctl+0xd > 2064 8053ce72:db_stack_trace_print+0x11 > 1488 8064f943:wdcprobe_with_reset+0xb > 1384 80d7ee2b:ipmi_match+0x9 > 1328 80467a95:usb_add_event+0x7 > 1304 80ba85bb:nfsrv_rename+0xd > 1256 8053069f:acpicpu_md_pstate_sysctl_all+0xd > 1256 8052cd13:acpicpu_start+0x9 > 1240 8043b162:linux_sys_rt_sigreturn+0x9 > 1192 80b9392a:procfs_do_pid_stat+0xd > 1176 80d70810:sysctl_hw_firmware_path+0xd > 1160 807b30a3:radeon_cs_ioctl+0xd > 1128 8044610f:oss_ioctl_mixer+0xd > 1128 8024dd3c:cdioctl+0xd > 1112 80c633ca:uvm_swap_stats.part.1+0xd > 1104 804fdf59:fw_bmr+0xb > 1096 80c8c0ab:ktrwrite+0xd > 1080 80573ca6:ahc_print_register+0xd > 1080 80550de8:procfs_getonecpu+0xd > 1080 8048d95e:aubtfwl_attach_hook+0x9 > 1064 80cf925d:proc_regio+0xd > 1064 80ccb407:bufq_alloc+0xd > 1064 80ae8090:ar5112SetPowerTable+0xd > 1064 80582aa0:ahd_print_register+0xd > 1064 80568a53:tpmread+0xd > 1064 80382262:txp_attach+0xd > 1064 802636da:ata_probe_caps+0xd > 1048 80e06097:ar9003_paprd_tx_tone_done+0xd > 1048 80d87e9b:sdl_print+0x9 > 1048 80c67604:coredump_getseghdrs_elf64+0xd > >
Re: kernel stack usage
In article <20200530095218.gb28...@mail.duskware.de>, Martin Husemann wrote: >Hey folks, > >triggered by some experiments simonb did on mips I wrote a script to find >the functions using the bigest stack frame in my current sparc64 kernel. > >The top 15 list is: > >Frame/b Function >4096pci_conf_print at pci_subr.c:4812 >4096dtv_demux_read at dtv_demux.c:493 >3536SHA3_Selftest at sha3.c:430 >3408genfb_calc_hsize at genfb.c:630 >3248radeonfb_pickres at radeonfb.c:4127 >2304radeonfb_set_cursor at radeonfb.c:3690 >2272gem_pci_attach at if_gem_pci.c:147 >2256twoway_memmem at memmem.c:84 >2240bwfm_rx_event_cb at bwfm.c:2099 >2240compat_60_ptmget_ioctl at tty_60.c:70 >2112db_stack_trace_print at db_trace.c:77 >1664wdcprobe_with_reset at wdc.c:491 >1424nfsrv_rename at nfs_serv.c:1906 >1408OF_mapintr at ofw_machdep.c:728 >1344sysctl_hw_firmware_path at firmload.c:81 >1280fw_bmr at firewire.c:2296 >1264cdioctl at cd.c:1204 >1248cpu_reset_fpustate at cpu.c:400 >1248aubtfwl_attach_hook at aubtfwl.c:273 >1248uvm_swap_stats at uvm_swap.c:726 > >(left column is size of the frame on sparc64 in bytes) > >I think anything > 1k is dubious and should be checked. I agree, here is the same for x86_64/GENERIC... 4408 8027af14:pci_conf_print+0xd 4128 80a8dca0:dtv_demux_read+0xb 3352 80b940bb:procfs_domounts+0xd 3272 80e36b4b:SHA3_Selftest+0xd 3264 80c677da:coredump_note_elf64+0xb 3240 80b537c6:genfb_calc_hsize.isra.0+0x5 2704 80c66a88:coredump_note_elf32+0xb 2408 80227a71:process_machdep_doxstate+0xd 2184 804381fd:linux_ioctl_termios+0xd 2168 80440b2d:linux32_ioctl_termios+0xd 2112 802c5579:gem_pci_attach+0xb 2104 80e465c3:twoway_memmem+0xd 2088 806b5c18:bwfm_rx_event_cb+0xd 2072 8097e221:compat_60_ptmget_ioctl+0xd 2064 8053ce72:db_stack_trace_print+0x11 1488 8064f943:wdcprobe_with_reset+0xb 1384 80d7ee2b:ipmi_match+0x9 1328 80467a95:usb_add_event+0x7 1304 80ba85bb:nfsrv_rename+0xd 1256 8053069f:acpicpu_md_pstate_sysctl_all+0xd 1256 8052cd13:acpicpu_start+0x9 1240 8043b162:linux_sys_rt_sigreturn+0x9 1192 80b9392a:procfs_do_pid_stat+0xd 1176 80d70810:sysctl_hw_firmware_path+0xd 1160 807b30a3:radeon_cs_ioctl+0xd 1128 8044610f:oss_ioctl_mixer+0xd 1128 8024dd3c:cdioctl+0xd 1112 80c633ca:uvm_swap_stats.part.1+0xd 1104 804fdf59:fw_bmr+0xb 1096 80c8c0ab:ktrwrite+0xd 1080 80573ca6:ahc_print_register+0xd 1080 80550de8:procfs_getonecpu+0xd 1080 8048d95e:aubtfwl_attach_hook+0x9 1064 80cf925d:proc_regio+0xd 1064 80ccb407:bufq_alloc+0xd 1064 80ae8090:ar5112SetPowerTable+0xd 1064 80582aa0:ahd_print_register+0xd 1064 80568a53:tpmread+0xd 1064 80382262:txp_attach+0xd 1064 802636da:ata_probe_caps+0xd 1048 80e06097:ar9003_paprd_tx_tone_done+0xd 1048 80d87e9b:sdl_print+0x9 1048 80c67604:coredump_getseghdrs_elf64+0xd
