On Fri, Feb 12, 2021 at 10:59:05PM +0100, Jeremie Courreges-Anglas wrote: > On Wed, Feb 10 2021, Martin Pieuchot <m...@openbsd.org> wrote: > > [...] > > > Which fields is the new lock protecting? Why isn't the KERNEL_LOCK() > > enough? > > When I mentioned this potential lack of locking to Marcus, I was > mistaken. Some of the functions in video.c are called from syscalls > that are marked NOLOCK. But now that I have added some printf > debugging, I can see that the kernel lock is held in places where > I didn't expect it to be held (videoioctl, videoread, videoclose...). > So there's probably a layer of locking that I am missing. > > Marcus, sorry for my misleading diff. O:) > > *crawls back under his rock*
Just because a syscall is marked NOLOCK does not mean that all of it will run without the KERNEL_LOCK. For example read and write are marked NOLOCK but the KERNEL_LOCK is grabbed later for all non-socket filedescriptors. This is why video(4) still runs with the KERNEL_LOCK. The NOLOCK in syscalls.master just tell the kernel to not grab the KERNEL_LOCK right at the start of the syscall. -- :wq Claudio
