A mirror of the official Linux kernel repository just in case
Go to file
David S. Miller 0e00c05fa7 Merge branch 'napi_gro_receive-caller-return-value-cleanups'
Jason A. Donenfeld says:

====================
napi_gro_receive caller return value cleanups

In 6570bc79c0 ("net: core: use listified Rx for GRO_NORMAL in
napi_gro_receive()"), the GRO_NORMAL case stopped calling
netif_receive_skb_internal, checking its return value, and returning
GRO_DROP in case it failed. Instead, it calls into
netif_receive_skb_list_internal (after a bit of indirection), which
doesn't return any error. Therefore, napi_gro_receive will never return
GRO_DROP, making handling GRO_DROP dead code.

I emailed the author of 6570bc79c0 on netdev [1] to see if this change
was intentional, but the dlink.ru email address has been disconnected,
and looking a bit further myself, it seems somewhat infeasible to start
propagating return values backwards from the internal machinations of
netif_receive_skb_list_internal.

Taking a look at all the callers of napi_gro_receive, it appears that
three are checking the return value for the purpose of comparing it to
the now never-happening GRO_DROP, and one just casts it to (void), a
likely historical leftover. Every other of the 120 callers does not
bother checking the return value.

And it seems like these remaining 116 callers are doing the right thing:
after calling napi_gro_receive, the packet is now in the hands of the
upper layers of the newtworking, and the device driver itself has no
business now making decisions based on what the upper layers choose to
do. Incrementing stats counters on GRO_DROP seems like a mistake, made
by these three drivers, but not by the remaining 117.

It would seem, therefore, that after rectifying these four callers of
napi_gro_receive, that I should go ahead and just remove returning the
value from napi_gro_receive all together. However, napi_gro_receive has
a function event tracer, and being able to introspect into the
networking stack to see how often napi_gro_receive is returning whatever
interesting GRO status (aside from _DROP) remains an interesting
data point worth keeping for debugging.

So, this series simply gets rid of the return value checking for the
four useless places where that check never evaluates to anything
meaningful.

[1] https://lore.kernel.org/netdev/20200624210606.GA1362687@zx2c4.com/
====================

Acked-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-25 16:16:21 -07:00
arch flexible-array member conversion patches for 5.8-rc2 2020-06-16 17:23:57 -07:00
block block: Replace zero-length array with flexible-array 2020-06-15 23:08:32 -05:00
certs .gitignore: add SPDX License Identifier 2020-03-25 11:50:48 +01:00
crypto Merge branch 'rwonce/rework' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux 2020-06-10 14:46:54 -07:00
Documentation docs: net: ieee802154: change link to new project URL 2020-06-19 22:08:09 +02:00
drivers wil6210: account for napi_gro_receive never returning GRO_DROP 2020-06-25 16:16:21 -07:00
fs AFS fixes 2020-06-16 17:40:51 -07:00
include sctp: Don't advertise IPv4 addresses if ipv6only is set on the socket 2020-06-25 16:11:33 -07:00
init Kbuild updates for v5.8 (2nd) 2020-06-13 13:29:16 -07:00
ipc mmap locking API: use coccinelle to convert mmap_sem rwsem call sites 2020-06-09 09:39:14 -07:00
kernel Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf 2020-06-17 13:26:55 -07:00
lib test_objagg: Fix potential memory leak in error handling 2020-06-15 13:32:11 -07:00
LICENSES LICENSES: Rename other to deprecated 2019-05-03 06:34:32 -06:00
mm Kbuild updates for v5.8 (2nd) 2020-06-13 13:29:16 -07:00
net sctp: Don't advertise IPv4 addresses if ipv6only is set on the socket 2020-06-25 16:11:33 -07:00
samples Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf 2020-06-17 13:26:55 -07:00
scripts scripts/decode_stacktrace: warn when modpath is needed but is unset 2020-06-15 15:37:24 -07:00
security ima: Replace zero-length array with flexible-array 2020-06-15 23:08:32 -05:00
sound ASoC: SOF: Replace zero-length array with flexible-array 2020-06-15 23:08:32 -05:00
tools tc-testing: avoid action cookies with odd length. 2020-06-25 16:10:45 -07:00
usr bpfilter: match bit size of bpfilter_umh to that of the kernel 2020-05-17 18:52:01 +09:00
virt MIPS: 2020-06-12 11:05:52 -07:00
.clang-format block: add bio_for_each_bvec_all() 2020-05-25 11:25:24 +02:00
.cocciconfig
.get_maintainer.ignore Opt out of scripts/get_maintainer.pl 2019-05-16 10:53:40 -07:00
.gitattributes .gitattributes: use 'dts' diff driver for dts files 2019-12-04 19:44:11 -08:00
.gitignore modpost: generate vmlinux.symvers and reuse it for the second modpost 2020-06-06 23:38:12 +09:00
.mailmap A fair amount of stuff this time around, dominated by yet another massive 2020-06-01 15:45:27 -07:00
COPYING COPYING: state that all contributions really are covered by this file 2020-02-10 13:32:20 -08:00
CREDITS mailmap: change email for Ricardo Ribalda 2020-05-25 18:59:59 -06:00
Kbuild kbuild: rename hostprogs-y/always to hostprogs/always-y 2020-02-04 01:53:07 +09:00
Kconfig kbuild: ensure full rebuild when the compiler is updated 2020-05-12 13:28:33 +09:00
MAINTAINERS MAINTAINERS: update email address for Felix Fietkau 2020-06-22 12:57:11 -07:00
Makefile Linux 5.8-rc1 2020-06-14 12:45:04 -07:00
README Drop all 00-INDEX files from Documentation/ 2018-09-09 15:08:58 -06:00

Linux kernel
============

There are several guides for kernel developers and users. These guides can
be rendered in a number of formats, like HTML and PDF. Please read
Documentation/admin-guide/README.rst first.

In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``.  The formatted documentation can also be read online at:

    https://www.kernel.org/doc/html/latest/

There are various text files in the Documentation/ subdirectory,
several of them using the Restructured Text markup notation.

Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.