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: <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