On 07/03/2019 06:29 PM, Guenter Roeck wrote: > 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@xxxxxxx> >>>> --- >>>> 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 > Sure thanks, will post it out soon.
