From mboxrd@z Thu Jan  1 00:00:00 1970
From: Cong Wang <xiyou.wangcong@gmail.com>
Subject: Re: [Patch net-next v3 3/3] net_sched: implement ->change_tx_queue_len()
 for pfifo_fast
Date: Sun, 28 Jan 2018 18:33:28 -0800
Message-ID: <CAM_iQpV=f4DoONwLqbT0=Xo6c+ZWte-V=gjJJYAXPjGREa7cwA@mail.gmail.com>
References: <20180126022624.20442-1-xiyou.wangcong@gmail.com>
 <20180126022624.20442-4-xiyou.wangcong@gmail.com> <eae09f55-072c-1f60-c231-d76455d00f8b@redhat.com>
 <CAM_iQpWLNhm-k_2Ncv2D=K1FCnUJtcqfemu6oKt6DXQk7rQy7g@mail.gmail.com> <20180126160850-mutt-send-email-mst@kernel.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Cc: Jason Wang <jasowang@redhat.com>,
        Linux Kernel Network Developers <netdev@vger.kernel.org>,
        John Fastabend <john.fastabend@gmail.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-pf0-f169.google.com ([209.85.192.169]:34513 "EHLO
        mail-pf0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S932836AbeA2Cdt (ORCPT
        <rfc822;netdev@vger.kernel.org>); Sun, 28 Jan 2018 21:33:49 -0500
Received: by mail-pf0-f169.google.com with SMTP id e76so3618629pfk.1
        for <netdev@vger.kernel.org>; Sun, 28 Jan 2018 18:33:49 -0800 (PST)
In-Reply-To: <20180126160850-mutt-send-email-mst@kernel.org>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Fri, Jan 26, 2018 at 6:10 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
>
> This part?

Yes, dev_deactivate() as you quote.

>
> +       bool up = dev->flags & IFF_UP;
> +       unsigned int i;
> +       int ret = 0;
> +
> +       if (up)
> +               dev_deactivate(dev);
> +
> +       for (i = 0; i < dev->num_tx_queues; i++) {
> +               ret = qdisc_change_tx_queue_len(dev, &dev->_tx[i]);
> +
> +               /* TODO: revert changes on a partial failure */
> +               if (ret)
> +                       break;
> +       }
> +
> +       if (up)
> +               dev_activate(dev);
>
>
> I wonder whether it really is safe to read dev->flags like that
> without any locks.

I really to hate to point it out again we have RTNL here. You
missed my previous response to John. ;)

Please read v1 and v2 when you response to v3.