Re: [ZOMG RFCRAP PATCH 0/2] xfs: horrifying eBPF hacks

["Darrick J. Wong" <darrick.wong@oracle.com>]

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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html