From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756078AbcGHSYi (ORCPT ); Fri, 8 Jul 2016 14:24:38 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:34591 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755769AbcGHSYa (ORCPT ); Fri, 8 Jul 2016 14:24:30 -0400 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 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * 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