[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <7e025613-3516-4957-b83a-70b125a24fa7@app.fastmail.com>
Date: Wed, 08 Jan 2025 15:10:03 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Niklas Cassel" <cassel@...nel.org>, "Hans Zhang" <18255117159@....com>
Cc: "Manivannan Sadhasivam" <manivannan.sadhasivam@...aro.org>,
Krzysztof WilczyĆski <kw@...ux.com>,
"Kishon Vijay Abraham I" <kishon@...nel.org>,
"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>, linux-pci@...r.kernel.org,
linux-kernel@...r.kernel.org, rockswang7@...il.com
Subject: Re: [v8] misc: pci_endpoint_test: Fix overflow of bar_size
On Tue, Jan 7, 2025, at 16:57, Niklas Cassel wrote:
> On Tue, Jan 07, 2025 at 11:44:21PM +0800, Hans Zhang wrote:
>> On 2025/1/7 19:47, Niklas Cassel wrote:
>>
>> Hi Niklas,
>>
>> > The error:
>> > drivers/misc/pci_endpoint_test.c:315: undefined reference to `__udivmoddi4'
>> > sounds like the compiler is using a specialized instruction to do both div
>> > and mod in one. By removing the mod in patch 1/2, I expect that patch 2/2
>> > will no longer get this error.
>>
>> The __udivmoddi4 may be the way div and mod are combined.
>>
>> Delete remain's patch 1/2 according to your suggestion. I compiled it as a
>> KO module for an experiment.
>>
>> There are still __udivdi3 errors, so the do_div API must be used.
>
> Ok. Looking at do_div(), it seems to be the correct API to use
> for this problem. Just change bar_size type to u64 (instead of casting)
> and use do_div() ? That is how it is seems to be used in other drivers.
I think using div_u64_rem() instead of do_div() would make this
more readable as this is always an inline function, so the type can
remain resource_size_t, and the division gets optimized well when
that is a 32-bit type.
Arnd
Powered by blists - more mailing lists