unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Tulio Magno Quites Machado Filho <tuliom@ascii.art.br>
To: "Lucas A. M. Magalhaes" <lamm@linux.ibm.com>, libc-alpha@sourceware.org
Cc: fweimer@redhat.com
Subject: Re: [PATCH v4] Fix tst-pkey expectations on pkey_get [BZ #23202]
Date: Wed, 19 Feb 2020 11:41:05 -0300	[thread overview]
Message-ID: <87sgj6wsfy.fsf@linux.ibm.com> (raw)
In-Reply-To: <20200217120952.5219-1-lamm@linux.ibm.com>

"Lucas A. M. Magalhaes" <lamm@linux.ibm.com> writes:

> From the GNU C Library manual the pkey_set can receive a combination of
> PKEY_DISABLE_WRITE and PKEY_DISABLE_ACCESS.  However PKEY_DISABLE_ACCESS
> is more restrictive than PKEY_DISABLE_WRITE and includes its behavior.
>
> The test expects that after setting
> (PKEY_DISABLE_WRITE|PKEY_DISABLE_ACCESS) pkey_get should return the
> same.  This may not be true as PKEY_DISABLE_ACCESS will succeed in
> describe the state of the key in this case.
>
> The pkey behavior during signal handling is different between x86 and
> POWER.  This change make the test compatible with both architectures.

The patch LGTM.
This test is now passing on Linux >= 5.0, but it still fails on Linux <= 4.18
because of issues in the kernel.
I'm not sure if 4.19 should work.

Old kernels do return valid data:

[pid 56757] pkey_alloc(0, 0 <unfinished ...>
[pid 56758] set_robust_list(0x7fff8994f260, 24 <unfinished ...>
[pid 56757] <... pkey_alloc resumed> )  = 2
[pid 56758] <... set_robust_list resumed> ) = 0
[pid 56757] pkey_alloc(0, PKEY_DISABLE_ACCESS <unfinished ...>
[pid 56758] futex(0x100208a4, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 56757] <... pkey_alloc resumed> )  = 3
[pid 56757] pkey_alloc(0, PKEY_DISABLE_WRITE) = 4
[pid 56757] mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fff89130000
[pid 56757] pkey_mprotect(0x7fff89130000, 65536, PROT_READ|PROT_WRITE, 2) = 0
[pid 56757] mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fff89120000
[pid 56757] pkey_mprotect(0x7fff89120000, 65536, PROT_READ|PROT_WRITE, 3) = 0
[pid 56757] mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fff89110000
[pid 56757] pkey_mprotect(0x7fff89110000, 65536, PROT_READ|PROT_WRITE, 4) = 0
[pid 56757] futex(0x100208a4, FUTEX_WAKE_PRIVATE, 2147483647) = 1
[pid 56758] <... futex resumed> )       = 0
[pid 56757] futex(0x7fff8994f250, FUTEX_WAIT, 56758, NULL <unfinished ...>
[pid 56758] mmap(NULL, 134217728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x7fff81110000
[pid 56758] munmap(0x7fff81110000, 49217536) = 0
[pid 56758] munmap(0x7fff88000000, 17891328) = 0
[pid 56758] mprotect(0x7fff84000000, 196608, PROT_READ|PROT_WRITE) = 0
[pid 56758] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid 56758] rt_sigaction(SIGSEGV, {sa_handler=0x1001fca8, sa_mask=[], sa_flags=SA_RESETHAND|SA_SIGINFO}, NULL, 8) = 0
[pid 56758] rt_sigaction(SIGSEGV, {sa_handler=SIG_DFL, sa_mask=[SEGV], sa_flags=SA_RESTART}, {sa_handler=0x1001fca8, sa_mask=[], sa_flags=SA_RESETHAND|SA_SIGINFO}, 8) = 0
[pid 56758] write(1, "error: ../sysdeps/unix/sysv/linu"..., 90error: ../sysdeps/unix/sysv/linux/tst-pkey.c:161: not true: !check_page_access (i, false)
) = 90

Anyway, pushed as 8d42bf859a289944749d9f978c076cd318119867.

Thanks!

-- 
Tulio Magno

      parent reply	other threads:[~2020-02-19 14:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-07 13:46 [PATCH] Fix tst-pkey expectations on pkey_get Lucas A. M. Magalhaes
2020-02-07 18:22 ` Florian Weimer
2020-02-11 14:03   ` Lucas A. M. Magalhaes
2020-02-11 16:08     ` Florian Weimer
2020-02-12 16:45       ` Lucas A. M. Magalhaes
2020-02-12 17:17         ` Florian Weimer
2020-02-13 18:41 ` [PATCH V2] " Lucas A. M. Magalhaes
2020-02-14 17:02   ` Florian Weimer
2020-02-14 20:44   ` [PATCH v3] Fix tst-pkey expectations on pkey_get [BZ #23202] Lucas A. M. Magalhaes
2020-02-15 13:12     ` Florian Weimer
2020-02-17 12:09       ` [PATCH v4] " Lucas A. M. Magalhaes
2020-02-17 12:50         ` Florian Weimer
2020-02-19 14:41         ` Tulio Magno Quites Machado Filho [this message]

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

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sgj6wsfy.fsf@linux.ibm.com \
    --to=tuliom@ascii.art.br \
    --cc=fweimer@redhat.com \
    --cc=lamm@linux.ibm.com \
    --cc=libc-alpha@sourceware.org \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).