Implement seek on FileOperations

[alex]

Refs #110

[geofft]

(LGTM otherwise)

[alex]

The kernel seems to just use loff_t for all these values, even when a negative makes no sense. Opinions?

[alex]

Updated to make from_ptr unsafe

[geofft]

Quoting this in the main comment thread so it doesn't get lost in line-item review.

Is as u64 the right thing here? (What does native C code do?)

OK, the answer is miserable:

• struct file stores the offset in the signed variable loff_t f_pos.
• For rare files like /dev/kmem that can be larger than the maximum signed long, there's a flag FMODE_UNSIGNED_OFFSET in struct file::f_mode that indicates that the offset is to be treated as an unsigned instead of a signed. That means, don't complain about a "negative" offset (it will be treated as positive by the read/write code). Introduced in torvalds/linux@4a3956c7, changed into its current form in torvalds/linux@cccb5a1e, vulnerability fixed in torvalds/linux@e8905ec2.
• The built-in generic code in fs/read_write.c (see default_llseek and generic_file_llseek_size/vfs_setpos) will calculate the final offset as a signed (loff_t), then do a signed comparison to zero if FMODE_UNSIGNED_OFFSET isn't set and raise EINVAL. Presumably it is UB to do SEEK_CUR while you're over in offsets greater than 2^63. (Yikes.)

I think the right thing to do here is to punt on handling FMODE_UNSIGNED_OFFSET files for now, raise EINVAL on a SeekFrom::Start(n) if n < 0, and encourage calling code to do the same if the final seek position makes no sense (either before the start or after the end).