On Thu, Nov 7, 2019 at 10:48 AM David Howells <dhowells@xxxxxxxxxx> wrote: > > Andy Lutomirski <luto@xxxxxxxxxx> wrote: > > > > Add an O_NOTIFICATION_PIPE flag that can be passed to pipe2() to indicate > > > that the pipe being created is going to be used for notifications. This > > > suppresses the use of splice(), vmsplice(), tee() and sendfile() on the > > > pipe as calling iov_iter_revert() on a pipe when a kernel notification > > > message has been inserted into the middle of a multi-buffer splice will be > > > messy. > > > > How messy? > > Well, iov_iter_revert() on a pipe iterator simply walks backwards along the > ring discarding the last N contiguous slots (where N is normally the number of > slots that were filled by whatever operation is being reverted). > > However, unless the code that transfers stuff into the pipe takes the spinlock > spinlock and disables softirqs for the duration of its ring filling, what were > N contiguous slots may now have kernel notifications interspersed - even if it > has been holding the pipe mutex. > > So, now what do you do? You have to free up just the buffers relevant to the > iterator and then you can either compact down the ring to free up the space or > you can leave null slots and let the read side clean them up, thereby > reducing the capacity of the pipe temporarily. > > Either way, iov_iter_revert() gets more complex and has to hold the spinlock. I feel like I'm missing something fundamental here. I can open a normal pipe from userspace (with pipe() or pipe2()), and I can have two threads. One thread writes to the pipe with write(). The other thread writes with splice(). Everything works fine. What's special about notifications?
