Fixes a compiler warning when building with plugin enabled.
BUG=None
TEST='cargo build --features=plugin'
Change-Id: Icbd731b249089d271caca17e192b7a539ba7219c
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1401124
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
The crosvm run --plugin option was behind #[cfg(feature = "plugin")],
but the recently-added --plugin-root and --plugin-mount were not. Add
feature checks around those options as well so that they are only
enabled when the plugin feature is enabled (and so they don't show up in
crosvm run -h for a non-plugin build).
Also allow dead code in struct BindMount, since this is only used for
plugin-enabled builds.
We could wrap all of the plugin-related command line parsing code with
feature checks instead, but that adds a lot of clutter and makes the
code harder to read.
BUG=None
TEST='cargo build' and 'cargo build --features=plugin'
Change-Id: Ieb240cfc55b8cad64748fe39c7de5faa58f1a26c
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1401123
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
The plugin process may need access to writable directories where it can
store its state. Add a plugin-mount option to specify paths that should
be mounted into the plugin's jail.
BUG=b:80150167
TEST=run plugin_adder and plugin_net_config
Change-Id: I2c87d19ab67edaaf99a2cfea6872d3531101d260
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1341106
Add support for having the tap fd be passed in on the command line the
same way we do for linux.
BUG=b:80150167
TEST=run plugin_net_config (after changing the expected ip/netmask/mac
address appropriately)
Change-Id: Ic81b167b7bb2caa71ce5931921b87d9eeca69af9
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1341105
We use the tap device interface name in some ioctls. When we are
creating a Tap struct from a raw fd make sure that we also grab the
interface name so that these ioctls don't fail later.
BUG=b:80150167
TEST=run the plugin_net_config test
Change-Id: Ic308ebd55d0545c1b445fc6abdf017fdc7ab594b
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1341104
When minijail is given a uid/gid map but is not given a uid/gid to
change to, it will default to setting the uid/gid inside the new user
namespace to root. This works fine if crosvm is launched as root but
fails miserably otherwise since we only map the current euid/egid into
the user namespace (and so 0 is not a valid uid/gid).
We would normally want to fix this by having minijail change its uid/gid
to the current euid/egid. However, because of the way minijail is set
up it only attempts to enter a new net namespace after exec-ing the
program to be jailed. Entering a new net namespace requires
CAP_SYS_ADMIN in the current namespace and this capability gets dropped
the moment we switch to a non-root user.
So to deal with this we map root inside the namespace to the crosvm user
outside the namespace. This allows us to enter a new net namespace and
we already tell minijail to drop all caps so the plugin will not have
any caps when it actually runs.
BUG=b:80150167
TEST=run plugin_adder
Change-Id: I10c9e6bef859fd787dd6e17d5cf2ff3e552501fb
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1341103
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Mounting a filesystem with the `exec` flag has required CAP_SYS_ADMIN in
the init namespace since February 2018.
BUG=b:80150167
TEST=run the plugin_adder test plugin
Change-Id: Ibf3fdf52314d15f0154742e1b6c11f73155d2d59
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1341102
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
validate_raw_fd is needed for the plugin crate. Move it into a common
location so that it can be shared by both the linux and plugin code.
BUG=b:80150167
TEST=manual
Change-Id: I427e10716e75b2619fd0f4ba6725fa40446db4af
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1341101
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The expressions that are being converted to usize are already naturally
usize without the casts.
BUG=None
TEST=build_test
Change-Id: Ifb8553e20a3d57cb5edb38dcfcd423edf12a1a28
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1396483
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The balloon socket interface was changed to take an absolute number of
pages in a u64 in commit 448516e3f9 ("balloon: Implement device
policy"), but the 'crosvm balloon' command wasn't updated to match. Fix
the crosvm front-end to send a u64 as expected by the command socket
reader instead of the i32 it was sending previously, and change the
parameter to bytes instead of pages to match the receiving end as well.
BUG=None
TEST=crosvm balloon a running VM to various sizes
Change-Id: I265bee55c06809de7559a79a5eb6d0d094533993
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1394157
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
This allows more type-safe usage of RawFds (preventing confusion with other c_ints) and provides a lightweight type that is usable in arguments to methods that take parameters of type AsRawFd.
BUG=None
TEST=Built.
Change-Id: Ibdeb03b0e759577385b05acb25ce76d51f2188c6
Reviewed-on: https://chromium-review.googlesource.com/1396495
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Miriam Zimmerman <mutexlox@chromium.org>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This will allow the disk size to be changed from the worker thread
during resize operations.
BUG=chromium:858815
TEST=build_test
Change-Id: I0b2e1a057831856b44f19c2ba30b4dd1ffdeafc3
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1394151
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This will allow the config space to change when a disk resize takes
place.
BUG=chromium:858815
TEST=Boot Termina on kevin
Change-Id: I115a7923097c3fd1f31535e9c48c87caa32f99d7
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1394150
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
We won't support resizing a QcowFile for now, since it would require
resizing refcount and L1 tables.
BUG=chromium:858815
TEST=build_test
Change-Id: Ia108e07be8b06b6fbe81838831a8ecbffdfb341c
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1394149
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Generalize file_sync into file_traits so that we can add another
wrapper, this time for the set_len() method implemented directly on
File. This will also be implemented on QcowFile.
BUG=chromium:858815
TEST=build_test
Change-Id: I43fbd1968a844c8cac359973a63babcc26942204
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1394148
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Split sub-crates under crosvm root directory into several independent
workspaces for adding ebuild files for those crates.
data_model and sys_util could only be built by emerge after creating
their ebuilds.
BUG=chromium:916921
TEST='emerge-eve crosvm'
TEST=Run 'cargo build' under crosvm directory
Change-Id: I2dddbbb7c7344e643183a5885e867f134b299591
Reviewed-on: https://chromium-review.googlesource.com/1385972
Commit-Ready: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: Chih-Yang Hsia <paulhsia@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Changes in this CL:
- Crate-level documentation for bit_field crate!
- Use absolute paths within generated code so that the caller is no
longer required to have various implementation details from the
bit_field crate in scope.
- Check that the total number of bits is a multiple of 8. Previously, it
would generate compilable code that panicked when invoking accessors.
- Provide B0 .. B64 as shorthand for BitField0 .. BitField64.
- Use `bool` as the bool specifier rather than BitFieldBool.
- Disallow BitFieldSpecifier impls outside the bit_field crate.
- Simplify declaration of the BitFieldN types by replacing the recursive
macro_rules with a simpler procedural macro.
TEST=`cargo test` in bit_field and in bit_field_derive
Change-Id: Ica9347bc89901de85f74366edd038fb5d8042ee6
Reviewed-on: https://chromium-review.googlesource.com/1382578
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Jingkui Wang <jkwang@google.com>
On sandboxed will be invoked when the device is sandboxed. Device
implementation could do initialization here. It does not need to return
fd opened here to keep fds.
BUG=None
TEST=local build and run
Change-Id: I42c2b3cae3a87dd54f02e77b8cd10766309a0770
Reviewed-on: https://chromium-review.googlesource.com/1327513
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
make open_fd patch optional. if sandboxed-libusb feature is not selected,
open_fd is not required.
In this case, the code must have access to /dev/bus/usb, and not
external fd is needed.
BUG=chromium:831850
TEST=cargo test
Change-Id: I21fa87dd15d08a03c2fe2b190559abbe6f63dcd5
Reviewed-on: https://chromium-review.googlesource.com/1375019
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
BitFieldSpecifiers are now generated by macros.
Can use BitFieldBool to specify a bool field.
BUG=chromium:831850
TEST=local cargo build/test
Change-Id: Id6b4a773ab612cea39ba811c3ec1da212b618ba2
Reviewed-on: https://chromium-review.googlesource.com/1356912
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Every implementation of Fn also implements FnMut, so if some callback
can be passed to GuestMemory::with_regions then it could also have been
passed to GuestMemory::with_regions_mut.
This CL removes GuestMemory::with_regions and renames with_regions_mut
to with_regions.
TEST=cargo check
Change-Id: Ia4f168ff4eb4d45a5ee8f9413821ae244fb72ee1
Reviewed-on: https://chromium-review.googlesource.com/1378688
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
The `cargo fmt` preupload check will be replaced with a rustfmt check
that does not require projects to opt in.
This reverts commit 35bac991e6.
BUG=chromium:908640
TEST=`repo upload`
Change-Id: I08f081ef7b889542a6d95fe3f13cdc480759207c
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1376070
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
In order to properly send dmabufs over the wayland protocol, accurate
buffer metadata is needed in the guest. This change plumbs information
from minigbm allocations to the guest using a virtio-gpu response.
BUG=875998
TEST=wayland-simple-egl
Change-Id: I5c80d539bc7757c302ad7adf56f5d3b011304617
Reviewed-on: https://chromium-review.googlesource.com/1227054
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: David Riley <davidriley@chromium.org>
We updated the production toolchain from 1.30 to 1.31 in CL:1366446.
This CL does the same upgrade for the local developer toolchain and
Kokoro.
The relevant changes are in rust-toolchain and kokoro/Dockerfile.
The rest are from rustfmt.
TEST=cargo fmt --all -- --check
TEST=as described in kokoro/README.md
Change-Id: I3b4913f3e237baa36c664b4953be360c09efffd4
Reviewed-on: https://chromium-review.googlesource.com/1374376
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This change uses the resource bridge between virtio-gpu and virtio-cpu
to send resources over the host wayland connection that originated from
the virtio-gpu device. This will help support gpu accelerated wayland
surfaces.
BUG=chromium:875998
TEST=wayland-simple-egl
Change-Id: I3340ecef438779be5cb3643b2de8bb8c33097d75
Reviewed-on: https://chromium-review.googlesource.com/1182793
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Add the minimal amount of functionality needed for audio threads that
need to run with real time priority.
Change-Id: I7052e0f2ba6b9179229fc4568b332952ee32f076
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1366542
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
This CL removes 300 lines of parsing code and 200 lines of tests of
parsing code by using the parsers provided by Syn, which we already use
in implementing our other custom derives.
TEST=cargo test poll_token_derive
TEST=cargo check crosvm
Change-Id: Ie2743b1bbb1b374326f9845fc37fc578b178c53d
Reviewed-on: https://chromium-review.googlesource.com/1365112
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This depends on the `assertions` crate added in CL:1366819.
`const_assert!(boolean expression)` is a compile-time assertion that
fails to compile if the expression is false.
TEST=`cargo check` each of the modified crates
Change-Id: I559884baf2275b1b506619693cd100a4ffc8adcd
Reviewed-on: https://chromium-review.googlesource.com/1368364
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
A static assertion is particularly appropriate when unsafe code relies
on two types to have the same size, or on some type to have a particular
size. This is a pattern I observed in USB code, for example:
ff7068402e/devices/src/usb/xhci/xhci_abi_schema.rs (522)
EXAMPLE:
extern crate assertions;
use assertions::const_assert;
fn main() {
const_assert!(std::mem::size_of::<String>() == 24);
}
EXAMPLE THAT FAILS TO COMPILE:
extern crate assertions;
use assertions::const_assert;
fn main() {
// fails to compile:
const_assert!(std::mem::size_of::<String>() == 8);
}
FAILURE LOOKS LIKE:
error[E0271]: type mismatch resolving `<[(); 0] as assertions::Expr>::Value == assertions::True`
--> src/main.rs:5:5
|
5 | const_assert!(std::mem::size_of::<String>() == 8);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `assertions::True`, found struct `assertions::False`
TEST=`cargo test` the new crate
Change-Id: I6abe36d5a6a4bd4acb1a02e3aa7c1ece5357f007
Reviewed-on: https://chromium-review.googlesource.com/1366819
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This CL adds a procedural macro to generate functions for converting a
primitive integer into the corresponding variant of an enum.
Loosely based on https://docs.rs/enum-primitive-derive but implemented
against a newer version of Syn and without the dependency on num-traits.
The generated function is named `n` and has the following signature:
impl YourEnum {
pub fn n(value: Repr) -> Option<Self>;
}
where `Repr` is an integer type of the right size as described in more
detail below.
EXAMPLE
extern crate enumn;
#[derive(PartialEq, Debug, enumn::N)]
enum Status {
LegendaryTriumph,
QualifiedSuccess,
FortuitousRevival,
IndeterminateStalemate,
RecoverableSetback,
DireMisadventure,
AbjectFailure,
}
fn main() {
let s = Status::n(1);
assert_eq!(s, Some(Status::QualifiedSuccess));
let s = Status::n(9);
assert_eq!(s, None);
}
SIGNATURE
The generated signature depends on whether the enum has a `#[repr(..)]`
attribute. If a `repr` is specified, the input to `n` will be required
to be of that type.
#[derive(enumn::N)]
#[repr(u8)]
enum E {
/* ... */
}
// expands to:
impl E {
pub fn n(value: u8) -> Option<Self> {
/* ... */
}
}
On the other hand if no `repr` is specified then we get a signature that
is generic over a variety of possible types.
impl E {
pub fn n<REPR: Into<i64>>(value: REPR) -> Option<Self> {
/* ... */
}
}
DISCRIMINANTS
The conversion respects explictly specified enum discriminants. Consider
this enum:
#[derive(enumn::N)]
enum Letter {
A = 65,
B = 66,
}
Here `Letter::n(65)` would return `Some(Letter::A)`.
TEST=`cargo test` against the new crate
Change-Id: I4286a816828c83507b35185fe497455ee30ae9e8
Reviewed-on: https://chromium-review.googlesource.com/1365114
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This CL adds a crate `sync` containing a type sync::Mutex which wraps
the standard library Mutex and mirrors the same methods, except that
they panic where the standard library would return a PoisonError. This
API codifies our error handling strategy around poisoned mutexes in
crosvm.
- Crosvm releases are built with panic=abort so poisoning never occurs.
A panic while a mutex is held (or ever) takes down the entire process.
Thus we would like for code not to have to consider the possibility of
poison.
- We could ask developers to always write `.lock().unwrap()` on a
standard library mutex. However, we would like to stigmatize the use
of unwrap. It is confusing to permit unwrap but only on mutex lock
results. During code review it may not always be obvious whether a
particular unwrap is unwrapping a mutex lock result or a different
error that should be handled in a more principled way.
Developers should feel free to use sync::Mutex anywhere in crosvm that
they would otherwise be using std::sync::Mutex.
TEST=boot linux
Change-Id: I9727b6f8fee439edb4a8d52cf19d59acf04d990f
Reviewed-on: https://chromium-review.googlesource.com/1359923
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
During runtime, we track unreferenced clusters (via unref_clusters and
avail_clusters) and reuse them before extending the disk image.
However, across boots, we did not previously recover the list of
unreferenced clusters, so the disk file could grow beyond the range that
the reference table count represent. This patch adds a boot-time scan
for all unreferenced clusters so that they get reused.
BUG=chromium:899273
TEST=Boot with qcow2 image, fill the disk with dd, delete the dd'd file,
refill with dd, and so on, repeatedly. Ensure that the disk image does
not grow beyond the expected max size and that no clusters beyond the
size of the refcount table are used.
Change-Id: Idd21b08bb4c55b8244e7ecaccafc4ccc46b7b17a
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1327822
Reviewed-by: Dylan Reid <dgreid@chromium.org>
I noticed this questionable loop that never loops in CL:1357700. Purely
guessing as to what it was supposed to do -- I have not tested this
codepath.
TEST=cargo check
Change-Id: I4560b80f080112a78adf440a663341f4fb0f1070
Reviewed-on: https://chromium-review.googlesource.com/1359010
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
The `while sig_ok` in the original code suggests that `sig_ok` would be mutated
by the loop body, but it was not. Really `while sig_ok` was being used to mean
`if sig_ok { loop { ... } }`, with breaks to exit the loop body.
I replaced `while sig_ok` with `if sig_ok` containing `loop`. Since this is an
extra layer of indentation, I removed two layers of indentation by flattening a
a nested match so the new code is overall less indented than before.
Clippy flags such loops in which the loop condition never changes as high
confidence of being a bug or at least misleading:
https://rust-lang.github.io/rust-clippy/master/index.html#while_immutable_condition
TEST=run linux
Change-Id: Ib925bbedbdda11bb50e47f8dd55c2f5af7c53698
Reviewed-on: https://chromium-review.googlesource.com/1357699
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Because the alignment of the data passed into from_slice is not checked,
it is very easy to pass in unaligned data that will get dereferenced at
a later point in the code. On ARM, this will lead to a SIGBUS.
This change adds an alignment check to prevent getting a signal.
Instead, the caller will get `None`.
BUG=chromium:900962
TEST=cargo test -p data_model
Change-Id: I7a0f835f7d0ffd8c3d44bbcd80a790027f652bc9
Reviewed-on: https://chromium-review.googlesource.com/1343989
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Hopefully the changes are self-explanatory and uncontroversial. This
eliminates much of the noise from `cargo clippy` and, for my purposes,
gives me a reasonable way to use it as a tool when writing and reviewing
code.
Here is the Clippy invocation I was using:
cargo +nightly clippy -- -W clippy::correctness -A renamed_and_removed_lints -Aclippy::{blacklisted_name,borrowed_box,cast_lossless,cast_ptr_alignment,enum_variant_names,identity_op,if_same_then_else,mut_from_ref,needless_pass_by_value,new_without_default,new_without_default_derive,or_fun_call,ptr_arg,should_implement_trait,single_match,too_many_arguments,trivially_copy_pass_by_ref,unreadable_literal,unsafe_vector_initialization,useless_transmute}
TEST=cargo check --features wl-dmabuf,gpu,usb-emulation
TEST=boot linux
Change-Id: I55eb1b4a72beb2f762480e3333a921909314a0a2
Reviewed-on: https://chromium-review.googlesource.com/1356911
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
These duplicate the doc comments found in `trait PciDevice`. I am
removing them because a sensible reader would already assume that they
have fallen out of sync with the doc comments in the trait, and thus
refer to the trait definition anyway.
TEST=none
Change-Id: Id86936a6f2a1b6c78a000b107bb4fc8ed78e40f9
Reviewed-on: https://chromium-review.googlesource.com/1355350
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Usb emulation depend on libusb. This path install libusb-1.0 to the
container.
BUG=chromium:831850
TEST=local build docker and run kokoro_simulator.sh
Change-Id: I2fa406914bf7cfe9a790ec945e15eb387e964d8e
Reviewed-on: https://chromium-review.googlesource.com/1356766
Commit-Ready: Jingkui Wang <jkwang@google.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
