On Tue, Jan 30, 2024 at 2:57 PM Mike Karels wrote:
>
> On 30 Jan 2024, at 15:48, Cy Schubert wrote:
>
> > In message > om>
> > , Rick Macklem writes:
> >> On Tue, Jan 30, 2024 at 10:49=E2=80=AFAM Mike Karels
> >> wrot=
> >> e:
> >>>
> >>> On 30 Jan 2024, at 3:00, Olivier Certner wrote:
> >>>
> Hi Warner,
>
> > I strongly oppose this notion to control this from loader.conf. Root i=
> >> s
> > mounted read-only, so it doesn't matter. That's why I liked Mike's
> > suggestion: root isn't special.
>
> Then in fact there is nothing to oppose. You've just said yourself tha=
> >> t root is mounted first read-only. As Mike already said, it is remounted
> >> r=
> >> /w in userland later in the boot process. I just re-checked the code,
> >> beca=
> >> use I only had a vague recollection of all this, and can confirm.
>
> I mentioned the need to modify '/etc/loader.conf' as a possible consequ=
> >> ence, not as a goal. Given what we have established, there is no need to
> >> c=
> >> hange it at all.
>
> The root FS is thus in no way more special in the sysctl proposal than =
> >> with Mike's (assuming it doesn't rely on sysctl), this is an independent
> >> pr=
> >> operty due to the boot process design.
> >>>
> >>> With the possible exception that the sysctl mechanism might then have to
> >>> apply to mount update.
> >>>
> >>> It also seems undesirable to add a sysctl to control a value that th=
> >> e
> >>> kernel doesn't use.
> >>
> >> The kernel has to use it to guarantee some uniform behavior irrespect=
> >> ive
> >> of the mount being performed through mount(8) or by a direct call to
> >> nmount(2). I think this consistency is important. Perhaps all
> >> auto-mounters and mount helpers always run mount(8) and never deal wi=
> >> th
> >> nmount(2), I would have to check (I seem to remember that, a long tim=
> >> e ago,
> >> when nmount(2) was introduced as an enhancement over mount(2), the st=
> >> ance
> >> was that applications should use mount(8) and not nmount(2) directly)=
> >> .
> >> Even if there were no obvious callers of nmount(2), I would be a bit
> >> uncomfortable with this discrepancy in behavior.
> >>>
> >>> Based on a quick git grep, it looks like most of the things in base use
> >>> nmount(2), not mount(2). If they use mount(8), then it's not a problem
> >>> because mount(8) would be the first thing to get things right. If, by
> >>> mount helpers, you mean things like mount_nfs and mount_mfs, then mount(8=
> >> )
> >>> uses them rather than the reverse. I also don't remember any admonition
> >>> not to use nmount(2). mount(8) has a limited set of file system types th=
> >> at
> >>> it handles directly.
> >>>
> > I disagree. I think Mike's suggestion was better and dealt with POLA a=
> >> nd
> > POLA breaking in a sane way. If the default is applied universally in =
> >> user
> > space, then we need not change the kernel at all.
>
> I think applying the changes to userland only is really a bad idea. I'=
> >> ve already explained why, but going to do it again in case you missed
> >> that.=
> >> If you have counter-arguments, fine, but I would like to see them.
>
> Changing userland only causes a discrepancy between mount(8) and nmount=
> >> (2). Even if the project would take a stance that nmount(2) is not a
> >> publi=
> >> c API and mount(8) must always be used, the system call will still be
> >> there=
> >> And if it's not supposed to be used, what's the problem with changing it=
> >> as well?
> >>>
> >>> I don't think that stance has been taken; nmount(2) is certainly document=
> >> ed.
> >>> But I think that user level changes are required in both cases. First, f=
> >> or
> >>> the kernel to do the right thing, it needs to know if either noatime or a=
> >> time
> >>> has been specified explicitly, or if the default should apply. Otherwise=
> >> , the
> >>> kernel can only force noatime to be used in all cases or none, which I be=
> >> lieve
> >>> is a non-starter. Second, for anything using mount(2), the flags include=
> >> only
> >>> MNT_NOATIME, which can only include two options, not the required three. =
> >> It
> >>> would be possible to add another flag meaning to actually use the state o=
> >> f the
> >>> MNT_NOATIME flag, but that would require user-level changes. Third, if I
> >>> understand correctly, mount(8) parses the options and condenses the stand=
> >> ard
> >>> boolean options like {,no}atime into a bit, preserving the last option
> >>> specified. E.g. if the fstab lists noatime for a file system, and "mount=
> >> -o
> >>> atime ..." is given on the command line, noatime will not be included in
> >>> the kernel options. The kernel can't tell why, whether nothing was speci=
> >> fied
> >>> or the option was explicit. In theory, three states can be encoded using
> >>> nmount; options could include "atime",
