[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y3vJQkc40o5zfM5v@ziepe.ca>
Date: Mon, 21 Nov 2022 14:53:54 -0400
From: Jason Gunthorpe <jgg@...pe.ca>
To: "Fabio M. De Francesco" <fmdefrancesco@...il.com>
Cc: Li Zhijian <lizhijian@...itsu.com>,
Zhu Yanjun <zyjzyj2000@...il.com>,
Leon Romanovsky <leon@...nel.org>, linux-rdma@...r.kernel.org,
linux-kernel@...r.kernel.org, Ira Weiny <ira.weiny@...el.com>
Subject: Re: [for-next PATCH 4/5] RDMA/rxe: refactor iova_to_vaddr
On Wed, Nov 16, 2022 at 01:37:14PM +0100, Fabio M. De Francesco wrote:
> > - return (void *)(uintptr_t)mr->map[m]->buf[n].addr + offset;
> > + if (mr->ibmr.type == IB_MR_TYPE_USER) {
> > + char *paddr;
> > + struct page *pg = mr->map[m]->buf[n].page;
> > +
> > + paddr = kmap_local_page(pg);
> > + if (paddr == NULL) {
> > + pr_warn("Failed to map page");
> > + return NULL;
> > + }
>
> I know nothing about this code but I am here as a result of regular checks for
> changes to HIGHMEM mappings across the entire kernel. So please forgive me if
> I'm objecting to the correct changes.
>
> 1) It looks like this code had a call to page_address() and you converted it
> to mapping with kmap_local_page().
It only worked properly because the kconfig is blocking CONFIG_HIGHMEM
so ZONE_HIGHMEM doesn't exist. These pages are obtained from GUP and
could be anything.
This is done indirectly through
config INFINIBAND_VIRT_DMA
def_bool !HIGHMEM
But this patch is undoing parts of what are causing that restriction
by using the proper APIs. Though I'm not sure if we can eventually get
to remove it for RXE completely.
Jason
Powered by blists - more mailing lists