From: Florian Schmaus via ltp <ltp@lists.linux.it>
To: Andrea Cervesato <andrea.cervesato@suse.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] keyctl05: Use DNS_LOOKUP_GOOD to avoid false-negatives due to EKEYEXPIRED
Date: Wed, 14 Oct 2026 11:25:30 +0200 [thread overview]
Message-ID: <3a04280e-4f73-451c-be84-857a49c8ce16@codasip.com> (raw)
In-Reply-To: <zEv6AUi5JUa4zZxBhpChWHtlkQSFX3ZQ9BPa@localhost.localdomain>
On 14/10/2026 09.43, Andrea Cervesato wrote:
> Hi Florian,
>
>
>> In keyctl05, test_update_nonupdatable() verifies that
>> keyctl(KEYCTL_UPDATE) fails with EOPNOTSUPP on key types without an
>> ->update() method (such as 'dns_resolver').
>>
>> Commit 4e9400050683 ("keyctl05: Improve the dns_res_payload for boundary
>> testing") changed the dns_res_payload to a 6-byte V1 server-list header:
>> { 0x00, 0x00, 0x01, 0xff, 0x00, 0x00 }
>>
>> Byte 4 represents the lookup status (enum dns_lookup_status). Setting it
>> to 0x00 (DNS_LOOKUP_NOT_DONE) causes the kernel's dns_resolver_preparse()
>> (net/dns_resolver/dns_key.c) to treat it as a failed lookup:
>> if ((v1->status != DNS_LOOKUP_GOOD &&
>> v1->status != DNS_LOOKUP_GOOD_WITH_BAD)) {
>> if (prep->expiry == TIME64_MAX)
>> prep->expiry = ktime_get_real_seconds() + 1;
>> }
>>
>> This sets an aggressive 1-second expiration on the key. On slower
>> environments, such as QEMU, more than 1 second may elapse between
>> add_key() and keyctl(KEYCTL_UPDATE), causing the update call in
>> test_update_nonupdatable() to fail with EKEYEXPIRED (127) rather than
>> EOPNOTSUPP:
>> keyctl05.c:143: TFAIL: updating 'dns_resolver' key unexpectedly failed: EKEYEXPIRED (127)
>>
>> Set status (byte 4) in dns_res_payload to 0x01 (DNS_LOOKUP_GOOD) so
>> that the kernel does not set a 1-second negative expiry, while still
>> retaining the 6-byte boundary payload check for commit acc657692aed.
>
> Good catch. I'm wondering if it makes sense to use KEYCTL_SET_TIMEOUT in
> this case, but I guess we can rely on the test timeout in this case.
>
> did you explore this option already?
Sorry, no. This seemed like the less intrusive fix.
> Otherwise LGTM
>
> Reviewed-by: Andrea Cervesato <andrea.cervesato@suse.com>
Thanks!
>
> --
> Andrea Cervesato
> SUSE QE Automation Engineer Linux
> andrea.cervesato@suse.com
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-10-14 9:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 7:17 [LTP] [PATCH] keyctl05: Use DNS_LOOKUP_GOOD to avoid false-negatives due to EKEYEXPIRED Florian Schmaus via ltp
2026-10-14 7:36 ` [LTP] " linuxtestproject.agent
2026-10-14 7:43 ` [LTP] [PATCH] " Andrea Cervesato via ltp
2026-10-14 9:25 ` Florian Schmaus via ltp [this message]
2026-10-14 8:24 ` Andrea Cervesato via ltp
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=3a04280e-4f73-451c-be84-857a49c8ce16@codasip.com \
--to=ltp@lists.linux.it \
--cc=andrea.cervesato@suse.com \
--cc=florian.schmaus@codasip.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