Profiling ifconfig was my first guess, I am not an experienced programmer in any sense of the word.
I did the ktrace/kdump run, and the result is just 65 lines, most of which seem normal (attached). The suspicious lines below: ``` 78429 ifconfig 1639744429.761912 CALL socket(AF_INET,0x2<SOCK_DGRAM>,0) 78429 ifconfig 1639744429.761920 RET socket 3 78429 ifconfig 1639744429.761922 CALL ioctl(3,SIOCGIFFLAGS,0xcc175b5b2a8) 78429 ifconfig 1639744429.761925 RET ioctl 0 78429 ifconfig 1639744429.761926 CALL ioctl(3,SIOCGIFXFLAGS,0xcc175b5b2a8) 78429 ifconfig 1639744429.761927 RET ioctl 0 78429 ifconfig 1639744429.761928 CALL ioctl(3,SIOCGIFMETRIC,0xcc175b5b2a8) 78429 ifconfig 1639744429.761929 RET ioctl 0 78429 ifconfig 1639744429.761934 CALL ioctl(3,SIOCBRDGRTS,0x7f7ffffbda50) 78429 ifconfig 1639744429.761936 RET ioctl -1 errno 25 Inappropriate ioctl for device 78429 ifconfig 1639744429.761937 CALL ioctl(3,SIOCGIFMTU,0xcc175b5b2a8) 78429 ifconfig 1639744429.761939 RET ioctl 0 78429 ifconfig 1639744429.761939 CALL ioctl(3,SIOCGIFRDOMAIN,0xcc175b5b2a8) 78429 ifconfig 1639744429.761942 RET ioctl 0 78429 ifconfig 1639744429.761943 CALL ioctl(3,SIOCGIFLLPRIO,0xcc175b5b2a8) 78429 ifconfig 1639744429.761944 RET ioctl 0 78429 ifconfig 1639744429.761945 CALL ioctl(3,SIOCGIFFLAGS,0x7f7ffffbda80) 78429 ifconfig 1639744429.761946 RET ioctl 0 78429 ifconfig 1639744429.761947 CALL ioctl(3,SIOCSIFFLAGS,0x7f7ffffbda80) 78429 ifconfig 1639744660.684179 RET ioctl 0 78429 ifconfig 1639744660.701556 CALL mprotect(0xcc385a48000,0x1000,0x3<PROT_READ|PROT_WRITE>) ``` I have no idea what this means, to be honest. ioctl(3,SIOCSIFFLAGS,0x7f7ffffbda80) seems to be the one running for 231 second. I looked at the code of if_vio.c, and it seems to be taking time at calling vio_init (as there is not much more in this ioctl), however, I do not know much about debugging kernel drivers, so suggestions welcome :). Is there a way to recompile it with profiling/tracing information, or maybe just putting printfs manually around the most interesting lines would be more productive?
ifconfig-kdump.result.2021-12-17_12-34
Description: Binary data
"Theo de Raadt" <dera...@openbsd.org> writes: > Claudio Jeker <cje...@diehard.n-r-g.com> wrote: > >> On Thu, Dec 16, 2021 at 03:55:43PM +0800, Vladimir Nikishkin wrote: >> > Hello, everyone >> > >> > Recently I had a problem: my system is losing network connectivity, >> > although the interface (vio0 on KVM) seemed up. Restarting the >> > connection with `ifconfig vio0 down` and `ifconfig vio0 up` restores the >> > connection. >> > >> > However, when I timed the execution, I found that the second `up` can >> > take up to 15 minutes. (Hugely unexpected!) To find out where the >> > program is waiting, I decided to recompile ifconfig from source with >> > debugging and profiling support. >> > >> > Slightly adjusting the commands provided by the Makefile, I came up with >> > the following commands: >> > >> > ``` >> > egcc -O0 -g -pg -fPIC -Werror-implicit-function-declaration -c ifconfig.c >> > egcc -O0 -g -pg -fPIC -Werror-implicit-function-declaration -c brconfig.c >> > egcc -O0 -g -pg -fPIC -Werror-implicit-function-declaration -c sff.c >> > egcc -g -pg -shared -pie -o ifconfig ifconfig.o brconfig.o sff.o -lc -pg >> > ``` >> > >> > However, when I run ./ifconfig compiled like this, I am getting (besides >> > the output of ifconfig itself) the following error message: >> > >> > ``` >> > gmon.out: No such file or directory >> > ``` >> > >> > I find this unexpected. Compiling and linking a simple helloworld with >> > -pg -g seems to be working fine, and gmon.out is produced as expected. >> > >> > What am I doing wrong? Is there something specific that needs to be >> > permitted to profile ifconfig? >> >> I doubt the problem is in ifconfig(8) itself but more an ioctl that takes >> long to finish. Anyway for prfiling to work you need to neuter unveil() in >> ifconfig. e.g. by changing the code. With unveil on the gmon.out file >> written in the atexit handler can't be created. > > Wrong tool being used to debug a userland program. It is better to attach > a debugger to a -g executable. Or use ktrace -di with kdump, to figure out > what system calls it is stuck in. > > And I suspect you will quickly decide there is no problem in ifconfig.. -- Your sincerely, Vladimir Nikishkin (MiEr, lockywolf) (Laptop)
