Hey Darrick, I'll try to get to testing this out early next week, I was out on vacation the last couple weeks so I kinda fell off the earth for a bit. I will test for functionality & performance as best I can, but we'll probably want to explore everyone's concerns on leveraging eBPF in this way as well. I have pretty limited experience with BPF, so I'm probably not going to be super useful in such a discussion, though I'll certainly try to get read up on it. Is there any precedence for doing this sort of thing with BPF anywhere else in the kernel? Richard > On Dec 21, 2017, at 8:45 AM, Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote: > > 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
