On Sat, Feb 11, 2023 at 5:39 PM Ming Lei <ming.lei@xxxxxxxxxx> wrote: > > > > > (a) what's the point of MAY_READ? A non-readable page sounds insane > > and wrong. All sinks expect to be able to read. > > For example, it is one page which needs sink end to fill data, so > we needn't to zero it in source end every time, just for avoiding > leak kernel data if (unexpected)sink end simply tried to read from > the spliced page instead of writing data to page. I still don't understand. A sink *reads* the data. It doesn't write the data. There's no point trying to deal with "if unexpectedly doing crazy things". If a sink writes the data, the sinkm is so unbelievably buggy that it's not even funny. And having two flags that you then say "have to be used together" is pointless. It's not two different flags if you can't use them separately! So I think your explanations are anything *but* explaining what you want. They are just strange and not sensible. Please explain to me in small words and simple sentences what it is you want. And no, if the explanation is "the sink wants to write to the buffer", then that's not an explanation, it's just insanity. We *used* to have the concept of "gifting" the buffer explicitly to the sink, so that the sink could - instead of reading from it - decide to just use the whole buffer as-is long term. The idea was that tthe buffer woudl literally be moved from the source to the destination, ownership and all. But if that's what you want, then it's not about "sink writes". It's literally about the splice() wanting to move not just the data, but the whole ownership of the buffer. Anyway, I will NAK this as long as the explanations for what the semantics are and what you want to do don't make sense. Right now they don't. Linus