linux-kernel - Re: No more bits in vm_area_struct's 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0909232056020.3360@sister.anvils>
Date:	Wed, 23 Sep 2009 21:23:40 +0100 (BST)
From:	Hugh Dickins <hugh.dickins@...cali.co.uk>
To:	Nigel Cunningham <ncunningham@...a.org.au>
cc:	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: No more bits in vm_area_struct's vm_flags.

On Wed, 23 Sep 2009, Nigel Cunningham wrote:
> 
> With the addition of the VM_MERGEABLE flag to vm_flags post-2.6.31, the
> last bit in vm_flags has been used.

Yes, it was rather selfish to take that, without even pointing out
that was the last of 32 bits in the changelog, and without mapping
out where to go next - sorry.

> 
> I have some code in TuxOnIce that needs a bit too (explicitly mark the
> VMA as needing to be atomically copied, for GEM objects), and am not

(I wonder what atomically copied means there.)

> sure what the canonical way to proceed is. Should a new unsigned long be
> added? The difficulty I see with that is that my flag was used in
> shmem_file_setup's flags parameter (drm_gem_object_alloc), so that
> function would need an extra parameter too..

I've assumed that, when necessary, we'll retype vm_flags from
unsigned long to unsigned long long (or u64).  But I've not yet
checked how much bloat that would add to 32-bit code: whether we
should put it off as long as we can, or be lazy and do it soon.

I'm thinking that we should use the full 32-bit vm_flags as a
prompt to dispose of a few.  VM_RESERVED is the one I always claim
I'm going to remove, then more important jobs intervene; and we seem
to have grown more weird variants of VM_PFNMAP than I care for in
the last year or two.  Suspect VM_PFN_AT_MMAP could make reasonable
use of VM_NONLINEAR, but probably not without some small change.

Does TuxOnIce rely on CONFIG_MMU?  If so, then the TuxOnIce patch
could presumably reuse VM_MAPPED_COPY for now - but don't be
surprised if that's one we clean away later on.

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