Re: building 9.1 kernel with /usr/src elsewhere?

> Date: Tue, 7 Mar 2023 18:32:46 -0500 (EST) > From: Mouse > > This completed apparently normally, reporting the build directory and > telling me to remember to make depend. I then went to ~/kbuild/GEN91 > and ran make depend && make. It failed fast - no more than a second or > two - with > >

Re: AMDGPU: Floating Point traps in Display Core code

> Date: Fri, 24 Feb 2023 23:21:35 -0800 > From: Jeff Frasca > > Ok, first off, the FP code I've run into is in the Display > Core code, specifically in: > sys/external/bsd/drm2/dist/drm/amd/display/dc/calcs/amdgpu_dcn_calcs.c > It's all SIMD code operating on xmmN registers. To get to > this

Nixing __HAVE_ATOMIC_AS_MEMBAR

I propose to delete current use of __HAVE_ATOMIC_AS_MEMBAR because it is a bad API, and replace it by one of two options: (a) Add membar_release_preatomic and membar_acquire_postatomic: noop if __HAVE_ATOMIC_AS_MEMBAR, alias for membar_release/acquire otherwise. (Maybe also add

Re: The list of __HAVE macros

> Date: Sun, 5 Mar 2023 21:20:55 +0300 > From: Valery Ushakov > > We don't seem to have(9) a man page that lists all __HAVE_* macros > that a port may provide. E.g. > > $ apropos -M '"__HAVE_PREEMPTION"' > cpu_need_resched (9)context switch notification > > but > > $ apropos -M

rw_downgrade/tryupgrade semantics

Questions about rwlock(9) memory ordering semantics: 1. Is rw_tryupgrade an acquire operation, so that all prior reader critical sections happen-before anything sequenced after it? Or does it only order stores issued by the caller, while loads in the following write section can be

Re: Nixing __HAVE_ATOMIC_AS_MEMBAR

> Date: Wed, 22 Feb 2023 12:57:24 + > From: Taylor R Campbell > > I propose to delete current use of __HAVE_ATOMIC_AS_MEMBAR because it > is a bad API, and replace it by one of two options: > > (a) Add membar_release_preatomic and membar_acq

Re: USB-related panic in 8.2_STABLE

> Date: Thu, 27 Apr 2023 13:10:19 +0200 > From: Timo Buhrmester > > | uvm_fault(0xfe82574c2458, 0x0, 1) -> e > | fatal page fault in supervisor mode > | trap type 6 code 0 rip 0x802f627e cs 0x8 rflags 0x10246 cr2 0x2 > ilevel 6 (NB: could be ilevel 0 as well) rsp 0x80013f482c10

Re: USB-related panic in 8.2_STABLE

> Date: Thu, 27 Apr 2023 21:39:38 +0200 > From: Edgar Fuß > > > list *(ugen_get_cdesc+0xb1) > 0x802f8f2e is in ugen_get_cdesc (/usr/src-8/sys/dev/usb/ugen.c:1376). > 1371usb_config_descriptor_t *cdesc, *tdesc, cdescr; > 1372int len; > 1373usbd_status

Re: USB-related panic in 8.2_STABLE

> Date: Fri, 28 Apr 2023 11:32:44 +0200 > From: Edgar Fuß > > But we still don't know what led to the disconnect. Does the > ohci0: 1 scheduling overruns > give any clue? Suggests a hardware problem to me. According to the OHCI spec, this can happen if the driver has committed too much

Re: flock(2): locking against itself?

> Date: Thu, 30 Mar 2023 08:22:45 -0400 (EDT) > From: Mouse > > I actually ran into a case where this distinction caused trouble. I > have a program that uses curses for output but wants to do non-blocking > input. So I set stdin nonblocking and threw fd 0 into the poll() loop. > > But, in

fstrans_start(vp->v_mount) and vgone

Last year hannken@ changed fstrans(9) to use a hash table mapping struct mount pointers to fstrans info, in order to fix a crash found by syzkaller arising from a race between fstrans_start(vp->v_mount) and vgone(vp): https://syzkaller.appspot.com/bug?extid=54dc9ac0804a97b59bc6

Re: Possible problem with WAPBL on FFSV1

> Date: Wed, 22 Mar 2023 12:21:41 -0700 > From: Brian Buhrow > > Both machines are running a single FFSV1 root filesystem and one > directory has over 32,000 files in it. This directory is > continually appended and, once a day, files are purged from it. > When the panic occurs, the systems

Re: devsw_detach is failing -- is this a manifestation of PR kern/56962?

> Date: Wed, 1 Feb 2023 23:24:53 -0800 > From: Brian Buhrow > > I'm runing NetBSD-9.99.77, which predates the pr kern/56962 > fixes. Is this behavior expected prior to the fix for this bug or > am I running into something else? I don't recall the details and don't have time to think

Re: config system question

> Date: Tue, 11 Jul 2023 15:36:08 -0700 > From: Phil Nelson > > I'm working on getting the iwlwifi driver for intel devices into > the new wifi framework. In going over the files as named I see > that there are multiple different files "xxx/tx.c" and "yyy/tx.c". > Those names would both

Re: [PATCH] style(5): No struct typedefs

> Date: Tue, 11 Jul 2023 19:50:19 -0700 > From: Jason Thorpe > > > On Jul 11, 2023, at 2:56 PM, Taylor R Campbell > > wrote: > > > > I agree the keyword is ugly, and it's unfortunate that in order to > > omit it we would have to use C++, but the u

[PATCH] style(5): No struct typedefs

.) Objections? >From 69dc9658454c8edce695630d2e1bc75db86c43eb Mon Sep 17 00:00:00 2001 From: Taylor R Campbell Date: Tue, 11 Jul 2023 09:57:54 + Subject: [PATCH] style(5): Prohibit new struct typedefs and explain why. --- share/misc/style | 16 +++- 1 file changed, 15 insertions(+)

