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:	Sat, 21 Apr 2007 21:30:25 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	miklos@...redi.hu, neilb@...e.de, dgc@....com,
	tomoki.sekiyama.qu@...achi.com, nikita@...sterfs.com,
	trond.myklebust@....uio.no, yingchao.zhou@...il.com
Subject: Re: [PATCH 04/10] lib: percpu_counter_mod64

On Sat, 2007-04-21 at 12:21 -0700, Andrew Morton wrote:
> On Sat, 21 Apr 2007 13:02:26 +0200 Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
> 
> > > > +	cpu = get_cpu();
> > > > +	pcount = per_cpu_ptr(fbc->counters, cpu);
> > > > +	count = *pcount + amount;
> > > > +	if (count >= FBC_BATCH || count <= -FBC_BATCH) {
> > > > +		spin_lock(&fbc->lock);
> > > > +		fbc->count += count;
> > > > +		*pcount = 0;
> > > > +		spin_unlock(&fbc->lock);
> > > > +	} else {
> > > > +		*pcount = count;
> > > > +	}
> > > > +	put_cpu();
> > > > +}
> > > > +EXPORT_SYMBOL(percpu_counter_mod64);
> > > 
> > > Bloaty.  Surely we won't be needing this on 32-bit kernels?  Even monster
> > > PAE has only 64,000,000 pages and won't be using deltas of more than 4
> > > gigapages?
> > > 
> > > <Does even 64-bit need to handle 4 gigapages in a single hit?  /me suspects
> > > another changelog bug>
> > 
> > Yeah, /me chastises himself for that...
> > 
> > This is because percpu_counter is s64 instead of the native long; I need
> > to halve the counter at some point (bdi_writeout_norm) and do that by
> > subtracting half the current value.
> 
> ah, the mysterious bdi_writeout_norm().
> 
> I don't think it's possible to precisely halve a percpu_counter - there has
> to be some error involved.  I guess that's acceptable within the
> inscrutable bdi_writeout_norm().
> 
> otoh, there's a chance that the attempt to halve the counter will take the
> counter negative, due to races.  Does the elusive bdi_writeout_norm()
> handle that?  If not, it should.  If it does, then there should be comments
> around the places where this is being handled, because it is subtle, and unobvious,
> and others might break it by accident.

The counter it is halving is only ever incremented, so we might be off a
little, but only to the safe side.

I shall do the comment thing along with all the other missing
comments :-)

-
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