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: <CAP5jrPEL-RAPr4NADfGtqw1UJq+uKAVyRiz3wmAjMXhXAgit4w@mail.gmail.com> Date: Thu, 11 May 2023 21:22:23 -0600 From: Max Georgiev <glipus@...il.com> To: Vladimir Oltean <vladimir.oltean@....com> Cc: kory.maincent@...tlin.com, kuba@...nel.org, netdev@...r.kernel.org, maxime.chevallier@...tlin.com, vadim.fedorenko@...ux.dev, richardcochran@...il.com, gerhard@...leder-embedded.com, liuhangbin@...il.com Subject: Re: [RFC PATCH net-next v6 1/5] net: Add NDOs for hardware timestamp get/set On Thu, May 11, 2023 at 6:32 AM Vladimir Oltean <vladimir.oltean@....com> wrote: > > On Mon, May 01, 2023 at 10:31:46PM -0600, Maxim Georgiev wrote: > > struct net_device_ops { > > int (*ndo_init)(struct net_device *dev); > > @@ -1649,6 +1659,12 @@ struct net_device_ops { > > ktime_t (*ndo_get_tstamp)(struct net_device *dev, > > const struct skb_shared_hwtstamps *hwtstamps, > > bool cycles); > > + int (*ndo_hwtstamp_get)(struct net_device *dev, > > + struct kernel_hwtstamp_config *kernel_config, > > + struct netlink_ext_ack *extack); > > I'm not sure it is necessary to pass an extack to "get". That should > only give a more detailed reason if the driver refuses something. I have to admit I just followed Jakub's guidance adding "extack" to the list of parametres. I'll let Jakub to comment on that. > > For that matter, now that ndo_hwtstamp_get() should no longer be > concerned with the copy_to_user(), I'm not even sure that it should > return int at all, and not void. The transition is going to be slightly > problematic though, with the generic_hwtstamp_get_lower() necessarily > still calling dev_eth_ioctl() -> copy_to_user(), so we probably can't > make it void just now. Would it make sense to keep the return int value here "for future extensions"?
Powered by blists - more mailing lists