linux-stable.git/arch/parisc/include/asm/atomic.h, branch linux-4.4.y

parisc: Add atomic64_set_release() define to avoid CPU soft lockups

2020-07-31T14:43:15+00:00

commit be6577af0cef934ccb036445314072e8cb9217b9 upstream.

Stalls are quite frequent with recent kernels. I enabled
CONFIG_SOFTLOCKUP_DETECTOR and I caught the following stall:

watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [cc1:22803]
CPU: 0 PID: 22803 Comm: cc1 Not tainted 5.6.17+ #3
Hardware name: 9000/800/rp3440
 IAOQ[0]: d_alloc_parallel+0x384/0x688
 IAOQ[1]: d_alloc_parallel+0x388/0x688
 RP(r2): d_alloc_parallel+0x134/0x688
Backtrace:
 [<000000004036974c>] __lookup_slow+0xa4/0x200
 [<0000000040369fc8>] walk_component+0x288/0x458
 [<000000004036a9a0>] path_lookupat+0x88/0x198
 [<000000004036e748>] filename_lookup+0xa0/0x168
 [<000000004036e95c>] user_path_at_empty+0x64/0x80
 [<000000004035d93c>] vfs_statx+0x104/0x158
 [<000000004035dfcc>] __do_sys_lstat64+0x44/0x80
 [<000000004035e5a0>] sys_lstat64+0x20/0x38
 [<0000000040180054>] syscall_exit+0x0/0x14

The code was stuck in this loop in d_alloc_parallel:

    4037d414:   0e 00 10 dc     ldd 0(r16),ret0
    4037d418:   c7 fc 5f ed     bb,< ret0,1f,4037d414 
    4037d41c:   08 00 02 40     nop

This is the inner loop of bit_spin_lock which is called by hlist_bl_unlock in
d_alloc_parallel:

static inline void bit_spin_lock(int bitnum, unsigned long *addr)
{
        /*
         * Assuming the lock is uncontended, this never enters
         * the body of the outer loop. If it is contended, then
         * within the inner loop a non-atomic test is used to
         * busywait with less bus contention for a good time to
         * attempt to acquire the lock bit.
         */
        preempt_disable();
#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK)
        while (unlikely(test_and_set_bit_lock(bitnum, addr))) {
                preempt_enable();
                do {
                        cpu_relax();
                } while (test_bit(bitnum, addr));
                preempt_disable();
        }
#endif
        __acquire(bitlock);
}

After consideration, I realized that we must be losing bit unlocks.
Then, I noticed that we missed defining atomic64_set_release().
Adding this define fixes the stalls in bit operations.

Signed-off-by: Dave Anglin 
Cc: stable@vger.kernel.org
Signed-off-by: Helge Deller 
Signed-off-by: Greg Kroah-Hartman

atomic, arch: Audit atomic_{read,set}()

2015-09-23T07:54:28+00:00

This patch makes sure that atomic_{read,set}() are at least
{READ,WRITE}_ONCE().

We already had the 'requirement' that atomic_read() should use
ACCESS_ONCE(), and most archs had this, but a few were lacking.
All are now converted to use READ_ONCE().

And, by a symmetry and general paranoia argument, upgrade atomic_set()
to use WRITE_ONCE().

Signed-off-by: Peter Zijlstra (Intel) 
Cc: Andrew Morton 
Cc: Dmitry Vyukov 
Cc: Linus Torvalds 
Cc: Paul E. McKenney 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: james.hogan@imgtec.com
Cc: linux-kernel@vger.kernel.org
Cc: oleg@redhat.com
Cc: will.deacon@arm.com
Signed-off-by: Ingo Molnar

atomic: Provide atomic_{or,xor,and}

2015-07-27T12:06:24+00:00

Implement atomic logic ops -- atomic_{or,xor,and}.

These will replace the atomic_{set,clear}_mask functions that are
available on some archs.

