Re: Anonymous vnodes?

On Mon, Jun 26, 2023 at 06:13:17PM -0400, Theodore Preduta wrote: > Is it possible to create a vnode for a regular file in a file system > without linking the vnode to any directory, so that it disappears when > all open file descriptors to it are closed? (As far as I can tell, this > isn't possib

Re: Per-descriptor state

On Thu, May 04, 2023 at 09:58:49AM +0100, Robert Swindells wrote: > > David Holland wrote: > >On Sun, Apr 30, 2023 at 09:44:49AM -0400, Mouse wrote: > > > > Close-on-fork is apparently either coming or already here, not sure > > > > which, but it's also per-descriptor. > > > > > > I should proba

Re: kernel goes dark on boot

Am Tue, Apr 04, 2023 at 08:30:51AM + schrieb Emmanuel Dreyfus: > Debugging what happens after that is more tricky. This is assembly > code, I am not sure I can printf from there. I try to make the > machine reboot at startprog64() start to see if I just reach that > place. Look for beep_on_re

Re: #pragma once

Am Sat, Oct 15, 2022 at 07:21:35PM + schrieb Taylor R Campbell: > How reliable/consistent is toolchain support for it? Is it worth > adopting or is the benefit negligible over continuing to use > traditional #include guards? Likely problems with adopting it? Does it gain anything beside a ti

Re: Emulating missing linux syscalls

Am Tue, Apr 19, 2022 at 02:39:44AM +0530 schrieb Piyush Sachdeva: > On Sat, Apr 16, 2022 at 2:06 AM Joerg Sonnenberger wrote: > > > > Am Wed, Apr 13, 2022 at 09:51:31PM - schrieb Christos Zoulas: > > > In article , Joerg Sonnenberger > > > wrote: > >

Re: Emulating missing linux syscalls

Am Wed, Apr 13, 2022 at 09:51:31PM - schrieb Christos Zoulas: > In article , Joerg Sonnenberger > wrote: > >Am Tue, Apr 12, 2022 at 04:56:05PM - schrieb Christos Zoulas: > > >splice(2) as a concept is much older than the current Linux implementation. > >

Re: Emulating missing linux syscalls

Am Tue, Apr 12, 2022 at 04:56:05PM - schrieb Christos Zoulas: > In article , Joerg Sonnenberger > wrote: > >Am Tue, Apr 12, 2022 at 12:29:21PM - schrieb Christos Zoulas: > >> In article > >, > >> Piyush Sachdeva wrote: > >> >-=-=-=-=-=-

Re: Emulating missing linux syscalls

Am Tue, Apr 12, 2022 at 12:29:21PM - schrieb Christos Zoulas: > In article > , > Piyush Sachdeva wrote: > >-=-=-=-=-=- > > > >Dear Stephen Borrill, > >My name is Piyush, and I was looking into the > >'Emulating missing Linux syscalls' project hoping to contribute > >to this year's GSoC. > >

Re: ETOOMANYZLIBS

Am Thu, Mar 24, 2022 at 10:13:32PM +0100 schrieb Thomas Klausner: > riastradh pointed out that this probably needs to be applied to > > src/sys/net/zlib.c > > as well, but that code seems to be from an older zlib version and the > patch doesn't apply cleanly. > > Can it be changed to use common/

Re: valgrind

Am Tue, Mar 22, 2022 at 09:01:19PM + schrieb RVP: > On Tue, 22 Mar 2022, Joerg Sonnenberger wrote: > > > Am Mon, Mar 21, 2022 at 11:09:41PM + schrieb RVP: > > > Sanitizers are OK, but, they don't seem to work in some cases: > > > > Neither case is

Re: valgrind

Am Mon, Mar 21, 2022 at 11:09:41PM + schrieb RVP: > Sanitizers are OK, but, they don't seem to work in some cases: Neither case is a memory leak. They are both reachable memory allocations. Joerg

Re: membar_enter semantics

Am Mon, Feb 14, 2022 at 02:45:46AM + schrieb David Holland: > On Mon, Feb 14, 2022 at 03:12:29AM +0100, Joerg Sonnenberger wrote: > > Am Mon, Feb 14, 2022 at 02:01:13AM + schrieb David Holland: > > > In this case I would argue that the names should be membar_loa

Re: membar_enter semantics

Am Mon, Feb 14, 2022 at 02:01:13AM + schrieb David Holland: > In this case I would argue that the names should be membar_load_any() > and membar_any_store(). Kind of like with the BUSDMA_* flags, it is not clear from that name in which direction they work either. As in: is it a barrier that st

Re: timecounters

On Sat, Nov 13, 2021 at 02:25:22AM +, Emmanuel Dreyfus wrote: > x86 TSC: cycle count from CPU register. Very quick to read, but unreliable if > CPU frequency changes because of power saving. Also each CPU has its own > value (how do we cope with that?) It's even more complicated. For older x8

Re: Interrupt storms with wm(4)

On Fri, Oct 15, 2021 at 02:10:32AM +, Emmanuel Dreyfus wrote: > The wm0 interface gets a lot of interrupts. On low usage, CPU > is spent around 10% in interrupts. It can rise to more than 80%. > See below what systat vm says when the machine is quiet. > ioapic0 pin 16 is the wm0 interface. Is

Re: [PATCH] Move DRM-driver firmware from base to its own set, gpufw

On Thu, Sep 23, 2021 at 02:43:22PM +, coypu wrote: > This set is only installed on amd64,i386,evbarm. I wonder if we shouldn't allow re-triggering firmware load via either sysctl or drvctl and just move them to outside root. Even the option to load them from pkgsrc might be useful. Joerg

Re: kern.maxlockf for byte range lock limit

On Tue, Jul 13, 2021 at 06:37:57AM +, Emmanuel Dreyfus wrote: > On Tue, Jul 13, 2021 at 03:36:49AM +, David Holland wrote: > > Well, that was the idea; make it some factor times the current open > > file limit or something like that. Not sure why the existing limit is > > apparently per-use

Re: protect pmf from network drivers that don't provide if_stop

On Thu, Jul 01, 2021 at 06:47:08AM -0300, Jared McNeill wrote: > Not really a fan of this as it doesn't protect other potential if_stop users > (and "temporary fix" rarely is..). How about something like this instead? I was more thinking along the lines of doing the assert in that place. The lack

Re: maximum limit of files open with O_EXLOCK

On Mon, Jun 21, 2021 at 03:51:51AM +, David Holland wrote: > On Sat, Jun 19, 2021 at 08:12:38AM +, nia wrote: > > The Zig developer found the kernel limit: > > https://nxr.netbsd.org/xref/src/sys/kern/vfs_lockf.c#116 > > > > but it doesn't seem to be adjustable through sysctl. > > I w

Re: 9.1: boot-time delay? [WORKAROUND FOUND]

On Fri, May 28, 2021 at 03:14:24AM +0700, Robert Elz wrote: > Date:Thu, 27 May 2021 05:05:15 - (UTC) > From:mlel...@serpens.de (Michael van Elst) > Message-ID: > > | mlel...@serpens.de (Michael van Elst) writes: > | > | >Either direction mstohz or hztoms sho

Re: problem with USER_LDT in current 9.99.81

On Wed, Apr 28, 2021 at 10:54:22AM +0100, Dave Tyson wrote: > I don't know whether altering the LDT size will have any implications for the > SVS stuff, currently > > #define MAX_USERLDT_SIZE PAGE_SIZE > > appears in the above include files. > > I changed the define to be: > > #define MAX_USE

Re: regarding the changes to kernel entropy gathering

On Sun, Apr 04, 2021 at 11:47:10PM +0700, Robert Elz wrote: > If not, what prevents someone from reading (copying) the file from the > system while it is stopped (assessing the storage device via other methods) > and then knowing exactly what the seed is going to be when the system boots? That is

Re: regarding the changes to kernel entropy gathering

On Sun, Apr 04, 2021 at 03:32:08PM -0700, Greg A. Woods wrote: > At Mon, 05 Apr 2021 00:14:30 +0200 (CEST), Havard Eidnes > wrote: > Subject: Re: regarding the changes to kernel entropy gathering > > > > > What about architectures that have nothing like RDRAND/RDSEED? Are > > > they, effectively

Re: regarding the changes to kernel entropy gathering

On Mon, Apr 05, 2021 at 12:07:49AM +0200, Havard Eidnes wrote: > I am still of the fairly firm beleif that the mistrust in the > hardware vendors' ability to make a reasonable and robust > implementation is without foundation. It's not without foundation. Remember the first hardware RNG on x86? It

Re: regarding the changes to kernel entropy gathering

On Sun, Apr 04, 2021 at 09:24:56PM +, RVP wrote: > PS. Is there a way to get the bit-stream from the various in-kernel > sources so that we can run them through these sort of tests? That > way we can check--not intuit--how random the bit-streams they > produce really are. Part of the problem h

Re: regarding the changes to kernel entropy gathering

On Sun, Apr 04, 2021 at 02:16:41PM -0700, Paul Goyette wrote: > > Personally, I'm happy with anything that your average high school > > student is unlikely to be able to crack in an hour. I don't run > > a bank, or a military installation, and I'm not the NSA. If someone > > is prepared to put

Re: ACPI related performance trouble

On Thu, Feb 25, 2021 at 11:46:21AM +0100, Emmanuel Dreyfus wrote: > I just got two identical machines, let us call them glutamine and leucine. I > run ffmpeg4 to transcode H264 video to webm, and leucine is about 12 times > faster than glutamine. Have you compared the machdep sysctl? Joerg

Re: cmake hangs on kqueue

On Tue, Jan 12, 2021 at 01:20:39PM +0100, Martin Husemann wrote: > On Tue, Jan 12, 2021 at 01:11:00PM +0100, Manuel Bouyer wrote: > > I think I've seen some mails about a similar problem in the past few months > > but I don't remember the details (and couldn't find a PR about it either). > > That

Re: Temporary memory allocation from interrupt context

On Wed, Nov 11, 2020 at 10:44:45AM +0100, Martin Husemann wrote: > Consider the following pseudo-code running in softint context: Why do those items not have a link element inside, so that no additional memory allocation is necesary? Joerg

Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64

On Wed, Oct 21, 2020 at 08:58:36AM +0900, Rin Okuyama wrote: > I'm also one who feels hesitate to import Linux'ism into our basic > components. However, for this problem in particular, I still think > it is not a good choice to keep NetBSD support in driver-aarch64.c: > > (a) Our sysctl(3)-based i

Re: style change: explicitly permit braces for single statements

On Mon, Jul 13, 2020 at 09:18:18AM -0400, Ted Lemon wrote: > On Jul 13, 2020, at 9:13 AM, Mouse wrote: > > . I find the braces pure visual clutter in the latter. > > What really bugs me is when my code winds up with a security fail because I > wasn’t careful. If only we had compilers that coul

Re: stat(2) performance

On Mon, Jun 15, 2020 at 09:31:48PM +0100, Robert Swindells wrote: > > Doing a 'cvs update' feels really slow > > Running it under ktrace(1) shows it doing a stat(2) for every metadata > file in the tree. The machine sounds like it is hitting the disk for > every one. Is there any kind of cache fo

Re: TSC improvement

On Tue, Jun 09, 2020 at 05:16:27PM +, Taylor R Campbell wrote: > It's great to see improvements to our calibration of the TSC (and I > tend to agree that cpu_counter should be serializing, so that, e.g., > cpu_counter(); ...; cpu_counter() reliably measures time taken in the > ellipsis). I'm p

Re: Avoid UB in pslist.h (NULL + 0)

On Sun, Mar 22, 2020 at 12:50:16AM +, Taylor R Campbell wrote: > (b) Change how we invoke ubsan and the compiler by passing > -fno-delete-null-pointer-checks to clang. joerg objected to this > but I don't recall the details off the top of my head; joerg, can > you expand on your ar

Re: NULL pointer arithmetic issues

On Mon, Mar 09, 2020 at 09:50:50AM -0400, Aaron Ballman wrote: > On Sun, Mar 8, 2020 at 2:30 PM Taylor R Campbell > > I ask because in principle a conformant implementation could compile > > the NetBSD kernel into a useless blob that does nothing -- we rely on > > all sorts of behaviour relative to

Re: NULL pointer arithmetic issues

On Sun, Mar 08, 2020 at 03:33:57PM +0100, Kamil Rytarowski wrote: > There was also a request to make a proof that memcpy(NULL,NULL,0) is UB > and can be miscompiled. > > Here is a reproducer: > > http://netbsd.org/~kamil/memcpy-ub.c > > 131 kamil@rugged /tmp $ gcc -O0 memcpy.c > > 132 kamil@rug

Re: NULL pointer arithmetic issues

On Sun, Mar 08, 2020 at 03:30:02PM +0100, Kamil Rytarowski wrote: > NULL+x is now miscompiled by Clang/LLVM after this commit: > > https://reviews.llvm.org/rL369789 > > This broke various programs like: > > "Performing base + offset pointer arithmetic is only allowed when base > itself is not nu

Re: NULL pointer arithmetic issues

On Mon, Feb 24, 2020 at 11:42:01AM +0100, Kamil Rytarowski wrote: > Forbidding NULL pointer arithmetic is not just for C purists trolls. It > is now in C++ mainstream and already in C2x draft. This is not true. NULL pointer arithmetic and nullptr arithmetic are *very* different things. Do not conf

Re: NULL pointer arithmetic issues

On Sat, Feb 22, 2020 at 05:25:42PM +0100, Kamil Rytarowski wrote: > When running the ATF tests under MKLIBCSANITIZER [1], there are many > NULL pointer arithmetic issues . Which flags are the sanitizers using? Because I wouldn't be surprised if they just hit _PSLIST_VALIDATE_PTRS and friends. Joe

Re: Stripping down 8.0

On Wed, Jan 29, 2020 at 04:20:45PM -0500, Mouse wrote: > > I'd say, just drop the acpiwmi driver, you don't include any driver > > for acpiwmibus, so the acpiwmi driver is useless to you. > > I'm not sure whether the right fix is to drop acpiwmi or add back > acpiec or acpiecdt, so...what _is_ acp

Re: Proposal: Remove filemon(4); switch make meta to ktrace

On Mon, Jan 13, 2020 at 06:09:20AM -0500, Mouse wrote: > > - What instead? The attached patch (patch set make-meta-v2.patch; > > combined diff make-meta-v2.diff) replaces make's use of > > /dev/filemon by ktrace, in meta mode. > > How does this interact with someone ktracing a make run? If i

Re: Solving the last piece of the uvm_pageqlock problem

On Tue, Dec 24, 2019 at 10:08:01PM +, Andrew Doran wrote: > This is a diff against a tree containing the allocator patch I posted > previously: > > http://www.netbsd.org/~ad/2019/pdpol.diff I wanted to give this a spin before travelling, but it doesn't survive very long here. I get NULL

Re: ptrace(2) interface for TLSBASE

On Tue, Dec 03, 2019 at 05:11:49PM +0100, Kamil Rytarowski wrote: > TLSBASE is stored on a selection of ports in a dedicated mcontext entry, > out of gpregs. That's an implementation detail and IMO something we shouldn't leak outside the arch. Just provide an accessor for l_private. There are then

Re: Some minor improvements to select/poll

On Wed, Nov 20, 2019 at 09:38:56PM +, Andrew Doran wrote: > (1) Increase the maximum number of clusters from 32 to 64 for large systems. > kcpuset_t could potentially be used here but that's an excursion I don't > want to go on right now. uint32_t -> uint64_t is very simple. Careful a

Re: __{read,write}_once

On Mon, Nov 11, 2019 at 01:15:16PM -0500, Mouse wrote: > > Uninterruptible means exactly that, there is a clear before and after > > state and no interrupts can happen in between. > > Is uninterruptible all you care about? Or does it also need to be > atomic with respect to other CPUs? Eventuall

Re: __{read,write}_once

On Mon, Nov 11, 2019 at 11:51:26AM -0500, Mouse wrote: > >>> (2) Use uninterruptible memory operations in per CPU memory, > >>> aggregate passively on demand. > > Problem is that (2) is natively only present on CISC platforms in > > general. Most RISC platforms can't do RMW in one instruction. >

Re: __{read,write}_once

On Mon, Nov 11, 2019 at 02:39:26PM +0100, Maxime Villard wrote: > Le 11/11/2019 à 13:51, Joerg Sonnenberger a écrit : > > On Mon, Nov 11, 2019 at 11:02:47AM +0100, Maxime Villard wrote: > > > Typically in sys/uvm/uvm_fault.c there are several lockless stat > > >

Re: __{read,write}_once

On Mon, Nov 11, 2019 at 11:02:47AM +0100, Maxime Villard wrote: > Typically in sys/uvm/uvm_fault.c there are several lockless stat increments > like the following: > > /* Increment the counters.*/ > uvmexp.fltanget++; Wasn't the general consensus here to ideally have per-cpu counters

Re: alloca() in kernel code

On Sun, Oct 13, 2019 at 12:46:24AM +0200, Johnny Billquist wrote: > On 2019-10-12 20:47, Joerg Sonnenberger wrote: > > On Sat, Oct 12, 2019 at 08:13:25PM +0200, Johnny Billquist wrote: > > > On 2019-10-12 19:01, Emmanuel Dreyfus wrote: > > > > Mouse wrote: >

Re: alloca() in kernel code

On Sat, Oct 12, 2019 at 02:01:16AM +0200, Emmanuel Dreyfus wrote: > I recently encountered a situation where I had to deal with variable > length structure at a time where kernel dynamic allocator was not > initialized. You can borrow pages directly if the data is potentially larger. Joerg

Re: alloca() in kernel code

On Sat, Oct 12, 2019 at 08:13:25PM +0200, Johnny Billquist wrote: > On 2019-10-12 19:01, Emmanuel Dreyfus wrote: > > Mouse wrote: > > > > > I'm presumably missing something here, but what? > > > > I suspect Maxime's concern is about uncontrolled stack-based variable > > buffer, which could be us

Re: build.sh sets with xz (was Re: vfs cache timing changes)

On Fri, Sep 13, 2019 at 07:06:59AM +0200, Martin Husemann wrote: > I am not sure whether the xz compiled in tools supports the "-T threads" > option, but if it does, we can add "-T 0" to the default args and see how > much that improves things. Jörg, do you know this? It doesn't currently, since i

Re: /dev/random is hot garbage

On Mon, Jul 22, 2019 at 04:36:41PM +, paul.kon...@dell.com wrote: > > > > On Jul 22, 2019, at 10:52 AM, Joerg Sonnenberger wrote: > > > > > > [EXTERNAL EMAIL] > > > > On Sun, Jul 21, 2019 at 09:13:48PM +, paul.kon...@dell.com wrote: >

Re: /dev/random is hot garbage

On Sun, Jul 21, 2019 at 09:13:48PM +, paul.kon...@dell.com wrote: > > > > On Jul 21, 2019, at 5:03 PM, Joerg Sonnenberger wrote: > > > > > > [EXTERNAL EMAIL] > > > > On Sun, Jul 21, 2019 at 08:50:30PM +, paul.kon...@dell.com wrote: > &g

Re: /dev/random is hot garbage

On Sun, Jul 21, 2019 at 08:50:30PM +, paul.kon...@dell.com wrote: > /dev/urandom is equivalent to /dev/random if there is adequate entropy, > but it will also deliver random numbers not suitable for cryptography before > that time. This is somewhat misleading. The problem is that with an unkn

Re: /dev/random is hot garbage

On Sun, Jul 21, 2019 at 07:20:08PM +, Taylor R Campbell wrote: > This is _locally_ sensible for a library that may have many users > beyond a compiler. No, it can be sensible behavior to allow *optionally* checking. But it is certainly not sensible default behavior for a library. Joerg

Re: re-enabling debugging of 32 bit processes with 64 bit debugger

On Sat, Jun 29, 2019 at 08:03:59PM -, Christos Zoulas wrote: > In article > , > Andrew Cagney wrote: > > > >Having 32-bit and 64-bit debuggers isn't sufficient. Specifically, it > >can't handle an exec() call where the new executable has a different > >ISA; and this imnsho is a must have. >

Re: Enable functionality by default

On Tue, Apr 16, 2019 at 04:55:41PM +0100, Sevan Janiyan wrote: > Not all of our network drivers support altq altq has some significant impact on the network layer and I would expect just enabling it to have a measureable impact on netio. Joerg

Re: Regarding the ULTRIX and OSF1 compats

On Sun, Mar 17, 2019 at 03:35:02AM +, m...@netbsd.org wrote: > I'm quite annoyed to hear the complaints about the VAX compiler > situation. Many people have put in a lot of work to keep it functional > with newer versions of GCC, and to fix bugs. Oh, complaining about the VAX compiler situatio

Re: RFC: New userspace fetch/store API

On Tue, Feb 26, 2019 at 01:59:42PM +0100, Rhialto wrote: > On Mon 25 Feb 2019 at 18:10:20 +, Eduardo Horvath wrote: > > I'd do something like: > > > > uint64_t ufetch_64(const uint64_t *uaddr, int *errp); > > > > where *errp needs to be initialized to zero and is set on fault so you can > >

Re: RFC: New userspace fetch/store API

On Sat, Feb 23, 2019 at 03:26:34PM -0800, Jason Thorpe wrote: > A project I’m working on has a need for a proper “int” size fetch / > store on all platforms, and it seems best to just tidy the whole mess > up. So, I am proposing a new replacement user fetch/store API. I'm far more inclined to jus

Re: Support for "pshared" POSIX semaphores

On Sat, Feb 02, 2019 at 02:11:47PM -0800, Jason Thorpe wrote: > Ok, updated patch: > > > https://patch-diff.githubusercontent.com/raw/thorpej/netbsd-src/pull/5.diff > > > I went an used a simple hash table with

Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev/usb)

On Sun, Jan 06, 2019 at 05:26:36PM -0500, Christos Zoulas wrote: > Shouldn't the compiler know how to do this right by padding around the > structure that needs alignment and assuming the default alignment for > the enclosing structure? Doesn't help if malloc will just return 64bit aligned memory.

Re: RFC: vioif(4) multiqueue support

On Wed, Dec 26, 2018 at 02:37:02AM +, Taylor R Campbell wrote: > > +static int > > +vioif_alloc_queues(struct vioif_softc *sc) > > +{ > > + int nvq_pairs = sc->sc_max_nvq_pairs; > > + int nvqs = nvq_pairs * 2; > > + int i; > > + > > + sc->sc_rxq = kmem_zalloc(sizeof(sc->sc_rxq[0]) * nvq

Re: Importing libraries for the kernel

On Fri, Dec 14, 2018 at 01:00:25PM -0500, Mouse wrote: > >>> [...] I have serious concerns for doing asymmetric cryptography in > >>> the kernel [...] > >> Can you clarify the concerns? > > Asymmetrical cryptography is slow and complex. [...] The > > implementation is non-trivial [...] > > Didn'

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

On Thu, Dec 13, 2018 at 02:37:06AM +0100, Kamil Rytarowski wrote: > In real life it's often needed to store time_t pointing before the UNIX > epoch. Again, I quite disagree and believe that you are confusing two different things. It makes perfect sense in certain applications to store time as rela

Re: Importing libraries for the kernel

On Thu, Dec 13, 2018 at 11:07:23PM +0900, Ryota Ozaki wrote: > On Thu, Dec 13, 2018 at 6:30 AM Joerg Sonnenberger wrote: > > > > On Thu, Dec 13, 2018 at 12:58:21AM +0900, Ryota Ozaki wrote: > > > Before that, I want to ask about how to import cryptography > &

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

On Wed, Dec 12, 2018 at 08:46:33PM +0100, Michał Górny wrote: > While researching libc++ test failures, I've discovered that NetBSD > suffers from the same issue as FreeBSD -- that is, both the userspace > tooling and the kernel have problems with (time_t)-1 timestamp, > i.e. one second before the

Re: Importing libraries for the kernel

On Thu, Dec 13, 2018 at 12:58:21AM +0900, Ryota Ozaki wrote: > Before that, I want to ask about how to import cryptography > libraries needed tor the implementation. The libraries are > libb2[1] and libsodium[2]: the former is for blake2s and > the latter is for curve25519 and [x]chacha20-poly1305

Re: libnv

On Mon, Aug 27, 2018 at 01:39:38AM +0100, Mindaugas Rasiukevicius wrote: > Hi, > > Here is patch to import the FreeBSD's libnv library: > > http://www.netbsd.org/~rmind/libnv.diff I don't think anything has changed since the last time this was discussed, so I consider this a really, really wrong

Re: Too many PMC implementations

On Fri, Aug 17, 2018 at 04:20:30PM +0200, Maxime Villard wrote: > Le 10/08/2018 à 11:40, Maxime Villard a écrit : > > I saw the thread [Re: Sample based profiling] on tech-userlevel@, I'm not > > subscribed to this list but I'm answering here because it's related to > > tprof among other things. >

Re: 8.0 performance issue when running build.sh?

On Fri, Aug 10, 2018 at 12:29:49AM +0200, Joerg Sonnenberger wrote: > On Thu, Aug 09, 2018 at 08:14:57PM +0200, Jaromír Doleček wrote: > > 2018-08-09 19:40 GMT+02:00 Thor Lancelot Simon : > > > On Thu, Aug 09, 2018 at 10:10:07AM +0200, Martin Husemann wrote: > > >

Re: 8.0 performance issue when running build.sh?

On Thu, Aug 09, 2018 at 08:14:57PM +0200, Jaromír Doleček wrote: > 2018-08-09 19:40 GMT+02:00 Thor Lancelot Simon : > > On Thu, Aug 09, 2018 at 10:10:07AM +0200, Martin Husemann wrote: > >> 100.002054 14.18 kernel_lock > >> 47.43 846 6.72 kernel_lockfileass

Re: hashtables

On Tue, Jul 24, 2018 at 05:03:56PM -0700, bch wrote: > Does nbperf(1) suit any need? I'm wondering the same. It seems to essentially switch between a fixed set of hash tables. Joerg

Re: Adding a boot flag for No ASLR

On Tue, Jul 24, 2018 at 02:08:53PM +0200, Kamil Rytarowski wrote: > I propose to move the code disabling PaX ASLR from bootloader and kernel > as proposed in the patch by Siddharth and introduce it directly into the > sanitizer, We can alter the CheckASLR() routine specific to NetBSD, with > the fo

Re: Adding a boot flag for No ASLR

On Tue, Jul 24, 2018 at 06:44:52AM +0200, Martin Husemann wrote: > On Mon, Jul 23, 2018 at 11:02:04PM +0200, Kamil Rytarowski wrote: > > We need to maintain a function to translate certain ranges to > > shadow/meta/origin/etc. We cannot map arbitrarily wide ranges to them. > > Can we extend the pa

Re: Adding a boot flag for No ASLR

On Mon, Jul 23, 2018 at 07:13:49PM +0200, Kamil Rytarowski wrote: > We need to have stack, heap and code of a program in predictable (and > quite narrow) ranges and thus ASLR disabled or less aggressive. What for? Nothing in the sanitizer design should require that. The only requirement should be

Re: Adding a boot flag for No ASLR

On Mon, Jul 23, 2018 at 06:24:09PM +0530, Siddharth Muralee wrote: > > > > > > (1) An implementation detail of userland shouldn't be leaked into the > > kernel boot (!) process. > > > > Okay. I think this makes sense(I am still pretty new to NetBSD) - Can you > suggest some other location/config t

Re: Adding a boot flag for No ASLR

On Mon, Jul 23, 2018 at 06:11:49PM +0530, Siddharth Muralee wrote: > Hello, >I have recently been working on adding a new boot flag for disabling > ASLR during boot. I feel that this is useful since MKSANITZER userland > (specifically Address Sanitizer, Thread Sanitizer, and Memory Sanitizer) >

Re: ./build.sh -k feature request (was Re: GENERIC Kernel Build errors with -fsanitize=undefined option enabled)

On Mon, Jun 25, 2018 at 08:23:22PM +0200, Reinoud Zandijk wrote: > On Sun, Jun 24, 2018 at 10:01:42PM +0200, Reinoud Zandijk wrote: > > On Wed, May 30, 2018 at 07:11:19PM +0800, Harry Pantazis wrote: > > > Continuing.. > > > > > > This first errors are located in > > > src/sys/external/bsd/drm2/di

Re: Looking for re(4) help

On Fri, Jun 22, 2018 at 01:38:28PM -0400, mo...@credil.org wrote: > So far I've drawn a complete blank looking for hardware documentation; You have searched just for the 8168 datasheet, have you? At least for older revisions, you can easily find the register description. Joerg

Re: Leaking kernel stack data in struct padding

On Wed, Jun 13, 2018 at 02:16:30PM +0300, Valery Ushakov wrote: > but I wonder if this scrubbing should be moved into > timespec_to_timespec50() - after all the most likley use of the compat > struct is to write or copyout it in the compat code, so the same > problem probably happens elsewhere. Ye

Re: Potential new syscall

On Tue, Apr 03, 2018 at 09:08:15AM +0700, Robert Elz wrote: > Kamil - "just use fork" is a very common response, but no matter how > fork gets implemented, vfork() when used correctly always performs > better by huge margins. But most of those cases are handled just as well by posix_spawn. Which d

Re: mmap implementation advice needed.

On Fri, Mar 30, 2018 at 04:22:29PM -0400, Mouse wrote: > And I (and ragge, I think it was) misspoke. It doesn't quite require > 128K of contiguous physical space. It needs two 64K blocks of > physically contiguous space, both within the block that maps system > space. (Nothing says that P0 PTEs

Re: mmap implementation advice needed.

On Fri, Mar 30, 2018 at 01:10:37PM -0400, Mouse wrote: > It takes 4 bytes of PTE to map 512 bytes of VA. (The VAX uses the > small, by today's standards, page size of 512 bytes.) So 2G of > userland space requires 16M of PTEs. Those PTEs must be in system > virtual space. And that 16M of system

Re: mmap implementation advice needed.

On Fri, Mar 30, 2018 at 11:33:48AM +0200, Anders Magnusson wrote: > Notes about vax memory management if someone is wondering: > - 2 areas (P0 and P1) of size 1G each, P0 grows from bottom, P1 grows from > top (intended for stack). AFAICT, VAX uses a max userland address of 2G, so what exactly is

Re: Fixing excessive shootdowns during FFS read (kern/53124) on x86

On Sun, Mar 25, 2018 at 07:24:25PM +0200, Maxime Villard wrote: > Le 25/03/2018 à 17:27, Joerg Sonnenberger a écrit : > > The other question is whether we can't just use the direct map for this > > on amd64 and similar platforms? > > no, because nothing guarant

Re: Fixing excessive shootdowns during FFS read (kern/53124) on x86

On Sun, Mar 25, 2018 at 03:19:28PM -, Michael van Elst wrote: > jo...@bec.de (Joerg Sonnenberger) writes: > > >What about having a passive unmap as fourth option? I.e. when unmapping > >in the transfer map, just add them to a FIFO. Process the FIFO on each > >CPU w

Re: Fixing excessive shootdowns during FFS read (kern/53124) on x86

On Sat, Mar 24, 2018 at 08:42:34PM +0100, Jaromír Doleček wrote: > The problem there is that FFS triggers a pathologic case. I/O transfer maps > and then unmaps each block into kernel pmap, so that the data could be > copied into user memory. This triggers TLB shootdown IPIs for each FS > block, se

Re: Let callout_reset return if it reschedules a pending callout

On Thu, Mar 01, 2018 at 01:58:29AM +0900, Ryota Ozaki wrote: > On Wed, Feb 28, 2018 at 10:11 PM, Joerg Sonnenberger wrote: > > On Wed, Feb 28, 2018 at 05:47:13PM +0900, Ryota Ozaki wrote: > >> The feature is useful when you have a reference to an object that is > >> p

Re: Let callout_reset return if it reschedules a pending callout

On Wed, Feb 28, 2018 at 05:47:13PM +0900, Ryota Ozaki wrote: > The feature is useful when you have a reference to an object that is > passed to a callout. In this case you need to take care of a > reference leak on callout_reset (and other APIs); it silently > reschedules (IOW cancels) a pending ca

Re: gcc: optimizations, and stack traces

On Sun, Feb 11, 2018 at 04:13:56PM +0700, Robert Elz wrote: > Date:Sun, 11 Feb 2018 09:11:45 +0100 > From:Maxime Villard > Message-ID: <2c83e9d9-f49c-479b-7a4c-1df581a2b...@m00nbsd.net> > > | So we have the same problem, and we need to find a way > | to tell GCC t

Re: gcc: optimizations, and stack traces

On Fri, Feb 09, 2018 at 11:23:17AM +0100, Maxime Villard wrote: > It implies that if a bug occurs _before_ these two instructions are executed, > we have a %rbp that points to the _previous_ function, the one we got called > from. And therefore, GDB does not display the current function (where the

Re: Bunch of bugs reported by Ilja van Sprundel

On Mon, Jan 29, 2018 at 10:16:05PM +0100, Kamil Rytarowski wrote: > On 29.01.2018 22:01, Joerg Sonnenberger wrote: > > On Mon, Jan 29, 2018 at 09:58:16PM +0100, Kamil Rytarowski wrote: > >> Another point is to set a rule that ABI is stable between patch versions > >> an

Re: Bunch of bugs reported by Ilja van Sprundel

On Mon, Jan 29, 2018 at 09:58:16PM +0100, Kamil Rytarowski wrote: > Another point is to set a rule that ABI is stable between patch versions > and binary packages (prebuilt software) still works as-is. I'm observing > now users who abandon researching this OS just because a patch version > of kerbe

Re: Spectre

On Wed, Jan 17, 2018 at 09:38:27PM -0500, Mouse wrote: > But, on the other hand, I can easily imagine a CPU designer looking at > it and saying "What's the big deal if this code can read that location? > It can get it anytime it wants with a simple load instruction anyway.", > something I have trou

Re: Proposal to obsolete SYS_pipe

On Sun, Dec 24, 2017 at 10:25:15PM +0100, Kamil Rytarowski wrote: > It is a special syscall that returns two integers from one function > call. Fanciness is not compatible with regular C syntax and it demands > per-cpu assembly wrappers and rump-kernel workarounds. It's not easily > usable with sys

Re: workqueue_drain

On Thu, Dec 21, 2017 at 05:32:58AM +0800, Paul Goyette wrote: > I'm not totally convinced here. It might be useful to wait for a > particular work to be finished in order to allow it to be enqueued > again (no work can be enqueued if already in the queue). But I don't > see how "remember the last

Re: RFC: ipsec(4) pseudo interface

On Mon, Dec 18, 2017 at 06:49:44PM +0900, Kengo NAKAHARA wrote: > (a) Add if_ipsec.4 > (b) move current ipsec.4(for ipsec protocol) to ipsec.9, and then > add ipsec.4(for ipsec pseudo interface) > (c) any other I'd call it either ifipsec(4) or ipsecif(4). Joerg

Re: kernel condvars: how to use?

On Thu, Dec 07, 2017 at 06:24:22PM -0500, Mouse wrote: > So I wrote some code using a condvar and a mutex, and the system > promptly deadlocked. I got into ddb, which told me it was inside > intr_biglock_wrapper(): Did you set the IPL for your mutex correctly? Adaptive mutexes must not be shared

  1   2   3   4   5   6   >