re: kernel stack usage

2020-05-30 Thread matthew green
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

Re: kernel stack usage

2020-05-30 Thread Jonathan A. Kollasch
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

Re: kernel stack usage

2020-05-30 Thread Jaromír Doleček
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 >

Re: kernel stack usage

2020-05-30 Thread Jason Thorpe
> 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

Re: kernel stack usage

2020-05-30 Thread Jaromír Doleček
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

Re: kernel stack usage

2020-05-30 Thread Christos Zoulas
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

Re: Fix for slow run(4) configuration on OHCI/UHCI

2020-05-30 Thread Christos Zoulas
In article <24273.15131.928644.743...@guava.gson.org>, Andreas Gustafsson wrote: >Hi all, > >When I connect a USB WiFi adapter based on a Ralink RT5370 chip to a >USB port that uses an OHCI or UHCI host controller, running "ifconfig >run0 up" takes a very long time, about 20-30 seconds. > >This

kernel stack usage

2020-05-30 Thread Martin Husemann
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 3536