All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Woods <brian.woods@xilinx.com>
To: Julien Grall <julien.grall@arm.com>
Cc: Brian Woods <brian.woods@xilinx.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] xen/arm: add warning if memory modules overlap
Date: Fri, 11 Oct 2019 11:06:13 -0700	[thread overview]
Message-ID: <20191011180612.GA19987@xilinx.com> (raw)
In-Reply-To: <b623fddb-9ab6-d9ef-0d66-93e465ee64c6@arm.com>

On Fri, Oct 11, 2019 at 05:58:35PM +0100, Julien Grall wrote:
> Hi,
> 
> Please at least remove the signature in the e-mail you reply to. The best
> would be to trim the e-mail and answer right below the specific paragraph.
> 
> >
> >To make sure the module is going to get added, you'd need to do the
> >check after the for loop.  This means there's going to be multiple for
> >loops just spread over the course of adding the boot modules rather than
> >one place.
> 
> I don't think you need to do the check after the loop. The only way to go
> out of the loop in add_boot_module() is when i reached mods->nr_mods.

See below.

> >
> >I had this before but decided against it but after changing it to both
> >starts rather than the stand and end (ends look much uglier), it looks
> >cleaner.
> >
> >     for ( i = 0 ; i < mods->nr_mods-1; i++ )
> >         for ( j = i+1 ; j < mods->nr_mods; j++ )
> >             if ( ((mods->module[i].start >= mods->module[j].start) &&
> >                   (mods->module[i].start <=
> >                    mods->module[j].start + mods->module[j].size)) ||
> >                  ((mods->module[j].start >= mods->module[i].start) &&
> >                   (mods->module[j].start <=
> >                    mods->module[i].start + mods->module[i].size)) )
> >                 printk("WARNING: modules %-12s and %-12s overlap\n",
> >                        boot_module_kind_as_string(mods->module[i].kind),
> >                        boot_module_kind_as_string(mods->module[j].kind));
> >
> >That's also a possibility.
> >
> >I just don't see a way around it, computationally.  You can split where
> >the loops are executed but in the end the same amount of checks/total
> >iterations have to be run.
> >
> >I was talking to someone and he suggested you could just check Xen at
> >early boot and then check other modules later.
> 
> What's wrong with:
> 
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 705a917abf..ecd09ec698 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -254,6 +254,10 @@ struct bootmodule __init
> *add_boot_module(bootmodule_kind kind,
>                  mod->domU = false;
>              return mod;
>          }
> +
> +        if ((mod->start >= start) &&
> +            (mod->start < (start + size)))
> +            printk("WARNING: modules...\n");
>      }
> 
>      mod = &mods->module[mods->nr_mods++];
> 
> Cheers,
> 
> -- 
> Julien Grall

For that, you'd need to either check the start and end of the added
module or the start of both.  So something like:

if ( ((mod->start >= start) && (mod->start < (start + size))) ||
     ((start >= mod->start) && (start < (mod->start + mod->size))) )
    printk("WARNING: ...");

If you don't you run the risk of having a module overlap but not at the
start of the added module (unless there's a guaranteed order).  You're
still running all of the checks from what I can tell, just not in nested
for loop so. Plus I'm not sure how many times add_boot_module gets run
and the "mod->kind == kind .." if statement gets run and is true.
If the above is true, wouldn't that cause extra checks for the for loop
iterations before it was true?

Brian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-10-11 18:06 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-09 19:47 [Xen-devel] [PATCH] xen/arm: add warning if memory modules overlap Brian Woods
2019-10-10 15:39 ` Julien Grall
2019-10-11 16:43   ` Brian Woods
2019-10-11 16:58     ` Julien Grall
2019-10-11 18:06       ` Brian Woods [this message]
2019-10-11 18:17         ` Julien Grall
2019-10-11 19:07           ` Brian Woods
2019-10-17  9:20             ` Julien Grall
2019-10-17 19:48               ` Brian Woods
2019-10-17 20:23                 ` Julien Grall
2019-10-17 20:07 ` [Xen-devel] [PATCH v2] " Brian Woods
2019-10-17 20:34   ` Julien Grall
2019-10-17 21:20     ` Brian Woods
2019-10-17 21:49       ` Julien Grall
2019-10-17 22:34         ` Brian Woods
2019-10-18 15:41           ` Julien Grall

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=20191011180612.GA19987@xilinx.com \
    --to=brian.woods@xilinx.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=julien.grall@arm.com \
    --cc=julien@xen.org \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.