This commit fixes a ceiling bug where the ceiling of a ready queue will be
incorrectly computed. The analysis was not including the priority of the system
timer interrupt (`SysTick`) in the analysis resulting in a priority ceiling
lower than what's required for memory safety which led to data races.
The bug can be observed in the following program:
``` rust
#[rtfm::app(device = /* .. */)]
const APP: () = {
#[init]
fn init() {
// ..
}
#[task(priority = 2)]
fn foo(x: i32) {
// ..
}
#[task(priority = 1, spawn = [foo], schedule = [foo])]
fn bar() {
// ..
}
extern "C" {
fn EXTI0();
fn EXTI1();
}
};
```
Here the framework chooses a priority of `2` for the `SysTick` interrupt
(because it matches the priority of the `schedule`-able task `foo`).
Both `SysTick` and `bar::Spawn.foo` need to access the ready queue (which, in
this case, stores the messages sent to task `foo`) but the framework doesn't
account for the priority of `SysTick` (`2`) and chooses a priority ceiling of
`1` for the ready queue (because it matches the priority of task `bar` which can
spawn `foo`).
The result is that `bar::Spawn.foo` modifies the ready queue *without* a
critical section (because `bar`'s priority matches the priority ceiling of the
ready queue) which is wrong because `SysTick` (priority = `3`) can also modify
the ready queue.
170: check task priority at compile time r=TeXitoi a=japaric
before we were checking the priority at runtime. The compile time error message
when the priority is too high is kind of awful though.
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
158: implement RFC #128: #[interrupt(binds = ..)] r=korken89 a=japaric
closes#128
r? @korken89 or @TeXitoi
suggestions for tests are welcome! (2 of the 3 tests I added hit bugs in my implementation)
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
159: reject duplicate arguments in #[interrupt] and #[exception] r=TeXitoi a=japaric
This program was being accepted:
``` rust
#[task(
capacity = 1,
capacity = 2,
priority = 1,
priority = 2,
)]
fn foo() {}
```
now it will trigger a compiler error
r? @korken89 || @TeXitoi
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
This program was being accepted:
``` rust
#[task(
capacity = 1,
capacity = 2,
priority = 1,
priority = 2,
)]
fn foo() {}
```
now it will trigger a compiler error
153: add "nightly" feature; replace hint::unreachable_unchecked with a panic r=korken89 a=japaric
this implements the action plan described in #149
to give you a sense of the overhead of this change: it has increased the binary
size of some of our examples by up to 10% but this is mainly from pulling in a
panic handler that does formatting
r? @korken89
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
151: make builds reproducible r=japaric a=japaric
This is a rebased and augmented version of #132. With this PR both dev and release builds that do not use the owned-singleton stuff become reproducible. (I haven't really bothered to make owned-singleton reproducible since [lifo] is way more ergonomic than [alloc-singleton] and will eventually make its way into heapless).
[lifo]: https://github.com/japaric/lifo
[alloc-singleton]: https://crates.io/crates/alloc-singleton
Thanks @hugwijst for doing the bulk of the work!
closes#132
Co-authored-by: Hugo van der Wijst <hvanderwijst@tesla.com>
Co-authored-by: Hugo van der Wijst <hugo@wij.st>
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
