diff for duplicates of <20180802212923.GA30522@ZenIV.linux.org.uk> diff --git a/a/1.txt b/N1/1.txt index 41f2a53..e90c630 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -2,7 +2,7 @@ On Thu, Aug 02, 2018 at 06:31:06PM +0100, Alan Jenkins wrote: > Hi > > I found this interesting, though I don't entirely follow the kernel -> mount/unmount code. I had one puzzle about the code, and two questions +> mount/unmount code.� I had one puzzle about the code, and two questions > which I was largely able to answer. > > On 01/08/18 16:24, David Howells wrote: @@ -16,14 +16,14 @@ On Thu, Aug 02, 2018 at 06:31:06PM +0100, Alan Jenkins wrote: > > + namespace_unlock(); > > +} > -> Can I ask why UMOUNT_SYNC is used here? I feel like I must have missed +> Can I ask why� UMOUNT_SYNC is used here?� I feel like I must have missed > something, but doesn't it skip the IS_MNT_LOCKED() check in > disconnect_mount() ? > > UMOUNT_SYNC seems used for non-lazy unmounts, and in internal cleanups where -> userspace wouldn't be able to see. But I think userspace can keep watching +> userspace wouldn't be able to see.� But I think userspace can keep watching > in this case, e.g. by `fd2 = openat(fd, ".", O_PATH)` (or `fd2 = -> open_tree(fd, ".", 0)` ?). I would think this function should avoid using +> open_tree(fd, ".", 0)` ?).� I would think this function should avoid using > UMOUNT_SYNC, like lazy unmount avoids it. FWIW, I suspect that UMOUNT_CONNECTED might be the right thing here... diff --git a/a/content_digest b/N1/content_digest index c095846..046b3f0 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -16,7 +16,7 @@ "> Hi\n" "> \n" "> I found this interesting, though I don't entirely follow the kernel\n" - "> mount/unmount code.\302\240 I had one puzzle about the code, and two questions\n" + "> mount/unmount code.\303\257\302\277\302\275 I had one puzzle about the code, and two questions\n" "> which I was largely able to answer.\n" "> \n" "> On 01/08/18 16:24, David Howells wrote:\n" @@ -30,16 +30,16 @@ "> > +\tnamespace_unlock();\n" "> > +}\n" "> \n" - "> Can I ask why\302\240 UMOUNT_SYNC is used here?\302\240 I feel like I must have missed\n" + "> Can I ask why\303\257\302\277\302\275 UMOUNT_SYNC is used here?\303\257\302\277\302\275 I feel like I must have missed\n" "> something, but doesn't it skip the IS_MNT_LOCKED() check in\n" "> disconnect_mount() ?\n" "> \n" "> UMOUNT_SYNC seems used for non-lazy unmounts, and in internal cleanups where\n" - "> userspace wouldn't be able to see.\302\240 But I think userspace can keep watching\n" + "> userspace wouldn't be able to see.\303\257\302\277\302\275 But I think userspace can keep watching\n" "> in this case, e.g. by `fd2 = openat(fd, \".\", O_PATH)` (or `fd2 =\n" - "> open_tree(fd, \".\", 0)` ?).\302\240 I would think this function should avoid using\n" + "> open_tree(fd, \".\", 0)` ?).\303\257\302\277\302\275 I would think this function should avoid using\n" "> UMOUNT_SYNC, like lazy unmount avoids it.\n" "\n" FWIW, I suspect that UMOUNT_CONNECTED might be the right thing here... -82a5e57c19ec52a21049c28871b39383ae6c415f8f017c9e59c1aa0bd9a3badd +d80f924b5036e4881ea1f79972fbf24fc25d7336c63c811719915f59c926290a
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.