public inbox for linux-m68k@lists.linux-m68k.org
 help / color / mirror / Atom feed
From: Michael Schmitz <schmitzmic@gmail.com>
To: Finn Thain <fthain@linux-m68k.org>
Cc: Martin Steigerwald <martin@lichtvoll.de>,
	Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org, linux-m68k@vger.kernel.org,
	geert@linux-m68k.org, Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH v7 2/2] block: add overflow checks for Amiga partition support
Date: Wed, 14 Jun 2023 13:20:35 +1200	[thread overview]
Message-ID: <12c29812-4afe-96d7-5fc2-15573ea571fd@gmail.com> (raw)
In-Reply-To: <437adeb4-160c-38a9-68af-ff4ec7454f5c@linux-m68k.org>

Hi Finn,

On 14/06/23 12:07, Finn Thain wrote:
> On Wed, 14 Jun 2023, Michael Schmitz wrote:
>
>> 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...
>>
> The new warning comes from this new code:
>
> 		if (cylblk > be32_to_cpu((__be32)rdb->rdb_CylBlocks)) {
> 			pr_warn("Dev %s: cylblk %u > rdb_CylBlocks %u!\n",
> 				state->disk->disk_name, cylblk,
> 				be32_to_cpu(rdb->rdb_CylBlocks));
> 		}
>
> The __be32 cast appears in the first line but not the fourth, which is an
> inconsistency you might want to tidy up. However, both lines produce the
> same sparse warning here.

Thanks for checking that - the cast is redundant as-is (be32_to_cpu() 
contains the same cast already). Does use of (__force __be32) instead 
make the warning go away? (I haven't managed to get sparse working for 
me, so I have no way of checking.)

> The inconsistent use of big-endian and native-endian members in struct
> RigidDiskBlock looks like the root cause to me but I know nothing about
> Amiga partition maps so I'm not going to guess.

The check appeared in the first version of the patch, after discussion 
around the RFC version at length. Going over that thread again, I 
haven't found why that check was added. It's probably been out of an 
overabundance of caution (as I know little about RDB, too) and can 
probably be removed.

Cheers,

     Michael



  reply	other threads:[~2023-06-14  1:20 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1539570747-19906-1-git-send-email-schmitzmic@gmail.com>
     [not found] ` <1539570747-19906-3-git-send-email-schmitzmic@gmail.com>
2022-07-25 12:36   ` [PATCH v7 2/2] block: add overflow checks for Amiga partition support Martin Steigerwald
2022-07-25 23:03     ` Jens Axboe
2022-07-26  1:53       ` Michael Schmitz
2022-07-26  3:40         ` Jens Axboe
2022-07-26  3:58           ` Michael Schmitz
2022-08-21 20:59             ` Martin Steigerwald
2022-08-22  5:46               ` Michael Schmitz
2022-08-22 13:57                 ` Jens Axboe
2022-08-22 20:39                   ` Michael Schmitz
2022-08-22 20:41                     ` Jens Axboe
2022-08-22 20:56                       ` Michael Schmitz
2023-06-13  7:25                         ` Martin Steigerwald
2023-06-13  8:18                           ` Michael Schmitz
2023-06-13 10:57                             ` Martin Steigerwald
2023-06-13 22:11                               ` Michael Schmitz
2023-06-14  0:07                                 ` Finn Thain
2023-06-14  1:20                                   ` Michael Schmitz [this message]
2023-06-14  7:19                                 ` Martin Steigerwald
2023-06-14  8:43                                   ` Michael Schmitz
     [not found]                                     ` <05bd2c1b-a985-d935-a955-06a048d54c18@earthlink.net>
2023-06-14 19:46                                       ` Michael Schmitz
2023-06-15  0:13                                     ` Finn Thain
2023-06-15  1:06                                       ` Michael Schmitz
2023-06-15  4:28                                       ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=12c29812-4afe-96d7-5fc2-15573ea571fd@gmail.com \
    --to=schmitzmic@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=fthain@linux-m68k.org \
    --cc=geert@linux-m68k.org \
    --cc=hch@infradead.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-m68k@vger.kernel.org \
    --cc=martin@lichtvoll.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox