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
| ||
|
Message-ID: <20230406165055.egz32amam6o2bmqu@skbuf> Date: Thu, 6 Apr 2023 19:50:55 +0300 From: Vladimir Oltean <vladimir.oltean@....com> To: Max Georgiev <glipus@...il.com> Cc: Jakub Kicinski <kuba@...nel.org>, kory.maincent@...tlin.com, netdev@...r.kernel.org, maxime.chevallier@...tlin.com, vadim.fedorenko@...ux.dev, richardcochran@...il.com, gerhard@...leder-embedded.com Subject: Re: [RFC PATCH v3 3/5] Add ndo_hwtstamp_get/set support to vlan code path On Thu, Apr 06, 2023 at 10:18:36AM -0600, Max Georgiev wrote: > If I may, there are other ways to work around this inefficiency. > Since kernel_hwtstamp_config was meant to be easily extendable, > we can abuse it and add a flag field there. One of the flag values > can indicate that the operation result structure was already copied > to kernel_config->ifr by the function that received this kernel_config > instance as a parameter, and that the content of the > hwtstamp_config-related fields in kernel_config structure must > be ignored when the function returns. It would complicate the > implementation logic, but we'd avoid some unnecessary copy > operations while converting *vlan components to the newer interface. > Would it be a completely unreasonable approach? No, I think that's fair game and a good idea. It would make the best case better (SET request on a converted real_dev drops from 3 copies to 2), while keeping the worst case the same (SET request on an unconverted real_dev remains at 3 copies).
Powered by blists - more mailing lists