2.6.13-rt1

2.6.13-rt1

[Ingo Molnar]

i have released the 2.6.13-rt1 tree, which can be downloaded from the 
usual place:

  http://redhat.com/~mingo/realtime-preempt/

the new "eliminate the global PI lock" code from Steven Rostedt is now 
ready for prime-time. Smaller fixes otherwise. Please re-report any 
remaining regressions.

Changes since 2.6.13-rc7-rt1:

 - second (final) phase p->pi_lock SMP scalability improvement: replace 
   the pi_lock with per-task ->pi_lock and eliminate the global pi_lock 
   (Steven Rostedt)

 - fix for ->pi_lock code (Steven Rostedt)

 - improve ->pi_lock code on UP (Steven Rostedt)

 - x86_64 boot fix (Daniel Walker)

 - ALL_TASKS_PI fixes (Daniel Walker)

 - enabled ALL_TASKS_PI for debugging purposes

 - merge to 2.6.13-final

to build a 2.6.13-rt1 tree, the following patches should be applied:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.13.tar.bz2
   http://redhat.com/~mingo/realtime-preempt/patch-2.6.13-rt1

	Ingo

Re: 2.6.13-rt1

[Steven Rostedt]

Ingo,

I think you have a slight glitch in your patch.

-- Steve

$ patch -p1 -s < /work/realtime-patches/patch-2.6.13-rt1
The next patch would delete the file Makefile.rej,
which does not exist!  Assume -R? [n]
Apply anyway? [n]

Re: 2.6.13-rt1

[Ingo Molnar]

* Steven Rostedt <rostedt@goodmis.org> wrote:

> Ingo,
> 
> I think you have a slight glitch in your patch.
> 
> -- Steve
> 
> $ patch -p1 -s < /work/realtime-patches/patch-2.6.13-rt1
> The next patch would delete the file Makefile.rej,
> which does not exist!  Assume -R? [n]
> Apply anyway? [n]

indeed. I fixed this up in the file without uploading a new release, so 
new downloads shouldnt see this.

	Ingo

Re: 2.6.13-rt1

[Hubert Tonneau]

I gave this one a spin, and my laptop locked hard after something like one hour
(everything frozen). As a result what I report is probably not very helpfull.

It was the first time I was trying an RT kernel, and the stock kernel works ok
on this laptop (except suspend, but one can do without it).

