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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 1 Sep 2011 10:37:44 +0800
From:	Yong Zhang <yong.zhang0@...il.com>
To:	Shan Hai <haishan.bai@...il.com>
Cc:	akpm@...ux-foundation.org, eric.dumazet@...il.com,
	vapier@...too.org, asharma@...com, linux-kernel@...r.kernel.org,
	linux-rt-users@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 1/1 -rt] lib:atomic64 using
 raw_spin_lock_irq[save|resotre] for atomicity

On Thu, Sep 01, 2011 at 09:28:00AM +0800, Shan Hai wrote:
> The spin_lock_irq[save|restore] could break the atomicity of the
> atomic64_* operations in the PREEMPT-RT configuration, because
> the spin_lock_irq[save|restore] themselves are preemptable in the
> PREEMPT-RT, using raw variant of the spin lock could provide the
> atomicity that atomic64_* need.
> 
> Signed-off-by: Shan Hai <haishan.bai@...il.com>

I think you could show your panic info also in the header.

And this should be routed to tglx(Cc'ing), and also to
linux-rt-users.

comments below:

> ---
>  lib/atomic64.c |   40 ++++++++++++++++++++--------------------
>  1 files changed, 20 insertions(+), 20 deletions(-)
> 
> diff --git a/lib/atomic64.c b/lib/atomic64.c
> index e12ae0d..26f524a 100644
> --- a/lib/atomic64.c
> +++ b/lib/atomic64.c
> @@ -48,9 +48,9 @@ long long atomic64_read(const atomic64_t *v)
>  	spinlock_t *lock = lock_addr(v);
>  	long long val;
>  
> -	spin_lock_irqsave(lock, flags);
> +	raw_spin_lock_irqsave(lock, flags);
>  	val = v->counter;
> -	spin_unlock_irqrestore(lock, flags);
> +	raw_spin_unlock_irqrestore(lock, flags);

I think this is indeed a problem;
but I don't see you touch the declaration and initialising of the lock,
why?

Thanks,
Yong

>  	return val;
>  }
>  EXPORT_SYMBOL(atomic64_read);
> @@ -60,9 +60,9 @@ void atomic64_set(atomic64_t *v, long long i)
>  	unsigned long flags;
>  	spinlock_t *lock = lock_addr(v);
>  
> -	spin_lock_irqsave(lock, flags);
> +	raw_spin_lock_irqsave(lock, flags);
>  	v->counter = i;
> -	spin_unlock_irqrestore(lock, flags);
> +	raw_spin_unlock_irqrestore(lock, flags);
>  }
>  EXPORT_SYMBOL(atomic64_set);
>  
> @@ -71,9 +71,9 @@ void atomic64_add(long long a, atomic64_t *v)
>  	unsigned long flags;
>  	spinlock_t *lock = lock_addr(v);
>  
> -	spin_lock_irqsave(lock, flags);
> +	raw_spin_lock_irqsave(lock, flags);
>  	v->counter += a;
> -	spin_unlock_irqrestore(lock, flags);
> +	raw_spin_unlock_irqrestore(lock, flags);
>  }
>  EXPORT_SYMBOL(atomic64_add);
>  
> @@ -83,9 +83,9 @@ long long atomic64_add_return(long long a, atomic64_t *v)
>  	spinlock_t *lock = lock_addr(v);
>  	long long val;
>  
> -	spin_lock_irqsave(lock, flags);
> +	raw_spin_lock_irqsave(lock, flags);
>  	val = v->counter += a;
> -	spin_unlock_irqrestore(lock, flags);
> +	raw_spin_unlock_irqrestore(lock, flags);
>  	return val;
>  }
>  EXPORT_SYMBOL(atomic64_add_return);
> @@ -95,9 +95,9 @@ void atomic64_sub(long long a, atomic64_t *v)
>  	unsigned long flags;
>  	spinlock_t *lock = lock_addr(v);
>  
> -	spin_lock_irqsave(lock, flags);
> +	raw_spin_lock_irqsave(lock, flags);
>  	v->counter -= a;
> -	spin_unlock_irqrestore(lock, flags);
> +	raw_spin_unlock_irqrestore(lock, flags);
>  }
>  EXPORT_SYMBOL(atomic64_sub);
>  
> @@ -107,9 +107,9 @@ long long atomic64_sub_return(long long a, atomic64_t *v)
>  	spinlock_t *lock = lock_addr(v);
>  	long long val;
>  
> -	spin_lock_irqsave(lock, flags);
> +	raw_spin_lock_irqsave(lock, flags);
>  	val = v->counter -= a;
> -	spin_unlock_irqrestore(lock, flags);
> +	raw_spin_unlock_irqrestore(lock, flags);
>  	return val;
>  }
>  EXPORT_SYMBOL(atomic64_sub_return);
> @@ -120,11 +120,11 @@ long long atomic64_dec_if_positive(atomic64_t *v)
>  	spinlock_t *lock = lock_addr(v);
>  	long long val;
>  
> -	spin_lock_irqsave(lock, flags);
> +	raw_spin_lock_irqsave(lock, flags);
>  	val = v->counter - 1;
>  	if (val >= 0)
>  		v->counter = val;
> -	spin_unlock_irqrestore(lock, flags);
> +	raw_spin_unlock_irqrestore(lock, flags);
>  	return val;
>  }
>  EXPORT_SYMBOL(atomic64_dec_if_positive);
> @@ -135,11 +135,11 @@ long long atomic64_cmpxchg(atomic64_t *v, long long o, long long n)
>  	spinlock_t *lock = lock_addr(v);
>  	long long val;
>  
> -	spin_lock_irqsave(lock, flags);
> +	raw_spin_lock_irqsave(lock, flags);
>  	val = v->counter;
>  	if (val == o)
>  		v->counter = n;
> -	spin_unlock_irqrestore(lock, flags);
> +	raw_spin_unlock_irqrestore(lock, flags);
>  	return val;
>  }
>  EXPORT_SYMBOL(atomic64_cmpxchg);
> @@ -150,10 +150,10 @@ long long atomic64_xchg(atomic64_t *v, long long new)
>  	spinlock_t *lock = lock_addr(v);
>  	long long val;
>  
> -	spin_lock_irqsave(lock, flags);
> +	raw_spin_lock_irqsave(lock, flags);
>  	val = v->counter;
>  	v->counter = new;
> -	spin_unlock_irqrestore(lock, flags);
> +	raw_spin_unlock_irqrestore(lock, flags);
>  	return val;
>  }
>  EXPORT_SYMBOL(atomic64_xchg);
> @@ -164,12 +164,12 @@ int atomic64_add_unless(atomic64_t *v, long long a, long long u)
>  	spinlock_t *lock = lock_addr(v);
>  	int ret = 0;
>  
> -	spin_lock_irqsave(lock, flags);
> +	raw_spin_lock_irqsave(lock, flags);
>  	if (v->counter != u) {
>  		v->counter += a;
>  		ret = 1;
>  	}
> -	spin_unlock_irqrestore(lock, flags);
> +	raw_spin_unlock_irqrestore(lock, flags);
>  	return ret;
>  }
>  EXPORT_SYMBOL(atomic64_add_unless);
> -- 
> 1.7.4.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Only stand for myself
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