Linux Test Project
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: Michael Menasherov <mmenashe@redhat.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v14 3/4] futex_wake05: Add EFAULT error coverage test
Date: Fri, 12 Jun 2026 19:56:15 +0200	[thread overview]
Message-ID: <aixIPzk4oTXw6Iaz@rei.lan> (raw)
In-Reply-To: <20260527092618.14824-4-mmenashe@redhat.com>

Hi!
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2026 Red Hat, Inc.
> + * Copyright (C) 2026 Michael Menasherov <mmenashe@redhat.com>
> + */
> +
> +/*\
> + * Check that futex(FUTEX_WAKE) returns EFAULT when uaddr points to
> + * unmapped or PROT_NONE memory.
> + *
> + * The test uses opflags=0 (no FUTEX_PRIVATE_FLAG), so futex_wake() takes
> + * the shared-futex path in get_futex_key() which must resolve the physical
> + * page. For PROT_NONE memory this page lookup fails with EFAULT, even though
> + * futex_wake() never reads *uaddr.

Maybe this should be more explicit and say that the unmapped address
takes different codepath than the PROT_NONE one. I had to check the
get_futex_key() to realize that this is one of the syscalls where
different types of EFAULT memory actually matters.

Also we have specific EFAULT handling for kernel addresses at the start
of the futex, so figuring out a kernel address and passing it to the
syscall would be a good idea as well.

Also there is a lot of NUMA specific code in there, so adding one more
test that requires NUMA and tries to hit the NUMA specific codepaths
would make sense as well.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2026-06-12 19:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-27  9:26 [LTP] [PATCH v14 0/4] futex: Add error coverage tests for wait, wake and cmp_requeue Michael Menasherov via ltp
2026-05-27  9:26 ` [LTP] [PATCH v14 1/4] futex_wait06: Add EFAULT error coverage test Michael Menasherov via ltp
2026-05-27  9:56   ` [LTP] " linuxtestproject.agent
2026-06-12 14:47   ` [LTP] [PATCH v14 1/4] " Cyril Hrubis
2026-05-27  9:26 ` [LTP] [PATCH v14 2/4] futex_wait07: Add EINTR " Michael Menasherov via ltp
2026-06-12 15:18   ` Cyril Hrubis
2026-05-27  9:26 ` [LTP] [PATCH v14 3/4] futex_wake05: Add EFAULT " Michael Menasherov via ltp
2026-06-12 17:56   ` Cyril Hrubis [this message]
2026-05-27  9:26 ` [LTP] [PATCH v14 4/4] futex_cmp_requeue03: " Michael Menasherov via ltp
2026-06-04  5:57 ` [LTP] [PATCH v14 0/4] futex: Add error coverage tests for wait, wake and cmp_requeue Michael Menasherov via ltp
2026-06-08 12:07 ` Michael Menasherov via ltp
2026-06-11  7:38 ` Michael Menasherov via ltp
2026-06-12 14:19   ` 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=aixIPzk4oTXw6Iaz@rei.lan \
    --to=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    --cc=mmenashe@redhat.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