On Fri, Jul 19, 2024 at 10:30:01AM GMT, Theodore Ts'o wrote: > On Thu, Jul 18, 2024 at 06:24:08PM -0400, Kent Overstreet wrote: > > > > I've gotten essentially zero in the way of test feedback from > > for-next (except from Stephen Rothwell directly, the odd build > > warning or merge issue, but 0day mostly catches the build stuff > > before it hits next). > > I am currently running regular testing on the new linux-next's fs-next > branch. Things which are still blocking me from announcing it are: > > *) Negotiating with Konstantin about the new lists.linux.dev mailing > list. > > *) A few minor bug fixes / robustification improves in the > "gce-xfstests watch" --- for example, right now if git fetch fails > due to load throttling / anti-DOS protections on git.kernel.org > trip the git watcher dies. Obviously, I need to teach it to do > exponential backoff retries, because I'm not going to leave my > kernel.org credentials on a VM running in the cloud to bypass the > kernel.org DOS protections. :-) > > As far as bcachefs is concerned, my xfstests-bld infrastructure isn't > set up to build rust userspace, and Debian has a very ancient bcachefs > packages --- the latest version in Debian stable and unstable dates > from November 2022. So I haven't enabled bcachefs support in > gce-xfstests and kvm-xfstests yet. Patches gratefully accepted. :-) I can apt install 1.9.1? But I just discovered, because I had to switch my own testing to the debian package, that the mount helper wasn't being run previously (doesn't check /usr/local/sbin); and mounts with the mount helper are failing with -EBUSY. Presumably there's a race, since before calling the mount syscall, our mount helper has to open and close the block device (we have to read the superblock to check if it's encrypted, we may need to ask for a passphrase). The delayed_fput stuff that was causing issues with io_uring - I suspect something similar. But the plot thickens - all the failing tests are ones that use device mapper...
