Am 07.02.2016 um 17:55 schrieb Borislav Petkov: > due to those > >> + _ASM_EXTABLE_FAULT(0b,30b) >> + _ASM_EXTABLE_FAULT(1b,31b) >> + _ASM_EXTABLE_FAULT(2b,32b) >> + _ASM_EXTABLE_FAULT(3b,33b) >> + _ASM_EXTABLE_FAULT(4b,34b) > > things below and that's because ex_handler_fault() is defined in > arch/x86/mm/extable.c and UML doesn't include that file in the build. It > takes kernel/extable.c and lib/extable.c only. > > Richi, what's the usual way to address that in UML? I.e., make an > x86-only symbol visible to the UML build too? Define a dummy one, just > so that it builds? As discussed on IRC with Boris, UML offers only minimal extable support. To get rid of the said #ifndef, UML would have to provide its own extable.c (mostly copy&paste from arch/x86) and an advanced struct exception_table_entry which includes the trap number. This implies also that UML can no longer use uaccess.h from asm-generic or has to add a new ifdef into uaccess.h to whiteout the minimal struct exception_table_entry from there. So, I'd vote to keep the #ifndef CONFIG_UML in memcpy_64.S. As soon you need another #ifndef please ping me and I'll happily bite the bullet and implement the advanced extable stuff for UML. Deal? Thanks, //richard -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>