All of lore.kernel.org
 help / color / mirror / Atom feed
From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"julien.grall@arm.com" <julien.grall@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [Xen-devel] [PATCH v5 2/7] xen/arm: make process_memory_node a device_tree_node_func
Date: Thu, 15 Aug 2019 11:20:27 +0000	[thread overview]
Message-ID: <875zmyhdzi.fsf@epam.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1908141528250.8737@sstabellini-ThinkPad-T480s>


Hi Stefano,

Stefano Stabellini writes:

> On Tue, 13 Aug 2019, Volodymyr Babchuk wrote:
>> > @@ -162,6 +156,10 @@ static void __init process_memory_node(const void *fdt, int node,
>> >          bootinfo.mem.bank[bootinfo.mem.nr_banks].size = size;
>> >          bootinfo.mem.nr_banks++;
>> >      }
>> > +
>> > +    if ( bootinfo.mem.nr_banks == NR_MEM_BANKS )
>> > +        return -ENOSPC;
>> Are you sure that this logic is correct?
>>
>> For example, if NR_MEM_BANKS is 1, and we have exactly one memory node
>> in device tree, this function will fail. But it should not. I think you
>> want this condition: bootinfo.mem.nr_banks > NR_MEM_BANKS
>
> You are right, if NR_MEM_BANKS is 1 and we have 1 memory node in device
> tree the code would return an error while actually it is normal.
>
> I think the right check would be:
>
>   if ( i < banks && bootinfo.mem.nr_banks == NR_MEM_BANKS )
>       return -ENOSPC;

Actually, this does not cover all corner cases. Here is the resulting
code:

 150     for ( i = 0; i < banks && bootinfo.mem.nr_banks < NR_MEM_BANKS; i++ )
 151     {
 152         device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
 153         if ( !size )
 154             continue;
 155         bootinfo.mem.bank[bootinfo.mem.nr_banks].start = start;
 156         bootinfo.mem.bank[bootinfo.mem.nr_banks].size = size;
 157         bootinfo.mem.nr_banks++;
 158     }
 159
 160     if ( i < banks && bootinfo.mem.nr_banks == NR_MEM_BANKS )
 161         return -ENOSPC;

Lines 153-154 cause the issue.

Imagine that NR_MEM_BANKS = 1 and we have two memory nodes in device
tree with. Nodes have sizes 0 and 1024. Your code will work as
intended. At the end of loop we will have banks = 2, i = 2 and
bootinfo.mem.nr_banks = 1.

But if we switch order of memory nodes, so first one will be with size
1024 and second one with size 0, your code will return -ENOSPC, because
we'll have banks = 2, i = 1, bootinfo.mem.nr_banks = 1.

I think, right solution will be to scan all nodes to count nodes
with size > 0. And then - either return an error or do second loop to
fill bootinfo.mem.bank[].

>
> (That's because it is impossible to get to nr_banks > NR_MEM_BANKS.)
Yes, this is my mistake.

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

  parent reply	other threads:[~2019-08-15 11:21 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-12 22:28 [Xen-devel] [PATCH v5 0/7] reserved-memory in dom0 Stefano Stabellini
2019-08-12 22:28 ` [Xen-devel] [PATCH v5 1/7] xen/arm: pass node to device_tree_for_each_node Stefano Stabellini
2019-08-13 13:45   ` Volodymyr Babchuk
2019-08-14 22:12     ` Stefano Stabellini
2019-08-13 17:25   ` Julien Grall
2019-08-14 22:11     ` Stefano Stabellini
2019-08-12 22:28 ` [Xen-devel] [PATCH v5 2/7] xen/arm: make process_memory_node a device_tree_node_func Stefano Stabellini
2019-08-13 14:14   ` Volodymyr Babchuk
2019-08-14 22:35     ` Stefano Stabellini
2019-08-15  9:12       ` Julien Grall
2019-08-15 11:20       ` Volodymyr Babchuk [this message]
2019-08-15 11:24         ` Julien Grall
2019-08-15 11:29           ` Julien Grall
2019-08-15 12:14             ` Volodymyr Babchuk
2019-08-15 12:33               ` Julien Grall
2019-08-15 13:51                 ` Volodymyr Babchuk
2019-08-15 14:15                   ` Julien Grall
2019-08-13 17:37   ` Julien Grall
2019-08-14 22:54     ` Stefano Stabellini
2019-08-12 22:28 ` [Xen-devel] [PATCH v5 3/7] xen/arm: keep track of reserved-memory regions Stefano Stabellini
2019-08-13 14:23   ` Volodymyr Babchuk
2019-08-13 14:46     ` Julien Grall
2019-08-13 15:14       ` Volodymyr Babchuk
2019-08-13 15:15         ` Julien Grall
2019-08-13 15:39           ` Volodymyr Babchuk
2019-08-14 12:48   ` Julien Grall
2019-08-12 22:28 ` [Xen-devel] [PATCH v5 4/7] xen/arm: early_print_info print reserved_mem Stefano Stabellini
2019-08-13 14:28   ` Volodymyr Babchuk
2019-08-13 14:47     ` Julien Grall
2019-08-14 22:21       ` Stefano Stabellini
2019-08-14 12:52   ` Julien Grall
2019-08-12 22:28 ` [Xen-devel] [PATCH v5 5/7] xen/arm: handle reserved-memory in consider_modules and dt_unreserved_regions Stefano Stabellini
2019-08-12 22:28 ` [Xen-devel] [PATCH v5 6/7] xen/arm: don't iomem_permit_access for reserved-memory regions Stefano Stabellini
2019-08-13 14:34   ` Volodymyr Babchuk
2019-08-13 14:55     ` Julien Grall
2019-08-14 22:40       ` Stefano Stabellini
2019-08-15  9:15         ` Julien Grall
2019-08-12 22:28 ` [Xen-devel] [PATCH v5 7/7] xen/arm: add reserved-memory regions to the dom0 memory node Stefano Stabellini

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=875zmyhdzi.fsf@epam.com \
    --to=volodymyr_babchuk@epam.com \
    --cc=julien.grall@arm.com \
    --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.