On 2013/2/19 20:59, Jan Kara wrote:

On Tue 19-02-13 19:47:30, Li Zefan wrote:

quoted

On 2013/2/19 17:19, Jan Kara wrote:

quoted

On Tue 19-02-13 09:22:40, Li Zefan wrote:

quoted

There's a long long-standing bug...As long as I don't know when it dates
from.

I've written and attached a simple program to reproduce this bug, and it can
immediately trigger the bug in my box. It uses two threads, one keeps calling
read(), and the other calling readdir(), both on the same directory fd.

  So the fact that read() or even write() to fd opened O_RDONLY has *any*
effect on f_pos looks really unexpected to me. I think we really should
have there:
	if (ret >= 0)
		file_pos_write(...);

I thought about this. The problem is then we have to check every fop->write()
to see if any of them can return -errno with file->f_pos changed and fix them,
though it's do-able.

  But returning error and advancing f_pos would be a bug - specification
says write() returns the number of bytes written or -1 and f_pos should be
advanced by the number of bytes written.

Oh, I had an illusion that vfs saves f_pos and calls write() and restore f_pos
if write() fails.