linux-kernel - Re: [PATCH v2 1/3] zsmalloc: support zsmalloc to ARM, MIPS, SUPERH

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: <20120517083213.GC14027@linux-sh.org>
Date:	Thu, 17 May 2012 17:32:13 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Minchan Kim <minchan@...nel.org>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Nitin Gupta <ngupta@...are.org>,
	Seth Jennings <sjenning@...ux.vnet.ibm.com>,
	Dan Magenheimer <dan.magenheimer@...cle.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Russell King <linux@....linux.org.uk>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Guan Xuetao <gxt@...c.pku.edu.cn>,
	Chen Liqin <liqin.chen@...plusct.com>
Subject: Re: [PATCH v2 1/3] zsmalloc: support zsmalloc to ARM, MIPS, SUPERH

On Wed, May 16, 2012 at 11:05:17AM +0900, Minchan Kim wrote:
> About local_flush_tlb_kernel_range,
> If architecture is very smart, it could flush only tlb entries related to vaddr.
> If architecture is smart, it could flush only tlb entries related to a CPU.
> If architecture is _NOT_ smart, it could flush all entries of all CPUs.
> So, it would be best to support both portability and performance.
> 
..

> Need double check about supporting local_flush_tlb_kernel_range
> in ARM, MIPS, SUPERH maintainers. And I will Ccing unicore32 and
> score maintainers because arch directory in those arch have
> local_flush_tlb_kernel_range, too but I'm very unfamiliar with those
> architecture so pass it to maintainers.
> I didn't coded up dumb local_flush_tlb_kernel_range which flush
> all cpus. I expect someone need ZSMALLOC will implement it easily in future.
> 

One thing you might consider is providing a stubbed definition that wraps
to flush_tlb_kernel_range() in the !SMP case, as this will extend your
testing coverage for staging considerably.

Once you exclude all of the non-SMP platforms, you're left with the
following:

	- blackfin: doesn't count, no TLB to worry about.
	- hexagon: seems to imply that the SMP case uses thread-based
	  CPUs that share an MMU, so no additional cost.
	- ia64: Does a global flush, which already has a FIXME comment.
	- m32r, mn10300: local_flush_tlb_all() could be wrapped.
	- parisc: global flush?
	- s390: Tests the cpumask to do a local flush, otherwise has a
	  __tlb_flush_local() that can be wrapped.
	- sparc32: global flush
	- sparc64: __flush_tlb_kernel_range() looks like a local flush.
	- tile: does strange hypervisory things, presumably global.
	- x86: has a local_flush_tlb() that could be wrapped.

Which doesn't look quite that bad. You could probably get away with a
Kconfig option for optimized local TLB flushing or something, since
single function Kconfig options seem to be all the rage these days.
--
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/