On Tue, Feb 16, 2021 at 09:29:15AM +, Roy Marples wrote:
> In my testing on aarch64 and octeon (both of which I think are strict
> alignment) neither need pullups nor copyups as the mbuf already has enough
> and arphrd is aligned correctly already.
Ah, we asserted too much alignment - indeed,
On 16/02/2021 09:20, Martin Husemann wrote:
On Tue, Feb 16, 2021 at 08:26:40AM +, Roy Marples wrote:
Is that because ARP_HDR_ALIGNMENT is forcing 4 byte alignment?
The KASSERT a few lines below triggerd, we need to be consistent.
For the purposes of using just the header we define I'm pr
On Tue, Feb 16, 2021 at 08:26:40AM +, Roy Marples wrote:
> Is that because ARP_HDR_ALIGNMENT is forcing 4 byte alignment?
The KASSERT a few lines below triggerd, we need to be consistent.
> For the purposes of using just the header we define I'm pretty sure we can
> use 2 byte alignment and s
On 16/02/2021 05:44, Martin Husemann wrote:
Module Name:src
Committed By: martin
Date: Tue Feb 16 05:44:14 UTC 2021
Modified Files:
src/sys/netinet: if_arp.c
Log Message:
Undo previous backout: alignment is needed here.
The reason for the previous backout was a misunders
> On Dec 4, 2020, at 8:57 AM, Christos Zoulas wrote:
>
> In article <20201204004439.90c25f...@cvs.netbsd.org>,
> Jason R Thorpe wrote:
>> -=-=-=-=-=-
>>
>> Module Name: src
>> Committed By:thorpej
>> Date:Fri Dec 4 00:44:39 UTC 2020
>>
>> Modified Files:
>> src/
In article <20201204004439.90c25f...@cvs.netbsd.org>,
Jason R Thorpe wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: thorpej
>Date: Fri Dec 4 00:44:39 UTC 2020
>
>Modified Files:
> src/sys/netinet: files.ipfilter
>
>Log Message:
>Build ip_sync.c with -Wno-error to avoid f
On Mon, Feb 25, 2019 at 11:35:35AM +0100, Kamil Rytarowski wrote:
> This is right, SCTP build wasn't tested and I got it enabled locally.
> I propose to build ALL by default as we now depend on external services
> to have functional 24/7 build with sanitizers (syzkaller).
Yes, it needs to be part
On 25.02.2019 11:23, Martin Husemann wrote:
> On Mon, Feb 25, 2019 at 01:19:02PM +0300, Valery Ushakov wrote:
>> On Mon, Feb 25, 2019 at 06:23:33 +0100, Martin Husemann wrote:
>>
>>> On Sun, Feb 24, 2019 at 09:43:52PM +0100, Kamil Rytarowski wrote:
I consider that this is just GCC specific beh
On Mon, Feb 25, 2019 at 01:19:02PM +0300, Valery Ushakov wrote:
> On Mon, Feb 25, 2019 at 06:23:33 +0100, Martin Husemann wrote:
>
> > On Sun, Feb 24, 2019 at 09:43:52PM +0100, Kamil Rytarowski wrote:
> > > I consider that this is just GCC specific behavior to make some warnings
> > > fatal depend
On Mon, Feb 25, 2019 at 06:23:33 +0100, Martin Husemann wrote:
> On Sun, Feb 24, 2019 at 09:43:52PM +0100, Kamil Rytarowski wrote:
> > I consider that this is just GCC specific behavior to make some warnings
> > fatal depending on driver configuration. This is typical behavior of GCC
> > that we k
> If you think that this is better and it works, please go for it.
please, no.
don't duplicate prototypes in a way that changes won't be detected.
ie, if the real sctp code changes, today the compat caller will
fail to build until updated. with this change, it will build and
be entirely wrong.
On 24.02.2019 23:55, Robert Swindells wrote:
>
> Kamil Rytarowski wrote:
>> Module Name:src
>> Committed By: kamil
>> Date: Sun Feb 24 17:01:52 UTC 2019
>>
>> Modified Files:
>>src/sys/netinet: sctp_asconf.h
>>
>> Log Message:
>> Appease GCC7 in sctp_asconf.h
>>
>> Do not
Kamil Rytarowski wrote:
>Module Name:src
>Committed By: kamil
>Date: Sun Feb 24 17:01:52 UTC 2019
>
>Modified Files:
>src/sys/netinet: sctp_asconf.h
>
>Log Message:
>Appease GCC7 in sctp_asconf.h
>
>Do not declare types inside function parameter list.
>Add decklarations o
On Sun, Feb 24, 2019 at 09:43:52PM +0100, Kamil Rytarowski wrote:
> I consider that this is just GCC specific behavior to make some warnings
> fatal depending on driver configuration. This is typical behavior of GCC
> that we keep observing all over again.
No, this is very different to optimizer a
On 24.02.2019 21:38, Martin Husemann wrote:
> On Sun, Feb 24, 2019 at 09:36:55PM +0100, Kamil Rytarowski wrote:
>> My only specific change was NetBSD/i386 kernel=GENERIC with kUBSan and
>> KCOV enabled.
>
> This does not answer the question. What does enabling kUBSan/KCOV break
> to make this erro
On 24.02.2019 21:43, Kamil Rytarowski wrote:
> On 24.02.2019 21:38, Martin Husemann wrote:
>> On Sun, Feb 24, 2019 at 09:36:55PM +0100, Kamil Rytarowski wrote:
>>> My only specific change was NetBSD/i386 kernel=GENERIC with kUBSan and
>>> KCOV enabled.
>>
>> This does not answer the question. What
On Sun, Feb 24, 2019 at 09:36:55PM +0100, Kamil Rytarowski wrote:
> My only specific change was NetBSD/i386 kernel=GENERIC with kUBSan and
> KCOV enabled.
This does not answer the question. What does enabling kUBSan/KCOV break
to make this error show up in your compilation, but not in our default
On 24.02.2019 20:39, Martin Husemann wrote:
> On Sun, Feb 24, 2019 at 07:20:10PM +0100, Kamil Rytarowski wrote:
>> On 24.02.2019 19:15, David Holland wrote:
>>> On Sun, Feb 24, 2019 at 05:01:52PM +, Kamil Rytarowski wrote:
>>> > Modified Files:
>>> > src/sys/netinet: sctp_asconf.h
>>> >
>>
On Sun, Feb 24, 2019 at 07:20:10PM +0100, Kamil Rytarowski wrote:
> On 24.02.2019 19:15, David Holland wrote:
> > On Sun, Feb 24, 2019 at 05:01:52PM +, Kamil Rytarowski wrote:
> > > Modified Files:
> > > src/sys/netinet: sctp_asconf.h
> > >
> > > Log Message:
> > > Appease GCC7 in sctp_a
On 24.02.2019 19:15, David Holland wrote:
> On Sun, Feb 24, 2019 at 05:01:52PM +, Kamil Rytarowski wrote:
> > Modified Files:
> >src/sys/netinet: sctp_asconf.h
> >
> > Log Message:
> > Appease GCC7 in sctp_asconf.h
> >
> > Do not declare types inside function parameter list.
> > A
On Sun, Feb 24, 2019 at 05:01:52PM +, Kamil Rytarowski wrote:
> Modified Files:
> src/sys/netinet: sctp_asconf.h
>
> Log Message:
> Appease GCC7 in sctp_asconf.h
>
> Do not declare types inside function parameter list.
> Add decklarations of types before these function prototypes
Rin Okuyama wrote:
>Ping? Can I insert "break" here?
Sorry, yes you are correct that it should be a break.
Will commit it now.
Robert Swindells
On 2019/02/15 23:04, Robert Swindells wrote:
Rin Okuyama wrote:
Ping? Can I insert "break" here?
Sorry, yes you are correct that it should be a break.
Will commit it now.
Robert Swindells
Thanks!
rin
Ping? Can I insert "break" here?
Thanks,
rin
On 2019/02/12 23:59, Rin Okuyama wrote:
Hi,
On 2019/02/12 23:40, Robert Swindells wrote:
Module Name: src
Committed By: rjs
Date: Tue Feb 12 14:40:38 UTC 2019
Modified Files:
src/sys/netinet: sctp_input.c sctp_usrreq.c
Log Messag
Hi,
On 2019/02/12 23:40, Robert Swindells wrote:
Module Name:src
Committed By: rjs
Date: Tue Feb 12 14:40:38 UTC 2019
Modified Files:
src/sys/netinet: sctp_input.c sctp_usrreq.c
Log Message:
Add some fallthrough annotations.
...
Index: src/sys/netinet/sctp_usrreq.c
di
Le 29/04/2018 à 16:24, Christos Zoulas a écrit :
In article <20180429121242.6ca71f...@cvs.netbsd.org>,
Maxime Villard wrote:
-=-=-=-=-=-
Module Name:src
Committed By: maxv
Date: Sun Apr 29 12:12:42 UTC 2018
Modified Files:
src/sys/netinet: tcp_var.h tcpip.h
Log Messag
In article <20180429121242.6ca71f...@cvs.netbsd.org>,
Maxime Villard wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: maxv
>Date: Sun Apr 29 12:12:42 UTC 2018
>
>Modified Files:
> src/sys/netinet: tcp_var.h tcpip.h
>
>Log Message:
>Move struct tcpiphdr from tcpip.h to tcp_v
On Fri, Apr 6, 2018 at 8:02 PM Roy Marples wrote:
> On 06/04/2018 11:59, Ryota Ozaki wrote:
> > On Fri, Apr 6, 2018 at 7:45 PM, Ryota Ozaki wrote:
> >> On Fri, Apr 6, 2018 at 7:04 PM, Roy Marples wrote:
> >>> On 06/04/2018 10:19, Ryota Ozaki wrote:
>
> Module Name:src
> Commi
On 06/04/2018 11:59, Ryota Ozaki wrote:
On Fri, Apr 6, 2018 at 7:45 PM, Ryota Ozaki wrote:
On Fri, Apr 6, 2018 at 7:04 PM, Roy Marples wrote:
On 06/04/2018 10:19, Ryota Ozaki wrote:
Module Name:src
Committed By: ozaki-r
Date: Fri Apr 6 09:19:16 UTC 2018
Modified Files:
On Fri, Apr 6, 2018 at 7:45 PM, Ryota Ozaki wrote:
> On Fri, Apr 6, 2018 at 7:04 PM, Roy Marples wrote:
>> On 06/04/2018 10:19, Ryota Ozaki wrote:
>>>
>>> Module Name:src
>>> Committed By: ozaki-r
>>> Date: Fri Apr 6 09:19:16 UTC 2018
>>>
>>> Modified Files:
>>> src/sys/n
On Fri, Apr 6, 2018 at 7:04 PM, Roy Marples wrote:
> On 06/04/2018 10:19, Ryota Ozaki wrote:
>>
>> Module Name:src
>> Committed By: ozaki-r
>> Date: Fri Apr 6 09:19:16 UTC 2018
>>
>> Modified Files:
>> src/sys/netinet: in.c
>>
>> Log Message:
>> Simplify; clear then set fl
On 06/04/2018 10:19, Ryota Ozaki wrote:
Module Name:src
Committed By: ozaki-r
Date: Fri Apr 6 09:19:16 UTC 2018
Modified Files:
src/sys/netinet: in.c
Log Message:
Simplify; clear then set flags to ia4_flags (NFCI)
This change is not right.
You are clearing the flags f
Date:Sat, 31 Mar 2018 15:33:30 +0100
From:Alexander Nasonov
Message-ID: <20180331143330.GB22190@neva>
| After looking at email archives I see that many active developers
| are "guilty" of committing 'hi dev@' messages.
It used to be common. More recently it has
> Date: Sat, 31 Mar 2018 14:53:36 +0100
> From: Alexander Nasonov
>
> Taylor R Campbell wrote:
> > One connotation of `hi dev@' may be `dev@ is an idiot'; it can be
> > offputting -- and it's not really necessary to call them out publicly.
> > Sometimes dev@ has a rapport with the committer and w
Robert Elz wrote:
> I totally agree with this - and it is worse when included in commit logs
> wherte it will remain, visible, and actually viewed, forever (unlike even
> in a mailing list, which while archived forever, somewhere, usually
> falls quickly out of view.)
Searching for archived email
Taylor R Campbell wrote:
> They mean different things.
>
> `hi dev@' means `FYI, dev@, you broke this, so I'm fixing it'.
>
> `ok dev@' means `dev@ reviewed and approved this change'.
I'm well aware they mean different things.
> One connotation of `hi dev@' may be `dev@ is an idiot'; it can be
Date:Sat, 31 Mar 2018 03:07:29 +
From:Taylor R Campbell
Message-ID: <20180331030950.2325d60...@jupiter.mumble.net>
| but a passive observer can't tell the difference between
| one colleague joshing another and someone saying `you're an idiot and
| I cleaned
> Date: Thu, 29 Mar 2018 23:53:42 +0100
> From: Alexander Nasonov
>
> m...@netbsd.org wrote:
> > I seem to recall a discussion about wanting to avoid this type
> > of commit message (hi dev-name), as it can be seen as excessively
> > hostile.
>
> 'ok rmind@' would definitely be better than 'hi m
In article ,
Maxime Villard wrote:
>Le 30/03/2018 à 00:34, m...@netbsd.org a écrit :
>> On Thu, Mar 29, 2018 at 09:40:53PM +, Mindaugas Rasiukevicius wrote:
>>> Module Name:src
>>> Committed By: rmind
>>> Date: Thu Mar 29 21:40:53 UTC 2018
>>>
>>> Modified Files:
Le 30/03/2018 à 00:34, m...@netbsd.org a écrit :
On Thu, Mar 29, 2018 at 09:40:53PM +, Mindaugas Rasiukevicius wrote:
Module Name:src
Committed By: rmind
Date: Thu Mar 29 21:40:53 UTC 2018
Modified Files:
src/sys/netinet: tcp_input.c
Log Message:
tcp_urp_drop: fix a
Le 29/03/2018 à 23:40, Mindaugas Rasiukevicius a écrit :
Module Name:src
Committed By: rmind
Date: Thu Mar 29 21:40:53 UTC 2018
Modified Files:
src/sys/netinet: tcp_input.c
Log Message:
tcp_urp_drop: fix a bug introduced in 1.390 rev (hi maxv@).
To generate a diff of t
m...@netbsd.org wrote:
> I seem to recall a discussion about wanting to avoid this type
> of commit message (hi dev-name), as it can be seen as excessively
> hostile.
'ok rmind@' would definitely be better than 'hi maxv@'.
Hostile? I don't think so. I personally quite like it.
--
Alex
On Thu, Mar 29, 2018 at 09:40:53PM +, Mindaugas Rasiukevicius wrote:
> Module Name: src
> Committed By: rmind
> Date: Thu Mar 29 21:40:53 UTC 2018
>
> Modified Files:
> src/sys/netinet: tcp_input.c
>
> Log Message:
> tcp_urp_drop: fix a bug introduced in 1.390 rev (hi maxv@).
>
I've reverted the change, I'll re-investigate this later.
Maxime
Le 13/02/2018 à 18:40, Frank Kardel a écrit :
This must be revisited - IKE/racoon breaks with 1.240.
racoon listens on port 500. packets for port 500 arrive at the interface
(tcpdump sees them), but racoon NEVER receives any packe
This must be revisited - IKE/racoon breaks with 1.240.
racoon listens on port 500. packets for port 500 arrive at the interface
(tcpdump sees them), but racoon NEVER receives any packets for port 500
(debug/ktuss sees nothing).
Frank
On 02/10/18 09:17, Maxime Villard wrote:
Module Name:s
Le 10/02/2018 à 23:49, David H. Gutteridge a écrit :
On Mon, 05 Feb 2018, at 13:23:11 +, Maxime Villard wrote:
Module Name:src
Committed By: maxv
Date: Mon Feb 5 13:23:11 UTC 2018
Modified Files:
src/sys/netinet: ip_input.c
Log Message:
Disable ip_allowsrcrt and ip
On Mon, 05 Feb 2018, at 13:23:11 +, Maxime Villard wrote:
>Module Name:src
>Committed By: maxv
>Date: Mon Feb 5 13:23:11 UTC 2018
>
>Modified Files:
>src/sys/netinet: ip_input.c
>
>Log Message:
>Disable ip_allowsrcrt and ip_forwsrcrt. Enabling them by default was a
>com
On Thu, Jan 11, 2018 at 3:51 AM, Christos Zoulas wrote:
> Module Name:src
> Committed By: christos
> Date: Wed Jan 10 18:51:31 UTC 2018
>
> Modified Files:
> src/sys/netinet: ip_output.c
>
> Log Message:
> from ozaki-r: use the proper ifp.
> XXX: perhaps push the lock in in
Ryota Ozaki writes:
> Yeah, so I hoped a better fix.
For now, I'm running with yours, and it seems to have solved the
problem. If a more correct solution is in place, I'm looking forward to
testing that on my susceptible system, but it'll take a few days before
I can: I'm away from that machine
On Fri, Dec 29, 2017 at 4:37 AM, Chuck Silvers wrote:
> On Thu, Dec 28, 2017 at 05:34:27PM +0900, Ryota Ozaki wrote:
>> On Thu, Dec 28, 2017 at 5:05 PM, Tom Ivar Helbekkmo
>> wrote:
>> > Ryota Ozaki writes:
>> >
>> >> I think the below patch fixes the above issue, but probably
>> >> there is a b
On Thu, Dec 28, 2017 at 05:34:27PM +0900, Ryota Ozaki wrote:
> On Thu, Dec 28, 2017 at 5:05 PM, Tom Ivar Helbekkmo
> wrote:
> > Ryota Ozaki writes:
> >
> >> I think the below patch fixes the above issue, but probably
> >> there is a better solution.
> >
> > Looks like didn't -- it just changed it
Ryota Ozaki writes:
> Oh, my patch failed to keep SPL at IPL_VM because mutex_exit
> tries to restore an SPL where mutex_enter is called. So I had to
> put splvm before mutex_enter. Could you try the 2nd patch:
> http://www.netbsd.org/~ozaki-r/fix-pool_catchup.diff
Will do. I assume that this
On Thu, Dec 28, 2017 at 5:05 PM, Tom Ivar Helbekkmo
wrote:
> Ryota Ozaki writes:
>
>> I think the below patch fixes the above issue, but probably
>> there is a better solution.
>
> Looks like didn't -- it just changed it a little bit. Just like the
> last time, the hang happened while reading em
Ryota Ozaki writes:
> I think the below patch fixes the above issue, but probably
> there is a better solution.
Looks like didn't -- it just changed it a little bit. Just like the
last time, the hang happened while reading email over IMAP, which
exercises disk and network at the same time, whil
On Wed, Dec 27, 2017 at 7:11 PM, Tom Ivar Helbekkmo
wrote:
> Ryota Ozaki writes:
>
>> I think the below patch fixes the above issue, but probably
>> there is a better solution.
>
> Thanks! I'm now running a fully up-to-date system (from just a half
> hour ago), with this patch added. I'll push
Ryota Ozaki writes:
> I think the below patch fixes the above issue, but probably
> there is a better solution.
Thanks! I'm now running a fully up-to-date system (from just a half
hour ago), with this patch added. I'll push it hard over the next 24h,
with a mix of disk and network I/O, which s
On Tue, Dec 26, 2017 at 5:23 PM, Ryota Ozaki wrote:
> On Tue, Dec 26, 2017 at 4:50 PM, Tom Ivar Helbekkmo
> wrote:
>> Ryota Ozaki writes:
>>
>>> One possible fix has been committed.
>>>
>>> Can you update the source code and try a new kernel?
>>
>> Will do.
>
> Thanks.
>
>
>>
>> Meanwhile, befor
On Tue, Dec 26, 2017 at 4:50 PM, Tom Ivar Helbekkmo
wrote:
> Ryota Ozaki writes:
>
>> One possible fix has been committed.
>>
>> Can you update the source code and try a new kernel?
>
> Will do.
Thanks.
>
> Meanwhile, before I got around to building a kernel with debug options
> enabled, I had
Ryota Ozaki writes:
> One possible fix has been committed.
>
> Can you update the source code and try a new kernel?
Will do.
Meanwhile, before I got around to building a kernel with debug options
enabled, I had another hang. Got it into DDB successfully, but then I
managed, while looking for a
One possible fix has been committed.
Can you update the source code and try a new kernel?
Thanks,
ozaki-r
On Tue, Dec 26, 2017 at 1:00 AM, Ryota Ozaki wrote:
> On Mon, Dec 25, 2017 at 8:31 PM, Tom Ivar Helbekkmo
> wrote:
>> Martin Husemann writes:
>>
>>> The sparc64 hang happened with:
>>>
On Mon, Dec 25, 2017 at 8:31 PM, Tom Ivar Helbekkmo
wrote:
> Martin Husemann writes:
>
>> The sparc64 hang happened with:
>>
>> $NetBSD: ip_output.c,v 1.288 2017/12/22 11:22:37 ozaki-r Exp $
>
> My amd64 that experienced hangs has:
>
> $NetBSD: ip_output.c,v 1.287 2017/12/15 04:03:46
On Mon, Dec 25, 2017 at 8:16 PM, Martin Husemann wrote:
> On Mon, Dec 25, 2017 at 12:05:28PM +0900, Ryota Ozaki wrote:
>> Anyway I annoy that we often cannot have suspect commits because of cvs
>> (you know the kernel version doesn't work at all for the purpose). I wish
>> we had revision IDs of s
Martin Husemann writes:
> The sparc64 hang happened with:
>
> $NetBSD: ip_output.c,v 1.288 2017/12/22 11:22:37 ozaki-r Exp $
My amd64 that experienced hangs has:
$NetBSD: ip_output.c,v 1.287 2017/12/15 04:03:46 ozaki-r Exp $
...and was last updated from CVS on December 19th, which
On Mon, Dec 25, 2017 at 12:05:28PM +0900, Ryota Ozaki wrote:
> Anyway I annoy that we often cannot have suspect commits because of cvs
> (you know the kernel version doesn't work at all for the purpose). I wish
> we had revision IDs of svn or commit IDs of git to know them.
The sparc64 hang happen
On Mon, Dec 25, 2017 at 11:00 AM, wrote:
> Oops, I misread the code, never mind :-)
Okay :)
>
> still looking because there are some reports of hangs (kern/52858 with a
> backtrace on sparc64, current-users without one on amd64), and your
> change is the only recent change that looks like it co
Oops, I misread the code, never mind :-)
still looking because there are some reports of hangs (kern/52858 with a
backtrace on sparc64, current-users without one on amd64), and your
change is the only recent change that looks like it could affect both.
On Fri, Dec 22, 2017 at 11:22:37AM +, Ryota Ozaki wrote:
> Module Name: src
> Committed By: ozaki-r
> Date: Fri Dec 22 11:22:37 UTC 2017
>
> Modified Files:
> src/sys/netinet: ip_output.c
>
> Log Message:
> Fix usage of curlwp_bind in ip_output
> @@ -303,6 +303,10 @@ ip_outp
"Maxime Villard" writes:
> Module Name: src
> Committed By: maxv
> Date: Sat Jul 29 05:08:48 UTC 2017
>
> Modified Files:
> src/sys/netinet: tcp_subr.c
>
> Log Message:
> Forgot to commit this file yesterday.
please always use real commit messages. this message was not useful
the
Le 29/07/2017 à 01:59, Robert Elz a écrit :
Date:Fri, 28 Jul 2017 19:16:41 +
From:"Maxime Villard"
Message-ID: <20170728191641.cf10cf...@cvs.netbsd.org>
| Remove TCP_COMPAT_42. This feature is a workaround for a bug in the TCP
| stack of BSD4.2. Having
Date:Fri, 28 Jul 2017 19:16:41 +
From:"Maxime Villard"
Message-ID: <20170728191641.cf10cf...@cvs.netbsd.org>
| Remove TCP_COMPAT_42. This feature is a workaround for a bug in the TCP
| stack of BSD4.2. Having such features just does not make any sense,
These
On Fri, 28 Jul 2017, Maxime Villard wrote:
Module Name:src
Committed By: maxv
Date: Fri Jul 28 19:16:41 UTC 2017
Modified Files:
src/sys/netinet: tcp_timer.c tcp_usrreq.c tcp_var.h
Log Message:
Remove TCP_COMPAT_42. This feature is a workaround for a bug in the TCP
stac
On Tue, Jul 4, 2017 at 7:26 PM, Roy Marples wrote:
> On 04/07/2017 09:04, Ryota Ozaki wrote:
>> On Tue, Jul 4, 2017 at 1:43 AM, Roy Marples wrote:
>>> Module Name:src
>>> Committed By: roy
>>> Date: Mon Jul 3 16:43:01 UTC 2017
>>>
>>> Modified Files:
>>> src/sys/netinet:
On 04/07/2017 09:04, Ryota Ozaki wrote:
> On Tue, Jul 4, 2017 at 1:43 AM, Roy Marples wrote:
>> Module Name:src
>> Committed By: roy
>> Date: Mon Jul 3 16:43:01 UTC 2017
>>
>> Modified Files:
>> src/sys/netinet: ip_output.c
>>
>> Log Message:
>> When outputting, search for
On Tue, Jul 4, 2017 at 1:43 AM, Roy Marples wrote:
> Module Name:src
> Committed By: roy
> Date: Mon Jul 3 16:43:01 UTC 2017
>
> Modified Files:
> src/sys/netinet: ip_output.c
>
> Log Message:
> When outputting, search for the sending address on the sending interface
> rat
On Jan 16, 8:28pm, r...@marples.name (Roy Marples) wrote:
-- Subject: Re: CVS commit: src/sys/netinet
| So we should do the same for nd6log yes?
I would leave it as it is now because:
1. It is not optional
2. Sometimes takes up to 3 buffers
3. It will churn a lot of code.
christos
On Jan 16, 8:28pm, r...@marples.name (Roy Marples) wrote:
-- Subject: Re: CVS commit: src/sys/netinet
| On 16/01/2017 15:14, Christos Zoulas wrote:
| > Module Name:src
| > Committed By: christos
| > Date: Mon Jan 16 15:14:16 UTC 2017
| >
| >
On 16/01/2017 15:14, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Mon Jan 16 15:14:16 UTC 2017
Modified Files:
src/sys/netinet: if_arp.c in_var.h ip_output.c
Log Message:
rename arplog -> ARPLOG to make it clear that it is a macro and tuck-in the
b
On Jan 1, 5:44pm, brad.har...@gmail.com (bch) wrote:
-- Subject: Re: CVS commit: src/sys/netinet
| On 1/1/17, Christos Zoulas wrote:
| > Module Name:src
| > Committed By: christos
| > Date: Mon Jan 2 01:18:42 UTC 2017
| >
| > Modified Files:
| >
On 1/1/17, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Mon Jan 2 01:18:42 UTC 2017
>
> Modified Files:
> src/sys/netinet: tcp.h tcp_input.c tcp_output.c tcp_subr.c
>
> Log Message:
> Fix TCP signature code:
> 1. pack options more tightly instead of be
On Jun 2, 6:19pm, m...@eterna.com.au (matthew green) wrote:
-- Subject: re: CVS commit: src/sys/netinet
| "Christos Zoulas" writes:
| > Module Name:src
| > Committed By: christos
| > Date: Fri May 27 16:44:15 UTC 2016
| >
| > Modified Files
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Fri May 27 16:44:15 UTC 2016
>
> Modified Files:
> src/sys/netinet: in.c
>
> Log Message:
> make hostzerobroadcast default to "no".
good. it's past time.
please add a note to the install doc and CHANGE
A possible fix has been committed. If the panic still happens,
please let me know.
Thanks,
ozaki-r
On Mon, Jan 25, 2016 at 7:15 PM, Ryota Ozaki wrote:
> Module Name:src
> Committed By: ozaki-r
> Date: Mon Jan 25 10:15:39 UTC 2016
>
> Modified Files:
> src/sys/netinet: i
On Wed, Nov 11, 2015 at 7:10 PM, Roy Marples wrote:
> On 11/11/2015 07:26, Ryota Ozaki wrote:
>> On Tue, Nov 10, 2015 at 10:30 PM, Roy Marples wrote:
>>> On 10/11/2015 09:56, Ryota Ozaki wrote:
> Certainly in our arp and ndp code the assumption is made that if a
> matching route is not ma
On 11/11/2015 07:26, Ryota Ozaki wrote:
> On Tue, Nov 10, 2015 at 10:30 PM, Roy Marples wrote:
>> On 10/11/2015 09:56, Ryota Ozaki wrote:
Certainly in our arp and ndp code the assumption is made that if a
matching route is not marked RTF_CLONING then it is not a neighbour.
>>>
>>> Just c
On Tue, Nov 10, 2015 at 10:30 PM, Roy Marples wrote:
> On 10/11/2015 09:56, Ryota Ozaki wrote:
>>> Certainly in our arp and ndp code the assumption is made that if a
>>> matching route is not marked RTF_CLONING then it is not a neighbour.
>>
>> Just confirmation, do you mean s/not a neighbour/a ne
On 10/11/2015 09:56, Ryota Ozaki wrote:
>> Certainly in our arp and ndp code the assumption is made that if a
>> matching route is not marked RTF_CLONING then it is not a neighbour.
>
> Just confirmation, do you mean s/not a neighbour/a neighbour/?
I believe it's like so:
rt = find_route_for_addr
On Fri, Nov 6, 2015 at 7:01 PM, Roy Marples wrote:
> On 06/11/2015 09:24, Ryota Ozaki wrote:
>> On Fri, Nov 6, 2015 at 6:09 PM, Roy Marples wrote:
>>> On 06/11/2015 08:38, Ryota Ozaki wrote:
Module Name: src
Committed By: ozaki-r
Date: Fri Nov 6 08:38:43 UTC 2015
>>>
On 2015-11-06 20:07, matthew green wrote:
Roy Marples writes:
On 06/11/2015 08:38, Ryota Ozaki wrote:
> Module Name: src
> Committed By: ozaki-r
> Date: Fri Nov 6 08:38:43 UTC 2015
>
> Modified Files:
>src/sys/netinet: if_arp.c
>
> Log Message:
> Fix inappropriate rt
Roy Marples writes:
> On 06/11/2015 08:38, Ryota Ozaki wrote:
> > Module Name:src
> > Committed By: ozaki-r
> > Date: Fri Nov 6 08:38:43 UTC 2015
> >
> > Modified Files:
> > src/sys/netinet: if_arp.c
> >
> > Log Message:
> > Fix inappropriate rt_flags check
> >
>
On 06/11/2015 09:24, Ryota Ozaki wrote:
> On Fri, Nov 6, 2015 at 6:09 PM, Roy Marples wrote:
>> On 06/11/2015 08:38, Ryota Ozaki wrote:
>>> Module Name: src
>>> Committed By: ozaki-r
>>> Date: Fri Nov 6 08:38:43 UTC 2015
>>>
>>> Modified Files:
>>> src/sys/netinet: if_arp.c
>>>
>>>
On Fri, Nov 6, 2015 at 6:09 PM, Roy Marples wrote:
> On 06/11/2015 08:38, Ryota Ozaki wrote:
>> Module Name: src
>> Committed By: ozaki-r
>> Date: Fri Nov 6 08:38:43 UTC 2015
>>
>> Modified Files:
>> src/sys/netinet: if_arp.c
>>
>> Log Message:
>> Fix inappropriate rt_flags check
>
On 06/11/2015 08:38, Ryota Ozaki wrote:
> Module Name: src
> Committed By: ozaki-r
> Date: Fri Nov 6 08:38:43 UTC 2015
>
> Modified Files:
> src/sys/netinet: if_arp.c
>
> Log Message:
> Fix inappropriate rt_flags check
>
> It depended on either RTF_CLONED or RTF_CLONING must be s
>Module Name: src
>Committed By: christos
>Date: Wed Feb 18 17:00:16 UTC 2015
>
>Modified Files:
> src/sys/netinet: icmp_var.h ip_icmp.h
>
>Log Message:
>PR/49676: Ryo Shimizu: ICMP_STATINC() buffer overflows
>XXX: pullup-7
please pullup-6 too.
--
ryo shimizu
On Tue, Apr 15, 2014 at 02:10:33PM -0700, Erik Fair wrote:
> This should be pulled up to netbsd-6
this is not critical:
the code is used only at boot time with root on nfs, and the condition that
would cause the leak is always false anyway.
--
Manuel Bouyer
NetBSD: 26 ans d'experience fero
Erik Fair writes:
> On Apr 12, 2014, at 05:24, Greg Troxel wrote:
>
>> Module Name: src
>> Committed By:gdt
>> Date:Sat Apr 12 12:24:50 UTC 2014
>>
>> Modified Files:
>> src/sys/netinet: if_arp.c
>>
>> Log Message:
>> revarprequest: Avoid leaking mbuf.
>>
>> In r
This should be pulled up to netbsd-6
On Apr 12, 2014, at 05:24, Greg Troxel wrote:
> Module Name: src
> Committed By: gdt
> Date: Sat Apr 12 12:24:50 UTC 2014
>
> Modified Files:
> src/sys/netinet: if_arp.c
>
> Log Message:
> revarprequest: Avoid leaking mbuf.
>
> In revarprequ
In article ,
Greg Troxel wrote:
>"Christos Zoulas" writes:
>
>> Module Name: src
>> Committed By:christos
>> Date:Wed Jun 5 00:48:32 UTC 2013
>>
>> Modified Files:
>> src/sys/netinet: udp_usrreq.c
>>
>> Log Message:
>> conditionalize the net traversal code on FAST_I
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Wed Jun 5 00:48:32 UTC 2013
>
> Modified Files:
> src/sys/netinet: udp_usrreq.c
>
> Log Message:
> conditionalize the net traversal code on FAST_IPSEC to make rump build.
FAST_IPSEC does not appear in -
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Tue Mar 12 21:54:36 UTC 2013
>
> Modified Files:
> src/sys/netinet: in4_cksum.c
>
> Log Message:
> - Don't panic on short packets unless DIAGNOSTIC. In general we should try
> to make the kernel surviv
On Dec 23, 4:03pm, chacon.ja...@gmail.com (James Chacon) wrote:
-- Subject: Re: CVS commit: src/sys/netinet
| On Fri, Dec 23, 2011 at 3:36 PM, Christos Zoulas wrot=
| e:
| > On Dec 23, =A03:10pm, chacon.ja...@gmail.com (James Chacon) wrote:
| > -- Subject: Re: CVS commit: src/sys/n
1 - 100 of 133 matches
Mail list logo
