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
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
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
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
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
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
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
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
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
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
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=160733342209497=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
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
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
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
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 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
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=160733342209497=2
>
> I don't have a iwx(4) card to test this, but the diff to iwm(4) is
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
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)
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
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:
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
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
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:
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
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
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
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
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
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
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
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
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
> 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
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
> >
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
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
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
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
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
41 matches
Mail list logo
