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.
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com> To: Vincenzo Frascino <vincenzo.frascino@arm.com> Cc: Branislav Rankov <Branislav.Rankov@arm.com>, Will Deacon <will@kernel.org>, Catalin Marinas <catalin.marinas@arm.com>, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Alexander Potapenko <glider@google.com>, linux-arm-kernel@lists.infradead.org, Andrey Konovalov <andreyknvl@google.com>, Dmitry Vyukov <dvyukov@google.com>, Andrey Ryabinin <aryabinin@virtuozzo.com>, Marco Elver <elver@google.com>, Evgenii Stepanov <eugenis@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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-01-19 15:14 UTC|newest] Thread overview: 54+ 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 ` Vincenzo Frascino 2021-01-18 18:30 ` [PATCH v4 1/5] arm64: mte: Add asynchronous " Vincenzo Frascino 2021-01-18 18:30 ` Vincenzo Frascino 2021-01-19 12:57 ` Catalin Marinas 2021-01-19 12:57 ` Catalin Marinas 2021-01-19 18:10 ` Andrey Konovalov 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-18 18:30 ` Vincenzo Frascino 2021-01-19 18:10 ` Andrey Konovalov 2021-01-19 18:10 ` Andrey Konovalov 2021-01-20 14:45 ` Vincenzo Frascino 2021-01-20 14:45 ` Vincenzo Frascino 2021-01-21 16: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-18 18:30 ` Vincenzo Frascino 2021-01-19 13:04 ` Catalin Marinas 2021-01-19 13:04 ` Catalin Marinas 2021-01-19 14:23 ` Vincenzo Frascino 2021-01-19 14:23 ` Vincenzo Frascino 2021-01-19 14:46 ` Mark Rutland [this message] 2021-01-19 14:46 ` Mark Rutland 2021-01-19 15:05 ` Vincenzo Frascino 2021-01-19 15:05 ` Vincenzo Frascino 2021-01-19 18:12 ` Andrey Konovalov 2021-01-19 18:12 ` Andrey Konovalov 2021-01-20 14:46 ` Vincenzo Frascino 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-18 18:30 ` Vincenzo Frascino 2021-01-19 14:34 ` Catalin Marinas 2021-01-19 14:34 ` Catalin Marinas 2021-01-19 14:45 ` Vincenzo Frascino 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-18 18:30 ` Vincenzo Frascino 2021-01-19 14:45 ` Catalin Marinas 2021-01-19 14:45 ` Catalin Marinas 2021-01-19 15:48 ` Vincenzo Frascino 2021-01-19 15:48 ` Vincenzo Frascino 2021-01-19 18:12 ` Andrey Konovalov 2021-01-19 18:12 ` Andrey Konovalov 2021-01-19 19:00 ` Catalin Marinas 2021-01-19 19:00 ` Catalin Marinas 2021-01-19 19:34 ` Andrey Konovalov 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-19 18:09 ` Andrey Konovalov 2021-01-21 11:35 ` Vincenzo Frascino 2021-01-21 11:35 ` Vincenzo Frascino 2021-01-21 12:25 ` Andrey Konovalov 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: linkBe 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.