[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190617212605.bb8cc4571ee67879033e1bc4@linux-foundation.org>
Date: Mon, 17 Jun 2019 21:26:05 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Nadav Amit <namit@...are.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
stable@...r.kernel.org, Borislav Petkov <bp@...e.de>,
Toshi Kani <toshi.kani@....com>,
Peter Zijlstra <peterz@...radead.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Dan Williams <dan.j.williams@...el.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH 1/3] resource: Fix locking in find_next_iomem_res()
On Wed, 12 Jun 2019 21:59:01 -0700 Nadav Amit <namit@...are.com> wrote:
> Since resources can be removed, locking should ensure that the resource
> is not removed while accessing it. However, find_next_iomem_res() does
> not hold the lock while copying the data of the resource.
Looks right to me.
> Keep holding the lock while the data is copied. While at it, change the
> return value to a more informative value. It is disregarded by the
> callers.
The kerneldoc needs a resync:
--- a/kernel/resource.c~resource-fix-locking-in-find_next_iomem_res-fix
+++ a/kernel/resource.c
@@ -326,7 +326,7 @@ EXPORT_SYMBOL(release_resource);
*
* 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 or -EINVAL for other invalid parameters.
+ * -ENODEV. Returns -EINVAL for invalid parameters.
*
* This function walks the whole tree and not just first level children
* unless @first_lvl is true.
_
Powered by blists - more mailing lists