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  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]
Date:   Tue, 10 Jul 2018 19:57:25 -0700
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Nishanth Devarajan <ndev2021@...il.com>
Cc:     Jamal Hadi Salim <jhs@...atatu.com>, Jiri Pirko <jiri@...nulli.us>,
        David Miller <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Cody Doucette <doucette@...edu>,
        Michel Machado <michel@...irati.com.br>
Subject: Re: [PATCH v3 net-next] net/sched: add skbprio scheduler

On Sat, Jul 7, 2018 at 3:14 AM Nishanth Devarajan <ndev2021@...il.com> wrote:
> diff --git a/Documentation/networking/sch_skbprio.txt b/Documentation/networking/sch_skbprio.txt
> new file mode 100644
> index 0000000..3aa4d3e
> --- /dev/null
> +++ b/Documentation/networking/sch_skbprio.txt

We usually document each qdisc behavior in tc man pages in iproute2.

I don't mind you document it in kernel, but it kinda breaks the tradition.


> +static int skbprio_change(struct Qdisc *sch, struct nlattr *opt,
> +                       struct netlink_ext_ack *extack)
> +{
> +       struct skbprio_sched_data *q = qdisc_priv(sch);
> +       struct tc_skbprio_qopt *ctl = nla_data(opt);
> +       const unsigned int min_limit = 1;
> +
> +       if (ctl->limit == (typeof(ctl->limit))-1)
> +               sch->limit = max(qdisc_dev(sch)->tx_queue_len, min_limit);
> +       else if (ctl->limit < min_limit)
> +               return -EINVAL;
> +       else
> +               sch->limit = ctl->limit;

The dev->tx_queue_len is fundamentally non-sense since now
almost every real NIC is multi-queue and qdisc has a completely
different sch->limit. This is why I suggested you to simply
avoid it in your code.

There is no standard way to use dev->tx_queue_len in kernel,
so I can't claim your use is correct or not, but it still looks odd,
other qdisc seems just uses as a default, rather than picking
the smaller or bigger value as a cap.

Powered by blists - more mailing lists