On Fri, Mar 20, 2015 at 07:37:58PM +0200, Vitaly Chernooky wrote: > > What does it have to do with filesystem type involved? > > Discussed trouble directly depends on is it used nonseekable_open() in > fs driver or not. Regular fss like ext4 does not use > nonseekable_open() so there is no troubles. But others like ubifs, > debugfs, fuse and xenfs use it and are affected by discussed > regression. What does nonseekable_open() have to do with that, other than as a heuristics for "we want to break 2.9.7"? > I do not know who, when and why has introduced this > mess. It is pre-git historical code. And now by introducing > FMODE_ATOMIC_POS we change behavior of this mature practice and affect > at least few filesystems. Yes, following standards is good, but I do > not accept than breaking mature code is good idea. So I have chosen to > clear FMODE_ATOMIC_POS in nonseekable_open() simultaneously with > FMODE_LSEEK because it returns that nonseekable semi-standard files > back to life. I guess, it is the best solution for now. And, also, XEN > guys are happy with this solution. > > So what do you think about all this mess and may be it is possible to > have got better solution? What the devil does that have to do with seeks, anyway? Exact same problem will happen for blocking read() vs. another read() attempts on the same descriptor. With perfectly accepted lseek() (which will also have to block, as per 2.9.7). Which file is that? And what behaviour did you get on old kernels with it? All reads block inside ->read() rather than sys_read()? Details, please. Your strace doesn't show the relevant open(), so it's hard to tell what's really going on there in that regression. I agree that user-visible behaviour changes need to be dealt with; it's the nature of your fix I've a problem with. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
