Skip to contentSkip to conversation

Fix leaks on /proc/{*/sched,sched_debug,timer_list,timer_stats}

PATCH In review Alexey Dobriyan 4 participants 5 messages Jul 17, 2007 – Jul 18, 2007

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Fix leaks on /proc/{*/sched,sched_debug,timer_list,timer_stats}

On every open/close one struct seq_operations leaks. Kudos to /proc/slab_allocators.

---

 fs/proc/base.c            |    2 +-
 kernel/sched_debug.c      |    2 +-
 kernel/time/timer_list.c  |    2 +-
 kernel/time/timer_stats.c |    2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)
fs/proc/base.c +1 -1
@@ -926,7 +926,7 @@ static const struct file_operations proc_pid_sched_operations = {
 	.read		= seq_read,
 	.write		= sched_write,
 	.llseek		= seq_lseek,
-	.release	= seq_release,
+	.release	= single_release,
 };
 
 #endif
kernel/sched_debug.c +1 -1
@@ -200,7 +200,7 @@ static struct file_operations sched_debug_fops = {
 	.open		= sched_debug_open,
 	.read		= seq_read,
 	.llseek		= seq_lseek,
-	.release	= seq_release,
+	.release	= single_release,
 };
 
 static int __init init_sched_debug_procfs(void)
kernel/time/timer_list.c +1 -1
@@ -267,7 +267,7 @@ static struct file_operations timer_list_fops = {
 	.open		= timer_list_open,
 	.read		= seq_read,
 	.llseek		= seq_lseek,
-	.release	= seq_release,
+	.release	= single_release,
 };
 
 static int __init init_timer_list_procfs(void)
kernel/time/timer_stats.c +1 -1
@@ -399,7 +399,7 @@ static struct file_operations tstats_fops = {
 	.read		= seq_read,
 	.write		= tstats_write,
 	.llseek		= seq_lseek,
-	.release	= seq_release,
+	.release	= single_release,
 };
 
 void __init init_timer_stats(void)
Acked-by on v1 1/1
#1 lore raw
Quoted 4 lines · Alexey Dobriyan

On every open/close one struct seq_operations leaks. Kudos to /proc/slab_allocators.

ouch ...

-stable material too, as far as timer_info/stats goes.

Review

Quoted 2 lines
(quoted diff) +1 -1
-       .release        = seq_release,
+       .release        = single_release,

i think seq_release() definitely needs to grow a WARN_ON() if it's being used on an inode that was opened via single_open(). This bug is so easily committed, and nothing but a small leak reminds us on it.

Ingo

#2 lore raw

PATCH 1/1 Fix leak on /proc/lockdep_stats

Quoted 11 lines · Ingo Molnar
Quoted 4 lines · Alexey Dobriyan

On every open/close one struct seq_operations leaks. Kudos to /proc/slab_allocators.

ouch ...

Quoted 8 lines

-stable material too, as far as timer_info/stats goes.

Review

Quoted 2 lines
(quoted diff) +1 -1
-       .release        = seq_release,
+       .release        = single_release,

i think seq_release() definitely needs to grow a WARN_ON() if it's being used on an inode that was opened via single_open(). This bug is so easily committed, and nothing but a small leak reminds us on it.

Yeah, I'll try to come up with something clean.

Meanwhile full single_open() audit revealed one more such leak. The rest seems OK.

[PATCH] Fix leak on /proc/lockdep_stats

---

 kernel/lockdep_proc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/lockdep_proc.c +1 -1
@@ -339,7 +339,7 @@ static const struct file_operations proc_lockdep_stats_operations = {
 	.open		= lockdep_stats_open,
 	.read		= seq_read,
 	.llseek		= seq_lseek,
-	.release	= seq_release,
+	.release	= single_release,
 };
 
 static int __init lockdep_proc_init(void)
#3 lore raw
In reply to Ingo Molnar
Quoted 6 lines · On Tue, 17 Jul 2007 14:36:10 +0200 Ingo Molnar <[email protected]> wrote:
Quoted 3 lines · Alexey Dobriyan

On every open/close one struct seq_operations leaks. Kudos to /proc/slab_allocators.

Quoted 7 lines
Quoted 1 line

ouch ...

-stable material too, as far as timer_info/stats goes.

So I have a patch which will not fully apply to -stable.

Sorry, but I can't be bothered splitting it up. Greg, Chris: please just apply the bits which apply and drop the other bits if that's OK.

#4 lore raw
Quoted 2 lines · * Andrew Morton ([email protected]) wrote:

Sorry, but I can't be bothered splitting it up. Greg, Chris: please just apply the bits which apply and drop the other bits if that's OK.

Yup