Re: [ANNOUNCE] 3.18.9-rt4
On Sat, Mar 7, 2015 at 11:15 AM, Sebastian Andrzej Siewior wrote: > > I'm pleased to announce the v3.18.9-rt4 patch set. > > Changes since v3.18.9-rt3 > Has v3.18.9-rt3 been released? If so, I missed the announcement. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ANNOUNCE] 3.18.9-rt4
On Sat, Mar 7, 2015 at 11:15 AM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: I'm pleased to announce the v3.18.9-rt4 patch set. Changes since v3.18.9-rt3 Has v3.18.9-rt3 been released? If so, I missed the announcement. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: [ANNOUNCE] 3.18.7-rt2
On Thu, Feb 26, 2015 at 5:02 AM, Mike Galbraith wrote: > On Tue, 2015-02-24 at 13:19 -0300, Gustavo Bittencourt wrote: > >> The deadlock returned after I applied this patch in v3.18.7-rt2. > > Grr, because dummy here munged a reject when he backported to 3.18-rt. > Please try the below, my trusty old Q6600 box is now running with > nouveau/drm in both 3.18-rt and 4.0-rt. > > I found what was breaking my core2 lappy in 4.0-rt as well, namely the > rtmutex.c set_current_state() munging that went into mainline recently, > and that also broke my Q6600 box with nouveau/drm as well! Seems you > need a slow box and drm to experience the breakage nice and repeatably, > which is kinda worrisome. Anyway, all of my boxen can use drm just fine > in both rt trees now, so your box _should_ be happy too. > Mike, my box is running very well now. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ANNOUNCE] 3.18.7-rt2
On Thu, Feb 26, 2015 at 5:02 AM, Mike Galbraith umgwanakikb...@gmail.com wrote: On Tue, 2015-02-24 at 13:19 -0300, Gustavo Bittencourt wrote: The deadlock returned after I applied this patch in v3.18.7-rt2. Grr, because dummy here munged a reject when he backported to 3.18-rt. Please try the below, my trusty old Q6600 box is now running with nouveau/drm in both 3.18-rt and 4.0-rt. I found what was breaking my core2 lappy in 4.0-rt as well, namely the rtmutex.c set_current_state() munging that went into mainline recently, and that also broke my Q6600 box with nouveau/drm as well! Seems you need a slow box and drm to experience the breakage nice and repeatably, which is kinda worrisome. Anyway, all of my boxen can use drm just fine in both rt trees now, so your box _should_ be happy too. Mike, my box is running very well now. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: [ANNOUNCE] 3.18.7-rt2
On Tue, Feb 24, 2015 at 2:50 PM, Mike Galbraith wrote: > On Tue, 2015-02-24 at 13:19 -0300, Gustavo Bittencourt wrote: >> >> The deadlock returned after I applied this patch in v3.18.7-rt2. Here is my >> log: > > > Hrmph. I definitely want your patch to die ;-) It adds a whole new > dimension to ww_mutex that only now exists in -rt. That's not good. No problem. > My > patchlet may not be perfect either, but it lets ww_mutex do that return > EALREADY business it's supposed to, vs going straight to while(1). We > can't have it both ways, so I suppose I'll fire up my old Q6600 box > (that doesn't have annoying GTX980 that my userspace can't deal with DRM > wise), and see if I can chase the nouveau thing down. I'm not all that > enthusiastic though, as there are or at least were other issues with > nouveau. Sebastian reported some completely _missing_ locking IIRC, > that led to his box exploding. Is there anyway that I could help? I think I can write a code to reproduce the deadlock without the nouveau driver. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ANNOUNCE] 3.18.7-rt2
On Tue, Feb 24, 2015 at 10:41 AM, Mike Galbraith wrote: > locking, ww_mutex: fix ww_mutex vs self-deadlock > > If the caller already holds the mutex, task_blocks_on_rt_mutex() > returns -EDEADLK, we proceed directly to rt_mutex_handle_deadlock() > where it's instant game over. > > Let ww_mutexes return EDEADLK/EALREADY as they want to instead. > > Signed-off-by: Mike Galbraith > --- > kernel/locking/rtmutex.c | 17 +++-- > 1 file changed, 11 insertions(+), 6 deletions(-) > > --- a/kernel/locking/rtmutex.c > +++ b/kernel/locking/rtmutex.c The deadlock returned after I applied this patch in v3.18.7-rt2. Here is my log: [ 244.476210] BUG: scheduling while atomic: Xorg/1549/0x0002 [ 244.476258] Modules linked in: ctr ccm nouveau arc4 ath9k ath9k_common ath9k_hw ath mac80211 uvcvideo snd_hda_codec_hdmi videobuf2_vmalloc snd_hda_codec_realtek videobuf2_memops videobuf2_core snd_hda_codec_generic v4l2_common snd_hda_intel videodev mxm_wmi wmi i2c_algo_bit drm_kms_helper snd_hda_controller snd_hda_codec ttm drm snd_pcm snd_hwdep snd_seq_midi snd_seq_midi_event snd_rawmidi intel_rapl snd_seq bnep x86_pkg_temp_thermal cfg80211 intel_powerclamp snd_timer mei_me snd_seq_device rfcomm snd btusb mei joydev soundcore bluetooth serio_raw mac_hid coretemp lpc_ich sony_laptop crc32_pclmul video parport_pc ppdev lp parport firewire_ohci psmouse ahci sdhci_pci firewire_core r8169 libahci sdhci mii crc_itu_t [ 244.476261] Preemption disabled at:[] rt_mutex_slowlock+0x3b/0x200 [ 244.476262] [ 244.476263] CPU: 2 PID: 1549 Comm: Xorg Tainted: GW 3.18.7-rt2-2-g8c033b9 #3 [ 244.476264] Hardware name: Sony Corporation VPCF215FB/VAIO, BIOS R0200V3 02/10/2011 [ 244.476271] f1a5fc5c c1681e38 f1968f20 f1a5fc74 c167eacf c18f581c [ 244.476278] c1685f5b c1685f5b 0002 f1a5fcf8 c1684a3e f1a5fcfc c187136c 001d [ 244.476287] c1adabc0 c1adabc0 f168fc00 0038 f1968f20 f7774bc0 f1968f20 [ 244.476288] Call Trace: [ 244.476291] [] dump_stack+0x4b/0x88 [ 244.476294] [] __schedule_bug+0x9e/0xac [ 244.476297] [] ? rt_mutex_slowlock+0x3b/0x200 [ 244.476300] [] ? rt_mutex_slowlock+0x3b/0x200 [ 244.476303] [] __schedule+0x6ce/0x7a0 [ 244.476306] [] ? print_oops_end_marker+0x3b/0x40 [ 244.476308] [] ? warn_slowpath_common+0x8f/0xa0 [ 244.476311] [] ? rt_mutex_handle_deadlock.isra.21.part.22+0x2f/0x48 [ 244.476313] [] ? rt_mutex_handle_deadlock.isra.21.part.22+0x2f/0x48 [ 244.476315] [] schedule+0x2b/0x90 [ 244.476318] [] rt_mutex_handle_deadlock.isra.21.part.22+0x46/0x48 [ 244.476320] [] rt_mutex_slowlock+0x1ed/0x200 [ 244.476322] [] ? get_parent_ip+0xb/0x40 [ 244.476325] [] __ww_mutex_lock_interruptible+0x22/0x30 [ 244.476343] [] nouveau_gem_ioctl_pushbuf+0x68b/0x13c0 [nouveau] [ 244.476345] [] ? debug_smp_processor_id+0x12/0x20 [ 244.476348] [] ? unpin_current_cpu+0x13/0x60 [ 244.476365] [] ? nouveau_gem_ioctl_new+0x1d0/0x1d0 [nouveau] [ 244.476373] [] drm_ioctl+0x1b7/0x510 [drm] [ 244.476390] [] ? nouveau_gem_ioctl_new+0x1d0/0x1d0 [nouveau] [ 244.476393] [] ? debug_smp_processor_id+0x12/0x20 [ 244.476395] [] ? unpin_current_cpu+0x13/0x60 [ 244.476397] [] ? migrate_enable+0xa0/0x1c0 [ 244.476400] [] ? __pm_runtime_resume+0x41/0x50 [ 244.476417] [] nouveau_drm_ioctl+0x47/0xb0 [nouveau] [ 244.476434] [] ? nouveau_pmops_thaw+0x20/0x20 [nouveau] [ 244.476436] [] do_vfs_ioctl+0x2f2/0x4f0 [ 244.476438] [] ? ktime_get_ts64+0x52/0x1a0 [ 244.476441] [] ? __remove_hrtimer+0xd0/0xd0 [ 244.476443] [] SyS_ioctl+0x60/0x90 [ 244.476446] [] sysenter_do_call+0x12/0x12 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ANNOUNCE] 3.18.7-rt2
On Tue, Feb 24, 2015 at 2:50 PM, Mike Galbraith umgwanakikb...@gmail.com wrote: On Tue, 2015-02-24 at 13:19 -0300, Gustavo Bittencourt wrote: The deadlock returned after I applied this patch in v3.18.7-rt2. Here is my log: Hrmph. I definitely want your patch to die ;-) It adds a whole new dimension to ww_mutex that only now exists in -rt. That's not good. No problem. My patchlet may not be perfect either, but it lets ww_mutex do that return EALREADY business it's supposed to, vs going straight to while(1). We can't have it both ways, so I suppose I'll fire up my old Q6600 box (that doesn't have annoying GTX980 that my userspace can't deal with DRM wise), and see if I can chase the nouveau thing down. I'm not all that enthusiastic though, as there are or at least were other issues with nouveau. Sebastian reported some completely _missing_ locking IIRC, that led to his box exploding. Is there anyway that I could help? I think I can write a code to reproduce the deadlock without the nouveau driver. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: [ANNOUNCE] 3.18.7-rt2
On Tue, Feb 24, 2015 at 10:41 AM, Mike Galbraith umgwanakikb...@gmail.com wrote: locking, ww_mutex: fix ww_mutex vs self-deadlock If the caller already holds the mutex, task_blocks_on_rt_mutex() returns -EDEADLK, we proceed directly to rt_mutex_handle_deadlock() where it's instant game over. Let ww_mutexes return EDEADLK/EALREADY as they want to instead. Signed-off-by: Mike Galbraith umgwanakikb...@gmail.com --- kernel/locking/rtmutex.c | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-) --- a/kernel/locking/rtmutex.c +++ b/kernel/locking/rtmutex.c The deadlock returned after I applied this patch in v3.18.7-rt2. Here is my log: [ 244.476210] BUG: scheduling while atomic: Xorg/1549/0x0002 [ 244.476258] Modules linked in: ctr ccm nouveau arc4 ath9k ath9k_common ath9k_hw ath mac80211 uvcvideo snd_hda_codec_hdmi videobuf2_vmalloc snd_hda_codec_realtek videobuf2_memops videobuf2_core snd_hda_codec_generic v4l2_common snd_hda_intel videodev mxm_wmi wmi i2c_algo_bit drm_kms_helper snd_hda_controller snd_hda_codec ttm drm snd_pcm snd_hwdep snd_seq_midi snd_seq_midi_event snd_rawmidi intel_rapl snd_seq bnep x86_pkg_temp_thermal cfg80211 intel_powerclamp snd_timer mei_me snd_seq_device rfcomm snd btusb mei joydev soundcore bluetooth serio_raw mac_hid coretemp lpc_ich sony_laptop crc32_pclmul video parport_pc ppdev lp parport firewire_ohci psmouse ahci sdhci_pci firewire_core r8169 libahci sdhci mii crc_itu_t [ 244.476261] Preemption disabled at:[c1685f5b] rt_mutex_slowlock+0x3b/0x200 [ 244.476262] [ 244.476263] CPU: 2 PID: 1549 Comm: Xorg Tainted: GW 3.18.7-rt2-2-g8c033b9 #3 [ 244.476264] Hardware name: Sony Corporation VPCF215FB/VAIO, BIOS R0200V3 02/10/2011 [ 244.476271] f1a5fc5c c1681e38 f1968f20 f1a5fc74 c167eacf c18f581c [ 244.476278] c1685f5b c1685f5b 0002 f1a5fcf8 c1684a3e f1a5fcfc c187136c 001d [ 244.476287] c1adabc0 c1adabc0 f168fc00 0038 f1968f20 f7774bc0 f1968f20 [ 244.476288] Call Trace: [ 244.476291] [c1681e38] dump_stack+0x4b/0x88 [ 244.476294] [c167eacf] __schedule_bug+0x9e/0xac [ 244.476297] [c1685f5b] ? rt_mutex_slowlock+0x3b/0x200 [ 244.476300] [c1685f5b] ? rt_mutex_slowlock+0x3b/0x200 [ 244.476303] [c1684a3e] __schedule+0x6ce/0x7a0 [ 244.476306] [c105fb6b] ? print_oops_end_marker+0x3b/0x40 [ 244.476308] [c105fbff] ? warn_slowpath_common+0x8f/0xa0 [ 244.476311] [c167ec42] ? rt_mutex_handle_deadlock.isra.21.part.22+0x2f/0x48 [ 244.476313] [c167ec42] ? rt_mutex_handle_deadlock.isra.21.part.22+0x2f/0x48 [ 244.476315] [c1684b3b] schedule+0x2b/0x90 [ 244.476318] [c167ec59] rt_mutex_handle_deadlock.isra.21.part.22+0x46/0x48 [ 244.476320] [c168610d] rt_mutex_slowlock+0x1ed/0x200 [ 244.476322] [c10848eb] ? get_parent_ip+0xb/0x40 [ 244.476325] [c1686142] __ww_mutex_lock_interruptible+0x22/0x30 [ 244.476343] [f8ddb7fb] nouveau_gem_ioctl_pushbuf+0x68b/0x13c0 [nouveau] [ 244.476345] [c132d022] ? debug_smp_processor_id+0x12/0x20 [ 244.476348] [c1060283] ? unpin_current_cpu+0x13/0x60 [ 244.476365] [f8ddb170] ? nouveau_gem_ioctl_new+0x1d0/0x1d0 [nouveau] [ 244.476373] [f891d137] drm_ioctl+0x1b7/0x510 [drm] [ 244.476390] [f8ddb170] ? nouveau_gem_ioctl_new+0x1d0/0x1d0 [nouveau] [ 244.476393] [c132d022] ? debug_smp_processor_id+0x12/0x20 [ 244.476395] [c1060283] ? unpin_current_cpu+0x13/0x60 [ 244.476397] [c1084e40] ? migrate_enable+0xa0/0x1c0 [ 244.476400] [c143f6b1] ? __pm_runtime_resume+0x41/0x50 [ 244.476417] [f8dd2707] nouveau_drm_ioctl+0x47/0xb0 [nouveau] [ 244.476434] [f8dd26c0] ? nouveau_pmops_thaw+0x20/0x20 [nouveau] [ 244.476436] [c11a9e82] do_vfs_ioctl+0x2f2/0x4f0 [ 244.476438] [c10c5132] ? ktime_get_ts64+0x52/0x1a0 [ 244.476441] [c10be330] ? __remove_hrtimer+0xd0/0xd0 [ 244.476443] [c11aa0e0] SyS_ioctl+0x60/0x90 [ 244.476446] [c1687d70] sysenter_do_call+0x12/0x12 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -rt] rtmutex: enable deadlock detection in ww_mutex_lock functions
According the ww-mutex-design.txt documentation, the ww_mutex_lock_interruptible and ww_mutex_lock functions should return -EDEADLK when faced with a deadlock. To do so, the detect_deadlock flag in the rt_mutex_slowlock calls should be enabled. This patch corrects potential deadlocks when running PREEMPT_RT with nouveau driver. PS: Sorry to post again, CC'ing -rt maintainers now. Signed-off-by: Gustavo Bittencourt --- kernel/locking/rtmutex.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c index 6c40660..3f6ef91 100644 --- a/kernel/locking/rtmutex.c +++ b/kernel/locking/rtmutex.c @@ -1965,7 +1965,7 @@ __ww_mutex_lock_interruptible(struct ww_mutex *lock, struct ww_acquire_ctx *ww_c might_sleep(); mutex_acquire(>base.dep_map, 0, 0, _RET_IP_); - ret = rt_mutex_slowlock(>base.lock, TASK_INTERRUPTIBLE, NULL, 0, ww_ctx); + ret = rt_mutex_slowlock(>base.lock, TASK_INTERRUPTIBLE, NULL, 1, ww_ctx); if (ret) mutex_release(>base.dep_map, 1, _RET_IP_); else if (!ret && ww_ctx->acquired > 1) @@ -1984,7 +1984,7 @@ __ww_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx *ww_ctx) mutex_acquire_nest(>base.dep_map, 0, 0, _ctx->dep_map, _RET_IP_); - ret = rt_mutex_slowlock(>base.lock, TASK_UNINTERRUPTIBLE, NULL, 0, ww_ctx); + ret = rt_mutex_slowlock(>base.lock, TASK_UNINTERRUPTIBLE, NULL, 1, ww_ctx); if (ret) mutex_release(>base.dep_map, 1, _RET_IP_); else if (!ret && ww_ctx->acquired > 1) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -rt] rtmutex: enable deadlock detection in ww_mutex_lock functions
According the ww-mutex-design.txt documentation, the ww_mutex_lock_interruptible and ww_mutex_lock functions should return -EDEADLK when faced with a deadlock. To do so, the detect_deadlock flag in the rt_mutex_slowlock calls should be enabled. This patch corrects potential deadlocks when running PREEMPT_RT with nouveau driver. PS: Sorry to post again, CC'ing -rt maintainers now. Signed-off-by: Gustavo Bittencourt gbit...@gmail.com --- kernel/locking/rtmutex.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c index 6c40660..3f6ef91 100644 --- a/kernel/locking/rtmutex.c +++ b/kernel/locking/rtmutex.c @@ -1965,7 +1965,7 @@ __ww_mutex_lock_interruptible(struct ww_mutex *lock, struct ww_acquire_ctx *ww_c might_sleep(); mutex_acquire(lock-base.dep_map, 0, 0, _RET_IP_); - ret = rt_mutex_slowlock(lock-base.lock, TASK_INTERRUPTIBLE, NULL, 0, ww_ctx); + ret = rt_mutex_slowlock(lock-base.lock, TASK_INTERRUPTIBLE, NULL, 1, ww_ctx); if (ret) mutex_release(lock-base.dep_map, 1, _RET_IP_); else if (!ret ww_ctx-acquired 1) @@ -1984,7 +1984,7 @@ __ww_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx *ww_ctx) mutex_acquire_nest(lock-base.dep_map, 0, 0, ww_ctx-dep_map, _RET_IP_); - ret = rt_mutex_slowlock(lock-base.lock, TASK_UNINTERRUPTIBLE, NULL, 0, ww_ctx); + ret = rt_mutex_slowlock(lock-base.lock, TASK_UNINTERRUPTIBLE, NULL, 1, ww_ctx); if (ret) mutex_release(lock-base.dep_map, 1, _RET_IP_); else if (!ret ww_ctx-acquired 1) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -rt] rtmutex: enable deadlock detection in the ww_mutex_lock functions
According the ww-mutex-design.txt documentation, the ww_mutex_lock_interruptible and ww_mutex_lock functions should return -EDEADLK when faced with a deadlock. To do so, the flag detect_deadlock in the rt_mutex_slowlock calls should be enabled. This patch corrects potential deadlocks when running PREEMPT_RT with nouveau driver. Kernel v3.14-rt Signed-off-by: Gustavo Bittencourt --- kernel/locking/rtmutex.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c index 6c40660..3f6ef91 100644 --- a/kernel/locking/rtmutex.c +++ b/kernel/locking/rtmutex.c @@ -1965,7 +1965,7 @@ __ww_mutex_lock_interruptible(struct ww_mutex *lock, struct ww_acquire_ctx *ww_c might_sleep(); mutex_acquire(>base.dep_map, 0, 0,_RET_IP_); - ret = rt_mutex_slowlock(>base.lock, TASK_INTERRUPTIBLE, NULL, 0, ww_ctx); + ret = rt_mutex_slowlock(>base.lock, TASK_INTERRUPTIBLE, NULL, 1, ww_ctx); if (ret) mutex_release(>base.dep_map, 1,_RET_IP_); else if (!ret && ww_ctx->acquired > 1) @@ -1984,7 +1984,7 @@ __ww_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx *ww_ctx) mutex_acquire_nest(>base.dep_map, 0, 0, _ctx->dep_map, _RET_IP_); - ret = rt_mutex_slowlock(>base.lock, TASK_UNINTERRUPTIBLE, NULL, 0, ww_ctx); + ret = rt_mutex_slowlock(>base.lock, TASK_UNINTERRUPTIBLE, NULL, 1, ww_ctx); if (ret) mutex_release(>base.dep_map, 1,_RET_IP_); else if (!ret && ww_ctx->acquired > 1) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -rt] rtmutex: enable deadlock detection in the ww_mutex_lock functions
According the ww-mutex-design.txt documentation, the ww_mutex_lock_interruptible and ww_mutex_lock functions should return -EDEADLK when faced with a deadlock. To do so, the flag detect_deadlock in the rt_mutex_slowlock calls should be enabled. This patch corrects potential deadlocks when running PREEMPT_RT with nouveau driver. Kernel v3.14-rt Signed-off-by: Gustavo Bittencourtgbit...@gmail.com --- kernel/locking/rtmutex.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c index 6c40660..3f6ef91 100644 --- a/kernel/locking/rtmutex.c +++ b/kernel/locking/rtmutex.c @@ -1965,7 +1965,7 @@ __ww_mutex_lock_interruptible(struct ww_mutex *lock, struct ww_acquire_ctx *ww_c might_sleep(); mutex_acquire(lock-base.dep_map, 0, 0,_RET_IP_); - ret = rt_mutex_slowlock(lock-base.lock, TASK_INTERRUPTIBLE, NULL, 0, ww_ctx); + ret = rt_mutex_slowlock(lock-base.lock, TASK_INTERRUPTIBLE, NULL, 1, ww_ctx); if (ret) mutex_release(lock-base.dep_map, 1,_RET_IP_); else if (!ret ww_ctx-acquired 1) @@ -1984,7 +1984,7 @@ __ww_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx *ww_ctx) mutex_acquire_nest(lock-base.dep_map, 0, 0, ww_ctx-dep_map, _RET_IP_); - ret = rt_mutex_slowlock(lock-base.lock, TASK_UNINTERRUPTIBLE, NULL, 0, ww_ctx); + ret = rt_mutex_slowlock(lock-base.lock, TASK_UNINTERRUPTIBLE, NULL, 1, ww_ctx); if (ret) mutex_release(lock-base.dep_map, 1,_RET_IP_); else if (!ret ww_ctx-acquired 1) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
