From: Yael Tzur via ltp <ltp@lists.linux.it>
To: Petr Vorel <pvorel@suse.cz>
Cc: linux-integrity@vger.kernel.org, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v4] syscalls/keyctl09: test encrypted keys with provided decrypted data.
Date: Wed, 16 Mar 2022 16:10:59 -0400 [thread overview]
Message-ID: <CAKoutNsc-JWQd1MOTFk7Hd_MgsFKj=6qi=uusKez2HgatTNCdQ@mail.gmail.com> (raw)
In-Reply-To: <YiDLn3GMNFu482XG@pevik>
On Thu, Mar 3, 2022 at 9:07 AM Petr Vorel <pvorel@suse.cz> wrote:
>
> Hi Cyril,
>
> [ Cc Richie, Li, Jan ]
>
> > Hi!
> > > > > > I this case I guess that in this case the change is so minimal that we
> > > > > > can add this test into LTP once it reaches Linus tree.
> > > > > Cyril, maybe we could finally merge our policy (waiting ack for you):
> > > > > https://patchwork.ozlabs.org/project/ltp/patch/20220203101803.10204-1-rpalethorpe@suse.com/
> > > > > and put keyctl09 into runtest/staging now.
>
> > > > I guess that we still did not agree on exactly how this should be
> > > > handled or did we?
>
> > > Isn't it enough "Once a feature is part of the stable kernel ABI the associated
> > > test must be moved out of staging." ?
>
> > The main problem is that someone has to make sure that it happens and
> > the process would be prone to errors. What I proposed instead was a flag
> > that would set a kernel version in which the ABI is going to be merged
> > and put the test right into the final runtest files. Then we can simply
> > skip the test on older kernels or do anything else we see as a
> > reasonable solution. At the same time we can easily add automatic
> > checker that would look for these flags in metadata into the CI which
> > would, for instance, send email to the ML once the flag is supposed to
> > be removed.
> OK, you're missing that kernel version. OTOH things get sometimes backported,
> thus it's not error prone (if we forget to leave that flag after kernel being
> released).
>
> Also version is hard to say if you use maintainer tree (which applies patches on
> previous rc1 than what is being in Linus tree). Thus maintainer's tree would be
> left, also IMHO next tree has no specific version in uname, thus we'd only
> support rc from Linus' tree.
>
> But anyway, if all agree that this is better than both solutions Richie
> implemented I'd try to find time to implement it so that we have finally a
> solution.
>
> > In this case it does not actually matter, since the test is guarded by a
> > kernel config option that is introduced by the patchset and the change
> > is fairly miniminal, so I do not think that there would be any changes
> > to the ABI anyways.
> Correct. At this stage IMHO we can dare to merge it.
>
> Kind regards,
> Petr
Hi Petr and Cyril,
I wanted to check whether there is pending action left on my end?
Thanks,
Yael
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2022-03-16 20:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-23 20:07 [LTP] [PATCH v4] syscalls/keyctl09: test encrypted keys with provided decrypted data Yael Tzur via ltp
2022-03-02 15:53 ` Cyril Hrubis
2022-03-02 20:16 ` Yael Tzur via ltp
2022-03-03 6:14 ` Petr Vorel
2022-03-03 12:44 ` Cyril Hrubis
2022-03-03 13:26 ` Petr Vorel
2022-03-03 13:46 ` Cyril Hrubis
2022-03-03 14:07 ` Petr Vorel
2022-03-16 20:10 ` Yael Tzur via ltp [this message]
2022-03-17 20:38 ` Petr Vorel
2022-03-23 19:13 ` Petr Vorel
2022-03-24 13:35 ` Cyril Hrubis
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='CAKoutNsc-JWQd1MOTFk7Hd_MgsFKj=6qi=uusKez2HgatTNCdQ@mail.gmail.com' \
--to=ltp@lists.linux.it \
--cc=linux-integrity@vger.kernel.org \
--cc=pvorel@suse.cz \
--cc=yaelt@google.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;
as well as URLs for NNTP newsgroup(s).