CONFIG_1GB:  y
CONFIG_ACPI:  y
CONFIG_ACPI_AC:  m
CONFIG_ACPI_BATTERY:  m
CONFIG_ACPI_BUTTON:  m
CONFIG_ACPI_FAN:  m
CONFIG_ACPI_PROCESSOR:  y
CONFIG_ACPI_SLEEP:  y
CONFIG_ACPI_THERMAL:  y
CONFIG_ACPI_VIDEO:  m
CONFIG_ACT200L_DONGLE:  m
CONFIG_ACTISYS_DONGLE:  m
CONFIG_APM_RTC_IS_GMT:  y
CONFIG_ATALK:  m
CONFIG_AUTOFS_FS:  m
CONFIG_BINFMT_ELF:  y
CONFIG_BINFMT_MISC:  y
CONFIG_BLK_DEV_CMD640:  y
CONFIG_BLK_DEV_FD:  m
CONFIG_BLK_DEV_GENERIC:  y
CONFIG_BLK_DEV_IDE:  y
CONFIG_BLK_DEV_IDECD:  m
CONFIG_BLK_DEV_IDECS:  m
CONFIG_BLK_DEV_IDEDISK:  y
CONFIG_BLK_DEV_IDEDMA:  y
CONFIG_BLK_DEV_IDEDMA_PCI:  y
CONFIG_BLK_DEV_IDEPCI:  y
CONFIG_BLK_DEV_IDESCSI:  m
CONFIG_BLK_DEV_LOOP:  m
CONFIG_BLK_DEV_NBD:  m
CONFIG_BLK_DEV_PIIX:  y
CONFIG_BLK_DEV_RAM:  m
CONFIG_BLK_DEV_RZ1000:  y
CONFIG_BLK_DEV_SD:  m
CONFIG_BLK_DEV_SR:  m
CONFIG_BLK_DEV_TRIRON:  y
CONFIG_BSD_PROCESS_ACCT:  y
CONFIG_BT:  m
CONFIG_BT_BNEP:  m
CONFIG_BT_HCIBCM203X:  m
CONFIG_BT_HCIBFUSB:  m
CONFIG_BT_HCIBPA10X:  m
CONFIG_BT_HCIUART:  m
CONFIG_BT_HCIUSB:  m
CONFIG_BT_HCIVHCI:  m
CONFIG_BT_HIDP:  m
CONFIG_BT_L2CAP:  m
CONFIG_BT_RFCOMM:  m
CONFIG_BT_RFCOMM_TTY:  y
CONFIG_BT_SCO:  m
CONFIG_CARDBUS:  y
CONFIG_CHR_DEV_SG:  m
CONFIG_CODA_FS:  m
CONFIG_CPU_FREQ:  y
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE:  y
CONFIG_CPU_FREQ_GOV_ONDEMAND:  m
CONFIG_CPU_FREQ_GOV_PERFORMANCE:  m
CONFIG_CPU_FREQ_GOV_POWERSAVE:  m
CONFIG_CPU_FREQ_GOV_USERSPACE:  y
CONFIG_CPU_FREQ_TABLE:  y
CONFIG_DONGLE:  m
CONFIG_DRM:  m
CONFIG_DRM_I810:  m
CONFIG_DRM_MGA:  m
CONFIG_DRM_R128:  m
CONFIG_DRM_RADEON:  m
CONFIG_DRM_SIS:  m
CONFIG_DUMMY_CONSOLE:  y
CONFIG_ESI_DONGLE:  m
CONFIG_EXPERIMENTAL:  y
CONFIG_EXT2_FS:  y
CONFIG_EXT3_FS:  y
CONFIG_EXT3_FS_XATTR:  y
CONFIG_FAT_FS:  m
CONFIG_FB:  y
CONFIG_FB_ATY:  m
CONFIG_FB_ATY128:  m
CONFIG_FB_I810:  m
CONFIG_FB_INTEL:  m
CONFIG_FB_MATROX:  m
CONFIG_FB_MODE_HELPER:  y
CONFIG_FB_NVIDIA:  m
CONFIG_FB_RADEON:  m
CONFIG_FB_RIVA:  m
CONFIG_FB_RIVA_I2C:  y
CONFIG_FB_VESA:  y
CONFIG_FILTER:  y
CONFIG_FRAMEBUFFER_CONSOLE:  y
CONFIG_GIRBIL_DONGLE:  m
CONFIG_HFSPLUS_FS:  m
CONFIG_HFS_FS:  m
CONFIG_HOTPLUG:  y
CONFIG_HPET_TIMER:  y
CONFIG_HPFS_FS:  m
CONFIG_IDE:  y
CONFIG_IDEDMA_AUTO:  y
CONFIG_IDEDMA_ONLYDISK:  y
CONFIG_IDEDMA_PCI_AUTO:  y
CONFIG_IDEPCI_SHARE_IRQ:  y
CONFIG_IDE_GENERIC:  y
CONFIG_IEEE1394:  m
CONFIG_IEEE1394_DV1394:  m
CONFIG_IEEE1394_OHCI1394:  m
CONFIG_IEEE1394_RAWIO:  m
CONFIG_IEEE1394_VIDEO1394:  m
CONFIG_INET:  y
CONFIG_INOTIFY:  y
CONFIG_INPUT:  y
CONFIG_INPUT_KEYBDEV:  m
CONFIG_INPUT_KEYBOARD:  y
CONFIG_INPUT_MOUSE:  y
CONFIG_INPUT_MOUSEDEV:  m
CONFIG_IP_ALIAS:  y
CONFIG_IP_ROUTE_VERBOSE:  y
CONFIG_IRCOMM:  m
CONFIG_IRDA:  m
CONFIG_IRDA_CACHE_LAST_LSAP:  y
CONFIG_IRDA_DEBUG:  y
CONFIG_IRDA_FAST_RR:  y
CONFIG_IRLAN:  m
CONFIG_IRPORT_SIR:  m
CONFIG_IRQBALANCE:  y
CONFIG_IRTTY_SIR:  m
CONFIG_ISA:  y
CONFIG_ISO9660_FS:  m
CONFIG_KCORE_ELF:  y
CONFIG_KEYBOARD_ATKBD:  y
CONFIG_LEGACY_PTYS:  y
CONFIG_LITELINK_DONGLE:  m
CONFIG_LOCKD:  m
CONFIG_M386:  n
CONFIG_M486:  n
CONFIG_M586:  n
CONFIG_M686:  n
CONFIG_MA600_DONGLE:  m
CONFIG_MAC_PARTITION:  y
CONFIG_MCP2120_DONGLE:  m
CONFIG_MODULES:  y
CONFIG_MODULE_UNLOAD:  y
CONFIG_MOUSE:  m
CONFIG_MOUSE_PS2:  y
CONFIG_MPENTIUMM:  y
CONFIG_MSDOS_FS:  m
CONFIG_MTRR:  y
CONFIG_NET:  y
CONFIG_NETDEVICES:  y
CONFIG_NET_ETHERNET:  y
CONFIG_NFSD:  m
CONFIG_NFS_FS:  m
CONFIG_NLS:  y
CONFIG_NLS_CODEPAGE_437:  m
CONFIG_NLS_CODEPAGE_850:  m
CONFIG_NLS_ISO8859_1:  m
CONFIG_NLS_UTF8:  m
CONFIG_NOHIGHMEM:  y
CONFIG_NTFS_FS:  m
CONFIG_OLD_BELKIN_DONGLE:  m
CONFIG_OOM_KILLER:  y
CONFIG_PACKET:  y
CONFIG_PARPORT:  m
CONFIG_PARPORT_PC:  m
CONFIG_PCCARD:  y
CONFIG_PCI:  y
CONFIG_PCI_BIOS:  y
CONFIG_PCI_GOANY:  y
CONFIG_PCI_OLD_PROC:  y
CONFIG_PCI_QUIRKS:  y
CONFIG_PCMCIA:  y
CONFIG_PIIX_TUNING:  y
CONFIG_PM:  y
CONFIG_PPP:  m
CONFIG_PPPOE:  m
CONFIG_PPP_ASYNC:  m
CONFIG_PPP_BSDCOMP:  m
CONFIG_PPP_DEFLATE:  m
CONFIG_PPP_FILTER:  y
CONFIG_PPP_SYNC_TTY:  m
CONFIG_PREEMPT:  n
CONFIG_PREEMPT_BKL:  y
CONFIG_PREEMPT_RT:  y
CONFIG_PREEMPT_VOLUNTARY:  n
CONFIG_PRINTER:  m
CONFIG_PRINTER_READBACK:  y
CONFIG_PROC_FS:  y
CONFIG_PSMOUSE:  y
CONFIG_QNX4FS_FS:  m
CONFIG_REGPARM:  y
CONFIG_RTC:  y
CONFIG_SCSI:  m
CONFIG_SCSI_MULTI_LUN:  y
CONFIG_SCSI_PROC_FS:  y
CONFIG_SERIAL:  m
CONFIG_SERIAL_8250:  m
CONFIG_SERIAL_8250_CS:  m
CONFIG_SHAPER:  m
CONFIG_SLIP:  m
CONFIG_SMB_FS:  m
CONFIG_SMC_IRCC_FIR:  m
CONFIG_SND:  m
CONFIG_SND_HDA_INTEL:  m
CONFIG_SND_INTEL8X0:  m
CONFIG_SND_INTEL8X0M:  m
CONFIG_SND_MIXER_OSS:  m
CONFIG_SND_PCM_OSS:  m
CONFIG_SND_RTCTIMER:  m
CONFIG_SND_SEQUENCER:  m
CONFIG_SND_SEQUENCER_OSS:  y
CONFIG_SND_SEQ_DUMMY:  m
CONFIG_SND_USB_AUDIO:  m
CONFIG_SOUND:  m
CONFIG_SOUND_ICH:  m
CONFIG_SUNRPC:  m
CONFIG_SYSCTL:  y
CONFIG_SYSVIPC:  y
CONFIG_TEKRAM_DONGLE:  m
CONFIG_TIGON3:  y
CONFIG_UFS_FS:  m
CONFIG_UMSDOS_FS:  m
CONFIG_UNIX:  y
CONFIG_USB:  m
CONFIG_USB_ACM:  m
CONFIG_USB_AUDIO:  m
CONFIG_USB_CDCETHER:  m
CONFIG_USB_DEVICEFS:  y
CONFIG_USB_EHCI_HCD:  m
CONFIG_USB_HID:  y
CONFIG_USB_HIDINPUT:  y
CONFIG_USB_KBD:  m
CONFIG_USB_MOUSE:  m
CONFIG_USB_OHCI:  m
CONFIG_USB_OHCI_HCD:  m
CONFIG_USB_PRINTER:  m
CONFIG_USB_SERIAL:  m
CONFIG_USB_SERIAL_FTDI_SIO:  m
CONFIG_USB_SERIAL_GENERIC:  y
CONFIG_USB_STORAGE:  m
CONFIG_USB_UHCI:  m
CONFIG_USB_UHCI_ALT:  m
CONFIG_USB_UHCI_HCD:  m
CONFIG_VFAT_FS:  m
CONFIG_VGA_CONSOLE:  y
CONFIG_VIDEO_SELECT:  y
CONFIG_VT:  y
CONFIG_VT_CONSOLE:  y
CONFIG_X86_MCE:  y
CONFIG_X86_SPEEDSTEP_CENTRINO:  y
CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI:  y
CONFIG_X86_UP_APIC:  y
CONFIG_X86_UP_IOAPIC:  y
CONFIG_YENTA:  y
CONGIG_KMOD:  y

