Steve Longerbeam <[EMAIL PROTECTED]> wrote:
> It seems that in the case of a private mapping over a directly-mappable
> backing store, the only requirement is that it be read-only. Is that correct?
More to the point, we mustn't have a private writable mapping mapped directly
to the backing device, otherwise any changes made to that mapping will affect
the backing store, and that's incorrect.
Actually, that's not the only requirement. If the process doing the mapping is
under the influence of a debugger, sharing of private mappings is disabled on
the theory that the debugger might want to modify them (determine_vm_flags()).
> If so, that check was already made in validate_mmap_request()
> (BDI_CAP_MAP_DIRECT is cleared if requesting a read/write mapping).
Yes.
> So if we get to the "private file mapping for a directly mappable backing
> store" case in determine_vm_flags(), we know at this point that it is also a
> read-only mapping.
That is true.
> - else if ((((vm_flags & capabilities) ^ vm_flags) &
> BDI_CAP_VMFLAGS) == 0)
> + else {
Both of these are incorrect, I think.
In the former (which you're replacing), the condition boils down to:
(capabilities & BDI_CAP_VMFLAGS) == BDI_CAP_VMFLAGS
In the latter (your replacement), doesn't take account of the capabilities of
the backing device. Direct writeability isn't the only thing that must be
checked; direct readability and direct executability also ought to be checked.
I need to think about this some more.
David
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
