First of all, my apologies for being very late with any pull requests this window. There had been quite a bit of reshuffling (and fixes) in mount API series; see vfs.git #Q.. (up to #Q44) for the whole gory story. And yes, it is what it looks like - 44 branches with this stuff getting massaged. In the current form it's not ready for pull as a whole. It's in much better shape than it used to be, and I *am* reasonably sure it'll get into mergable shape by the next cycle, but right now the situation looks thus: * beginning of the series - preparatory LSM massage (includes some fixes, as well, but nothing earth-shattering). That part is, IMO, stable and makes sense on its own. -300LoC balance, most of it in security/* and a lot of code duplication in there is gone. Sat in -next for a while, appears to work. That's #mount.part1. IMO ready for merge. * introduction of fs_context, conversion of mount(2) and friends to it, fs_context methods. Carved up into reasonable chunks, sat in -next for a while, appears to work. One thing in there that I'm not entirely happy about is the fs_parser data structures. That's options-parsing machinery and IMO it's overoptimized. If that ends up pulled in, I expect it to turn into a much dumber form over the next cycle or two. bsearch() is *not* worth bothering with, when the table size is in low tens and the codepath isn't hot by any stretch of imagination. That's pretty much orthogonal to everything else (static tables representing the options syntax; the functional interface is OK and I don't expect any changes in it). I'd say it's not an obstacle to pulling the thing in; being late in cycle, OTOH, might be. If that part is not in -rc1, the dumbing down of those tables will happen by -rc2 time, regardless of the pull timing. That part is in #mount.part2. * conversion of a bunch of filesystems to fs_context mechanism. Mostly to get rid of weird abuses of the old one, since they (e.g. passing stuff to internal procfs and mqueue mounts) can be done in a lot more straightforward way now. That part is mostly OK, except that kernfs/cgroup/sysfs side is not well. There had been refcounting bugs (including the one present in mainline, caught just today) and while I'm optimistic about the fixes posted, if it needs non-trivial fixing on the Thursday of the second week of merge window... FWIW, userns interactions in that part (broken in the original series) is fixed. Anyway, kernfs conversion could be skipped for a while - subsequent commits do not depend upon it. We'll definitely need mainline refcounting fixes to go first for backporting reasons. I expect this thing to settle down pretty soon, it's just that it's clearly too late for -rc1. * documentation. Needs some tidying up. * AFS conversion to fs_context. AFAICS it's fine. * new syscalls. That's been outside of -next for the last couple of weeks; I have fixes for propagation issues (as well as handling of referral points/submounts after fsmount()) in a local branch, but it had been too close to -final, so that part goes into the next cycle. * NFS and btrfs conversions. Definitely next cycle; never sat in -next, and most of the NFS series is independent from fs_context, so it shouldn't be cause cross-tree headache. It does clean NFS mount-related logics nicely (horrors with 4 internal file_system_type are all gone, for example), and it does seem to work, but it didn't get anywhere near testing and exposure. The footprint of the series has shrunk quite a bit since the last cycle; so has the result (~-800LoC total). More commits in there now, due to carving up... Other than that, there are 3 very small branches in -next, with assorted cleanups and fixes (#work.misc, #work.iov_iter, #misc.misc). The only problem with pulling those is being very late in the cycle; other than that there shouldn't be no problem with those. How would you prefer to for this stuff to be handled?
