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,URIBL_BLOCKED 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 26E91C282CA for ; Tue, 12 Feb 2019 08:56:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DF66B2080A for ; Tue, 12 Feb 2019 08:55:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b="Kmy6zVLl" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728580AbfBLIz6 (ORCPT ); Tue, 12 Feb 2019 03:55:58 -0500 Received: from mail-yw1-f67.google.com ([209.85.161.67]:37781 "EHLO mail-yw1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728086AbfBLIz6 (ORCPT ); Tue, 12 Feb 2019 03:55:58 -0500 Received: by mail-yw1-f67.google.com with SMTP id k14so718454ywe.4 for ; Tue, 12 Feb 2019 00:55:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=VYhEkkAsAH4bQsC54ZEJjvtHnyBdSJ4aNYNyoXu9Cl0=; b=Kmy6zVLlmbnzey+vtMO9y1MQSpA6t/PEijw35JV836firpz7yBmH8g3CjQOw9iWYA1 dwYXPOPe+N909o2Eg5u2dIbRUV8OlnZo3Yg0fvpffzak2+HcV7DHQnzJM98vsUkQPtAa Ho9FihquM/tLxKxo+Qd2/2vWas5/kxd+wPRAw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=VYhEkkAsAH4bQsC54ZEJjvtHnyBdSJ4aNYNyoXu9Cl0=; b=JIeU+ZkkXFsgfvH3NaqptWdu3UurDwvSe1bRmMa7fSkQE9dbzY79wYkATlqzsMyWDt DqX8SrLS0ZZ1Z43T66c5XDVs5eoBkE0DwK1g9nyzf6Yw0TZ7K5g00Y8dtIU9j2aCuOel KxYmcF8cFa9MxFVS72UgUyeRY/7c1nLOehZvE0UjC+nUvj7JiHXUDzYoQ9NNV2BCNG8G /s3NYjirkFAM6nfBW6WcKxaDE05bYYbv/jXryBJOSONefz5hJXamb0OunAhGUBaHEhkR FJZQcdfncq6r47+CGXLK+YYCJE6QGSYTzxBw+jkIOYTlYF9Ch6MuM7yiDLTT+UIYcOAb gaoQ== X-Gm-Message-State: AHQUAub13ER7fisoOlPgH0PgBnYF+TgcYxCXuu2KzhjFI4za2KWsAjo3 wKPTtNbN282KSBfPCj/139zduu8sZb9eeFcEj4arAw== X-Google-Smtp-Source: AHgI3IbgUR+G8r4YH73vlpIrZXY0dULb2z943jk73SQB/gCy8Wjde5hQId4YSDsSXeEI8kTxW0WZWHBIMWT5b0tWiAk= X-Received: by 2002:a81:77c1:: with SMTP id s184mr1935225ywc.300.1549961757233; Tue, 12 Feb 2019 00:55:57 -0800 (PST) MIME-Version: 1.0 References: <874la1r0io.fsf@linkitivity.dja.id.au> In-Reply-To: From: Michael Chan Date: Tue, 12 Feb 2019 00:55:46 -0800 Message-ID: Subject: Re: Stack sends oversize UDP packet to the driver To: =?UTF-8?B?TWFoZXNoIEJhbmRld2FyICjgpK7gpLngpYfgpLYg4KSs4KSC4KSh4KWH4KS14KS+4KSwKQ==?= Cc: Daniel Axtens , Netdev , David Miller , Eric Dumazet , Willem de Bruijn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, Feb 8, 2019 at 12:26 PM Mahesh Bandewar (=E0=A4=AE=E0=A4=B9=E0=A5= =87=E0=A4=B6 =E0=A4=AC=E0=A4=82=E0=A4=A1=E0=A5=87=E0=A4=B5=E0=A4=BE=E0=A4= =B0) wrote: > > On Wed, Feb 6, 2019 at 8:51 PM Mahesh Bandewar (=E0=A4=AE=E0=A4=B9=E0=A5= =87=E0=A4=B6 =E0=A4=AC=E0=A4=82=E0=A4=A1=E0=A5=87=E0=A4=B5=E0=A4=BE=E0=A4= =B0) > wrote: > > > > On Tue, Feb 5, 2019 at 11:36 AM Michael Chan wrote: > > > I've looked at this a little more. The blackhole_dev is not IFF_UP | > > > IFF_RUNNING, right? May be that's why the packets are never getting > > > to the xmit function? > > Yes, so I added those two flags and ended up writing a test-module for > > the device (which I will include while posting the patch-series). > > However, adding those flags is also not sufficient since the qdisc is > > initialized to noop_qdisc so qdisc enqueue will drop packets before > > hitting the ndo_start_xmit(). > > I have another version of the fix (with help from Eric) and this > should hit the .ndo_start_xmit() of the blackhole_dev. I'm adding > these flags during the setup and then calling dev_activate() to change > noop qdisc to null qdisc. Please give this patch set a try and let me > know if the blackhole_dev xmit path gets exercised in your test > scenario. The new version still works in the sense that no oversize packets are seen in the NIC driver's xmit function. But I still don't see any packets hitting the blackhole's xmit function. I'm not 100% sure but I think the blackhole dev has no IP address and so the UDP packets are dropped in ip_finish_output2() because there is no neigh. Something like that.