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.
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
