On Mon, 13 Mar 2023, Ian Kent wrote: > On 13/3/23 11:26, NeilBrown wrote: > > On Sat, 11 Mar 2023, Ian Kent wrote: > >> 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. > >> > > I'm not sure that I understand the cause of the deadlock. > > It's been a while but IIRC it was because of mounts that were > > propagation shared. > > > They were propagating to another mount but were also being > > propagated back which was strange. Again, IIRC and I'm not sure > > I do, when a mount was triggered it was causing the propagation > > (back) to cover original mount and trying to follow it triggered > > another mount that couldn't be competed (since the first couldn't > > be completed). It was odd and I'm pretty sure it shouldn't have > > been happening. > I didn't some digging and experimenting. I created /etc/auto.master.d/tst.autofs : /import /etc/import.map shared bind and /etc/import.map loop -type=lofs / localhost:/export /B localhost:/export/B /C localhost:/export/C and then tried to access /import/loop/B. I got a deadlock. automount has called spawn_bind_mount() which called do_spawn() with SPAWN_OPT_OPEN set. After forking and changing pgrp do_spawn() tried to open the target: /export/B. This had an autofs mount back-propagated to it and hung waiting for the bind mount to complete. I rebuilt after configuring with --enable-mount-locking (which turns off SPAWN_OPT_OPEN) and don't get the deadlock any more. I don't think that is a useful solution, just a proof-of-concept work-around. > > Fact is it was hard to understand what was going on in the first > > place, but one thing is sure, propagation shared is not friendly > > for automounting and is probably a bad choice for the root file > > system on systemd's part. You probably aren't alone in that view, but I suspect the are real advantages. Probably there is something wrong with the abstraction as different people want different things for good reasons. Changing the abstraction might be hard.... I'll sleep on it and try to provide a credible solution for autofs now that I understand the problems. Quite possibly it will just extend the current "private" etc flags to the autofs mounts... Thanks, NeilBrown > > > > > > I assume it happens when an autofs mount appears somewhere that the > > automount daemon doesn't know about, and when propagation is configured > > so that when automount mounts something on the location it *does* know > > about, the mount isn't propagated to the problem location. > > Tbh, I can't remember now. > > > > > > And access of that problem location would then block waiting for the > > automount daemon to mount something, but it never will. > > > > Is that correct? Is that the only problem? > > I think the only autofs problem is mounts can be set propagation shared. > > > > > > So if automount bind-mounts something from elsewhere over an autofs > > mount point, it doesn't want any autofs mount points is mounts below > > this to be propagated back to the origin. This is why it defaults to > > "slave". That makes sense. It would be safe for mounts to propagate > > back only of the original mount was shared or slave - be we cannot check > > or enforce that. > > I don't think there is any autofs case where a mount should be set > > propagation shared. I am talking about autofs mounts themselves > > though not the things autofs mounts for us. > > > > > > Though if the first autofs mount point were already private, then it > > should probably leave the child bind-mount as private rather than change > > it to slave. > > Yes, I agree. > > > > > > It feels like there is a lot of potential for problems if someone > > creates a bind mount from an automount-manager tree and makes it > > private, or if the original tree is private. So maybe we shouldn't > > support "private" autofs mounts. They should be shared, slave, or > > unbindable. > > I don't think we should allow autofs mounts to be set propagation > > shared, if someone wants to do this they probably don't actually > > need to do it and will very likely see a mount hang. > > > Not sure about private usage, in fact I don't think I care either > > way. Thing is users might get themselves into odd situations but > > I don't think it will lead to problems bleeding into other mount > > trees like we see with shared mount trees. > > > Clearly binding a private tree elsewhere is going to leave a tree > > of mounts that will need to be umounted manually unless it is within > > a new mount namespace. > > > The use case for bind mounting autofs mounts (well what I mean is > > actually mount namespace creation but it sounds like and looks like > > bind mounting when talking about containers) is into containers where > > they need to have the same path to work and need to be propagation > > slave for the child directories or mount point triggers that cause > > automounts to trigger that then propagate to the namespace. > > > > > > Similarly slave autofs mounts would be a problem as if they are > > bind-mounted to somewhere (or just duplicated into a new namespace). > > Changes made by automount wouldn't propagate elsewhere and so deadlocks > > could happen. > > I think we do need to distinguish between bind-mounting and mount namespace > > creation. I've previously used these interchangeably which is not right. > > Propagated mounts (I think) are cloned not bound (hehe, sounds like a > > bind mount). > > > Straight bind-mounting generally isn't useful. I'm not sure it should be > > prevented since it's usually not harmful although also not useful. Mount > > namespace creation should prevent propagation shared autofs mounts being > > included, and there should be some way to prevent any autofs mounts (trees) > > from being included, and only specifically requested mounts should be cloned > > to the target namespace. > > > But that's kindof a "never ever do this, but allow it if someone says > please" > > type thing, and I don't know how to do that, ;) > > > > > > So maybe the autofs mounts should always be either shared or unbindable. > > I agree with that. > > Not sure we care about unbindable since pure bind mounts should not cause > > harmful side effects but they aren't useful either so ... it's an open > > question. > > > > > > When autofs mounts a new filesystem on an autofs mount it can safely > > inherit from the parent. However when it bind-mounts an existing > > filesystem it needs to ensure it is at most "slave". > > > > So I can see two sensible options. > > > > 1/ The autofs mount is "shared" if parent is shared, and is > > unbindable otherwise. > > bind-mounts are "slave" if the parent is shared, or > > unbindable otherwise > > I think it's only necessary to over-ride setting the mount propagation > > shared, I don't think there's a use case for shared at all. I may be > > wrong ... time will tell. > > > > > > 2/ Everything is unbindable. This could be achieved with the "private" > > option. > > I must admit I found unbindable behavior odd. > > I played with it a bit and probably need to do so again. > > IIRC I thought it wasn't usable to prevent bind mounting. > > > > > > I guess that we still need to support "shared" with leaves bind mounts > > as shared, but with a warning that deadlocks can occur if used > > carelessly. > > Haha, did I say I really don't like propagation shared mounts ... just > > in case, I don't like mount that are propagation shared, ;) > > > Ian > >
