[PATCH] procfs: fix numbering in /proc/locks

[PATCH] procfs: fix numbering in /proc/locks

[Jerome Marchand]

The lock number in /proc/locks (first field) is implemented by a counter
(private field of struct seq_file) which is incremented at each call of
locks_show(). Currently it is reset each time locks_start() is called,
that is each time we call the read() syscall on /proc/locks. Because of
that, the numbering erratically restarts at 1 several times when reading
a long /proc/locks file.
We want the counter to be initialized at opening time and then never
reset until we close the file. Fortunately, seq_open() memzeros the
seq_file structure, so we can just drop the reset in locks_start() and
move the increment the counter before actually printing the line so the
numbering still starts at 1.

Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
---
diff --git a/fs/locks.c b/fs/locks.c
index ab24d49..a5eab5e 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -2161,19 +2161,18 @@ static int locks_show(struct seq_file *f, void *v)
 
 	fl = list_entry(v, struct file_lock, fl_link);
 
+	f->private++;
 	lock_get_status(f, fl, (long)f->private, "");
 
 	list_for_each_entry(bfl, &fl->fl_block, fl_block)
 		lock_get_status(f, bfl, (long)f->private, " ->");
 
-	f->private++;
 	return 0;
 }
 
 static void *locks_start(struct seq_file *f, loff_t *pos)
 {
 	lock_kernel();
-	f->private = (void *)1;
 	return seq_list_start(&file_lock_list, *pos);
 }
 

Re: [PATCH] procfs: fix numbering in /proc/locks

[Pavel Emelyanov]

On 09/27/2010 07:13 PM, Jerome Marchand wrote:
> 
> The lock number in /proc/locks (first field) is implemented by a counter
> (private field of struct seq_file) which is incremented at each call of
> locks_show(). Currently it is reset each time locks_start() is called,
> that is each time we call the read() syscall on /proc/locks. Because of
> that, the numbering erratically restarts at 1 several times when reading
> a long /proc/locks file.
> We want the counter to be initialized at opening time and then never
> reset until we close the file. Fortunately, seq_open() memzeros the
> seq_file structure, so we can just drop the reset in locks_start() and
> move the increment the counter before actually printing the line so the
> numbering still starts at 1.

IMHO the implementation is wrong. If you want the proper sequence number
while file is open you should increase on in the ->next callback of the
seq_ops, not in show.

> Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
> ---
> diff --git a/fs/locks.c b/fs/locks.c
> index ab24d49..a5eab5e 100644
> --- a/fs/locks.c
> +++ b/fs/locks.c
> @@ -2161,19 +2161,18 @@ static int locks_show(struct seq_file *f, void *v)
>  
>  	fl = list_entry(v, struct file_lock, fl_link);
>  
> +	f->private++;
>  	lock_get_status(f, fl, (long)f->private, "");
>  
>  	list_for_each_entry(bfl, &fl->fl_block, fl_block)
>  		lock_get_status(f, bfl, (long)f->private, " ->");
>  
> -	f->private++;
>  	return 0;
>  }
>  
>  static void *locks_start(struct seq_file *f, loff_t *pos)
>  {
>  	lock_kernel();
> -	f->private = (void *)1;
>  	return seq_list_start(&file_lock_list, *pos);
>  }
>  
> 

Re: [PATCH] procfs: fix numbering in /proc/locks

[Jerome Marchand]

On 09/27/2010 05:24 PM, Pavel Emelyanov wrote:
> On 09/27/2010 07:13 PM, Jerome Marchand wrote:
>>
>> The lock number in /proc/locks (first field) is implemented by a counter
>> (private field of struct seq_file) which is incremented at each call of
>> locks_show(). Currently it is reset each time locks_start() is called,
>> that is each time we call the read() syscall on /proc/locks. Because of
>> that, the numbering erratically restarts at 1 several times when reading
>> a long /proc/locks file.
>> We want the counter to be initialized at opening time and then never
>> reset until we close the file. Fortunately, seq_open() memzeros the
>> seq_file structure, so we can just drop the reset in locks_start() and
>> move the increment the counter before actually printing the line so the
>> numbering still starts at 1.
> 
> IMHO the implementation is wrong. If you want the proper sequence number
> while file is open you should increase on in the ->next callback of the
> seq_ops, not in show.

