• Alexey Dobriyan's avatar
    seq_file: more atomicity in traverse() · cb510b81
    Alexey Dobriyan authored
    Original problem: in some circumstances seq_file interface can present
    infinite proc file to the following script when normally said proc file is
    	while read line; do
    		[do something with $line]
    	done </proc/$FILE
    bash, to implement such loop does essentially
    	read(0, buf, 128);
    	[find \n]
    	lseek(0, -difference, SEEK_CUR);
    Consider, proc file prints list of objects each of them consists of many
    lines, each line is shorter than 128 bytes.
    Two objects in list, with ->index'es being 0 and 1.  Current one is 1, as
    bash prints second object line by line.
    Imagine first object being removed right before lseek().
    traverse() will be called, because there is negative offset.
    traverse() will reset ->index to 0 (!).
    traverse() will call ->next() and get NULL in any usual iterate-over-list
    code using list_for_each_entry_continue() and such. There is one object in
    list now after all...
    traverse() will return 0, lseek() will update file position and pretend
    everything is OK.
    So, what we have now: ->f_pos points to place where second object will be
    printed, but ->index is 0.  seq_read() instead of returning EOF, will start
    printing first line of first object every time it's called, until enough
    objects are added to ->f_pos return in bounds.
    Fix is to update ->index only after we're sure we saw enough objects down
    the road.
    Signed-off-by: default avatarAlexey Dobriyan <adobriyan@sw.ru>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>