linux-kernel - Re: Adding kmap_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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20081024093233.GA20310@elte.hu>
Date:	Fri, 24 Oct 2008 11:32:33 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Thomas Hellström <thomas@...gstengraphics.com>
Cc:	Keith Packard <keithp@...thp.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	nickpiggin@...oo.com.au, airlied@...ux.ie, dri-devel@...ts.sf.net,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	jbarnes@...tuousgeek.org, Peter Anvin <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>, yinghai@...nel.org
Subject: Re: Adding kmap_atomic_prot_pfn

* Thomas Hellström <thomas@...gstengraphics.com> wrote:

> Ingo Molnar wrote:
>> * Thomas Hellström <thomas@...gstengraphics.com> wrote:
>>
>>   
>>> Keith,
>>>
>>> What you actually are doing here is claiming copyright on code that  
>>> other people have written, and tighten the export restrictions.   
>>> kmap_atomic_prot_pfn() appeared long ago in drm git with identical  
>>> code and purpose, but with different authors, and iounmap_atomic is  
>>> identical to kunmap_atomic.
>>>     
>>
>>   
>>>> +EXPORT_SYMBOL_GPL(iomap_atomic_prot_pfn);
>>>>       
>>
>> you want to use this facility in a binary-only driver?
>>
>> 	Ingo
>>   
> At this point I have no such use for it, no.
> The original user was a MIT style licenced driver.

okay, then just to put this question to rest: i wrote the original 
32-bit highmem code ~10 years ago. I wrote the first version of fixmap 
support - in fact i coined the term. I wrote the first version of the 
atomic-kmap facility as well.

All of that code is licensed under the GPLv2. So if anyone wants to make 
any copyright claims about highmem/kmap/fixmap derivative works, 
consider it in that light.

Regarding this new API variant that Keith wrote: it would be silly and 
dangerous to export it anywhere but to in-kernel drivers. The API 
disables preemption on 32-bit and rummages deep in the guts of the 
kernel as well, uses up a precious resource (fixmap slots), etc. It's 
internal and we eventually might want to deprecate forms of it and 
concentrate on the good 64-bit performance side.

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