lkml.org 
[lkml]   [2014]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v6 02/10] x86, mpx: add MPX specific mmap interface
    On Tue, Jun 24, 2014 at 6:40 PM, Ren, Qiaowei <qiaowei.ren@intel.com> wrote:
    > On 2014-06-25, Andy Lutomirski wrote:
    >> On Mon, Jun 23, 2014 at 10:53 PM, Ren, Qiaowei <qiaowei.ren@intel.com>
    >> wrote:
    >>> On 2014-06-24, Andy Lutomirski wrote:
    >>>>> On 06/23/2014 01:06 PM, Andy Lutomirski wrote:
    >>>>>> Can the new vm_operation "name" be use for this? The magic
    >>>>>> "always written to core dumps" feature might need to be reconsidered.
    >>>>>
    >>>>> One thing I'd like to avoid is an MPX vma getting merged with a
    >>>>> non-MPX vma. I don't see any code to prevent two VMAs with
    >>>>> different vm_ops->names from getting merged. That seems like a
    >>>>> bit of a design oversight for ->name. Right?
    >>>>
    >>>> AFAIK there are no ->name users that don't also set ->close, for
    >>>> exactly that reason. I'd be okay with adding a check for ->name, too.
    >>>>
    >>>> Hmm. If MPX vmas had a real struct file attached, this would all
    >>>> come for free. Maybe vmas with non-default vm_ops and file != NULL
    >>>> should never be mergeable?
    >>>>
    >>>>>
    >>>>> Thinking out loud a bit... There are also some more complicated
    >>>>> but more performant cleanup mechanisms that I'd like to go after in the future.
    >>>>> Given a page, we might want to figure out if it is an MPX page or not.
    >>>>> I wonder if we'll ever collide with some other user of vm_ops->name.
    >>>>> It looks fairly narrowly used at the moment, but would this keep
    >>>>> us from putting these pages on, say, a tmpfs mount? Doesn't look
    >>>>> that way at the moment.
    >>>>
    >>>> You could always check the vm_ops pointer to see if it's MPX.
    >>>>
    >>>> One feature I've wanted: a way to have special per-process vmas that
    >>>> can be easily found. For example, I want to be able to efficiently
    >>>> find out where the vdso and vvar vmas are. I don't think this is
    >>>> currently supported.
    >>>>
    >>> Andy, if you add a check for ->name to avoid the MPX vmas merged
    >>> with
    >> non-MPX vmas, I guess the work flow should be as follow (use
    >> _install_special_mapping to get a new vma):
    >>>
    >>> unsigned long mpx_mmap(unsigned long len) {
    >>> ......
    >>> static struct vm_special_mapping mpx_mapping = {
    >>> .name = "[mpx]",
    >>> .pages = no_pages,
    >>> };
    >>>
    >>> ....... vma = _install_special_mapping(mm, addr, len, vm_flags,
    >>> &mpx_mapping); ......
    >>> }
    >>>
    >>> Then, we could check the ->name to see if the VMA is MPX specific. Right?
    >>
    >> Does this actually create a vma backed with real memory? Doesn't this
    >> need to go through anon_vma or something? _install_special_mapping
    >> completely prevents merging.
    >>
    > Hmm, _install_special_mapping should completely prevent merging, even among MPX vmas.
    >
    > So, could you tell me how to set MPX specific ->name to the vma when it is created? Seems like that I could not find such interface.

    You may need to add one.

    I'd suggest posting a new thread to linux-mm describing what you need
    and asking how to do it.

    --Andy


    \
     
     \ /
      Last update: 2014-06-25 23:41    [W:4.450 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site