Re: [PATCH/RFC] autofs-5.1.8 - support setting mount propagation for autofs mount point.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/3/23 14:26, Ian Kent wrote:
On 9/3/23 17:23, NeilBrown wrote:
On Thu, 09 Mar 2023, Ian Kent wrote:
On 8/3/23 13:52, NeilBrown wrote:
New flags in the master map:
    autofsshared
    autofsprivate
    autofsslave

cause the corresponding mount propagation flags to be set on the autofs mount point.  If none are specified the current behaviour of inheriting
from the parent unchanged.

For example specify "autofsprivate" allows mount points to be moved
away from autofs using "mount -M .....".  This is not supported by the
kernel for the normal default of "shared".

Better flag names should be chosen.  I would have liked to use "shared", "private", and "slave", but they are already in use and only affect bind
mounts.
Looks fine, I'll add it to my patch queue, can't say when I'll commit

them though. If you need it committed sooner let me know.
No rush at all - that fact that you don't hate it is enough for now.
I was hoping you *would* hate the flag names I chose and would suggest
something better.

I think your suggesting merging this with the existing code, that's were

I was going too.


After pondering some more the best I can think of is

   private-autofs
etc.
Can you think of anything better?

maybe
   private=autofs
which could later be extended to a list of filesystem types...

My other thought is that if they autofs mount is "private" then that is
inherited to all descendants including the "bind" mounts.  So if we
changed "private" to apply to the autofs mounts rather than just the
bind mounts, then it would still affect the bind mounts as documented,
but it would affect more as well....  I guess that would end up
negatively affecting someone though...

I can't remember now the motivation for what I originally did.


I'll need to look at that but I suspect it's similar, if not

the same, as your reasons for needing it. I should get a bit

of time soon to have a look ...

It looks like the only thing to worry about if we decide to merge

the existing propagation options and these is whether we check

and stop people from shooting themselves in the foot by causing

a deadlock and working out if there are other cases of deadlock

beside bind mounting.


Ian




[Index of Archives]     [Linux Filesystem Development]     [Linux Ext4]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux