linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Andrey Konovalov <andreyknvl@google.com>,
	Branislav Rankov <Branislav.Rankov@arm.com>,
	Marco Elver <elver@google.com>,
	Evgenii Stepanov <eugenis@google.com>,
	linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,
	Alexander Potapenko <glider@google.com>,
	linux-arm-kernel@lists.infradead.org,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Will Deacon <will@kernel.org>, Dmitry Vyukov <dvyukov@google.com>
Subject: Re: [PATCH v4 3/5] kasan: Add report for async mode
Date: Tue, 19 Jan 2021 14:46:25 +0000	[thread overview]
Message-ID: <20210119144625.GB2338@C02TD0UTHF1T.local> (raw)
In-Reply-To: <813f907f-0de8-6b96-c67a-af9aecf31a70@arm.com>

On Tue, Jan 19, 2021 at 02:23:03PM +0000, Vincenzo Frascino wrote:
> On 1/19/21 1:04 PM, Catalin Marinas wrote:
> > On Mon, Jan 18, 2021 at 06:30:31PM +0000, Vincenzo Frascino wrote:

> >> +bool kasan_report_async(unsigned long addr, size_t size,
> >> +			bool is_write, unsigned long ip);
> > 
> > We have no address, no size and no is_write information. Do we have a
> > reason to pass all these arguments here? Not sure what SPARC ADI does
> > but they may not have all this information either. We can pass ip as the
> > point where we checked the TFSR reg but that's about it.
> 
> I kept the interface generic for future development and mainly to start a
> discussion. I do not have a strong opinion either way. If Andrey agrees as well
> I am happy to change it to what you are suggesting in v5.

For now, I think it's preferable that this only has parameters that we
can actually provide. That way it's clearer what's going on in both
callers and callees, and we can always rework the prototype later or add
separate variants of the function that can take additional parameters.

I don't think we even need to use __kasan_report() -- more on that
below.

[...]

> >> @@ -388,11 +388,11 @@ static void __kasan_report(unsigned long addr, size_t size, bool is_write,
> >>  	start_report(&flags);
> >>  
> >>  	print_error_description(&info);
> >> -	if (addr_has_metadata(untagged_addr))
> >> +	if (addr_has_metadata(untagged_addr) && (untagged_addr != 0))
> >>  		print_tags(get_tag(tagged_addr), info.first_bad_addr);
> >>  	pr_err("\n");
> >>  
> >> -	if (addr_has_metadata(untagged_addr)) {
> >> +	if (addr_has_metadata(untagged_addr) && (untagged_addr != 0)) {
> >>  		print_address_description(untagged_addr, get_tag(tagged_addr));
> >>  		pr_err("\n");
> >>  		print_memory_metadata(info.first_bad_addr);
> >> @@ -419,6 +419,18 @@ bool kasan_report(unsigned long addr, size_t size, bool is_write,
> >>  	return ret;
> >>  }
> >>  
> >> +bool kasan_report_async(unsigned long addr, size_t size,
> >> +			bool is_write, unsigned long ip)
> >> +{
> >> +	pr_info("==================================================================\n");
> >> +	pr_info("KASAN: set in asynchronous mode\n");
> >> +	pr_info("KASAN: some information might not be accurate\n");
> >> +	pr_info("KASAN: fault address is ignored\n");
> >> +	pr_info("KASAN: write/read distinction is ignored\n");
> >> +
> >> +	return kasan_report(addr, size, is_write, ip);
> > 
> > So just call kasan_report (0, 0, 0, ip) here.

Given there's no information available, I think it's simpler and
preferable to handle the logging separately, as is done for
kasan_report_invalid_free(). For example, we could do something roughly
like:

void kasan_report_async(void)
{
	unsigned long flags;

	start_report(&flags);
	pr_err("BUG: KASAN: Tag mismatch detected asynchronously\n");
	pr_err("KASAN: no fault information available\n");
	dump_stack();
	end_report(&flags);
}

... which is easier to consume, since there's no misleading output,
avoids complicating the synchronous reporting path, and we could
consider adding information that's only of use for debugging
asynchronous faults here.

Since the callside is logged in the backtrace, we don't even need the
synthetic IP parameter.

Thanks,
Mark.

  reply	other threads:[~2021-01-19 15:14 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-18 18:30 [PATCH v4 0/5] arm64: ARMv8.5-A: MTE: Add async mode support Vincenzo Frascino
2021-01-18 18:30 ` [PATCH v4 1/5] arm64: mte: Add asynchronous " Vincenzo Frascino
2021-01-19 12:57   ` Catalin Marinas
2021-01-19 18:10   ` Andrey Konovalov
2021-01-18 18:30 ` [PATCH v4 2/5] kasan: Add KASAN mode kernel parameter Vincenzo Frascino
2021-01-19 18:10   ` Andrey Konovalov
2021-01-20 14:45     ` Vincenzo Frascino
2021-01-21 16:45     ` Vincenzo Frascino
2021-01-18 18:30 ` [PATCH v4 3/5] kasan: Add report for async mode Vincenzo Frascino
2021-01-19 13:04   ` Catalin Marinas
2021-01-19 14:23     ` Vincenzo Frascino
2021-01-19 14:46       ` Mark Rutland [this message]
2021-01-19 15:05         ` Vincenzo Frascino
2021-01-19 18:12         ` Andrey Konovalov
2021-01-20 14:46           ` Vincenzo Frascino
2021-01-18 18:30 ` [PATCH v4 4/5] arm64: mte: Enable async tag check fault Vincenzo Frascino
2021-01-19 14:34   ` Catalin Marinas
2021-01-19 14:45     ` Vincenzo Frascino
2021-01-18 18:30 ` [PATCH v4 5/5] arm64: mte: Inline mte_assign_mem_tag_range() Vincenzo Frascino
2021-01-19 14:45   ` Catalin Marinas
2021-01-19 15:48     ` Vincenzo Frascino
2021-01-19 18:12       ` Andrey Konovalov
2021-01-19 19:00         ` Catalin Marinas
2021-01-19 19:34           ` Andrey Konovalov
2021-01-19 18:09 ` [PATCH v4 0/5] arm64: ARMv8.5-A: MTE: Add async mode support Andrey Konovalov
2021-01-21 11:35   ` Vincenzo Frascino
2021-01-21 12:25     ` Andrey Konovalov

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=20210119144625.GB2338@C02TD0UTHF1T.local \
    --to=mark.rutland@arm.com \
    --cc=Branislav.Rankov@arm.com \
    --cc=andreyknvl@google.com \
    --cc=aryabinin@virtuozzo.com \
    --cc=catalin.marinas@arm.com \
    --cc=dvyukov@google.com \
    --cc=elver@google.com \
    --cc=eugenis@google.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vincenzo.frascino@arm.com \
    --cc=will@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 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 NNTP newsgroup(s).