Received: by 10.223.185.116 with SMTP id b49csp869306wrg; Tue, 20 Feb 2018 09:08:43 -0800 (PST) X-Google-Smtp-Source: AH8x227rgcFbs1A9MJxy5qDKeFjK3EwQtzH0HcXByuRwzjMwnmVPkE0ZUiu+9F1PglWYGSG2hb+K X-Received: by 2002:a17:902:7d8d:: with SMTP id a13-v6mr279396plm.304.1519146523192; Tue, 20 Feb 2018 09:08:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519146523; cv=none; d=google.com; s=arc-20160816; b=T3ncFvnSxEcr2php3crubMxjd0GMrTgZWSVvpRzRtl4XZC8hRHVWDbKjVHmWGveoUN HxqdXGyabTZ/CzhWUXtCqq5fPX50nKjEWPRA2+H4EdsUjX/fhQ5eUyMcr6iMqewmBHO6 wct0TqqjrdxKIzSauhxIdT6kNyaCqSGPtkPZ8Dzc47R88TMtGV8e5mANkdaN4RyRhsW1 SVFIwJCWkhDxChxwrh+Qd1sb0+tvYMJHUX5ojpctF3lRFE9qdojDIwJF+eAm1DvGbHDI B8LQtlPjhTeTq1qz/96Nf4PDj/H4kFOsyDAPvQs160apo2Wox6zS14Dr7wDP2/Dm7pvI l8ug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=JfYY0LTJrqKwfVutz/JktbLIH/nmQbKdLmwtasI3/8k=; b=QaSEC0oA2oiysSgZdedVHIZ6iAuJfGMn56Go1goeoZFtwv3x9q2qtPAHbAZbUaXv3P IMgrHbWPLgYBY0odLOYhL/flG+dPk4cMM92uYCkBiqsS4iFRcLCf3dTRwHCelQHjaQpl d/jlupT8nihV1GhQafyt1LFg7VMvEfyaDHa04O2AuWsxIfe5Wgg9RrlT20eayD6Ren2s IPHQwymKLBKyKsaDt8eImYF2morCkm/wroSQ2bez/dy7sUlrjUbbZqFGCpDsEsO0y6bZ kBHAEATEELqhH5VYlUH+RWpUcn3SiDYzwl7Sp7d7RqBdjf6l6DNCklqhroxldnLLIsfi R1Gw== 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 g12-v6si5936869pla.564.2018.02.20.09.08.28; Tue, 20 Feb 2018 09:08:43 -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 S1753364AbeBTRHl (ORCPT + 99 others); Tue, 20 Feb 2018 12:07:41 -0500 Received: from lhrrgout.huawei.com ([194.213.3.17]:26895 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753298AbeBTRHk (ORCPT ); Tue, 20 Feb 2018 12:07:40 -0500 Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 153F7D3BD4F4D; Tue, 20 Feb 2018 17:07:37 +0000 (GMT) Received: from [10.122.225.51] (10.122.225.51) by smtpsuk.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 20 Feb 2018 17:07:35 +0000 Subject: Re: [PATCH 1/6] genalloc: track beginning of allocations To: Kees Cook CC: Matthew Wilcox , Randy Dunlap , Jonathan Corbet , Michal Hocko , Laura Abbott , Jerome Glisse , Christoph Hellwig , "Christoph Lameter" , linux-security-module , Linux-MM , LKML , Kernel Hardening References: <20180212165301.17933-1-igor.stoppa@huawei.com> <20180212165301.17933-2-igor.stoppa@huawei.com> From: Igor Stoppa Message-ID: Date: Tue, 20 Feb 2018 19:07:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: 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 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13/02/18 01:52, Kees Cook wrote: > On Mon, Feb 12, 2018 at 8:52 AM, Igor Stoppa wrote: >> @@ -738,14 +1031,16 @@ EXPORT_SYMBOL(devm_gen_pool_create); >> >> #ifdef CONFIG_OF >> /** >> - * of_gen_pool_get - find a pool by phandle property >> + * of_gen_pool_get() - find a pool by phandle property >> * @np: device node >> * @propname: property name containing phandle(s) >> * @index: index into the phandle array >> * >> - * Returns the pool that contains the chunk starting at the physical >> - * address of the device tree node pointed at by the phandle property, >> - * or NULL if not found. >> + * Return: >> + * * pool address - it contains the chunk starting at the physical >> + * address of the device tree node pointed at by >> + * the phandle property >> + * * NULL - otherwise >> */ >> struct gen_pool *of_gen_pool_get(struct device_node *np, >> const char *propname, int index) > > I wonder if this might be more readable by splitting the kernel-doc > changes from the bitmap changes? I.e. fix all the kernel-doc in one > patch, and in the following, make the bitmap changes. Maybe it's such > a small part that it doesn't matter, though? I had the same thought, but then I would have made most of the kerneldoc changes to something that would be altered by the following patch, because it would have made little sense to fix only those parts that would have survived. If it is really a problem to keep them together, I could put these changes in a following patch. Would that be ok? -- igor