Nick Piggin <[email protected]> wrote:
> > Nick Piggin <[email protected]> wrote:
> > > This reintroduces the fault vs truncate race window, which must be fixed.
> >
> > Hmmm... perhaps.
>
> What do you mean by perhaps?
I mean 'perhaps'. I'm not sure I remember what the race was, so I can't
evaluate whether or not the same race crops up in AFS too. So: can you
describe the race please.
> No, you could do writeback caching but disallow read of dirty data.
Someone might already have read-access via mmap at the point someone attempts
to write to an mmapped region. That means that I'd have to revoke the read
access of the first someone before letting the write take place.
Does NFS do this?
> > > But otherwise I guess if you really want to discard the dirty data after
> > > a failed writeback attempt, what's wrong with just
> > > invalidate_inode_pages2?
> >
> > Erm... Because it deadlocks?
>
> Why don't you call it after calling end_page_writeback?
Because then there can be a race over who gets to flush the dead write.
Actually, this may no longer be a problem with your write_begin() changes.
I'll need to have another look at those.
Besides, I don't agree that invalidate_inode_pages2() is necessarily the right
way to do things.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]