Intermittent t_timerfd failures

sys/lib/libc/sys/t_timerfd.c timerfd_block is intermittently failing on the i386 test bed. I added some diagnostic prints to see exactly what the timing failure is, which yielded: t_timerfd.c:198: then=1368.605876566 now=1369.462708087 delta=0.856831521

Re: kcmp(2)

> Date: Tue, 11 Jul 2023 22:00:25 +0100 > From: Robert Swindells > > Linux has the kcmp(2) syscall, Mesa makes use of it. > > Do we want a version of the syscall? Can you give any more details? What is kcmp(2) useful for? Is kcmp(2) a good design for that goal? What does Mesa use kcmp(2)

Re: [PATCH] style(5): No struct typedefs

ate: Tue, 11 Jul 2023 05:56:27 -0700 > From: Jason Thorpe > > > On Jul 11, 2023, at 3:17 AM, Taylor R Campbell wrote: > > > > If we used `struct bus_dma_tag *' instead, the forward declaration > > could be `struct bus_dma_tag;' instead of having to pull in all of &g

[PATCH] __builtin_ffs/clz in sys/bitops.h

be worthwhile, but performance measurements for this sort of thing constitute a rabbit hole that I probably won't find the time to fall into for in the foreseeable future. >From 494ce7f4bddb181a7de6e97aa461899926c8e761 Mon Sep 17 00:00:00 2001 From: Taylor R Campbell Date: Thu, 13 Jul 2023 20

Re: [PATCH] style(5): No struct typedefs

ting `struct foo' everywhere -- you can use `union foo' with a single anonymous struct member, and it's one character shorter!) >From 724e1b6101fd3d4397d34ac2678ec07aa2d3ba28 Mon Sep 17 00:00:00 2001 From: Taylor R Campbell Date: Tue, 11 Jul 2023 09:57:54 + Subject: [PATCH] style(5): Advise

Re: ALTQ cannot be stopped Was: Fwd: 10-BETA : some network issues

> Date: Wed, 19 Jul 2023 15:36:48 +0200 > From: BERTRAND Joël > > Yesterday, I have done a mistake... ALTQD is running on one of my > NetBSD server (this server routes rtp packets) and I have tried to > reboot this machine... It was not possible: shutdown stalled on > "Stopping altqd"

