On Sat, Mar 15, 2025 at 02:41:33PM -0400, Kent Overstreet wrote: > That's the sort of thing that process is supposed to avoid. To be clear, > you and Christoph are the two reasons I've had to harp on process in the > past - everyone else in the kernel has been fine. Kent, stop those attacks. Maybe your patches are just simply not correct? Sometimes that might be on the eye of the beholder when it is about code structure, but in may cases they simply are objectively broken. In this case you very clearly misunderstood how the FUA bit works on reads (and clearly documented that misunderstanding in the commit log). You've had multiple people explain to you how it is wrong, and the maintainer reject it for that reason. What other amount of arguments to you want? If you need another one: FUA is not just use NVMe and SCSI where it is supported on reads even if not in the way you think, but also for all kinds of other protocols. Even if we ended up thinking REQ_FUA on reads is a good idea (and so far no one but you does) you'd need to audit all these to check if the behavior is valid, and most likely add a per-driver opt-in. But so far you've not even tried to make the use case for your feature. > As I said before, I'm not trying to bypass you without communicating - > but this has gone completely off the rails. You have a very clear pattern where you assume you're perfect, everyone else is stupid and thus must be overridden. Most people (including me recently) have mostly given up arguing with your because it's so fruitless. Maybe we shouldn't have because that just seem to reaffirm you in your personal universe.
