On Sat, 25 Jul 2020 18:27:45 +0100
Laurence Tratt wrote:
> On Sat, Jul 25, 2020 at 10:27:15AM -0600, Theo de Raadt wrote:
>
> Hello Theo,
>
> > My primary concern is about a user changing settings which then
> > persist past close.
> >
> > Upon re-open, how do they know what mode they are in?
>
ok.
> On 29 Jul 2020, at 11:38, Klemens Nanni wrote:
>
> On Tue, Jul 28, 2020 at 07:09:17PM +0200, Klemens Nanni wrote:
>> bridge_status() and switch_status() do the regular sanity check with
>> SIOCGIFFLAGS, but both functions also call is_switch(), bridge_status()
>> also calls is_bridge().
>>
On Tue, Jul 28, 2020 at 07:09:17PM +0200, Klemens Nanni wrote:
> bridge_status() and switch_status() do the regular sanity check with
> SIOCGIFFLAGS, but both functions also call is_switch(), bridge_status()
> also calls is_bridge().
>
> Those is_*() helpers do the same SIOCGIFFLAGS sanity check,
Someone (can't recall who) gave me an ER4. I found it while cleaning
out my closet. Since I'm not active anymore, if any openbsd developer
wants it, reach out to me privately and I'll see about sending it
to you.
Thanks.
-ml
On Tue, Jul 28, 2020 at 07:30:36PM +0200, Mark Kettenis wrote:
> > Date: Tue, 28 Jul 2020 21:42:46 +1000
> > From: Jonathan Matthew
> >
> > On Tue, Jul 28, 2020 at 11:12:21AM +0200, Mark Kettenis wrote:
> > > > Date: Tue, 28 Jul 2020 13:46:34 +1000
> > > > From: Jonathan Matthew
> > > >
> > > >
> On 29 Jul 2020, at 00:09, sven falempin wrote:
>
> On Tue, Jul 28, 2020 at 4:42 PM Vitaliy Makkoveev wrote:
>>
>> On Tue, Jul 28, 2020 at 04:10:01PM -0400, sven falempin wrote:
>>> Hello,
>>>
>>> I am running some trunk interfaces in a multi core environment,
>>> it's a slightly modified
On Tue, Jul 28, 2020 at 4:42 PM Vitaliy Makkoveev wrote:
>
> On Tue, Jul 28, 2020 at 04:10:01PM -0400, sven falempin wrote:
> > Hello,
> >
> > I am running some trunk interfaces in a multi core environment,
> > it's a slightly modified version, i have a few NET_ASSERT_LOCKED();
> > suspecting some
On Tue, Jul 28, 2020 at 04:10:01PM -0400, sven falempin wrote:
> Hello,
>
> I am running some trunk interfaces in a multi core environment,
> it's a slightly modified version, i have a few NET_ASSERT_LOCKED();
> suspecting some multi core shenanigans, which i guess was confirmed:
> (unsure the hav
Hello,
I am running some trunk interfaces in a multi core environment,
it's a slightly modified version, i have a few NET_ASSERT_LOCKED();
suspecting some multi core shenanigans, which i guess was confirmed:
(unsure the have X meaning, but i ' m pretty sure 256 is very wrong)
the if_trunk.c lockin
Hello Yasuoka,
On Wed, Jul 29, 2020 at 01:55:20AM +0900, YASUOKA Masahiko wrote:
> Hi,
>
> Let me add another fix of previous.
>
> ok?
OK. thanks for taking care of that. I've entirely missed 1 vs. -1 return
value, when reviewing your change.
regards
sashan
On Tue, Jul 28, 2020 at 01:44:33PM -0400, Johan Huldtgren wrote:
> hello,
>
> On 2020-07-28 11:12, Mark Kettenis wrote:
> > > Date: Tue, 28 Jul 2020 13:46:34 +1000
> > > From: Jonathan Matthew
> > >
> > > On Mon, Jul 27, 2020 at 05:16:47PM +0200, Mark Kettenis wrote:
> > > > > Date: Mon, 27 Jul
hello,
On 2020-07-28 11:12, Mark Kettenis wrote:
> > Date: Tue, 28 Jul 2020 13:46:34 +1000
> > From: Jonathan Matthew
> >
> > On Mon, Jul 27, 2020 at 05:16:47PM +0200, Mark Kettenis wrote:
> > > > Date: Mon, 27 Jul 2020 17:02:41 +0200 (CEST)
> > > > From: Mark Kettenis
> > > >
> > > > Recent A
> Date: Tue, 28 Jul 2020 21:42:46 +1000
> From: Jonathan Matthew
>
> On Tue, Jul 28, 2020 at 11:12:21AM +0200, Mark Kettenis wrote:
> > > Date: Tue, 28 Jul 2020 13:46:34 +1000
> > > From: Jonathan Matthew
> > >
> > > On Mon, Jul 27, 2020 at 05:16:47PM +0200, Mark Kettenis wrote:
> > > > > Date:
bridge_status() and switch_status() do the regular sanity check with
SIOCGIFFLAGS, but both functions also call is_switch(), bridge_status()
also calls is_bridge().
Those is_*() helpers do the same SIOCGIFFLAGS sanity check, making those
in *_status() entirely redundant, so I'd like to remove them
Hi,
On Tue, 28 Jul 2020 18:54:48 +0200
Alexandr Nedvedicky wrote:
> On Wed, Jul 29, 2020 at 01:22:48AM +0900, YASUOKA Masahiko wrote:
>> Previous commit has a wrong part..
>>
>> ok?
>>
>> Fix previous commit which referred wrong address.
>
> would it make sense to move the block, you've in
Hello Yasuoka,
On Wed, Jul 29, 2020 at 01:22:48AM +0900, YASUOKA Masahiko wrote:
> Hi,
>
> Previous commit has a wrong part..
>
> ok?
>
> Fix previous commit which referred wrong address.
would it make sense to move the block, you've introduced earler
under the !PF_AZERO() branch just
Hi,
Let me add another fix of previous.
ok?
Fix previous commit which referred wrong address and returned wrong
value.
Index: sys/net/pf_lb.c
===
RCS file: /cvs/src/sys/net/pf_lb.c,v
retrieving revision 1.66
diff -u -p -r1.66 pf_lb
Hi,
Previous commit has a wrong part..
ok?
Fix previous commit which referred wrong address.
Index: sys/net/pf_lb.c
===
RCS file: /cvs/src/sys/net/pf_lb.c,v
retrieving revision 1.65
diff -u -p -r1.65 pf_lb.c
--- sys/net/pf_lb.c
On Tue, Jul 28, 2020 at 01:09:51PM +0200, Mark Kettenis wrote:
> > Date: Tue, 28 Jul 2020 11:16:56 +0100
> > From: Jason McIntyre
> >
> > On Tue, Jul 28, 2020 at 11:12:21AM +0200, Mark Kettenis wrote:
> > > > Date: Tue, 28 Jul 2020 13:46:34 +1000
> > > > From: Jonathan Matthew
> > > >
> > > > O
On Tue, Jul 28, 2020 at 11:12:21AM +0200, Mark Kettenis wrote:
> > Date: Tue, 28 Jul 2020 13:46:34 +1000
> > From: Jonathan Matthew
> >
> > On Mon, Jul 27, 2020 at 05:16:47PM +0200, Mark Kettenis wrote:
> > > > Date: Mon, 27 Jul 2020 17:02:41 +0200 (CEST)
> > > > From: Mark Kettenis
> > > >
> >
> Date: Tue, 28 Jul 2020 11:16:56 +0100
> From: Jason McIntyre
>
> On Tue, Jul 28, 2020 at 11:12:21AM +0200, Mark Kettenis wrote:
> > > Date: Tue, 28 Jul 2020 13:46:34 +1000
> > > From: Jonathan Matthew
> > >
> > > On Mon, Jul 27, 2020 at 05:16:47PM +0200, Mark Kettenis wrote:
> > > > > Date: M
On Tue, 28 Jul 2020 11:42:43 +0200
Martin Pieuchot wrote:
> On 26/07/20(Sun) 16:23, Marcus Glocker wrote:
> > On Sun, 26 Jul 2020 13:27:34 +
> > sc.dy...@gmail.com wrote:
> >
> > > On 2020/07/26 10:54, Marcus Glocker wrote:
> > > > On Sat, 25 Jul 2020 20:31:44 +
> > > > sc.dy...@gmai
On Tue, Jul 28, 2020 at 11:12:21AM +0200, Mark Kettenis wrote:
> > Date: Tue, 28 Jul 2020 13:46:34 +1000
> > From: Jonathan Matthew
> >
> > On Mon, Jul 27, 2020 at 05:16:47PM +0200, Mark Kettenis wrote:
> > > > Date: Mon, 27 Jul 2020 17:02:41 +0200 (CEST)
> > > > From: Mark Kettenis
> > > >
> >
On Tue, Jul 28, 2020 at 10:26:53AM +0200, Martin Pieuchot wrote:
> On 17/07/20(Fri) 17:04, Vitaliy Makkoveev wrote:
> > Subj. Also add NET_ASSERT_LOCKED() to pipex_{link,unlink,rele}_session()
> > to be sure they called under NET_LOCK().
>
> pipex_rele_session() is freeing memory. When this funct
On 26/07/20(Sun) 16:23, Marcus Glocker wrote:
> On Sun, 26 Jul 2020 13:27:34 +
> sc.dy...@gmail.com wrote:
>
> > On 2020/07/26 10:54, Marcus Glocker wrote:
> > > On Sat, 25 Jul 2020 20:31:44 +
> > > sc.dy...@gmail.com wrote:
> > >
> > >> On 2020/07/25 18:10, Marcus Glocker wrote:
> >
On Tue, Jul 28, 2020 at 10:23:08AM +0200, Martin Pieuchot wrote:
> On 17/07/20(Fri) 16:29, Vitaliy Makkoveev wrote:
> > We are going to lock the whole pipex(4) by NET_LOCK(). So move
> > `multicast_session' freeing undet NET_LOCK() too.
>
> pipex_iface_fini() should be called on the last reference
> Date: Tue, 28 Jul 2020 13:46:34 +1000
> From: Jonathan Matthew
>
> On Mon, Jul 27, 2020 at 05:16:47PM +0200, Mark Kettenis wrote:
> > > Date: Mon, 27 Jul 2020 17:02:41 +0200 (CEST)
> > > From: Mark Kettenis
> > >
> > > Recent ACPI versions have deprecated "Processor()" nodes in favout of
> >
On 17/07/20(Fri) 18:15, Stefan Sperling wrote:
> On Fri, Jul 17, 2020 at 03:59:38PM +0200, Stefan Sperling wrote:
> > While measuring Tx performance at a fixed Tx rate with iwm(4) I observed
> > unexpected dips in throughput measured by tcpbench. These dips coincided
> > with one or more gap timeou
On 17/07/20(Fri) 17:04, Vitaliy Makkoveev wrote:
> Subj. Also add NET_ASSERT_LOCKED() to pipex_{link,unlink,rele}_session()
> to be sure they called under NET_LOCK().
pipex_rele_session() is freeing memory. When this function is called
those chunks of memory shouldn't be referenced by any other C
On 17/07/20(Fri) 16:29, Vitaliy Makkoveev wrote:
> We are going to lock the whole pipex(4) by NET_LOCK(). So move
> `multicast_session' freeing undet NET_LOCK() too.
pipex_iface_fini() should be called on the last reference of the
descriptor. So this shouldn't be necessary. If there's an issue
w
On 2020-07-27 18:24, Mark Kettenis wrote:
Date: Mon, 27 Jul 2020 17:14:21 +0200
From: Christian Weisgerber
Scott Cheloha:
--- lib/libc/arch/amd64/gen/usertc.c8 Jul 2020 09:17:48 - 1.2
+++ lib/libc/arch/amd64/gen/usertc.c25 Jul 2020 17:50:38 -
@@ -21,9 +21,12 @@
static
31 matches
Mail list logo