PCI devices:
8086 	Intel Corporation 	3340 	82855PM 	0 		Host-Hub Interface Bridge
8086 	Intel Corporation 	3341 	82855PM 	0 		AGP Bridge
8086 	Intel Corporation 	24C2 	82801DB/DBL/DBM 	B 		USB UHCI Controller #1
8086 	Intel Corporation 	24C4 	82801DB/DBL/DBM 	B 		USB UHCI Controller #2
8086 	Intel Corporation 	24C7 	82801DB/DBL/DBM 	B 		USB UHCI Controller #3
8086 	Intel Corporation 	24CD 	82801DB/DBL/DBM 	B 		USB EHCI Controller
8086 	Intel Corporation 	2448 	82801BAM/CAM/DBM 	0 		Hub Interface to PCI Bridge
8086 	Intel Corporation 	24CC 	82801DBM 	0 		LPC Interface Bridge
8086 	Intel Corporation 	24CA 	82801DBM 	B 		IDE Controller (UltraATA/100)
8086 	Intel Corporation 	24C5 	82801DB 	7 		AC97 Audio Controller
8086 	Intel Corporation 	24C6 	82801DB/DBM 	B 		AC97 Modem Controller
10DE 	NVIDIA Corporation 	0324 	NV31 	B 		nVidia GeForce FX Go 5200, 64MB
14E4 	Broadcom Corporation 	165D 	BCM5705M 	B 		Broadcom NetXtreme Gigabit Ethernet
104C 	Texas Instruments 	AC47 	7510/4510 	B 		Cardbus
104C 	Texas Instruments 	AC4A 		B 		
104C 	Texas Instruments 	802B 		B 		
104C 	Texas Instruments 	8204 	4610, 4515, 4610FM 	0 		TI UltraMedia Firmware Loader Device
8086 	Intel Corporation 	4220 	MPCI3B 	B 		Intel 2200 mPCI 3B - RoW

