So you can use Arc<Mutex<T>> for thread-safe shared mutable data. It also supports sharing mutable data between threads via atomics or without any synchronization at all via the standard reference safety system which enforces that mutable references do not alias anything else.
Conversation
So for example you can divide up an array into non-overlapping mutable slices (pointer + length views) sent to different threads with their lifetimes constrained by the compiler to not outlive the data. It prevents data races (not higher level race conditions) in the type system.
2
1
Things like that are decent initial step but as programmer with kernel background, not picking a fight here, type systems can be abused by inexperienced programmers. Sometimes type systems aren't the most direct or sustainable way of writing that type of code
2
Linux kernel driver layers can have rather complicated nested structures. Some are a hybrid of of two subsystems like USB and ALSA (audio). Both have smaller structures inside them per each subsystems. In the case of a class compliant USB audio driver, both subsystems 1/
2
This is just a bad driver model. There's no reason for a driver to have any complex data structures or structure lifetimes. Hardware is highly finite and static.
2
This Tweet was deleted by the Tweet author. Learn more
What do you claim a driver needs dynamic object relationships for?
This Tweet was deleted by the Tweet author. Learn more
Sharing actual list (including access to pointers) with hardware is unsafe, bogus to do. Sharing the data buffer space does not require any complex data structures. Storage for that should be allocated and managed by OS infrastructure outside of the driver.
1
1
The driver can read and sanity check that kind of data. The Linux kernel has a lot of drivers that are insane enough to even put function pointers inside areas where the hardware has DMA access. Linux screws up IOMMU isolation quite a bit even without taking bugs into account.
1
1
As in never directly use that kind of data without first copying it out and sanity checking the copy. It's a common anti-pattern in the drivers to trust the hardware completely or to do racy checks where they sanity check it but then use the memory the driver can write to.
It's not treated with anything close to the same care that is taken for kernel <-> userspace which is far from good enough and required hardware mitigations (SMEP/SMAP, PXN/PAN) largely to cope with the inability to safely (for the kernel side) abstract userspace access in C.
1
Hard to say. It really depends on the scenario and what kind of driver it might be. Copying potentially stale data and validating before use isn't a convention typically done in Linux kernel
2
It's not stale data unless the device is evil but that does matter. Lots of the drivers definitely put their data structures into memory that the driver writes to with DMA (even including function pointers in some cases, but that's not required for it to be a code execution bug).
1
Show replies
Right. You're talking about what Linux does. I'm talking about what actually makes sense for operating systems/drivers.
2