09 Oct, 2012

1 commit

  • A long time ago, in v2.4, VM_RESERVED kept swapout process off VMA,
    currently it lost original meaning but still has some effects:

    | effect | alternative flags
    -+------------------------+---------------------------------------------
    1| account as reserved_vm | VM_IO
    2| skip in core dump | VM_IO, VM_DONTDUMP
    3| do not merge or expand | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
    4| do not mlock | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP

    This patch removes reserved_vm counter from mm_struct. Seems like nobody
    cares about it, it does not exported into userspace directly, it only
    reduces total_vm showed in proc.

    Thus VM_RESERVED can be replaced with VM_IO or pair VM_DONTEXPAND | VM_DONTDUMP.

    remap_pfn_range() and io_remap_pfn_range() set VM_IO|VM_DONTEXPAND|VM_DONTDUMP.
    remap_vmalloc_range() set VM_DONTEXPAND | VM_DONTDUMP.

    [akpm@linux-foundation.org: drivers/vfio/pci/vfio_pci.c fixup]
    Signed-off-by: Konstantin Khlebnikov
    Cc: Alexander Viro
    Cc: Carsten Otte
    Cc: Chris Metcalf
    Cc: Cyrill Gorcunov
    Cc: Eric Paris
    Cc: H. Peter Anvin
    Cc: Hugh Dickins
    Cc: Ingo Molnar
    Cc: James Morris
    Cc: Jason Baron
    Cc: Kentaro Takeda
    Cc: Matt Helsley
    Cc: Nick Piggin
    Cc: Oleg Nesterov
    Cc: Peter Zijlstra
    Cc: Robert Richter
    Cc: Suresh Siddha
    Cc: Tetsuo Handa
    Cc: Venkatesh Pallipadi
    Acked-by: Linus Torvalds
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Konstantin Khlebnikov
     

04 Jan, 2012

1 commit

  • Error handling code following a kmalloc should free the allocated data.
    Out_unlock is used on both success and failure, so free vm_priv before
    jumping to that label.

    A simplified version of the semantic match that finds the problem is as
    follows: (http://coccinelle.lip6.fr)

    //
    @r exists@
    local idexpression x;
    statement S;
    identifier f1;
    position p1,p2;
    expression *ptr != NULL;
    @@

    x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
    ...
    if (x == NULL) S
    }
    x->f1
    ...>
    (
    return \(0\|\|ptr\);
    |
    return@p2 ...;
    )

    @script:python@
    p1 << r.p1;
    p2 << r.p2;
    @@

    print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
    //

    Signed-off-by: Julia Lawall
    [v1: Altered the description a bit]
    Signed-off-by: Konrad Rzeszutek Wilk

    Julia Lawall
     

21 Dec, 2011

1 commit

  • * commit 'v3.2-rc3': (412 commits)
    Linux 3.2-rc3
    virtio-pci: make reset operation safer
    virtio-mmio: Correct the name of the guest features selector
    virtio: add HAS_IOMEM dependency to MMIO platform bus driver
    eCryptfs: Extend array bounds for all filename chars
    eCryptfs: Flush file in vma close
    eCryptfs: Prevent file create race condition
    regulator: TPS65910: Fix VDD1/2 voltage selector count
    i2c: Make i2cdev_notifier_call static
    i2c: Delete ANY_I2C_BUS
    i2c: Fix device name for 10-bit slave address
    i2c-algo-bit: Generate correct i2c address sequence for 10-bit target
    drm: integer overflow in drm_mode_dirtyfb_ioctl()
    Revert "of/irq: of_irq_find_parent: check for parent equal to child"
    drivers/gpu/vga/vgaarb.c: add missing kfree
    drm/radeon/kms/atom: unify i2c gpio table handling
    drm/radeon/kms: fix up gpio i2c mask bits for r4xx for real
    ttm: Don't return the bo reserved on error path
    mount_subtree() pointless use-after-free
    iio: fix a leak due to improper use of anon_inode_getfd()
    ...

    Konrad Rzeszutek Wilk
     

17 Dec, 2011

2 commits

  • When a multi-page mapping of gntalloc is created, the reference counts
    of all pages in the vma are incremented. However, the vma open/close
    operations only adjusted the reference count of the first page in the
    mapping, leaking the other pages. Store a struct in the vm_private_data
    to track the original page count to properly free the pages when the
    last reference to the vma is closed.

    Reported-by: Anil Madhavapeddy
    Signed-off-by: Daniel De Graaf
    Signed-off-by: Konrad Rzeszutek Wilk

    Daniel De Graaf
     
  • gnttab_end_foreign_access_ref does not return the grant reference it is
    passed to the free list; gnttab_free_grant_reference needs to be
    explicitly called. While gnttab_end_foreign_access provides a wrapper
    for this, it is unsuitable because it does not return errors.

    Reported-by: Anil Madhavapeddy
    Signed-off-by: Daniel De Graaf
    Signed-off-by: Konrad Rzeszutek Wilk

    Daniel De Graaf
     

22 Nov, 2011

2 commits


17 Nov, 2011

2 commits

  • gref->gref_id is unsigned so the error handling didn't work.
    gnttab_grant_foreign_access() returns an int type, so we can add a
    cast here, and it doesn't cause any problems.
    gnttab_grant_foreign_access() can return a variety of errors
    including -ENOSPC, -ENOSYS and -ENOMEM.

    CC: stable@kernel.org
    Signed-off-by: Dan Carpenter
    Signed-off-by: Konrad Rzeszutek Wilk

    Dan Carpenter
     
  • On 32 bit systems a high value of op.count could lead to an integer
    overflow in the kzalloc() and gref_ids would be smaller than
    expected. If the you triggered another integer overflow in
    "if (gref_size + op.count > limit)" then you'd probably get memory
    corruption inside add_grefs().

    CC: stable@kernel.org
    Signed-off-by: Dan Carpenter
    Signed-off-by: Konrad Rzeszutek Wilk

    Dan Carpenter
     

10 Mar, 2011

1 commit

  • The only time when granted pages need to be treated specially is when
    using Xen's PTE modification for grant mappings owned by another domain
    (that is, only gntdev on PV guests). Otherwise, the area does not
    require VM_DONTCOPY and VM_PFNMAP, since it can be accessed just like
    any other page of RAM.

    Since the vm_operations_struct close operations decrement reference
    counts, a corresponding open function that increments them is required
    now that it is possible to have multiple references to a single area.

    We are careful in the gntdev to check if we can remove those flags. The
    reason that we need to be careful in gntdev on PV guests is because we are
    not changing the PFN/MFN mapping on PV; instead, we change the application's
    page tables to point to the other domain's memory. This means that the vma
    cannot be copied without using another grant mapping hypercall; it also
    requires special handling on unmap, which is the reason for gntdev's
    dependency on the MMU notifier.

    For gntalloc, this is not a concern - the pages are owned by the domain
    using the gntalloc device, and can be mapped and unmapped in the same manner
    as any other page of memory.

    Acked-by: Ian Campbell
    Signed-off-by: Daniel De Graaf
    Signed-off-by: Konrad Rzeszutek Wilk
    [v2: Added in git commit "We are.." from email correspondence]

    Daniel De Graaf
     

15 Feb, 2011

2 commits