tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Proposed change to makesyscalls.sh



On Sun, 5 Aug 2018, Martin Husemann wrote:

On Sun, Aug 05, 2018 at 06:24:25AM +0800, Paul Goyette wrote:
The primary usage for this is for arch/usermode's syscallemu() which
(according to those working on arch/usermode) could be considered
"dangerous" and "should never be autoloaded.  Having this change will
allow use of a "registered" syscall number rather than having to have
a work-around for PR kern/45781.

Doesn't (say) 211 work? Then just mark it as reserved in syscalls.master
in a comment, like:

;
; Syscalls 210-219 are reserved for dynamically loaded syscalls
;
210     EXTERN  MODULAR openafs { int|sys||afssys(long id, long a1, long a2, \
                         long a3, long a4, long a5, long a6); }
211     UNIMPL	/* syscallemu for sys/arch/usermode/modules/syscallemu */
212     UNIMPL
213     UNIMPL
214     UNIMPL

That would work, but only with the "work-around" for 45781. Otherwise, syscall_establish() will only install entries with sys_nomodule as the entrypoint. As far as I understand, UNIMPL generates entries with an entry point of sys_nosys - hence the work-around.

Has anyone analyzed PR 45781? Is it just about extending the valid range
or does it break for this numbers too?

It's not just the range, it's the entrypoint that triggers the autoload stuff. (If the syscall number exceed the limit SYS_NSYSENT, which controls the size of various allocated arrays, there's not much you can do...)

We could change syscall_establish() to install for both sys_nomodule or sys_nosys entry points. But then we'd need to remember which value to restore when syscall_disestablish() is called.

Hmmm, looking closer at the code, we probably could ignore that issue. If we blindly restore a value of sys_nomodule in syscall_disestablish() the only thing that happens is that any subsequent attempts to use that syscall will go through the search of the syscall_autoload[] list to find one that matches the syscall number. If no entry is found, then we'll simply return sys_nosys() after all.

OK, so the original proposal isn't necessary. Here's a proposal to allow syscall_establish() to install new syscalls for either sys_nosys or sys_nomodule entry points:

Index: kern_syscall.c
===================================================================
RCS file: /cvsroot/src/sys/kern/kern_syscall.c,v
retrieving revision 1.16
diff -u -p -r1.16 kern_syscall.c
--- kern_syscall.c      24 Mar 2017 17:40:44 -0000      1.16
+++ kern_syscall.c      5 Aug 2018 13:06:41 -0000
@@ -123,7 +123,8 @@ syscall_establish(const struct emul *em,
 	 * on error.
 	 */
 	for (i = 0; sp[i].sp_call != NULL; i++) {
-		if (sy[sp[i].sp_code].sy_call != sys_nomodule) {
+		if (sy[sp[i].sp_code].sy_call != sys_nomodule &&
+		    sy[sp[i].sp_code].sy_call != sys_nosys) {
 #ifdef DIAGNOSTIC
 			printf("syscall %d is busy\n", sp[i].sp_code);
 #endif

This avoids the need for the "work-around" for syscallemu...


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


Home | Main Index | Thread Index | Old Index