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

[matthew green <mrg%eterna.com.au@localhost>]

> >>> there's a fairly significant problem with this implementation.
> >>> 
> >>> you're only catching callers who use end up going through sy_call()
> >>> and that's not the majority.  mostly they're called directly from
> >>> MD code.  so to fix that, you have to update every platform syscall
> >>> handler.
> 
> FWIW, I did check the archives from 8 years ago when ad@ added the
> sy_call() wrapper.  It appears that he had already addressed the
> several md-specific syscall dispatchers to use the wrapper, so it
> seems that we don't need to do anything special.  See [1] for the
> relevant commit.  If you can point out any other code that still
> needs to be updated, please do!
> 
> [1]http://mail-index.netbsd.org/source-changes/2008/10/21/msg211565.html

i think you're OK here.  i did happen to find a couple of weird things
just now:

- filemon(4) is utterly broken.  it literally replaces the sysent
  values for the current emulation while active.  so it has an ugly
  obvious problem with runtime usage (particularly at unload.)
  however, a much bigger problem is that it adjusts an emulation
  that might not be the default one.  (32 bit modload of filemon
  on a 64 bit kernel, i think, will adjust the netbsd32 sysent.)
  so it could break the emulation.  this also means that every
  other emulation will not be affected and IO will be missed (see:
  "utterly broken".)

- all the emulation support for ptrace(2) is oddly implemented.
  while most simple calls that just need to adjust for pointer or
  integer sizes, and then call the real function, eg accept:

        return (sys_accept(l, &ua, retval));

  the ptrace for netbsd32 (and all other support emuls) calls via
  .sy_call directly:

        return (*sysent[SYS_ptrace].sy_call)(l, &ua, retval);

but it's not clear to me why.


.mrg.