Messages in this thread | | | Subject | Re: [DRAFT] mm/kprobes: Add generic kprobe_fault_handler() fallback definition | From | Guenter Roeck <> | Date | Wed, 3 Jul 2019 05:59:01 -0700 |
| |
On 7/2/19 10:35 PM, Anshuman Khandual wrote: > > > On 07/01/2019 06:58 PM, Guenter Roeck wrote: >> On 7/1/19 2:35 AM, Anshuman Khandual wrote: >>> Architectures like parisc enable CONFIG_KROBES without having a definition >>> for kprobe_fault_handler() which results in a build failure. Arch needs to >>> provide kprobe_fault_handler() as it is platform specific and cannot have >>> a generic working alternative. But in the event when platform lacks such a >>> definition there needs to be a fallback. >>> >>> This adds a stub kprobe_fault_handler() definition which not only prevents >>> a build failure but also makes sure that kprobe_page_fault() if called will >>> always return negative in absence of a sane platform specific alternative. >>> >>> While here wrap kprobe_page_fault() in CONFIG_KPROBES. This enables stud >>> definitions for generic kporbe_fault_handler() and kprobes_built_in() can >>> just be dropped. Only on x86 it needs to be added back locally as it gets >>> used in a !CONFIG_KPROBES function do_general_protection(). >>> >>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> >>> --- >>> I am planning to go with approach unless we just want to implement a stub >>> definition for parisc to get around the build problem for now. >>> >>> Hello Guenter, >>> >>> Could you please test this in your parisc setup. Thank you. >>> >> >> With this patch applied on top of next-20190628, parisc:allmodconfig builds >> correctly. I scheduled a full build for tonight for all architectures. > > How did that come along ? Did this pass all build tests ? >
Let's say it didn't find any failures related to this patch. I built on top of next-20190701 which was quite badly broken for other reasons. Unfortunately, next-20190702 is much worse, so retesting would not add any value at this time. I'd say go for it.
Guenter
| |