+successful, false on failure. Failure cases include the following:
+
+@itemize @bullet
+@item
+@var{addr} is not page-aligned.
+
+@item
+@var{length} is not positive.
+
+@item
+The range of pages mapped overlaps any existing set of mapped pages,
+including the stack or pages mapped at executable load time.
+@end itemize
+
+@var{length} is treated as if it were rounded up to the nearest
+multiple of the page size, that is, as if the first statement in the
+system call's implementation were
+@example
+length = ROUND_UP (length, PGSIZE);
+@end example
+The remainder of this description assumes that this has been done.
+
+If @var{length} is less than @var{fd}'s length, you should only map
+the first part of the file. If @var{length} is greater than
+@var{fd}'s length, when the file's length is also rounded up to the
+nearest multiple of the page size, the call should fail. Ideally it
+would extend the file, but our file system does not yet support
+growing files.
+
+If @var{length} is greater than @var{fd}'s unrounded length, then some
+bytes in the final mapped page ``stick out'' beyond the end of the
+file. These bytes are set to zero when the page is faulted in from
+disk. They are discarded when the page is written back to disk.
+
+Your VM system should be able to use the @code{mmap}'d file itself as
+backing store for the mapped segment. That is, if a page mapped by
+@code{mmap} must be evicted, write it to the file it was mapped from.
+(In fact, you may choose to implement executable mappings as a special
+case of file mappings.)