linux-kernel - Re: [PATCH 3/5] writeback: fix dirtied pages accounting on sub-page writes

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:	Tue, 22 Nov 2011 14:53:19 +0100
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Wu Fengguang <fengguang.wu@...el.com>
Cc:	Jan Kara <jack@...e.cz>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	Christoph Hellwig <hch@....de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	paulmck <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCH 3/5] writeback: fix dirtied pages accounting on sub-page
 writes

On Tue, 2011-11-22 at 21:41 +0800, Wu Fengguang wrote:
> On Tue, Nov 22, 2011 at 09:07:50PM +0800, Wu Fengguang wrote:
> > On Tue, Nov 22, 2011 at 08:57:42PM +0800, Peter Zijlstra wrote:
> > > On Tue, 2011-11-22 at 13:21 +0100, Jan Kara wrote:
> > > > > +             __get_cpu_var(bdp_ratelimits)++;
> > > >   I think you need preempt_disable() and preempt_enable() pair around
> > > > __get_cpu_var(). Otherwise a process could get rescheduled in the middle of
> > > > read-modify-write cycle... 
> > > 
> > > there's of course the this_cpu_inc(bdp_ratelimits); thing.
> > > 
> > > On x86 that'll turn into a single insn, on others it will add the
> > > required preempt_disable/enable bits.
> > 
> > It's good to know that. But what if we don't really care which CPU
> > data it's increasing, and can accept losing some increases due to the
> > resulted race condition?
> 
> I just added a comment for it, hope it helps :)
> 
>                 /*
>                  * This is racy, however bdp_ratelimits merely serves as a
>                  * gross safeguard. We don't really care the exact CPU it's
>                  * charging to and the resulted inaccuracy is acceptable.
>                  */
>                 __get_cpu_var(bdp_ratelimits)++;

Thing is, I'm not sure how much update you can effectively wreck by
interleaving the RmW cycles of two CPUs like this.

Simply loosing a few increments would be fine, but what are the
practical implications of actually relying on this behaviour and how do
various architectures cope.


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