On Thu, Nov 12, 2020 at 02:27:49PM -0700, Shuah Khan wrote:
> atomic64_t depends on CONFIG_64BIT
>
> include/linux/types.h
>
> #ifdef CONFIG_64BIT
> typedef struct {
> s64 counter;
> } atomic64_t;
> #endif
That's because some 32bit archs need to override the type definition.
atomic64_t
On 11/11/20 12:23 PM, Shuah Khan wrote:
On 11/10/20 5:18 PM, Kees Cook wrote:
On Tue, Nov 10, 2020 at 09:43:02PM +0100, Greg KH wrote:
On Tue, Nov 10, 2020 at 09:41:40PM +0100, Greg KH wrote:
On Tue, Nov 10, 2020 at 12:53:27PM -0700, Shuah Khan wrote:
+Decrement interface
+---
On 11/12/20 9:45 AM, Greg KH wrote:
On Thu, Nov 12, 2020 at 09:17:27AM -0700, Shuah Khan wrote:
On 11/12/20 5:36 AM, Matthew Wilcox wrote:
On Wed, Nov 11, 2020 at 12:23:03PM -0700, Shuah Khan wrote:
Agreed: this is a clear wrapping sequence counter. It's only abuse would
be using it in a place
On Thu, Nov 12, 2020 at 09:17:27AM -0700, Shuah Khan wrote:
> On 11/12/20 5:36 AM, Matthew Wilcox wrote:
> > On Wed, Nov 11, 2020 at 12:23:03PM -0700, Shuah Khan wrote:
> > > > Agreed: this is a clear wrapping sequence counter. It's only abuse would
> > > > be using it in a place where wrapping act
On 11/12/20 5:36 AM, Matthew Wilcox wrote:
On Wed, Nov 11, 2020 at 12:23:03PM -0700, Shuah Khan wrote:
Agreed: this is a clear wrapping sequence counter. It's only abuse would
be using it in a place where wrapping actually is _not_ safe. (bikeshed:
can we call it wrap_u32 and wrap_u64?)
Still
On Wed, Nov 11, 2020 at 09:15:55PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 11, 2020 at 11:28:13AM -0700, Shuah Khan wrote:
> > On 11/11/20 10:50 AM, Peter Zijlstra wrote:
> > > On Wed, Nov 11, 2020 at 10:34:05AM -0700, Shuah Khan wrote:
> > >
> > > > Not sure what to make of the 6080 atomic_rea
On Wed, Nov 11, 2020 at 12:23:03PM -0700, Shuah Khan wrote:
> > Agreed: this is a clear wrapping sequence counter. It's only abuse would
> > be using it in a place where wrapping actually is _not_ safe. (bikeshed:
> > can we call it wrap_u32 and wrap_u64?)
>
> Still like seqnum_ops.
>
> There is
On Wed, Nov 11, 2020 at 11:28:13AM -0700, Shuah Khan wrote:
> On 11/11/20 10:50 AM, Peter Zijlstra wrote:
> > On Wed, Nov 11, 2020 at 10:34:05AM -0700, Shuah Khan wrote:
> >
> > > Not sure what to make of the 6080 atomic_read()s and 3413
> > > atomic_inc()s, some of which might be assuming uniquen
On 11/10/20 5:18 PM, Kees Cook wrote:
On Tue, Nov 10, 2020 at 09:43:02PM +0100, Greg KH wrote:
On Tue, Nov 10, 2020 at 09:41:40PM +0100, Greg KH wrote:
On Tue, Nov 10, 2020 at 12:53:27PM -0700, Shuah Khan wrote:
+Decrement interface
+---
+
+Decrements sequence number and doesn'
On 11/11/20 10:50 AM, Peter Zijlstra wrote:
On Wed, Nov 11, 2020 at 10:34:05AM -0700, Shuah Khan wrote:
Not sure what to make of the 6080 atomic_read()s and 3413
atomic_inc()s, some of which might be assuming uniqueness
guarantee.
Well, clearly you just did: git grep atimic_{read,inc}() | wc
On Wed, Nov 11, 2020 at 10:34:05AM -0700, Shuah Khan wrote:
> Not sure what to make of the 6080 atomic_read()s and 3413
> atomic_inc()s, some of which might be assuming uniqueness
> guarantee.
Well, clearly you just did: git grep atimic_{read,inc}() | wc -l and
didn't look at the usage. Equally c
On 11/11/20 9:04 AM, Peter Zijlstra wrote:
On Wed, Nov 11, 2020 at 08:56:49AM -0700, Shuah Khan wrote:
Why would you say no to read and inc?
Because they don't guarantee uniqueness (bar wrapping), which is the
only reason to use an atomic to begin with.
Thanks for the explanation. I see wh
On Wed, Nov 11, 2020 at 08:56:49AM -0700, Shuah Khan wrote:
> Why would you say no to read and inc?
Because they don't guarantee uniqueness (bar wrapping), which is the
only reason to use an atomic to begin with.
On 11/11/20 1:23 AM, Peter Zijlstra wrote:
On Tue, Nov 10, 2020 at 12:53:27PM -0700, Shuah Khan wrote:
+ * The interface provides:
+ * seqnum32 & seqnum64 functions:
+ * initialization
+ * set
+ * read
+ * increment and no return
+ * decrement and no return
NAK, this is ba
On 11/10/20 5:20 PM, Kees Cook wrote:
On Tue, Nov 10, 2020 at 03:58:48PM -0700, Shuah Khan wrote:
Yes we have some instances where unsigned is being used. I considered
going to unsigned. Changing the API to unsigned has other ramifications
and cascading changes to current atomic_t usages that ar
On Tue, Nov 10, 2020 at 12:53:27PM -0700, Shuah Khan wrote:
> + * The interface provides:
> + * seqnum32 & seqnum64 functions:
> + * initialization
> + * set
> + * read
> + * increment and no return
> + * decrement and no return
NAK, this is batshit insane again. If you want a sequence
On Tue, Nov 10, 2020 at 03:58:48PM -0700, Shuah Khan wrote:
> Yes we have some instances where unsigned is being used. I considered
> going to unsigned. Changing the API to unsigned has other ramifications
> and cascading changes to current atomic_t usages that are up counters.
As in, existing cal
On Tue, Nov 10, 2020 at 09:43:02PM +0100, Greg KH wrote:
> On Tue, Nov 10, 2020 at 09:41:40PM +0100, Greg KH wrote:
> > On Tue, Nov 10, 2020 at 12:53:27PM -0700, Shuah Khan wrote:
> > > +Decrement interface
> > > +---
> > > +
> > > +Decrements sequence number and doesn't return the
On 11/10/20 2:03 PM, Matthew Wilcox wrote:
On Tue, Nov 10, 2020 at 12:53:27PM -0700, Shuah Khan wrote:
Sequence Numbers wrap around to INT_MIN when it overflows and should not
Why would sequence numbers be signed? I know they're built on top of
atomic_t, which is signed, but conceptually a se
On Tue, Nov 10, 2020 at 12:53:27PM -0700, Shuah Khan wrote:
> Sequence Numbers wrap around to INT_MIN when it overflows and should not
Why would sequence numbers be signed? I know they're built on top of
atomic_t, which is signed, but conceptually a sequence number is unsigned.
> +++ b/Documenta
On Tue, Nov 10, 2020 at 09:41:40PM +0100, Greg KH wrote:
> On Tue, Nov 10, 2020 at 12:53:27PM -0700, Shuah Khan wrote:
> > +Decrement interface
> > +---
> > +
> > +Decrements sequence number and doesn't return the new value. ::
> > +
> > +seqnum32_dec() --> atomic_dec()
> >
On Tue, Nov 10, 2020 at 12:53:27PM -0700, Shuah Khan wrote:
> +Decrement interface
> +---
> +
> +Decrements sequence number and doesn't return the new value. ::
> +
> +seqnum32_dec() --> atomic_dec()
> +seqnum64_dec() --> atomic64_dec()
Why would you need to decreme
22 matches
Mail list logo
