On Thu, Dec 21, 2017 at 05:33:38AM -0800, Christoph Hellwig wrote: > Eek. Whie eBPF is a really nice debug tool we should never use > it for actual required kernel I/O functionality. Certainly not in its current hacky form. I'm curious if Richard has had a chance to try out these patches to see if it affects performance in a noticeable way? I /think/ bpf has enough safety mechanisms (no loops, no direct writing to kernel memory, bytecode verifiers, opcode count limits) that such a beast could be hidden behind a kconfig option that isn't turned for the general public. For people who have these particularly specific use cases I think it better to have a general mechanism to accomodate them vs. scattering code all over xfs vs. "no sorry go away", though this ebpf thing isn't necessarily the final answer. We do validate that the proposed iflags are allowed for the fs geometry, though I acknowledge that the prospect of running ebpf with ilock_excl does give me pause. I'm curious, though, what are your (and everyone else's) concerns about this? --D > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
