linux-kernel - Re: [RFC PATCH] pps: Increase PPS_MAX

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <38f38f66-0fd5-4e6c-4839-8272cef77046@ni.com>
Date:   Fri, 9 Jun 2023 16:00:55 -0500
From:   Charlie Johnston <charlie.johnston@...com>
To:     Rodolfo Giometti <giometti@...eenne.com>
Cc:     linux-kernel@...r.kernel.org, brenda.streiff@...com
Subject: Re: [RFC PATCH] pps: Increase PPS_MAX_SOURCES value.

On 6/9/23 02:30, Rodolfo Giometti wrote:
> On 08/06/23 00:07, Charlie Johnston wrote:
>> On 6/7/23 02:33, Rodolfo Giometti wrote:
>>> On 05/06/23 22:31, Charlie Johnston wrote:
>>>> For consistency with what ptp uses for minors, this
>>>> change sets PPS_MAX_SOURCES to MINORMASK + 1.
>>>>
>>>> The PPS_MAX_SOURCES value is currently set to 16. In
>>>> some cases this was not sufficient for a system. For
>>>> example, a system with multiple (4+) PCIe cards each
>>>> with 4 PTP-capable ethernet interfaces could run out
>>>> of the available PPS major:minors if each interface
>>>> registers a PPS source.
>>>>
>>>> Signed-off-by: Charlie Johnston <charlie.johnston@...com>
>>>> ---
>>>>    include/uapi/linux/pps.h | 2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/include/uapi/linux/pps.h b/include/uapi/linux/pps.h
>>>> index 009ebcd8ced5..85f472330da8 100644
>>>> --- a/include/uapi/linux/pps.h
>>>> +++ b/include/uapi/linux/pps.h
>>>> @@ -26,7 +26,7 @@
>>>>    #include <linux/types.h>
>>>>      #define PPS_VERSION        "5.3.6"
>>>> -#define PPS_MAX_SOURCES        16        /* should be enough... */
>>>> +#define PPS_MAX_SOURCES        (MINORMASK + 1)
>>>>      /* Implementation note: the logical states ``assert'' and ``clear''
>>>>     * are implemented in terms of the chip register, i.e. ``assert''
>>>
>>> I have just one question: are you sure that it's safe to call idr_alloc(..., 0, (MINORMASK + 1), ...)?
>>>
>>> Ciao,
>>>
>>> Rodolfo
>>>
>>
>> Thanks for taking a look!
>>
>> My understanding is that idr_alloc(..., start, end, ...) can take any end value up to INT_MAX. It also handles any values <= 0 by treating them as equal to INT_MAX + 1 since the end value is non-inclusive. I can't think of any reason using MINORMASK + 1 here would be an issue since it's much less than the maximum value idr_alloc() allows.
>>
>> A number of drivers (e.g. ptp) just explicitly use a start and end value of 0, but I don't think that change would fit here.
> 
> I see and maybe I should replace the usage of idr_*() with ida_*() as PTP does...
> 
> However the right-thing(TM) to do here should be dropping PPS_MAX_SOURCES at all!
> 
> Let me go deeper in this issue. I'm going to produce a patch set in next days. Have you any chances to test it?
> 
> Ciao,
> 
> Rodolfo
> 

I'll have to check when the system we used for testing is available again (not easy to find a system with 20+ Ethernet ports) but I'd be happy to test a patch!

I know an increase to PPS_MAX_SOURCES was tested on that system.

Thanks,
Charlie