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
| ||
|
Message-ID: <CAJve8o=nTsAwwgSib4vOLXjOWSMV2+J+BFsUZ57OdAK7eW8q8A@mail.gmail.com> Date: Thu, 21 Dec 2023 10:58:40 +0800 From: Haibo Xu <xiaobo55x@...il.com> To: Marc Zyngier <maz@...nel.org> 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 Wed, Dec 20, 2023 at 9:58 PM Marc Zyngier <maz@...nel.org> wrote: > > On Wed, 20 Dec 2023 13:51:24 +0000, > Haibo Xu <xiaobo55x@...il.com> wrote: > > > > On Wed, Dec 20, 2023 at 5:00 PM Marc Zyngier <maz@...nel.org> wrote: > > > > > > 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: > > > >> > 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? > > > > > > > Hi Marc, > > > > I agree that negative values are meaningless for the margin. > > If I understand correctly, the negative margin should be filtered by > > assertion in atoi_non_negative(). > > No. Please. > > atoi_non_negative() returns a uint32_t, which is what it should do. > The bug is squarely in the use of an 'int' to store such value, and it > is the *storage* that turns a positive value into a negative one. > Thanks for the detailed info! May I understand that your concern is mainly for a platform with 64bit int type, which may trigger the positive to negative convert? If so, I think we may need to do a clean up for the test code since several other places have the same issue. Regards, Haibo > M. > > -- > Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists