On Wed, Jun 21, 2017 at 11:43:05AM +0900, AKASHI Takahiro wrote: > On Tue, Jun 20, 2017 at 06:07:00PM +0100, Will Deacon wrote: > > On Tue, Jun 20, 2017 at 11:43:34AM +0900, AKASHI Takahiro wrote: > > > On Wed, Jun 07, 2017 at 05:50:18PM +0100, Will Deacon wrote: > > > > On Wed, Jun 07, 2017 at 02:34:50PM +0900, AKASHI Takahiro wrote: > > > > > > Ok, but don't we need to re-enable interrupts, otherwise we can't safely > > > > handle the fault (which might involve blocking)? > > > > > > I thought a lot, but have got no other way to solve the issue, which > > > totally makes stepi in vain. > > > In theory, you might be right, but in practice, people don't always expect > > > to step through the whole sequence of fault recovery with single stepping. > > > Once we do 'c(ontinue),' interrupts are enabled again and the execution > > > will follow as expected. > > > > It's not the stepping guarantees I'm worried about. I'm more worried that > > the fault handler panics because it's called with IRQs disabled, > > I'm still wondering how it can cause panic.
Well you're calling the page fault path with interrupts disabled. It might try to allocate page tables without passing GFP_ATOMIC, or it might block on I/O or reschedule. The answer might well be "you can't step put_user and friends", but perhaps we should try to enforce that rather than go horribly wrong if you do it. Will ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Kgdb-bugreport mailing list Kgdb-bugreport@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
