Messages in this thread | | | Subject | Re: [PATCH 2/2] riscv: Add KASAN support | From | Andrey Ryabinin <> | Date | Thu, 22 Aug 2019 20:08:00 +0300 |
| |
On 8/14/19 10:44 AM, Nick Hu wrote:
>> >>> diff --git a/arch/riscv/kernel/vmlinux.lds.S b/arch/riscv/kernel/vmlinux.lds.S >>> index 23cd1a9..9700980 100644 >>> --- a/arch/riscv/kernel/vmlinux.lds.S >>> +++ b/arch/riscv/kernel/vmlinux.lds.S >>> @@ -46,6 +46,7 @@ SECTIONS >>> KPROBES_TEXT >>> ENTRY_TEXT >>> IRQENTRY_TEXT >>> + SOFTIRQENTRY_TEXT >> >> Hmm. What is the relation to kasan here? Maybe we should add this >> separately with a good changelog? >> > There is a commit for it: > > Author: Alexander Potapenko <glider@google.com> > Date: Fri Mar 25 14:22:05 2016 -0700 > > arch, ftrace: for KASAN put hard/soft IRQ entries into separate sections > > KASAN needs to know whether the allocation happens in an IRQ handler. > This lets us strip everything below the IRQ entry point to reduce the > number of unique stack traces needed to be stored. > > Move the definition of __irq_entry to <linux/interrupt.h> so that the > users don't need to pull in <linux/ftrace.h>. Also introduce the > __softirq_entry macro which is similar to __irq_entry, but puts the > corresponding functions to the .softirqentry.text section. > > After reading the patch I understand that soft/hard IRQ entries should be > separated for KASAN to work, but why? >
KASAN doesn't need soft/hard IRQ entries separated. KASAN wants to know the entry point of IRQ (hard or soft) to filter out random non-irq part of the stacktrace before feeding it to stack_depot_save. See filter_irq_stacks().
| |