netdev - Re: [RFC net 00/03]: dev_queue

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20090611.031852.90563118.davem@davemloft.net>
Date:	Thu, 11 Jun 2009 03:18:52 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	kaber@...sh.net
Cc:	netdev@...r.kernel.org
Subject: Re: [RFC net 00/03]: dev_queue_xmit error propagation

From: Patrick McHardy <kaber@...sh.net>
Date: Tue,  9 Jun 2009 18:16:59 +0200 (MEST)

> Currently the ->ndo_hard_start_xmit() callbacks are only permitted to return
> one of the NETDEV_TX codes. This prevents any kind of error propagation for
> virtual devices, like queue congestion of the underlying device in case of
> layered devices, or unreachability in case of tunnels.
> 
> These patches change the return conventions so hard_start_xmit() can return
> a NETDEV_TX code, an errno code or a NET_XMIT code. This means it can
> additionally to the NETDEV_TX codes simply return the value of dev_queue_xmit().
> 
> When queueing is used, errors can't be propagated back since transmission is
> asynchronously and all non-NETDEV codes are mapped to NETDEV_TX_OK, reflecting
> the fact that the skb is consumed unconditionally.
> 
> In case of virtual devices not using queueing, the NETDEV_TX codes are consumed
> by dev_queue_xmit(), everything else is returned to the higher layers.
> 
> The end result is that virtual network devices can propagate queue congestion
> state of the underlying device, or other errors, back to the socket layer.
> One immediately useful effect is that TCP can make use of this information
> as is currently done with non-virtual devices. But it also seems useful in case
> of tunnels, which can return more meaningful errors, or for statistics.
> 
> Comments welcome. A review of my changes in dev_hard_start_xmit() would be
> especially appreciated :)

These changes look fine to me.

That one if() conditional checking 'ret' for three different
properties is stretching the brain a bit.  Maybe you can
encapsulate that sucker into an inline function with suitable
comments.  That way when someone reads the test, it just says
what it is looking for, rather than being some complicated
set of tests.

Once you fix that up and the problem Eric spotted in patch #3
feel free to formally submit this.

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html