netdev - Re: [PATCH net-next 1/2] sfc: Implement ndo_hwtstamp

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]

Date: Mon, 4 Dec 2023 13:00:35 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: "Austin, Alex (DCCG)" <alexaust@....com>
Cc: Jakub Kicinski <kuba@...nel.org>, Alex Austin <alex.austin@....com>,
	netdev@...r.kernel.org, linux-net-drivers@....com,
	ecree.xilinx@...il.com, habetsm.xilinx@...il.com,
	davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
	richardcochran@...il.com, lorenzo@...nel.org, memxor@...il.com,
	alardam@...il.com, bhelgaas@...gle.com
Subject: Re: [PATCH net-next 1/2] sfc: Implement ndo_hwtstamp_(get|set)

On Mon, Dec 04, 2023 at 10:26:30AM +0000, Austin, Alex (DCCG) wrote:
> This seems like a good approach. I'll re-work into a v2.
> 
> Alex
> 
> On 02/12/2023 03:25, Jakub Kicinski wrote:
> > Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> > 
> > 
> > On Thu, 30 Nov 2023 13:58:25 +0000 Alex Austin wrote:
> > > -     struct hwtstamp_config config;
> > > +     struct kernel_hwtstamp_config config;
> > > +     *config = efx->ptp_data->config;
> > Do we have a lot of places which assign the new structure directly
> > like this?
> > 
> > There's a bit of "request state" in it:
> > 
> > struct kernel_hwtstamp_config {
> >          int flags;
> >          int tx_type;
> >          int rx_filter;
> >          struct ifreq *ifr;             <<<
> >          bool copied_to_user;           <<<
> >          enum hwtstamp_source source;
> > };
> > 
> > Maybe keep the type of config as was, and use
> > hwtstamp_config_to_kernel() to set the right fields?
> 

If I may intervene. The "request state" will ultimately go away once all
drivers are converted. I know it's more fragile and not all fields are
valid, but I think I would like drivers to store the kernel_ variant of
the structure, because more stuff will be added to the kernel_ variant
in the future (the hwtstamp provider + qualifier), and doing this from
the beginning will avoid reworking them again.