netdev - Re: [PATCH net-next 5/8] ice: register 1588 PTP clock device object for E810 devices

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, 14 Jun 2021 15:25:36 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Jacob Keller <jacob.e.keller@...el.com>
Cc:     "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
        Richard Cochran <richardcochran@...il.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "sassmann@...hat.com" <sassmann@...hat.com>,
        "Brelinski, TonyX" <tonyx.brelinski@...el.com>
Subject: Re: [PATCH net-next 5/8] ice: register 1588 PTP clock device object
 for E810 devices

On Mon, 14 Jun 2021 13:51:57 -0700 Jacob Keller wrote:
> > Ah, you're right, ptp4l will explicitly cap the freq adjustments
> > based on max_adj from sysfs, so setting max_adj too low could impact
> > the convergence time in strange scenarios.
> 
> Your patch to fix it so that the conversion from scaled_ppm to ppb can't
> overflow is the correct approach, here. The scaled_ppm function didn't
> account for the fact that the provided adjustment could overflow the s32.
> 
> Increasing that to s64 ensures it won't overflow and prevents invalid
> bogus frequencies from passing that check.

On second though I went with long for ppb IOW the same as scaled_ppm,
presumably the problem does not exist on 32bit, so no point using 64b
everywhere.