From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9FD38C43381 for ; Fri, 1 Mar 2019 12:19:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 63D0120840 for ; Fri, 1 Mar 2019 12:19:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=cloudflare.com header.i=@cloudflare.com header.b="iZQBUkVx" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387724AbfCAMTU (ORCPT ); Fri, 1 Mar 2019 07:19:20 -0500 Received: from mail-wr1-f42.google.com ([209.85.221.42]:42572 "EHLO mail-wr1-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728113AbfCAMTU (ORCPT ); Fri, 1 Mar 2019 07:19:20 -0500 Received: by mail-wr1-f42.google.com with SMTP id r5so25623283wrg.9 for ; Fri, 01 Mar 2019 04:19:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=IjKbHkpD3QJH8A9yZnUf2ljHls11mKxaciyGOQAbFsM=; b=iZQBUkVx/aSDJ2kBFZP0R2BaxG0hUaS2j0UHQalrLRSAtk0RPa8OB7l51m6VTFJ7+p 1EFYYPZ19soXdpj/xTgVpm3dvWThogIcQQMxIgqDsrORV+MFYrM9PpwInK3OetOmKxZU QAIW/iCek00ZUxQtbmpmdA0JuLp5CVn7p2xg0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=IjKbHkpD3QJH8A9yZnUf2ljHls11mKxaciyGOQAbFsM=; b=HVzvQcn3ozU9UvjW1K4rU0U0jDzVb1/BGZfM1q4KUXmaUIAtWFc7+4mimabwhivhGy SV7QB8vTQYiVbSKBAABD6KofgFLVEL45pNlg2URXBtxruY6b04hRBBBVSt89kcVVCVtZ fGEUgkZk7K+/H3eew/sPQcSOU0teeweO07lD+o36t4CN/25vwfUrXVPsd7Q6Ncv3LicX de3lKDGhvSTMLHbi+UeL3T5sqIFVPB+kLRfrCFc2M4g/jfAkBWKFMdDSWIVOeorxTVzu HLc5ClLJkZSiWuMHjzbQ2fJACeOOLgzHm+JuV+LikmnsBg/OlIxVrHJCWsgP97oAgabz dJiw== X-Gm-Message-State: APjAAAUwNl51LFdaExf0SylHz8DvWoOZAmFkD+QksGaO/c7ESwa4oiL/ oMWBAbWj5XLf6sb8QFSrVVwdclh23VOCb3NnNXlMIrhUU0U1/g== X-Google-Smtp-Source: APXvYqxCJpJLH62YplHKH1pcjUXkoxdWpxDePtYXy3IMKP4lK/WL/7rhonZzV8TWvMgDjelKCQnunOOR/cU262XJl4o= X-Received: by 2002:adf:824b:: with SMTP id 69mr3365301wrb.24.1551442758758; Fri, 01 Mar 2019 04:19:18 -0800 (PST) MIME-Version: 1.0 From: Ignat Korchagin Date: Fri, 1 Mar 2019 12:19:07 +0000 Message-ID: Subject: noqueue qdisc and non-virtual interfaces To: netdev@vger.kernel.org Cc: Daniel Dao , Ivan Babrou , Frank Hofmann , Nicolae Vartolomei Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Good day, According to this link: http://linux-tc-notes.sourceforge.net/tc/doc/sch_noqueue.txt it should not be possible to assign noqueue qdisc to physical devices or classes. Yet, I can clearly do it even on the latest 5.0-rc series kernels: $ sudo tc qdisc add dev eth0 root noqueue $ sudo tc qdisc show dev eth0 qdisc noqueue 8005: root refcnt 385 If I understand the source correctly, noqueue qdisc was designed only for network interfaces, which have IFF_NO_QUEUE in priv_flags in net_device structure. However, I see no checks in the code, which enforce it when attaching this qdisc to an interface. I believe, it was not possible before, but commit d66d6c3152e8d5a6db42a56bf7ae1c6cae87ba48 changed that. Regardless, if it is intentional or not, the change is incomplete as it introduces a potential NULL ptr dereference bug, which can be triggered by doing something like: dev="eth0" sudo tc qdisc replace dev $dev root noqueue sudo tc qdisc delete dev $dev root sudo tc qdisc replace dev $dev root handle 1: htb default 1 sudo tc class add dev $dev parent 1: classid 1:1 htb rate 1000Gbps sudo tc qdisc add dev $dev parent 1:1 handle 10: noqueue I believe it should not be possible to have noqueue qdisc on physical nics, but, please, let me know if I'm wrong. Regards, Ignat