All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Xionggui Chen <evers_chen@163.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Shuah Khan <shuah@kernel.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>,
	linux-mm@kvack.org, linux-kselftest@vger.kernel.org,
	linux-kernel@vger.kernel.org, chenxionggui@lanxincomputing.com
Subject: Re: [PATCH] selftests/mm: Handle implicit read permissions in madv_populate
Date: Fri, 13 Nov 2026 20:02:40 +0100	[thread overview]
Message-ID: <64e1c24f-08fb-437e-80c1-e5b486d15200@kernel.org> (raw)
In-Reply-To: <20261112031811.56500-1-evers_chen@163.com>

On 11/12/26 04:18, Xionggui Chen wrote:
> From: Xionggui Chen <chenxionggui@lanxincomputing.com>
> 
> The madv_populate selftest assumes that a mapping created with
> PROT_WRITE cannot be read, and expects MADV_POPULATE_READ to fail
> with EINVAL.
> 
> However, some architectures, including RISC-V, may implicitly grant
> read permission to PROT_WRITE mappings. On such architectures,
> MADV_POPULATE_READ succeeds, causing the test to fail incorrectly.
> 
> Check the actual VMA permissions through /proc/self/maps and adjust
> the expected result accordingly.
> 
> Add a PROT_NONE test to verify that MADV_POPULATE_READ still fails
> with EINVAL for mappings without read permission.
> 
> On RISC-V with Linux 7.2.0, the original test fails 1 out of 16
> tests, while the updated test passes all 17 tests.

I would have said, if RISCV is the odd one, special case it and call it a day?

That would keep the changes to test_prot_write() to a minimum.


-- 
Cheers,

David

      parent reply	other threads:[~2026-11-13 19:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-12  3:18 [PATCH] selftests/mm: Handle implicit read permissions in madv_populate Xionggui Chen
2026-11-12 19:32 ` Andrew Morton
2026-11-13  2:12   ` 陈熊贵 
2026-11-13  3:15   ` cxg
2026-11-13  3:19 ` sashiko-bot
2026-11-13  3:58   ` cxg
2026-11-13 19:02 ` David Hildenbrand (Arm) [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

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

  git send-email \
    --in-reply-to=64e1c24f-08fb-437e-80c1-e5b486d15200@kernel.org \
    --to=david@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=chenxionggui@lanxincomputing.com \
    --cc=evers_chen@163.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=shuah@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.