From: lijiang <lijiang@redhat.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: thomas.lendacky@amd.com, brijesh.singh@amd.com,
akpm@linux-foundation.org, bhe@redhat.com, tiwai@suse.de,
x86@kernel.org, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, mingo@redhat.com,
baiyaowei@cmss.chinamobile.com, hpa@zytor.com,
dan.j.williams@intel.com, bp@suse.de, dyoung@redhat.com,
tglx@linutronix.de, Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [PATCH 3/3] resource: Fix find_next_iomem_res() iteration issue
Date: Fri, 28 Sep 2018 13:09:37 +0800 [thread overview]
Message-ID: <caec9ff1-f654-b4ea-ae3b-78ff2d073ee5@redhat.com> (raw)
In-Reply-To: <20180927140351.GA257735@bhelgaas-glaptop.roam.corp.google.com>
在 2018年09月27日 22:03, Bjorn Helgaas 写道:
> On Thu, Sep 27, 2018 at 01:27:41PM +0800, lijiang wrote:
>> 在 2018年09月25日 06:15, Bjorn Helgaas 写道:
>>> From: Bjorn Helgaas <bhelgaas@google.com>
>>>
>>> Previously find_next_iomem_res() used "*res" as both an input parameter for
>>> the range to search and the type of resource to search for, and an output
>>> parameter for the resource we found, which makes the interface confusing
>>> and hard to use correctly.
>>>
>>> All callers allocate a single struct resource and use it for repeated calls
>>> to find_next_iomem_res(). When find_next_iomem_res() returns a resource,
>>> it overwrites the start, end, flags, and desc members of the struct. If we
>>> call find_next_iomem_res() again, we must update or restore these fields.
>>>
>>> The callers (__walk_iomem_res_desc() and walk_system_ram_range()) do not
>>> restore res->flags, so if the caller is searching for flags of
>>> IORESOURCE_MEM | IORESOURCE_BUSY and finds a resource with flags of
>>> IORESOURCE_MEM | IORESOURCE_BUSY | IORESOURCE_SYSRAM, the next search will
>>> find only resources marked as IORESOURCE_SYSRAM.
>>>
>>> Fix this by restructuring the interface so it takes explicit "start, end,
>>> flags" parameters and uses "*res" only as an output parameter.
>>
>> Hi, Bjorn
>> I personally suggest that some comments might be added in the code, make it clear
>> and easy to understand, then which could avoid the old confusion and more code changes.
>
> Since I think the current interface (using *res as both input and
> output parameters that have very different meanings) is confusing,
> it's hard for *me* to write comments that make it less confusing, but
> of course, you're welcome to propose something.
>
> My opinion (probably not universally shared) is that my proposal would
> make the code more readable, and it's worth doing even though the diff
> is larger.
>
> Anyway, I'll post these patches independently and see if anybody else
> has an opinion.
>
I don't mind at all, because that is just my own opinion about more code
changes.
Anyway, thank you to improve this patch.
Regards,
Lianbo
> Bjorn
>
>>> Original-patch: http://lore.kernel.org/lkml/20180921073211.20097-2-lijiang@redhat.com
>>> Based-on-patch-by: Lianbo Jiang <lijiang@redhat.com>
>>> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>>> ---
>>> kernel/resource.c | 94 +++++++++++++++++++++++------------------------------
>>> 1 file changed, 41 insertions(+), 53 deletions(-)
>>>
>>> diff --git a/kernel/resource.c b/kernel/resource.c
>>> index 155ec873ea4d..9891ea90cc8f 100644
>>> --- a/kernel/resource.c
>>> +++ b/kernel/resource.c
>>> @@ -319,23 +319,26 @@ int release_resource(struct resource *old)
>>> EXPORT_SYMBOL(release_resource);
>>>
>>> /*
>>> - * Finds the lowest iomem resource existing within [res->start..res->end].
>>> - * The caller must specify res->start, res->end, res->flags, and optionally
>>> - * desc. If found, returns 0, res is overwritten, if not found, returns -1.
>>> - * This function walks the whole tree and not just first level children until
>>> - * and unless first_level_children_only is true.
>>> + * Finds the lowest iomem resource that covers part of [start..end]. The
>>> + * caller must specify start, end, flags, and desc (which may be
>>> + * IORES_DESC_NONE).
>>> + *
>>> + * If a resource is found, returns 0 and *res is overwritten with the part
>>> + * of the resource that's within [start..end]; if none is found, returns
>>> + * -1.
>>> + *
>>> + * This function walks the whole tree and not just first level children
>>> + * unless first_level_children_only is true.
>>> */
>>> -static int find_next_iomem_res(struct resource *res, unsigned long desc,
>>> - bool first_level_children_only)
>>> +static int find_next_iomem_res(resource_size_t start, resource_size_t end,
>>> + unsigned long flags, unsigned long desc,
>>> + bool first_level_children_only,
>>> + struct resource *res)
>>> {
>>> - resource_size_t start, end;
>>> struct resource *p;
>>> bool sibling_only = false;
>>>
>>> BUG_ON(!res);
>>> -
>>> - start = res->start;
>>> - end = res->end;
>>> BUG_ON(start >= end);
>>>
>>> if (first_level_children_only)
>>> @@ -344,7 +347,7 @@ static int find_next_iomem_res(struct resource *res, unsigned long desc,
>>> read_lock(&resource_lock);
>>>
>>> for (p = iomem_resource.child; p; p = next_resource(p, sibling_only)) {
>>> - if ((p->flags & res->flags) != res->flags)
>>> + if ((p->flags & flags) != flags)
>>> continue;
>>> if ((desc != IORES_DESC_NONE) && (desc != p->desc))
>>> continue;
>>> @@ -359,32 +362,31 @@ static int find_next_iomem_res(struct resource *res, unsigned long desc,
>>> read_unlock(&resource_lock);
>>> if (!p)
>>> return -1;
>>> +
>>> /* copy data */
>>> - if (res->start < p->start)
>>> - res->start = p->start;
>>> - if (res->end > p->end)
>>> - res->end = p->end;
>>> + res->start = max(start, p->start);
>>> + res->end = min(end, p->end);
>>> res->flags = p->flags;
>>> res->desc = p->desc;
>>> return 0;
>>> }
>>>
>>> -static int __walk_iomem_res_desc(struct resource *res, unsigned long desc,
>>> - bool first_level_children_only,
>>> - void *arg,
>>> +static int __walk_iomem_res_desc(resource_size_t start, resource_size_t end,
>>> + unsigned long flags, unsigned long desc,
>>> + bool first_level_children_only, void *arg,
>>> int (*func)(struct resource *, void *))
>>> {
>>> - u64 orig_end = res->end;
>>> + struct resource res;
>>> int ret = -1;
>>>
>>> - while ((res->start < res->end) &&
>>> - !find_next_iomem_res(res, desc, first_level_children_only)) {
>>> - ret = (*func)(res, arg);
>>> + while (start < end &&
>>> + !find_next_iomem_res(start, end, flags, desc,
>>> + first_level_children_only, &res)) {
>>> + ret = (*func)(&res, arg);
>>> if (ret)
>>> break;
>>>
>>> - res->start = res->end + 1;
>>> - res->end = orig_end;
>>> + start = res.end + 1;
>>> }
>>>
>>> return ret;
>>> @@ -407,13 +409,7 @@ static int __walk_iomem_res_desc(struct resource *res, unsigned long desc,
>>> int walk_iomem_res_desc(unsigned long desc, unsigned long flags, u64 start,
>>> u64 end, void *arg, int (*func)(struct resource *, void *))
>>> {
>>> - struct resource res;
>>> -
>>> - res.start = start;
>>> - res.end = end;
>>> - res.flags = flags;
>>> -
>>> - return __walk_iomem_res_desc(&res, desc, false, arg, func);
>>> + return __walk_iomem_res_desc(start, end, flags, desc, false, arg, func);
>>> }
>>> EXPORT_SYMBOL_GPL(walk_iomem_res_desc);
>>>
>>> @@ -427,13 +423,9 @@ EXPORT_SYMBOL_GPL(walk_iomem_res_desc);
>>> int walk_system_ram_res(u64 start, u64 end, void *arg,
>>> int (*func)(struct resource *, void *))
>>> {
>>> - struct resource res;
>>> -
>>> - res.start = start;
>>> - res.end = end;
>>> - res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
>>> + unsigned long flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
>>>
>>> - return __walk_iomem_res_desc(&res, IORES_DESC_NONE, true,
>>> + return __walk_iomem_res_desc(start, end, flags, IORES_DESC_NONE, true,
>>> arg, func);
>>> }
>>>
>>> @@ -444,13 +436,9 @@ int walk_system_ram_res(u64 start, u64 end, void *arg,
>>> int walk_mem_res(u64 start, u64 end, void *arg,
>>> int (*func)(struct resource *, void *))
>>> {
>>> - struct resource res;
>>> -
>>> - res.start = start;
>>> - res.end = end;
>>> - res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
>>> + unsigned long flags = IORESOURCE_MEM | IORESOURCE_BUSY;
>>>
>>> - return __walk_iomem_res_desc(&res, IORES_DESC_NONE, true,
>>> + return __walk_iomem_res_desc(start, end, flags, IORES_DESC_NONE, true,
>>> arg, func);
>>> }
>>>
>>> @@ -464,25 +452,25 @@ int walk_mem_res(u64 start, u64 end, void *arg,
>>> int walk_system_ram_range(unsigned long start_pfn, unsigned long nr_pages,
>>> void *arg, int (*func)(unsigned long, unsigned long, void *))
>>> {
>>> + resource_size_t start, end;
>>> + unsigned long flags;
>>> struct resource res;
>>> unsigned long pfn, end_pfn;
>>> - u64 orig_end;
>>> int ret = -1;
>>>
>>> - res.start = (u64) start_pfn << PAGE_SHIFT;
>>> - res.end = ((u64)(start_pfn + nr_pages) << PAGE_SHIFT) - 1;
>>> - res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
>>> - orig_end = res.end;
>>> - while ((res.start < res.end) &&
>>> - (find_next_iomem_res(&res, IORES_DESC_NONE, true) >= 0)) {
>>> + start = (u64) start_pfn << PAGE_SHIFT;
>>> + end = ((u64)(start_pfn + nr_pages) << PAGE_SHIFT) - 1;
>>> + flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
>>> + while (start < end &&
>>> + !find_next_iomem_res(start, end, flags, IORES_DESC_NONE,
>>> + true, &res)) {
>>> pfn = (res.start + PAGE_SIZE - 1) >> PAGE_SHIFT;
>>> end_pfn = (res.end + 1) >> PAGE_SHIFT;
>>> if (end_pfn > pfn)
>>> ret = (*func)(pfn, end_pfn - pfn, arg);
>>> if (ret)
>>> break;
>>> - res.start = res.end + 1;
>>> - res.end = orig_end;
>>> + start = res.end + 1;
>>> }
>>> return ret;
>>> }
>>>
>>>
>>> _______________________________________________
>>> kexec mailing list
>>> kexec@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/kexec
>>>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2018-09-28 5:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-21 7:32 [PATCH 0/3 v3] add reserved e820 ranges to the kdump kernel e820 table Lianbo Jiang
2018-09-21 7:32 ` [PATCH 1/3 v3] resource: fix an error which walks through iomem resources Lianbo Jiang
2018-09-24 17:52 ` Bjorn Helgaas
2018-09-25 7:08 ` lijiang
2018-09-24 22:14 ` [PATCH 0/3] find_next_iomem_res() fixes Bjorn Helgaas
2018-09-24 22:14 ` [PATCH 1/3] x86/kexec: Correct KEXEC_BACKUP_SRC_END off-by-one error Bjorn Helgaas
2018-09-24 22:14 ` [PATCH 2/3] resource: Include resource end in walk_*() interfaces Bjorn Helgaas
2018-09-24 22:15 ` [PATCH 3/3] resource: Fix find_next_iomem_res() iteration issue Bjorn Helgaas
2018-09-25 8:58 ` Baoquan He
2018-09-25 11:20 ` Baoquan He
2018-09-27 5:27 ` lijiang
2018-09-27 14:03 ` Bjorn Helgaas
2018-09-28 5:09 ` lijiang [this message]
2018-09-28 13:10 ` Borislav Petkov
2018-09-26 9:22 ` [PATCH 0/3] find_next_iomem_res() fixes lijiang
2018-09-26 13:36 ` lijiang
2018-09-21 7:32 ` [PATCH 2/3 v3] x86/kexec_file: add e820 entry in case e820 type string matches to io resource name Lianbo Jiang
2018-09-21 7:32 ` [PATCH 3/3 v3] x86/kexec_file: add reserved e820 ranges to kdump kernel e820 table Lianbo Jiang
2018-10-16 2:56 ` [PATCH 0/3 v3] add reserved e820 ranges to the " Dave Young
2018-10-16 3:45 ` lijiang
-- strict thread matches above, loose matches on Subject: below --
2018-09-27 14:21 [PATCH 0/3] find_next_iomem_res() fixes Bjorn Helgaas
2018-09-27 14:22 ` [PATCH 3/3] resource: Fix find_next_iomem_res() iteration issue Bjorn Helgaas
2018-09-28 16:41 ` Borislav Petkov
2018-10-09 17:30 ` Bjorn Helgaas
2018-10-09 17:35 ` Borislav Petkov
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=caec9ff1-f654-b4ea-ae3b-78ff2d073ee5@redhat.com \
--to=lijiang@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=baiyaowei@cmss.chinamobile.com \
--cc=bhe@redhat.com \
--cc=bp@suse.de \
--cc=brijesh.singh@amd.com \
--cc=dan.j.williams@intel.com \
--cc=dyoung@redhat.com \
--cc=helgaas@kernel.org \
--cc=hpa@zytor.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=tiwai@suse.de \
--cc=vgoyal@redhat.com \
--cc=x86@kernel.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