linux-kernel - Re: vmalloc performance

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <h2m28c262361004140812y92447e97z29c001d0a8b8eaaf@mail.gmail.com>
Date:	Thu, 15 Apr 2010 00:12:45 +0900
From:	Minchan Kim <minchan.kim@...il.com>
To:	Steven Whitehouse <steve@...gwyn.com>
Cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: vmalloc performance

On Wed, Apr 14, 2010 at 11:24 PM, Steven Whitehouse <steve@...gwyn.com> wrote:
> Hi,
>
> Also, what lock should be protecting this code:
>
>        va->flags |= VM_LAZY_FREE;
>        atomic_add((va->va_end - va->va_start) >> PAGE_SHIFT,
> &vmap_lazy_nr);
>
> in free_unmap_vmap_area_noflush() ? It seem that if
> __purge_vmap_area_lazy runs between the two statements above that the
> number of pages contained in vmap_lazy_nr will be incorrect. Maybe the
> two statements should just be reversed? I can't see any reason that the
> flag assignment would be atomic either. In recent tests, including the
> patch below, the following has been reported to me:

It was already fixed.
https://patchwork.kernel.org/patch/89783/

Thanks.

-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/