The Linux file_operations API expects the read and write operations
to take a single user buffer pointer (along with the length and the
file offset as an in/out parameter).
However, the debugfs_fill function was violating this part of the
contract as it was passing down kernel pointers instead. An earlier
commit (5668c22a13c6befa9b8486387d38457c40ce7af4) hacked around this
by modifying simple_read_from_buffer() to treat its user pointer
argument as a kernel pointer instead. However, other commits keep
tripping over this same API mismatch
(e.g. 78e25e65bf381303c8bdac9a713ab7b26a854b8c passes a kernel pointer
to copy_from_user in fops_str_write).
Instead, change debugfs_fill to use the "raw" pseudofs mode where the
uio is passed down to directly to the fill callback rather than an
sbuf. debufs_fill now iterates over the iovec in the uio similar to
the implementation of uiomove invoking the read or write operation on
each user pointer.
This also fixes a tiny bug where the initial file offset from
uio_offset was ignored. Instead, the operations were always invoked
with a file offset of 0.
As part of this, revert the the changes to simple_read_from_buffer()
from commit 5668c22a13c6befa9b8486387d38457c40ce7af4.
Also as part of this, the simple_attr_read/write methods and seq_read
now also need to accept and handle user pointers (also matching the
API in Linux).
For simple_attr_write*(), copy the user buffer into a kernel buffer
before parsing. Also, do not permit writes at an offset as it's
unclear what the semantics for those would even be (perhaps you would
write out the formatted value into a buffer first and then allow the
copy_from_user to overwrite/extend that buffer and then re-parse the
integer value?). The old handling of *ppos for writes was definitely
wrong before and only worked for an offset of 0 anyway.
Sponsored by: AFRL, DARPA