On Mon, Apr 08, 2013 at 08:27:50PM -0700, John Stultz wrote:marked volatile, it should remain volatile until someone who has theYes. We need it that clear volatile ranges when the file is closed
file open marks it as non-volatile. The only time we clear the
volatility is when the file is closed by all users.
by ball users. That's what we need and blow my concern out.
I think the concern about surprising an application that isn'tTrue. My concern is delayed punching without any client of fd and
expecting volatility is odd, since if an application jumped in and
punched a hole in the data, that could surprise other applications
as well. If you're going to use a file that can be shared,
applications have to deal with potential changes to that file by
others.
there is no interface to detect some range of file is volatile state or
not. It means anyone mapped a file with shared could encunter SIGBUS
although he try to best effort to check it with lsof before using.
To me, the value in using volatile ranges on the file data isAgree if you provide to clear out volatility when file are closed by
exactly because the file data can be shared. So it makes sense to me
to have the volatility state be like the data in the file. I guess
the only exception in my case is that if all the references to a
file are closed, we can clear the volatility (since we don't have a
sane way for the volatility to persist past that point).
all stakeholder.
One question that might help resolve this: Would having some sort ofIf we can provide above things, I think we don't need such interface
volatility checking interface be helpful in easing your concern
about applications being surprised by volatility?
until someone want it with reasonable logic.
True. And performance needs to be good if this hinting interface isNP. But keep in mind that mmap_sem was really terrible for performance
to be used easily. Although I worry about performance trumping sane
semantics. So let me try to implement the desired behavior and we
can measure the difference.
when I took a expereiment(ie, concurrent page fault by many threads
while a thread calls mmap).
I guess primary reason is CONFIG_MUTEX_SPIN_ON_OWNER.
So at least, we should avoid it by introducing new mode like
VOLATILE_ANON|VOLATILE_FILE|VOLATILE_BOTH if we want to
support mvrange-file and mvragne interface was thing userland people
really want although ashmem have used fd-based model.