Re: [PATCH] arc: use little endian accesses

2016-03-09 Thread Arnd Bergmann
On Thursday 10 March 2016, Vineet Gupta wrote: > On Wednesday 09 March 2016 10:51 PM, Lada Trimasova wrote: > > Memory access primitives should use cpu_to_le16, cpu_to_le32, le16_to_cpu > > and le32_to_cpu because it is not really guaranteed that drivers handles > > any ordering themselves. > > Th

Re: [PATCH] arc: use little endian accesses

2016-03-09 Thread Alexey Brodkin
Hi Vineet, On Thu, 2016-03-10 at 05:05 +, Vineet Gupta wrote: > +CC Noam > > On Wednesday 09 March 2016 10:51 PM, Lada Trimasova wrote: > > > > Memory access primitives should use cpu_to_le16, cpu_to_le32, le16_to_cpu > > and le32_to_cpu because it is not really guaranteed that drivers handl

Re: [PATCH] mm: slub: Ensure that slab_unlock() is atomic

2016-03-09 Thread Vineet Gupta
On Wednesday 09 March 2016 08:21 PM, Peter Zijlstra wrote: >> But in SLUB: bit_spin_lock() + __bit_spin_unlock() is acceptable ? How so >> (ignoring the performance thing for discussion sake, which is a side effect >> of >> this implementation). > > The sort answer is: Per definition. They are de

Re: [PATCH] arc: use little endian accesses

2016-03-09 Thread Vineet Gupta
On Thursday 10 March 2016 10:35 AM, Vineet Gupta wrote: > +CC Noam > > On Wednesday 09 March 2016 10:51 PM, Lada Trimasova wrote: >> > Memory access primitives should use cpu_to_le16, cpu_to_le32, le16_to_cpu >> > and le32_to_cpu because it is not really guaranteed that drivers handles >> > any ord

Re: [PATCH] arc: use little endian accesses

2016-03-09 Thread Vineet Gupta
+CC Noam On Wednesday 09 March 2016 10:51 PM, Lada Trimasova wrote: > Memory access primitives should use cpu_to_le16, cpu_to_le32, le16_to_cpu > and le32_to_cpu because it is not really guaranteed that drivers handles > any ordering themselves. That is the driver issue. readxx as API simply retu

[PATCH] arc: use little endian accesses

2016-03-09 Thread Lada Trimasova
Memory access primitives should use cpu_to_le16, cpu_to_le32, le16_to_cpu and le32_to_cpu because it is not really guaranteed that drivers handles any ordering themselves. For example, serial port driver doesn't work when kernel is build for arc big endian architecture. Signed-off-by: Lada Trimaso

Re: [PATCH] mm: slub: Ensure that slab_unlock() is atomic

2016-03-09 Thread Peter Zijlstra
On Wed, Mar 09, 2016 at 06:52:45PM +0530, Vineet Gupta wrote: > On Wednesday 09 March 2016 03:43 PM, Peter Zijlstra wrote: > >> There is clearly a problem in slub code that it is pairing a > >> test_and_set_bit() > >> with a __clear_bit(). Latter can obviously clobber former if they are not > >>

Re: [PATCH] mm: slub: Ensure that slab_unlock() is atomic

2016-03-09 Thread Vineet Gupta
On Wednesday 09 March 2016 03:43 PM, Peter Zijlstra wrote: >> There is clearly a problem in slub code that it is pairing a >> test_and_set_bit() >> with a __clear_bit(). Latter can obviously clobber former if they are not a >> single >> instruction each unlike x86 or they use llock/scond kind of

Re: [PATCH] mm: slub: Ensure that slab_unlock() is atomic

2016-03-09 Thread Peter Zijlstra
On Wed, Mar 09, 2016 at 05:23:26PM +0530, Vineet Gupta wrote: > > I did not follow through the maze, I think the few archs implementing > > this simply do not include this file at all. > > > > I'll let the first person that cares about this worry about that :-) > > Ok - that's be me :-) although

Re: [PATCH] mm: slub: Ensure that slab_unlock() is atomic

2016-03-09 Thread Vineet Gupta
On Wednesday 09 March 2016 05:10 PM, Peter Zijlstra wrote: > On Wed, Mar 09, 2016 at 04:30:31PM +0530, Vineet Gupta wrote: >> FWIW, could we add some background to commit log, specifically what prompted >> this. >> Something like below... > > Sure.. find below. > >>> +++ b/include/asm-generic/bi

Re: [PATCH] mm: slub: Ensure that slab_unlock() is atomic

2016-03-09 Thread Peter Zijlstra
On Wed, Mar 09, 2016 at 04:30:31PM +0530, Vineet Gupta wrote: > FWIW, could we add some background to commit log, specifically what prompted > this. > Something like below... Sure.. find below. > > +++ b/include/asm-generic/bitops/lock.h > > @@ -29,16 +29,16 @@ do {

Re: [PATCH] mm: slub: Ensure that slab_unlock() is atomic

2016-03-09 Thread Vineet Gupta
On Wednesday 09 March 2016 04:01 PM, Peter Zijlstra wrote: > On Wed, Mar 09, 2016 at 11:13:49AM +0100, Peter Zijlstra wrote: >> --- >> Subject: bitops: Do not default to __clear_bit() for __clear_bit_unlock() >> >> __clear_bit_unlock() is a special little snowflake. While it carries the >> non-atom

Re: [PATCH] mm: slub: Ensure that slab_unlock() is atomic

2016-03-09 Thread Vineet Gupta
On Wednesday 09 March 2016 03:43 PM, Peter Zijlstra wrote: >>> If you take the lock in __bit_spin_unlock >>> then the race cannot happen. >> >> Of course it won't but that means we penalize all non atomic callers of the >> API >> with a superfluous spinlock which is not require din first place giv

Re: [PATCH] mm: slub: Ensure that slab_unlock() is atomic

2016-03-09 Thread Peter Zijlstra
On Wed, Mar 09, 2016 at 11:13:49AM +0100, Peter Zijlstra wrote: > --- > Subject: bitops: Do not default to __clear_bit() for __clear_bit_unlock() > > __clear_bit_unlock() is a special little snowflake. While it carries the > non-atomic '__' prefix, it is specifically documented to pair with > test

Re: [PATCH] mm: slub: Ensure that slab_unlock() is atomic

2016-03-09 Thread Peter Zijlstra
On Wed, Mar 09, 2016 at 12:13:16PM +0530, Vineet Gupta wrote: > +CC linux-arch, parisc folks, PeterZ > > On Wednesday 09 March 2016 02:10 AM, Christoph Lameter wrote: > > On Tue, 8 Mar 2016, Vineet Gupta wrote: > > > >> # set the bit > >> 80543b8e: ld_s r2,[r13,0] <--- (A) Finds PG_locked