* mm/filemap.c: atomic file read(2)/write(2) ?
@ 2004-01-09 12:08 Klaus Ripke
2004-01-10 16:35 ` Linus Torvalds
0 siblings, 1 reply; 2+ messages in thread
From: Klaus Ripke @ 2004-01-09 12:08 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: mm/filemap.c: atomic file read(2)/write(2) ?
2004-01-09 12:08 mm/filemap.c: atomic file read(2)/write(2) ? Klaus Ripke
@ 2004-01-10 16:35 ` Linus Torvalds
0 siblings, 0 replies; 2+ messages in thread
From: Linus Torvalds @ 2004-01-10 16:35 UTC (permalink / raw)
To: Klaus Ripke; +Cc: Kernel Mailing List
On Fri, 9 Jan 2004, Klaus Ripke wrote:
>
> 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
Nope. There are file descriptors that have atomicity guarantees (pipes(,
but regular files do not. In particular, even on UP you'll see nonatomic
reads with PREEMPT enabled.
Even without preempt you could see interesting partial updates if you take
a page fault. That's true even if your user space only ever reads or
writes within a whole page, since what you can get on the read() path is:
- read one word from the page cache
- try to write it to user space
- take a page fault - sleep
- writer now comes in and updates the region
- the reader comes back after the page fault
- the reader completes the copy_to_user(), but the _first_ word was read
from the old page cache contents and not re-read.
(This will depend on which particular version of copy_to_user() you use: a
"rep movs" will re-read the page cache and give an "atomic" read, while
all other forms of memory copies will only re-try the destination write
instruction, with the old value read from the source).
Linus
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2004-01-10 17:01 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-09 12:08 mm/filemap.c: atomic file read(2)/write(2) ? Klaus Ripke
2004-01-10 16:35 ` Linus Torvalds
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).