first get the "HOME" env from "/etc/passwd", if
there's no corresponding uid entry in /etc/passwd,
then set "/" as the home env.
Fixes: #1643
Signed-off-by: fupan.lfp <fupan.lfp@antfin.com>
On commit 17e9a2cff5 it was introduced a guard for the case the mount point is already
mounted. Instead of log only the mount tag ("kataShared") with this change it will print
both tag and mount point path.
Fixes: #1398
Signed-off-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
get_device_name() contains logic to wait for a specific uevent, then
extract the /dev node name from it. In future we're going to want similar
logic to wait on uevents, but using different match criteria, or getting
different information out.
To simplify this, add a wait_for_uevent() helper in the uevent module,
which takes an explicit UeventMatcher object and returns the whole uevent
found.
To make testing easier, we also extract the cut down uevent watcher from
test_get_device_name() into a new spawn_test_watcher() helper. Its used
for both test_get_device_name() and a new test_wait_for_uevent() amd will
be useful for more tests in future.
fixes#1484
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
get_device_name() looks at kernel uevents to work out the device name for
a given PCI (usually) address. However, when we call it we can't know if
the uevent we're interested in has already happened (in which case it will
have been recorded in Sandbox::uevent_map) or yet to come, in which case
we need to register to watch it.
However, we currently match differently against past and future events.
For past events we simply look for a sysfs path including the address, but
for future events we use a complex bit of logic in the is_match() closure.
Change it to use the exact same matching logic in both cases.
fixes#1397
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Currently, Sandbox::uevent_watchers lists uevents to watch for by a
"device address" string. This is not very clearly defined, and is
matched against events with a rather complex closure created in
Uevent::process_add().
That closure makes a bunch of fragile assumptions about what sort of
events we could ever be interested in. In some ways it is too
restrictive (requires everything to be a block device), but in others
is not restrictive enough (allows things matching NVDIMM paths, even
if we're looking for a PCI block device).
To allow the clients more precise control over uevent matching, we
define a new UeventMatcher trait with a method to match uevents. We
then have the atchers list include UeventMatcher trait objects which
are used directly by Uevent::process_add(), instead of constructing
our match directly from dev_addr.
For now we don't actually change the matching function, or even use
multiple different trait implementations, but we'll refine that in
future.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The event matching logic in Uevent::process_add() is split into two parts.
The first checks if we care about the event at all, the second checks
whether the event is relevant to a particular watcher.
However, we're going to be adding more types of watchers in future, which
will make the global filter too restrictive. Fold the two bits of logic
together into a per-watcher filter function.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Uevent::process() is a bit oddly organized. It treats the onlining of
hotplugged memory as the "default" case, although that's quite specific,
while treating the handling of hotplugged block devices more like a special
case, although that's pretty close to being very general.
Furthermore splitting Uevent::is_block_add_event() from
Uevent::handle_block_add_event() doesn't make a lot of sense, since their
logic is intimately related to each other.
Alter the code to be a bit more sensible: first split on the "action" type
since that's the most fundamental difference, then handle the memory
onlining special case, then the block device add (which will become a lot
more general in future changes).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Sandbox:dev_watcher is a HashMap from a "device address" to a channel used
to notify get_device_name() that a suitable uevent has been found.
However, "device address" isn't well defined, having somewhat different
meanings for different device/event types. We never actually look up this
HashMap by key, except to remove entries.
Not looking up by key suggests that a map is not the appropriate data
structure here. Furthermore, HashMap imposes limitations on the types
which will prevent some future extensions we want.
So, replace the HashMap with a Vec<Option<>>. We need the Option<> so that
we can remove entries by index (removing them from the Vec completely would
hange the indices of other entries, possibly breaking concurrent work.
This does mean that the vector will keep growing as we watch for different
events during startup. However, we don't expect the number of device
events we watch for during a run to be very large, so that shouldn't be
a problem. We can optimize this later if it becomes a problem.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Currently, when Uevent::handle_block_add_event() receives an event matching
a registered watcher, it reports the /dev node name from the event back
to the watcher.
This changes it to report the entire uevent, not just the /dev node name.
This will allow various future extensions. It also makes the client side
of the uevent watching - get_device_name() - more consistent between its
two paths: finding a past uevent in Sandbox::uevent_map() or waiting for
a new uevent via a watcher.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Sandbox::pci_device_map contains a mapping from sysfs paths to /dev entries
which is used by get_device_name() to look up the right /dev node. But,
the map only supplies the answer if the uevent for the device has already
been received, otherwise get_device_name() has to wait for it.
However the matching for already-received and yet-to-come uevents isn't
quite the same which makes the whole system fragile.
In order to make sure the matching for both cases is identical, we need the
already-received side to store the whole uevent to match against, not just
the sysfs path and device name.
So, rename pci_device_map to uevent_map and store the whole uevent there
verbatim.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
In Kata 1.x, both the sysToDevMap and the deviceWatchers are in the sandbox
structure. For some reason in Kata 2.x, the device watchers have moved to
a separate global variable, GLOBAL_DEVICE_WATCHER.
This is a bad idea: apart from introducing an extra global variable
unnecessarily, it means that Sandbox::pci_device_map and
GLOBAL_DEVICE_WATCHER are protected by separate mutexes. Since the
information in these two structures has to be kept in sync with each other,
it makes much more sense to keep them both under the same single Sandbox
mutex.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
For the case of virtio-blk PCI devices, when matching uevents we create
a pci_p temporary. However, we build it incorrectly: the dev_addr values
we use for PCI devices are a relative sysfs paths from the PCI root to the
device in question *including an initial /*. But when we construct pci_p
we add an extra /, meaning the resulting path will *not* match properly.
AFAICT the only reason we got away with this is because in practice the
virtio-blk devices where discovered by the kernel before we looked for them
meaning the loosed matching in get_device_name() was used, rather than the
pci_p logic in handle_block_add_event().
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The current test_get_device_name(), ported from Kata 1.x doesn't really
reflect how the function is used in practice. The example path appears
to be for a virtio-blk device, but it's an s390 specific variant, not a
PCI device. The s390 form isn't actually supported by any of the existing
users of get_device_name().
Change it to a plausible virtio-blk-pci style path to better test how
get_device_name() will actually be used in practice.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The only right way to shutdown pipe is drop it
Otherwise PipeStream will conflict with its twins
Because they both have the same fd, and both registered.
Fixes: #1614
Signed-off-by: Tim Zhang <tim@hyper.sh>
Kata 1.x had a testcase for the equivalent getDeviceName function in Go,
this adapts it to Rust and adds it to Kata 2.x.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Rust 1.51 appears to have added a new warning in anticipation of Rust 2021,
which requires the format string for panic!()s (including via the various
assert!() macros) to be a string literal. This triggers quite a few times
in the agent code. This patch fixes them.
fixes#1626
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
For k8s emptyDir volume, a specific fsGroup would
be set for it, thus guest should get this fsGroup
from runtime and set it properly on the emptyDir volume
in guest.
Fixes: #1580
Signed-off-by: fupan.lfp <fupan.lfp@antfin.com>
Instead of having different VERSION files spread accross the project,
let's always use the one in the topsrcdir and remove all the others,
keeping only a synlink to the topsrcdir one.
Fixes: #1579
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
statfs f_types are long on most architectures, but not on s390x, where
they are uint. Following the fix in rust-lang/libc at
https://github.com/rust-lang/libc/pull/1999, the custom defined
PROC_SUPER_MAGIC must be updated in a similar way.
Fixes: #1204
Signed-off-by: Jakob Naucke <jakob.naucke@ibm.com>
Move the signal handling code into a new module and refactor into the
main handler and a new SIGCHLD handling function to make the code
simpler and easier to understand.
Also added a unit test for shutdown.
Signed-off-by: James O. D. Hunt <james.o.hunt@intel.com>
Make changes to logger thread to allow the logger to be replaced with
a NOP logger (required for agent shutdown).
Signed-off-by: James O. D. Hunt <james.o.hunt@intel.com>
The agent doesn't normally shutdown: it doesn't need to be as it is
killed *after* the workload has finished. However, a clean and ordered
shutdown sequence is required to support agent tracing, since all trace
spans need to be completed to ensure a valid trace transaction.
Enable a controlled shutdown by allowing the main threads (tasks) to be
stopped.
To allow this to happen, each thread is now passed a shutdown channel
which it must listen to asynchronously, and shut down the thread if
activity is detected on that channel.
Since some threads are created for I/O and since the standard `io::copy`
cannot be stopped, added a new `interruptable_io_copier()` function
which shares the same semantics as `io::copy()`, but which is also
passed a shutdown channel to allow asynchronous I/O operations to be
stopped cleanly.
Fixes: #1531.
Signed-off-by: James O. D. Hunt <james.o.hunt@intel.com>
Encapsulate the logic for handling the task that displays logger output
into a new function to simplify the code and remove another anonymous
async block.
Signed-off-by: James O. D. Hunt <james.o.hunt@intel.com>
Maintain a list of tasks and wait on them all before main returns.
This is preparatory work for the agent shutdown: all tasks that are
started need to be added to the list. This aggregation makes it easier
to identify what needs to stop before the agent can exit cleanly.
Signed-off-by: James O. D. Hunt <james.o.hunt@intel.com>
Move most of the main logic into a separate async function. This makes
the code clearer and avoids the anonymous async block.
Signed-off-by: James O. D. Hunt <james.o.hunt@intel.com>
Return a guard variable from `create_logger()` which the caller can
implicitly drop to guarantee that all threads started by the async log
drain are stopped.
This fixes a long-standing bug [1] whereby the agent could panic with
the following error, generated by the `slog` logging crate:
```
slog::Fuse Drain: Custom { kind: Other, error: "serde serialization error: Bad file descriptor (os error 9)" }
```
[1] - See https://github.com/kata-containers/kata-containers/issues/171.
Signed-off-by: James O. D. Hunt <james.o.hunt@intel.com>
Fixed the `assert_error!()` test macro so that it correctly handles the
scenario where the test expects an error, but the actual result was `Ok`
(no error).
Signed-off-by: James O. D. Hunt <james.o.hunt@intel.com>
It's better to get the online cpus from
"/sys/devices/system/cpu/online" instead of from
cpuset cgroup, cause there would be an latency
between one cpu online and present in the root
cpuset cgroup.
Fixes: #1536
Signed-off-by: fupan.lfp <fupan.lfp@antfin.com>
