Re: MCLADDREFERENCE() incrementing the wrong ext_refcnt?

Hi, On Sat, Mar 23, 2024 at 12:44 AM Edgar Fuß wrote: > > Hello. > > I'm under the impression that MCLADDREFERENCE() may increment the wrong > ext_refcnt. > > In case it's permitted (I cant't find anything to the contrary) to > call MCLADDREFERENCE(m1, m2) and then MCLADDREFERENCE(m2, m3), then

Re: Enable to send packets on if_loop via bpf

On Tue, Nov 22, 2022 at 8:25 PM Ryota Ozaki wrote: > > On Tue, Nov 22, 2022 at 8:00 PM Ryota Ozaki wrote: > > > > On Tue, Nov 22, 2022 at 12:49 AM Greg Troxel wrote: > > > > > > > > > Ryota Ozaki writes: > > > > > > > I

Re: Enable to send packets on if_loop via bpf

On Tue, Nov 22, 2022 at 8:00 PM Ryota Ozaki wrote: > > On Tue, Nov 22, 2022 at 12:49 AM Greg Troxel wrote: > > > > > > Ryota Ozaki writes: > > > > > In the specification DLT_NULL assumes a protocol family in the host > > > byte order fol

Re: Enable to send packets on if_loop via bpf

On Tue, Nov 22, 2022 at 12:49 AM Greg Troxel wrote: > > > Ryota Ozaki writes: > > > In the specification DLT_NULL assumes a protocol family in the host > > byte order followed by a payload. Interfaces of DLT_NULL uses > > bpf_mtap_af to pass a mbuf prepending a pr

Re: Enable to send packets on if_loop via bpf

On Wed, Nov 9, 2022 at 9:21 PM Greg Troxel wrote: > > > Ryota Ozaki writes: > > > NetBSD can't do this because a loopback interface > > registers itself to bpf as DLT_NULL and bpf treats > > packets being sent over the interface as AF_UNSPEC. > > Packets of AF

Re: Restructuring inpcb/in6pcb

On Fri, Oct 28, 2022 at 2:53 PM Ryota Ozaki wrote: > > On Wed, Oct 26, 2022 at 5:36 PM Ryota Ozaki wrote: > > > > On Wed, Oct 26, 2022 at 12:00 AM Christos Zoulas > > wrote: > > > > > > In article > > > , > > > Ryota Ozaki wrote: &

Re: Restructuring inpcb/in6pcb

On Wed, Oct 26, 2022 at 5:36 PM Ryota Ozaki wrote: > > On Wed, Oct 26, 2022 at 12:00 AM Christos Zoulas wrote: > > > > In article > > , > > Ryota Ozaki wrote: > > >Hi, > > > > > >Data structures of network protocol contr

Re: Restructuring inpcb/in6pcb

On Wed, Oct 26, 2022 at 12:00 AM Christos Zoulas wrote: > > In article > , > Ryota Ozaki wrote: > >Hi, > > > >Data structures of network protocol control blocks (PCBs) > >(struct inpcb, in6pcb and inpcb_hdr) are not organized well. > >Users of the data

Restructuring inpcb/in6pcb

Hi, Data structures of network protocol control blocks (PCBs) (struct inpcb, in6pcb and inpcb_hdr) are not organized well. Users of the data structures have to handle them separately and thus the code becomes duplicated and cluttered. The proposal restructures the data structures, which

Re: if_ethersubr.c: if_ierrors -> if_iqdrops?

On Wed, Nov 10, 2021 at 6:03 AM Christos Zoulas wrote: > > In article <3360841c-e7fc-147d-1347-fe427d41a...@sdf.org>, > RVP wrote: > >On Mon, 8 Nov 2021, Jason Thorpe wrote: > > > >>> On Nov 7, 2021, at 11:07 PM, RVP wrote: > >>> > >>> So, I hacked up a small patch to put most of these into

Re: psref leak detector (aggressive version)

On Fri, May 10, 2019 at 7:01 PM Ryota Ozaki wrote: > > Hi, > > https://www.netbsd.org/~ozaki-r/psref-debug-aggressive.diff > > This patch implements yet another psref leak detector that > enables to tell where a leak occurs while a simpler version > that is alre

psref leak detector (aggressive version)

Hi, https://www.netbsd.org/~ozaki-r/psref-debug-aggressive.diff This patch implements yet another psref leak detector that enables to tell where a leak occurs while a simpler version that is already committed just tells an occurrence of a leak. Investigating of psref leaks is hard because once

Re: Importing libraries for the kernel

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 > > libraries needed tor the implementation. The libraries are > > libb2[1] and

Re: Importing libraries for the kernel

On Thu, Dec 13, 2018 at 2:12 AM Greg Troxel wrote: > > m...@netbsd.org writes: > > > I don't expect there to be any problems with the ISC license. It's the > > preferred license for OpenBSD and we use a lot of their code (it's > > everywhere in sys/dev/) > > Agreed that the license is ok. > > >

Importing libraries for the kernel

Hi, As you may know I'm working on implementing WireGuard in the kernel. The implementation works and buildable. Some code cleanups are still needed but I'll propose it on the list in the near future. Before that, I want to ask about how to import cryptography libraries needed tor the

Re: Things not referenced in kernel configs, but mentioned in files.*

On Tue, Nov 13, 2018 at 1:26 AM Christos Zoulas wrote: > > In article , > Greg Troxel wrote: > > > >co...@sdf.org writes: > > > >> This is an automatically generated list with some hand touchups, feel > >> free to do whatever with it. I only generated the output. > >> > >> ac100ic > >> acemidi

Re: Let callout_reset return if it reschedules a pending callout

On Thu, Mar 1, 2018 at 5:45 AM, Joerg Sonnenberger <jo...@bec.de> wrote: > On Thu, Mar 01, 2018 at 01:58:29AM +0900, Ryota Ozaki wrote: >> On Wed, Feb 28, 2018 at 10:11 PM, Joerg Sonnenberger <jo...@bec.de> wrote: >> > On Wed, Feb 28, 2018 at 05:47:13PM +0900, Ryota

Re: Let callout_reset return if it reschedules a pending callout

On Wed, Feb 28, 2018 at 10:11 PM, Joerg Sonnenberger <jo...@bec.de> 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 >> passed to a callout. In this case you need to take care o

Let callout_reset return if it reschedules a pending callout

Hi, This proposal lets callout_reset and callout_schedule return true if it reschedules a pending callout and return false otherwise. 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

Re: Race condition between an LWP migration and curlwp_bind

On Thu, Feb 15, 2018 at 5:30 AM, Mateusz Guzik <mjgu...@gmail.com> wrote: > On Tue, Feb 13, 2018 at 05:14:38PM +0900, Ryota Ozaki wrote: >> panic: kernel diagnostic assertion "(psref->psref_cpu == curcpu())" >> failed: file "/(hidden)/sys/kern/subr_

Re: Race condition between an LWP migration and curlwp_bind

On Wed, Feb 14, 2018 at 8:05 AM, Christos Zoulas <chris...@astron.com> wrote: > In article > <CAKrYomgZYn-YUR8yhipp-7co+DioyofrZT-hsu6LmkBWKWyp=g...@mail.gmail.com>, > Ryota Ozaki <ozak...@netbsd.org> wrote: >> >>Is the fix appropriate? > > Lo

Race condition between an LWP migration and curlwp_bind

Hi, I have been encountering the following panic infrequently during torture tests. panic: kernel diagnostic assertion "(psref->psref_cpu == curcpu())" failed: file "/(hidden)/sys/kern/subr_psref.c", line 317 passive reference transferred from CPU 0 to CPU 3 fatal breakpoint trap in

Re: rw_lock_held

On Wed, Feb 7, 2018 at 2:29 PM, Ryota Ozaki <ozak...@netbsd.org> wrote: > On Wed, Feb 7, 2018 at 2:21 PM, Taylor R Campbell > <campbell+netbsd-tech-k...@mumble.net> wrote: >>> Date: Wed, 7 Feb 2018 14:14:35 +0900 >>> From: Ryota Ozaki <ozak...@netbsd.org&

Re: rw_lock_held

On Wed, Feb 7, 2018 at 2:21 PM, Paul Goyette <p...@whooppee.com> wrote: > On Wed, 7 Feb 2018, Ryota Ozaki wrote: > >>> a better wording for the manpage could be: >>> >>> Test the lock's condition and return non-zero if the lock is >>>

Re: rw_lock_held

On Wed, Feb 7, 2018 at 2:21 PM, Taylor R Campbell <campbell+netbsd-tech-k...@mumble.net> wrote: >> 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

Re: rw_lock_held

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 <ozak...@netbsd.org> >> >> Is there any reason that rw_lock_held checks if it's held >> by *someone

Re: rw_lock_held

On Wed, Feb 7, 2018 at 2:01 AM, Chuck Silvers <c...@chuq.com> wrote: > On Tue, Feb 06, 2018 at 07:06:33PM +0900, Ryota Ozaki wrote: >> Hi, >> >> Is there any reason that rw_lock_held checks if it's held >> by *someone*, not by curlwp? It's confusable and most (

rw_lock_held

Hi, 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). Well, rwlock.9 says that rw_*_held behave so, but that's perhaps just out-of-date because rw_read_held and

Re: High priority xcall with an arbitrary IPL_SOFT*

On Mon, Jan 29, 2018 at 1:08 PM, Ryota Ozaki <ozak...@netbsd.org> wrote: > Hi, > > This proposal extends xcall to allow to specify an IPL of the high > priority xcall. Currently the high priority xcall uses only a softint > of IPL_SOFTSERIAL. It doesn't work if the caller dep

High priority xcall with an arbitrary IPL_SOFT*

Hi, This proposal extends xcall to allow to specify an IPL of the high priority xcall. Currently the high priority xcall uses only a softint of IPL_SOFTSERIAL. It doesn't work if the caller depends on a different softint IPL. I'm now working on stability improvements of the network stack under

Re: MP-safe DAD timer destruction with callout_stop

On Fri, Jan 12, 2018 at 8:27 PM, Taylor R Campbell wrote: >> 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

Re: MP-safe DAD timer destruction with callout_stop

On Fri, Jan 12, 2018 at 1:33 PM, Christos Zoulas wrote: > In article >

MP-safe DAD timer destruction with callout_stop

Hi, For a certain reason(*), DAD timers are hard to use callout_halt to destroy DAD timer objects. So I was going to fall back to callout_stop (as of NetBSD 7) that is almost safe but still has a possibility of going wrong(**). (*) See the thread starting at

Re: workqueue_drain

On Fri, Dec 22, 2017 at 4:12 PM, Ryota Ozaki <ozak...@netbsd.org> wrote: > On Thu, Dec 21, 2017 at 5:56 PM, Ryota Ozaki <ozak...@netbsd.org> wrote: >> On Thu, Dec 21, 2017 at 5:58 AM, Michael van Elst <mlel...@serpens.de> wrote: >>> ozak...@netbsd.org (Ryota O

Re: workqueue_drain

On Thu, Dec 21, 2017 at 5:56 PM, Ryota Ozaki <ozak...@netbsd.org> wrote: > On Thu, Dec 21, 2017 at 5:58 AM, Michael van Elst <mlel...@serpens.de> wrote: >> ozak...@netbsd.org (Ryota Ozaki) writes: >> >>>On Wed, Dec 20, 2017 at 8:06 PM, Michael van Elst <mle

Re: struct ifnet locking [was Re: IFEF_MPSAFE]

On Fri, Dec 22, 2017 at 11:33 AM, Ryota Ozaki <ozaki.ry...@gmail.com> wrote: > On Thu, Dec 21, 2017 at 7:45 PM, Frank Kardel <kar...@netbsd.org> wrote: >> Hi, >> >> does this panic (with -current/amd64 as of 20171221) ring a bell with >> anyone? > &

Re: struct ifnet locking [was Re: IFEF_MPSAFE]

On Thu, Dec 21, 2017 at 7:58 PM, Nick Hudson <sk...@netbsd.org> wrote: > On 12/19/17 08:21, Ryota Ozaki wrote: >> >> On Tue, Dec 19, 2017 at 4:52 PM, Nick Hudson <nick.hud...@gmx.co.uk> >> wrote: >>> >>> On 19/12/2017 03:43, Ryota Ozaki wrote:

Re: struct ifnet locking [was Re: IFEF_MPSAFE]

On Thu, Dec 21, 2017 at 7:45 PM, Frank Kardel wrote: > Hi, > > does this panic (with -current/amd64 as of 20171221) ring a bell with > anyone? Yes. Could you try the patch below? Thanks, ozaki-r diff --git a/sys/net/if.c b/sys/net/if.c index 05ac3b2273c..fc3e144373f

Re: workqueue_drain

On Wed, Dec 20, 2017 at 5:41 PM, Ryota Ozaki <ozak...@netbsd.org> wrote: > On Wed, Dec 20, 2017 at 4:57 PM, Paul Goyette <p...@whooppee.com> wrote: >> On Wed, 20 Dec 2017, Ryota Ozaki wrote: >> >>> Hi, >>> >>> workqueue_destroy requires that

Re: workqueue_drain

On Thu, Dec 21, 2017 at 5:58 AM, Michael van Elst <mlel...@serpens.de> wrote: > ozak...@netbsd.org (Ryota Ozaki) writes: > >>On Wed, Dec 20, 2017 at 8:06 PM, Michael van Elst <mlel...@serpens.de> wrote: >>> What about a method that waits for a specific work to

Re: workqueue_drain

On Wed, Dec 20, 2017 at 8:06 PM, Michael van Elst <mlel...@serpens.de> wrote: > ozak...@netbsd.org (Ryota Ozaki) writes: > >>Here is a patch: >> http://www.netbsd.org/~ozaki-r/workqueue_drain.diff >>(I will update workqueue.4 once the proposal is accepted.) >

Re: workqueue_drain

On Wed, Dec 20, 2017 at 5:41 PM, Ryota Ozaki <ozak...@netbsd.org> wrote: > On Wed, Dec 20, 2017 at 4:57 PM, Paul Goyette <p...@whooppee.com> wrote: >> On Wed, 20 Dec 2017, Ryota Ozaki wrote: >> >>> Hi, >>> >>> workqueue_destroy requires that

Re: workqueue_drain

On Wed, Dec 20, 2017 at 4:57 PM, Paul Goyette <p...@whooppee.com> wrote: > On Wed, 20 Dec 2017, Ryota Ozaki wrote: > >> Hi, >> >> workqueue_destroy requires that its queue doesn't have >> any works (and no new work will be enqueued anymore) >> before being

workqueue_drain

Hi, workqueue_destroy requires that its queue doesn't have any works (and no new work will be enqueued anymore) before being called. Currently users of workqueue have to ensure the contract by theirselves. It's possible but it may need to add extra synchronization mechanisms such as mutex and

Re: struct ifnet locking [was Re: IFEF_MPSAFE]

On Thu, Dec 14, 2017 at 10:41 PM, Nick Hudson <nick.hud...@gmx.co.uk> wrote: > > > On 14/12/2017 10:48, Ryota Ozaki wrote: >> >> On Fri, Dec 8, 2017 at 7:53 PM, Nick Hudson <sk...@netbsd.org> wrote: >> > >>> Not sure I follow this. I think w

Re: struct ifnet locking [was Re: IFEF_MPSAFE]

On Tue, Dec 19, 2017 at 4:52 PM, Nick Hudson <nick.hud...@gmx.co.uk> wrote: > On 19/12/2017 03:43, Ryota Ozaki wrote: > > >> BTW I committed a change that disables IFEF_MPSAFE by default on >> all interfaces because it seems that IFEF_MPSAFE requires additiona

Re: struct ifnet locking [was Re: IFEF_MPSAFE]

On Fri, Dec 8, 2017 at 7:53 PM, Nick Hudson <sk...@netbsd.org> wrote: > On 12/06/17 11:11, Ryota Ozaki wrote: >> >> On Tue, Nov 28, 2017 at 6:40 PM, Ryota Ozaki <ozaki.ry...@gmail.com> >> wrote: >>> >>> On Mon, Nov 27, 2017 at 12:24 AM, Nick Hud

Re: RFC: PERCPU_LIST to fix PR kern/52515

On Fri, Dec 8, 2017 at 6:51 PM, Kengo NAKAHARA wrote: > Hi, > > On 2017/12/07 14:21, Taylor R Campbell wrote: >> 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

Re: struct ifnet locking [was Re: IFEF_MPSAFE]

On Tue, Nov 28, 2017 at 6:40 PM, Ryota Ozaki <ozaki.ry...@gmail.com> wrote: > On Mon, Nov 27, 2017 at 12:24 AM, Nick Hudson <sk...@netbsd.org> wrote: >> On 11/17/17 07:44, Ryota Ozaki wrote: >>> >>> On Wed, Nov 15, 2017 at 1:53 PM, Ryota Ozaki <ozaki.ry

Re: struct ifnet locking [was Re: IFEF_MPSAFE]

On Mon, Nov 27, 2017 at 12:24 AM, Nick Hudson <sk...@netbsd.org> wrote: > On 11/17/17 07:44, Ryota Ozaki wrote: >> >> On Wed, Nov 15, 2017 at 1:53 PM, Ryota Ozaki <ozaki.ry...@gmail.com> >> wrote: >>> >>> On Fri, Nov 10, 2017 at 6:35 PM, Ryota Oz

Re: Debugging features for pserialize(9)

On Mon, Nov 13, 2017 at 12:44 PM, Ryota Ozaki <ozak...@netbsd.org> wrote: > On Sat, Nov 11, 2017 at 1:14 AM, Taylor R Campbell > <campbell+netbsd-tech-k...@mumble.net> wrote: >>> Date: Fri, 10 Nov 2017 18:54:58 +0900 >>> From: Ryota Ozaki <ozak...@netbsd.org

Re: IFEF_MPSAFE

On Wed, Nov 15, 2017 at 1:53 PM, Ryota Ozaki <ozaki.ry...@gmail.com> wrote: > On Fri, Nov 10, 2017 at 6:35 PM, Ryota Ozaki <ozaki.ry...@gmail.com> wrote: >> Hi, >> >> http://www.netbsd.org/~ozaki-r/IFEF_MPSAFE.diff >> >> I'm going to commit the above

Re: IFEF_MPSAFE

On Fri, Nov 10, 2017 at 6:35 PM, Ryota Ozaki <ozaki.ry...@gmail.com> wrote: > Hi, > > http://www.netbsd.org/~ozaki-r/IFEF_MPSAFE.diff > > I'm going to commit the above change that integrates > IFEF_OUTPUT_MPSAFE and IFEF_START_MPSAFE flags into > IFEF_MPSAFE. > &g

Re: Debugging features for pserialize(9)

On Sat, Nov 11, 2017 at 1:14 AM, Taylor R Campbell <campbell+netbsd-tech-k...@mumble.net> wrote: >> Date: Fri, 10 Nov 2017 18:54:58 +0900 >> From: Ryota Ozaki <ozak...@netbsd.org> >> >> Hi, >> >> I implemented two debugging features for pserialize(9

IFEF_MPSAFE

Hi, http://www.netbsd.org/~ozaki-r/IFEF_MPSAFE.diff I'm going to commit the above change that integrates IFEF_OUTPUT_MPSAFE and IFEF_START_MPSAFE flags into IFEF_MPSAFE. The motivation is to not waste if_extflags bits. I'm now trying to make if_ioctl() hold KERNEL_LOCK selectively for some

Re: RFC: PERCPU_LIST to fix PR kern/52515

On Fri, Oct 6, 2017 at 4:24 PM, Ryota Ozaki <ozak...@netbsd.org> wrote: > On Fri, Oct 6, 2017 at 1:14 PM, Ryota Ozaki <ozak...@netbsd.org> wrote: >> On Fri, Oct 6, 2017 at 11:58 AM, Taylor R Campbell >> <campbell+netbsd-tech-k...@mumble.net> wrote: >>

Re: RFC: PERCPU_LIST to fix PR kern/52515

On Fri, Oct 6, 2017 at 1:14 PM, Ryota Ozaki <ozak...@netbsd.org> wrote: > On Fri, Oct 6, 2017 at 11:58 AM, Taylor R Campbell > <campbell+netbsd-tech-k...@mumble.net> wrote: >>> Date: Fri, 6 Oct 2017 11:26:40 +0900 >>> From: Ryota Ozaki <ozak...@netbsd.org&g

Re: RFC: PERCPU_LIST to fix PR kern/52515

On Fri, Oct 6, 2017 at 1:21 PM, Taylor R Campbell <campbell+netbsd-tech-k...@mumble.net> wrote: >> Date: Fri, 6 Oct 2017 13:14:14 +0900 >> From: Ryota Ozaki <ozak...@netbsd.org> >> >> On Fri, Oct 6, 2017 at 11:58 AM, Taylor R Campbell >> <campbell+

Re: RFC: PERCPU_LIST to fix PR kern/52515

On Fri, Oct 6, 2017 at 11:58 AM, Taylor R Campbell <campbell+netbsd-tech-k...@mumble.net> wrote: >> Date: Fri, 6 Oct 2017 11:26:40 +0900 >> From: Ryota Ozaki <ozak...@netbsd.org> >> >> On Mon, Oct 2, 2017 at 11:13 PM, Taylor R Campbell >> <campbell+n

Re: RFC: PERCPU_LIST to fix PR kern/52515

On Mon, Oct 2, 2017 at 11:13 PM, Taylor R Campbell wrote: > Quick summary of the problem: > >percpu_alloc(9) may move existing per-CPU objects to different >locations in memory. This means you can't reliably store pointers >to the per-CPU objects

Re: RFC: PERCPU_LIST to fix PR kern/52515

On Tue, Sep 19, 2017 at 1:38 PM, Kengo NAKAHARA wrote: > Hi, > > To fix PR kern/52515(*), in particular psref(9), I implement PERCPU_LIST which > is dedicated for percpu_alloc'ed percpu struct. Here is the patch which > consists > of PERCULI_LIST implementation and applying

Re: Debugging function of localcount

On Thu, Jul 27, 2017 at 1:49 AM, Taylor R Campbell <campbell+netbsd-tech-k...@mumble.net> wrote: >> Date: Wed, 26 Jul 2017 18:41:36 +0900 >> From: Ryota Ozaki <ozak...@netbsd.org> >> >> Oops. I thought we could use percpu_foreach in softint, but >> I

Re: MP-safe IPsec SPD

()); rather than writing the constraint in a comment. Thanks, ozaki-r On Fri, Aug 4, 2017 at 12:02 AM, Taylor R Campbell <campbell+netbsd-tech-k...@mumble.net> wrote: >> Date: Fri, 28 Jul 2017 16:47:15 +0900 >> From: Ryota Ozaki <ozak...@netbsd.org> >> >> This

Re: Debugging function of localcount

On Wed, Jul 26, 2017 at 1:34 PM, Ryota Ozaki <ozak...@netbsd.org> wrote: > (resending, please ignore if duplicated) > > Hi, > > I propose a debugging function of localcount, > localcount_debug_refcnt, which returns a total > reference count of a specifi

Debugging function of localcount

Hi, I propose a debugging function of localcount, localcount_debug_refcnt, which returns a total reference count of a specified localcount. A result of localcount_debug_refcnt isn't guaranteed to be accurate, however it's still useful for debugging purposes, for example debugging on ATF tests

Debugging function of localcount

(resending, please ignore if duplicated) Hi, I propose a debugging function of localcount, localcount_debug_refcnt, which returns a total reference count of a specified localcount. A result of localcount_debug_refcnt isn't guaranteed to be accurate, however it's still useful for debugging

Re: Keep local symbols of rump libraries

On Fri, Apr 14, 2017 at 1:31 PM, Paul Goyette <p...@whooppee.com> wrote: > On Fri, 14 Apr 2017, Paul Goyette wrote: > >> On Fri, 14 Apr 2017, Ryota Ozaki wrote: >> >>>>> If it's useful for other than rump libraries, having a new global >>>&

Re: Keep local symbols of rump libraries

On Wed, Apr 12, 2017 at 6:58 PM, Ryota Ozaki <ozak...@netbsd.org> wrote: > On Wed, Apr 12, 2017 at 9:27 AM, Chuck Silvers <c...@chuq.com> wrote: >> On Mon, Apr 10, 2017 at 07:22:45PM +0900, Ryota Ozaki wrote: >>> Hi, >>> >>> I'm u

Re: Keep local symbols of rump libraries

On Wed, Apr 12, 2017 at 9:27 AM, Chuck Silvers <c...@chuq.com> wrote: > On Mon, Apr 10, 2017 at 07:22:45PM +0900, Ryota Ozaki wrote: >> Hi, >> >> I'm using ATF tests running rump kernels (rump_server) >> for development and debugging. When a rump kernel gets &g

Re: Keep local symbols of rump libraries

On Mon, Apr 10, 2017 at 11:15 PM, Kamil Rytarowski <n...@gmx.com> wrote: > On 10.04.2017 12:22, Ryota Ozaki wrote: >> Hi, >> >> I'm using ATF tests running rump kernels (rump_server) >> for development and debugging. When a rump kernel gets >> panic, it dum

Move if_opackets++ to where if_obytes are

Hi, I propose to move if_opackets from device drivers to where if_obytes is incremented (not just one place), for example in if_transmit. The aims of the change are: - Unify how it's incremented - Usages of the counter are different between device drivers - There are roughly two places

Re: workqueue for pr_input

On Thu, Jan 26, 2017 at 10:29 AM, Darren Reed wrote: > Apologies all for the blob of text :( > > I resent with better formatting but that's likely in a spam queue > somewhere... > > So I'll try and summarise in a readable fashion: > > (1) patch introduces new locks for

Re: workqueue for pr_input

On Tue, Jan 24, 2017 at 3:47 PM, Ryota Ozaki <ozak...@netbsd.org> wrote: > On Mon, Jan 23, 2017 at 10:01 PM, Thor Lancelot Simon <t...@panix.com> wrote: >> On Mon, Jan 23, 2017 at 05:58:20PM +0900, Ryota Ozaki wrote: >>> >>> The demerit is that that mecha

Re: workqueue for pr_input

On Mon, Jan 23, 2017 at 10:01 PM, Thor Lancelot Simon <t...@panix.com> wrote: > On Mon, Jan 23, 2017 at 05:58:20PM +0900, Ryota Ozaki wrote: >> >> The demerit is that that mechanism adds non-trivial >> overhead; RTT of ping increases by 30 usec. > > I don't see w

Re: bpf_mtap_softint

On Wed, Jan 18, 2017 at 6:25 PM, Martin Husemann <mar...@duskware.de> wrote: > On Wed, Jan 18, 2017 at 04:48:32PM +0900, Ryota Ozaki wrote: >> Note that it of course consumes more CPU time for softint >> and more memory for m_dup. That said, I think that this is >> a

bpf_mtap_softint

Hi, This proposal is a part of the task of MP-safe bpf. To make the task easy, we want to prevent bpf_mtap* from running in hardware interrupt context. By the commit "Move bpf_mtap and if_ipackets++ on Rx of each driver to percpuq if_input" (*), most bpf_mtap on Rx run in softint now. However,

Unify bpf_mtap & if_ipackets++ on Rx

Hi, This is another proposal that unifies bpf_mtap and if_ipackets++, which are executed in each driver now, into the percpuq if_input framework. The benefits of the change are: - We can reduce codes - We can provide the same behavior between drivers - How if_ipackets is counted up - Well,

Re: Deferred if_start

On Mon, Dec 5, 2016 at 6:54 PM, Joerg Sonnenberger <jo...@bec.de> wrote: > On Mon, Dec 05, 2016 at 12:16:42PM +0900, Ryota Ozaki wrote: >> On Fri, Dec 2, 2016 at 7:55 PM, Joerg Sonnenberger <jo...@bec.de> wrote: >> > Especially on older systems, adding non-trivial

Re: Deferred if_start

On Fri, Dec 2, 2016 at 7:55 PM, Joerg Sonnenberger <jo...@bec.de> wrote: > On Fri, Dec 02, 2016 at 06:46:12PM +0900, Ryota Ozaki wrote: >> On Fri, Dec 2, 2016 at 6:32 PM, Joerg Sonnenberger <jo...@bec.de> wrote: >> > On Fri, Dec 02, 2016 at 04:07:24PM +0900, Ry

Re: Deferred if_start

On Fri, Dec 2, 2016 at 6:32 PM, Joerg Sonnenberger <jo...@bec.de> wrote: > On Fri, Dec 02, 2016 at 04:07:24PM +0900, Ryota Ozaki wrote: >> We need it for MP-ification of bpf because some drivers call >> if_start (or equivalent, say drvX_start) from hardware >> interrupt

Deferred if_start

Hi, This proposal introduces the deferred if_start framework for network device drivers. It provides a means to schedule if_start that will be executed in softint later. We need it for MP-ification of bpf because some drivers call if_start (or equivalent, say drvX_start) from hardware interrupt,

Re: Tidy up in6_select*

On Mon, Nov 7, 2016 at 9:55 PM, Ryota Ozaki <ozak...@netbsd.org> wrote: > On Mon, Nov 7, 2016 at 7:12 PM, Roy Marples <r...@marples.name> wrote: >> On 07/11/2016 07:30, Ryota Ozaki wrote: >>> I propose tidy-up of in6_select* functions, esp. >>> selectro

Re: Tidy up in6_select*

On Mon, Nov 7, 2016 at 7:12 PM, Roy Marples <r...@marples.name> wrote: > On 07/11/2016 07:30, Ryota Ozaki wrote: >> I propose tidy-up of in6_select* functions, esp. >> selectroute. > > ... > >> The patch is here: >> http://www.netbsd.org/~ozaki-r/tidyup-

Tidy up in6_select*

Hi, I propose tidy-up of in6_select* functions, esp. selectroute. selectroute is annoying because: - It returns both/either of a rtentry and/or an ifp - Yes, it may return only an ifp! - It is valid but selectroute shouldn't handle the case - Such conditional behavior makes it difficult

Re: if_tun module doesn't autoload if opening /dev/tunN

On Wed, Sep 7, 2016 at 2:50 PM, Paul Goyette wrote: > According to the tun(4) man page, you can create an interface "by using the > ifconfig(8) create command" and this works just fine. The man page goes on > to say "An open() call on /dev/tunN, will also create a network >

Re: -falign-functions=16 for i386/amd64

On Tue, Sep 6, 2016 at 3:14 AM, matthew green wrote: >> dut1# cpuctl identify 0 >> cpu0: highest basic info 000b >> cpu0: highest extended info 8008 >> cpu0: "Intel(R) Atom(TM) CPU C2558 @ 2.40GHz" >> cpu0: Intel Atom C2000 (686-class), 2400.27 MHz >> cpu0: family

Re: -falign-functions=16 for i386/amd64

On Fri, Sep 2, 2016 at 4:40 AM, Joerg Sonnenberger <jo...@bec.de> wrote: > On Thu, Sep 01, 2016 at 10:00:52PM +0900, Ryota Ozaki wrote: >> On Thu, Sep 1, 2016 at 6:45 PM, Joerg Sonnenberger <jo...@bec.de> wrote: >> > On Thu, Sep 01, 2016 at 03:46:15PM +0900,

Re: -falign-functions=16 for i386/amd64

On Thu, Sep 1, 2016 at 6:45 PM, Joerg Sonnenberger <jo...@bec.de> wrote: > On Thu, Sep 01, 2016 at 03:46:15PM +0900, Ryota Ozaki wrote: >> http://www.netbsd.org/~ozaki-r/align-functions-16.diff >> >> The patch adds the option to sys/arch/amd64/conf/Makefile.amd64. >&

Re: -falign-functions=16 for i386/amd64

On Thu, Sep 1, 2016 at 4:04 PM, matthew green wrote: > have you tested other values than 1 and 16? what about 4 or 8? 4 and 8 are not so good; their performance fluctuations are similar to the unaligned case in my experiments. > > can you post the size difference of

Re: -falign-functions=16 for i386/amd64

On Mon, Aug 29, 2016 at 4:43 PM, Ryota Ozaki <ozak...@netbsd.org> wrote: > Hi, > > I propose to set -falign-functions=16 to kernels > of i386/amd64 to reduce performance fluctuations > by small, unrelated changes. > > [Background] > > I noticed that performance of

Re: -falign-functions=16 for i386/amd64

On Mon, Aug 29, 2016 at 4:43 PM, Ryota Ozaki <ozak...@netbsd.org> wrote: > Hi, > > I propose to set -falign-functions=16 to kernels > of i386/amd64 to reduce performance fluctuations > by small, unrelated changes. > > [Background] > > I noticed that performance of

Re: Apply psz/psref to ifaddr and in_ifaddr

On Tue, Jul 26, 2016 at 1:19 PM, Ryota Ozaki <ozak...@netbsd.org> wrote: > Hi, > > This change makes struct ifaddr and struct in_ifaddr > (and lists for them) MP-safe using pserialize(9) and > psref(9). Changes to in6_ifaddr aren't included. http://www.netbsd.org/~ozaki

Apply psz/psref to ifaddr and in_ifaddr

Hi, This change makes struct ifaddr and struct in_ifaddr (and lists for them) MP-safe using pserialize(9) and psref(9). Changes to in6_ifaddr aren't included. There are two patches: http://www.netbsd.org/~ozaki-r/revert-revert-ifaddr-change.diff

Re: CVS commit: src/sys

On Fri, Jul 15, 2016 at 6:18 PM, Martin Husemann <mar...@duskware.de> wrote: > On Fri, Jul 15, 2016 at 09:51:09AM +0900, Ryota Ozaki wrote: >> Does NFS root matter? > > Not sure, Nick says his ERLITE still boots (where NFS root would be the > only obvious difference), but

Re: CVS commit: src/sys

On Fri, Jul 15, 2016 at 4:20 AM, Martin Husemann wrote: >> > >> Modified Files: >> > >> src/sys/net: route.c >> > >> src/sys/netinet: ip_flow.c >> > >> src/sys/netinet6: ip6_flow.c nd6.c > > It is specifically the route.c change, backing that one out avoids the > problem

Re: Run timers in workqueue

On Thu, Jul 7, 2016 at 10:34 AM, Ryota Ozaki <ozak...@netbsd.org> wrote: > Hi, > > Timers (such as nd6_timer) typically free/destroy > some data in callout (softint). If we apply psz/psref > for such data, we cannot do free/destroy process in > there because synchroniza

Run timers in workqueue

Hi, Timers (such as nd6_timer) typically free/destroy some data in callout (softint). If we apply psz/psref for such data, we cannot do free/destroy process in there because synchronization of psz/psref cannot be used in softint. So I propose to run such timers in workqueue. The change is

Re: Introduce curlwp_bind and curlwp_unbind for psref(9)

On Fri, Jul 1, 2016 at 9:51 AM, Masao Uebayashi <uebay...@gmail.com> wrote: > On Tue, Jun 28, 2016 at 10:08 AM, Ryota Ozaki <ozak...@netbsd.org> wrote: >> On Sat, Jun 25, 2016 at 11:56 AM, matthew green <m...@eterna.com.au> wrote: >>>> > Since we alr

Re: Make sure to insert ifa/ia after initialization

On Wed, Jun 29, 2016 at 5:26 PM, Roy Marples <r...@marples.name> wrote: > On 29/06/2016 04:36, Ryota Ozaki wrote: >> On Wed, Jun 29, 2016 at 3:22 AM, Roy Marples <r...@marples.name> wrote: >>> On 2016-06-28 02:03, Ryota Ozaki wrote: >>>> >>>

Make sure to free all interface addresses in if_detach

Hi, Addresses of an interface (struct ifaddr) have a (reverse) pointer of an interface object (ifa->ifa_ifp). If the addresses are surely freed when their interface is destroyed, the pointer is always valid and we don't need a tweak of replacing the pointer to if_index like mbuf. Is the

  1   2   3   4   >