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
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
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
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,
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
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
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
...
> 3248
