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
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
> >
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
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
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
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
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
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
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
>
> 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
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
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
>4096
16 matches
Mail list logo
