lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 16 Aug 2007 08:03:11 +0530 (IST) From: Satyam Sharma <satyam@...radead.org> To: Paul Mackerras <paulus@...ba.org> cc: Herbert Xu <herbert@...dor.apana.org.au>, Christoph Lameter <clameter@....com>, "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>, Stefan Richter <stefanr@...6.in-berlin.de>, Chris Snook <csnook@...hat.com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, linux-arch@...r.kernel.org, Linus Torvalds <torvalds@...ux-foundation.org>, netdev@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>, ak@...e.de, heiko.carstens@...ibm.com, davem@...emloft.net, schwidefsky@...ibm.com, wensong@...ux-vs.org, horms@...ge.net.au, wjiang@...ilience.com, cfriesen@...tel.com, zlynx@....org, rpjday@...dspring.com, jesper.juhl@...il.com, segher@...nel.crashing.org Subject: Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures On Thu, 16 Aug 2007, Paul Mackerras wrote: > Herbert Xu writes: > > > See sk_stream_mem_schedule in net/core/stream.c: > > > > /* Under limit. */ > > if (atomic_read(sk->sk_prot->memory_allocated) < sk->sk_prot->sysctl_mem[0]) { > > if (*sk->sk_prot->memory_pressure) > > *sk->sk_prot->memory_pressure = 0; > > return 1; > > } > > > > /* Over hard limit. */ > > if (atomic_read(sk->sk_prot->memory_allocated) > sk->sk_prot->sysctl_mem[2]) { > > sk->sk_prot->enter_memory_pressure(); > > goto suppress_allocation; > > } > > > > We don't need to reload sk->sk_prot->memory_allocated here. > > Are you sure? How do you know some other CPU hasn't changed the value > in between? I can't speak for this particular case, but there could be similar code examples elsewhere, where we do the atomic ops on an atomic_t object inside a higher-level locking scheme that would take care of the kind of problem you're referring to here. It would be useful for such or similar code if the compiler kept the value of that atomic object in a register. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists