lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141218221249.GA10229@kroah.com>
Date:	Thu, 18 Dec 2014 14:12:49 -0800
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Brian Norris <computersforpeace@...il.com>
Cc:	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
	Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH] stable_kernel_rules: reorganize and update submission
 options

On Wed, Dec 17, 2014 at 11:11:16PM -0800, Brian Norris wrote:
> The current organization of Documentation/stable_kernel_rules.txt
> doesn't clearly differentiate the mutually exclusive options for
> submission to the -stable review process. As I understand it, patches
> are not actually required to be mailed directly to
> stable@...r.kernel.org, but the instructions do not make this clear.
> 
> Also, there are some established processes that are not listed --
> specifically, what I call Option 2 below.
> 
> This patch updates and reorganizes a bit, to make things clearer.
> 
> Signed-off-by: Brian Norris <computersforpeace@...il.com>
> ---
> This patch brough to you as a follow-up of:
> 
>   https://lkml.org/lkml/2014/9/5/757
> 
> I don't profess to know your mind, Greg, but this is my attempt at codifying
> what I've observed.
> 
>  Documentation/stable_kernel_rules.txt | 42 ++++++++++++++++++++++++++---------
>  1 file changed, 32 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt
> index aee73e78c7d4..a34adcb462b0 100644
> --- a/Documentation/stable_kernel_rules.txt
> +++ b/Documentation/stable_kernel_rules.txt
> @@ -32,18 +32,40 @@ Procedure for submitting patches to the -stable tree:
>   - If the patch covers files in net/ or drivers/net please follow netdev stable
>     submission guidelines as described in
>     Documentation/networking/netdev-FAQ.txt
> - - Send the patch, after verifying that it follows the above rules, to
> -   stable@...r.kernel.org.  You must note the upstream commit ID in the
> -   changelog of your submission, as well as the kernel version you wish
> -   it to be applied to.
> - - To have the patch automatically included in the stable tree, add the tag
> + - Security patches should not be handled (solely) by the -stable review
> +   process but should follow the procedures in Documentation/SecurityBugs.
> +
> +For all other submissions, choose one of the following procedures:
> +
> +   --- Option 1 ---
> +
> +   To have the patch automatically included in the stable tree, add the tag
>       Cc: stable@...r.kernel.org
>     in the sign-off area. Once the patch is merged it will be applied to
>     the stable tree without anything else needing to be done by the author
>     or subsystem maintainer.
> - - If the patch requires other patches as prerequisites which can be
> -   cherry-picked, then this can be specified in the following format in
> -   the sign-off area:
> +
> +   --- Option 2 ---
> +
> +   Send an email to stable@...r.kernel.org that just contains the commit ID
> +   of the patch -- after it has been merged to Linus' tree, of course.

"just" should also have at least the subject of the patch, why you think
it should be applied, and what kernel version you wish it to be applied
to.

> +
> +   --- Option 3 ---
> +
> +   Send the patch, after verifying that it follows the above rules, to
> +   stable@...r.kernel.org.  You must note the upstream commit ID in the
> +   changelog of your submission, as well as the kernel version you wish
> +   it to be applied to.
> +
> +Option 1 is probably the easiest and most common. Options 2 and 3 are more
> +useful if the patch isn't deemed worthy at the time it is applied to a public
> +git tree (for instance, because it deserves more regression testing first).
> +Option 3 is especially useful if the patch needs some special handling to apply
> +to an older kernel (e.g., if API's have changed in the meantime).
> +
> +Additionally, some patches submitted via Option 1 may have additional patch
> +prerequisites which can be cherry-picked. This can be specified in the following
> +format in the sign-off area:
>  
>       Cc: <stable@...r.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
>       Cc: <stable@...r.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
> @@ -57,13 +79,13 @@ Procedure for submitting patches to the -stable tree:
>       git cherry-pick fd21073
>       git cherry-pick <this commit>
>  
> +Following the submission:
> +
>   - The sender will receive an ACK when the patch has been accepted into the
>     queue, or a NAK if the patch is rejected.  This response might take a few
>     days, according to the developer's schedules.
>   - If accepted, the patch will be added to the -stable queue, for review by
>     other developers and by the relevant subsystem maintainer.
> - - Security patches should not be sent to this alias, but instead to the
> -   documented security@...nel.org address.

Other than the above comments, this looks good, care to redo it?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