diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index 618591c89..4f975d375 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -27,6 +27,7 @@
     - [Integration testing](./tests/integration.md)
         - [Crater](./tests/crater.md)
         - [Fuchsia](./tests/fuchsia.md)
+        - [Rust for Linux](./tests/rust-for-linux.md)
     - [Performance testing](./tests/perf.md)
     - [Suggest tests tool](./tests/suggest-tests.md)
 - [Debugging the compiler](./compiler-debugging.md)
diff --git a/src/tests/integration.md b/src/tests/integration.md
index ff2d44742..1eddf7ce3 100644
--- a/src/tests/integration.md
+++ b/src/tests/integration.md
@@ -25,7 +25,7 @@ Integration jobs build large open-source Rust projects that are used as
 regression tests in CI. Our integration jobs build the following projects:
 
 - [Fuchsia](fuchsia.md)
-- Linux kernel
+- [Rust for Linux](rust-for-linux.md)
 
 ## A note about terminology
 
diff --git a/src/tests/rust-for-linux.md b/src/tests/rust-for-linux.md
new file mode 100644
index 000000000..148638365
--- /dev/null
+++ b/src/tests/rust-for-linux.md
@@ -0,0 +1,32 @@
+# Rust for Linux integration tests
+
+[Rust for Linux](https://rust-for-linux.com/) (RfL) is an effort for adding support for the Rust programming
+language into the Linux kernel.
+
+## Building Rust for Linux in CI
+
+Rust for Linux builds as part of the suite of bors tests that run before a pull request
+is merged.
+
+The workflow builds a stage1 sysroot of the Rust compiler, downloads the Linux kernel, and tries to compile several Rust for Linux drivers and examples using this sysroot. RfL uses several unstable compiler/language features, therefore this workflow notifies us if a given compiler change would break it.
+
+If you are worried that a pull request might break the Rust for Linux builder and want
+to test it out before submitting it to the bors queue, simply add this line to
+your PR description:
+
+> try-job: x86_64-rust-for-linux
+
+Then when you `@bors try` it will pick the job that builds the Rust for Linux integration.
+
+## What to do in case of failure
+
+Currently, we use the following unofficial policy for handling failures caused by a change breaking the RfL integration:
+
+- If the breakage was unintentional, then fix the PR.
+- If the breakage was intentional, then let [RFL][rfl-ping] know and discuss what will the kernel need to change.
+    - If the PR is urgent, then disable the test temporarily.
+    - If the PR can wait a few days, then wait for RFL maintainers to provide a new Linux kernel commit hash with the needed changes done, and apply it to the PR, which would confirm the changes work.
+
+If something goes wrong with the workflow, you can ping the [Rust for Linux][rfl-ping] ping group to ask for help.
+
+[rfl-ping]: ../notification-groups/rust-for-linux.md