Messages in this thread |  | | | Date | Thu, 2 Jul 2009 10:39:01 -0700 (PDT) | | From | Linus Torvalds <> | | Subject | Re: Exiting with locks still held (was Re: [PATCH] kmemleak: Fix scheduling-while-atomic bug) |
On Thu, 2 Jul 2009, Catalin Marinas wrote: > > Initially, the scan_mutex was acquired in kmemleak_open() and released > in kmemleak_release() (corresponding to /sys/kernel/debug/kmemleak > operations). This was causing some lockdep reports when the file was > closed from a different task than the one opening it. This patch moves > the scan_mutex acquiring in kmemleak_write() or kmemleak_seq_show().
This is better, but not really how you are supposed to do it.
The whole seq-file thing is very much _designed_ for taking a lock at the beginning of the operation, and releasing it at the end. It's a very common pattern.
But you should _not_ do it in the "show" routine. If you do, you're always going to be racy wrt lseek() and friends.
What you _should_ do is to take the lock in the "seq_start" routine, and release it in "seq_stop". The "seq_show" routine may be called multiple times in between.
For a trivial example, see the drivers/char/misc.c file. Note how it needs to hold the lock over the whole list traversal, and how seqfiles allows it to do that quite naturally.
Linus
|  |