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: <CANn89iKYCeLcY4=i1849aMx5NO3HMYy5STPuxE_51QqugwkdhA@mail.gmail.com>
Date:   Wed, 8 Nov 2017 15:43:00 -0800
From:   Eric Dumazet <edumazet@...gle.com>
To:     Dave Taht <dave.taht@...il.com>
Cc:     Stephen Hemminger <stephen@...workplumber.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH v3 net-next 2/3] netem: add uapi to express delay and
 jitter in nanoseconds

On Wed, Nov 8, 2017 at 3:36 PM, Dave Taht <dave.taht@...il.com> wrote:
> On Wed, Nov 8, 2017 at 3:24 PM, Stephen Hemminger
> <stephen@...workplumber.org> wrote:
>> On Wed,  8 Nov 2017 15:12:27 -0800
>> Dave Taht <dave.taht@...il.com> wrote:
>>
>>> --- a/net/sched/sch_netem.c
>>> +++ b/net/sched/sch_netem.c
>>> @@ -819,6 +819,8 @@ static const struct nla_policy netem_policy[TCA_NETEM_MAX + 1] = {
>>>       [TCA_NETEM_LOSS]        = { .type = NLA_NESTED },
>>>       [TCA_NETEM_ECN]         = { .type = NLA_U32 },
>>>       [TCA_NETEM_RATE64]      = { .type = NLA_U64 },
>>> +     [TCA_NETEM_LATENCY64]   = { .type = NLA_S64 },
>>> +     [TCA_NETEM_JITTER64]    = { .type = NLA_S64 },
>>>  };
>>>
>>>  static int parse_attr(struct nlattr *tb[], int maxtype, struct nlattr *nla,
>>> @@ -916,6 +918,12 @@ static int netem_change(struct Qdisc *sch, struct nlattr *opt)
>>>               q->rate = max_t(u64, q->rate,
>>>                               nla_get_u64(tb[TCA_NETEM_RATE64]));
>>>
>>> +     if (tb[TCA_NETEM_LATENCY64])
>>> +             q->latency = nla_get_s64(tb[TCA_NETEM_LATENCY64]);
>>> +
>>> +     if (tb[TCA_NETEM_JITTER64])
>>> +             q->jitter = nla_get_s64(tb[TCA_NETEM_JITTER64]);
>>> +
>>>       if (tb[TCA_NETEM_ECN])
>>>               q->ecn = nla_get_u32(tb[TCA_NETEM_ECN]);
>>>
>>
>> Although some of the maths use signed 64 bit.
>> I think the API should be unsigned 64 bit.  Or do you want to allow
>> negative latency?
>
> Personally I find things simpler to reason about when signed, and the
> userspace side of the code (currently) offers the ability to generically
> have signed time values for "other stuff".
>
> The constrained range of 63 vs 64 bits we can debate in 272 years or so.

ktime_get_ns() returns number of nanosec in u64, since machine _boot_

So we wont have overflows, unless a linux host can stay up for more
than 500 years.

This seems unlikely.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