On Wed, May 10, 2017 at 04:21:37AM +0100, Al Viro wrote: > On Wed, May 10, 2017 at 04:12:54AM +0100, Al Viro wrote: > > > 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. > > kvec_length(): please, don't. I would rather have the last remaining > iov_length() gone... What do you need it for, anyway? You have only > two users and both have the count passed to them (as *count and *cnt resp.) fcntl stuff: I've decided not to put something similar into work.compat since I couldn't decide what to do with compat stuff - word-by-word copy from userland converting to struct flock + conversion to posix_lock + actual work + conversion to flock + word-by-word copy to userland... Smells like we might be better off with compat_flock_to_posix_lock() et.al. I'm still not sure; played a bit one way and another and dediced to drop it for now. Hell knows... -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