Good point. My implementation is definitely wrong. But I'm afraid that
moving the increment in locks_next() won't help either. It will fail when
a program do something more than just read the file sequentially (use
of lseek() for instance). We need a better way to keep track of the
current position in the list.

Thanks,
Jerome

Re: [PATCH] procfs: fix numbering in /proc/locks

[Pavel Emelyanov]

> Good point. My implementation is definitely wrong. But I'm afraid that
> moving the increment in locks_next() won't help either. It will fail when
> a program do something more than just read the file sequentially (use
> of lseek() for instance). We need a better way to keep track of the
> current position in the list.

The seq files core implementation knows about the lseek and
calls the seq_ops callbacks properly.

> Thanks,
> Jerome
> 
> 

Re: [PATCH] procfs: fix numbering in /proc/locks

[Jerome Marchand]

On 09/29/2010 01:43 PM, Pavel Emelyanov wrote:
>> Good point. My implementation is definitely wrong. But I'm afraid that
>> moving the increment in locks_next() won't help either. It will fail when
>> a program do something more than just read the file sequentially (use
>> of lseek() for instance). We need a better way to keep track of the
>> current position in the list.
> 
> The seq files core implementation knows about the lseek and
> calls the seq_ops callbacks properly.
> 

Yes, but if read a few lines and then lseek() back. I'm afraid it will call
a few more locks_next() function and thus increase the counter again.

Re: [PATCH] procfs: fix numbering in /proc/locks

[Pavel Emelyanov]

On 09/29/2010 03:52 PM, Jerome Marchand wrote:
> On 09/29/2010 01:43 PM, Pavel Emelyanov wrote:
>>> Good point. My implementation is definitely wrong. But I'm afraid that
>>> moving the increment in locks_next() won't help either. It will fail when
>>> a program do something more than just read the file sequentially (use
>>> of lseek() for instance). We need a better way to keep track of the
>>> current position in the list.
>>
>> The seq files core implementation knows about the lseek and
>> calls the seq_ops callbacks properly.
>>
> 
> Yes, but if read a few lines and then lseek() back. I'm afraid it will call
> a few more locks_next() function and thus increase the counter again.

No. If you lseek back it calls the locks_start which should reset the
counter, and then will call locks_next.

Can you try out my proposal and check whether it really works as expected?

Thanks,
Pavel

Re: [PATCH] procfs: fix numbering in /proc/locks

[Jerome Marchand]

On 09/29/2010 01:56 PM, Pavel Emelyanov wrote:
> On 09/29/2010 03:52 PM, Jerome Marchand wrote:
>> On 09/29/2010 01:43 PM, Pavel Emelyanov wrote:
>>>> Good point. My implementation is definitely wrong. But I'm afraid that
>>>> moving the increment in locks_next() won't help either. It will fail when
>>>> a program do something more than just read the file sequentially (use
>>>> of lseek() for instance). We need a better way to keep track of the
>>>> current position in the list.
>>>
>>> The seq files core implementation knows about the lseek and
>>> calls the seq_ops callbacks properly.
>>>
>>
>> Yes, but if read a few lines and then lseek() back. I'm afraid it will call
>> a few more locks_next() function and thus increase the counter again.
> 
> No. If you lseek back it calls the locks_start which should reset the
> counter, and then will call locks_next.
> 
> Can you try out my proposal and check whether it really works as expected?
> 

OK. I didn't understand you meant to keep the reset in locks_start(). I'll
try that.

Jerome