On 05/07/2018 04:30 AM, Michael Ellerman wrote: > Benjamin Herrenschmidt <b...@kernel.crashing.org> writes: >> On Fri, 2018-05-04 at 20:42 +1000, Michael Ellerman wrote: >>> Cédric Le Goater <c...@kaod.org> writes: >>> >>>> This is not the case for the moment, but future releases of pHyp might >>>> need to introduce some synchronisation routines under the hood which >>>> would make the XIVE hcalls longer to complete. >>>> >>>> As this was done for H_INT_RESET, let's wrap the other hcalls in a >>>> loop catching the H_LONG_BUSY_* codes. >>> >>> Are we sure it's safe to msleep() in all these paths? >> >> Probably not. We can have the IRQ descriptor lock. We might need to >> mdelay. >> >> There's a Kconfig option (forgot which one) that will add checks for >> attempts to sleep inside locks, you should run with that. > > CONFIG_DEBUG_ATOMIC_SLEEP
[ 435.757986] kexec_core: Starting new kernel [ 435.778162] BUG: scheduling while atomic: kexec/1633/0x00000003 That proved to be useful. Thanks. I will resend the full series changing msleep() to mdelay() and fixing a bit the changelog. Cheers, C.
