Re: [PATCH v7 2/2] block: add overflow checks for Amiga partition support

[Michael Schmitz <schmitzmic@gmail.com>]

Hi Martin,

On 13/06/23 22:57, Martin Steigerwald wrote:
> Michael Schmitz - 13.06.23, 10:18:24 CEST:
>> Am 13.06.2023 um 19:25 schrieb Martin Steigerwald:
>>> Hi Michael, hi Jens, Hi Geert.
>>>
>>> Michael Schmitz - 22.08.22, 22:56:10 CEST:
>>>> On 23/08/22 08:41, Jens Axboe wrote:
>>>>> On 8/22/22 2:39 PM, Michael Schmitz wrote:
>>>>>> Hi Jens,
>>>>>>
>>>>>> will do - just waiting to hear back what needs to be done
>>>>>> regarding
>>>>>> backporting issues raised by Geert.
>>>>> It needs to go upstream first before it can go to stable. Just
>>>>> mark
>>>>> it with the right Fixes tags and that will happen automatically.
>>> […]
>>>
>>>> thanks - the Fixes tag in my patches refers to Martin's bug report
>>>> and won't be useful to decide how far back this must be applied.
>>>>
>>>> Now the bug pre-dates git, making the commit to 'fix'
>>>> 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ... That one's a bit
>>>> special, please yell if you want me to lie about this and use a
>>>> later commit specific to the partition parser code.
>>> After this discussion happened I thought the patch went in. However…
>>> as John Paul Adrian asked in "Status of affs support in the kernel
>>> and affstools" thread on linux-m68k and debian-68k mailing list, I
>>> searched for the patch in git history but did not find it.
>> I may have messed that one up, as it turns out. Last version was v9
>> which I had to resend twice, and depending on what Jens uses to keep
>> track of patches, the resends may not have shown up in his tool. I
>> should have bumped the version number instead.
>>
>> I'll see if my latest version still applies cleanly ...
> Many thanks!
>
> Would be nice to see it finally go in.
My last version (v9) still applies, but that one still threw a sparse 
warning for patch 2:

Link:https://lore.kernel.org/all/202208231319.Ng5RTzzg-lkp@intel.com

Not sure how to treat that one - rdb_CylBlocks is not declared as big 
endian so the warning is correct, but as far as I can see, for all 
practical purposes rdb_CylBlocks would be expected to be in big endian 
order (partition usually prepared on a big endian system)?

I can drop the be32_to_cpu conversion (and would expect to see a warning 
printed on little endian systems), or force the cast to __be32. Or 
rather drop that consistency check outright...

Cheers,

     Michael

>
> Best,