public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stefan Berger <stefanb@linux.ibm.com>
To: Jarkko Sakkinen <jarkko@kernel.org>,
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
	Lukas Wunner <lukas@wunner.de>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>,
	keyrings@vger.kernel.org, linux-crypto@vger.kernel.org,
	herbert@gondor.apana.org.au, davem@davemloft.net,
	linux-kernel@vger.kernel.org, saulo.alessandre@tse.jus.br,
	bbhushan2@marvell.com
Subject: Re: [PATCH v6 00/13] Add support for NIST P521 to ecdsa
Date: Thu, 21 Mar 2024 12:36:36 -0400	[thread overview]
Message-ID: <cce10484-99cb-4c2e-9768-862fc35a6725@linux.ibm.com> (raw)
In-Reply-To: <CZZKCJGKVP5N.3GUU48O4Y62KQ@kernel.org>



On 3/21/24 12:19, Jarkko Sakkinen wrote:
> On Thu Mar 21, 2024 at 6:17 PM EET, Jarkko Sakkinen wrote:
>> On Wed Mar 20, 2024 at 4:41 PM EET, Konstantin Ryabitsev wrote:
>>> On Wed, Mar 20, 2024 at 06:40:33AM +0100, Lukas Wunner wrote:
>>>> If Herbert applies patches with "b4 am --apply-cover-trailers" or
>>>> "b4 shazam --apply-cover-trailers" (I don't know if he does),
>>>> it is completely irrelevant whether Stefan strips my Tested-by from
>>>> individual patches:  It will automatically be re-added when the
>>>> series gets applied.
>>>
>>> Applying trailers sent to the cover letter is now the default behaviour in
>>> 0.13, so this flag is no longer required (it does nothing).
>>>
>>> -K
>>
>> The whole policy of how to put tested-by in my experience is subsystem
>> dependent.
>>
>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
>>
>> Official documentation only speaks about patches so perhaps it should
>> then be refined for the series.
>>
>> I'm hearing about this option in b4 for the first time in my life.
> 
> It is also pretty relevant to know when you read the commit log e.g.
> when bisecting what was *actually* tested.
> 
> If you put tested-by to whole series it probably means that you've
> tested the uapi and are getting the expected results. Thus in this
> case it would 13/13 that is *actually* tested.

Btw, we have 2 entry points into the code and those are uapi and testmgr.

So if I was to exercise the uapi with a NIST P521 key then are you 
saying that none of the other code was exercised and therefore wasn't 
tested? How would YOU suggest to test individual patches then?

What the docs at the link above say is this:

A Tested-by: tag indicates that the patch has been successfully tested 
(in some environment) by the person named. This tag informs maintainers 
that some testing has been performed, provides a means to locate testers 
for future patches, and ensures credit for the testers.

Note: 'some testing' 'in some environment'. We probably can reasonably 
assume that not only 13/13 is necessary but also several of the other 
patches are necessary to support this new curve and were exercised with 
either UAPI and probably also testmgr.

> 
> Putting tested-by to every possible patch only degrades the quality
> of the commit log.

I would still be interested how one would test individual patches in a 
series so they are worthy of a Tested-by tag.

> 
> I don't see how this is "irrelevant".
> 
> BR, Jarkko

  reply	other threads:[~2024-03-21 16:37 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-12 18:36 [PATCH v6 00/13] Add support for NIST P521 to ecdsa Stefan Berger
2024-03-12 18:36 ` [PATCH v6 01/13] crypto: ecc - Use ECC_CURVE_NIST_P192/256/384_DIGITS where possible Stefan Berger
2024-03-18 20:08   ` Jarkko Sakkinen
2024-03-12 18:36 ` [PATCH v6 02/13] crypto: ecdsa - Convert byte arrays with key coordinates to digits Stefan Berger
2024-03-18 20:21   ` Jarkko Sakkinen
2024-03-18 20:35     ` Lukas Wunner
2024-03-18 22:20       ` Jarkko Sakkinen
2024-03-12 18:36 ` [PATCH v6 03/13] crypto: ecdsa - Adjust tests on length of key parameters Stefan Berger
2024-03-18 20:25   ` Jarkko Sakkinen
2024-03-18 20:32     ` Lukas Wunner
2024-03-18 22:25       ` Jarkko Sakkinen
2024-03-12 18:36 ` [PATCH v6 04/13] crypto: ecdsa - Extend res.x mod n calculation for NIST P521 Stefan Berger
2024-03-18 20:33   ` Jarkko Sakkinen
2024-03-18 20:39     ` Lukas Wunner
2024-03-18 22:19       ` Jarkko Sakkinen
2024-03-12 18:36 ` [PATCH v6 05/13] crypto: ecc - Add nbits field to ecc_curve structure Stefan Berger
2024-03-18 20:34   ` Jarkko Sakkinen
2024-03-12 18:36 ` [PATCH v6 06/13] crypto: ecc - Implement vli_mmod_fast_521 for NIST p521 Stefan Berger
2024-03-18  5:47   ` [EXTERNAL] " Bharat Bhushan
2024-03-18 18:38     ` Stefan Berger
2024-03-19  3:53       ` Bharat Bhushan
2024-03-18 20:35   ` Jarkko Sakkinen
2024-03-12 18:36 ` [PATCH v6 07/13] crypto: ecc - Add special case for NIST P521 in ecc_point_mult Stefan Berger
2024-03-18 20:50   ` Jarkko Sakkinen
2024-03-12 18:36 ` [PATCH v6 08/13] crypto: ecc - Add NIST P521 curve parameters Stefan Berger
2024-03-18 21:05   ` Jarkko Sakkinen
2024-03-18 22:54     ` Stefan Berger
2024-03-12 18:36 ` [PATCH v6 09/13] crypto: ecdsa - Replace ndigits with nbits where precision is needed Stefan Berger
2024-03-18 21:06   ` Jarkko Sakkinen
2024-03-12 18:36 ` [PATCH v6 10/13] crypto: ecdsa - Rename keylen to bufsize where necessary Stefan Berger
2024-03-18 21:07   ` Jarkko Sakkinen
2024-03-12 18:36 ` [PATCH v6 11/13] crypto: ecdsa - Register NIST P521 and extend test suite Stefan Berger
2024-03-18 21:08   ` Jarkko Sakkinen
2024-03-12 18:36 ` [PATCH v6 12/13] crypto: asymmetric_keys - Adjust signature size calculation for NIST P521 Stefan Berger
2024-03-18  5:58   ` [EXTERNAL] " Bharat Bhushan
2024-03-18  7:06     ` Lukas Wunner
2024-03-19  3:38       ` Bharat Bhushan
2024-03-18 21:12   ` Jarkko Sakkinen
2024-03-18 22:42     ` Stefan Berger
2024-03-19 18:21       ` Jarkko Sakkinen
2024-03-12 18:36 ` [PATCH v6 13/13] crypto: x509 - Add OID for NIST P521 and extend parser for it Stefan Berger
2024-03-15 17:10 ` [PATCH v6 00/13] Add support for NIST P521 to ecdsa Stefan Berger
2024-03-18 18:48 ` Lukas Wunner
2024-03-18 22:42   ` Stefan Berger
2024-03-19 18:22     ` Jarkko Sakkinen
2024-03-19 18:25       ` Jarkko Sakkinen
2024-03-19 18:55       ` Stefan Berger
2024-03-19 19:14         ` Jarkko Sakkinen
2024-03-20  5:40       ` Lukas Wunner
2024-03-20 14:41         ` Konstantin Ryabitsev
2024-03-21 16:17           ` Jarkko Sakkinen
2024-03-21 16:19             ` Jarkko Sakkinen
2024-03-21 16:36               ` Stefan Berger [this message]
2024-03-21 16:50                 ` Jarkko Sakkinen

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=cce10484-99cb-4c2e-9768-862fc35a6725@linux.ibm.com \
    --to=stefanb@linux.ibm.com \
    --cc=bbhushan2@marvell.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=jarkko@kernel.org \
    --cc=keyrings@vger.kernel.org \
    --cc=konstantin@linuxfoundation.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=saulo.alessandre@tse.jus.br \
    --cc=stefanb@linux.vnet.ibm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox