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: <1332892874.2882.66.camel@pasglop>
Date:	Wed, 28 Mar 2012 11:01:14 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Anton Vorontsov <anton.vorontsov@...aro.org>,
	Mike Frysinger <vapier@...too.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	user-mode-linux-devel@...ts.sourceforge.net,
	linux-sh@...r.kernel.org, Richard Weinberger <richard@....at>,
	linux-kernel@...r.kernel.org,
	uclinux-dist-devel@...ckfin.uclinux.org, linux-mm@...ck.org,
	Paul Mundt <lethal@...ux-sh.org>,
	John Stultz <john.stultz@...aro.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Russell King <linux@....linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linuxppc-dev@...ts.ozlabs.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2.1 01/10] cpu: Introduce clear_tasks_mm_cpumask()
 helper

On Sun, 2012-03-25 at 19:42 +0200, Oleg Nesterov wrote:
> > Also, Per Peter Zijlstra's idea, now we don't grab tasklist_lock in
> > the new helper, instead we take the rcu read lock. We can do this
> > because the function is called after the cpu is taken down and
> marked
> > offline, so no new tasks will get this cpu set in their mm mask.
> 
> And only powerpc needs rcu_read_lock() and task_lock().
> 
> OTOH, I do not understand why powepc does this on CPU_DEAD...
> And probably CPU_UP_CANCELED doesn't need to clear mm_cpumask().
> 
> That said, personally I think these patches are fine, the common
> helper makes sense. 

Not strictly speaking a problem with this patch, but I was wondering...

Do we know for sure that the mmu context has been fully flushed out
before the unplug ? idle_task_exit() will do a context switch but in our
case that may not be enough.

Once the CPU is offline, tlb flushes won't hit it any more so it can get
out of sync (in some cases the offlining process is just some kind of
deep sleep loop that doesn't involve a TLB state loss).

Should we add a flush_tlb_mm of all those bits in that loop ? that would
be a tad expensive... we don't have a flush_tlb_all() as a generic kind
of accessors, but we could add something like that as a requirement for
ppc_md.cpu_die ?

Cheers,
Ben.


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