linux-kernel - Re: copy_page_range() with VM

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

Date:	Mon, 10 Mar 2008 18:53:38 +0000
From:	"Will Newton" <will.newton@...il.com>
To:	"Hugh Dickins" <hugh@...itas.com>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: copy_page_range() with VM_LOCKED

On Mon, Mar 10, 2008 at 5:40 PM, Hugh Dickins <hugh@...itas.com> wrote:

>  > mmap with MAP_LOCKED only promises the page will not be paged out, not
>  > that the page will never fault but I would like to get that behaviour.
>  >
>  > Would it be possible to add VM_LOCKED to the above conditional so
>  > copy_page_range would always copy VM_LOCKED vma page tables or would
>  > that be considered insane and broken?
>
>  It would be possible, but I don't think it would be justified - for
>  everybody who wants your behaviour, there'll be others who want the
>  current behaviour (and that condition reflects those cases on which
>  correctness demands we do the copy).
>
>  If you really want that, I think you'll have to patch your own kernel.
>
>  But much much better, mlock that area in your child after the fork,
>  since it isn't actually locked at present: that mlock will bring in
>  the pages - not quite as efficiently as copy_page_range would have done,
>  but as or more efficiently than the original mlock in the parent.

The reason I want to do this is to work around a silicon bug so I'd
rather keep the whole workaround in the kernel rather than hacking the
C library etc. I wasn't aware that the VM_LOCKED flag would be lost in
the child, it looks like I'll have to come up with a more creative
solution...

Thanks for taking the time to explain how this stuff fits together,
--
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/