On Wed, May 10, 2017 at 03:45:24AM +0100, Al Viro wrote: > FWIW, some parts of that queue are obviously sane; it's the conversions of > kernel_write() and friends to ->read_iter/->write_iter() that are non-starters. Egads... OK, I *have* misread what you are doing there. Your vfs_iter_read() works for files sans ->read_iter(). For strange values of "works" - you hardwire "it's either iovec or kvec iterator" into its calling conventions, which is a trouble waiting to happen. What's the point? What's wrong with having kernel_read()/kernel_readv()/etc.? You still have set_fs() in there; doing that one level up in call chain would be just fine... IDGI. Broken commit: "net: don't play with address limits in kernel_recvmsg". It would be OK if it was only about data. Unfortunately, that's not true in one case: svc_udp_recvfrom() wants ->msg_control. Another delicate place: you can't assume that write() always advances file position by its (positive) return value. btrfs stuff is sensitive to that. ashmem probably _is_ OK with demanding ->read_iter(), but I'm not sure about blind asma->file->f_pos += ret. That's begging for races. Actually, scratch that - it *is* racy. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
