Linux Test Project
 help / color / mirror / Atom feed
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

  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