linux-kernel - Re: [patch v2 3/4] percpu_counter: fix code for 32bit systems

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]

Message-ID: <20110413190411.GC3987@mtj.dyndns.org>
Date:	Thu, 14 Apr 2011 04:04:11 +0900
From:	Tejun Heo <tj@...nel.org>
To:	shaohua.li@...el.com
Cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	cl@...ux.com, eric.dumazet@...il.com
Subject: Re: [patch v2 3/4] percpu_counter: fix code for 32bit systems

On Wed, Apr 13, 2011 at 03:57:18PM +0800, shaohua.li@...el.com wrote:
>  static inline s64 percpu_counter_read(struct percpu_counter *fbc)
>  {
> +#if BITS_PER_LONG == 32
> +	s64 count;
> +	unsigned long flags;
> +	spin_lock_irqsave(&fbc->lock, flags);
> +	count = fbc->count;
> +	spin_unlock_irqrestore(&fbc->lock, flags);
> +	return count;
> +#else
>  	return fbc->count;
> +#endif

I don't think this is safe.  The possible deadlock scenario was
percpu_counter_read() being called from irq context and adding irq
locking to percpu_counter_read() doesn't change that in any way.  You
should be changing locking in other places.  Given that the next patch
would make this dancing with locks all pointless, my suggestion is to
drop this patch and proceed with atomic64_t conversion directly and
note that the conversion also removes possible 32bit deviation on
32bit archs.

Thanks.

-- 
tejun
--
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/