Signed-off-by: Adrien Reynard <[email protected]> --- Documentation/dev-tools/kasan.rst | 2 +- Documentation/networking/switchdev.rst | 2 +- Documentation/virt/uml/user_mode_linux_howto_v2.rst | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst index 4968b2aa60c8..3a8bd40ad905 100644 --- a/Documentation/dev-tools/kasan.rst +++ b/Documentation/dev-tools/kasan.rst @@ -392,7 +392,7 @@ reserved to tag freed memory regions. If the hardware does not support MTE (pre ARMv8.5), Hardware Tag-Based KASAN will not be enabled. In this case, all KASAN boot parameters are ignored. -Note that enabling CONFIG_KASAN_HW_TAGS always results in in-kernel TBI being +Note that enabling CONFIG_KASAN_HW_TAGS always results in-kernel TBI being enabled. Even when ``kasan.mode=off`` is provided or when the hardware does not support MTE (but supports TBI). diff --git a/Documentation/networking/switchdev.rst b/Documentation/networking/switchdev.rst index 2966b7122f05..948bce44ca9b 100644 --- a/Documentation/networking/switchdev.rst +++ b/Documentation/networking/switchdev.rst @@ -162,7 +162,7 @@ The switchdev driver can know a particular port's position in the topology by monitoring NETDEV_CHANGEUPPER notifications. For example, a port moved into a bond will see its upper master change. If that bond is moved into a bridge, the bond's upper master will change. And so on. The driver will track such -movements to know what position a port is in in the overall topology by +movements to know what position a port is in the overall topology by registering for netdevice events and acting on NETDEV_CHANGEUPPER. L2 Forwarding Offload diff --git a/Documentation/virt/uml/user_mode_linux_howto_v2.rst b/Documentation/virt/uml/user_mode_linux_howto_v2.rst index c37e8e594d12..7b08738c30aa 100644 --- a/Documentation/virt/uml/user_mode_linux_howto_v2.rst +++ b/Documentation/virt/uml/user_mode_linux_howto_v2.rst @@ -1092,7 +1092,7 @@ be formatted as plain text. Developing always goes hand in hand with debugging. First of all, you can always run UML under gdb and there will be a whole section -later on on how to do that. That, however, is not the only way to +later on how to do that. That, however, is not the only way to debug a Linux kernel. Quite often adding tracing statements and/or using UML specific approaches such as ptracing the UML kernel process are significantly more informative. -- 2.54.0
