From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752843AbbDQXky (ORCPT ); Fri, 17 Apr 2015 19:40:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51893 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751396AbbDQXkv (ORCPT ); Fri, 17 Apr 2015 19:40:51 -0400 Date: Fri, 17 Apr 2015 20:39:52 -0300 From: Marcelo Tosatti To: Andy Lutomirski Cc: Linus Torvalds , John Stultz , Paolo Bonzini , Peter Zijlstra , "linux-kernel@vger.kernel.org" , Gleb Natapov , kvm list , Ralf Baechle , Andrew Lutomirski Subject: Re: [GIT PULL] First batch of KVM changes for 4.1 Message-ID: <20150417233952.GB18714@amt.cnet> References: <20150417131037.GG23123@twins.programming.kicks-ass.net> <55310CF2.6070107@redhat.com> <20150417190146.GA24395@amt.cnet> <55316598.908@redhat.com> <20150417201841.GA31302@amt.cnet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 17, 2015 at 03:25:28PM -0700, Andy Lutomirski wrote: > On Fri, Apr 17, 2015 at 3:04 PM, Linus Torvalds > wrote: > > On Fri, Apr 17, 2015 at 5:42 PM, Andy Lutomirski wrote: > >> > >> Muahaha. The auditors have invaded your system. (I did my little > >> benchmark with a more sensible configuration -- see way below). > >> > >> Can you send the output of: > >> > >> # auditctl -s > >> # auditctl -l > > > > # auditctl -s > > enabled 1 > > flag 1 > > pid 822 > > rate_limit 0 > > backlog_limit 320 > > lost 0 > > backlog 0 > > backlog_wait_time 60000 > > loginuid_immutable 0 unlocked > > # auditctl -l > > No rules > > Yes, "No rules" doesn't mean "don't audit". > > > > >> Are you, perchance, using Fedora? > > > > F21. Yup. > > > > I used to just disable auditing in the kernel entirely, but then I > > ended up deciding that I need to run something closer to the broken > > Fedora config (selinux in particular) in order to actually optimize > > the real-world pathname handling situation rather than the _sane_ one. > > Oh well. I think audit support got enabled at the same time in my > > kernels because I ended up using the default config and then taking > > out the truly crazy stuff without noticing AUDITSYSCALL. > > > >> I lobbied rather heavily, and > >> successfully, to get the default configuration to stop auditing. > >> Unfortunately, the fix wasn't retroactive, so, unless you have a very > >> fresh install, you might want to apply the fix yourself: > > > > Is that fix happening in Fedora going forward, though? Like F22? > > It's in F21, actually. Unfortunately, the audit package is really > weird. It installs /etc/audit/rules.d/audit.rules, containing: > > # This file contains the auditctl rules that are loaded > # whenever the audit daemon is started via the initscripts. > # The rules are simply the parameters that would be passed > # to auditctl. > > # First rule - delete all > -D > > # This suppresses syscall auditing for all tasks started > # with this rule in effect. Remove it if you need syscall > # auditing. > -a task,never > > Then, if it's a fresh install (i.e. /etc/audit/audit.rules doesn't > exist) it copies that file to /etc/audit/audit.rules post-install. > (No, I don't know why it works this way.) > > IOW, you might want to copy your /etc/audit/rules.d/audit.rules to > /etc/audit/audit.rules. I think you need to reboot to get the full > effect. You could apply the rule manually (or maybe restart the audit > service), but it will only affect newly-started tasks. > > > > >> Amdy Lumirtowsky thinks he meant to attach a condition to his > >> maintainerish activities: he will do his best to keep the audit code > >> *out* of the low-level stuff, but he's going to try to avoid ever > >> touching the audit code itself, because if he ever had to change it, > >> he might accidentally delete the entire file. > > > > Oooh. That would be _such_ a shame. > > > > Can we please do it by mistake? "Oops, my fingers slipped" > > > >> Seriously, wasn't there a TAINT_PERFORMANCE thing proposed at some > >> point? I would love auditing to set some really loud global warning > >> that you've just done a Bad Thing (tm) performance-wise by enabling > >> it. > > > > Or even just a big fat warning in dmesg the first time auditing triggers. > > > >> Back to timing. With kvm-clock, I see: > >> > >> 23.80% timing_test_64 [kernel.kallsyms] [k] pvclock_clocksource_read > > > > Oh wow. How can that possibly be sane? > > > > Isn't the *whole* point of pvclock_clocksource_read() to be a native > > rdtsc with scaling? How does it cause that kind of insane pain? > > An unnecessarily complicated protocol, a buggy host implementation, > and an unnecessarily complicated guest implementation :( How about start by removing the unnecessary rdtsc-barrier?