[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/2] arm/xen: Add misuse warning to virt_to_gfn



On 26.08.20 20:37, Julien Grall wrote:
Hi Simon,

On 25/08/2020 10:31, Simon Leiner wrote:
As virt_to_gfn uses virt_to_phys, it will return invalid addresses when
used with vmalloc'd addresses. This patch introduces a warning, when
virt_to_gfn is used in this way.

Signed-off-by: Simon Leiner <simon@xxxxxxxxx>
---
  include/xen/arm/page.h | 6 +++++-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/xen/arm/page.h b/include/xen/arm/page.h
index d7f6af50e200..b0d303b633d0 100644
--- a/include/xen/arm/page.h
+++ b/include/xen/arm/page.h
@@ -76,7 +76,11 @@ static inline unsigned long bfn_to_pfn(unsigned long bfn)
  #define bfn_to_local_pfn(bfn)    bfn_to_pfn(bfn)
  /* VIRT <-> GUEST conversion */
-#define virt_to_gfn(v)        (pfn_to_gfn(virt_to_phys(v) >> XEN_PAGE_SHIFT)) +#define virt_to_gfn(v)                                                         \ + ({                                                                     \
+        WARN_ON_ONCE(is_vmalloc_addr(v));                              \

virt_to_gfn() will usually be called from generic code. WARN_ON_ONCE()

"Usually" is a bit gross here. The only generic call site I could find
is xenbus_grant_ring(). All other instances (I counted 22) are not
generic at all.

will only catch one instance and it means we would have to fix the first instance and then re-run to catch the others.

So I think we want to switch to WARN_ON() here.

No, please don't. In case there would be a frequent path the result
would be a basically unusable system due to massive console clobbering.


Juergen



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.