Received: by 10.223.185.116 with SMTP id b49csp1228355wrg; Wed, 21 Feb 2018 14:36:25 -0800 (PST) X-Google-Smtp-Source: AH8x225d0zNxuXBpIvYdBL+mZtIHloSOzvWn0B6bnHcyVcCu6RKKTqIb3WfEv2ltbu0JelAH+tL+ X-Received: by 2002:a17:902:4601:: with SMTP id o1-v6mr4501588pld.210.1519252584984; Wed, 21 Feb 2018 14:36:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519252584; cv=none; d=google.com; s=arc-20160816; b=ZZwUBRlQVqgdzsyLqt3IOxW+lAGzMmz575eg0g3sl/Ir/oCuAEuvr/1KxJPqiFrZ8h PhcL8lUjHSnc4isl50RqXf/gczz/YXHhIhuHfiRtjNNfkU2+m02MjHndUQj2WGII6VC2 tjO5ROXG7uGETqz0f5v1XlI9IuflxZcXwzjQQJiW2ewFXW5a3+KHr0OL1ejwvjOlNOd3 JDYbOlNWdCN1D4/kVdQ8imarnWSfRoaJJRKy0o88CKStR/tCFnyGvcEipdAEUlg4kHti K1hMd70Ci8pAemv18Zd/DWyYFUyQafR/zEE7mAhZKCQDdNpz5ORR5OvSU9jtIGKaOU9T wtoQ== 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:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=MM9XnDBYm0i4xCWZERNIX4RnrUgLNZV4QeNNUESbtRQ=; b=Wz7DBc79I2AgMlAalMfAH46MLuki9YfMMc/XT5RAsJUF1VK3YR2b+dg2iRIIpv5E9q 7LcjqoynT9Sd24u/3TxgWAKUgFs7inPx70YYg0lbK6N1RI0A9akjoDPY0awgX1aJSvrZ +uJRijvDHfxXAt0TFvIaoPqC9xshqiEATx1xVaaFcbVBz9N2W7yui9c3NetOkNoDdOcD RpbsoHEML49ZDCgzACEUnyWXPcdtuXq6cHY1GIVfjCnhxgIZeqB0FRYN3FofzB5DFtWk l4ZTimoSOUbImIlCdnEMZYi4D7rRWT7R4BBgu5XrgRbeDUM9JQXQbIHiaxsq2pmjp0+X DoOQ== 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 k23si8043970pfi.222.2018.02.21.14.36.10; Wed, 21 Feb 2018 14:36:24 -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 S1751399AbeBUWfb (ORCPT + 99 others); Wed, 21 Feb 2018 17:35:31 -0500 Received: from ms.lwn.net ([45.79.88.28]:39786 "EHLO ms.lwn.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751129AbeBUWf3 (ORCPT ); Wed, 21 Feb 2018 17:35:29 -0500 Received: from lwn.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ms.lwn.net (Postfix) with ESMTPSA id 562362C5; Wed, 21 Feb 2018 22:35:28 +0000 (UTC) Date: Wed, 21 Feb 2018 15:35:27 -0700 From: Jonathan Corbet To: Kees Cook Cc: Igor Stoppa , Matthew Wilcox , Randy Dunlap , Michal Hocko , Laura Abbott , Jerome Glisse , Christoph Hellwig , Christoph Lameter , linux-security-module , Linux-MM , LKML , Kernel Hardening Subject: Re: [PATCH 1/6] genalloc: track beginning of allocations Message-ID: <20180221153527.12e7d12c@lwn.net> In-Reply-To: References: <20180212165301.17933-1-igor.stoppa@huawei.com> <20180212165301.17933-2-igor.stoppa@huawei.com> Organization: LWN.net MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 21 Feb 2018 14:29:06 -0800 Kees Cook wrote: > >> 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? > > Hmmm... I think keeping it as-is would be better than a trailing > docs-only patch. Maybe Jon has an opinion? I would be inclined to agree. Putting docs changes with the associated code changes helps to document the patch itself, among other things. I wouldn't split them up. jon