linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
To: "NeilBrown" <neilb@suse.de>
Cc: "Jes Sorensen" <jes@trained-monkey.org>,
	"Paul Menzel" <pmenzel@molgen.mpg.de>,
	linux-raid@vger.kernel.org
Subject: Re: [PATCH mdadm v2] super1: report truncated device
Date: Thu, 25 Aug 2022 09:59:17 +0200	[thread overview]
Message-ID: <20220825095917.00002549@linux.intel.com> (raw)
In-Reply-To: <166138706173.27490.18440987438153337183@noble.neil.brown.name>

On Thu, 25 Aug 2022 10:24:21 +1000
"NeilBrown" <neilb@suse.de> wrote:

> On Thu, 25 Aug 2022, Jes Sorensen wrote:
> > On 7/25/22 03:42, Mariusz Tkaczyk wrote:  
> > > On Sat, 23 Jul 2022 14:37:11 +1000
> > > "NeilBrown" <neilb@suse.de> wrote:
> > >   
> > >> On Thu, 21 Jul 2022, Mariusz Tkaczyk wrote:  
> > >>> Hi Neil,
> > >>>
> > >>> On Wed, 13 Jul 2022 13:48:11 +1000
> > >>> "NeilBrown" <neilb@suse.de> wrote:  
> > ....  
> > >>> why not just:
> > >>> if (__le64_to_cpu(super->data_offset) + __le64_to_cpu(super->data_size)
> > >>> > dsize) from my understanding, only this check matters.    
> > >>
> > >> It seemed safest to test both.  I don't remember the difference between  
> > >> ->size and ->data_size.  In getinfo_super1() we have    
> > >>
> > >> 	if (info->array.level <= 0)
> > >> 		data_size = __le64_to_cpu(sb->data_size);
> > >> 	else
> > >> 		data_size = __le64_to_cpu(sb->size);
> > >>
> > >> which suggests that either could be relevant.
> > >> I guess ->size should always be less than ->data_size.  But
> > >> load_super1() doesn't check that, so it isn't safe to assume it.  
> > > 
> > > Honestly, I don't understand why but I didn't realize that you are
> > > checking two different fields (size and data_size). I focused on
> > > understanding what is going on  here, and didn't catch difference in
> > > variables (because data_offset and data_size have similar prefix).
> > > For me, something like:
> > > 
> > > unsigned long long _size;
> > > if (st->minor_version >= 1 && st->ignore_hw_compat == 0)
> > >     _size= __le64_to_cpu(super->size);
> > > else
> > >     _size= __le64_to_cpu(super->data_size);
> > > 
> > > if (__le64_to_cpu(super->data_offset) + _size > dsize)
> > > {....}
> > > 
> > > is more readable because I don't need to analyze complex if to get the
> > > difference. Also, I removed doubled __le64_to_cpu(super->data_offset).
> > > Could you refactor this part?  
> > 
> > What is the consensus on this discussion? I see Coly pulled this into
> > his tree, but I don't see Mariusz's last concern being addressed.  
> 
> I don't think we reached a consensus.  I probably got distracted.
> I don't like that suggestion from Mariusz as it makes assumptions that I
> didn't want to make.  I think it is safest to always test dsize against
> bother ->size and ->data_size without baking in assumptions about when
> either is meaningful.
> 
Hi Neil,
It seems that I failed to understand it again. You are right, you approach is
safer. Please fix stylistic issues then and I'm fine with the change.

Sorry for confusing you,
Mariusz


  reply	other threads:[~2022-08-25  7:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-12  1:00 [PATCH mdadm] super1: report truncated device NeilBrown
     [not found] ` <cff69e79-d681-c9d6-c719-8b10999a558a@molgen.mpg.de>
2022-07-13  3:48   ` [PATCH mdadm v2] " NeilBrown
2022-07-21  8:19     ` Mariusz Tkaczyk
2022-07-21 16:21       ` Ternary Operator (was: [PATCH mdadm v2] super1: report truncated device) Paul Menzel
2022-07-22  6:55         ` Mariusz Tkaczyk
2022-07-23  4:37       ` [PATCH mdadm v2] super1: report truncated device NeilBrown
2022-07-25  7:42         ` Mariusz Tkaczyk
2022-08-24 15:58           ` Jes Sorensen
2022-08-25  0:24             ` NeilBrown
2022-08-25  7:59               ` Mariusz Tkaczyk [this message]
2022-08-25 13:42                 ` Jes Sorensen
2022-08-25 22:55                   ` [PATCH v3] " NeilBrown
2022-08-29 15:46                     ` Jes Sorensen

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=20220825095917.00002549@linux.intel.com \
    --to=mariusz.tkaczyk@linux.intel.com \
    --cc=jes@trained-monkey.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=pmenzel@molgen.mpg.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;
as well as URLs for NNTP newsgroup(s).