Re: ipfilter crash in latest netbsd-9
Le 01/06/2020 à 03:06, Emmanuel Dreyfus a écrit : Emmanuel Dreyfus wrote: After upgrading to 9.0, I experienced crashes when enabling ipfilter (backtrace below). I tried latest netbsd-9 kernel without improvement. In the meantime, I filed kern/55236 about the ipfilter regression in NetBSD 9.0 i386 Xen. It happens with i386 XEN3PAE_DOMU kernels when ipfilter is loaded as a module. If I add back pseudo-device ipfilter in the kernel, the problems vanishes. Maxime, you made the change quite a long time ago. Nobody reported issue? Would you have an idea of where this bug stems from? http://mail-index.netbsd.org/source-changes/2018/08/01/msg097228.html I don't have time to check precisely right now, but if the problem arises in a module and not in built-in, then it probably is a #define mishap. Try to rebuild the module with -DXEN and -DPAE in CFLAGS.
Re: ipfilter crash in latest netbsd-9
Emmanuel Dreyfus wrote: > After upgrading to 9.0, I experienced crashes when enabling > ipfilter (backtrace below). I tried latest netbsd-9 kernel without > improvement. In the meantime, I filed kern/55236 about the ipfilter regression in NetBSD 9.0 i386 Xen. It happens with i386 XEN3PAE_DOMU kernels when ipfilter is loaded as a module. If I add back pseudo-device ipfilter in the kernel, the problems vanishes. Maxime, you made the change quite a long time ago. Nobody reported issue? Would you have an idea of where this bug stems from? http://mail-index.netbsd.org/source-changes/2018/08/01/msg097228.html -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
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
