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: <1299241020.2428.13504.camel@twins>
Date:	Fri, 04 Mar 2011 13:17:00 +0100
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Guan Xuetao <gxt@...c.pku.edu.cn>
Cc:	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	linux-mm@...ck.org,
	'Benjamin Herrenschmidt' <benh@...nel.crashing.org>,
	'David Miller' <davem@...emloft.net>,
	'Hugh Dickins' <hugh.dickins@...cali.co.uk>,
	'Mel Gorman' <mel@....ul.ie>,
	'Nick Piggin' <npiggin@...nel.dk>,
	'Paul McKenney' <paulmck@...ux.vnet.ibm.com>,
	'Yanmin Zhang' <yanmin_zhang@...ux.intel.com>,
	'Andrea Arcangeli' <aarcange@...hat.com>,
	'Avi Kivity' <avi@...hat.com>,
	'Thomas Gleixner' <tglx@...utronix.de>,
	'Rik van Riel' <riel@...hat.com>,
	'Ingo Molnar' <mingo@...e.hu>, akpm@...ux-foundation.org,
	'Linus Torvalds' <torvalds@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>
Subject: RE: [PATCH 09/13] unicore: mmu_gather rework

On Fri, 2011-03-04 at 19:56 +0800, Guan Xuetao wrote:

> Thanks Peter.
> It looks good to me, though it is dependent on your patch set "mm: Preemptible mmu_gather"

It is indeed, the split-out per arch is purely to ease review. The final
commit should be a merge of the first 10 patches so as not to break
bisection.

> While I have another look to include/asm-generic/tlb.h, I found it is also suitable for unicore32.
> And so, I rewrite the tlb.h to use asm-generic version, and then your patch set will also work for me.

Awesome, I notice you're loosing flush_tlb_range() support for this, if
you're fine with that I'm obviously not going to argue, but if its
better for your platform to keep doing this we can work on that as well
as I'm trying to add generic support for range tracking into the generic
tlb code.

More importantly, you seem to loose your call to flush_cache_range()
which isn't a NOP on your platform.

Furthermore, while arch/unicore32/mm/tlb-ucv2.S is mostly magic to me, I
see unicore32 is one of the few architectures that actually uses
vm_flags in flush_tlb_range(). Do you have independent I/D-TLB flushes
or are you flushing I-cache on VM_EXEC?

Also, I notice your flush_tlb_range() implementation looks to be a loop
invalidating individual pages, which I can imagine is cheaper for small
ranges but large ranges might be better of with a full invalidate. Did
you think about this?



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