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: <f98879dc24f948f7a8a7b5374a32bc04@kernel.org>
Date: Wed, 20 Dec 2023 09:00:48 +0000
From: Marc Zyngier <maz@...nel.org>
To: Haibo Xu <xiaobo55x@...il.com>
Cc: Haibo Xu <haibo1.xu@...el.com>, ajones@...tanamicro.com, Paul Walmsley
 <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>, Albert Ou
 <aou@...s.berkeley.edu>, Paolo Bonzini <pbonzini@...hat.com>, Shuah Khan
 <shuah@...nel.org>, Oliver Upton <oliver.upton@...ux.dev>, James Morse
 <james.morse@....com>, Suzuki K Poulose <suzuki.poulose@....com>, Zenghui Yu
 <yuzenghui@...wei.com>, Anup Patel <anup@...infault.org>, Atish Patra
 <atishp@...shpatra.org>, Guo Ren <guoren@...nel.org>, Mayuresh Chitale
 <mchitale@...tanamicro.com>, Greentime Hu <greentime.hu@...ive.com>, wchen
 <waylingii@...il.com>, Conor Dooley <conor.dooley@...rochip.com>, Heiko
 Stuebner <heiko@...ech.de>, Minda Chen <minda.chen@...rfivetech.com>, Samuel
 Holland <samuel@...lland.org>, Jisheng Zhang <jszhang@...nel.org>, Sean
 Christopherson <seanjc@...gle.com>, Peter Xu <peterx@...hat.com>, Like Xu
 <likexu@...cent.com>, Vipin Sharma <vipinsh@...gle.com>, Maciej
 Wieczor-Retman <maciej.wieczor-retman@...el.com>, Aaron Lewis
 <aaronlewis@...gle.com>, Thomas Huth <thuth@...hat.com>,
 linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
 kvm@...r.kernel.org, linux-kselftest@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
 kvm-riscv@...ts.infradead.org
Subject: Re: [PATCH v4 11/11] KVM: selftests: Enable tunning of err_margin_us
 in arch timer test

On 2023-12-20 06:50, Haibo Xu wrote:
> On Wed, Dec 20, 2023 at 2:22 AM Marc Zyngier <maz@...nel.org> wrote:
>> 
>> On Tue, 12 Dec 2023 09:31:20 +0000,
>> Haibo Xu <haibo1.xu@...el.com> wrote:
>> > > @@ -216,6 +221,9 @@ static bool parse_args(int argc, char *argv[])
>> >               case 'm':
>> >                       test_args.migration_freq_ms = atoi_non_negative("Frequency", optarg);
>> >                       break;
>> > +             case 'e':
>> > +                     test_args.timer_err_margin_us = atoi_non_negative("Error Margin", optarg);
>> > +                     break;
>> 
>> So your error margin is always unsigned...
>> 
> 
> The error margin was supposed to be a non-negative [0, INT_MAX].
> (May be need to define a Max for the input, instead of INT_MAX)
> 
>> >               case 'o':
>> >                       test_args.counter_offset = strtol(optarg, NULL, 0);
>> >                       test_args.reserved = 0;
>> > diff --git a/tools/testing/selftests/kvm/include/timer_test.h b/tools/testing/selftests/kvm/include/timer_test.h
>> > index 968257b893a7..b1d405e7157d 100644
>> > --- a/tools/testing/selftests/kvm/include/timer_test.h
>> > +++ b/tools/testing/selftests/kvm/include/timer_test.h
>> > @@ -22,6 +22,7 @@ struct test_args {
>> >       int nr_iter;
>> >       int timer_period_ms;
>> >       int migration_freq_ms;
>> > +     int timer_err_margin_us;
>> 
>> ... except that you are storing it as a signed value. Some consistency
>> wouldn't hurt, really, and would avoid issues when passing large
>> values.
>> 
> 
> Yes, it's more proper to use an unsigned int for the non-negative error 
> margin.
> Storing as signed here is just to keep the type consistent with that
> of timer_period_ms
> since there will be '+' operation in other places.
> 
>         tools/testing/selftests/kvm/aarch64/arch_timer.c
>         /* Setup a timeout for the interrupt to arrive */
>          udelay(msecs_to_usecs(test_args.timer_period_ms) +
>              test_args.timer_err_margin_us);

But that's exactly why using a signed quantity is wrong.
What does it mean to have a huge *negative* margin?

I don't see how you can justify this.

         M.
-- 
Jazz is not dead. It just smells funny...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