[PATCH 0/7] seq_file .next functions should increase position index

[PATCH 0/7] seq_file .next functions should increase position index

[Vasily Averin]

In Aug 2018 NeilBrown noticed 
commit 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface")
"Some ->next functions do not increment *pos when they return NULL...
Note that such ->next functions are buggy and should be fixed. 
A simple demonstration is
   
dd if=/proc/swaps bs=1000 skip=1
    
Choose any block size larger than the size of /proc/swaps.  This will
always show the whole last line of /proc/swaps"

Described problem is still actual. If you make lseek into middle of last output line 
following read will output end of last line and whole last line once again.

$ dd if=/proc/swaps bs=1  # usual output
Filename				Type		Size	Used	Priority
/dev/dm-0                               partition	4194812	97536	-2
104+0 records in
104+0 records out
104 bytes copied

$ dd if=/proc/swaps bs=40 skip=1    # last line was generated twice
dd: /proc/swaps: cannot skip to specified offset
v/dm-0                               partition	4194812	97536	-2
/dev/dm-0                               partition	4194812	97536	-2 
3+1 records in
3+1 records out
131 bytes copied

There are lot of other affected files, I've found 30+ including
/proc/net/ip_tables_matches and /proc/sysvipc/*

I've sent patches into maillists of affected subsystems already,
this patch-set fixes the problem in files related to 
pstore, tracing, gcov, sysvipc  and other subsystems processed 
via linux-kernel@ mailing list directly

https://bugzilla.kernel.org/show_bug.cgi?id=206283

Vasily Averin (7):
  pstore_ftrace_seq_next should increase position index
  gcov_seq_next should increase position index
  t_next should increase position index
  fpid_next should increase position index
  eval_map_next should increase position index
  trigger_next should increase position index
  sysvipc_find_ipc should increase position index

 fs/pstore/inode.c                   | 2 +-
 ipc/util.c                          | 2 +-
 kernel/gcov/fs.c                    | 2 +-
 kernel/trace/ftrace.c               | 9 ++++++---
 kernel/trace/trace.c                | 4 +---
 kernel/trace/trace_events_trigger.c | 5 +++--
 6 files changed, 13 insertions(+), 11 deletions(-)

-- 
1.8.3.1

[PATCH] seq_read: info message about buggy .next functions

[Vasily Averin]

It helps to detect missed or out-of-tree incorect .next seq_file functions

https://bugzilla.kernel.org/show_bug.cgi?id=206283
Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
---
 fs/seq_file.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/fs/seq_file.c b/fs/seq_file.c
index 1600034..07c6909 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -256,9 +256,12 @@ ssize_t seq_read(struct file *file, char __user *buf, size_t size, loff_t *ppos)
 		loff_t pos = m->index;
 
 		p = m->op->next(m, p, &m->index);
-		if (pos == m->index)
-			/* Buggy ->next function */
+		if (pos == m->index) {
+			pr_info("buggy seq_file .next function %ps "
+				"did not updated position index\n",
+				m->op->next);
 			m->index++;
+		}
 		if (!p || IS_ERR(p)) {
 			err = PTR_ERR(p);
 			break;
-- 
1.8.3.1

Re: [PATCH 0/7] seq_file .next functions should increase position index

[Steven Rostedt]

On Fri, 24 Jan 2020 10:02:36 +0300
Vasily Averin <vvs@virtuozzo.com> wrote:

> 
> I've sent patches into maillists of affected subsystems already,
> this patch-set fixes the problem in files related to 
> pstore, tracing, gcov, sysvipc  and other subsystems processed 
> via linux-kernel@ mailing list directly

Since you sent the patches out individually, and not as the usually way
of replying to the 0/7 patch (this email), do you expect the patches to
just be accepted by the individual maintainers, and not as a series?

-- Steve

> 
> https://bugzilla.kernel.org/show_bug.cgi?id=206283
> 
> Vasily Averin (7):
>   pstore_ftrace_seq_next should increase position index
>   gcov_seq_next should increase position index
>   t_next should increase position index
>   fpid_next should increase position index
>   eval_map_next should increase position index
>   trigger_next should increase position index
>   sysvipc_find_ipc should increase position index
> 
>  fs/pstore/inode.c                   | 2 +-
>  ipc/util.c                          | 2 +-
>  kernel/gcov/fs.c                    | 2 +-
>  kernel/trace/ftrace.c               | 9 ++++++---
>  kernel/trace/trace.c                | 4 +---
>  kernel/trace/trace_events_trigger.c | 5 +++--
>  6 files changed, 13 insertions(+), 11 deletions(-)
> 

Re: [PATCH 0/7] seq_file .next functions should increase position index

[Vasily Averin]

On 1/24/20 6:50 PM, Steven Rostedt wrote:
> On Fri, 24 Jan 2020 10:02:36 +0300
> Vasily Averin <vvs@virtuozzo.com> wrote:
> 
>>
>> I've sent patches into maillists of affected subsystems already,
>> this patch-set fixes the problem in files related to 
>> pstore, tracing, gcov, sysvipc  and other subsystems processed 
>> via linux-kernel@ mailing list directly
> 
> Since you sent the patches out individually, and not as the usually way
> of replying to the 0/7 patch (this email), do you expect the patches to
> just be accepted by the individual maintainers, and not as a series?

Yes, you are right, I've missed it.
Could you please review tracing-related patches of this patch set?

>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=206283
>>
>> Vasily Averin (7):
>>   pstore_ftrace_seq_next should increase position index
>>   gcov_seq_next should increase position index
>>   t_next should increase position index
>>   fpid_next should increase position index
>>   eval_map_next should increase position index
>>   trigger_next should increase position index
>>   sysvipc_find_ipc should increase position index
>>
>>  fs/pstore/inode.c                   | 2 +-
>>  ipc/util.c                          | 2 +-
>>  kernel/gcov/fs.c                    | 2 +-
>>  kernel/trace/ftrace.c               | 9 ++++++---
>>  kernel/trace/trace.c                | 4 +---
>>  kernel/trace/trace_events_trigger.c | 5 +++--
>>  6 files changed, 13 insertions(+), 11 deletions(-)
>>
>