From: Masayoshi Mizuma <msys.mizuma@gmail.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: kexec mailing list <kexec@lists.infradead.org>,
Bhupesh Sharma <bhsharma@redhat.com>,
Simon Horman <horms@verge.net.au>,
James Morse <james.morse@arm.com>
Subject: Re: [PATCH v2 2/3] arm64: kexec: allocate memory space avoiding reserved regions
Date: Wed, 18 Dec 2019 10:08:48 -0500 [thread overview]
Message-ID: <20191218150848.anisllbuawkwolm6@gabell> (raw)
In-Reply-To: <20191218024849.GA7386@linaro.org>
On Wed, Dec 18, 2019 at 11:48:50AM +0900, AKASHI Takahiro wrote:
> On Mon, Dec 16, 2019 at 09:16:06AM -0500, Masayoshi Mizuma wrote:
> > On Mon, Dec 16, 2019 at 11:22:56AM +0530, Bhupesh Sharma wrote:
> > > Thanks Masa,
>
> [...]
>
> > > Since this is an old thread, it would be useful for people looking at
> > > the same, if you can add some comments/details about why you think
> > > this nit is needed.
> >
> > Thank you for your follow up and I'm sorry I didn't explain it.
> > mem_regions_alloc_and_exclude() may fail in case realloc() or
> > mem_region_exclude() fail, so it would be better to add the error
> > handling.
> >
> > >
> > > Also if Akashi agrees with the same, it would be better if he could
> > > send a rebased version of the patchset (with your comments addressed),
> > > so that the same can be picked for upstream kexec-tools cleanly.
> >
> > Sounds great!
>
> I have almost forgotten the background of this patch.
> If you see that it is still useful, please feel free to re-post it.
Thanks! I'll repost the patchset as v3.
- Masa
>
> Thanks,
> -Takahiro Akashi
>
> > - Masa
> >
> > >
> > > @Akashi- Hi Akashi, Please let us know your views.
> > >
> > > Thanks,
> > > Bhupesh
> > >
> > > > + dbgprintf("%s:- %016llx - %016llx\n",
> > > > > + __func__, start, end);
> > > > > + }
> > > > > + }
> > > > > +
> > > > > + fclose(fp);
> > > > > +
> > > > > + *range = memranges.ranges;
> > > > > + *ranges = memranges.size;
> > > > >
> > > > > /* As a fallback option, we can try determining the PHYS_OFFSET
> > > > > * value from the '/proc/iomem' entries as well.
> > > > > @@ -976,52 +1041,15 @@ static int get_memory_ranges_iomem_cb(void *data, int nr, char *str,
> > > > > * between the user-space and kernel space 'PHYS_OFFSET'
> > > > > * value.
> > > > > */
> > > > > - set_phys_offset(r->start, "iomem");
> > > > > + if (memranges.size)
> > > > > + set_phys_offset(memranges.ranges[0].start, "iomem");
> > > > >
> > > > > - dbgprintf("%s: %016llx - %016llx : %s", __func__, r->start,
> > > > > - r->end, str);
> > > > > + dbgprint_mem_range("System RAM ranges;",
> > > > > + memranges.ranges, memranges.size);
> > > > >
> > > > > return 0;
> > > > > }
> > > > >
> > > > > -/**
> > > > > - * get_memory_ranges_iomem - Try to get the memory ranges from
> > > > > - * /proc/iomem.
> > > > > - */
> > > > > -
> > > > > -static int get_memory_ranges_iomem(struct memory_range *array,
> > > > > - unsigned int *count)
> > > > > -{
> > > > > - *count = kexec_iomem_for_each_line(NULL,
> > > > > - get_memory_ranges_iomem_cb, array);
> > > > > -
> > > > > - if (!*count) {
> > > > > - dbgprintf("%s: failed: No RAM found.\n", __func__);
> > > > > - return EFAILED;
> > > > > - }
> > > > > -
> > > > > - return 0;
> > > > > -}
> > > > > -
> > > > > -/**
> > > > > - * get_memory_ranges - Try to get the memory ranges some how.
> > > > > - */
> > > > > -
> > > > > -int get_memory_ranges(struct memory_range **range, int *ranges,
> > > > > - unsigned long kexec_flags)
> > > > > -{
> > > > > - static struct memory_range array[KEXEC_SEGMENT_MAX];
> > > > > - unsigned int count;
> > > > > - int result;
> > > > > -
> > > > > - result = get_memory_ranges_iomem(array, &count);
> > > > > -
> > > > > - *range = result ? NULL : array;
> > > > > - *ranges = result ? 0 : count;
> > > > > -
> > > > > - return result;
> > > > > -}
> > > > > -
> > > > > int arch_compat_trampoline(struct kexec_info *info)
> > > > > {
> > > > > return 0;
> > > > > --
> > > > > 2.19.1
> > > > >
> > > > >
> > > >
> > >
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2019-12-18 15:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-11 9:59 [PATCH v2 0/3] arm64: handle "reserved" entries in /proc/iomem AKASHI Takahiro
2019-01-11 9:59 ` [PATCH v2 1/3] kexec: add variant helper functions for handling memory regions AKASHI Takahiro
2019-01-11 9:59 ` [PATCH v2 2/3] arm64: kexec: allocate memory space avoiding reserved regions AKASHI Takahiro
2019-12-13 20:04 ` Masayoshi Mizuma
2019-12-16 5:52 ` Bhupesh Sharma
2019-12-16 14:16 ` Masayoshi Mizuma
2019-12-18 2:48 ` AKASHI Takahiro
2019-12-18 15:08 ` Masayoshi Mizuma [this message]
2019-01-11 9:59 ` [PATCH v2 3/3] arm64: kdump: deal with a lot of resource entries in /proc/iomem AKASHI Takahiro
2019-01-13 11:36 ` [PATCH v2 0/3] arm64: handle "reserved" " Bhupesh Sharma
2019-12-13 19:53 ` Masayoshi Mizuma
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=20191218150848.anisllbuawkwolm6@gabell \
--to=msys.mizuma@gmail.com \
--cc=bhsharma@redhat.com \
--cc=horms@verge.net.au \
--cc=james.morse@arm.com \
--cc=kexec@lists.infradead.org \
--cc=takahiro.akashi@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox