Hello,
On Tue, Mar 15, 2022 at 12:58:48AM +0300, Vitaliy Makkoveev wrote:
> >
> >I think local var `ipa` needs to be initialized to NULL
> >to avoid random value/pointer when no `ipa` for given `seq`
> >is found.
> >
> >ipsp_pending_acquire() plays the same gamble.
>
> #define
> On 15 Mar 2022, at 00:45, Alexandr Nedvedicky
> wrote:
>
> Hello,
>
> On Tue, Mar 15, 2022 at 12:37:00AM +0300, Vitaliy Makkoveev wrote:
>> Hi,
>>
>> Why do you want to initialize `ipa’ variable in
>> ipsp_pending_acquire() and ipsec_get_acquire()? This doesn’t
>> require.
>
>after
Hello,
On Tue, Mar 15, 2022 at 12:37:00AM +0300, Vitaliy Makkoveev wrote:
> Hi,
>
> Why do you want to initialize `ipa’ variable in
> ipsp_pending_acquire() and ipsec_get_acquire()? This doesn’t
> require.
after looking at code with bluhm's diff applied I see this:
936 struct
Hi,
Why do you want to initialize `ipa’ variable in
ipsp_pending_acquire() and ipsec_get_acquire()? This doesn’t
require.
> On 14 Mar 2022, at 13:09, Alexandr Nedvedicky
> wrote:
>
> Hello,
>
>
>
> changes looks good. just few nits.
>
>I took a closer look at ipsec_delete_policy():
>
It is currently impossible to use more than one iwm or iwx interface
in a system because I don't understand C.
Trying to bring up an uninitialized interface anyway results in a
kernel panic ("bogus channel pointer" from net80211), so prevent
the device from being used in case we never managed to
Tests, OKs?
diff --git usr.sbin/nsd/Makefile.in usr.sbin/nsd/Makefile.in
index 8aa40269f2a..e28fc47cd32 100644
--- usr.sbin/nsd/Makefile.in
+++ usr.sbin/nsd/Makefile.in
@@ -586,7 +586,7 @@ cutest_udb.o: $(srcdir)/tpkg/cutest/cutest_udb.c config.h
$(srcdir)/tpkg/cutest/
cutest_udbrad.o:
On Mon, Mar 14, 2022 at 02:01:07AM -0700, Philip Guenther wrote:
> On Mon, Mar 14, 2022 at 12:47 AM Visa Hankala wrote:
>
> > On Sun, Mar 13, 2022 at 06:26:19PM -0700, Philip Guenther wrote:
> > > On Sun, Mar 13, 2022 at 10:27 AM Visa Hankala wrote:
> > >
> > > > On Sun, Mar 13, 2022 at
On Mon, Mar 14, 2022 at 10:38:46AM +0100, Remi Locherer wrote:
> This is how OpenBSD responds with pf disabled:
> 192.168.201.21.20 > 192.168.201.29.22: SF 0:0(0) win 8192
> 192.168.201.29.22 > 192.168.201.21.20: S 2641340782:2641340782(0) ack 1 win
> 16384 (DF)
>
> So pf behaves kind of
Hello,
On Fri, Mar 11, 2022 at 09:40:00PM +0100, Alexander Bluhm wrote:
> Regress tested with witness, rebased to current, anyone?
>
> On Wed, Mar 02, 2022 at 07:13:09PM +0100, Alexander Bluhm wrote:
> > Hi,
> >
> > pf_socket_lookup() calls in_pcbhashlookup() in the PCB layer. So
> > to run pf
Hello,
changes looks good. just few nits.
I took a closer look at ipsec_delete_policy():
667 ipsec_delete_policy(struct ipsec_policy *ipo)
668 {
669 struct ipsec_acquire *ipa;
670 struct radix_node_head *rnh;
671
On Mon, Mar 14, 2022 at 01:27:14AM +0100, Alexander Bluhm wrote:
> On Sun, Mar 13, 2022 at 11:24:33PM +0100, Remi Locherer wrote:
> > Hi,
> >
> > When pf processes a TCP packet with SYN and FIN flags set, it removes
> > the FIN flag and continuous processing it. I propose we change that and
> >
On Mon, Mar 14, 2022 at 12:47 AM Visa Hankala wrote:
> On Sun, Mar 13, 2022 at 06:26:19PM -0700, Philip Guenther wrote:
> > On Sun, Mar 13, 2022 at 10:27 AM Visa Hankala wrote:
> >
> > > On Sun, Mar 13, 2022 at 04:29:44PM +0100, Mark Kettenis wrote:
> > >
> > ...
> >
> > > > Under what
On Sun, Mar 13, 2022 at 06:26:19PM -0700, Philip Guenther wrote:
> On Sun, Mar 13, 2022 at 10:27 AM Visa Hankala wrote:
>
> > On Sun, Mar 13, 2022 at 04:29:44PM +0100, Mark Kettenis wrote:
> >
> ...
>
> > > Under what circumstances does memory ordering matter for these
> > > interfaces?
> >
> >
On 9.3.2022. 19:14, Alexander Bluhm wrote:
> Hi,
>
> Hrvoje has hit a crash with IPsec acquire while testing the parallel
> ip forwarding diff. Analysis with sashan@ concludes that this part
> is not MP safe. Mutex and refcount should fix the memory management.
>
> Hrvoje: Could you test this
14 matches
Mail list logo
