From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751300AbcDPJAe (ORCPT ); Sat, 16 Apr 2016 05:00:34 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:33206 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751136AbcDPJAa (ORCPT ); Sat, 16 Apr 2016 05:00:30 -0400 Date: Sat, 16 Apr 2016 11:00:25 +0200 From: Ingo Molnar To: Kees Cook Cc: Yinghai Lu , Junjie Mao , Josh Triplett , Andrew Morton , Baoquan He , Ard Biesheuvel , Matt Redfearn , "x86@kernel.org" , "H. Peter Anvin" , Ingo Molnar , Borislav Petkov , Vivek Goyal , Andy Lutomirski , lasse.collin@tukaani.org, Dave Young , "kernel-hardening@lists.openwall.com" , LKML Subject: Re: [PATCH v5 07/21] x86, boot: Fix run_size calculation Message-ID: <20160416090025.GB30071@gmail.com> References: <1460672954-32567-1-git-send-email-keescook@chromium.org> <1460672954-32567-8-git-send-email-keescook@chromium.org> <20160415083105.GG30715@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Kees Cook wrote: > > So can we rename it to something more expressive, such as kernel_total_size or > > so? > > You got it. Thanks again for digging through all this! You are welcome! A couple of logistical suggestions: Could you please split up the series a bit and limit the next series to say no more than around 5 patches? (Can be a little bit more when justified to finish up a particular line of thought) That way I can apply them in reviewable groups, without having to reject the whole series because some patch deep into the series has some problem. I'd suggest starting with absolutely critical fixes (if any!) as-is, to make backporting easier. By the looks of it I don't think there's any such patch in this series, but just in case there are any, they can be at the front. Then come the various cleanup patches and non-critical fixes - everything that is not supposed to change the behavior of the kernel. I'd suggest doing them in roughly this order: - file renames first - so that any later revert in a smaller patch does not have to go through a rename barrier. - then .o-invariant trivial cleanups, the fixing, harmonization (and creation ;-) of comments. - then come more involved cleanups like moving logic from build time to boot time, stricter bounds checks, non-essential fixes, etc. It might be useful if you declared at this stage that you are mostly done with the preparatory work and that the code base is ready for heavier changes, so that people (and me) can review the whole source for anything missing. Often a car needs a good power wash before we can tell what body work is needed. ... and once we are happy and proud about the code base, then come the more exciting things: more fundamental changes, and new features - on top of a squeaky clean code base. This all can happen pretty quickly, as long as the ordering is proper. Thanks, Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com Sender: Ingo Molnar Date: Sat, 16 Apr 2016 11:00:25 +0200 From: Ingo Molnar Message-ID: <20160416090025.GB30071@gmail.com> References: <1460672954-32567-1-git-send-email-keescook@chromium.org> <1460672954-32567-8-git-send-email-keescook@chromium.org> <20160415083105.GG30715@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: [kernel-hardening] Re: [PATCH v5 07/21] x86, boot: Fix run_size calculation To: Kees Cook Cc: Yinghai Lu , Junjie Mao , Josh Triplett , Andrew Morton , Baoquan He , Ard Biesheuvel , Matt Redfearn , "x86@kernel.org" , "H. Peter Anvin" , Ingo Molnar , Borislav Petkov , Vivek Goyal , Andy Lutomirski , lasse.collin@tukaani.org, Dave Young , "kernel-hardening@lists.openwall.com" , LKML List-ID: * Kees Cook wrote: > > So can we rename it to something more expressive, such as kernel_total_size or > > so? > > You got it. Thanks again for digging through all this! You are welcome! A couple of logistical suggestions: Could you please split up the series a bit and limit the next series to say no more than around 5 patches? (Can be a little bit more when justified to finish up a particular line of thought) That way I can apply them in reviewable groups, without having to reject the whole series because some patch deep into the series has some problem. I'd suggest starting with absolutely critical fixes (if any!) as-is, to make backporting easier. By the looks of it I don't think there's any such patch in this series, but just in case there are any, they can be at the front. Then come the various cleanup patches and non-critical fixes - everything that is not supposed to change the behavior of the kernel. I'd suggest doing them in roughly this order: - file renames first - so that any later revert in a smaller patch does not have to go through a rename barrier. - then .o-invariant trivial cleanups, the fixing, harmonization (and creation ;-) of comments. - then come more involved cleanups like moving logic from build time to boot time, stricter bounds checks, non-essential fixes, etc. It might be useful if you declared at this stage that you are mostly done with the preparatory work and that the code base is ready for heavier changes, so that people (and me) can review the whole source for anything missing. Often a car needs a good power wash before we can tell what body work is needed. ... and once we are happy and proud about the code base, then come the more exciting things: more fundamental changes, and new features - on top of a squeaky clean code base. This all can happen pretty quickly, as long as the ordering is proper. Thanks, Ingo