| Message ID | 20180927101017.990471-1-arnd@arndb.de (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | RDMA/ucontext: fix building with CONFIG_MMU=n | expand |
On Thu, Sep 27, 2018 at 12:10:03PM +0200, Arnd Bergmann wrote: > The zap_vma_ptes() is declared but not defined on NOMMU kernels, > causing a link error for the newly added uverbs code: > > drivers/infiniband/core/uverbs_main.o: In function `uverbs_user_mmap_disassociate': > uverbs_main.c:(.text+0x114c): undefined reference to `zap_vma_ptes' > drivers/infiniband/core/uverbs_main.o: In function `rdma_umap_open': > uverbs_main.c:(.text+0x53c): undefined reference to `zap_vma_ptes' I'm a bit surprised by this - the code is not new, it just got moved out of the drivers, and I don't see any protections there against CONFIG_MMU ?? > To fix this, we can either make uverbs depend on CONFIG_MMU, or try > to build it anyway. Since this is the only compile-time dependency, > I decided to allow building it with an extra compile-time check for > CONFIG_MMU before calling the one function. Hrm. So this code doesn't work at all on NOMMU, it relies on remap_pfn_range, which always fails on those kernels, Due to this of this the entirety of INFINIBAND_USER_ACCESS is broken. I think a kconfig change is the better way to go? Jason
On Thu, Sep 27, 2018 at 6:26 PM Jason Gunthorpe <jgg@ziepe.ca> wrote: > > On Thu, Sep 27, 2018 at 12:10:03PM +0200, Arnd Bergmann wrote: > > The zap_vma_ptes() is declared but not defined on NOMMU kernels, > > causing a link error for the newly added uverbs code: > > > > drivers/infiniband/core/uverbs_main.o: In function `uverbs_user_mmap_disassociate': > > uverbs_main.c:(.text+0x114c): undefined reference to `zap_vma_ptes' > > drivers/infiniband/core/uverbs_main.o: In function `rdma_umap_open': > > uverbs_main.c:(.text+0x53c): undefined reference to `zap_vma_ptes' > > I'm a bit surprised by this - the code is not new, it just got moved > out of the drivers, and I don't see any protections there against > CONFIG_MMU ?? I think I just never hit those in my randconfig builds. Out of the three drivers, one is 64-bit only, and the others depend on PCI. The nommu configurations I'm testing in randconfig are all 32-bit without PCI. > > To fix this, we can either make uverbs depend on CONFIG_MMU, or try > > to build it anyway. Since this is the only compile-time dependency, > > I decided to allow building it with an extra compile-time check for > > CONFIG_MMU before calling the one function. > > Hrm. So this code doesn't work at all on NOMMU, it relies on > remap_pfn_range, which always fails on those kernels, > > Due to this of this the entirety of INFINIBAND_USER_ACCESS is broken. > > I think a kconfig change is the better way to go? Works for me. Can you just commit that yourself with 'Reported-by: Arnd Bergmann <arnd@arndb.de>' then? Arnd
diff --git a/drivers/infiniband/core/uverbs_main.c b/drivers/infiniband/core/uverbs_main.c index 40dcf3d02a4b..5c1202af0748 100644 --- a/drivers/infiniband/core/uverbs_main.c +++ b/drivers/infiniband/core/uverbs_main.c @@ -884,7 +884,8 @@ static void rdma_umap_open(struct vm_area_struct *vma) * point, so zap it. */ vma->vm_private_data = NULL; - zap_vma_ptes(vma, vma->vm_start, vma->vm_end - vma->vm_start); + if (IS_ENABLED(CONFIG_MMU)) + zap_vma_ptes(vma, vma->vm_start, vma->vm_end - vma->vm_start); } static void rdma_umap_close(struct vm_area_struct *vma) @@ -1023,8 +1024,9 @@ void uverbs_user_mmap_disassociate(struct ib_uverbs_file *ufile) continue; list_del_init(&priv->list); - zap_vma_ptes(vma, vma->vm_start, - vma->vm_end - vma->vm_start); + if (IS_ENABLED(CONFIG_MMU)) + zap_vma_ptes(vma, vma->vm_start, + vma->vm_end - vma->vm_start); vma->vm_flags &= ~(VM_SHARED | VM_MAYSHARE); } mutex_unlock(&ufile->umap_lock);
The zap_vma_ptes() is declared but not defined on NOMMU kernels, causing a link error for the newly added uverbs code: drivers/infiniband/core/uverbs_main.o: In function `uverbs_user_mmap_disassociate': uverbs_main.c:(.text+0x114c): undefined reference to `zap_vma_ptes' drivers/infiniband/core/uverbs_main.o: In function `rdma_umap_open': uverbs_main.c:(.text+0x53c): undefined reference to `zap_vma_ptes' To fix this, we can either make uverbs depend on CONFIG_MMU, or try to build it anyway. Since this is the only compile-time dependency, I decided to allow building it with an extra compile-time check for CONFIG_MMU before calling the one function. Fixes: 5f9794dc94f5 ("RDMA/ucontext: Add a core API for mmaping driver IO memory") Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- drivers/infiniband/core/uverbs_main.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)