Re: TSC improvement

> Date: Wed, 10 Jun 2020 23:11:32 + > From: Andrew Doran > > On Tue, Jun 09, 2020 at 05:16:27PM +0000, Taylor R Campbell wrote: > > > At the same time, I wonder whether we should _also_: > > > > 1. Modify the tsc timecounter so that it uses

Re: TSC improvement

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). At the same time, I wonder whether we should _also_: 1. Modify the tsc

Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP

> Date: Mon, 18 May 2020 17:51:51 -0400 > From: Thor Lancelot Simon > > On Mon, May 18, 2020 at 09:08:14PM +0100, Alexander Nasonov wrote: > > matthew green wrote: > > > what's the use-case for disabling encrypted swap later? > > > > It might be too slow on some machines. > > > > > i'd argue

Re: sys/idtype.h unused enumeration values

> Date: Mon, 18 May 2020 21:40:16 +0200 > From: Kamil Rytarowski > > If I delete P_TASKID ... P_P_CPUID ones, P_SETID will be reordered (but > we can force the number anyway). If I delete P_CID there is an inelegant > hole. Naturally P_SETID -> P_CID can fill the gap. > > This is in theory ABI

Re: sys/idtype.h unused enumeration values

> Date: Mon, 18 May 2020 21:11:36 +0200 > From: Kamil Rytarowski > > On 18.05.2020 20:24, Robert Elz wrote: > > Date:Mon, 18 May 2020 19:45:55 +0200 > > From:Kamil Rytarowski > > Message-ID: > > > > | I have got a local use-case for another P_type (premature to

Re: Initial entropy with no HWRNG

[trimming cc list to tech-crypto] > Date: Tue, 12 May 2020 11:45:58 -0400 > From: Thor Lancelot Simon > > 1) It's hard to understand how many bits of entropy to assign to a >sample from one of these sources. [...] > >The delta estimator _was_ good for these things, particularly for >

getrandom and getentropy

tropy=3=0=FreeBSD+12.1-RELEASE+and+Ports [8] rust-random manual, struct rand::rngs::OsRng, 2020-05-01. https://rust-random.github.io/rand/rand/rngs/struct.OsRng.html >From c56cbc75071e66f014528d40e0e8c48c395f494d Mon Sep 17 00:00:00 2001 From: Taylor R Campbell Date: Mon, 13 Jan 2020 22:26:24 +

Re: Reduce contention on fstrans_lock

