Hi everybody, Paul Gortmaker <paul.gortmaker <at> windriver.com> writes: > -this patch is against 3.10-rt, but the code for all recent -rt > that include the recent linux-stable rtmutex changes should have > the same issue. [The 3.14-rt has a trivial path change where the > kernel/rtmutex.c of v3.10 becomes kernel/locking/rtmutex.c but > aside from that it applies to 3.14 too] > > -I'd got a report of this BUG_ON triggering on a v3.4-rt based > kernel; that kernel was using my integration of the tglx rtmutex > stable changes into 3.4-rt as described here: > https://lkml.org/lkml/2014/9/23/944 > but the related code in rostedt's 3.10.53-rt56 (in linux-stable-rt) > and in tglx's 3.14.12-rt9 patch queue is AFAICT identical. So I > have to conclude that anything using the stable rtmutex changes > can inadvertently suffer the same BUG trigger. > > -this change gets us back to the pre-rtmutex stable commit behaviour, > but I suspect that smarter people than me can advise on a way to > achieve the same end result. So I'll wait before adding anything > to the linux-stable-rt branches I'd put here at: > https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-stable-rt.git What is the status of this patch? I have a machine here I can get to crash in about half an hour by doing a bidirectional iperf as proposed in <http://thread.gmane.org/gmane.linux.rt.user/12681>. Ffor posterity: The command is "iperf -c 1.2.3.4 -i 10 -d -l 64k -t 50400" which would normally do a 14 hour-iperf test against 1.2.3.4. My machine crashes with both 3.10.53-rt56 and 3.14.29-rt26. After applying your patch to 3.14 the machine has not crashed in 24 hours. Have "smarter people" had a chance to advise about this patch? Is there any reason not to use it? Regards, Philipp Tölke ��.n��������+%������w��{.n�����{�����ǫ���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