Re: kcmp(2)

> Date: Wed, 19 Jul 2023 03:51:29 + > From: David Holland > > On Tue, Jul 18, 2023 at 03:25:02PM -0700, Jason Thorpe wrote: > > That *might* work in this particular case, but it would not work > > for e.g. a cloning device where you get additional descriptors via > > dup() or whatever. >

Re: DRM/KMS: vmwgfx driver is now available

> Date: Sun, 16 Jul 2023 01:12:48 +0900 > From: PHO > > I've been working on vmwgfx driver, a driver for VMware virtualized GPU. > It was partly ported to NetBSD but wasn't buildable, and now it builds > and actually works. (Thank you riastradh@, your prior work helped > tremendously. I don't

Re: sdmmc question.

> Date: Tue, 23 May 2023 22:54:13 -0700 > From: Phil Nelson > >I'm presuming that we'll need something in the dev/spi/files.spi, > but haven't figured out what to say to get it to work. And I'm > assuming there is a .c file that needs to implement the interface > between the sdmmc and the

Re: sdmmc question.

Looks like there are actually already two different drivers for some kind of sd@spi, but they live under evbsh3 -- so, not sure if they're actually specific to sh3 boards or what: https://nxr.netbsd.org/xref/src/sys/arch/evbsh3/t_sh7706lan/scimci.c

Re: malloc(9) vs kmem(9) interfaces

> Date: Wed, 31 May 2023 20:54:34 + > From: Andrew Doran > > On Sat, Oct 29, 2022 at 02:42:27PM +0000, Taylor R Campbell wrote: > > > - Was the rationale migrating to kmem(9) written down or discussed > > publicly anywhere? > > Some I know of are: >

Re: Testing Emulation Syscalls

> Date: Mon, 31 Jul 2023 22:29:29 +0100 > From: Robert Swindells > > Theodore Preduta wrote: > > This comes somewhat as a "part 2" to > > https://mail-index.netbsd.org/tech-kern/2023/06/21/msg028926.html > > > > Given the responses to that thread, I decided to add native stubs > > for epoll

Re: DRM/KMS: vmwgfx driver is now available

> Date: Sun, 23 Jul 2023 12:36:10 +0900 > From: PHO > > This: > https://github.com/depressed-pho/netbsd-src/blob/91daa67f17222da355d3fddd6fa849c786d9c545/sys/external/bsd/drm2/dist/drm/vmwgfx/vmwgfx_fence.c#L45 > > and this: >

Re: DRM/KMS: vmwgfx driver is now available

> Date: Sun, 23 Jul 2023 22:57:14 +0900 > From: PHO > > On 7/23/23 21:24, Taylor R Campbell wrote: > > Why can't the loop just use dma_fence_get_rcu and dma_fence_put? > > > > Might need to release and reacquire the lock around dma_fence_put. > > I tried bu

Re: [PATCH] Driver for Elantech I2C touchpad

> Date: Sat, 15 Jul 2023 03:48:54 +0200 > From: "Vladimir 'phcoder' Serbinenko" > > I've submitted a similar patch for OpenBSD recently and it got merged. It > adds support for Elantech I2C touchpad used on many laptops. Tested on my > Chromebook Elemi Cool! This looks great. I don't have any

Restoring interface attributes

The thorpej-cfargs branch had a change to systematically remove interface attributes from config attachments: https://mail-index.netbsd.org/source-changes-hg/2021/03/23/msg273413.html I don't understand what the purpose is. It's like changing function calls to not name the function that you're

Re: Strange crash of DIAGNOSTIC kernel on cv_destroy(9)

> Date: Mon, 24 Jul 2023 12:05:34 +0900 > From: PHO > > I realized the cause of this: > [...] > There were cases where the function was destroying a condvar that it > didn't initialize! Ugh, this is the very reason why I dislike C... Oops... Sorry, was blowing through the vmwgfx code a little

Re: ALTQ cannot be stopped Was: Fwd: 10-BETA : some network issues

> Date: Sat, 22 Jul 2023 17:14:11 +0200 > From: BERTRAND Joël > > I have rebuilt my tree, started and stopped altqd. Excellent, thanks! Can you either: (a) send me a tarball of your altqd binary together with all the shared libraries and .debug files that gdb mentioned, and together

Re: DRM/KMS: vmwgfx driver is now available

> Date: Sun, 23 Jul 2023 00:47:39 +0900 > From: PHO > > On 7/22/23 22:23, Taylor R Campbell wrote: > > For that matter, do we even need a new allocator here? Can we just do > > a new bus_dmamem_alloc/load for each one? > > Sure, but I fear that would degrade the p

Re: DRM/KMS: vmwgfx driver is now available

> Date: Sun, 16 Jul 2023 04:50:35 +0900 > From: PHO > > On 7/16/23 04:19, Taylor R Campbell wrote: > > > 1. Did you reimplement an allocator for the dma_pool_* API? Should it > > use vmem(9) instead or can that not handle the requests that it > >

Re: Strange crash of DIAGNOSTIC kernel on cv_destroy(9)

> Date: Sat, 22 Jul 2023 21:52:40 +0900 > From: PHO > > >> cv_destroy(); // <-- Panics! > >> > >> It seldom panics on KASSERT(!cv_has_waiters(cv)) in cv_destroy() but not > >> always. The panic seems to happen when cv_timedwait_sig() exits due to > >> the timeout expiring before it gets

Re: Strange crash of DIAGNOSTIC kernel on cv_destroy(9)

> Date: Sat, 22 Jul 2023 21:52:40 +0900 > From: PHO > > Jul 17 00:52:34 netbsd-current /netbsd: [ 64017.6151161] > vmw_fence_wait() at netbsd:vmw_fence_wait+0xdc Just to confirm, what does `info line *(vmw_fence_wait+0xdc)' say in gdb? And, if you can get to the frame in gdb, what does gdb

Re: Strange crash of DIAGNOSTIC kernel on cv_destroy(9)

> Date: Mon, 17 Jul 2023 12:57:42 +0900 > From: PHO > > While further testing my DRM/KMS vmwgfx driver patches by playing > games/minetest from pkgsrc, I experienced inexplicable kernel panics on > this code: > >

ulimits and memfd(2)

Is there any mechanism that limits the memory usage of processes via memfd(2)? Without memfd(2), there are ulimits -- you can use RLIMIT_AS to limit the address space size, and the number of file descriptors a process can create to store data in pipe buffers is limited, and the amount of data

Re: kevent ext member?

> Date: Wed, 9 Aug 2023 13:11:13 -0400 > From: Theodore Preduta > > On 2023-08-09 04:58, Taylor R Campbell wrote: > >> Date: Tue, 8 Aug 2023 11:47:17 -0400 > >> From: Theodore Preduta > >> > >> The semantics come from MacOS (and are the same in

kevent ext member?

What is the new struct kevent::ext member about? I read the new man page but I'm still unclear on it. 1. Who owns it? Does it depend on the filter, the identifier, or both? 2. Who writes or reads it, inside the kernel? It doesn't seem to be mentioned in kern_event.c. 3. Why is

Re: kevent ext member?

> Date: Tue, 8 Aug 2023 11:47:17 -0400 > From: Theodore Preduta > > On 2023-08-08 06:53, Taylor R Campbell wrote: > > What is the new struct kevent::ext member about? I read the new man > > page but I'm still unclear on it. > > 8. Is this API shared with any othe

veriexec(4) maintenance

veriexec(4), and the fileassoc(9) API it uses internally, needs maintenance and probably some serious rework to fix synchronization problems on any MP and/or preemptible kernels (i.e., all x86 of the past couple decades) with implications for any security properties it is supposed to provide. If

Re: Anonymous vnodes?

On discussion with chs@, I realize that: (a) you could just use uao_create(INT64_MAX - PAGE_SIZE), like tmpfs does, and not bother with defining a uao_resize (just .pgo_put the pages when you truncate and update the length under the lock); but (b) this is kind of duplicating the existing

Re: Anonymous vnodes?

> Date: Mon, 26 Jun 2023 18:13:17 -0400 > From: Theodore Preduta > > 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

Re: Anonymous vnodes?

> Date: Tue, 27 Jun 2023 16:27:34 -0400 > From: Theodore Preduta > > On 2023-06-26 20:03, Taylor R Campbell wrote: > > For a syscall, you should implement it in terms of uvm anonymous > > objects: > > Is there a preexisting way to resize a uvm_object? Or do I need

PROPOSAL: Split uiomove into uiopeek, uioskip

tl;dr I propose adding uiopeek(buf, n, uio) and uioskip(n, uio) which together are equivalent to successful uiomove(buf, n, uio). This allows a driver to separately: 1. transfer data into a buffer (uiopeek) first, and then 2. advance the uio (uioskip) only after determining how much of the

PROPOSAL: config_* with device_t references

config_attach_pseudo_acquire as the aux argument to the .ca_attach function. >From 066f934f6c0dd3c3884b827d1b78f02c4b50fc3e Mon Sep 17 00:00:00 2001 From: Taylor R Campbell Date: Fri, 26 Aug 2022 10:35:08 + Subject: [PATCH] autoconf(9): New functions for referenced attach/detach. New functio

Re: PROPOSAL: Split uiomove into uiopeek, uioskip

If we think too hard about making this precise we'll wind up with names like uiosimulateviolatingnocloningtheorem and uiowavecollapse. uioskip serves either to discard data without consuming it, or to advance the pointer after using the data with uiopeek. peek is in contrast to get, like

Re: PROPOSAL: Split uiomove into uiopeek, uioskip

> Date: Tue, 9 May 2023 23:03:27 -0400 (EDT) > From: Mouse > > > (In general, erroring in I/O is a whole additional can of worms; it's > > wrong to not report back however much work happened before the error > > when it can't be undone, but also impossible to both report work and > > raise an

Re: PROPOSAL: config_* with device_t references

> Date: Wed, 10 May 2023 01:08:27 + > From: Taylor R Campbell > > I propose to add new config_*_acquire/release functions: [...] Updated patch so that the legacy config_* operations require the caller to hold the kernel lock, while the new config_*_acquire/release ones do n

Re: [10.0-BETA] Reproductible panic (filesystem)

> Date: Thu, 18 May 2023 22:55:04 +0200 > From: BERTRAND Joël > > Both wd0 and wd1 have been tested and don't have smart alerts. When I > restart this server, I can see a message just before system reboots. If > I remember, this message indicates that ccd0 is removed from system > before

Re: [10.0-BETA] Reproductible panic (filesystem)

> Date: Fri, 19 May 2023 11:55:09 +0200 > From: BERTRAND Joël > > This morning, ccd0 (and of course dk5) are "locked". All tasks stall in > uninterruptible state when they try to access to dk5: > > legendre# cd /var/squid/cache > legendre# du -hs > ^C^C^C^C^Cs^C^C^C Can you show the

Re: Thinkpad X200 volume hotkeys

> Date: Mon, 22 Jan 2024 20:49:56 +0100 > From: Andreas Hecht > > I am trying to get the volume hotkeys (VolumeUp, VolumeDown, VolumeMute) on my > Lenovo Thinkpad X200 to work. Unfortunately the respective hotkey events are > not seen by thinkpad_acpi driver's thinkpad_notify_handler. The

Re: PSA: Clock drift and pkgin

> Date: Fri, 22 Dec 2023 23:41:47 -0500 (EST) > From: Mouse > > Specifically, under a kernel built with HZ=100, requesting signals at > 100Hz actually delivers them at 50Hz. This is behind the clock running > at half speed on my VAX emulator, and quite likely behind similar > behaviour from

Re: PSA: Clock drift and pkgin

ations -- only a target _minimum_, with an average that is higher by necessity. >From bca90989210e59c45efee9b44d7575e91f053a07 Mon Sep 17 00:00:00 2001 From: Taylor R Campbell Date: Sat, 23 Dec 2023 21:03:13 + Subject: [PATCH] time(9): Avoid adding partial tick to periodic interval timers. This way, configuring

Re: radeon, amdgpu improvements for aarch64

> Date: Thu, 28 Dec 2023 01:02:08 +0100 > From: Tobias Nygren > > I've spent some time testing GPUs on aarch64 and fixing bugs. > Attached are some patches to make things more usable. Cool, thanks! Some notes below. Everything else seems fine. > [2] /libdata/firmware/amdgpu is not shipped. >

Re: VirtIO MMIO for amd64

> Date: Wed, 20 Dec 2023 08:37:32 +0100 > From: Emile 'iMil' Heitor > > On 12/20/23 06:55, Emile 'iMil' Heitor wrote: > > > Well that's the thing, I can't find where does MMIO attaches on FreeBSD, > > they have a very simple way of creating the resources: > > After a bit of digging, their

Proposal: Restore malloc(9) interface

I propose to deprecate the kmem(9) interface and go back to the malloc(9) interface. 1. The main difference is that the malloc(9) interface enables attribution of memory usage: how many bytes have been used for this purpose vs that purpose, partitioned by named malloc tags like M_MBUF

Re: pvclock (kvm_clock) support: where to attach

> Date: Sun, 31 Dec 2023 11:36:41 +0100 > From: Emile 'iMil' Heitor > > I ported pvclock / kvm_clock from OpenBSD in order for Firecracker to > have an RTC. It's working but I'm not entirely sure where to attach it. > > The device is x86 only so I added the source code in arch/x86/x86, and >

Re: VirtIO MMIO for amd64

> Date: Tue, 19 Dec 2023 08:55:32 +0100 > From: Emile 'iMil' Heitor > > Maybe related: the interrupt handler function I wrote uses > softint_establish() as there's no "real" hardware behind this > block device, is this the correct way to deal with it? You need to use softint_schedule in order

Re: Creating a hackable kernel for AMD64

> Date: Tue, 23 Apr 2024 10:52:41 -0400 > From: Jared Barnak > > I watched "How to get started hacking NetBSD" and it was great, I just > noticed that some things didn't work when cross compiling for amd64. and > frankly, I'm not sure what I did wrong. Cool, thanks! The main thing you're

Re: Forcing a USB device to "ugen"

> Date: Mon, 25 Mar 2024 19:47:31 -0400 > From: Greg Troxel > > Jason Thorpe writes: > > > I should be able to do this with OpenOCD (pkgsrc/devel/openocd), but > > libfdti1 fails to find the device because libusb1 only deals in > > "ugen". > > Is that fundamental, in that ugen has ioctls that

Re: Forcing a USB device to "ugen"

> Date: Tue, 26 Mar 2024 17:41:52 -0400 > From: Thor Lancelot Simon > > On Tue, Mar 26, 2024 at 12:25:07AM +0000, Taylor R Campbell wrote: > > > > We should really expose a /dev/ugen* instance for _every_ USB device; > > those that have kernel drivers attache

Re: poll(): IN/OUT vs {RD,WR}NORM

> Date: Mon, 27 May 2024 20:27:28 -0400 (EDT) > From: Mouse > > In sys/sys/poll.h, I see (in 1.4T, -current according to cvsweb, and > everything I've checked in between): > > #define POLLIN 0x0001 > #define POLLPRI 0x0002 > #define POLLOUT 0x0004 > #define POLLRDNORM

Re: NetBSD-10.0/i386 spurious SIGSEGV

> Date: Sun, 9 Jun 2024 05:28:49 + > From: Emmanuel Dreyfus > > I have seen many crashes on system call returns. Another one on > __gettimeofday50: > >0xbb610570 <__gettimeofday50>: mov$0x1a2,%eax >0xbb610575 <__gettimeofday50+5>: int$0x80 >0xbb610577

Re: WAPBL fix for deallocation exhaustion + slow file removal

Date: Thu, 6 Oct 2016 22:36:48 +0200 From: Jaromír Doleček I've incorporated the mutex fix, here is the final patch relative to trunk. I'd like to commit this sometime next week. OK, thanks, I'll try to find time to review in the next couple days!

Re: Plan: journalling fixes for WAPBL

Date: Wed, 21 Sep 2016 17:06:18 -0700 From: Brian Buhrow hello. Does this discussion imply that the WAPBL log/journaling function is broken in NetBSD-current? Are we back to straight FFS as it was before the days of WAPBL or softdep? Please tell me

Re: WAPBL fix for deallocation exhaustion + slow file removal

Date: Sat, 1 Oct 2016 18:40:31 +0200 From: Jaromír Dole ek > Thanks for taking a shot at this! But I think it needs a little more > time for review -- certainly I can't digest it in the 24 hours you're > giving. Sure. OK, thanks! I'll try to find

Re: WAPBL fix for deallocation exhaustion + slow file removal

Date: Sat, 1 Oct 2016 16:19:33 +0200 From: =?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?= attached patch contains a fix to WAPBL deallocation structure exhaustion and panic (kern/47146), and avoids need to do slow partial truncates in loop, fixing kern/49175.

Re: Prospective project for Summer of Code.

happy to process Git patches. /* $NetBSD$*/ /*- * 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 wi

Re: Add a mountlist iterator

> Date: Thu, 30 Mar 2017 11:21:41 +0200 > From: "J. Hannken-Illjes" > > Plan is to untangle the mountlist processing from vfs_busy() / vfs_unbusy() > and add an iterator for the mountlist: Generally seems like a good idea to me! > - void

Re: Add a mountlist iterator (round 2)

> Date: Sun, 9 Apr 2017 18:47:25 +0200 > From: "J. Hannken-Illjes" > > > On 6. Apr 2017, at 11:44, J. Hannken-Illjes wrote: > > Good hint. Prepared a partial implementation of > > > > int > > mountlist_iterate(int (*cb)(struct mount *, void

Re: Add a mountlist iterator

> Date: Sun, 2 Apr 2017 11:09:49 +0200 > From: "J. Hannken-Illjes" <hann...@eis.cs.tu-bs.de> > > > On 1. Apr 2017, at 23:03, Taylor R Campbell > > <campbell+netbsd-tech-k...@mumble.net> wrote: > > > > Any particular reason to use a

Re: locking from VOP_INACTIVE to VOP_RECLAIM

> Date: Sun, 2 Apr 2017 10:47:42 +0200 > From: "J. Hannken-Illjes" <hann...@eis.cs.tu-bs.de> > > > On 1. Apr 2017, at 20:41, Taylor R Campbell > > <campbell+netbsd-tech-k...@mumble.net> wrote: > > VOP_RECLAIM then *destroys* the lock, so we don

Re: locking from VOP_INACTIVE to VOP_RECLAIM

> Date: Sun, 2 Apr 2017 16:34:20 +0200 > From: "J. Hannken-Illjes" > > Looks like your proposal needs some clarification regarding "vnode lock" > and "the lock". > > We have two vnode related locks: > > - the "vnode lock", located as field "vi_lock" in "struct

Re: Restructure vfs_busy and friends

> Date: Fri, 14 Apr 2017 12:22:48 +0200 > From: "J. Hannken-Illjes" > > Currently we have: > > - vfs_busy(mp, NULL) to take a reference on the mount and enter > a critical section against unmounting. > [...] > > Plan is to restructure this as follows: > > -

preserve dvp lock and ref in VOP_REMOVE/VOP_RMDIR

The attached patch changes VOP_REMOVE and VOP_RMDIR so that they neither unlock nor release the directory vnode. Except for rename, these are the last two directory operations that still vput dvp -- all the others (lookup, create, link, mkdir, ) have been changed to stop doing that. These still

[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

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

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

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 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 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: 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: 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: 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: 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: 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: 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: 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

<    2   3   4   5   6   7