[Bug tapsets/19756] New: linux 4.5-rc1 commit 8463833590

["dsmith at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=19756

            Bug ID: 19756
           Summary: linux 4.5-rc1 commit 8463833590
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com
  Target Milestone: ---

The following kernel commit:

====
commit 84638335900f1995495838fe1bd4870c43ec1f67
Author: Konstantin Khlebnikov <koct9i@gmail.com>
Date:   Thu Jan 14 15:22:07 2016 -0800

    mm: rework virtual memory accounting

    When inspecting a vague code inside prctl(PR_SET_MM_MEM) call (which
    testing the RLIMIT_DATA value to figure out if we're allowed to assign
    new @start_brk, @brk, @start_data, @end_data from mm_struct) it's been
    commited that RLIMIT_DATA in a form it's implemented now doesn't do
    anything useful because most of user-space libraries use mmap() syscall
    for dynamic memory allocations.

    Linus suggested to convert RLIMIT_DATA rlimit into something suitable
    for anonymous memory accounting.  But in this patch we go further, and
    the changes are bundled together as:

     * keep vma counting if CONFIG_PROC_FS=n, will be used for limits
     * replace mm->shared_vm with better defined mm->data_vm
     * account anonymous executable areas as executable
     * account file-backed growsdown/up areas as stack
     * drop struct file* argument from vm_stat_account
     * enforce RLIMIT_DATA for size of data areas

    This way code looks cleaner: now code/stack/data classification depends
    only on vm_flags state:

     VM_EXEC & ~VM_WRITE            -> code  (VmExe + VmLib in proc)
     VM_GROWSUP | VM_GROWSDOWN      -> stack (VmStk)
     VM_WRITE & ~VM_SHARED & !stack -> data  (VmData)

    The rest (VmSize - VmData - VmStk - VmExe - VmLib) could be called
    "shared", but that might be strange beast like readonly-private or VM_IO
    area.

     - RLIMIT_AS            limits whole address space "VmSize"
     - RLIMIT_STACK         limits stack "VmStk" (but each vma individually)
     - RLIMIT_DATA          now limits "VmData"
====

Causes compile failures in the proc_mem_data() and proc_mem_data_pid()
functions (as shown by failures in testsuite/buildok/proc_mem-embedded.stp).

-- 
You are receiving this mail because:
You are the assignee for the bug.