> Date: Sat, 4 Apr 2020 14:37:44 -0700 > From: Jason Thorpe > > +static int > +fstrans_lwp_ctor(void *arg, void *obj, int flags) > +{ > + struct fstrans_lwp_info *fli = obj; > + > + memset(fli, 0, sizeof(*fli)); > + membar_sync(); > + mutex_enter(_lock); > +

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

> Date: Sun, 22 Mar 2020 03:30:56 +0100 > From: Kamil Rytarowski > > On 22.03.2020 01:50, Taylor R Campbell wrote: > > So far, after several weeks of discussion, nobody has presented a case > > that there is a credible thread of a compiler actually misbehav

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

> Date: Sun, 22 Mar 2020 00:03:57 +0100 > From: Kamil Rytarowski > > I propose to change the fun(pointer + 0) logic with fun(pointer, 0). I don't think this is a good approach -- it requires modifying code further and further away from the relevant part. But let's step back a moment. So far,

Re: Please review: lookup changes

> Date: Mon, 9 Mar 2020 19:59:03 + > From: Andrew Doran > > As far as I recall layer vnodes persist unless recycled like any other > vnode, so there should be nothing special happening there around contention > due to lifecycle. I think you could cache or transpose the cached names > above,

Re: Please review: lookup changes

> Date: Thu, 5 Mar 2020 22:48:25 + > From: Andrew Doran > > I'd like to merge the changes on the ad-namecache branch, and would > appreciate any code review. The motivation for these changes is, as > you might guess, performance. I put an overview below. I won't be > merging this for a

Re: NULL pointer arithmetic issues

> Date: Sun, 8 Mar 2020 20:52:29 +0300 > From: Roman Lebedev > > so we are allowed to lower that in clang front-end as: > > int > statu(char *a) > { > __builtin_assume(a != NULL); > a += getuid() - geteuid(); > __builtin_assume(a != NULL); Allowed, yes. What I'm wondering is whether

Re: NULL pointer arithmetic issues

Thanks for doing the research. > Date: Sun, 8 Mar 2020 15:30:02 +0100 > From: Kamil Rytarowski > > NULL+0 was added to UBSan proactively as it is as of today not > miscompiled, but it is planned to so in not so distant time. It is a > chicken-egg problem. If you say it is planned, can you

Re: NULL pointer arithmetic issues

> Date: Mon, 24 Feb 2020 11:42:01 +0100 > From: Kamil Rytarowski > > Forbidding NULL pointer arithmetic is not just for C purists trolls. It > is now in C++ mainstream and already in C2x draft. > > The newer C standard will most likely (already accepted by the > committee) adopt nullptr on par

Re: NULL pointer arithmetic issues

> Date: Sun, 23 Feb 2020 22:51:08 +0100 > From: Kamil Rytarowski > > On 23.02.2020 20:08, Taylor R Campbell wrote: > Date: Sun, 23 Feb 2020 22:51:08 +0100 > From: Kamil Rytarowski > > On 23.02.2020 20:08, Taylor R Campbell wrote: > >> Date: Sat, 22 Feb 202

Re: NULL pointer arithmetic issues

> Date: Sat, 22 Feb 2020 17:25:42 +0100 > From: Kamil Rytarowski > > When running the ATF tests under MKLIBCSANITIZER [1], there are many > NULL pointer arithmetic issues . > > http://netbsd.org/~kamil/mksanitizer-reports/ubsan-2020-02-22-null-pointer.txt > > These issues are in macros like: >

Re: config_mounroot - spinout while attaching nouveaufb0 on amd64 with LOCKDEBUG

> Date: Mon, 17 Feb 2020 00:29:03 +0100 > From: Jaromír Doleček > > while debugging the MSI attachment for nouveaufb0, I've got several > times spinout panic like one below. It doesn't happen on every boot, > but on almost every one. > > I confirmed via ddb that this happens due to

Re: closing pad(4) before audio(4) causes panic

> Date: Sun, 02 Feb 2020 14:25:12 +0900 > From: Tetsuya Isaki > > According to audio.c comment, vdevgone() calls close(). But it is > not called actually. vdevgone calls VOP_REVOKE on the vnode, which _used_ to call audio_close, but it does essentially nothing for cloning file descriptors as

Re: fault(4)

> Date: Sat, 8 Feb 2020 06:19:43 -0800 (PST) > From: Paul Goyette > > If this is a device on which you can use ioctl() to configure, why is > it not stored under sys/dev and why is it not included in kernel config > with pseudo-device directive (and corresponding files.kern changes)? There's no

Re: [PATCH] percpu_create -- associate ctors and dtors

> Date: Thu, 30 Jan 2020 02:46:42 + > From: Taylor R Campbell > > The attached patch set [...] Some day, perhaps I will not be bad at attachments. That day, however, has yet to come. >From 32542bb28f86862f91fcf874f2b7494d4df00c62 Mon Sep 17 00:00:00 2001 From: Taylor R Camp

[PATCH] percpu_create -- associate ctors and dtors

We have a number of abuses of percpu_foreach in tree: percpu_foreach forbids sleeping on allocation, but a number of subsystems use it to allocate memory to which pointers are stored in percpu objects because the percpu objects themselves may move around in memory. Each ad hoc abuse of

Re: percpu_foreach() does not execute remotely

[Cc'ing the wizards at IIJ because a diagnostic measure we're discussing may require adapting the network stack.] > Date: Wed, 29 Jan 2020 05:43:39 -0800 > From: Jason Thorpe > > > On Jan 28, 2020, at 9:46 PM, Taylor R Campbell > > wrote: > > > > Normally sle

Re: percpu_foreach() does not execute remotely

> Date: Tue, 28 Jan 2020 20:49:50 -0800 > From: Jason Thorpe > > What happens if: > > oink = percpu_getref(...); > ... > mutex_enter(...); // blocks for a long time for whatever reason. > // while we're blocked, someone else does a percpu_alloc() that results >

Re: percpu_foreach() does not execute remotely

> Date: Tue, 28 Jan 2020 20:00:00 -0800 > From: Jason Thorpe > > Hm, actually, I think you are right, but because of a property of > xcalls themselves... > > -- percpu_cpu_swap() is a low-pri xcall, and thus won't run > concurrently with a low-pri percpu_foreach_xcall(), so no need to > grab

Re: percpu_foreach() does not execute remotely

> Date: Tue, 28 Jan 2020 18:54:59 -0800 > From: Jason Thorpe > > Something like this. I haven't tested this yet, but I will shortly. > Only high-pri xcalls are supported in this -- to make low-pri xcalls > work, you'd need to change how percpu_cpu_swap() interlocks with > percpu_foreach().

Re: percpu_foreach() does not execute remotely

> Date: Tue, 28 Jan 2020 09:08:22 -0800 > From: Jason Thorpe > > >> 2- If I were to use xc_broadcast(), then in the case of network > >> protocol / interface stats, I would need to use either atomic > >> operations or add some other synchronization into the shared > >> "exported copy" of the

Re: percpu_foreach() does not execute remotely

> Date: Tue, 28 Jan 2020 08:52:35 -0800 > From: Jason Thorpe > > 1- This seems to be a general issue with percpu_foreach(). I mean, > one of the main purposes of per-cpu storage is that other CPUs don't > touch it, and percpu_foreach() completely violates the POLA in this > regard. I see

Re: percpu_foreach() does not execute remotely

> Date: Mon, 27 Jan 2020 18:36:17 -0800 > From: Jason Thorpe > > So, percpu_foreach() is pretty handy for enumerating data that's > managed on a per-cpu basis. But there's a problem ... it does not > actually execute the callback on the remote CPU, instead getting a > pointer to the remote data

Re: libc.so's vmobjlock / v_interlock

> Date: Sun, 19 Jan 2020 21:50:24 + > From: Andrew Doran > > The biggest single remaining concurency problem is the mutex on libc.so's > uvm_object / vnode. It pops up in a number of places, but most clearly seen > above the "uvm_fault_internal" box. > > I think making the vmobjlock /

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

> Date: Mon, 13 Jan 2020 06:09:20 -0500 (EST) > From: Mouse > > > - 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

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

? Thoughts? >From 656117e6a394087bbf134a8a1c09b0ff9248f4cc Mon Sep 17 00:00:00 2001 From: Taylor R Campbell Date: Mon, 23 Dec 2019 05:41:16 + Subject: [PATCH 1/2] Reimplement make(1) meta mode without filemon(4). --- usr.bin/make/Makefile | 7 +- usr.bin/make/compat.c | 2 +- usr.bin/m

Re: Rump dependencies (5.2)?

> Date: Sun, 12 Jan 2020 21:56:30 -0500 (EST) > From: Mouse > > But now, when I try to build the world, rump_nfs fails to link, citing > as undefined two routines I added to uipc_usrreq.c which are referred > to from uipc_syscalls.c. > > This leads me to ask - and I realize it's possible nobody

Re: [PATCH] Kernel entropy rework

> Date: Thu, 26 Dec 2019 20:16:20 + > From: m...@netbsd.org > > On Sat, Dec 21, 2019 at 10:08:20PM +0000, Taylor R Campbell wrote: > > - Replace SHA-1/LFSR entropy pool by Keccak sponge. > > The peanut gallery would like to inquire if you have a secret BLAKE2 >

Re: [PATCH v4 2/4] Fix alignment when reading core notes

> Date: Tue, 24 Dec 2019 07:52:14 +0100 > From: Micha� Górny > > On Mon, 2019-12-23 at 16:17 +, Christos Zoulas wrote: > > In article <20191222164104.165346-2-mgo...@gentoo.org>, > > Micha� Górny wrote: > > > Both desc and note header needs to be aligned. Therefore, we need > > > to

Re: [PATCH] Kernel entropy rework

> Date: Sun, 22 Dec 2019 01:27:58 + > From: > > > On Dec 21, 2019, at 5:08 PM, Taylor R Campbell wrote: > > - For (e.g.) keyboard interrupt and network packet timings, this > >is zero, because an adversary can cause events to happen with &

Re: [PATCH] Address USB abort races

> Date: Mon, 23 Dec 2019 14:17:18 + > From: Nick Hudson > > - Any reason that dwc2 and ahci didn't get the conversion? At least dwc2 >should be done - I'm not sure ahci ever worked, but I've tried to keep >it up-to-date in the past. slhci probably needs some love too. I forgot to

Re: [PATCH] Kernel entropy rework

I guess I should have included a single unified diff rather than just a git format-patch set. From a CVS tree, the attached entropy-unified.patch can be applied with cd /path/to/src && patch -p1 < /path/to/entropy-unified.patch (And from a git tree, you can apply the patch set in the original

[PATCH] Address USB abort races

t; -> wake and acquire lock -> xfer->ux_status = CANCELLED -> usb_transfer_complete(xfer) >From d1ffd7e3b7b26ba65542c5ab4289d5260daf6b25 Mon Sep 17 00:00:00 2001 From: Taylor R Campbell Date: Fri, 10 Aug 2018 05:51:54 + Subject: [PATCH 1/7] Teach usb_rem_task to return

New cpu_count races; seqlocks?

It is great to get rid of global contention over a bunch of counters that don't need to be read exactly. However, the new cpu_count logic is racy -- particularly on 32-bit platforms, where it's not simply a matter of reading stale values but a matter of reading total garbage: /* sys/cpu_data.h

Re: Why NetBSD x86's bus_space_barrier does not use [sml]fence?

> Date: Mon, 2 Dec 2019 15:54:34 +0900 > From: Masanobu SAITOH > > On 2019/12/02 15:48, s ymgch wrote: > >> I had a misunderstanding. The driver uses BUS_SPACE_MAP_PREFETCHABLE > >> specified in PCI configuration space. > > This is well known pitfall: > >

Re: Why NetBSD x86's bus_space_barrier does not use [sml]fence?

> Date: Fri, 29 Nov 2019 14:49:33 + > From: Andrew Doran > > It no, the CALL instruction that calls bus_space_barrier() produces a write > to the stack when storing the return address. On x86, stores are totally > ordered, and loads are never reordered around stores. No further barrier >

Re: FYI: mb(9) API is finally going away

The mb(9) API is now gone, except within sys/arch/mips where it is used inside __cpu_simple_lock -- there were too many ifdefs across components for me to disentangle, and the logic seems to be completely bonkers, e.g. on Octeon __cpu_simple_unlock issues a memory barrier _after_ the store to

Re: __{read,write}_once

> Date: Sun, 24 Nov 2019 19:25:52 + > From: Taylor R Campbell > > This thread is not converging on consensus, so we're discussing the > semantics and naming of these operations as core and will come back > with a decision by the end of the week. We (core) careful

FYI: mb(9) API is finally going away

FYI: The mb(9) API -- consisting of the mb_read, mb_write, and mb_memory memory barriers -- was incomplete for users (failed to cover important use cases) and incompletely defined (not defined on some platforms like x86). It was intended to be removed over a decade ago in favour of the

Re: __{read,write}_once

> Date: Wed, 6 Nov 2019 12:31:37 +0100 > From: Maxime Villard > > There are cases in the kernel where we read/write global memory locklessly, > and accept the races either because it is part of the design (eg low-level > scheduling) or we simply don't care (eg global stats). > > In these cases,

Re: more fexecve questions

> Date: Tue, 10 Sep 2019 16:03:23 - (UTC) > From: chris...@astron.com (Christos Zoulas) > > In article <20190910150418.becab60...@jupiter.mumble.net>, > Taylor R Campbell wrote: > >Can we just cache these when the file descriptor is opened with > >O_EXEC? &g

Re: fexecve

> Date: Sun, 8 Sep 2019 14:03:03 -0400 > From: Thor Lancelot Simon > > On Sun, Sep 08, 2019 at 01:23:46PM -0400, Christos Zoulas wrote: > > > > Here's a simple fexecve(2) implementation. Comments? > > I think this is dangerous in systems which use chroot into filesystems > mounted noexec (or

Re: workqueue_destroy() can cause hanging up in the some cases

> Date: Fri, 6 Sep 2019 12:17:32 +0900 > From: Kengo NAKAHARA > > I found workqueue_destroy() for WQ_PERCPU workqueue can cause hanging up > while preempt disabled. The caller of workqueue_destroy() requires > for q_worker kthread to call kthread_exit(). In the implementation, > the caller do

Re: /dev/random is hot garbage

> Date: Sun, 21 Jul 2019 20:52:52 +0200 > From: Manuel Bouyer > > /dev/randon actually works as documented and if rust wants /dev/urandom > behavior it should use /dev/urandom. Also I'd like to get explained why > a compiler needs that much random bits. The difference is that /dev/random may

Re: /dev/random is hot garbage

> Date: Sun, 21 Jul 2019 11:55:23 -0400 > From: Greg Troxel > > I don't think we should change /dev/random. For a very long time, the > notion is that the bits from /dev/random really are ok for keys, and > there has been a notion that such bits are precious and you should be > prepared to

Re: /dev/random is hot garbage

> Date: Sun, 21 Jul 2019 17:28:17 +0200 > From: Martin Husemann > > Replacing the /dev/random device node by a symlink to /dev/urandom sounds > fine. For binaries it is easy to just use the sysctl instead to get high > quality randomness. Are there any shell script like applications that >

Re: Removing PF

Core decided a while ago that npf is the way forward and pf and ipf will be deprecated and removed at some point. It is not worth the effort to try to update pf or ipf. We are not removing pf or ipf immediately but they will certainly be deprecated in netbsd-9 so they can be gone in netbsd-10.

Re: RFC: vioif(4) multiqueue support

> Date: Wed, 26 Dec 2018 10:03:15 +0900 > From: Shoichi Yamaguchi > > > I implemented a patch that make vioif(4) support multi-queue. And I have put > > the patch on ftp.n.o. I used vioif(4) multiqueue on qemu-kvm on Linux kernel > > 4.19.5. And It seems to be working fine. > > > >

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

> Date: Sat, 15 Dec 2018 10:30:13 +0100 > From: theo4...@borm.org > > Might I suggest that the obvious solution to this, and probably a host > of other issues, is to make time_t an always negative number > (negint/neglong?) and redefine the epoch as 03:14:09 UTC on Tuesday, 19 > January 2038,

Re: pci_intr_alloc() vs pci_intr_establish() - retry type?

> Date: Tue, 27 Nov 2018 21:14:04 + > From: Robert Swindells > > It looks to me that drivers try MSI and/or MSIX first based on the > device type not on whether the host controller can handle it. Can we make the same API work for MSI, MSI-X, and INTx interrupts, so that we don't have to

Re: Help with a bug in mmap

> Date: Wed, 31 Oct 2018 23:16:49 +0100 > From: Kamil Rytarowski > > On 31.10.2018 18:05, Taylor R Campbell wrote: > > For the moment, as a provisional workaround to make progress, you can > > probably get by with `pa << PGSHIFT', where pa is the physical (byte) &g

Re: Help with a bug in mmap

> Date: Wed, 31 Oct 2018 22:01:14 +0530 > From: Siddharth Muralee > > Hello All, > I have recently been working on porting the kcov(4) feature to NetBSD. > The feature comes as a /dev module. I have been stuck for a while with the > mmap() function of the device. I have been trying to

Re: HEADS UP: drmkms update incoming

The drmkms update commit bomb is finished. I've compile-tested amd64, i386, macppc, sparc64, and evbarm/TEGRA, and they all build. I'll be around this evening US/Eastern to clean up fallout, of which I'm sure there will be some, but I need to get to $DAYJOB for a while now!

HEADS UP: drmkms update incoming

I'm going to start an automated process to update our DRM/KMS graphics drivers. I've been working on this in Git, and I have a script to apply the changes to CVS as long as they apply cleanly. IF ANYTHING GOES WRONG AND THIS NEEDS TO BE INTERRUPTED: log into www.n.o and run touch

Re: kasan: monitor pools

> Date: Tue, 21 Aug 2018 14:30:55 +0200 > From: Maxime Villard > > Le 21/08/2018 à 14:05, Christos Zoulas a écrit : > > Sure, how about also following the empty function style the redzone code > > follows to reduce ifdefs? > > Why not, but origsize will become unused, so still need one ifdef.

Re: How to prevent a mutex being _enter()ed from being _destroy()ed?

> Date: Mon, 13 Aug 2018 14:19:42 + > From: Taylor R Campbell > > If you are running with DIAGNOSTIC off, then KASSERT(fp->f_count != 0) > in unp_gc in netbsd-6 will never panic; instead it may attempt to > regain a reference too late to a socket file that another threa

Re: How to prevent a mutex being _enter()ed from being _destroy()ed?

> Date: Mon, 13 Aug 2018 12:05:10 + > From: Taylor R Campbell > > > Date: Sun, 12 Aug 2018 20:59:07 +0200 > > From: Edgar Fuß > > > > OK, I hit my new panic in soput(). The call chain is > > breakpoint<-vpanic<-printf_nolog<-soqinsqu

Re: How to prevent a mutex being _enter()ed from being _destroy()ed?

> Date: Sun, 12 Aug 2018 20:59:07 +0200 > From: Edgar Fuß > > OK, I hit my new panic in soput(). The call chain is > breakpoint<-vpanic<-printf_nolog<-soqinsque<-soclose<-soo_close<-closef<-fd_close<-syscall. That's weird. soclose doesn't call soqinsque. I don't have a hypothesis for how the

Re: Finding an available fss device

> Date: Fri, 10 Aug 2018 13:46:55 + > From: Emmanuel Dreyfus > > Perhaps the right way is to add a FSSIOBUSY ioctl that would > use mutex_tryenter and return EBUSY if the device is in use? Unless I misunderstand fss(4), this is an abuse of mutex(9): nothing should sleep while holding the

Re: How to prevent a mutex being _enter()ed from being _destroy()ed?

> Date: Fri, 10 Aug 2018 19:48:40 +0200 > From: Edgar Fuß > > > Yes -- isn't that the symptom you're seeing, or did I miss something? > It's the mutex_oncpu in the while condition that crashes, not the on in the > if condition above the do. Are you sure it _only_ happens in the do/while and

Re: How to prevent a mutex being _enter()ed from being _destroy()ed?

> Date: Fri, 10 Aug 2018 19:05:28 +0200 > From: Edgar Fuß > > > More likely is that the socket is prematurely freed before unp_gc > > grabs it at all. > But then the mutex_oncpu() in the if above the do...while would panic, no? Yes -- isn't that the symptom you're seeing, or did I miss

Re: How to prevent a mutex being _enter()ed from being _destroy()ed?

> Date: Fri, 10 Aug 2018 17:51:11 +0200 > From: Edgar Fuß > > I'm currently running an 8.0_STABLE kernel on the machine (with 6.1_STABLE > userland) and no panics so far. This smay be > -- luck > -- different timing that doesn't trigger the race > -- a bug fixed since 6.1 > > If someone

Re: How to prevent a mutex being _enter()ed from being _destroy()ed?

> Date: Fri, 10 Aug 2018 08:03:55 -0400 > From: Greg Troxel > > Edgar Fuß writes: > > > Is there a general scheme/rule/proposal how to prevent a mutex that someone > > is trying to mutex_enter() from being teared down by someone else calling > > mutex_destroy() on it during that? > > Not

Proposal: rename min/max -> umin/umax

I propose we rename libkern's min/max to umin/umax. The names min and max invite general use like MIN and MAX, but these functions truncate their arguments to unsigned first. We also have imin/imax, lmin/lmax, and ulmin/ulmax. This came to my attention while working on a drmkms update, where

[PATCH] Tag each .c file with the options that might have brought it in.

or OPTS.foo.c, in the first two replies to this patch; otherwise I will reject your paint colours with prejudice!) >From 5e0ee893cdb9e42d7454624fd46fd6979688ba90 Mon Sep 17 00:00:00 2001 From: Taylor R Campbell Date: Mon, 30 Jul 2018 21:30:31 + Subject: [PATCH] Tag each .c file with the o

Re: workqueues ....

> Date: Thu, 26 Jul 2018 22:57:57 -0700 > From: Phil Nelson > > I'm trying to work with workqueues and am having a locking problem Is this a conceptual problem, or do you have a symptom that you're actually hitting with specific code? If the latter, can you describe the symptom and quote

Re: usb_rem_task_wait

> Date: Sun, 01 Jul 2018 08:02:11 -0700 > From: Jason Thorpe > > I've been thinking about this interface a bit... it would be handy > to have a version of it for some non-usb stuff I have in the hopper. > Should it be generalized and moved to sys/kern?

usb_rem_task_wait

The attached patch implements usb_rem_task_wait and uses it in various drivers' detach routines so that they have a chance of guaranteeing not to leave pending tasks floating around using memory after free. Also changes various callout_stops near usb_rem_task to callout_halt if they seemed

Re: rw_lock_held

> Date: Wed, 7 Feb 2018 14:14:35 +0900 > From: Ryota Ozaki <ozak...@netbsd.org> > > On Wed, Feb 7, 2018 at 2:55 AM, Taylor R Campbell > <campbell+netbsd-tech-k...@mumble.net> wrote: > >> Date: Tue, 6 Feb 2018 19:06:33 +0900 > >> From: Ryota Ozaki

Re: rw_lock_held

> Date: Wed, 7 Feb 2018 14:11:56 +0900 > From: Ryota Ozaki > > On Wed, Feb 7, 2018 at 2:01 AM, Chuck Silvers wrote: > > your option (1) sounds fine to me. > > a better wording for the manpage could be: > > > > Test the lock's condition and return

Re: rw_lock_held

> Date: Tue, 6 Feb 2018 19:06:33 +0900 > From: Ryota Ozaki > > Is there any reason that rw_lock_held checks if it's held > by *someone*, not by curlwp? It's confusable and most (or all?) > users of the API seem to expect the latter (held by curlwp). Wild guesses: (a)

Re: virtual to physical memory address translation

ow to make it read anything that is not already cached a priori, but I didn't try the physical memory mappings. /*- * Copyright (c) 2018 Taylor R. Campbell * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided th

Re: Proposal to fix buggy PCC.

> Date: Mon, 15 Jan 2018 01:33:41 +0900 > From: "Naruaki.Etomi" > > I propose to fix buggy PCC. Cool, thanks for working on this! I don't have time to review it right now, but the main point that is broken in many of our per-CPU timecounters is that the timecounter API is

Re: MP-safe DAD timer destruction with callout_stop

> Date: Fri, 12 Jan 2018 04:33:06 + (UTC) > From: chris...@astron.com (Christos Zoulas) > > Even then (with callout_halt) nothing prevents something from > calling callout_schedule() or callout_reset() again between > that time and callout_destroy()... I have code that adds another > flag

Re: amd64: svs

> Date: Thu, 11 Jan 2018 20:24:55 +0100 > From: Martin Husemann > > On Thu, Jan 11, 2018 at 08:14:59PM +0100, Jaromír Dole?ek wrote: > > Okay, I'll look into this. The feature seems pretty simple to use, though > > it will need > > some care to allow inactive processes to

Re: kernel condvars: how to use?

> Date: Mon, 11 Dec 2017 11:13:16 -0500 (EST) > From: Mouse > > > If read does > > > while (sc->sc_foo < sc->sc_bar) > > cv_wait(>sc_cv, >sc_lock); > > > then whoever changes sc_foo or sc_bar might test whether they changed > > from sc->sc_foo <

Re: Merging ugen into the usb stack

> Date: Mon, 11 Dec 2017 12:44:32 +0100 > From: Martin Husemann > > I could hack uftdi to allow attaching a ugen child, but that sounds > like a very special hack. Jared suggested to instead make ugen not a > separate device, but globaly fold it into the usb stack. That would

Re: RFC: PERCPU_LIST to fix PR kern/52515

> Date: Mon, 11 Dec 2017 11:55:27 +0100 > From: Edgar Fuß > > > struct psref { > > - LIST_ENTRY(psref) psref_entry; > > + SLIST_ENTRY(psref) psref_entry; > > + /* To keep ABI with LIST_ENTRY(psref) version. */ > > + void

Re: RFC: PERCPU_LIST to fix PR kern/52515

> Date: Mon, 11 Dec 2017 10:53:11 +0900 > From: Kengo NAKAHARA > > Thank you for your reviewing. I see. Here is the updated patch. > [...] > If there is no problem, can I commit and pullup -8 the patch? LGTM, please commit!

Re: kernel condvars: how to use?

> Date: Fri, 8 Dec 2017 14:00:40 -0500 (EST) > From: Mouse > > > If anything, you should just test rather whether you changed from a > > state that would block a read to a state in which a read can make > > progress. > > That's kind-of what LPT_RF_WAITING records.

Re: kernel condvars: how to use?

> Date: Fri, 8 Dec 2017 09:04:25 -0500 (EST) > From: Mouse > > > Where do you set LPT_RF_WAITING? > > Hm, now that you mention it, I think I don't. Note that a flag like this is not normally necessary, or even particularly helpful -- cv_broadcast already has

Re: RFC: PERCPU_LIST to fix PR kern/52515

> Date: Fri, 8 Dec 2017 18:51:28 +0900 > From: Kengo NAKAHARA > > However, it seems your patch has large diff... From the point of code > stability, smaller diff SLIST version would be better for netbsd-8 branch > to fix the bug. Because your patch causes some new ATF

Re: Attaching to an attribute

> Date: Fri, 8 Dec 2017 04:29:49 +0300 > From: Valery Ushakov > > Astonishingly, i386 and amd64 GENERIC do _not_ have > > wsmouse* at wsmousedev? > > wildcard attachment and instead use separate attachments for each > parent. I'm overcome with nostalgy, but this probably

Re: kernel condvars: how to use?

> Date: Thu, 7 Dec 2017 22:26:54 -0500 (EST) > From: Mouse > > DIAGNOSTIC and DEBUG are both on already. None of the LOCK* options > are, though - see Paul Goyette's response, below. My usual debug-all-the-things kernel configuration is: makeoptions DBG=-"-g"

Re: kernel condvars: how to use?

> Date: Thu, 7 Dec 2017 18:24:22 -0500 (EST) > From: Mouse > > On reflection, I think I know why. Userland's syscall handler took the > mutex in preparation for cv_wait_sig(), the interrupt happens, my code > is called (verified with a printf), and it tries to take

Re: kernel condvars: how to use?

> Date: Thu, 7 Dec 2017 18:24:22 -0500 (EST) > From: Mouse > > db{0}> tr > breakpoint() at netbsd:breakpoint+0x5 > comintr() at netbsd:comintr+0x53a > Xintr_ioapic_edge7() at netbsd:Xintr_ioapic_edge7+0xeb > --- interrupt --- > x86_pause() at netbsd:x86_pause >

Re: RFC: PERCPU_LIST to fix PR kern/52515

> Date: Thu, 7 Dec 2017 05:23:59 + > From: Taylor R Campbell <campbell+netbsd-tech-k...@mumble.net> > > > Date: Thu, 7 Dec 2017 05:21:58 +0000 > > From: Taylor R Campbell <campbell+netbsd-tech-k...@mumble.net> > > > > I dropped this thre

Re: RFC: PERCPU_LIST to fix PR kern/52515

> Date: Thu, 7 Dec 2017 05:21:58 + > From: Taylor R Campbell <campbell+netbsd-tech-k...@mumble.net> > > I dropped this thread on the floor a while ago and I forget what the > status was. I've had a patch sitting in my tree for a while which I > brushed off to p

Re: RFC: PERCPU_LIST to fix PR kern/52515

I dropped this thread on the floor a while ago and I forget what the status was. I've had a patch sitting in my tree for a while which I brushed off to put the list update logic in separate functions, as I think chuq requested a while ago, but still keep it all isolated to subr_psref.c and avoid

Re: Parallelize page queues

/ /*- * Copyright (c) 2015 The NetBSD Foundation, Inc. * All rights reserved. * * This code is derived from software contributed to The NetBSD Foundation * by Taylor R. Campbell. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided t

Re: Debugging function of localcount

> Date: Mon, 13 Nov 2017 13:59:32 +0900 > From: Ryota Ozaki > > I'm sorry for not replying this thread. I'm back. > > I've revised the patch as your suggestions: > http://www.netbsd.org/~ozaki-r/localcount_debug_atomic.revised.diff Looks better, thanks! Couple nits: 1.

Re: Still getting XEN DomU KASSERT ...

> Date: Mon, 13 Nov 2017 06:42:33 +0700 > From: Robert Elz > > I am still seeing this (with sources updated to within the past > 12 hours or so - I have seen no potentially relevant commits since) > > panic: kernel diagnostic assertion "known_mpsafe == (level != IPL_VM)" >

Re: kaslr: better rng

> Date: Sat, 11 Nov 2017 21:48:54 +0100 > From: Maxime Villard > > The hash of y against rdtsc and rdseed is the new secret, not just y. It's > not a recurrent Yn+1 = H(Yn) construction from a single Y0 seed - in which > case one leak in the chain would indeed compromise the

Re: kaslr: better rng

> Date: Sat, 11 Nov 2017 15:48:12 +0100 > From: Maxime Villard > > It is based on the SHAKE256 hash function, which can produce a variable > sized output. We use an area of 32 bytes, and regenerate it as many times > as needed. > > The first time, it is generated with: > >

<    1   2   3   4   5   6   7   >