NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/50430: syscall_disestablish() can remove active syscalls
The following reply was made to PR kern/50430; it has been noted by GNATS.
From: Masao Uebayashi <uebayasi%gmail.com@localhost>
To: Paul Goyette <paul%whooppee.com@localhost>
Cc: Christos Zoulas <christos%zoulas.com@localhost>, gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost,
gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/50430: syscall_disestablish() can remove active syscalls
Date: Mon, 16 Nov 2015 17:42:04 +0900
On Mon, Nov 16, 2015 at 5:20 PM, Paul Goyette <paul%vps1.whooppee.com@localhost> wrote:
> On Mon, 16 Nov 2015, Masao Uebayashi wrote:
>
>>> Sure, that sounds prudent. It is difficult to fix properly. One way to do
>>> this would be to mark all lwps that have used compat syscalls with a bit
>>> depending on the module they have used, and refuse to unload the module
>>> until the lwp is gone.
>>>
>>> - when load a module that has compat syscalls, assign to it a bit.
>>> - mark a flags field of all syscalls that were loaded with that module
>>> with that bit.
>>> - or the lwp flags with the syscall flags on each syscall.
>>> - when it is time to unload check that no lwp has that bit in the flags
>>> set.
>>> - instead of keeping l_sysent, keep l_sysmodflags or something.
>>
>>
>> What happens if signal handler does longjmp(3) and interrupted syscall
>> never returns?
>
>
> Whether or not the interrupted syscall returns, as long as the lwp is
> still alive it will prevent the syscall from being disestablished.
>
> In effect, it is a "false positive" but it allows us to err on the side
> of caution. I'd rather have the module remain loaded even if nothing is
> currently referencing its resources, rather than have it get unloaded
> and then the kernel crashes.
Ah. That's simpler. :)
Home |
Main Index |
Thread Index |
Old Index