No proprietary drivers in the system: I'm using XFree 4.3 driver for Nvidia.

Re: 2.6.13-rt1

[Daniel Walker]

On Mon, 2005-08-29 at 10:48 +0200, Ingo Molnar wrote:

> 
>  - x86_64 boot fix (Daniel Walker)

Ingo, Did this work for you?

Daniel

Re: 2.6.13-rt1

[Ingo Molnar]

* Daniel Walker <dwalker@mvista.com> wrote:

> On Mon, 2005-08-29 at 10:48 +0200, Ingo Molnar wrote:
> 
> > 
> >  - x86_64 boot fix (Daniel Walker)
> 
> Ingo, Did this work for you?

nope, it's a UP box.

	Ingo

Re: 2.6.13-rt1

[Daniel Walker]

On Mon, 2005-08-29 at 17:18 +0200, Ingo Molnar wrote:
> * Daniel Walker <dwalker@mvista.com> wrote:
> 
> > On Mon, 2005-08-29 at 10:48 +0200, Ingo Molnar wrote:
> > 
> > > 
> > >  - x86_64 boot fix (Daniel Walker)
> > 
> > Ingo, Did this work for you?
> 
> nope, it's a UP box.


Does it hang early during like ACPI , or after init ?

Daniel

Re: 2.6.13-rt1

