linux-kernel - Re: [PATCH v3 7/9] KVM-GST: KVM Steal time accounting

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4E0D35E5.9080506@redhat.com>
Date:	Thu, 30 Jun 2011 23:50:13 -0300
From:	Glauber Costa <glommer@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
	Rik van Riel <riel@...hat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
	Avi Kivity <avi@...hat.com>,
	Anthony Liguori <aliguori@...ibm.com>,
	Eric B Munson <emunson@...bm.net>
Subject: Re: [PATCH v3 7/9] KVM-GST: KVM Steal time accounting

On 06/30/2011 06:54 PM, Peter Zijlstra wrote:
> On Wed, 2011-06-29 at 11:29 -0400, Glauber Costa wrote:
>> +static noinline bool touch_steal_time(int is_idle)
>
> That noinline is very unlucky there,
>
>> +{
>> +       u64 steal, st = 0;
>> +
>> +       if (static_branch(&paravirt_steal_enabled)) {
>> +
>> +               steal = paravirt_steal_clock(smp_processor_id());
>> +
>> +               steal -= this_rq()->prev_steal_time;
>> +
>> +               st = steal_ticks(steal);
>> +               this_rq()->prev_steal_time += st * TICK_NSEC;
>> +
>> +               if (is_idle || st == 0)
>> +                       return false;
>> +
>> +               account_steal_time(st);
>> +               return true;
>> +       }
>> +       return false;
>> +}
>> +
>>   static void update_rq_clock_task(struct rq *rq, s64 delta)
>>   {
>>          s64 irq_delta;
>> @@ -3716,6 +3760,9 @@ void account_user_time(struct task_struct *p,
>> cputime_t cputime,
>>          struct cpu_usage_stat *cpustat =&kstat_this_cpu.cpustat;
>>          cputime64_t tmp;
>>
>> +       if (touch_steal_time(0))
>> +               return;
>
> Means we have an unconditional call here, even if the static_branch() is
> patched out.
Ok.

I was under the impression that the proper use of jump labels required 
each label to be tied to a single location. If we make it inline, the 
same key would point to multiple locations, and we would have trouble
altering all of the locations. I might be wrong, of course. Isn't it the 
case?
--
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/