From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3rmND81b5mzDqpH for ; Sat, 9 Jul 2016 04:23:52 +1000 (AEST) Received: by mail-wm0-x242.google.com with SMTP id x83so8150354wma.3 for ; Fri, 08 Jul 2016 11:23:51 -0700 (PDT) Sender: Ingo Molnar Date: Fri, 8 Jul 2016 20:23:44 +0200 From: Ingo Molnar To: Linus Torvalds Cc: Kees Cook , Linux Kernel Mailing List , Rik van Riel , Casey Schaufler , PaX Team , Brad Spengler , Russell King , Catalin Marinas , Will Deacon , Ard Biesheuvel , Benjamin Herrenschmidt , Michael Ellerman , Tony Luck , Fenghua Yu , "David S. Miller" , the arch/x86 maintainers , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Andy Lutomirski , Borislav Petkov , Mathias Krause , Jan Kara , Vitaly Wool , Andrea Arcangeli , Dmitry Vyukov , Laura Abbott , "linux-arm-kernel@lists.infradead.org" , "linux-ia64@vger.kernel.org" , ppc-dev , sparclinux@vger.kernel.org, "linux-arch@vger.kernel.org" , linux-mm , "kernel-hardening@lists.openwall.com" , Thomas Gleixner , "H. Peter Anvin" , Peter Zijlstra Subject: Re: [PATCH 0/9] mm: Hardened usercopy Message-ID: <20160708182344.GC4429@gmail.com> References: <1467843928-29351-1-git-send-email-keescook@chromium.org> <20160708084639.GA4562@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , * Linus Torvalds wrote: > On Fri, Jul 8, 2016 at 1:46 AM, Ingo Molnar wrote: > > > > Could you please try to find some syscall workload that does many small user > > copies and thus excercises this code path aggressively? > > Any stat()-heavy path will hit cp_new_stat() very heavily. Think the > usual kind of "traverse the whole tree looking for something". "git > diff" will do it, just checking that everything is up-to-date. > > That said, other things tend to dominate. So I think a cached 'find /usr >/dev/null' might be a good one as well: triton:~/tip> strace -c find /usr >/dev/null % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 47.09 0.006518 0 254697 newfstatat 26.20 0.003627 0 254795 getdents 14.45 0.002000 0 1147411 fcntl 7.33 0.001014 0 509811 close 3.28 0.000454 0 128220 1 openat 1.52 0.000210 0 128230 fstat 0.27 0.000016 0 12810 write 0.00 0.000000 0 10 read triton:~/tip> perf stat --repeat 3 -e cycles:u,cycles:k,cycles find /usr >/dev/null Performance counter stats for 'find /usr' (3 runs): 1,594,437,143 cycles:u ( +- 2.76% ) 2,570,544,009 cycles:k ( +- 2.50% ) 4,164,981,152 cycles ( +- 2.59% ) 0.929883686 seconds time elapsed ( +- 2.57% ) ... and it's dominated by kernel overhead, with a fair amount of memcpy overhead as well: 1.22% find [kernel.kallsyms] [k] copy_user_enhanced_fast_string But maybe there are simple shell commands that are even more user-memcpy intense? Thanks, Ingo