This may be completely off-in-newbie land, but I figured I'd throw in what I think I've tracked down. It looks as if there was a fairly recent patch to turn locks in parts of the code into atomic instructions (apologies - I don't have the patch id to hand atm) in do_get_write_access() amongst others. Then in turn the C++ standard library loops around calls to write() whilst access isn't available, basically blocking on the atomic (which then in turn doesn't support priority inheritance), causing the wait loop. Absolutely one of the first things we need to do in our "userland" is to get the file writes out of the high priority code - that certainly makes every sense in the book. -----Original Message----- From: Theodore Ts'o [mailto:tytso@xxxxxxx] Sent: Thursday, January 03, 2013 8:19 AM To: Steven Rostedt Cc: Staffan Tjernstrom; linux-rt-users@xxxxxxxxxxxxxxx; tglx@xxxxxxxxxxxxx; C.Emde@xxxxxxxxx; jkacur@xxxxxxxxxx Subject: Re: Observed deadlock in ext4 under 3.2.23-rt37 & 3.2.33-rt50 On Thu, Jan 03, 2013 at 08:21:31AM -0500, Steven Rostedt wrote: > Anytime you have something that does the following in order to break > lock ordering: > > repeat: > lock(A); > <do something> > if (!trylock(B)) { > unlock(A); > cpu_relax(); > goto repeat; > } > > > We can live lock, because spinlocks in -rt turn into a mutex. Thus, > the holder of lock B may not be on another CPU but actually on the > current CPU and is waiting for the process that is in this loop. If > that process happens to be an RT task, then the system stops. Good point, but I'm prety sure we don't have any kind of trylock loops in either fs/ext4 or fs/jbd2, though. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
