linux-kernel - Re: [PATCH] grant-table: don't set m2p override if kmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131105145607.GB25836@phenom.dumpdata.com>
Date:	Tue, 5 Nov 2013 09:56:07 -0500
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Roger Pau Monné <roger.pau@...rix.com>
Cc:	David Vrabel <david.vrabel@...rix.com>, xen-devel@...ts.xen.org,
	linux-kernel@...r.kernel.org, Matt Wilson <msw@...zon.com>
Subject: Re: [PATCH] grant-table: don't set m2p override if kmap_ops is not
 set

On Tue, Nov 05, 2013 at 03:47:08PM +0100, Roger Pau Monné wrote:
> On 05/11/13 13:36, David Vrabel wrote:
> > On 05/11/13 11:24, Roger Pau Monne wrote:
> >> IMHO there's no reason to set a m2p override if the mapping is done in
> >> kernel space, so only set the m2p override when kmap_ops is set.
> > 
> > Can you provide a more detailed reasoning about why this is safe?
> 
> To tell the truth, I don't understand why we need to use the m2p
> override for kernel space only mappings, my understanding is that this
> m2p override is needed for user space mappings only (where we actually
> end up doing two mappings, one in kernel space and one in user space).
> For kernel space I don't see why we need to do anything else than
> setting the right p2m translation.

We needed the m2p when doing DMA operations. As the driver would
want the bus address (so p2m) and then when unmapping the DMA we
only get the bus address  - so we needed to do a m2p lookup.

But perhaps there is a better way to do this in the SWIOTLB code.

> 
> > Did you consider other ways of improving scalability?  e.g., a
> > per-bucket read-write lock.
> 
> Not really, the main focus of this patch is to optimize kernel space
> only mappings (like the ones done in blkback), so why go down this road
> when we can actually remove the need for a lock at all in this case?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/