On Tue, Dec 08, 2020 at 12:11:07AM -0500, Kurt Mosiejczuk wrote:
> > With this patch we only echo the RSN capalibities which we actually support.
> > I am handling MFP and PBAR bits here as done elsewhere, but note that
> > neither of these features is enabled yet at run-time.
> > (We do have code
On Mon, Dec 07, 2020 at 10:55:29PM +0100, Stefan Sperling wrote:
> When announcing RSN (WPA2) capabilities in management frames such as
> association requests, we currently echo back all RSN (i.e. WPA2)
> capabilities which were announced by our peer.
> This is bad in case the peer announces featu
On Wed, Dec 02, 2020 at 11:43:32PM +0100, Mark Kettenis wrote:
> > From: "Constantine A. Murenin"
> > Date: Wed, 2 Dec 2020 14:04:52 -0800
> >
> > Not sure if you've seen it, but ipmi(4) has been disabled for over 12
> > years, because it's broken on some machines, so, this code is not
> > necess
> 2020/12/07 16:47、Claudio Jeker のメール:
>
> On Mon, Dec 07, 2020 at 01:00:05PM +0900, Yuichiro NAITO wrote:
>> Hi.
>>
>> I have set up OpenBSD as a IPsec gateway and tried to forward IPv6 packets.
>> But IPv6 packets are not forwarded via IPsec tunnel.
>> IPv4 forwarding via IPsec works for me.
Looks good, no regression for my AP at home.
OK
On 2020 Dec 07 (Mon) at 22:55:29 +0100 (+0100), Stefan Sperling wrote:
:When announcing RSN (WPA2) capabilities in management frames such as
:association requests, we currently echo back all RSN (i.e. WPA2)
:capabilities which were announced by our
On Mon, Dec 07, 2020 at 09:55:06PM +, Job Snijders wrote:
> On Mon, Dec 07, 2020 at 10:03:57PM +0100, Claudio Jeker wrote:
> > So ghostbuster records (rfc6493) are showing up in RPKI datasets and
> > instead of silently ignoring them rpki-client should first of all validate
> > the file hash in
When announcing RSN (WPA2) capabilities in management frames such as
association requests, we currently echo back all RSN (i.e. WPA2)
capabilities which were announced by our peer.
This is bad in case the peer announces features we don't support.
One such feature is Management Frame Protection (MF
On Mon, Dec 07, 2020 at 10:03:57PM +0100, Claudio Jeker wrote:
> So ghostbuster records (rfc6493) are showing up in RPKI datasets and
> instead of silently ignoring them rpki-client should first of all validate
> the file hash in the manifest and later on also validate the CMS data.
>
> This first
On Mon, Dec 07, 2020 at 10:18:04PM +0100, Alexandr Nedvedicky wrote:
> On Mon, Dec 07, 2020 at 12:22:22PM -0800, Philip Guenther wrote:
> > On Mon, Dec 7, 2020 at 11:16 AM Alexandr Nedvedicky <
> > alexandr.nedvedi...@oracle.com> wrote:
> >
> > > What's the plan for rw_write_held()? Currently macr
On Mon, Dec 07, 2020 at 12:22:22PM -0800, Philip Guenther wrote:
> On Mon, Dec 7, 2020 at 11:16 AM Alexandr Nedvedicky <
> alexandr.nedvedi...@oracle.com> wrote:
>
> > What's the plan for rw_write_held()? Currently macro is true, if whoever
> > holds
> > the lock.
> >
> > >
> > > +#define rw_
So ghostbuster records (rfc6493) are showing up in RPKI datasets and
instead of silently ignoring them rpki-client should first of all validate
the file hash in the manifest and later on also validate the CMS data.
This first diff does ensure that all files in an mft are present and have
a valid h
On Mon, Dec 7, 2020 at 11:16 AM Alexandr Nedvedicky <
alexandr.nedvedi...@oracle.com> wrote:
> What's the plan for rw_write_held()? Currently macro is true, if whoever
> holds
> the lock.
>
> >
> > +#define rw_write_held(rwl) (rw_status(rwl) == RW_WRITE)
>
Nope. rw_status() returns RW_
Hello,
What's the plan for rw_write_held()? Currently macro is true, if whoever holds
the lock.
>
> +#define rw_write_held(rwl) (rw_status(rwl) == RW_WRITE)
I would expect something like instead:
#define rw_write_held(rwl) (RWLOCK_OWNER(rwl) == curproc)
Diff below rewrites uvm_fault() using a loop.
I added a KERNEL_LOCK/UNLOCK() dance around the part that won't be
unlocked soon to illustrate where this is going.
ok?
Index: uvm/uvm_fault.c
===
RCS file: /cvs/src/sys/uvm/uvm_fault.c,
That's all fine, until someone uses this not for KASSERT, but as part of
their logic.
while(!rw_read_held(lock)) {
do something;
}
I think this kind of thing fleads to people building "try" APIs.
Martin Pieuchot wrote:
> Simple diff below to add the rw_lock_held
On 2020 Dec 07 (Mon) at 16:41:33 +0100 (+0100), Stefan Sperling wrote:
:On Mon, Dec 07, 2020 at 03:49:20PM +0100, Tobias Heider wrote:
:> On Mon, Dec 07, 2020 at 02:33:10PM +0100, Stefan Sperling wrote:
:> > On Mon, Dec 07, 2020 at 01:31:09PM +0100, Tobias Heider wrote:
:> > > Some APs request a BA
Simple diff below to add the rw_lock_held() as well as a read & write
version.
This allows us to reduce the difference with NetBSD in UVM by adding the
following checks:
KASSERT(rw_write_held(amap->am_lock));
ok?
Index: sys/rwlock.h
==
OK
On 2020 Dec 07 (Mon) at 10:28:59 +0100 (+0100), Tobias Heider wrote:
:Hi,
:
:In iwm_rx_pkt() the calculation of "remain" seems to be wrong if
:there are three or more MPDUs in one packet.
:"remain" is initialized with the output buffer size.
:Each time an MPDU is found in the packet remain is r
On 2020 Dec 07 (Mon) at 15:02:14 +0100 (+0100), Stefan Sperling wrote:
:On Mon, Dec 07, 2020 at 02:36:05PM +0100, Tobias Heider wrote:
:> Hi,
:>
:> our net80211 gapwait accounting implementation seems to have several
:> problems:
:> - If we lose packets with serial numbers 0 und 2 but receive the
Getting a page from the fault handler might require poking at some
swap-related states.
These are not in the hot-path of the fault handler so for the moment
just assert that the KERNEL_LOCK() is held or grab it if the function
might be called from an future unlocked path.
ok?
Index: uvm/uvm_swap
Pratik Vyas [m...@pd.io] wrote:
>
> This cpuid emulation bit was added during the time when using tsc was
> the only way to get a precise clock and before pvclock was added [2]. This
> also doesn't work on AMD machines (on at least mine). We could get rid
> of this cpuid emulation.
>
If cpuid e
On Mon, 7 Dec 2020 13:39:30 +0100
Antoine Jacoutot :
> Index: syspatch.8
> ===
> RCS file: /cvs/src/usr.sbin/syspatch/syspatch.8,v
> retrieving revision 1.21
> diff -u -p -r1.21 syspatch.8
> --- syspatch.825 Jul 2020 15:45:44
Diff below adds a per-thread kqueue that will be initialized during the
first select(2) or poll(2) syscall and freed upon exit.
Along with this queue a per-thread serial number is used to check the
integrity of events enqueued during a given syscall. This could also
later be used to perform lazy
On Mon, Dec 07, 2020 at 03:49:20PM +0100, Tobias Heider wrote:
> On Mon, Dec 07, 2020 at 02:33:10PM +0100, Stefan Sperling wrote:
> > On Mon, Dec 07, 2020 at 01:31:09PM +0100, Tobias Heider wrote:
> > > Some APs request a BA agreement and continue to send QOS packets
> > > for the same tid (with no
On Mon, Dec 07, 2020 at 03:32:48PM +0100, Tobias Heider wrote:
> Hi,
>
> this is an iwx(4) port of the iwm(4) fix by Christian Erhardt
> which I sent in a previous mail:
> https://marc.info/?l=openbsd-tech&m=160733342209497&w=2
>
> I don't have a iwx(4) card to test this, but the diff to iwm(4) i
On Mon, Dec 07, 2020 at 02:33:10PM +0100, Stefan Sperling wrote:
> On Mon, Dec 07, 2020 at 01:31:09PM +0100, Tobias Heider wrote:
> > Some APs request a BA agreement and continue to send QOS packets
> > for the same tid (with normal ack policy). Currently, these packets
> > make it to the higher la
Hi,
this is an iwx(4) port of the iwm(4) fix by Christian Erhardt
which I sent in a previous mail:
https://marc.info/?l=openbsd-tech&m=160733342209497&w=2
I don't have a iwx(4) card to test this, but the diff to iwm(4) is trivial.
ok?
Index: if_iwx.c
=
On Mon, Dec 07, 2020 at 02:36:05PM +0100, Tobias Heider wrote:
> Hi,
>
> our net80211 gapwait accounting implementation seems to have several
> problems:
> - If we lose packets with serial numbers 0 und 2 but receive the
> packet with serial number 1, the first gap wait timeout will
> skip ser
Hi,
our net80211 gapwait accounting implementation seems to have several
problems:
- If we lose packets with serial numbers 0 und 2 but receive the
packet with serial number 1, the first gap wait timeout will
skip serial number 0, flush out serial number 1 and then wait
for serial number 2.
On Mon, Dec 07, 2020 at 01:31:09PM +0100, Tobias Heider wrote:
> Some APs request a BA agreement and continue to send QOS packets
> for the same tid (with normal ack policy). Currently, these packets
> make it to the higher layers without going through BA reordering or the
> BA buffer. This results
On Mon, Dec 07, 2020 at 10:28:59AM +0100, Tobias Heider wrote:
> Hi,
>
> In iwm_rx_pkt() the calculation of "remain" seems to be wrong if
> there are three or more MPDUs in one packet.
> "remain" is initialized with the output buffer size.
> Each time an MPDU is found in the packet remain is reduc
On Mon, Dec 07, 2020 at 10:13:44AM -0300, Martin Pieuchot wrote:
> On 05/12/20(Sat) 22:34, Jonathan Matthew wrote:
> > On Fri, Dec 04, 2020 at 10:03:46AM -0300, Martin Pieuchot wrote:
> > > On 04/12/20(Fri) 12:01, Jonathan Matthew wrote:
> > > > On Wed, Dec 02, 2020 at 11:41:04AM -0300, Martin Pieu
On 05/12/20(Sat) 22:34, Jonathan Matthew wrote:
> On Fri, Dec 04, 2020 at 10:03:46AM -0300, Martin Pieuchot wrote:
> > On 04/12/20(Fri) 12:01, Jonathan Matthew wrote:
> > > On Wed, Dec 02, 2020 at 11:41:04AM -0300, Martin Pieuchot wrote:
> > > > [...]
> > > > Could you try the diff below that only
Hi Antoine,
Antoine Jacoutot wrote on Mon, Dec 07, 2020 at 01:39:30PM +0100:
> On Mon, Dec 07, 2020 at 01:30:55PM +0100, Ingo Schwarze wrote:
>> Antoine Jacoutot wrote on Mon, Dec 07, 2020 at 01:01:27PM +0100:
>>> I just tested this change and it seems to work:
[...]
>> I think a slightly more ex
On Mon, Dec 07, 2020 at 01:30:55PM +0100, Ingo Schwarze wrote:
> Hello Antoine,
>
> Antoine Jacoutot wrote on Mon, Dec 07, 2020 at 01:01:27PM +0100:
>
> > I just tested this change and it seems to work:
>
> I did not repeat my testing, but here is some quick feedback purely
> from code inspectio
Some APs request a BA agreement and continue to send QOS packets
for the same tid (with normal ack policy). Currently, these packets
make it to the higher layers without going through BA reordering or the
BA buffer. This results in reduced performance later on as the sequence
numbers are expected b
Hello Antoine,
Antoine Jacoutot wrote on Mon, Dec 07, 2020 at 01:01:27PM +0100:
> I just tested this change and it seems to work:
I did not repeat my testing, but here is some quick feedback purely
from code inspection:
The proposed code change makes sense to me.
The proposed manual page text
On Mon, Dec 07, 2020 at 11:54:04AM +0100, Ingo Schwarze wrote:
> > Index: syspatch.sh
> > ===
> > RCS file: /cvs/src/usr.sbin/syspatch/syspatch.sh,v
> > retrieving revision 1.166
> > diff -u -p -r1.166 syspatch.sh
> > --- syspatch.sh
Hi Antoine,
Antoine Jacoutot wrote on Mon, Dec 07, 2020 at 09:48:36AM +0100:
> On Sun, Dec 06, 2020 at 10:52:37PM +0100, Alexander Hall wrote:
>> On December 6, 2020 8:13:26 PM GMT+01:00, Antoine Jacoutot wrote:
>>> On Sun, Dec 06, 2020 at 05:20:31PM +, Stuart Henderson wrote:
On 2020/12/
Hi,
In iwm_rx_pkt() the calculation of "remain" seems to be wrong if
there are three or more MPDUs in one packet.
"remain" is initialized with the output buffer size.
Each time an MPDU is found in the packet remain is reduced
by the offset of the MPDU in the receive buffer, which is only
correct f
On Sun, Dec 06, 2020 at 10:52:37PM +0100, Alexander Hall wrote:
>
>
> On December 6, 2020 8:13:26 PM GMT+01:00, Antoine Jacoutot
> wrote:
> >On Sun, Dec 06, 2020 at 05:20:31PM +, Stuart Henderson wrote:
> >> On 2020/12/06 16:39, Otto Moerbeek wrote:
> >> > On Sun, Dec 06, 2020 at 03:31:19PM
41 matches
Mail list logo
