Re: mmap call to filesystem

Subject: Re: mmap call to filesystem
From: Terry Lambert <email@hidden>
Date: Sun, 29 Jun 2008 11:25:44 -0700

On Jun 28, 2008, at 11:45 PM, shailesh jain <email@hidden> wrote:

On Sat, Jun 28, 2008 at 11:25 PM, Michael Smith <email@hidden> wrote:

On Jun 28, 2008, at 7:33 PM, shailesh jain wrote:
On Sat, Jun 28, 2008 at 7:09 PM, Michael Smith <email@hidden> wrote:

On Jun 28, 2008, at 5:09 PM, shailesh jain wrote:

2) Also, I wanted to know about the option MAP_PRIVATE passed to the mmap call. When, this option
is passed, the modifications to the data are just made in-memory and are not reflected to the actual object. Now, If PROT_WRITE option is passed to the filesystem and the file is just opened for reading,
should the call fail ?

No. It is perfectly legal to open a file with read/write permission and then map a portion such that changes to the mapped region are not written back to the file.

For mmap to succeed, the file should have been opened with the read flag always.

Not at all. A file can be written to without being read, whether the vector by which it is written is a mapped operation or a regular file write.
<code snippet>
220 #if 3777787
221         /*

222          * Since the hardware currently does not support writing without
223          * read-before-write, or execution-without-read, if the request is

224          * for write or execute access, we must imply read access as well;
225          * otherwise programs expecting this to work will fail to operate.

226          */
227         if (prot & (VM_PROT_EXECUTE | VM_PROT_WRITE))

228                 prot |= VM_PROT_READ;
229 #endif  /* radar 3777787 */

230 
</code snippet>

This is the comment in the mmap code. i.e they implcitly add PROT_READ protection bits. Further down the code they check, if VM_PROT_READ was specified and file was not opened for reading then they return EACCES error code.

<code snippet>
380                         if (fp->f_fglob->fg_flag & FREAD)

381                                 maxprot |= VM_PROT_READ;

382                         else if (prot & PROT_READ) {

383                                 (void)vnode_put(vp);

384                                 error = EACCES;

385                                 goto bad;
386                         }
</code snippet>

Also, the man page for mmap ( http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/mmap.2.html ) says
that mmap will fail with EACCES if fildes is not opened for reading. Am I missing something ?

No. I wrote that code. It was processor capability specific.

Shouldn't it depend upon options {MAP_PRIVATE or MAP_SHARED } which are not passed to the filesystem ?

No. The VM is responsible for deciding whether pages will be written to the file; the filesystem is generally not involved in authorisation.

Also, I was looking at the mmap implementation but couldn't figure out how MAP_PRIVATE option was handled by kernel.

You're looking at the wrong place; you want to look at how the VM sets up the mapping against the object. You can expect to see the region marked copy-on-write, with an intermediate copy object involved.

So, if the filesystem is not involved in authorization that what is the purpose of passing protection flag {PROT_WRITE, PROT_READ, PROT_EXEC} to the filesystem ?

These are supplied as a courtesy to the filesystem in case it wants/needs to make specific arrangements regarding the mapping.

I did not follow this comment. What specific arrangements can be made regarding the mapping ?

Unless the filesystem is a proxy for a remote authority (e.g. a network filesystem), its responsibility regarding authorisation is limited to correctly answering questions posed by VNOP_GETATTR.

If it was network file system what difference would it make ?

A network FS can have different mapping requirements. Specifically, to execute it, you may needs to be able to read it. This is the same problem Intel hardware has.

Mike is correct about write-only, which I think was his point. As an FS author you need to be prepared for that.

-- Terry

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References:
	>mmap call to filesystem (From: "shailesh jain" <email@hidden>)
	>Re: mmap call to filesystem (From: "shailesh jain" <email@hidden>)
	>Re: mmap call to filesystem (From: Michael Smith <email@hidden>)
	>Re: mmap call to filesystem (From: "shailesh jain" <email@hidden>)

Prev by Date: Re: mmap call to filesystem
Next by Date: Re: mmap call to filesystem
Previous by thread: Re: mmap call to filesystem
Next by thread: Re: mmap call to filesystem
Index(es):
- Date
- Thread