Re: makesyscalls (moving forward)
On Sun, Jun 14, 2020 at 02:21:07PM -0700, Paul Goyette wrote: > > (2) What is the installed syscall description file called and where > > does it go? It is likely to be derived from (i.e., not the same as) > > syscalls.master. It isn't a C header file so it doesn't belong in > > /usr/include. It isn't necessarily particularly human-readable. My > > suggestion would be to add a directory in /usr/share for API > > descriptions and put it there, something like maybe > > /usr/share/api/syscalls.def. > > Perhaps /usr/share/sys/syscalls.def ? > > I'd suspect we might find more .../sys/... stuff (compared to the > amound of .../api... stuff) in the future which could minimize the > lonliness of syscalls.def :) Or even maybe /usr/share/kern/... > might work. I was thinking that other machine-readable API definitions might appear in the future, e.g. for parts of libc and for other base libraries. Wherever we put it now, it's going to be lonely to begin with :-/ -- David A. Holland dholl...@netbsd.org
Re: makesyscalls (moving forward)
On Sun, Jun 14, 2020 at 11:59:54PM +0200, Johnny Billquist wrote: > > "usr.bin/makesyscalls" sounds good to me. > > Uh? usr.bin is where stuff for /usr/bin is located, right? Anything there > should be pretty normal tools that any user might be interested in. Don't > seem to me as makesyscalls would be a tool like that? > > Possibly some sbin thing, but in all honestly, wouldn't this make more > sense to have somewhere under sys? Don't we have some other tools and bits > which are specific for kernel and library building? So this was, in fact, a discussion I was intending to provoke, because right now we have no place to put tools that are part of the system build but don't make any sense to install in /usr, and that seems like a gap. However, Kamil convinced me that there will be external users of this thing. As I mentioned in the original mail, apparently the llvm sanitizers already have a netbsd-specific script that tries to read the existing syscalls.master, and any future sanitizer-like thing will need something similar if we don't provide a facility. Having 3rd-party sources like this groping in our tree trying to read an internal file whose format and semantics we don't support is not the right way. Meanwhile it doesn't belong in sbin because it doesn't require root, nor does doing something useful with it require root, and it doesn't need to be on /, so... usr.bin. Unless we think libexec is reasonable, but if 3rd-party code is going to be running it we really want it on the $PATH, so... -- David A. Holland dholl...@netbsd.org
Re: [PATCH] Add support for RUMP_USE_LIBC_ALLOCATORS
In article , Kamil Rytarowski wrote: >-=-=-=-=-=- >-=-=-=-=-=- > >I propose to add a new option for building rumpkernel: >RUMP_USE_LIBC_ALLOCATORS. > >This option wires the kernel allocators directly to the libc functions. >This is useful for sanitizers with their fine-grained checks of >allocated chunks. > >http://netbsd.org/~kamil/patch-00268-RUMP_USE_LIBC_ALLOCATORS.2.txt > >Does this code and approach look good? Is possible to improve this >approach? There is a fallout with ATF test t_vm::uvmwait as it no longer >passes as the memory limit is no longer respected. > >With this patch rumpkernel is now more sensitive to real memory access >bugs. The immediate detected problem is with kthread_join() that >attempts to join a thread that was freed. > >http://netbsd.org/~kamil/rump/heap-use-after-free.txt > >We use this patch during the ongoing GSoC so quick merge into src/ is >wanted. I think putting the libc allocator versions of the functions in their own files is better, because this way has too many ifdefs. Perhaps subr_pool needs to be split for that to be effective. Try that and see if it looks better... christos
Re: makesyscalls (moving forward)
On 2020-06-15 00:07, Kamil Rytarowski wrote: On 14.06.2020 23:59, Johnny Billquist wrote: On 2020-06-14 23:21, Paul Goyette wrote: On Sun, 14 Jun 2020, David Holland wrote: This raises two points that need to be bikeshedded: (1) What's the new tool called, and where does it live in the tree? "usr.bin/makesyscalls" is fine with me but ymmv. "usr.bin/makesyscalls" sounds good to me. Uh? usr.bin is where stuff for /usr/bin is located, right? Anything there should be pretty normal tools that any user might be interested in. Don't seem to me as makesyscalls would be a tool like that? Possibly some sbin thing, but in all honestly, wouldn't this make more sense to have somewhere under sys? Don't we have some other tools and bits which are specific for kernel and library building? /usr/bin is appropriate and there are already similar tools (like ioctlprint(1)). It's already in PATH and definitely in interest of some end-users (like me) and I do want to have it. It could certainly be questioned if ioctlprint should be in /usr/bin as well. If we think tools like ping, which arguably a lot of people have heard about, and actually use, are in /sbin, what makes ioctlprint such a more commonly looked for, and used tool? I would say this is really a tool for pretty advanced users. But even so, I could more easily see ioctlprint in /usr/bin than I could makesyscalls. Anyone writing code that sits in the kernel is definitely in the area of users who have privileges and abilities that don't apply to normal users. And the question was not about having it or not, but where it should be located. Looking at hier(7), we have: /sbin/ System programs and administration utilities used in both single-user and multi-user environments. /usr/sbin/ System daemons and system utilities (normally executed by the super-user). and /bin/ Utilities used in both single and multi-user environments. /usr/bin/ Common utilities, programming tools, and applications. How "common" would you say makesyscalls is (or ioctlprint for that matter)? I don't mind the name, but I also agree that this is mostly something for build.sh, which I am wondering if it wouldn't more appropriately fit in somewhere under sys? Definitely not something I would expect a normal user to ever make use of. But that's just me. I'll leave the deciding to you guys... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: makesyscalls (moving forward)
On 2020-06-15 00:50, Robert Swindells wrote> Johnny Billquist wrote: On 2020-06-14 23:21, Paul Goyette wrote: On Sun, 14 Jun 2020, David Holland wrote: This raises two points that need to be bikeshedded: (1) What's the new tool called, and where does it live in the tree? "usr.bin/makesyscalls" is fine with me but ymmv. "usr.bin/makesyscalls" sounds good to me. Uh? usr.bin is where stuff for /usr/bin is located, right? Anything there should be pretty normal tools that any user might be interested in. Don't seem to me as makesyscalls would be a tool like that? As config(1) is in /usr/bin that seems the best place for makesyscalls too. Ouch! What a rabbit hole! I should be quiet now. :-) (I don't really think config makes any sense at all to have in /usr/bin... ;-) ) I would expect that the generated files would have the developer uid and gid, I wouldn't want them owned by root. I guess I fail to see the problem there. That all depends on who is running it, and where the files are placed. Don't really matter where the tool is located. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: makesyscalls (moving forward)
> This is only me, but /sbin and /usr/sbin are for users with root > privileges, while /bin and /usr/bin for everybody. Maybe mostly. But there are exceptions enough that I think keeping this with the likes of config(1) and genassym(1) makes sense, especially in view of cross-builds. Personally, the biggest exception in practice is probably ping(8), which I routinely use as a non-root user. Others of use to me even as non-root include iostat(8), mount(8), and ntpdc(8). In the other direction, chflags(1) and lastcomm(1) strike me as among the most likely to belong in /usr/sbin instead. And there is enough history - config(1), genassym(1) - behind build tools being in /usr/bin that I think this one belongs there too. Given its typical, and apparent design, use, revoke(1) too. Looking at the lists of commands, I don't think it's so much "root" and "non-root" as it is "sysadmin" and "non-sysadmin" - which is also part of why it's significantly harder to find exceptions in /usr/bin than in /usr/sbin, since "root commands" is closer to being a subset of "sysadmin commands" than the other way around. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: makesyscalls (moving forward)
On 2020-06-15 00:52, Kamil Rytarowski wrote: On 15.06.2020 00:26, Johnny Billquist wrote: But that's just me. I'll leave the deciding to you guys... This is only me, but /sbin and /usr/sbin are for users with root privileges, while /bin and /usr/bin for everybody. makesyscalls(1) intends to be an end-user program that aids building software and this is just another specialized program similar to flex(1) or yacc(1), just a more domain specific code generator. Is ping only for people with root privileges??? Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: makesyscalls (moving forward)
On 15.06.2020 00:26, Johnny Billquist wrote: > But that's just me. I'll leave the deciding to you guys... > This is only me, but /sbin and /usr/sbin are for users with root privileges, while /bin and /usr/bin for everybody. makesyscalls(1) intends to be an end-user program that aids building software and this is just another specialized program similar to flex(1) or yacc(1), just a more domain specific code generator. I don't see any reason why to restrict makesyscalls(1) to root-only. /usr/bin is a settled path for native programs and chaing it is not worth it (and I personally see no reason). If I want to plug makesyscalls(1) into LLVM or GDB or some fuzzers, it would be certainly cumbersome to pass full path to some /sys/bin or similar. signature.asc Description: OpenPGP digital signature
Re: makesyscalls (moving forward)
Johnny Billquist wrote: >On 2020-06-14 23:21, Paul Goyette wrote: >> On Sun, 14 Jun 2020, David Holland wrote: >> >> >> >>> This raises two points that need to be bikeshedded: >>> >>> (1) What's the new tool called, and where does it live in the tree? >>> "usr.bin/makesyscalls" is fine with me but ymmv. >> >> "usr.bin/makesyscalls" sounds good to me. > >Uh? usr.bin is where stuff for /usr/bin is located, right? Anything >there should be pretty normal tools that any user might be interested >in. Don't seem to me as makesyscalls would be a tool like that? As config(1) is in /usr/bin that seems the best place for makesyscalls too. I would expect that the generated files would have the developer uid and gid, I wouldn't want them owned by root.
Re: makesyscalls (moving forward)
On 14.06.2020 23:59, Johnny Billquist wrote: > On 2020-06-14 23:21, Paul Goyette wrote: >> On Sun, 14 Jun 2020, David Holland wrote: >> >> >> >>> This raises two points that need to be bikeshedded: >>> >>> (1) What's the new tool called, and where does it live in the tree? >>> "usr.bin/makesyscalls" is fine with me but ymmv. >> >> "usr.bin/makesyscalls" sounds good to me. > > Uh? usr.bin is where stuff for /usr/bin is located, right? Anything > there should be pretty normal tools that any user might be interested > in. Don't seem to me as makesyscalls would be a tool like that? > > Possibly some sbin thing, but in all honestly, wouldn't this make more > sense to have somewhere under sys? Don't we have some other tools and > bits which are specific for kernel and library building? > /usr/bin is appropriate and there are already similar tools (like ioctlprint(1)). It's already in PATH and definitely in interest of some end-users (like me) and I do want to have it. makesyscalls(1) sounds like a good name. /usr/share/sys/syscalls.de should be an internal detail for makesyscalls(1). I actually think that syscalls.def should be builtin into the program and we should avoid an external file dependency as it is expected to be operational for only one kernel ABI release + makesyscalls(1) version. There are expected no external consumers of this .def file and all we need and want is to pass rules how to generate syscall definitions. makesyscalls(1) will likely quickly turn into a ./build.sh tool and reducing management of an external file is especially a good idea. There is already a prior art as ioctlprint(1) has a builtin database for the ioctl codes and it works well. > Johnny > signature.asc Description: OpenPGP digital signature
Re: TSC improvement
On Thu, Jun 11, 2020 at 04:50:40AM +, Taylor R Campbell wrote: > What's trickier is synchronizing per-CPU timecounters so that they all > give a reasonably consistent view of absolute wall clock time -- and > so it's not just one CPU that leads while the others play catchup > every time they try to read the clock. (In other words, adding atomic > catchup logic certainly does not obviate the need to synchronize > per-CPU timecounters!) > > But neither synchronization nor global monotonicity is always > necessary -- e.g., for rusage we really only need a local view of time > since we're only measuring relative time durations spent on the > current CPU anyway. > > > >This is what the timecounter(9) API per se expects of timecounters, > > >and right now tsc (along with various other per-CPU cycle counters) > > >fails to guarantee that. > > > > Howso, do you see a bug? I think it's okay. The TSC is only used for the > > timecounter where it's known that it's insensitive to core speed variations > > and is driven by PLL related to the bus clock. Fortunately that means most > > x86 systems, excepting a window of some years from roughly around the time > > of the Pentium 4 onwards. > > If tc_get_timecount goes backward by a little, e.g. because you > queried it on cpu0 the first time and on cpu1 the second time, > kern_tc.c will interpret that to mean that it has instead jumped > forward by a lot -- nothing in the timecounter abstraction copes with > a timecounter that goes backwards at all. I thought about it some more and I just don't think we have this problem on x86 anyway. The way I see it, with any counter if you make explicit comparisons on a global basis the counter could appear to go a tiny bit backwards due to timing differences in execution - unless you want to go to some lengths to work around that. I think all you can really expect is for the clock to not go backwards within a single thread of execution. By my understanding that's all the timecounter code expects and the TSC code on x86 makes sure of that. I changed tsc_get_timecount so it'll print a message out if it's ever observed. > (There's also an issue where the `monotonic' clock goes backwards > sometimes, as reported by sched_pstats. I'm not sure anyone has > tracked down where that's coming from -- it seems unlikely to be > related to cross-CPU tsc synchronization because lwp rtime should > generally be computed from differences between samples on a single CPU > at a time, but I don't know.) Hmm. There was a race condition with rusage and softints that I fixed about 6 months ago where proc0 had absurd times in ps/top but I have not seen the "clock has gone backwards" one in a long time. I wonder if it's related. Andrew
Re: makesyscalls (moving forward)
On 2020-06-14 23:21, Paul Goyette wrote: On Sun, 14 Jun 2020, David Holland wrote: This raises two points that need to be bikeshedded: (1) What's the new tool called, and where does it live in the tree? "usr.bin/makesyscalls" is fine with me but ymmv. "usr.bin/makesyscalls" sounds good to me. Uh? usr.bin is where stuff for /usr/bin is located, right? Anything there should be pretty normal tools that any user might be interested in. Don't seem to me as makesyscalls would be a tool like that? Possibly some sbin thing, but in all honestly, wouldn't this make more sense to have somewhere under sys? Don't we have some other tools and bits which are specific for kernel and library building? Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: makesyscalls (moving forward)
On Sun, 14 Jun 2020, David Holland wrote: This raises two points that need to be bikeshedded: (1) What's the new tool called, and where does it live in the tree? "usr.bin/makesyscalls" is fine with me but ymmv. "usr.bin/makesyscalls" sounds good to me. (2) What is the installed syscall description file called and where does it go? It is likely to be derived from (i.e., not the same as) syscalls.master. It isn't a C header file so it doesn't belong in /usr/include. It isn't necessarily particularly human-readable. My suggestion would be to add a directory in /usr/share for API descriptions and put it there, something like maybe /usr/share/api/syscalls.def. Perhaps /usr/share/sys/syscalls.def ? I'd suspect we might find more .../sys/... stuff (compared to the amound of .../api... stuff) in the future which could minimize the lonliness of syscalls.def :) Or even maybe /usr/share/kern/... might work. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
makesyscalls (moving forward)
As I mentioned a few days ago the reason I was prodding makesyscalls.sh is that I've been looking at generating more of the system call argument handling code. It seems to me that all of the following is mechanical and should be automatically generated, beyond what makesyscalls already does: - all the code that calls copyin/copyout - compat32 translation for all syscalls and all ioctls - compat_otheros translation as well The first of these has been routine in research OSes for 25+ years and offers no particular difficulties other than it'll take a fair amount of coding. The second and third follow directly from a good solution to the first, modulo some semantic concerns about schema translation that I believe aren't relevant for the things we need to do. (As in, anything semantically complicated is going to end up being written by hand anyway and the translation itself is about different representations of the same data.) Past experience (this will not be the first or I think even the second syscall marshalling generator I've had the pleasure of writing) says is that doing this well requires real compiler tooling and infrastructure. The copyin/copyout code can be, but should not be, generated with just an awk script. Going beyond that requires a real tool with sources that get compiled. Meanwhile looking at the large amount of cutpaste in the current makesyscalls.sh, the number of similar output files already generated, and talking with Kamil about what's needed by sanitizers, makes me think that at least part of the generation should be driven by output templates. That is, you run some tool and you feed it an output template that describes one set of things and you get the in-kernel copyin/copyout code. Then, you feed it some other template and out comes the rump version, a third template and you get sanitizer wrappers, etc. etc. I will need to think some about how to do this effectively (it is not as straightforward as just spewing code out) but I don't think it is going to be particularly difficult. However, it means that the tool needs to be installed in the system and so does the master description file for at least NetBSD's own system calls. (Currently, it seems that the llvm sanitizers build reads syscalls.master itself from a source tree, so it needs a system source tree to build, which is bad.) This raises two points that need to be bikeshedded: (1) What's the new tool called, and where does it live in the tree? "usr.bin/makesyscalls" is fine with me but ymmv. (2) What is the installed syscall description file called and where does it go? It is likely to be derived from (i.e., not the same as) syscalls.master. It isn't a C header file so it doesn't belong in /usr/include. It isn't necessarily particularly human-readable. My suggestion would be to add a directory in /usr/share for API descriptions and put it there, something like maybe /usr/share/api/syscalls.def. Note that the eventual tool that gets committed will be written in C, but the development version will probably be written in something with stronger types. For this reason I expect to not be committing development versions until things are pretty much done. -- David A. Holland dholl...@netbsd.org
Re: makesyscalls
On Fri, Jun 12, 2020 at 04:40:28PM +0200, Reinoud Zandijk wrote: > > Yes, it can be rewritten in C as a subsequent step. *After* quite a > > bit of tidying. And no, I'm not doing that now. Among other problems, > > compiling it requires bikeshedding where to put it in the tree. Feel > > free to sort that out. > > I'd say 'C'. If the specification is read in, sanity checking can > be added on the read in datastructure too wich is hard to do in awk > and `friends'. Things like missing compat definitions, missing > syscall numbers etc can be printed out to be noted as non-existent > etc. I don't know about structure versioning and system calls as > for compat but generating them seems the right way to go. C is not a great language for writing code generators, but it's what we've got. There's nothing better that we want in base or that I'd be willing to suggest accepting an external dependence for. Anyway, the conclusion seems to me that I'm not going to check in the Python version of the script. -- David A. Holland dholl...@netbsd.org
Re: Firefox dysfunctional, need help with sys/kern/uipc_sem.c
Disaster averted thanks to how macOS this limitation :) I have a patch (thanks to nia) that avoids the need for process-shared semaphores, so we aren't in a bad shape. Will commit soon.
Re: pci_mapreg_map and BAR from `Bus space tutorial'
Hi. On 6/12/20 3:30 PM, Rocky Hotas wrote: I applied your patch and it works for me the same way. Thanks! Excellent, glad to hear that. As a sidenote: I found your bus_space_tutorial very useful, the only one available about this topic. For this problem, I suspended it at slide 47 of your pdf. There's also a good general tutorial about NetBSD drivers, by Jochen Kunz, that is referenced at the end of bus_space tutorial. My intention is to follow it entirely, and then to elaborate and expend it (adding comments, citations from the manpages), in order to keep a useful and up-to-date introduction for a newbie. Would you agree? Yes, definitely. Originally, the slides were used as a part of hands-on tutorial delivered by me during EuroBSDCon 2012 (and later for some commercial clients). The slides were not designed as a stand-alone learning material - I just used them to track the progress of a live tutorial, and emphasize important areas. So slides obviously lack any background information or comments. As you have probably noticed, the source to slides and examples is available on GitHub. However, if you are serious about expanding the tutorial please contact me off-list, as I am getting more and more hesitant to continue using GitHub for anything (I'll arrange a self-hosted repo). I hope to be able to follow the remainder of the tutorial by my own. But if some other problem could arise, can I contact you in future? Obviously only if and when strictly necessary. Sure, feel free to contact me. Due to time constraints, I cannot guarantee a timely response, but I am very much interested in any further problems, or general comments that you may have. P.S. I don't know if it's relevant, but something weird instead happens if I try to write 0x in the faa BAR. Before your patch, after the write, the BAR provided the value 0xFFF0: I was expecting 0xFFF0. After your patch, and after writing 0x, BAR showed an even weirder value: 0x000F. I used pcictl(8) for these operations. However, it all seems to work from the dmesg, so maybe they are due to the fact that this PCI device is not real. I honeslty have no idea, debugging this would require digging into gxemul internals. Best regards, Radoslaw
Firefox dysfunctional, need help with sys/kern/uipc_sem.c
Hi all,
I'd like to call attention to a bug we have:
http://gnats.netbsd.org/55386
At some point Firefox added support for running on multiple OS
processes. To do this, it uses a process-shared semaphores.
We used to not support them properly (rather: lied about supporting
them, but failed to implement in practice). This caused a different set
of issues in the past.
In NetBSD 9.x, thorpej implemented process-shared semaphores, but the
implementation is a bit weird to avoid breaking compatibility with the
struct choices done in the previous implementation.
It has one caveat remaining: it doesn't allow destroying a semaphore
from another process. This causes firefox to violently leak fds, and
eventually show corrupt output.
sys__ksem_destroy
...
/* Cannot destroy if we did't create it. */
KASSERT(fd == -1);
KASSERT(ks->ks_pshared_proc != NULL);
if (ks->ks_pshared_proc != curproc) {
error = EINVAL;
goto out;
}
Most of the web is usable with bumping sysctl kern.maxfiles, but it
doesn't seem to bump RLIMIT_NOFILE, so a few websites still fail.
It might be worthwhile to bump MAXFILES anyway, it's somewhat long
overdue.
It would be nice if more people looked at this problem, because it is
getting very hard to work-around this issue in Firefox. Our previous
workaround (entirely disable multiprocess firefox) can't display
google.com(!).
Thanks.
[PATCH] Add support for RUMP_USE_LIBC_ALLOCATORS
I propose to add a new option for building rumpkernel: RUMP_USE_LIBC_ALLOCATORS. This option wires the kernel allocators directly to the libc functions. This is useful for sanitizers with their fine-grained checks of allocated chunks. http://netbsd.org/~kamil/patch-00268-RUMP_USE_LIBC_ALLOCATORS.2.txt Does this code and approach look good? Is possible to improve this approach? There is a fallout with ATF test t_vm::uvmwait as it no longer passes as the memory limit is no longer respected. With this patch rumpkernel is now more sensitive to real memory access bugs. The immediate detected problem is with kthread_join() that attempts to join a thread that was freed. http://netbsd.org/~kamil/rump/heap-use-after-free.txt We use this patch during the ongoing GSoC so quick merge into src/ is wanted. signature.asc Description: OpenPGP digital signature
sys/rump/kern/lib/libsys_*/syscalls.master
Does anyone know what the files sys/rump/kern/lib/libsys_*/syscalls.master are for and/or how they're used? They don't seem to have been built with makesyscalls; there's some suggestion that makesyscalls might be run on them on the fly during a build (which would be wrong)... but the makefile logic for maybe doing that doesn't seem to be used. However, this is rump and the only things that are obvious are misleading. (The * in libsys_* expands to: linux, cygwin, sunos, for whatever that's worth.) -- David A. Holland dholl...@netbsd.org
