[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.2020 01:48, Stefano Stabellini wrote: > On Tue, 25 Aug 2020, Jan Beulich wrote: >> On 25.08.2020 11:31, Simon Leiner wrote: >>> --- 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)); \ >>> + pfn_to_gfn(virt_to_phys(v) >> XEN_PAGE_SHIFT); \ >>> + }) >> >> Shouldn't such a check cover more than just the vmalloc range, >> i.e. everything outside of what __va() can validly return? > > Keep in mind that this patch is meant as sister patch to > https://marc.info/?l=xen-devel&m=159834800203817 > so it makes sense to check for vmalloc addresses specifically. I had seen that patch before writing the reply, and I had assumed precisely what you say. It was for this reason that I did point out the limitation: While there's a specific issue for the vmalloc range, any other addresses outside the direct mapping area are as problematic (aiui). > That said, I am not aware of a good way to implement the __va test you > are suggesting. Hmm, to me __phys_to_virt() and __virt_to_phys_nodebug() give the impression that they're just linear transformations of the address, which would seem to suggest there's a pre-determined address range used for the direct map. Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |