[lkml]   [2008]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] eCryptfs - use page_alloc not kmalloc to get a page of memory
    Hi Eric,

    Eric Sandeen wrote:
    > Pekka Enberg wrote:
    >> On Mon, Jul 28, 2008 at 11:35 PM, Andrew Morton
    >> <> wrote:
    >>> On Mon, 28 Jul 2008 11:13:03 -0500
    >>> Eric Sandeen <> wrote:
    >>>> With SLUB debugging turned on in 2.6.26, I was getting memory corruption
    >>>> when testing eCryptfs. The root cause turned out to be that eCryptfs
    >>>> was doing kmalloc(PAGE_CACHE_SIZE); virt_to_page() and treating that
    >>>> as a nice page-aligned chunk of memory. But at least with SLUB debugging
    >>>> on, this is not always true, and the page we get from virt_to_page does
    >>>> not necessarily match the PAGE_CACHE_SIZE worth of memory we got from
    >>>> kmalloc.
    >>>> My simple testcase was 2 loops doing "rm -f fileX; cp /tmp/fileX ." for
    >>>> 2 different multi-megabyte files. With this change I no longer see
    >>>> the corruption.
    >>> The fix applies to both 2.6.25 and to 2.6.26 and appears to be needed
    >>> in both kernel versions, so I have tagged it for backporting into both.
    >> Hmm, SLUB will use the page allocator directly for PAGE_CACHE_SIZE
    >> regadless of whether debugging is enabled or not...
    > For whatever reason, I did see non-page-aligned memory returned from
    > kmalloc(PAGE_CACHE_SIZE), and I think this is what caused the problem
    > once virt_to_page() was used to get hold of a page to pass around in the
    > ecryptfs/crypto code...

    With SLUB? I can't see how that's possible. I can see this with SLAB,
    though, for 4K pages.

    In any case, the patch, of course, make sense as kmalloc() behavior
    varies between allocators.


     \ /
      Last update: 2008-07-28 23:23    [W:0.020 / U:4.880 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site