Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753256AbdHQQ1x (ORCPT ); Thu, 17 Aug 2017 12:27:53 -0400 Received: from lhrrgout.huawei.com ([194.213.3.17]:33403 "EHLO lhrrgout.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752664AbdHQQ1w (ORCPT ); Thu, 17 Aug 2017 12:27:52 -0400 From: Igor Stoppa Subject: [RFC] memory allocations in genalloc To: Jes Sorensen CC: Michal Hocko , Laura Abbott , "James Morris" , Jerome Glisse , "Paul Moore" , LKML , Linux-MM , "kernel-hardening@lists.openwall.com" , Message-ID: <299c22f9-2e34-36dc-a6da-22eadbc0a59d@huawei.com> Date: Thu, 17 Aug 2017 19:26:16 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.122.225.51] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5995C3EC.0237,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f7c77bba1a678910ab94f911dd4f0a61 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2125 Lines: 63 Foreword: If I should direct this message to someone else, please let me know. I couldn't get a clear idea, by looking at both MAINTAINERS and git blame. **** Hi, I'm currently trying to convert the SE Linux policy db into using a protectable memory allocator (pmalloc) that I have developed. Such allocator is based on genalloc: I had come up with an implementation that was pretty similar to what genalloc already does, so it was pointed out to me that I could have a look at it. And, indeed, it seemed a perfect choice. But ... when freeing memory, genalloc wants that the caller also states how large each specific memory allocation is. This, per se, is not an issue, although genalloc doesn't seen to check if the memory being freed is really matching a previous allocation request. However, this design doesn't sit well with the use case I have in mind. In particular, when the SE Linux policy db is populated, the creation of one or more specific entry of the db might fail. In this case, the memory previously allocated for said entry, is released with kfree, which doesn't need to know the size of the chunk being freed. I would like to add similar capability to genalloc. genalloc already uses bitmaps, to track what words are allocated (1) and which are free (0) What I would like to do is to add another bitmap, which would track the beginning of each individual allocation (1 on the first allocation unit of each allocation, 0 otherwise). Such enhancement would enable also the detection of calls to free with incorrect / misaligned addresses - right now it is possible to successfully free a memory area that overlaps the interface of two adjacent allocations, without fully covering either of them. Would this change be acceptable? Is there any better way to achieve what I want? --- I have also a question wrt the use of spinlocks in genalloc. Why a spinlock? Freeing a chunk of memory previously allocated with vmalloc requires invoking vfree_atomic, instead of vfree, because the list of chunks is walked with the spinlock held, and vfree can sleep. Why not using a mutex? -- TIA, igor