re: Problem with syscall_disestablish() - PR kern/50430

[Paul Goyette <paul%vps1.whooppee.com@localhost>]

On Tue, 17 Nov 2015, matthew green wrote:

> additional problems i've realised:
>
> - this should be process specific, not LWP specific.
>
> - we might need some way to copy this across fork().
>
> - as l_sysent seems unreliable, we should just remove it.

l_sysent serves another purpose:  it is used to restart the syscall
if it originally pointed to sys_nomodule() and we auto-load the
module that provides the syscall.

> > In a nut-shell, we cannot rely on the struct lwp's l_sysent member
> > to determine if a particular syscall is "active", since it could be
> > overwritten during signal handling.  As a result, it is possible to
> > unload modules which have active syscalls, and when those syscalls
> > are resumed they'll return into memory that most likely no longer
> > contains the syscall code.  (A big "Thanks!" goes out to Masao
> > Uebayashi for identifying this bug.)
>
> ah, i think i understand this now.  i wonder if any of the system
> calls that support being restarted actually are modloadable (ie,
> is this a non-problem?)  most system calls aren't and the few that
> are are pretty basic.

There's actually a fairly large number of mod(auto-)loadable syscalls
as can be found in (generated) source-file kern/syscalls_autoload.c
I don't know how many of these could be interruptable.

I don't think "restartable" is the right adjective here - that would
imply (to me) that the syscall returned ERESTART, rather than not
having returned at all and therefore still being active.  If a syscall
returns with ERESTART, then it would be ok to unload the module, and
retrying the syscall would either fail or re(auto-)load the module.


> i have another idea.
>
> if these calls, at entry, mark the module as "busy in proc X".  then
> when the unload is attempted, if X is still around, fail.  that
> pushes all the resources into the module again, and seems to plug
> all the holes.

Hmmm.  This would mean we'd need to keep a _set_of_ prox_X values, and
I'm not sure about sizing (and resizing) the set.  But it certainly is
a possibility.

Can you please update the PR with this alternate suggestion?


+------------------+--------------------------+-------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com    |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org  |
+------------------+--------------------------+-------------------------+