Signed-off-by: Peter Zijlstra (Intel) 
Signed-off-by: Thomas Gleixner

parisc: Provide atomic_{or,xor,and}

2015-07-27T12:06:23+00:00

Implement atomic logic ops -- atomic_{or,xor,and}.

These will replace the atomic_{set,clear}_mask functions that are
available on some archs.

Signed-off-by: Peter Zijlstra (Intel) 
Signed-off-by: Thomas Gleixner

locking,arch: Use ACCESS_ONCE() instead of cast to volatile in atomic_read()

2014-10-03T04:06:23+00:00

Use the much more reader friendly ACCESS_ONCE() instead of the cast to volatile.
This is purely a stylistic change.

Signed-off-by: Pranith Kumar 
Acked-by: Jesper Nilsson 
Acked-by: Hans-Christian Egtvedt 
Acked-by: Max Filippov 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Linus Torvalds 
Cc: linux-arch@vger.kernel.org
Link: http://lkml.kernel.org/r/1411482607-20948-1-git-send-email-bobby.prani@gmail.com
Signed-off-by: Ingo Molnar

locking,arch,parisc: Fold atomic_ops

2014-08-14T10:48:11+00:00

OK, no LoC saved in this case because sub was defined in terms of add.
Still do it because this also prepares for easy addition of new ops.

Signed-off-by: Peter Zijlstra 
Cc: Helge Deller 
Cc: James E.J. Bottomley 
Cc: Linus Torvalds 
Cc: Paul E. McKenney 
Cc: linux-parisc@vger.kernel.org
Link: http://lkml.kernel.org/r/20140508135852.659342353@infradead.org
Signed-off-by: Ingo Molnar

arch,parisc: Convert smp_mb__*()

2014-04-18T12:20:41+00:00

parisc fully relies on asm-generic/barrier.h, therefore its smp_mb()
is barrier and the default implementation suffices.

Signed-off-by: Peter Zijlstra 
Acked-by: Paul E. McKenney 
Link: http://lkml.kernel.org/n/tip-mxs4aubiyesi79v8xx53093q@git.kernel.org
Cc: Helge Deller 
Cc: James E.J. Bottomley 
Cc: Linus Torvalds 
Cc: linux-kernel@vger.kernel.org
Cc: linux-parisc@vger.kernel.org
Signed-off-by: Ingo Molnar

parisc: implement atomic64_dec_if_positive()

2013-05-06T21:10:04+00:00

Signed-off-by: Helge Deller

parisc: fix compile warnings triggered by atomic_sub(sizeof(),v)

2013-03-02T19:01:05+00:00

This fixes compile warnings like this one:
net/ipv4/igmp.c: In function ‘ip_mc_leave_group’:
net/ipv4/igmp.c:1898:3: warning: overflow in implicit constant conversion [-Woverflow]

atomic_sub() is defined as __atomic_add_return(-(VAL),(v))))
and if VAL is of type unsigned int (as returned by sizeof()), negating
this value will overflow. Fix this by type-casting VAL to int type.

Signed-off-by: Helge Deller

[PARISC] Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts

2012-07-25T05:08:46+00:00

The following build error occured during a parisc build with
swap-over-NFS patches applied.

net/core/sock.c:274:36: error: initializer element is not constant
net/core/sock.c:274:36: error: (near initialization for 'memalloc_socks')
net/core/sock.c:274:36: error: initializer element is not constant

Dave Anglin says:
> Here is the line in sock.i:
>
> struct static_key memalloc_socks = ((struct static_key) { .enabled =
> ((atomic_t) { (0) }) });

The above line contains two compound literals.  It also uses a designated
initializer to initialize the field enabled.  A compound literal is not a
constant expression.

The location of the above statement isn't fully clear, but if a compound
literal occurs outside the body of a function, the initializer list must
consist of constant expressions.

Reported-by: Fengguang Wu 
Signed-off-by: Mel Gorman 
Cc: 
Signed-off-by: James Bottomley