Received: by 10.223.185.116 with SMTP id b49csp6605205wrg; Wed, 28 Feb 2018 12:13:36 -0800 (PST) X-Google-Smtp-Source: AH8x2251xy2RF79upAuLOhbrfMJUaVbrMrYtcR13ZMC4t59kI53AxrKd8/NRivJeq5842r/1wXoM X-Received: by 2002:a17:902:ab88:: with SMTP id f8-v6mr19465202plr.325.1519848816310; Wed, 28 Feb 2018 12:13:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519848816; cv=none; d=google.com; s=arc-20160816; b=VIOr+sY+AkqCwTfowcqJjY1UbeTt0ss0E+Lxbf2h+3MzMTS//Zjgwx3W06K/XOr+i7 Rd2qLUvX7Uzxcmg6JtRhFngeGaXbLezAj+EKnVwcZfZW/9tvfA4yixagW6AB1/mtYcgR w0+FUc3XjbFx4JD5QiJ7FoTd/0r48x4B+FtrnzYT7624SBotQ6vEuHNk2xlAnkwryFK4 OskFRGBH9kfh8Nu1ZcYypkfEEhFD23Xs2ydIXLFh2miKG9WuVw0fxfKsa7jRJ3F4cX3M wyFFqEpx/EgsEE1l/DZ/5yzwW3L9tNSy+b1FWdJdIKsAAHzMbb9UaCJcJRGvkmjqWH3r Ah8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:arc-authentication-results; bh=NpEJXfEcJyWsZ845QTN2GifRtdyfS/RSZltYKrw3COM=; b=K+HrBGsXmBwUZY97qBKpUFKLyBk0FqdPleAAEgwjHxaYeAHL3IGTjiB+9VPSqb/a3k IfOgQoUEWo5bxlW5M6IFt5m+Uh4UQMZ3TlVrQff2agTm7l4+CEk7eAuqccmj6TgSMleI fXVGWcCWP+OTq9rjnAhEOHLKpBvYGKN6GCDfuOLaU4GpAHjyzcI4sfVSXeY0+1kF8ssU dBO8xAZ731k4XrEyL9oJtjEZhrN87hqYSaUeqBLIYqhz6FP0s4YR1or1AGm7RgTwW8bt LZZIXccQ0W+hl22G0QvdK0QiJr9u1aX63x2EIfIzGcOYkVuRQbtxxV3cVP/ddWXJozpi E1Yw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h10-v6si1778806plk.706.2018.02.28.12.13.21; Wed, 28 Feb 2018 12:13:36 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934484AbeB1ULq (ORCPT + 99 others); Wed, 28 Feb 2018 15:11:46 -0500 Received: from lhrrgout.huawei.com ([194.213.3.17]:27900 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S934011AbeB1ULp (ORCPT ); Wed, 28 Feb 2018 15:11:45 -0500 Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 0093E9C11E15; Wed, 28 Feb 2018 20:11:42 +0000 (GMT) Received: from localhost.localdomain (10.122.225.51) by smtpsuk.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 28 Feb 2018 20:11:34 +0000 From: Igor Stoppa To: , , , CC: , , , , , Igor Stoppa Subject: [PATCH 7/7] Documentation for Pmalloc Date: Wed, 28 Feb 2018 22:06:20 +0200 Message-ID: <20180228200620.30026-8-igor.stoppa@huawei.com> X-Mailer: git-send-email 2.14.1 In-Reply-To: <20180228200620.30026-1-igor.stoppa@huawei.com> References: <20180228200620.30026-1-igor.stoppa@huawei.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.122.225.51] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Detailed documentation about the protectable memory allocator. Signed-off-by: Igor Stoppa --- Documentation/core-api/index.rst | 1 + Documentation/core-api/pmalloc.rst | 111 +++++++++++++++++++++++++++++++++++++ 2 files changed, 112 insertions(+) create mode 100644 Documentation/core-api/pmalloc.rst diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index c670a8031786..8f5de42d6571 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -25,6 +25,7 @@ Core utilities genalloc errseq printk-formats + pmalloc Interfaces for kernel debugging =============================== diff --git a/Documentation/core-api/pmalloc.rst b/Documentation/core-api/pmalloc.rst new file mode 100644 index 000000000000..8fb9c9d3171b --- /dev/null +++ b/Documentation/core-api/pmalloc.rst @@ -0,0 +1,111 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Protectable memory allocator +============================ + +Purpose +------- + +The pmalloc library is meant to provide R/O status to data that, for some +reason, could neither be declared as constant, nor could it take advantage +of the qualifier __ro_after_init, but is write-once and read-only in spirit. +It protects data from both accidental and malicious overwrites. + +Example: A policy that is loaded from userspace. + + +Concept +------- + +pmalloc builds on top of genalloc, using the same concept of memory pools. + +The value added by pmalloc is that now the memory contained in a pool can +become R/O, for the rest of the life of the pool. + +Different kernel drivers and threads can use different pools, for finer +control of what becomes R/O and when. And for improved lockless concurrency. + + +Caveats +------- + +- Memory freed while a pool is not yet protected will be reused. + +- Once a pool is protected, it's not possible to allocate any more memory + from it. + +- Memory "freed" from a protected pool indicates that such memory is not + in use anymore by the requester; however, it will not become available + for further use, until the pool is destroyed. + +- pmalloc does not provide locking support with respect to allocating vs + protecting an individual pool, for performance reasons. + It is recommended not to share the same pool between unrelated functions. + Should sharing be a necessity, the user of the shared pool is expected + to implement locking for that pool. + +- pmalloc uses genalloc to optimize the use of the space it allocates + through vmalloc. Some more TLB entries will be used, however less than + in the case of using vmalloc directly. The exact number depends on the + size of each allocation request and possible slack. + +- Considering that not much data is supposed to be dynamically allocated + and then marked as read-only, it shouldn't be an issue that the address + range for pmalloc is limited, on 32-bit systems. + +- Regarding SMP systems, the allocations are expected to happen mostly + during an initial transient, after which there should be no more need to + perform cross-processor synchronizations of page tables. + +- To facilitate the conversion of existing code to pmalloc pools, several + helper functions are provided, mirroring their kmalloc counterparts. + + +Use +--- + +The typical sequence, when using pmalloc, is: + +1. create a pool + +.. kernel-doc:: include/linux/pmalloc.h + :functions: pmalloc_create_pool + +2. [optional] pre-allocate some memory in the pool + +.. kernel-doc:: include/linux/pmalloc.h + :functions: pmalloc_prealloc + +3. issue one or more allocation requests to the pool with locking as needed + +.. kernel-doc:: include/linux/pmalloc.h + :functions: pmalloc + +.. kernel-doc:: include/linux/pmalloc.h + :functions: pzalloc + +4. initialize the memory obtained with desired values + +5. [optional] iterate over points 3 & 4 as needed + +6. write-protect the pool + +.. kernel-doc:: include/linux/pmalloc.h + :functions: pmalloc_protect_pool + +7. use in read-only mode the handles obtained through the allocations + +8. [optional] release all the memory allocated + +.. kernel-doc:: include/linux/pmalloc.h + :functions: pfree + +9. [optional, but depends on point 8] destroy the pool + +.. kernel-doc:: include/linux/pmalloc.h + :functions: pmalloc_destroy_pool + +API +--- + +.. kernel-doc:: include/linux/pmalloc.h -- 2.14.1