[lkml]   [2007]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/24] make atomic_read() behave consistently across all architectures
Herbert Xu writes:

> If you're referring to the code in sk_stream_mem_schedule
> then it's working as intended. The atomicity guarantees

You mean it's intended that *sk->sk_prot->memory_pressure can end up
as 1 when sk->sk_prot->memory_allocated is small (less than
->sysctl_mem[0]), or as 0 when ->memory_allocated is large (greater
than ->sysctl_mem[2])? Because that's the effect of the current code.
If so I wonder why you bother computing it.

> that the atomic_add/atomic_sub won't be seen in parts by
> other readers.
> We certainly do not need to see other atomic_add/atomic_sub
> operations immediately.
> If you're referring to another code snippet please cite.
> > I'd go so far as to say that anywhere where you want a non-"volatile"
> > atomic_read, either your code is buggy, or else an int would work just
> > as well.
> An int won't work here because += and -= do not have the
> atomicity guarantees that atomic_add/atomic_sub do. In
> particular, this may cause an atomic_read on another CPU
> to give a bogus reading.

The point is that guaranteeing the atomicity of the increment or
decrement does not suffice to make the code race-free. In this case
the race arises from the fact that reading ->memory_allocated and
setting *->memory_pressure are separate operations. To make that code
work properly you need a lock. And once you have the lock an ordinary
int would suffice for ->memory_allocated.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-08-16 05:51    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean