On Thu, Mar 10, 2022 at 07:17:43PM +0100, Alexander Bluhm wrote:
> On Thu, Mar 10, 2022 at 04:39:49PM +0100, Alexander Bluhm wrote:
> > > Below is a patch that shows how to accomplish release semantics with
> > > the file and refcnt APIs. (The added memory barriers ensure that the
> > > CPU
On Thu, Mar 10, 2022 at 12:35:20PM +0100, Stefan Sperling wrote:
>
> On Thu, Mar 10, 2022 at 12:25:17PM +0100, Stefan Sperling wrote:
> > Unless anyone else finds a problem, this patch can be considered ready
> > for review and commit.
>
> Of course, I forgot to apply my sysassert fix to the
On Tue, Mar 08, 2022 at 01:44:47PM +, Visa Hankala wrote:
> On Tue, Mar 08, 2022 at 08:04:36AM +0100, Anton Lindqvist wrote:
> > On Mon, Mar 07, 2022 at 07:36:35AM +, Visa Hankala wrote:
> > > I still think that checking TXFF and using the same code for both
> > > SBSA and true PL011 UARTs
On Wed, Mar 09, 2022 at 01:07:47PM +0100, Stefan Sperling wrote:
> This patch adds initial 11ac support to the iwx(4) driver.
> This means that 80MHz channels can be used. No other 11ac features
> are enabled yet.
>
> This is not yet a patch which could be committed. Apart from debug
> prints
On Thu, Mar 10, 2022 at 12:25:17PM +0100, Stefan Sperling wrote:
> Unless anyone else finds a problem, this patch can be considered ready
> for review and commit.
Of course, I forgot to apply my sysassert fix to the second phy context
command function... Fixed here.
diff refs/heads/master
On Wed, Mar 09, 2022 at 07:16:41PM +0300, Mikhail wrote:
> On Wed, Mar 09, 2022 at 01:07:47PM +0100, Stefan Sperling wrote:
> > /*
> > + * Install received VHT caps information in the node's state block.
> > + */
> > +void
> > +ieee80211_setup_vhtcaps(struct ieee80211_node *ni, const uint8_t
On Thu, Mar 10, 2022 at 09:05:54AM +, Visa Hankala wrote:
Hello Visa,
> In general, atomic_* functions have not provided implicit memory
> barriers on OpenBSD.
I've used atomics fairly extensively in other settings. Forgive me if I'm
explaining the obvious, but I had a devil of a job making
On Wed, Mar 09, 2022 at 08:45:35PM +0100, Alexander Bluhm wrote:
> On Tue, Mar 08, 2022 at 04:55:56PM +0100, Alexander Bluhm wrote:
> > Once we had the discussion where we need the READ_ONCE() macro. As
> > modern C compiler has much freedom how to access memory, I came to
> > the conclusion that
On Thu, Mar 10, 2022 at 09:05:54AM +, Visa Hankala wrote:
> > As a bonus alpha gets the membar it needs.
>
> In general, atomic_* functions have not provided implicit memory
> barriers on OpenBSD.
>
> I am not sure if the data dependency barrier is needed where
> atomic_load_int() and
Hi Stefan,
* Stefan Sperling wrote:
> On Thu, Mar 10, 2022 at 12:25:17PM +0100, Stefan Sperling wrote:
> > Unless anyone else finds a problem, this patch can be considered ready
> > for review and commit.
>
> Of course, I forgot to apply my sysassert fix to the second phy context
> command
On Thu, Mar 10, 2022 at 10:45:47AM +, Laurence Tratt wrote:
> On Thu, Mar 10, 2022 at 09:05:54AM +, Visa Hankala wrote:
>
> Hello Visa,
>
> > In general, atomic_* functions have not provided implicit memory
> > barriers on OpenBSD.
>
> I've used atomics fairly extensively in other
Mikhail wrote:
> On Wed, Mar 02, 2022 at 09:47:31AM +0100, Omar Polo wrote:
> > Hello tech,
> >
> > mg(1) has this tendency to leave a lot of trailing whitespaces around in
> > auto-indent-mode and c-mode which I find annoying. Yes, there's
> > delete-trailing-space but it works only on the
Replace rsync command with openrsync in EXAMPLES.
diff --git usr.bin/rsync/rsync.1 usr.bin/rsync/rsync.1
index 8144754695a..9bcf3566bb9 100644
--- usr.bin/rsync/rsync.1
+++ usr.bin/rsync/rsync.1
@@ -290,7 +290,7 @@ with the local
and
.Pa ../src/baz :
.Pp
-.Dl % rsync -t ../src/bar ../src/baz
On Thu, Mar 10, 2022 at 06:15:48PM +0100, Theo Buehler wrote:
> On Thu, Mar 10, 2022 at 06:03:14PM +0100, Claudio Jeker wrote:
> > On Thu, Mar 10, 2022 at 05:54:21PM +0100, Theo Buehler wrote:
> > > On Thu, Mar 10, 2022 at 05:51:46PM +0100, Claudio Jeker wrote:
> > > > On Thu, Mar 10, 2022 at
On Thu, Mar 10, 2022 at 02:03:26PM +, Visa Hankala wrote:
> My understanding is that OpenBSD's atomic_* instructions are relaxed
> in terms of memory order. To accomplish a specific form of semantics,
> the user adds the appropriate memory barrier instruction. Well, this
> is the plan at
Hi
This pulls up and adjusts the check if i exceeds the bounds of pfds.
Before it was technically wrong, as i > NPFDS means that the last
write (i == NPFDS) was already out of bounds.
Best,
Martin
Index: http.c
===
RCS file:
On Thu, Mar 10, 2022 at 05:33:28PM +0100, Martin Vahlensieck wrote:
> Hi
>
> This pulls up and adjusts the check if i exceeds the bounds of pfds.
> Before it was technically wrong, as i > NPFDS means that the last
> write (i == NPFDS) was already out of bounds.
I see no reason to pull up the
On Thu, Mar 10, 2022 at 05:54:21PM +0100, Theo Buehler wrote:
> On Thu, Mar 10, 2022 at 05:51:46PM +0100, Claudio Jeker wrote:
> > On Thu, Mar 10, 2022 at 05:33:28PM +0100, Martin Vahlensieck wrote:
> > > Hi
> > >
> > > This pulls up and adjusts the check if i exceeds the bounds of pfds.
> > >
On Thu, Mar 10, 2022 at 06:03:14PM +0100, Claudio Jeker wrote:
> On Thu, Mar 10, 2022 at 05:54:21PM +0100, Theo Buehler wrote:
> > On Thu, Mar 10, 2022 at 05:51:46PM +0100, Claudio Jeker wrote:
> > > On Thu, Mar 10, 2022 at 05:33:28PM +0100, Martin Vahlensieck wrote:
> > > > Hi
> > > >
> > > >
On Thu, Mar 10, 2022 at 05:51:46PM +0100, Claudio Jeker wrote:
> On Thu, Mar 10, 2022 at 05:33:28PM +0100, Martin Vahlensieck wrote:
> > Hi
> >
> > This pulls up and adjusts the check if i exceeds the bounds of pfds.
> > Before it was technically wrong, as i > NPFDS means that the last
> > write
On 2022 Mar 10 (Thu) at 12:35:20 +0100 (+0100), Stefan Sperling wrote:
:On Thu, Mar 10, 2022 at 12:25:17PM +0100, Stefan Sperling wrote:
:> Unless anyone else finds a problem, this patch can be considered ready
:> for review and commit.
:
:Of course, I forgot to apply my sysassert fix to the
Hi,
claudio@ mentioned that documentation for membar_enter_after_atomic
and membar_exit_before_atomic is missing.
ok?
bluhm
Index: membar_sync.9
===
RCS file: /data/mirror/openbsd/cvs/src/share/man/man9/membar_sync.9,v
retrieving
> Date: Thu, 10 Mar 2022 21:43:02 +0100
> From: Alexander Bluhm
>
> On Thu, Mar 10, 2022 at 07:47:16PM +0100, Mark Kettenis wrote:
> > > In general, atomic_* functions have not provided implicit memory
> > > barriers on OpenBSD.
> > >
> > > I am not sure if the data dependency barrier is needed
Stefan Sperling writes:
> On Thu, Mar 10, 2022 at 01:56:19PM -0500, Dave Voutila wrote:
>>
>> Stefan Sperling writes:
>>
>> > On Thu, Mar 10, 2022 at 12:25:17PM +0100, Stefan Sperling wrote:
>> >> Unless anyone else finds a problem, this patch can be considered ready
>> >> for review and
On Thu, Mar 10, 2022 at 07:47:16PM +0100, Mark Kettenis wrote:
> > In general, atomic_* functions have not provided implicit memory
> > barriers on OpenBSD.
> >
> > I am not sure if the data dependency barrier is needed where
> > atomic_load_int() and atomic_load_long() are used. The memory
> Date: Thu, 10 Mar 2022 21:53:13 +0100
> From: Alexander Bluhm
>
> Hi,
>
> claudio@ mentioned that documentation for membar_enter_after_atomic
> and membar_exit_before_atomic is missing.
>
> ok?
I think this is fine, although it doesn't actually define what an
"atomic operation" is in this
On Thu, Mar 10, 2022 at 10:45:47AM +, Laurence Tratt wrote:
> On Thu, Mar 10, 2022 at 09:05:54AM +, Visa Hankala wrote:
>
> Hello Visa,
>
> > In general, atomic_* functions have not provided implicit memory
> > barriers on OpenBSD.
>
> I've used atomics fairly extensively in other
On Thu, Mar 10, 2022 at 06:29:40PM +0100, Martin Vahlensieck wrote:
> On Thu, Mar 10, 2022 at 06:15:48PM +0100, Theo Buehler wrote:
> > On Thu, Mar 10, 2022 at 06:03:14PM +0100, Claudio Jeker wrote:
> > > On Thu, Mar 10, 2022 at 05:54:21PM +0100, Theo Buehler wrote:
> > > > On Thu, Mar 10, 2022 at
On Thu, Mar 10, 2022 at 04:39:49PM +0100, Alexander Bluhm wrote:
> > Below is a patch that shows how to accomplish release semantics with
> > the file and refcnt APIs. (The added memory barriers ensure that the
> > CPU completes its loads and stores to the object before dropping the
> > reference.
> Date: Thu, 10 Mar 2022 09:05:54 +
> From: Visa Hankala
>
> On Wed, Mar 09, 2022 at 08:45:35PM +0100, Alexander Bluhm wrote:
> > On Tue, Mar 08, 2022 at 04:55:56PM +0100, Alexander Bluhm wrote:
> > > Once we had the discussion where we need the READ_ONCE() macro. As
> > > modern C compiler
Stefan Sperling writes:
> On Thu, Mar 10, 2022 at 12:25:17PM +0100, Stefan Sperling wrote:
>> Unless anyone else finds a problem, this patch can be considered ready
>> for review and commit.
>
> Of course, I forgot to apply my sysassert fix to the second phy context
> command function...
On Thu, Mar 10, 2022 at 01:56:19PM -0500, Dave Voutila wrote:
>
> Stefan Sperling writes:
>
> > On Thu, Mar 10, 2022 at 12:25:17PM +0100, Stefan Sperling wrote:
> >> Unless anyone else finds a problem, this patch can be considered ready
> >> for review and commit.
> >
> > Of course, I forgot to
On Thu, Mar 10, 2022 at 10:26:21PM +, Laurence Tratt wrote:
> On Thu, Mar 10, 2022 at 09:52:27PM +0100, Mark Kettenis wrote:
>
> Hello Mark,
>
> > If you think about it, the invariants being tested by those KASSERTs should
> > not depend on whether the old or the new value is read if another
> From: Jeremie Courreges-Anglas
> Cc: Mark Kettenis , Patrick Wildt
> Date: Thu, 10 Mar 2022 02:03:10 +0100
> Content-Type: text/plain
>
> On Mon, Oct 25 2021, Jeremie Courreges-Anglas wrote:
> > On Mon, Oct 25 2021, Patrick Wildt wrote:
> >> Am Mon, Oct 25, 2021 at 11:43:55AM +0200 schrieb
On Thu, Mar 10, 2022 at 09:52:27PM +0100, Mark Kettenis wrote:
Hello Mark,
> If you think about it, the invariants being tested by those KASSERTs should
> not depend on whether the old or the new value is read if another CPU is
> modifying that variable at the same time. Unless of course there
On Fri, Mar 11, 2022 at 09:00:57AM +1000, David Gwynne wrote:
Hello David,
>> Unfortunately this transformation almost certainly isn't safe: for
>> example, the non-atomic load can return values that were never written by
>> any thread (e.g. due to load/store tearing amongst other fun effects).
36 matches
Mail list logo
