lkml.org 
[lkml]   [2009]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [GIT PATCH] TTY patches for 2.6.33-git


On Sat, 12 Dec 2009, Alan Cox wrote:

> > I think we could possibly add a "__might_sleep()" to _lock_kernel(). It
> > doesn't really sleep, but it's invalid to take the kernel lock in an
> > atomic region, so __might_sleep() might be the right thing anyway.
>
> It's only invalid if you don't already hold the lock.

True.

> The old tty code worked because every path into tty_fasync already held
> the lock ! That specific case - taking it the first time should
> definitely __might_sleep().

That would give us at least somewhat better debugging. And it's a very
natural thing to do. IOW, just something like the appended.

But maybe it complains about valid (but unusual) things. For example, it's
not strictly speaking _wrong_ to take the kernel lock while preemption is
disabled, even though it's a really bad idea.

Anybody willing to be the guinea-pig?

Linus

---
lib/kernel_lock.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/lib/kernel_lock.c b/lib/kernel_lock.c
index 4ebfa5a..5526b46 100644
--- a/lib/kernel_lock.c
+++ b/lib/kernel_lock.c
@@ -122,8 +122,10 @@ void __lockfunc _lock_kernel(const char *func, const char *file, int line)

trace_lock_kernel(func, file, line);

- if (likely(!depth))
+ if (likely(!depth)) {
+ might_sleep();
__lock_kernel();
+ }
current->lock_depth = depth;
}


\
 
 \ /
  Last update: 2009-12-13 02:19    [W:0.474 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site