Page MenuHomeFreeBSD

Kernel environments: use any and all provided environments, evict hintmode and envmode
ClosedPublic

Authored by kevans on Jun 21 2018, 3:38 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Nov 26, 1:37 PM
Unknown Object (File)
Sep 26 2024, 1:58 PM
Unknown Object (File)
Sep 25 2024, 1:35 PM
Unknown Object (File)
Sep 23 2024, 12:21 AM
Unknown Object (File)
Sep 22 2024, 1:40 PM
Unknown Object (File)
Sep 22 2024, 4:33 AM
Unknown Object (File)
Sep 21 2024, 8:08 PM
Unknown Object (File)
Sep 20 2024, 7:52 AM

Details

Summary

(This one I'll actually let sit for a longer period of time)

At the moment, hintmode and envmode are used to indicate whether static hints or static env have been provided in the kernel config(5) and the static versions are mutually exclusive with loader(8)-provided environment. hintmode *can* be reconfigured later to pull from the dynamic environment, thus taking advantage of the loader(8) or post-kmem environment setting.

This changeset fixes both problems at once to move us from a semi-confusing state to a consistent state: if an environment file, hints file, or loader(8) environment are provided, we use them in a well-known order of precedence:

  • loader(8) environment
  • static environment
  • static hints file

Once the dynamic environment is setup this becomes a moot point. The loader(8) and static environments are merged (respecting the above order of precedence), and the static hints are merged in on an as-needed basis after the dynamic environment has been setup.

Hints lookup are changed to respect all of the above. Before the dynamic environment is setup, lookups use the above-mentioned order and fallback to the next environment if a matching hint is not found. Once the dynamic environment is setup, that is used on its own since it captures all of the above information plus any dynamic kenv settings that came up later in boot.

The following tangentially related changes were made to res_find:

  • A hintp cookie is now passed in so that related searches continue using the chain of environments (or dynamic environment) without relying on global state
  • All three environments will be searched if they actually have valid hints to use, rather than just choosing the first environment that actually had a hint and rolling with that only

The hintmode sysctl has been ripped out.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 17612

Event Timeline

kevans edited the summary of this revision. (Show Details)

Add back in the ability to specify static_env.disabled and static_hints.disabled. The reimplementation of these follows suit with how we treat environments in the new age- static_hints.disabled may be specified in either static_env or loader(8) env, and static_env.disabled may only be specified in loader(8) env.

I intend to commit this by the end of next week (July 6-8 time frame) without any strong objections, given the lack of any outcry from my e-mail to -arch/-embedded.

I don't see anything that's going to cause us obvious problems on BERI.

sys/kern/kern_environment.c
319

Shouldn't there be a realloc if prevlen < len - 1?

Add realloc missed in previous revision

sys/kern/kern_environment.c
319

Whoops, indeed. =) Expanded my local test setup for that, and added a check for kenvp[pos] == NULL since nothing here seemed to previously care if the allocation actually failed.

*sigh*

Avoid reallocation if we're looking at a same-size replacement.

brooks added inline comments.
sys/kern/kern_environment.c
335

Since you're using M_WAITOK this could probably be a panic.

This revision is now accepted and ready to land.Jun 25 2018, 6:53 PM

Looks OK to me.

sys/kern/kern_environment.c
335

At most this is a kassert, no?
We cant fail the alloc above.

sys/kern/kern_environment.c
335

Right, I seem to have mixed up my flags internally... I'll remove this before commit (since it's otherwise harmless) unless further changes are required here.

kevans added a subscriber: cperciva.

Some relatively minor issues:

  • The logic for static_env.disabled was backwards
  • Initializing the dynamic env now uses the first value for a variable that it finds, and any later assignments of the same value are ignored. This is to match how searching the static environment in the kernel works so that we get consistent results between the static environment and the dynamic environment. config(8) should setup the static environment for us in such a way that a later assignment to a variable overrides an earlier assignment.
  • In rS273487. @cperciva started zero'ing out the static environment as it filled the dynamic environment to avoid leaking data from the kernel environment. I've extended this cleaning to zero out even the skipped entries to eradicate all traces of the static environment once we've provisioned the dynamic one.
This revision now requires review to proceed.Jun 26 2018, 1:36 PM
This revision was not accepted when it landed; it landed in state Needs Review.Jul 5 2018, 4:26 PM
This revision was automatically updated to reflect the committed changes.