OpenBSD Journal
Home : : Add Story : : Archives : : About : : Create Account : : Login :
a2k17 hackathon report: Martin Pieuchot on NET_LOCK and much more
Contributed by nayden on Sat Jan 28 02:25:52 2017 (GMT)
from the unlocking dept.

Our next a2k17 report comes from Martin Pieuchot (mpi@), who writes:

My goal for a2k17 was to fix the remaining issues with the NET_LOCK() and enable it again.

It has not been an easy task, but we made it [0]! I say "we" because this could not have been possible without the help of bluhm@ and his awesome automated regression test setup [1].

The first goal of the NET_LOCK() is to ensure no unwanted sleeping point are introduced when sending network packets from the socket layer. But during this hackathon I discussed it with dlg@, guenther@, claudio@ and deraadt@, and we came up with a plan to un-KERNEL_LOCK() the socket layer. Of course the NET_LOCK() is part of this plan.

Since I had many machines available, I decided to start fuzzing our USB stack again. The first problem I found is that my USB cable was dead, which explained why I didn't manage to make the fuzzer work last time I tried. After the first day fuzzing common drivers (hub, hid, keyboard) without finding any panic I decided to take a look at fuzzing uaudio(4). It found so many panics in the horrible custom descriptor parser that I ran away from USB for this hackathon.

Then I spent some time in librthread. I wrote an alternative mutex and condition variable implementation based on CAS and futex(2). Once they passed all our base regress I started porting more tests [2]. Thanks to these tests I found an unfixable flaw in my condition variable code, so I started porting musl [3]'s implementation.

At the same time I had a nice chat with tb@ about creating a tool to generate a dynamic graph based on kdump(1)'s output. The would help us a lot to analyze what processes are doing over a long period of time.

This led me back in the scheduler code where I found that for some workload CPUs are playing ping-pong [4]. I'm looking for test reports!

Finally I implemented Dynamic Profiling for i386, just like I did for amd64 [5] at g2k16. This combined to ISC-licensed CTF [6] tools [7] should allow us to build a dynamic tracing framework. Stay tuned!

I'd like to thanks dlg@ and jmatthew@ for organising yet another great spider hackathon! It was awesome.

[0] https://marc.info/?l=openbsd-cvs&m=148532495904546&w=2
[1] http://bluhm.genua.de/regress/results/regress.html
[2] https://github.com/mpieuchot/libpthread-regress
[3] http://www.musl-libc.org/
[4] https://marc.info/?l=openbsd-tech&m=148522892511536&w=2
[5] https://marc.info/?l=openbsd-cvs&m=147298098607098&w=2
[6] https://github.com/mpieuchot/ctfdump
[7] https://github.com/mpieuchot/ctfconvert

Thanks, Martin, for the report - and, of course, the great work!

[topicopenbsd]

<< a2k17 hackathon report: Kenneth Westerback on the hidden wonders of the build system, the network stack and more | Reply | Threaded | a2k17 hackathon report: Patrick Wildt on the arm64 port >>

Threshold: Help

Related Links
more by nayden


[ Home | Add Story | Archives | Polls | About ]

Copyright © 2004-2008 Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to April 2nd 2004 as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. Some icons from slashdot.org used with permission from Kathleen. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. Search engine is ht://Dig. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]