linux-kernel - [RFC] iomap_atomic_prot

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 for Android: free password hash cracker in your pocket

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

Message-ID: <47D55CE0.3020402@tungstengraphics.com>
Date:	Mon, 10 Mar 2008 17:08:00 +0100
From:	Thomas Hellström <thomas@...gstengraphics.com>
To:	Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: [RFC] iomap_atomic_prot_pfn()

Hi!

For the new DRM graphics memory manager, there is a need to map and 
patch graphics command buffers from within the kernel. When the memory 
manager has sorted out where the buffers are located, the command stream 
and state buffers need to be patched up with references to the new 
locations. At this point, the buffers are usually located in graphics 
memory or bound to the AGP aperture.

So there is a need to do quick map - write - unmap of a single or 
possibly a pair of these pages, and it seems something like 
kmap_atomic() would be the best thing, in order to avoid IPI tlb flushing.
It seems like ioremap_nocache() is too slow, and it's not really an 
option to permanently map a large area of graphics memory or AGP 
aperture space.

So I've considered implementing something like the following:

void *iomap_atomic_prot_pfn(unsigned long pfn, enum km_type type,
                                                pgprot_t protection);

Initially at least on some architectures: x86 and ppc.

But there are some options:
1) Reuse the fixmap kmap_atomic KM_USER? and KM_IRQ? slots on 
architectures that support them, and add them to the fixmap of the other.
2) Add completely new fixmap slots on all architectures, starting with 
the ones listed above.
3) Don't do any of this, but allocate some permanent ptes using vmap() 
and hack those ptes within the driver when needed.

So basically I'm asking for some guidance on which is the preferred 
method to do this. Any comments appreciated.

/Thomas Hellström
Tungsten Graphics

--
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/