From: Steve Magnani <steve.magnani@digidescorp.com>
To: Jan Kara <jack@suse.cz>
Cc: Jan Kara <jack@suse.com>,
linux-kernel@vger.kernel.org,
"Steven J . Magnani" <steve@digidescorp.com>
Subject: Re: [PATCH] udf: Fix 64-bit sign extension issues affecting blocks > 0x7FFFFFFF
Date: Tue, 10 Oct 2017 22:30:30 -0500 [thread overview]
Message-ID: <d4475684-55bd-b951-adaf-3f687b620d02@digidescorp.com> (raw)
In-Reply-To: <20171010073307.GA775@quack2.suse.cz>
Jan -
On 10/10/2017 02:33 AM, Jan Kara wrote:
> On Mon 09-10-17 10:04:52, Steve Magnani wrote:
>
> ...the patch seems to be mixing two changes into one which I'd prefer to be
> separate patches:
>
> 1) Changes so that physical block numbers are stored in uint32_t (and
> accompanying format string changes). Also when doing this, could you please
> create a dedicated type like
>
> typedef uint32_t udf_pblk_t;
>
> and use it instead of uint32_t? That way it would be cleaner what's going
> on. Thanks!
I agree with this in principle and in fact do something like it in my
application code for just that reason. But, doing a complete job of this
in the driver would increase the scope far beyond what is needed to fix
the bugs I see and beyond what I am able to support. Would it be
acceptable to limit usage of this type to a subset of the places it
could ultimately be used? (Example: use it in udf_readdir(), which has a
bug requiring a type change, but not necessarily in udf_read_tagged(),
which doesn't).
> 2) Changes fixing signedness in various format strings for various types -
> put these in a separare patch please.
Sure - but would you be opposed to putting _all_ of the format string
changes in that patch? There are some format string changes (i.e., in
unicode.c) that obviously don't have anything to do with block numbers,
but I think almost all of the rest do. It gets a little murky when block
numbers or counts are used in calculations. The unifying idea behind all
the format string changes is preventing sign extension from causing
unsigned values to be printed as negative, so on that basis I think an
argument can be made that they all "go" together.
>> --- a/fs/udf/balloc.c (revision 26779)
>> +++ b/fs/udf/balloc.c (working copy)
> ...
>> @@ -151,7 +151,7 @@
>> bh = bitmap->s_block_bitmap[bitmap_nr];
>> for (i = 0; i < count; i++) {
>> if (udf_set_bit(bit + i, bh->b_data)) {
>> - udf_debug("bit %ld already set\n", bit + i);
>> + udf_debug("bit %lu already set\n", bit + i);
> This change looks wrong - bit and i are signed. However they are ints, not
> longs, so that should indeed be fixed.
'bit' and 'i' are ints in the function _below_ this change, but unsigned
long within this function. So I think this is correct.
Regards,
------------------------------------------------------------------------
Steven J. Magnani "I claim this network for MARS!
www.digidescorp.com Earthling, return my space modulator!"
#include <standard.disclaimer>
next prev parent reply other threads:[~2017-10-11 3:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-09 15:04 Steve Magnani
2017-10-10 7:33 ` Jan Kara
2017-10-11 3:30 ` Steve Magnani [this message]
2017-10-11 8:27 ` Jan Kara
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=d4475684-55bd-b951-adaf-3f687b620d02@digidescorp.com \
--to=steve.magnani@digidescorp.com \
--cc=jack@suse.com \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=steve@digidescorp.com \
/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
all inboxes | Powered by JetHome®