All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yeoreum Yun <yeoreum.yun@arm.com>
To: Mark Brown <broonie@kernel.org>
Cc: catalin.marinas@arm.com, pcc@google.com, will@kernel.org,
	anshuman.khandual@arm.com, joey.gouly@arm.com,
	yury.khrustalev@arm.com, maz@kernel.org, oliver.upton@linux.dev,
	frederic@kernel.org, akpm@linux-foundation.org,
	surenb@google.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH v6 9/9] kselftest/arm64/mte: add mtefar tests on check_mmap_options
Date: Wed, 11 Jun 2025 14:34:28 +0100	[thread overview]
Message-ID: <aEmF5PYpgtsuTu9R@e129823.arm.com> (raw)
In-Reply-To: <9a81979b-2b9d-4bf6-88a0-5803483f802c@sirena.org.uk>

Hi Mark,
> On Wed, Jun 11, 2025 at 10:41:07AM +0100, Yeoreum Yun wrote:
>
> > +static int check_anonymous_memory_mapping(int mem_type, int mode, int mapping, int tag_check, int atag_check)
> >  {
> >  	char *ptr, *map_ptr;
> >  	int run, result, map_size;
> > @@ -97,16 +106,16 @@ static int check_anonymous_memory_mapping(int mem_type, int mode, int mapping, i
> >  			munmap((void *)map_ptr, map_size);
> >  			return KSFT_FAIL;
> >  		}
> > -		result = check_mte_memory(ptr, sizes[run], mode, tag_check);
> > +		result = check_mte_memory(ptr, sizes[run], mode, tag_check, atag_check);
> >  		mte_clear_tags((void *)ptr, sizes[run]);
> >  		mte_free_memory((void *)map_ptr, map_size, mem_type, false);
> > -		if (result == KSFT_FAIL)
> > -			return KSFT_FAIL;
> > +		if (result != KSFT_SKIP)
> > +			return result;
> >  	}
>
> This changes the logic to exit the loop immediately if the check passes
> which doesn't seem like what we want, should we instead change the test
> to be:
>
> 	if (result != KSFT_PASS)
>
> which I think is more the intent?

Well, at the time of write, when the check_mte_memory return the "SKIP"
intent is to iterating the next item. But, yes this is meandingless.
I'll change with your suggestion.

>
> > +		result = check_mte_memory(ptr, sizes[run], mode, TAG_CHECK_ON, atag_check);
> >  		mte_free_memory_tag_range((void *)ptr, sizes[run], mem_type, UNDERFLOW, OVERFLOW);
> >  		if (result != KSFT_PASS)
> >  			return KSFT_FAIL;
> > @@ -192,7 +201,7 @@ static int check_clear_prot_mte_flag(int mem_type, int mode, int mapping)
> >  			close(fd);
> >  			return KSFT_FAIL;
> >  		}
>
> Won't this upgrade any skips to fails?

Right. I'll change this.

Thanks!


--
Sincerely,
Yeoreum Yun


      reply	other threads:[~2025-06-11 17:59 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-11  9:40 [PATCH v6 0/9] support FEAT_MTE_TAGGED_FAR feature Yeoreum Yun
2025-06-11  9:40 ` [PATCH v6 1/9] arm64/cpufeature: add " Yeoreum Yun
2025-06-11  9:41 ` [PATCH v6 2/9] arm64: report address tag when FEAT_MTE_TAGGED_FAR is supported Yeoreum Yun
2025-06-11 11:43   ` Mark Brown
2025-06-11 12:19     ` Yeo Reum Yun
2025-06-11 12:35       ` Mark Brown
2025-06-11 13:16         ` Yeoreum Yun
2025-06-11  9:41 ` [PATCH v6 3/9] tools/kselftest: add MTE_FAR hwcap test Yeoreum Yun
2025-06-11  9:41 ` [PATCH v6 4/9] kselftest/arm64/mte: register mte signal handler with SA_EXPOSE_TAGBITS Yeoreum Yun
2025-06-11 11:45   ` Mark Brown
2025-06-11  9:41 ` [PATCH v6 5/9] kselftest/arm64/mte: check MTE_FAR feature is supported Yeoreum Yun
2025-06-11 11:52   ` Mark Brown
2025-06-11 12:23     ` Yeo Reum Yun
2025-06-11  9:41 ` [PATCH v6 6/9] kselftest/arm64/mte: add address tag related macro and function Yeoreum Yun
2025-06-11 11:58   ` Mark Brown
2025-06-11 12:25     ` Yeo Reum Yun
2025-06-11 12:37       ` Mark Brown
2025-06-11  9:41 ` [PATCH v6 7/9] kselftest/arm64/mte: add verification for address tag in signal handler Yeoreum Yun
2025-06-11 12:12   ` Mark Brown
2025-06-11 13:26     ` Yeoreum Yun
2025-06-11  9:41 ` [PATCH v6 8/9] kselftest/arm64/mte: refactor check_mmap_option test Yeoreum Yun
2025-06-11 12:27   ` Mark Brown
2025-06-11 13:28     ` Yeoreum Yun
2025-06-11  9:41 ` [PATCH v6 9/9] kselftest/arm64/mte: add mtefar tests on check_mmap_options Yeoreum Yun
2025-06-11 12:25   ` Mark Brown
2025-06-11 13:34     ` Yeoreum Yun [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=aEmF5PYpgtsuTu9R@e129823.arm.com \
    --to=yeoreum.yun@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=frederic@kernel.org \
    --cc=joey.gouly@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=pcc@google.com \
    --cc=surenb@google.com \
    --cc=will@kernel.org \
    --cc=yury.khrustalev@arm.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 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.