mm/filemap.c: atomic file read(2)/write(2) ?

[Klaus Ripke <paul@malete.org>]

hi all

judging from mm/filemap.c it seems like
ordinary reads/writes should be atomic to each other
(read sees write completely or not at all,
not only where it "can be proven to be after the write"),
if
- the fs uses the generic code from filemap.c,
  like ext2 and most do
- the file region affected fits within one cache page,
  like nice little B-Tree blocks do,
  so there is only one copy_from/to_user per call
- the respective userspace memory regions fit within
  one page, so the copy will not be interrupted
- we're not interfering with another processor
  (but depending on mm hardware it could even work on SMP ?)

correct?

Would be a nice property to avoid read locks on a L-B-Tree

thx + cheers
Paul