On Wed, Apr 16, 2025 at 9:25 PM Taylor R Campbell wrote:
>
> > Module Name:src
> > Committed By: ozaki-r
> > Date: Wed Apr 16 05:29:45 UTC 2025
> >
> > Modified Files:
> > src/sys/net: if_bridge.c
> >
> > Log Message:
> > bridge: avoid a race condition on stopping callout
>
> Module Name:src
> Committed By: ozaki-r
> Date: Wed Apr 16 05:29:45 UTC 2025
>
> Modified Files:
> src/sys/net: if_bridge.c
>
> Log Message:
> bridge: avoid a race condition on stopping callout
>
> Without BRIDGE_LOCK, the callout can be scheduled after callout_halt.
O
When did it start causing panics ?
Can I get a log of the crash ?
> On 20 Mar 2025, at 9:49 AM, Paul Goyette wrote:
>
> Module Name: src
> Committed By: pgoyette
> Date: Thu Mar 20 09:49:02 UTC 2025
>
> Modified Files:
> src/sys/net/npf: npf_os.c
>
> Log Message:
> Disable auto
On Thu, 20 Mar 2025, Emmanuel Nyarko wrote:
When did it start causing panics ?
sometime between Feb 9 and March 19
Can I get a log of the crash ?
No serial coonsole, but I did transcribe the backtrace:
vpanic
kern_assert
spec_close
VOP_CLOSE
vn_clos
Thanks for kind words!
Apparently, we need some test to detect kernel and userland mismatch
for bpf(4) header...
I'd also like to fix problems by which ATF does not complete on ERL3.
Some CPU/memory consuming tests, e.g., lib/libc/regex/t_exhaust,
trigger watchdog.
I guess something wrong in in
Module Name:src
Committed By: rin
Date: Wed Aug 23 13:21:17 UTC 2023
Modified Files:
src/sys/net: bpf.h
Log Message:
bpf: Fix SIZEOF_BPF_HDR (for LP64 userland) on mips64
It cannot fit within 18 bytes, of course ;)
As we had never provided working bpf(4) implementation f
"Jonathan A. Kollasch" writes:
> Module Name: src
> Committed By: jakllsch
> Date: Thu Jan 5 02:38:51 UTC 2023
>
> Modified Files:
> src/sys/net: if_wg.c
>
> Log Message:
> Check for authorization for SIOCSDRVSPEC and SIOCGDRVSPEC ioctls for wg(4).
>
> Addresses PR 57161.
might be
On 2022/10/25 14:55, Masanobu SAITOH wrote:
>
>
> On 2022/10/25 14:51, matthew green wrote:
>> "SAITOH Masanobu" writes:
>>> Module Name:src
>>> Committed By: msaitoh
>>> Date: Mon Oct 24 07:45:44 UTC 2022
>>>
>>> Modified Files:
>>> src/sys/net: if_dl.h
>>>
>>>
On 2022/10/25 14:51, matthew green wrote:
> "SAITOH Masanobu" writes:
>> Module Name: src
>> Committed By:msaitoh
>> Date:Mon Oct 24 07:45:44 UTC 2022
>>
>> Modified Files:
>> src/sys/net: if_dl.h
>>
>> Log Message:
>> Increase sdl_data so that more then IFNAMSIZ byt
"SAITOH Masanobu" writes:
> Module Name: src
> Committed By: msaitoh
> Date: Mon Oct 24 07:45:44 UTC 2022
>
> Modified Files:
> src/sys/net: if_dl.h
>
> Log Message:
> Increase sdl_data so that more then IFNAMSIZ bytes are available.
>
> - Increase the size of dl_data[] from 12 to 2
On Mon, 15 Nov 2021 07:07:06 +
Shoichi YAMAGUCHI wrote:
> Date: Mon Nov 15 07:07:06 UTC 2021
>
> Modified Files:
> src/sys/net: if_ether.h if_ethersubr.c if_vlan.c
> src/sys/net/lagg: if_lagg.c
>
> Log Message:
> introduced APIs to configure VLAN TAG to ethernet devices
In article <20210506061816.94bb1f...@cvs.netbsd.org>,
Shoichi YAMAGUCHI wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: yamaguchi
>Date: Thu May 6 06:18:16 UTC 2021
>
>Modified Files:
> src/sys/net: if_spppsubr.c
>
>Log Message:
>do not clear destination address if there
> (I haven't investigated exactly what's going on leading to ~5 KB-byte
> stack frames, but this shuts gcc up, at least, and the hypotheses
> sound plausible to me!)
this matches what i saw when looking at it. i was going to
test the exact same idea (noinline).
.mrg.
On 13/02/2021 14:19, Jonathan A. Kollasch wrote:
On Sat, Feb 13, 2021 at 07:28:05AM +, Roy Marples wrote:
Module Name:src
Committed By: roy
Date: Sat Feb 13 07:28:05 UTC 2021
Modified Files:
src/sys/net: if_ether.h if_ethersubr.c
Log Message:
if_ether: Ensure that e
On Sat, Feb 13, 2021 at 07:28:05AM +, Roy Marples wrote:
> Module Name: src
> Committed By: roy
> Date: Sat Feb 13 07:28:05 UTC 2021
>
> Modified Files:
> src/sys/net: if_ether.h if_ethersubr.c
>
> Log Message:
> if_ether: Ensure that ether_header is aligned
>
>
> To generate
Hi,
I have one question about the following commit.
Why stoeplitz_hash_ip4() and stoeplitz_hash_ip4port() argument types
are different between toeplitz.c and toeplitz.h? They have in_addr_t
and in_port_t argument types in toeplitz.c, howerver uint32_t and
uint16_t in toeplitz.h.
On 2021/01/31
On 29.01.2020 07:40, Jason Thorpe wrote:
>
>> On Jan 28, 2020, at 10:25 PM, Kamil Rytarowski wrote:
>>
>> The distribution build breaks for me with:
>
> Should be fixed with:
>
> /cvsroot/src/sys/rump/net/lib/libnet/Makefile,v <-- Makefile
> new revision: 1.33; previous revision: 1.32
>
>>
> On Jan 28, 2020, at 10:25 PM, Kamil Rytarowski wrote:
>
> The distribution build breaks for me with:
Should be fixed with:
/cvsroot/src/sys/rump/net/lib/libnet/Makefile,v <-- Makefile
new revision: 1.33; previous revision: 1.32
> /public/netbsd-root/tooldir.NetBSD-9.99.38-amd64/lib/gcc
On 29.01.2020 04:16, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Wed Jan 29 03:16:28 UTC 2020
>
> Modified Files:
> src/sys/net: Makefile files.net if.c if.h
> Added Files:
> src/sys/net: if_stats.c if_stats.h
>
> Log Message:
> Add support for MP
On 2019/12/05 14:29, SAITOH Masanobu wrote:
> Module Name: src
> Committed By: msaitoh
> Date: Thu Dec 5 05:29:28 UTC 2019
>
> Modified Files:
> src/sys/net: if_media.h
>
> Log Message:
> Fix previous comment change for ifm_media. It was correct.
>
> The real problem is that som
On Mon, Sep 23, 2019 at 4:14 PM Kamil Rytarowski wrote:
>
> On 23.09.2019 06:53, Rin Okuyama wrote:
> > Hi,
> >
> > On 2019/09/22 18:30, Kamil Rytarowski wrote:
> >> On 12.04.2018 06:38, Ryota Ozaki wrote:
> >>> Module Name:src
> >>> Committed By:ozaki-r
> >>> Date:Thu Apr 12 04:38
On 23.09.2019 06:53, Rin Okuyama wrote:
> Hi,
>
> On 2019/09/22 18:30, Kamil Rytarowski wrote:
>> On 12.04.2018 06:38, Ryota Ozaki wrote:
>>> Module Name: src
>>> Committed By: ozaki-r
>>> Date: Thu Apr 12 04:38:13 UTC 2018
>>>
>>> Modified Files:
>>> src/sys/net: if.h route.c rou
Hi,
On 2019/09/22 18:30, Kamil Rytarowski wrote:
On 12.04.2018 06:38, Ryota Ozaki wrote:
Module Name:src
Committed By: ozaki-r
Date: Thu Apr 12 04:38:13 UTC 2018
Modified Files:
src/sys/net: if.h route.c route.h rtsock.c
Log Message:
Resolve tangled lock dependencies i
On 12.04.2018 06:38, Ryota Ozaki wrote:
> Module Name: src
> Committed By: ozaki-r
> Date: Thu Apr 12 04:38:13 UTC 2018
>
> Modified Files:
> src/sys/net: if.h route.c route.h rtsock.c
>
> Log Message:
> Resolve tangled lock dependencies in route.c
>
> This change sweeps remaining
Le 06/08/2019 à 12:31, Christos Zoulas a écrit :
I did not see any messages about it, and the fix is fine until rmind comes up
with something better.
Yes turns out it was an off-list email
It is not nice to have HEAD unusable for 2 weeks now (since July 22nd).
Given your second commit, I s
Yes, rmind asked me to commit the change in private email.
christos
> On Aug 6, 2019, at 3:59 PM, Maxime Villard wrote:
>
> Le 06/08/2019 à 12:31, Christos Zoulas a écrit :
>> I did not see any messages about it, and the fix is fine until rmind comes
>> up with something better.
>
> Yes turns
I did not see any messages about it, and the fix is fine until rmind comes up
with something better.
It is not nice to have HEAD unusable for 2 weeks now (since July 22nd).
christos
> On Aug 6, 2019, at 1:26 PM, Maxime Villard wrote:
>
> Le 06/08/2019 à 12:25, Christos Zoulas a écrit :
>> Modu
Le 06/08/2019 à 12:25, Christos Zoulas a écrit :
Module Name:src
Committed By: christos
Date: Tue Aug 6 10:25:13 UTC 2019
Modified Files:
src/sys/net/npf: npf_conn.c
Log Message:
Introduce an npf_conn_destroy_idx() that can handle partially constructed
conn structures.
In article ,
Ryota Ozaki wrote:
>On Tue, Apr 16, 2019 at 5:51 AM Christos Zoulas wrote:
>>
>> Module Name:src
>> Committed By: christos
>> Date: Mon Apr 15 20:51:46 UTC 2019
>>
>> Modified Files:
>> src/sys/net: if.c
>>
>> Log Message:
>> Zero out the ifreq struct for SIO
On Tue, Apr 16, 2019 at 5:51 AM Christos Zoulas wrote:
>
> Module Name:src
> Committed By: christos
> Date: Mon Apr 15 20:51:46 UTC 2019
>
> Modified Files:
> src/sys/net: if.c
>
> Log Message:
> Zero out the ifreq struct for SIOCGIFCONF to avoid up to 127 bytes of stack
>
Date:Tue, 26 Mar 2019 00:23:32 +
From:"Paul Goyette"
Message-ID: <20190326002332.c0241f...@cvs.netbsd.org>
| XXX Someone(tm) needs to update MAKEDEV to create the /dev/srtN device
| nodes (with device-major 179)!
Yes, I know ...
That's easy - but as I mentio
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Mon Feb 18 23:13:14 UTC 2019
>
> Modified Files:
> src/sys/net: zlib.c
>
> Log Message:
> add fallthrough's
i specific avoided changing upstream code where possible by adding
the relevant cflags.
where
Thank you for finding it out. I removed it in accident.
rin
On 2018/12/14 21:27, Martin Husemann wrote:
Module Name:src
Committed By: martin
Date: Fri Dec 14 12:27:22 UTC 2018
Modified Files:
src/sys/net: if_bridge.c
Log Message:
Need for ip6_statinc() prototype.
To
Panic seems not optimal. A rate limited log message at LOG_ERROR seems better.
-- thorpej
Sent from my iPhone.
> On Dec 13, 2018, at 12:54 PM, Rin Okuyama wrote:
>
> Module Name:src
> Committed By:rin
> Date:Thu Dec 13 20:54:50 UTC 2018
>
> Modified Files:
>src/sys/net: et
On Tue, Jul 10, 2018 at 05:02:27PM +, Christos Zoulas wrote:
> Should be pulled up to -8, with the other patch.
Already done ;-)
In article <20180710110040.e80fcf...@cvs.netbsd.org>,
Robert Elz wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: kre
>Date: Tue Jul 10 11:00:40 UTC 2018
>
>Modified Files:
> src/sys/net: if_llatbl.c
>
>Log Message:
>Avoid attempting to call arp related functions if there i
Le 07/04/2018 à 23:28, Christos Zoulas a écrit :
In article <20180407090627.20058f...@cvs.netbsd.org>,
Maxime Villard wrote:
-=-=-=-=-=-
Module Name:src
Committed By: maxv
Date: Sat Apr 7 09:06:27 UTC 2018
Modified Files:
src/sys/net/npf: npf_inet.c
Log Message:
Rewr
In article <20180407090627.20058f...@cvs.netbsd.org>,
Maxime Villard wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: maxv
>Date: Sat Apr 7 09:06:27 UTC 2018
>
>Modified Files:
> src/sys/net/npf: npf_inet.c
>
>Log Message:
>Rewrite npf_fetch_tcpopts:
>
> * Instead of doing
Le 31/01/2018 à 00:18, Mindaugas Rasiukevicius a écrit :
[...]
Fix this by using uint32_t. While here, it seems to me there is also a
memory overflow: still in npf_cache_ip, npc_hlen may be incremented with
a value that goes beyond the mbuf.
[...]
If the npc_hlen value is beyond the packet leng
"Maxime Villard" wrote:
> Module Name: src
> Committed By: maxv
> Date: Fri Dec 15 21:00:26 UTC 2017
>
> Modified Files:
> src/sys/net/npf: npf.h
>
> Log Message:
> Fix a vulnerability in NPF, that allows whatever incoming IPv6 packet to
> bypass a certain number of filtering rule
Le 19/01/2018 à 13:31, Takeshi Nakayama a écrit :
Module Name:src
Committed By: nakayama
Date: Fri Jan 19 12:31:28 UTC 2018
Modified Files:
src/sys/net: if_ethersubr.c
Log Message:
Fix inverted logic.
To generate a diff of this commit:
cvs rdiff -u -r1.256 -r1.257 src/
On Tue, Jan 09, 2018 at 01:07:50AM +, m...@netbsd.org wrote:
> This is causing PR kern/52914 (on netbsd-8, not current)
Copied wrong number
kern/52895
it's in -current but also -8
This is causing PR kern/52914 (on netbsd-8, not current)
On Fri, Dec 15, 2017 at 04:04:59AM +, Ryota Ozaki wrote:
> Module Name: src
> Committed By: ozaki-r
> Date: Fri Dec 15 04:04:59 UTC 2017
>
> Modified Files:
> src/sys/net: if.c
>
> Log Message:
> Remove IFNET_GLOBAL_LOCK
2017/12/18 22:09 "Christos Zoulas" :
On Dec 18, 2:42pm, ozak...@netbsd.org (Ryota Ozaki) wrote:
-- Subject: Re: CVS commit: src/sys/net
| Oh cool. I didn't know that technique.
Great, can you undo the change then?
I already did it :)
ozaki-r
Thanks,
christos
On Dec 18, 2:42pm, ozak...@netbsd.org (Ryota Ozaki) wrote:
-- Subject: Re: CVS commit: src/sys/net
| Oh cool. I didn't know that technique.
Great, can you undo the change then?
Thanks,
christos
On Thu, Dec 14, 2017 at 10:03 PM, Christos Zoulas wrote:
> On Dec 14, 5:42pm, ozak...@netbsd.org (Ryota Ozaki) wrote:
> -- Subject: Re: CVS commit: src/sys/net
>
> | Is there a flag to suppress auto inlining? COPTS=-fno-inline build.sh?
> | Anyway no objection to revert the cha
On Dec 14, 5:42pm, ozak...@netbsd.org (Ryota Ozaki) wrote:
-- Subject: Re: CVS commit: src/sys/net
| Is there a flag to suppress auto inlining? COPTS=-fno-inline build.sh?
| Anyway no objection to revert the change that is not quite important
| (but makes my life easy).
just do:
cat <<
On Thu, Dec 14, 2017 at 3:27 PM, Christos Zoulas wrote:
> In article <20171214054314.e76edf...@cvs.netbsd.org>,
> Ryota Ozaki wrote:
>>-=-=-=-=-=-
>>
>>Module Name: src
>>Committed By: ozaki-r
>>Date: Thu Dec 14 05:43:14 UTC 2017
>>
>>Modified Files:
>> src/sys/net: rtsock.c
>>
In article <20171214054314.e76edf...@cvs.netbsd.org>,
Ryota Ozaki wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: ozaki-r
>Date: Thu Dec 14 05:43:14 UTC 2017
>
>Modified Files:
> src/sys/net: rtsock.c
>
>Log Message:
>Spinkle __noinline to some non-performance-sensitive fu
On 2017/11/22 14:40, Robert Elz wrote:
Date:Wed, 22 Nov 2017 04:56:52 +
From:"SAITOH Masanobu"
Message-ID: <20171122045652.2ee75f...@cvs.netbsd.org>
| Return EINVAL in vlan_config() when a VLAN ID is 0 or 65535.
| The spec states 0 and 65535 are reser
Date:Wed, 22 Nov 2017 04:56:52 +
From:"SAITOH Masanobu"
Message-ID: <20171122045652.2ee75f...@cvs.netbsd.org>
| Return EINVAL in vlan_config() when a VLAN ID is 0 or 65535.
| The spec states 0 and 65535 are reserved.
Tags are 12 bigs, so 0..4095 (65535 won'
On Fri, Sep 22, 2017 at 5:53 PM, Joerg Sonnenberger wrote:
> On Fri, Sep 22, 2017 at 05:05:32AM +, Ryota Ozaki wrote:
>> Module Name: src
>> Committed By: ozaki-r
>> Date: Fri Sep 22 05:05:32 UTC 2017
>>
>> Modified Files:
>> src/sys/net: route.c
>>
>> Log Message:
>> Remove the
On Fri, Sep 22, 2017 at 05:05:32AM +, Ryota Ozaki wrote:
> Module Name: src
> Committed By: ozaki-r
> Date: Fri Sep 22 05:05:32 UTC 2017
>
> Modified Files:
> src/sys/net: route.c
>
> Log Message:
> Remove the global lock for rtcache
>
> Thanks to removal of LIST_ENTRY of stru
On Thu, Apr 6, 2017 at 3:34 AM, Taylor R Campbell
wrote:
>> Date: Wed, 5 Apr 2017 15:46:38 +0800 (+08)
>> From: Paul Goyette
>>
>> @@ -3385,6 +3428,13 @@ if_mcast_op(ifnet_t *ifp, const unsigned
>> {
>> int rc;
>> struct ifreq ifr;
>> + bool need_unlock = false;
>> +
>>
> Date: Wed, 5 Apr 2017 15:46:38 +0800 (+08)
> From: Paul Goyette
>
> @@ -3385,6 +3428,13 @@ if_mcast_op(ifnet_t *ifp, const unsigned
> {
> int rc;
> struct ifreq ifr;
> + bool need_unlock = false;
> +
> + /* XXX if_ioctl_lock may or may not be held here */
> +
@@ -3385,6 +3428,13 @@ if_mcast_op(ifnet_t *ifp, const unsigned
{
int rc;
struct ifreq ifr;
+ bool need_unlock = false;
+
+ /* XXX if_ioctl_lock may or may not be held here */
+ if (ifp->if_ioctl_lock != NULL && !mutex_owned(ifp->if_ioctl_lock)) {
+
oops, I was wrong here, please disregard :-)
On Thu, Jan 26, 2017 at 09:13:19PM +, Nick Hudson wrote:
> @@ -803,32 +790,14 @@ tunread(dev_t dev, struct uio *uio, int
> goto out;
> }
> tp->tun_flags |= TUN_RWAIT;
> - if (mtsleep((void *)tp, PZERO
Hi,
On Thu, Jan 26, 2017 at 09:13:19PM +, Nick Hudson wrote:
> @@ -534,14 +527,12 @@ tun_output(struct ifnet *ifp, struct mbu
> const struct rtentry *rt)
> {
> struct tun_softc *tp = ifp->if_softc;
> - int s;
> int error;
> #if defined(INET) || de
Hi,
On 2016/06/27 18:55, Roy Marples wrote:
> On 27/06/2016 09:58, Kengo NAKAHARA wrote:
>> Module Name: src
>> Committed By:knakahara
>> Date:Mon Jun 27 08:58:50 UTC 2016
>>
>> Modified Files:
>> src/sys/net: if.c if.h
>>
>> Log Message:
>> reduce link state changing
On 27/06/2016 09:58, Kengo NAKAHARA wrote:
> Module Name: src
> Committed By: knakahara
> Date: Mon Jun 27 08:58:50 UTC 2016
>
> Modified Files:
> src/sys/net: if.c if.h
>
> Log Message:
> reduce link state changing softint if it is not required
>
> ok by ozaki-r@n.o
There is a s
Date: Mon, 11 Apr 2016 14:33:41 +0900
From: Ryota Ozaki
On Mon, Apr 11, 2016 at 12:31 PM, Taylor R Campbell
wrote:
> Nice, thanks for doing this! Have you tried subjecting it to load,
> with options DIAGNOSTIC?
Yes. It passes ATF tests (that enable DIAGNOSTIC).
OK, great!
On Mon, Apr 11, 2016 at 12:31 PM, Taylor R Campbell
wrote:
>Date: Mon, 11 Apr 2016 02:04:14 +
>From: Ryota Ozaki
>
>Module Name:src
>Committed By: ozaki-r
>Date: Mon Apr 11 02:04:14 UTC 2016
>
>Modified Files:
>src/sys/net: bridgestp.c if_br
Date: Mon, 11 Apr 2016 02:04:14 +
From: Ryota Ozaki
Module Name:src
Committed By: ozaki-r
Date: Mon Apr 11 02:04:14 UTC 2016
Modified Files:
src/sys/net: bridgestp.c if_bridge.c if_bridgevar.h
Log Message:
Use pslist(9) in bridge(4)
Thi
> And add an assertion of if_addrlen and ll_addr.
thanks. i almost did this myself :-)
On Fri, Feb 19, 2016 at 12:16 PM, Roy Marples wrote:
> On 18/02/2016 11:29, Ryota Ozaki wrote:
>> Okay, I've changed my mind. Let's commit your patch anyway and
>> keep an eye on the lossage messages to know how often and how
>> many lossage happens. If there are issues, we can improve then.
>> It
On 18/02/2016 11:29, Ryota Ozaki wrote:
> Okay, I've changed my mind. Let's commit your patch anyway and
> keep an eye on the lossage messages to know how often and how
> many lossage happens. If there are issues, we can improve then.
> It's not too late.
The irony is that overnight I changed my m
On Thu, Feb 18, 2016 at 12:08 PM, Ryota Ozaki wrote:
> On Thu, Feb 18, 2016 at 12:18 AM, Roy Marples wrote:
>> On 17/02/2016 01:46, Roy Marples wrote:
>>> Patch attached to solve change from a priority array into a bit mask
>>> approach where we swallow the whole queue in a softint.
>>
>> I did t
On 2016/02/18 11:54, Ryota Ozaki wrote:
On Wed, Feb 17, 2016 at 9:12 PM, Roy Marples wrote:
On 17/02/2016 09:02, Ryota Ozaki wrote:
So what events would you choose to skip, if not the scheme that Roy
described?
(I think I confused you, sorry...)
I rather want to not skip anything as much as
On Thu, Feb 18, 2016 at 12:18 AM, Roy Marples wrote:
> On 17/02/2016 01:46, Roy Marples wrote:
>> Patch attached to solve change from a priority array into a bit mask
>> approach where we swallow the whole queue in a softint.
>
> I did the same tests as noted in PR 50602 - put the system under loa
On Wed, Feb 17, 2016 at 9:12 PM, Roy Marples wrote:
> On 17/02/2016 09:02, Ryota Ozaki wrote:
>>> So what events would you choose to skip, if not the scheme that Roy
>>> described?
>>
>> (I think I confused you, sorry...)
>>
>> I rather want to not skip anything as much as possible
>> (except for
On 17/02/2016 01:46, Roy Marples wrote:
> Patch attached to solve change from a priority array into a bit mask
> approach where we swallow the whole queue in a softint.
I did the same tests as noted in PR 50602 - put the system under load by
building clang from src and qt5 from pkgsrc at the same
On 17/02/2016 09:02, Ryota Ozaki wrote:
>> So what events would you choose to skip, if not the scheme that Roy
>> described?
>
> (I think I confused you, sorry...)
>
> I rather want to not skip anything as much as possible
> (except for repeating same events (e.g., up/up/up) because
> keeping the
On Wed, Feb 17, 2016 at 4:52 PM, Taylor R Campbell
wrote:
>Date: Wed, 17 Feb 2016 15:12:31 +0900
>From: Ryota Ozaki
>
>On Wed, Feb 17, 2016 at 2:13 PM, Taylor R Campbell
> wrote:
>> Note that this queueing takes effect only if the link state changes
>> multiple times withi
Date: Wed, 17 Feb 2016 15:12:31 +0900
From: Ryota Ozaki
On Wed, Feb 17, 2016 at 2:13 PM, Taylor R Campbell
wrote:
> Note that this queueing takes effect only if the link state changes
> multiple times within maybe a few microseconds, before the softint can
> run. If your li
On Wed, Feb 17, 2016 at 2:13 PM, Taylor R Campbell
wrote:
>Date: Wed, 17 Feb 2016 11:49:48 +0900
>From: Ryota Ozaki
>
>And the priority provides asymmetric event deliveries; when the state
>repeats up and down, a down event is delivered if the final state is down
>while a down
On Wed, Feb 17, 2016 at 1:40 PM, Roy Marples wrote:
> On 2016-02-17 02:49, Ryota Ozaki wrote:
>>>
>>> If you don't read the patch, here is the comment I added to the
>>> if_link_state_change() function:
>>>
>>> * Queue a change in the interface link state.
>>> *
>>> * The queue itself is very limi
Date: Wed, 17 Feb 2016 11:49:48 +0900
From: Ryota Ozaki
And the priority provides asymmetric event deliveries; when the state
repeats up and down, a down event is delivered if the final state is down
while a down event and a up event are delivered if the final state is up.
It's
On 2016-02-17 02:49, Ryota Ozaki wrote:
If you don't read the patch, here is the comment I added to the
if_link_state_change() function:
* Queue a change in the interface link state.
*
* The queue itself is very limited:
* no state can be queued more than once
* a higher priority state will
On Wed, Feb 17, 2016 at 10:46 AM, Roy Marples wrote:
> On Tuesday 16 February 2016 22:20:37 Taylor R Campbell wrote:
>> Except for an issue with queueing discussed privately (scheduling a
>> softint that is already scheduled won't cause it to run again, so
>> if_link_state_change_si needs to proce
On Tuesday 16 February 2016 22:20:37 Taylor R Campbell wrote:
> Except for an issue with queueing discussed privately (scheduling a
> softint that is already scheduled won't cause it to run again, so
> if_link_state_change_si needs to process the whole queue in one go),
> that approach looks fine t
On Tuesday 16 February 2016 22:20:37 Taylor R Campbell wrote:
> This has the consequence that if the link goes up/down in quick
> succession, and then up/down in quick succession, &c., with the queue
> processed after each up/down transition, userland will never be
> notified. However, if the link
Date: Tue, 16 Feb 2016 13:24:15 +
From: Roy Marples
I found the time to work on this, here is the patch I've been running
for an hour or so upping and downing interfaces.
The rule in Roy's patch is that each new state changes kicks out all
higher-priority transitions, and is queu
Date: Tue, 16 Feb 2016 08:38:55 +
From: Roy Marples
The queue can be kept quite short because we don't care about any prior
entries each time state changes to LINK_STATE_DOWN.
Also, we don't care about any prior entries (other than LINK_STATE_DOWN)
when
setting LINK_STATE
Date: Tue, 16 Feb 2016 16:30:54 +0900
From: Ryota Ozaki
On Tue, Feb 16, 2016 at 6:16 AM, Taylor R Campbell
wrote:
> void
> if_link_state_change(struct ifnet *ifp, int link_state)
> {
> int s;
>
> s = splnet();
> if (ifp->if_link_state_pend
On 16/02/2016 08:38, Roy Marples wrote:
> On Tuesday 16 February 2016 13:37:28 you wrote:
>>> Oh, I see. We shouldn't drop any events of link state changes.
>>
>> i don't see any point in keeping a huge series of link changes
>> if they can be collapsed into an equivalent sequence. with VMs
>> and
On 16/02/2016 08:38, Roy Marples wrote:
> for (i = 0; i < ifp->if_link_queue_len; i++) {
> if (link_state <= ifp->if_link_queue[i]) {
> ifp->if_link_queue[i] = link_state;
> ifp->if_link_queue_len = i;
This should be ifp->if_link_queu
On Tuesday 16 February 2016 13:37:28 you wrote:
> > Oh, I see. We shouldn't drop any events of link state changes.
>
> i don't see any point in keeping a huge series of link changes
> if they can be collapsed into an equivalent sequence. with VMs
> and other user-controlled systems it's possible
On Tue, Feb 16, 2016 at 6:16 AM, Taylor R Campbell
wrote:
>Date: Mon, 15 Feb 2016 11:06:52 +
>From: Roy Marples
>
>On 15/02/2016 10:32, Ryota Ozaki wrote:
>> I think we can fix by returning from if_link_state_change_si
>> if ifp->if_link_state == ifp->if_old_link_state. Is
On Tue, Feb 16, 2016 at 11:37 AM, matthew green wrote:
>> Oh, I see. We shouldn't drop any events of link state changes.
>
> i don't see any point in keeping a huge series of link changes
> if they can be collapsed into an equivalent sequence. with VMs
> and other user-controlled systems it's pos
> Oh, I see. We shouldn't drop any events of link state changes.
i don't see any point in keeping a huge series of link changes
if they can be collapsed into an equivalent sequence. with VMs
and other user-controlled systems it's possible to flood such a
link state checking engine.
.mrg.
On Mon, Feb 15, 2016 at 8:06 PM, Roy Marples wrote:
> On 15/02/2016 10:32, Ryota Ozaki wrote:
>> On Mon, Feb 15, 2016 at 6:35 PM, Roy Marples wrote:
>>> On 15/02/2016 08:08, Ryota Ozaki wrote:
Module Name: src
Committed By: ozaki-r
Date: Mon Feb 15 08:08:04 UTC 2016
>
Date: Mon, 15 Feb 2016 11:06:52 +
From: Roy Marples
On 15/02/2016 10:32, Ryota Ozaki wrote:
> I think we can fix by returning from if_link_state_change_si
> if ifp->if_link_state == ifp->if_old_link_state. Is it correct?
Then we're not doing what we should because the proto
On Mon, Feb 15, 2016 at 11:06:52AM +, Roy Marples wrote:
> Can we not extend softint_schedule to take some user data? That way,
> each call (which I'm assuming would be sequential) can carry the link
> state change in the user data which can then be applied to the interface.
Sounds like a work
On 15/02/2016 10:32, Ryota Ozaki wrote:
> On Mon, Feb 15, 2016 at 6:35 PM, Roy Marples wrote:
>> On 15/02/2016 08:08, Ryota Ozaki wrote:
>>> Module Name: src
>>> Committed By: ozaki-r
>>> Date: Mon Feb 15 08:08:04 UTC 2016
>>>
>>> Modified Files:
>>> src/sys/net: if.c if.h
>>>
>>> L
On Mon, Feb 15, 2016 at 6:35 PM, Roy Marples wrote:
> On 15/02/2016 08:08, Ryota Ozaki wrote:
>> Module Name: src
>> Committed By: ozaki-r
>> Date: Mon Feb 15 08:08:04 UTC 2016
>>
>> Modified Files:
>> src/sys/net: if.c if.h
>>
>> Log Message:
>> Run if_link_state_change in softint
On 15/02/2016 08:08, Ryota Ozaki wrote:
> Module Name: src
> Committed By: ozaki-r
> Date: Mon Feb 15 08:08:04 UTC 2016
>
> Modified Files:
> src/sys/net: if.c if.h
>
> Log Message:
> Run if_link_state_change in softint
>
> if_link_state_change can execute the network stack that i
Hi,
On 2016/01/13 7:10, David Laight wrote:
> On Fri, Dec 11, 2015 at 11:37:29AM +0900, Kengo NAKAHARA wrote:
>> # Sorry, I forgot to subscribe source-changes-d ml, I reply as
>> # a new mail.
>>
>> Hi,
>>
>>> In article <20151210081103.E0FBBFB83%cvs.NetBSD.org@localhost>,
>>> Kengo NAKAHARA wrot
On Fri, Dec 11, 2015 at 11:37:29AM +0900, Kengo NAKAHARA wrote:
> # Sorry, I forgot to subscribe source-changes-d ml, I reply as
> # a new mail.
>
> Hi,
>
> > In article <20151210081103.E0FBBFB83%cvs.NetBSD.org@localhost>,
> > Kengo NAKAHARA wrote:
> >>-=-=-=-=-=-
> >>
> >>Module Name:sr
Hi,
On 2015/12/11 13:00, Christos Zoulas wrote:
> On Dec 11, 11:37am, k-nakah...@iij.ad.jp (Kengo NAKAHARA) wrote:
> -- Subject: Re: CVS commit: src/sys/net
>
> | Hi,
> |
> | > In article <20151210081103.E0FBBFB83%cvs.NetBSD.org@localhost>,
1 - 100 of 217 matches
Mail list logo
