On Wed, Apr 15, 2026 at 04:10:00PM +0100, Matthew Wilcox wrote: > On Wed, Apr 15, 2026 at 04:04:50PM +0200, Miklos Szeredi wrote: > > On Wed, 15 Apr 2026 at 15:35, Gregory Price <[email protected]> wrote: > > > > > This was my first reaction when I realized the BPF program would be > > > controlling iomap return value in the fault path. Big ol' (!) popped > > > up over my head. > > > > I'm wondering which part of this triggers the big (!). > > > > BPF program being run in the fault path? > > > > Or that the return value from the BPF function is used as iomap? > > > > Or something else? > > If a BPF program controls what memory address a fault now allows access > to, who validates that this is a memory address within the purview of > the BPF program, and not, say, the address of the kernel page tables? > > (I have done no looking to determine if this is already considered)
We're not using bpf to implement ->filemap_fault directly. fuse would implement that as a call to dax_iomap_fault, iomap would then call fuse's ->iomap_begin, and that's where the bpf program would take over. The mapping provided would return a (struct dax_device, u64 addr, u64 length), and (presumably) the dax device access function would rangecheck that. Unless someone foolishly puts kernel page tables on the dax device... --D
