[lkml]   [2010]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Arch specific mmap attributes (Was: mprotect pgprot handling weirdness)
    > On Tue, 2010-04-06 at 14:52 +0900, KOSAKI Motohiro wrote:
    > (Adding linux-arch)
    > > This check was introduced the following commit. yes now we don't
    > > consider arch specific PROT_xx flags. but I don't think it is odd.
    > >
    > > Yeah, I can imagine at least embedded people certenary need arch
    > > specific PROT_xx flags and they hope to change it. but I don't
    > > think mprotect() fit for your usage. I mean mprotect() is widely
    > > used glibc internally. then, If mprotec can change which flags,
    > > glibc might turn off such flags implictly.
    > >
    > > So, Why can't we proper new syscall? It has no regression risk.
    > I don't care much personally whether we use mprotect() or a new syscall,
    > but at this stage we already have PROT_SAO going that way for powerpc so
    > that would be an ABI change.
    > However, the main issue isn't really there. The main issue is that right
    > now, everything we do in mmap.c, mprotect.c, ... revolves around having
    > everything translated into the single vm_flags field. VMA merging
    > decisions, construction of vm_page_prot, etc... everything is there.
    > However, this is a 32-bit field on 32-bit archs, and we already use all
    > possible bits in there. It's also a field entirely defined in generic
    > code with no provision for arch specific bits.
    > The question here thus boils down to what direction do we want to go to
    > if we want to untangle that and provide the ability to expose mapping
    > "attributes" basically. In fact, I suspect even x86 might have good use
    > of that to create things like relaxed ordering mappings no ?
    > This boils down, so far to a few facts/questions to be resolved:
    > - Do we want to use the existing PROT_ argument to mmap, mprotect,... ?
    > There's plenty of bit space, and we already have at least one example of
    > an arch adding something to it (powerpc with PROT_SAO - aka Strong
    > Access Ordering - aka Make It Look Like An x86 :-)
    > - If not, while a separate syscall would be fine with me for setting
    > attributes after the fact, it makes it harder to pass them via mmap, is
    > that a big deal ? IE. Ie it means one -always- has to call it after mmap
    > to change the attributes. That means for example that mmap will
    > potentially create a VMA merged with another one, just to be re-split
    > due to the attribute change. A bit gross...
    > - Do we want to keep the current "Funnel everything into vm_flags"
    > approach ? That leaves no option that I can see but to extend it into a
    > u64 so it grows on 32-bit archs.
    > - If not, I see two approaches here: Either having a separate / new
    > "attribute" field in the VMA or going straight for the vm_page_prot (ie.
    > the pgprot). In both cases, things like vma_merge() need to grow a new
    > argument since obviously we can't merge things with different
    > attributes.
    > - ... Unless we just replace VM_SAO with VM_CANT_MERGE and set that
    > whenever a VMA has a non-0 attributes. Sad but simpler
    > Any other / better idea ?

    I guess you haven't catch my intention. I didn't say we have to remove
    PROT_SAO and VM_SAO.
    I mean mmap(PROT_SAO) is ok, it's only append new flag, not change exiting
    flags meanings. I'm only against mprotect(PROT_NONE) turn off PROT_SAO

    IOW I recommend we use three syscall
    mmap() create new mappings
    mprotect() change a protection of mapping (as a name)
    mattribute(): (or similar name)
    change an attribute of mapping (e.g. PROT_SAO or
    another arch specific flags)

    I'm not against changing mm/protect.c for PROT_SAO.

     \ /
      Last update: 2010-04-06 08:27    [W:0.035 / U:7.144 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site