All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-rt-users@vger.kernel.org,
	Eric Biggers <ebiggers@google.com>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: Re: [PATCH crypto-stable v3 1/2] crypto: arch/lib - limit simd usage to 4k chunks
Date: Thu, 23 Apr 2020 20:42:19 +0200	[thread overview]
Message-ID: <20200423184219.GA80650@kroah.com> (raw)
In-Reply-To: <CAMj1kXHV=ryaFmj0jhQVGBd31nfHs7q5RtSyu7dY6GdEJJsr7A@mail.gmail.com>

On Thu, Apr 23, 2020 at 09:18:15AM +0200, Ard Biesheuvel wrote:
> FYI: you shouldn't cc stable@vger.kernel.org directly on your patches,
> or add the cc: line. Only patches that are already in Linus' tree
> should be sent there.

Not true at all, please read:
    https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.  Please do not spread incorrect
information.

And Jason did this properly, he put cc: stable@ in the s-o-b area and
all is good, I will pick up this patch once it hits Linus's tree.

And there is no problem actually sending the patch to stable@vger while
under development like this, as it gives me a heads-up that something is
coming, and is trivial to filter out.

If you really want to be nice, you can just do:
	cc: stable@kernel.org
which goes to /dev/null on kernel.org, so no email will be sent to any
list, but my scripts still pick it up.  But no real need to do that,
it's fine.

> Also, the fixes tags are really quite sufficient.

No it is not, I have had to dig out patches more and more because people
do NOT put the cc: stable and only put Fixes:, which is not a good thing
as I then have to "guess" what the maintainer/developer ment.

Be explicit if you know it, cc: stable please.

> In fact, it is
> actually rather difficult these days to prevent something from being
> taken into -stable if the bots notice that it applies cleanly.

Those "bots" are still driven by a lot of human work, please make it
easy on us whenever possible.

thanks,

greg k-h

  parent reply	other threads:[~2020-04-23 18:42 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-20  7:57 [PATCH crypto-stable] crypto: arch/lib - limit simd usage to PAGE_SIZE chunks Jason A. Donenfeld
2020-04-20  8:32 ` David Laight
2020-04-21  4:02   ` Jason A. Donenfeld
2020-04-21  4:14   ` FPU register granularity [Was: Re: [PATCH crypto-stable] crypto: arch/lib - limit simd usage to PAGE_SIZE chunks] Jason A. Donenfeld
2020-04-21  4:25     ` Jason A. Donenfeld
2020-04-21  7:02     ` Ard Biesheuvel
2020-04-21  8:05       ` David Laight
2020-04-21  8:11     ` David Laight
2020-04-22  4:04 ` [PATCH crypto-stable] crypto: arch/lib - limit simd usage to PAGE_SIZE chunks Eric Biggers
2020-04-22  7:23   ` Ard Biesheuvel
2020-04-22  7:38     ` Jason A. Donenfeld
2020-04-22 11:28     ` Sebastian Andrzej Siewior
2020-04-22 19:35       ` Jason A. Donenfeld
2020-04-22  7:32   ` Jason A. Donenfeld
2020-04-22  7:39     ` Ard Biesheuvel
2020-04-22 19:51       ` Jason A. Donenfeld
2020-04-22 20:17         ` Jason A. Donenfeld
2020-04-23  8:45           ` Ard Biesheuvel
2020-04-22 20:03 ` [PATCH crypto-stable v2] crypto: arch - limit simd usage to 4k chunks Jason A. Donenfeld
2020-04-22 22:39   ` Eric Biggers
2020-04-22 23:09     ` Jason A. Donenfeld
2020-04-22 23:18   ` [PATCH crypto-stable v3 1/2] crypto: arch/lib " Jason A. Donenfeld
2020-04-22 23:18     ` [PATCH crypto-stable v3 2/2] crypto: arch/nhpoly1305 - process in explicit " Jason A. Donenfeld
2020-04-23 20:39       ` Eric Biggers
2020-04-23  7:18     ` [PATCH crypto-stable v3 1/2] crypto: arch/lib - limit simd usage to " Ard Biesheuvel
2020-04-23  7:40       ` Christophe Leroy
2020-04-23  7:47         ` Ard Biesheuvel
2020-04-23 18:42       ` Greg KH [this message]
2020-04-23 18:47         ` Ard Biesheuvel
2020-04-23 20:23           ` Eric Biggers
2020-04-23 20:49             ` Ard Biesheuvel
2020-04-28 23:09               ` Jason A. Donenfeld
2020-04-30  5:30     ` Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200423184219.GA80650@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=Jason@zx2c4.com \
    --cc=ardb@kernel.org \
    --cc=bigeasy@linutronix.de \
    --cc=ebiggers@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.