Landlock doesn't use eBPF; it has its own syscalls and supporting infrastructure in the kernel proper. I think the relationship to LSM is simply that the LSM component is what ties
other syscalls into the subsystem, otherwise the Landlock infrastructure is never hit when operating on files.
AFAICT, Landlock works much the same way as OpenBSD unveil--it doesn't compare path strings at the point of open, but rather opens and caches dentry objects when you install the rule. Rules are basically attached to inodes. So, for example, if you permit read access at or under /some/path, then when installing the rule a Landlock application opens /some/path to acquire a file descriptor to the then-existing directory or file from which the Landlock syscall will retrieve and cache the dentry object. (OpenBSD unveil takes a path string, not a file descriptor, but the process is otherwise identical--the unveil syscall effectively performs the open, but there's no need to actually create a file descriptor.)
On Unix, when a file open is performed the open syscall traverses the string path, iteratively looking up (or creating) dentry objects for each path component. What Landlock does is that as each dentry object is traversed, it looks for Landlock rulesets attached to that dentry and accumulates a bitmask of permitted operations across all traversed dentries. When it reaches the terminal dentry object, if the requested operation (e.g. read-only, read-write, execute) isn't in the accumulated bitmask, then the open is rejected.
On OpenBSD if the directory or file with the attached rule is unlinked then you effectively lose access to that path (including any subpath) as any newly created file or directory at that path will have a different inode. Notably, a rule effectively pins a directory or file for the life of process, so it's possible to temporary leak disk space, same as unlinking something while retaining a previously opened file descriptor. I assume (without looking deeper into the code) the same is true with Landlock, but it's possible it might prevent unlinking or do some extra gymnastics to provide slightly more intuitive behavior.
Attaching rules to dentries neatly avoids fatal TOCTTOU security issues from which path name string comparison-based access restrictions have typically suffered. But the mechanism leaks Unix VFS and FS semantics--existence of and relationship between dentries, inodes, and path components.