My error from 1998. Your diff is correct.
Paul Janzen.
On Wed, 28 Apr 2021, trondd wrote:
> Looks like we picked up some extra loopty loops during an update from
> NetBSD back in 1998.
>
> I sanity checked against NetBSD to make sure this matches their
> source.
>
> Tim.
>
>
> Index: io.c
Slightly more consistent.
Index: date.1
===
RCS file: /cvs/src/bin/date/date.1,v
retrieving revision 1.71
diff -u -p -u -r1.71 date.1
--- date.1 8 Aug 2019 02:17:51 - 1.71
+++ date.1 29 Apr 2021 00:19:36 -
@@
Looks like we picked up some extra loopty loops during an update from
NetBSD back in 1998.
I sanity checked against NetBSD to make sure this matches their
source.
Tim.
Index: io.c
===
RCS file: /cvs/src/games/phantasia/io.c,v
What I saw is a Ubiquity router v6 session misconfigured to ask for v4
routes. The current logic decides the MP is inconsistant, and thus AFI.
If no AFI, then provide v4... anyways, that cannot be right.
It was worse because the v4 received routes on the famously high quality
Ubiquity were acted
> On 29 Apr 2021, at 02:48, Alexandr Nedvedicky
> wrote:
>
> On Thu, Apr 29, 2021 at 02:30:48AM +0300, Vitaliy Makkoveev wrote:
>>
>>
>>> On 29 Apr 2021, at 02:20, Alexandr Nedvedicky
>>> wrote:
>>>
>>>
This time arpcache() is only called by netisr() with both kernel and
On Thu, Apr 29, 2021 at 02:30:48AM +0300, Vitaliy Makkoveev wrote:
>
>
> > On 29 Apr 2021, at 02:20, Alexandr Nedvedicky
> > wrote:
> >
> >
> >>
> >> This time arpcache() is only called by netisr() with both kernel and
> >> exclusive net locks held. RTM_DELETE message processing will also
> On 29 Apr 2021, at 02:20, Alexandr Nedvedicky
> wrote:
>
>
>>
>> This time arpcache() is only called by netisr() with both kernel and
>> exclusive net locks held. RTM_DELETE message processing will also call
>> ifp->if_rtrequest() with exclusive netlock held.
>>
>> So this while() loop
>
> This time arpcache() is only called by netisr() with both kernel and
> exclusive net locks held. RTM_DELETE message processing will also call
> ifp->if_rtrequest() with exclusive netlock held.
>
> So this while() loop within arpcache() can’t be broken by “arp -a -d”.
completely agree.
> On 29 Apr 2021, at 01:38, Alexandr Nedvedicky
> wrote:
>
> Hello,
>
>
>> Such a diff is below. I will test extensively towmorrow. If anyone
>> wants to try now, be my guest.
>>
>> Is the comment correct?
>
>I think comment is not quite right.
>
>
>
> the packet gets inserted
Hello,
> Such a diff is below. I will test extensively towmorrow. If anyone
> wants to try now, be my guest.
>
> Is the comment correct?
I think comment is not quite right.
the packet gets inserted into la->la_mq via arpresolve(), which
is not protected by KERNEL_LOCK().
arpresolve()
On Wed, Apr 28, 2021 at 03:31:41PM +0200, Claudio Jeker wrote:
> On Wed, Apr 28, 2021 at 02:56:27PM +0200, Alexandr Nedvedicky wrote:
> > I would say the la->la_mq queue should be empty once we dispatch all
> > packets to wire. If it is not empty, then something went wrong and
> > packets
> On 28 Apr 2021, at 23:40, Alexander Bluhm wrote:
>
> On Wed, Apr 28, 2021 at 11:13:05PM +0300, Vitaliy Makkoveev wrote:
>> Also we have two cases where `la_mq??? is not empty:
>> 1. This thread put it back while performed ifp->if_output
>> 2. Concurrent thread put it???s own packet because
On Wed, Apr 28, 2021 at 11:13:05PM +0300, Vitaliy Makkoveev wrote:
> Also we have two cases where `la_mq??? is not empty:
> 1. This thread put it back while performed ifp->if_output
> 2. Concurrent thread put it???s own packet because ARP resolution failed.
>
> So I doubt ???XXXSMP??? and
> On 28 Apr 2021, at 22:40, Alexander Bluhm wrote:
>
> On Wed, Apr 28, 2021 at 04:01:42PM +0200, Alexandr Nedvedicky wrote:
>> On Wed, Apr 28, 2021 at 03:31:41PM +0200, Claudio Jeker wrote:
>>> Another option is to assert on the condition. It is an error case
>>> that should not exist.
>>>
Hello,
diff looks good to me, I've just found one cosmetic nit.
> @@ -683,21 +685,17 @@ arpcache(struct ifnet *ifp, struct ether
>
> la->la_asked = 0;
> la->la_refreshed = 0;
> - while ((m = mq_dequeue(>la_mq)) != NULL) {
> - unsigned int len;
> -
> -
On Wed, Apr 28, 2021 at 04:01:42PM +0200, Alexandr Nedvedicky wrote:
> On Wed, Apr 28, 2021 at 03:31:41PM +0200, Claudio Jeker wrote:
> > Another option is to assert on the condition. It is an error case
> > that should not exist.
> >
>
> I think assert won't hurt here as it will enable us
Dave Voutila writes:
> Claudio Jeker writes:
>
>> On Wed, Apr 28, 2021 at 09:55:16AM -0400, Dave Voutila wrote:
>>>
>>> Claudio Jeker writes:
>>>
>>> > On Wed, Apr 28, 2021 at 08:18:47AM -0400, Dave Voutila wrote:
>>> >>
>>> >> Claudio Jeker writes:
>>> >>
>>> >> > Another thing to consider is
Claudio Jeker writes:
> On Wed, Apr 28, 2021 at 09:55:16AM -0400, Dave Voutila wrote:
>>
>> Claudio Jeker writes:
>>
>> > On Wed, Apr 28, 2021 at 08:18:47AM -0400, Dave Voutila wrote:
>> >>
>> >> Claudio Jeker writes:
>> >>
>> >> > Another thing to consider is that X-Forwarded headers should
On Wed, Apr 28, 2021 at 09:55:16AM -0400, Dave Voutila wrote:
>
> Claudio Jeker writes:
>
> > On Wed, Apr 28, 2021 at 08:18:47AM -0400, Dave Voutila wrote:
> >>
> >> Claudio Jeker writes:
> >>
> >> > Another thing to consider is that X-Forwarded headers should only be
> >> > accepted from
On Wed, Apr 28, 2021 at 03:31:41PM +0200, Claudio Jeker wrote:
> On Wed, Apr 28, 2021 at 02:56:27PM +0200, Alexandr Nedvedicky wrote:
> > Hello,
> >
> > On Wed, Apr 28, 2021 at 02:25:26AM +0200, Alexander Bluhm wrote:
> > > On Wed, Apr 28, 2021 at 03:19:47AM +0300, Vitaliy Makkoveev wrote:
> > >
Claudio Jeker writes:
> On Wed, Apr 28, 2021 at 08:18:47AM -0400, Dave Voutila wrote:
>>
>> Claudio Jeker writes:
>>
>> > Another thing to consider is that X-Forwarded headers should only be
>> > accepted from trusted sources. I don't think this particular usage of
>> > X-Forwarded-Proto is
On Wed, Apr 28, 2021 at 02:56:27PM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> On Wed, Apr 28, 2021 at 02:25:26AM +0200, Alexander Bluhm wrote:
> > On Wed, Apr 28, 2021 at 03:19:47AM +0300, Vitaliy Makkoveev wrote:
> > > The code not only breaks loop but also cleans the queue. Should this be
>
On Wed, Apr 28, 2021 at 08:18:47AM -0400, Dave Voutila wrote:
>
> Claudio Jeker writes:
>
> > Another thing to consider is that X-Forwarded headers should only be
> > accepted from trusted sources. I don't think this particular usage of
> > X-Forwarded-Proto is probelmatic. In the end for this
Hello,
On Wed, Apr 28, 2021 at 02:25:26AM +0200, Alexander Bluhm wrote:
> On Wed, Apr 28, 2021 at 03:19:47AM +0300, Vitaliy Makkoveev wrote:
> > The code not only breaks loop but also cleans the queue. Should this be
> > kept?
>
this is a good point
> In IPv6 nd6_cache_lladdr() we have
On Wed, Apr 21, 2021 at 11:21:51AM +0200, Eric Faurot wrote:
> There is actually no reason to defer calls to tls_accept_socket() and
> tls_connect_socket() in an event callback. The code can be simplified
> by a great deal. It also eliminates the issue of keeping a reference
> to the listener
On Wed, Apr 28, 2021 at 12:06:26PM +0200, Alexander Bluhm wrote:
> On Tue, Apr 27, 2021 at 08:22:20PM -0700, Greg Steuck wrote:
> > Vitaliy Makkoveev writes:
> >
> > > On Tue, Apr 27, 2021 at 09:12:56PM +0200, Alexander Bluhm wrote:
> > >> On Tue, Apr 27, 2021 at 12:18:02PM -0600, Theo de Raadt
Claudio Jeker writes:
> Another thing to consider is that X-Forwarded headers should only be
> accepted from trusted sources. I don't think this particular usage of
> X-Forwarded-Proto is probelmatic. In the end for this particular case of
> redirect using a relative URL seems to be a better
At the moment bgpd will fall back to IPv4 unicast if there was no match in
the multiprotocol capabilities between local and remote peer.
This is not correct, if the router expects a certain AFI/SAFI for the
session then it should not fall back to IPv4 unicast.
An example is when bgpd uses IPv6
On Tue, Apr 27, 2021 at 08:22:20PM -0700, Greg Steuck wrote:
> Vitaliy Makkoveev writes:
>
> > On Tue, Apr 27, 2021 at 09:12:56PM +0200, Alexander Bluhm wrote:
> >> On Tue, Apr 27, 2021 at 12:18:02PM -0600, Theo de Raadt wrote:
> >> > Actually, your variation seems pretty good. Is there any
On Tue, Apr 27, 2021 at 04:34:18PM -0400, Dave Voutila wrote:
>
> Stuart Henderson writes:
>
> > On 2021/04/27 10:40, Vincent Lee wrote:
> >>
> >> Hi all,
> >>
> >> Consider the following situation. A reverse proxy which performs TLS
> >> termination is deployed in front of httpd, which listens
On Wed, Apr 28, 2021 at 01:11:07AM +0200, Alexander Bluhm wrote:
> On Mon, Apr 26, 2021 at 05:13:55PM +0200, Sebastien Marie wrote:
> > > I can't vouch that it builds for all architectures... Did anyone do
> > > that? Number 1 rule: don't break Theo's build.
> >
> > One test would be to build on
On Tue, Apr 27, 2021 at 06:42:07PM -0400, Ashton Fagg wrote:
> Hi all,
>
> Attached is a diff which update iscsictl.8 to reflect the recent change in
> behavior of
> iscsictl's reload command.
>
> Thanks,
>
> Ash
>
> diff --git a/usr.sbin/iscsictl/iscsictl.8 b/usr.sbin/iscsictl/iscsictl.8
>
On Sun, Apr 25, 2021 at 06:41:09PM +0200, Mark Kettenis wrote:
> > Date: Sun, 25 Apr 2021 17:53:31 +0200
> > From: Otto Moerbeek
> >
> > Hi,
> >
> > A local test and jca@ confirm the special casing isn't needed anymore.
> >
> > Two things:
> >
> > - This could do with a ports bulk build to
On Wed, Apr 28, 2021 at 11:23:17AM +0200, Mark Kettenis wrote:
> I'm not srprised I got this wrong. The refcounting rules were unclear
> to me. I trust that you have a better idea how this is supposed to
> work than I.
I got confused. See my other response just now. The existing code is fine.
On Wed, Apr 28, 2021 at 11:11:29AM +0200, Stefan Sperling wrote:
> The commit which introduced hostap power management support in athn(4)
> had a node refcounting bug. When buffered management or multicast frames
> are sent from ic_bss's ni_savedq the Tx node's reference count isn't bumped.
> This
> Date: Wed, 28 Apr 2021 11:11:29 +0200
> From: Stefan Sperling
>
> The commit which introduced hostap power management support in athn(4)
> had a node refcounting bug. When buffered management or multicast frames
> are sent from ic_bss's ni_savedq the Tx node's reference count isn't bumped.
>
This patch reverts the following CVS commit:
ieee80211_proto.c revision 1.97
date: 2020/05/29 07:34:19; author: stsp; state: Exp; lines: +7 -1;
commitid: 8vKZsdvvkjTr5BG5;
This change was wrong because it was made under the assumption that
frames queued on the power-saving queue were already
The commit which introduced hostap power management support in athn(4)
had a node refcounting bug. When buffered management or multicast frames
are sent from ic_bss's ni_savedq the Tx node's reference count isn't bumped.
This means the reference count of ic_bss could become negative when the
Tx
There are various time fields in the JSON output.
last_read, last_write, last_updown on sessions, last_update for rib
entries and last_change for sets. Currently the value is the fmt_timeframe
string (which looks something like 7w3d12h) and is hard to parse for
machines. Include an additional _sec
On Sun, Apr 25, 2021 at 08:31:07PM +0200, Theo Buehler wrote:
> On Sun, Apr 25, 2021 at 05:53:31PM +0200, Otto Moerbeek wrote:
> > Hi,
> >
> > A local test and jca@ confirm the special casing isn't needed anymore.
> >
> > Two things:
> >
> > - This could do with a ports bulk build to find other
40 matches
Mail list logo
