netdev - DMA coalescing - ethtool vs. kernel

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-next>] [day] [month] [year] [list]

Date:   Thu, 23 Nov 2017 13:31:58 +0100
From:   Michal Kubecek <mkubecek@...e.cz>
To:     "John W. Linville" <linville@...driver.com>
Cc:     netdev@...r.kernel.org, Paul Greenwalt <paul.greenwalt@...el.com>,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        Stephen Hemminger <stephen@...workplumber.org>
Subject: DMA coalescing - ethtool vs. kernel

Hello,

while digging through the interface between ethtool and kernel,
I noticed that ethtool commit 5dd7bfbc5079 ("ethtool: Add DMA Coalescing
support") added new member dmac into struct ethtool_coalesce which is
part of kernel UAPI but there is no kernel counterpart to this change in
master, net or net-next tree.

This doesn't cause any serious trouble as with userspace structure
longer than kernel thinks, kernel would simply ignore the extra member
so that the feature "only" doesn't work. But I doubt such change could
be accepted to kernel side of the interface as new kernel would then
overflow shorter structure passed by older ethtool. Stephen Hemminger
mentioned the ABI compatibility issue when this patch was submitted:

  https://patchwork.ozlabs.org/patch/806049/#1757846

Does it make sense to have ethtool feature without kernel counterpart?

Michal Kubecek