[Bill Davidsen]

Hubert Tonneau wrote:
> I gave this one a spin, and my laptop locked hard after something like one hour
> (everything frozen). As a result what I report is probably not very helpfull.
> 
> It was the first time I was trying an RT kernel, and the stock kernel works ok
> on this laptop (except suspend, but one can do without it).
> 
Funny, suspend works on all my laptops and most of my desktops, I was 
hoping that someone might get resume working next. :-(

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: 2.6.13-rt1

[Steven Rostedt]

Ingo,

I just found another deadlock in the pi_lock logic.  The PI logic is
very dependent on the P1->L1->P2->L2->P3 order.  But our good old friend
is back, the BKL.

Since the BKL is let go and regrabbed even if a task is grabbing another
lock, it messes up the order.  For example, it can do the following:
L1->P1->L2->P2->L1 if L1 is the BKL.  Luckly, (and I guess there's
really no other way) the BKL is only held by those that are currently
running, or at least not blocked on anyone.  So I added code in the
pi_setprio code to test if the next lock in the loop is the BKL and if
so, if its owner is the current task.  If so, the loop is broken.

Without this patch, I would constantly get lock ups on shutdown where it
sends SIGTERM to all the processes.  It usually would lock up on the
killing of udev.  But with the patch, I've shutdown a few times already
and no lockups so far.

-- Steve

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

Index: linux_realtime_goliath/kernel/rt.c
===================================================================
--- linux_realtime_goliath/kernel/rt.c	(revision 308)
+++ linux_realtime_goliath/kernel/rt.c	(working copy)
@@ -816,6 +816,21 @@
 		l = w->lock;
 		TRACE_BUG_ON_LOCKED(!lock);
 
+		/*
+		 * The BKL can really be a pain.  It can happen that the lock
+		 * we are blocked on is owned by a task that is waiting for
+		 * the BKL, and we own it.  So, if this is the BKL and we own
+		 * it, then end the loop here.
+		 */
+		if (unlikely(l == &kernel_sem.lock) && lock_owner(l) == current_thread_info()) {
+			/*
+			 * No locks are held for locks, so fool the unlocking code
+			 * by thinking the last lock was the original.
+			 */
+			l = lock;
+			break;
+		}
+
 		if (l != lock)
 			__raw_spin_lock(&l->wait_lock);
 

Re: 2.6.13-rt1

[Ingo Molnar]

* Steven Rostedt <rostedt@goodmis.org> wrote:

> Ingo,
> 
> I just found another deadlock in the pi_lock logic.  The PI logic is 
> very dependent on the P1->L1->P2->L2->P3 order.  But our good old 
> friend is back, the BKL.
> 
> Since the BKL is let go and regrabbed even if a task is grabbing 
> another lock, it messes up the order.  For example, it can do the 
> following: L1->P1->L2->P2->L1 if L1 is the BKL.  Luckly, (and I guess 
> there's really no other way) the BKL is only held by those that are 
> currently running, or at least not blocked on anyone.  So I added code 
> in the pi_setprio code to test if the next lock in the loop is the BKL 
> and if so, if its owner is the current task.  If so, the loop is 
> broken.
> 
> Without this patch, I would constantly get lock ups on shutdown where 
> it sends SIGTERM to all the processes.  It usually would lock up on 
> the killing of udev.  But with the patch, I've shutdown a few times 
> already and no lockups so far.

thanks, applied.

	Ingo

Re: 2.6.13-rt1

[Steven Rostedt]

Hi Ingo,

Looks like the BKL is a little more complicated than what I first sent.
I've been analyzing the logic and found that there's a point in time
where the BKL->P1->L1->P2->BKL can exist without any of the spinlocks
protecting it.  That is after P1 blocks on L1 but before it schedules
out and releases the BKL.  In this time another process on another CPU
could loop here.

The supplied patch fixes this.

Also, I need to look more into the logic of __up to see if the BKL can't
cause a deadlock with the grabbing and releasing of locks there.  So I
might be sending more patches to clean this up.

Do me a favor, and just take a quick look at the logic here, and make
sure that the situation is OK to break there, and that there won't be
any other side-effects, wrt. priority leaks.

Thanks,

-- Steve

Patch is against rt2

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

Index: linux_realtime_goliath/kernel/rt.c
===================================================================
--- linux_realtime_goliath/kernel/rt.c	(revision 310)
+++ linux_realtime_goliath/kernel/rt.c	(working copy)
@@ -760,11 +760,12 @@
  */
 static void pi_setprio(struct rt_mutex *lock, struct task_struct *task, int prio)
 {
-	struct rt_mutex *l = lock;
-	struct task_struct *p = task;
 	/*
 	 * We don't want to release the parameters locks.
 	 */
+	struct rt_mutex *l = lock;
+	struct task_struct *p = task;
+	int bkl = 0;
 
 	if (unlikely(!p->pid)) {
 		pi_null++;
@@ -800,7 +801,7 @@
 #endif
 
 		mutex_setprio(p, prio);
-		if (!w)
+		if (!w || unlikely(bkl))
 			break;
 		/*
 		 * If the task is blocked on a lock, and we just made
@@ -817,18 +818,31 @@
 		TRACE_BUG_ON_LOCKED(!lock);
 
 		/*
-		 * The BKL can really be a pain.  It can happen that the lock
-		 * we are blocked on is owned by a task that is waiting for
-		 * the BKL, and we own it.  So, if this is the BKL and we own
-		 * it, then end the loop here.
+		 * The BKL can really be a pain. It can happen where the
+		 * BKL is being held by one task that is just about to 
+		 * block on another task that is waiting for the BKL.
+		 * This isn't a deadlock, since the BKL is released
+		 * when the task goes to sleep.  This also means that
+		 * all holders of the BKL are not blocked, or are just
+		 * about to be blocked.
+		 *
+		 * Another side-effect of this is that there's a small
+		 * window where the spinlocks are not held, and the blocked
+		 * process hasn't released the BKL.  So if we are going
+		 * to boost the owner of the BKL, stop after that,
+		 * since that owner is either running, or about to sleep
+		 * but don't go any further or we are in a loop.
 		 */
-		if (unlikely(l == &kernel_sem.lock) && lock_owner(l) == current_thread_info()) {
-			/*
-			 * No locks are held for locks, so fool the unlocking code
-			 * by thinking the last lock was the original.
-			 */
-			l = lock;
-			break;
+		if (unlikely(l == &kernel_sem.lock)) {
+			if (lock_owner(l) == current_thread_info()) {
+				/*
+				 * No locks are held for locks, so fool the unlocking code
+				 * by thinking the last lock was the original.
+				 */
+				l = lock;
+				break;
+			}
+			bkl = 1;
 		}
 
 		if (l != lock)

Re: 2.6.13-rt1

[Daniel Walker]

Have you tried turning on 
"Non-preemptible critical section latency timing" or "Latency tracing"

I don't know if it's related to the PI changes, but I'm getting a crash
with those on em64t .

With both above options I get

<0>init[1]: segfault at ffffffff8010ef44 rip ffffffff8010ef44 rsp 00007fffferror 5
<0>init[1]: segfault at ffffffff8010ef44 rip ffffffff8010ef44 rsp 00007ffffffe8de8 error 5

printed never ending right after init starts.

If I only turn on "Non-preemptible critical section latency timing",
then when I enter the command,
"echo 0 > /proc/sys/kernel/preempt_max_latency"

The kernel will spit out a couple of max critical section updates , then
it will hang silently.

This is all new in 2.6.13-rtX . It could have just come in with 2.6.13 ,
but I thought I'd mention it.

Daniel

On Tue, 2005-08-30 at 09:06 -0400, Steven Rostedt wrote:
> Hi Ingo,
> 
> Looks like the BKL is a little more complicated than what I first sent.
> I've been analyzing the logic and found that there's a point in time
> where the BKL->P1->L1->P2->BKL can exist without any of the spinlocks
> protecting it.  That is after P1 blocks on L1 but before it schedules
> out and releases the BKL.  In this time another process on another CPU
> could loop here.
> 
> The supplied patch fixes this.
> 
> Also, I need to look more into the logic of __up to see if the BKL can't
> cause a deadlock with the grabbing and releasing of locks there.  So I
> might be sending more patches to clean this up.
> 
> Do me a favor, and just take a quick look at the logic here, and make
> sure that the situation is OK to break there, and that there won't be
> any other side-effects, wrt. priority leaks.
> 
> Thanks,
> 
> -- Steve
> 
> Patch is against rt2
> 
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> 
> Index: linux_realtime_goliath/kernel/rt.c
> ===================================================================
> --- linux_realtime_goliath/kernel/rt.c	(revision 310)
> +++ linux_realtime_goliath/kernel/rt.c	(working copy)
> @@ -760,11 +760,12 @@
>   */
>  static void pi_setprio(struct rt_mutex *lock, struct task_struct *task, int prio)
>  {
> -	struct rt_mutex *l = lock;
> -	struct task_struct *p = task;
>  	/*
>  	 * We don't want to release the parameters locks.
>  	 */
> +	struct rt_mutex *l = lock;
> +	struct task_struct *p = task;
> +	int bkl = 0;
>  
>  	if (unlikely(!p->pid)) {
>  		pi_null++;
> @@ -800,7 +801,7 @@
>  #endif
>  
>  		mutex_setprio(p, prio);
> -		if (!w)
> +		if (!w || unlikely(bkl))
>  			break;
>  		/*
>  		 * If the task is blocked on a lock, and we just made
> @@ -817,18 +818,31 @@
>  		TRACE_BUG_ON_LOCKED(!lock);
>  
>  		/*
> -		 * The BKL can really be a pain.  It can happen that the lock
> -		 * we are blocked on is owned by a task that is waiting for
> -		 * the BKL, and we own it.  So, if this is the BKL and we own
> -		 * it, then end the loop here.
> +		 * The BKL can really be a pain. It can happen where the
> +		 * BKL is being held by one task that is just about to 
> +		 * block on another task that is waiting for the BKL.
> +		 * This isn't a deadlock, since the BKL is released
> +		 * when the task goes to sleep.  This also means that
> +		 * all holders of the BKL are not blocked, or are just
> +		 * about to be blocked.
> +		 *
> +		 * Another side-effect of this is that there's a small
> +		 * window where the spinlocks are not held, and the blocked
> +		 * process hasn't released the BKL.  So if we are going
> +		 * to boost the owner of the BKL, stop after that,
> +		 * since that owner is either running, or about to sleep
> +		 * but don't go any further or we are in a loop.
>  		 */
> -		if (unlikely(l == &kernel_sem.lock) && lock_owner(l) == current_thread_info()) {
> -			/*
> -			 * No locks are held for locks, so fool the unlocking code
> -			 * by thinking the last lock was the original.
> -			 */
> -			l = lock;
> -			break;
> +		if (unlikely(l == &kernel_sem.lock)) {
> +			if (lock_owner(l) == current_thread_info()) {
> +				/*
> +				 * No locks are held for locks, so fool the unlocking code
> +				 * by thinking the last lock was the original.
> +				 */
> +				l = lock;
> +				break;
> +			}
> +			bkl = 1;
>  		}
>  
>  		if (l != lock)
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.13-rt1

[Steven Rostedt]

On Tue, 2005-08-30 at 15:34 -0700, Daniel Walker wrote:
> Have you tried turning on 
> "Non-preemptible critical section latency timing" or "Latency tracing"

I just turned on the following:

  CONFIG_CRITICAL_PREEMPT_TIMING
  CONFIG_CRITICAL_IRQSOFF_TIMING
  CONFIG_LATENCY_TRACE

recompiled and booted.  No problem here.

> 
> I don't know if it's related to the PI changes, but I'm getting a crash
> with those on em64t .
> 
> With both above options I get
> 
> <0>init[1]: segfault at ffffffff8010ef44 rip ffffffff8010ef44 rsp 00007fffferror 5
> <0>init[1]: segfault at ffffffff8010ef44 rip ffffffff8010ef44 rsp 00007ffffffe8de8 error 5
> 
> printed never ending right after init starts.
> 
> If I only turn on "Non-preemptible critical section latency timing",
> then when I enter the command,
> "echo 0 > /proc/sys/kernel/preempt_max_latency"
> 
> The kernel will spit out a couple of max critical section updates , then
> it will hang silently.
> 
> This is all new in 2.6.13-rtX . It could have just come in with 2.6.13 ,
> but I thought I'd mention it.

Did you try the latest patches I just sent. Mainly this last one on
-rt2?  There is a deadlock that is fixed wrt the BKL.

-- Steve