On 05/23/2016 02:46 PM, Jason Low wrote:
On Sat, 2016-05-21 at 09:04 -0700, Peter Hurley wrote:
On 05/18/2016 12:58 PM, Jason Low wrote:
It should be fine to use the standard READ_ONCE here, even if it's just
for documentation, as it's probably not going to cost anything in
practice. It would
On 05/23/2016 02:46 PM, Jason Low wrote:
On Sat, 2016-05-21 at 09:04 -0700, Peter Hurley wrote:
On 05/18/2016 12:58 PM, Jason Low wrote:
It should be fine to use the standard READ_ONCE here, even if it's just
for documentation, as it's probably not going to cost anything in
practice. It would
On Mon, 23 May 2016, Paul E. McKenney wrote:
But rcu_read_lock() does not exclude updates, which is one reason why
pointer reads use rcu_dereference() rather than normal assignments.
Yes, I was referring to readers. With updates, otoh, are done holding a number
of locks.
So I do not
On Mon, 23 May 2016, Paul E. McKenney wrote:
But rcu_read_lock() does not exclude updates, which is one reason why
pointer reads use rcu_dereference() rather than normal assignments.
Yes, I was referring to readers. With updates, otoh, are done holding a number
of locks.
So I do not
On Mon, May 23, 2016 at 12:44:16PM -0700, Davidlohr Bueso wrote:
> On Mon, 23 May 2016, Jason Low wrote:
>
> >On Sat, 2016-05-21 at 09:04 -0700, Peter Hurley wrote:
> >>On 05/18/2016 12:58 PM, Jason Low wrote:
> >>> It should be fine to use the standard READ_ONCE here, even if it's just
> >>> for
On Mon, May 23, 2016 at 12:44:16PM -0700, Davidlohr Bueso wrote:
> On Mon, 23 May 2016, Jason Low wrote:
>
> >On Sat, 2016-05-21 at 09:04 -0700, Peter Hurley wrote:
> >>On 05/18/2016 12:58 PM, Jason Low wrote:
> >>> It should be fine to use the standard READ_ONCE here, even if it's just
> >>> for
On Mon, 23 May 2016, Jason Low wrote:
On Sat, 2016-05-21 at 09:04 -0700, Peter Hurley wrote:
On 05/18/2016 12:58 PM, Jason Low wrote:
> It should be fine to use the standard READ_ONCE here, even if it's just
> for documentation, as it's probably not going to cost anything in
> practice. It
On Mon, 23 May 2016, Jason Low wrote:
On Sat, 2016-05-21 at 09:04 -0700, Peter Hurley wrote:
On 05/18/2016 12:58 PM, Jason Low wrote:
> It should be fine to use the standard READ_ONCE here, even if it's just
> for documentation, as it's probably not going to cost anything in
> practice. It
On Sat, 2016-05-21 at 09:04 -0700, Peter Hurley wrote:
> On 05/18/2016 12:58 PM, Jason Low wrote:
> > It should be fine to use the standard READ_ONCE here, even if it's just
> > for documentation, as it's probably not going to cost anything in
> > practice. It would be better to avoid adding any
On Sat, 2016-05-21 at 09:04 -0700, Peter Hurley wrote:
> On 05/18/2016 12:58 PM, Jason Low wrote:
> > It should be fine to use the standard READ_ONCE here, even if it's just
> > for documentation, as it's probably not going to cost anything in
> > practice. It would be better to avoid adding any
On Sat, May 21, 2016 at 09:04:14AM -0700, Peter Hurley wrote:
> And by the way, it's not just "here" but _everywhere_.
> What about reading ->on_cpu locklessly?
In the smp_cond_acquire() rework that I have pending that one is
actually 'fixed'.
But yeah, the whole load/store tearing thing is
On Sat, May 21, 2016 at 09:04:14AM -0700, Peter Hurley wrote:
> And by the way, it's not just "here" but _everywhere_.
> What about reading ->on_cpu locklessly?
In the smp_cond_acquire() rework that I have pending that one is
actually 'fixed'.
But yeah, the whole load/store tearing thing is
On 05/18/2016 12:58 PM, Jason Low wrote:
> On Wed, 2016-05-18 at 14:29 -0400, Waiman Long wrote:
>> On 05/18/2016 01:21 PM, Jason Low wrote:
>>> On Wed, 2016-05-18 at 07:04 -0700, Davidlohr Bueso wrote:
On Tue, 17 May 2016, Waiman Long wrote:
> Without using WRITE_ONCE(), the
On 05/18/2016 12:58 PM, Jason Low wrote:
> On Wed, 2016-05-18 at 14:29 -0400, Waiman Long wrote:
>> On 05/18/2016 01:21 PM, Jason Low wrote:
>>> On Wed, 2016-05-18 at 07:04 -0700, Davidlohr Bueso wrote:
On Tue, 17 May 2016, Waiman Long wrote:
> Without using WRITE_ONCE(), the
On 05/19/2016 06:21 PM, Jason Low wrote:
On Wed, 2016-05-18 at 12:58 -0700, Jason Low wrote:
On Wed, 2016-05-18 at 14:29 -0400, Waiman Long wrote:
On 05/18/2016 01:21 PM, Jason Low wrote:
On Wed, 2016-05-18 at 07:04 -0700, Davidlohr Bueso wrote:
On Tue, 17 May 2016, Waiman Long wrote:
On 05/19/2016 06:21 PM, Jason Low wrote:
On Wed, 2016-05-18 at 12:58 -0700, Jason Low wrote:
On Wed, 2016-05-18 at 14:29 -0400, Waiman Long wrote:
On 05/18/2016 01:21 PM, Jason Low wrote:
On Wed, 2016-05-18 at 07:04 -0700, Davidlohr Bueso wrote:
On Tue, 17 May 2016, Waiman Long wrote:
On Wed, 2016-05-18 at 12:58 -0700, Jason Low wrote:
> On Wed, 2016-05-18 at 14:29 -0400, Waiman Long wrote:
> > On 05/18/2016 01:21 PM, Jason Low wrote:
> > > On Wed, 2016-05-18 at 07:04 -0700, Davidlohr Bueso wrote:
> > >> On Tue, 17 May 2016, Waiman Long wrote:
> > >>
> > >>> Without using
On Wed, 2016-05-18 at 12:58 -0700, Jason Low wrote:
> On Wed, 2016-05-18 at 14:29 -0400, Waiman Long wrote:
> > On 05/18/2016 01:21 PM, Jason Low wrote:
> > > On Wed, 2016-05-18 at 07:04 -0700, Davidlohr Bueso wrote:
> > >> On Tue, 17 May 2016, Waiman Long wrote:
> > >>
> > >>> Without using
On Wed, 2016-05-18 at 14:29 -0400, Waiman Long wrote:
> On 05/18/2016 01:21 PM, Jason Low wrote:
> > On Wed, 2016-05-18 at 07:04 -0700, Davidlohr Bueso wrote:
> >> On Tue, 17 May 2016, Waiman Long wrote:
> >>
> >>> Without using WRITE_ONCE(), the compiler can potentially break a
> >>> write into
On Wed, 2016-05-18 at 14:29 -0400, Waiman Long wrote:
> On 05/18/2016 01:21 PM, Jason Low wrote:
> > On Wed, 2016-05-18 at 07:04 -0700, Davidlohr Bueso wrote:
> >> On Tue, 17 May 2016, Waiman Long wrote:
> >>
> >>> Without using WRITE_ONCE(), the compiler can potentially break a
> >>> write into
On 05/18/2016 01:21 PM, Jason Low wrote:
On Wed, 2016-05-18 at 07:04 -0700, Davidlohr Bueso wrote:
On Tue, 17 May 2016, Waiman Long wrote:
Without using WRITE_ONCE(), the compiler can potentially break a
write into multiple smaller ones (store tearing). So a read from the
same data by another
On 05/18/2016 01:21 PM, Jason Low wrote:
On Wed, 2016-05-18 at 07:04 -0700, Davidlohr Bueso wrote:
On Tue, 17 May 2016, Waiman Long wrote:
Without using WRITE_ONCE(), the compiler can potentially break a
write into multiple smaller ones (store tearing). So a read from the
same data by another
On Wed, 2016-05-18 at 07:04 -0700, Davidlohr Bueso wrote:
> On Tue, 17 May 2016, Waiman Long wrote:
>
> >Without using WRITE_ONCE(), the compiler can potentially break a
> >write into multiple smaller ones (store tearing). So a read from the
> >same data by another task concurrently may return a
On Wed, 2016-05-18 at 07:04 -0700, Davidlohr Bueso wrote:
> On Tue, 17 May 2016, Waiman Long wrote:
>
> >Without using WRITE_ONCE(), the compiler can potentially break a
> >write into multiple smaller ones (store tearing). So a read from the
> >same data by another task concurrently may return a
On Wed, 2016-05-18 at 07:04 -0700, Davidlohr Bueso wrote:
> On Tue, 17 May 2016, Waiman Long wrote:
>
> >Without using WRITE_ONCE(), the compiler can potentially break a
> >write into multiple smaller ones (store tearing). So a read from the
> >same data by another task concurrently may return a
On Wed, 2016-05-18 at 07:04 -0700, Davidlohr Bueso wrote:
> On Tue, 17 May 2016, Waiman Long wrote:
>
> >Without using WRITE_ONCE(), the compiler can potentially break a
> >write into multiple smaller ones (store tearing). So a read from the
> >same data by another task concurrently may return a
On Tue, 17 May 2016, Waiman Long wrote:
Without using WRITE_ONCE(), the compiler can potentially break a
write into multiple smaller ones (store tearing). So a read from the
same data by another task concurrently may return a partial result.
This can result in a kernel crash if the data is a
On Tue, 17 May 2016, Waiman Long wrote:
Without using WRITE_ONCE(), the compiler can potentially break a
write into multiple smaller ones (store tearing). So a read from the
same data by another task concurrently may return a partial result.
This can result in a kernel crash if the data is a
Without using WRITE_ONCE(), the compiler can potentially break a
write into multiple smaller ones (store tearing). So a read from the
same data by another task concurrently may return a partial result.
This can result in a kernel crash if the data is a memory address
that is being dereferenced.
Without using WRITE_ONCE(), the compiler can potentially break a
write into multiple smaller ones (store tearing). So a read from the
same data by another task concurrently may return a partial result.
This can result in a kernel crash if the data is a memory address
that is being dereferenced.
30 matches
Mail list logo
