linux-kernel - Re: Question about memory mapping mechanism

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-next>] [day] [month] [year] [list]

Date:	Thu, 8 Mar 2007 22:36:51 +0100 (CET)
From:	Martin Drab <drab@...ler.fjfi.cvut.cz>
To:	Carsten Otte <cotte.de@...il.com>
cc:	hugh@...itas.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Question about memory mapping mechanism

On Thu, 8 Mar 2007, Carsten Otte wrote:

> On 3/8/07, Martin Drab <drab@...ler.fjfi.cvut.cz> wrote:
> > 
> > The thing is that I'd like to prevent kernel to swap these pages out,
> > because then I may loose some data when they are not available in time
> > for the next round.
> 
> One think you could do is grab a reference to the pages upfront.

I'm not really sure what exactly do you mean by "grab a reference 
upfront"?

> When you stop pushing data out to the userspace, or at least when the 
> file is released, you need to drop that reference again.

Or do you mean reference like with the get_page()? Sure, I do a get_page() 
in the nopage() handler for each page before it is passed to the 
user-space. That's OK, there is no problem. Problem seems to be in the 
PG_reserved bit set when the pages are unmapped from the userspace, i.e. 
when the application calls munmap(2).

> You could even do a kmap_atomic(), which would give you a kernel space 
> mapping. That way, you avoid copy_to_user for that data.

If I understand kmap_atomic() right, then it is not really what I need in 
this case. The kmap() just returns a virtual address (logical address in 
this case, since the pages are not in high memory) for a page. The 
kmap_atomic() does the same but disables preemption first, so all 
processing with the page needs to be atomic, which in this case can not 
be guaranteed.

Or do I get it wrong? I'm not really a kernel's memory management guru, so 
maybe I just don't get it. ;-)

But thanks anyway.

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