On Mon, Aug 25, 2025 at 04:46:34PM +0400, Askar Safin wrote: > > ---- On Tue, 19 Aug 2025 12:21:33 +0400 Christian Brauner <brauner@xxxxxxxxxx> wrote --- > > On Mon, Aug 18, 2025 at 03:31:27PM +1000, Aleksa Sarai wrote: > > > I would merge the first three patches -- adding and removing code like > > Agreed. > > May I still not merge these patches? > > All they may (hypothetically) fail on their own. > > If they do, then it will be valuable to know from bisection which of them failed. > > Let's discuss them one-by-one. > > The first patch moves checks from handle_mounts to traverse_mounts. > But handle_mounts is not the only caller of traverse_mounts. > traverse_mounts is also called by follow_down. > I. e. theoretically follow_down-related code paths can lead to problems. > I just checked all them, none of them set LOOKUP_NO_XDEV. > So, they should not lead to problems. But in kernel we, of course, never > can be sure. They should not lead to problems, but still can. > > The second patch removes LOOKUP_NO_XDEV check. > This is okay, because if "jumped" is set and "LOOKUP_NO_XDEV" is set, then > this means that we already set error, and thus ND_JUMPED should > not be read, because it is not read in error path. But this is not obvious, and > so Al asked me add comment ( > https://lore.kernel.org/linux-fsdevel/20250817180057.GA222315@ZenIV/ > ), and, of course, I will add it in the second version in any case. > So, ND_JUMPED should not be checked in error path, and thus this should > not lead to problems. But still can. > > The third patch makes traverse_mounts fail > immidiately after first mount-crossing > (if LOOKUP_NO_XDEV is set). As opposed to very end. > This should not lead to problems. But can. > > So, again, any of these 3 patches can (hypothetically) > lead to its own problems. You can send them separately if you like but I'll still reserve the right to squash them when applying. I don't see the value in these minimal changes yet and the regression potential is completely theoretical so far.
