* [patch 01/16] MAINTAINERS: update CZ.NIC's Turris information
2021-04-09 20:26 incoming Andrew Morton
@ 2021-04-09 20:27 ` Andrew Morton
2021-04-09 20:27 ` [patch 02/16] treewide: change my e-mail address, fix my name Andrew Morton
` (14 subsequent siblings)
15 siblings, 0 replies; 22+ messages in thread
From: Andrew Morton @ 2021-04-09 20:27 UTC (permalink / raw)
To: akpm, bgolaszewski, gregkh, jassisinghbrar, kabel, linus.walleij,
linux-mm, mm-commits, pavel, torvalds
From: Marek Behún <kabel@kernel.org>
Subject: MAINTAINERS: update CZ.NIC's Turris information
Add all the files maintained by Turris team, not only for MOX, but also
for Omnia. Change website.
Link: https://lkml.kernel.org/r/20210325171123.28093-1-kabel@kernel.org
Signed-off-by: Marek Behún <kabel@kernel.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
MAINTAINERS | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/MAINTAINERS~maintainers-update-cznics-turris-information
+++ a/MAINTAINERS
@@ -1790,19 +1790,26 @@ F: drivers/net/ethernet/cortina/
F: drivers/pinctrl/pinctrl-gemini.c
F: drivers/rtc/rtc-ftrtc010.c
-ARM/CZ.NIC TURRIS MOX SUPPORT
+ARM/CZ.NIC TURRIS SUPPORT
M: Marek Behun <marek.behun@nic.cz>
S: Maintained
-W: http://mox.turris.cz
+W: https://www.turris.cz/
F: Documentation/ABI/testing/debugfs-moxtet
F: Documentation/ABI/testing/sysfs-bus-moxtet-devices
F: Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm
F: Documentation/devicetree/bindings/bus/moxtet.txt
F: Documentation/devicetree/bindings/firmware/cznic,turris-mox-rwtm.txt
F: Documentation/devicetree/bindings/gpio/gpio-moxtet.txt
+F: Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml
+F: Documentation/devicetree/bindings/watchdog/armada-37xx-wdt.txt
F: drivers/bus/moxtet.c
F: drivers/firmware/turris-mox-rwtm.c
+F: drivers/leds/leds-turris-omnia.c
+F: drivers/mailbox/armada-37xx-rwtm-mailbox.c
F: drivers/gpio/gpio-moxtet.c
+F: drivers/watchdog/armada_37xx_wdt.c
+F: include/dt-bindings/bus/moxtet.h
+F: include/linux/armada-37xx-rwtm-mailbox.h
F: include/linux/moxtet.h
ARM/EZX SMARTPHONES (A780, A910, A1200, E680, ROKR E2 and ROKR E6)
_
^ permalink raw reply [flat|nested] 22+ messages in thread
* [patch 02/16] treewide: change my e-mail address, fix my name
2021-04-09 20:26 incoming Andrew Morton
2021-04-09 20:27 ` [patch 01/16] MAINTAINERS: update CZ.NIC's Turris information Andrew Morton
@ 2021-04-09 20:27 ` Andrew Morton
2021-04-09 20:27 ` [patch 03/16] mailmap: update email address for Jordan Crouse Andrew Morton
` (13 subsequent siblings)
15 siblings, 0 replies; 22+ messages in thread
From: Andrew Morton @ 2021-04-09 20:27 UTC (permalink / raw)
To: akpm, bgolaszewski, gregkh, jassisinghbrar, kabel, linus.walleij,
linux-mm, mm-commits, pavel, torvalds
From: Marek Behún <kabel@kernel.org>
Subject: treewide: change my e-mail address, fix my name
Change my e-mail address to kabel@kernel.org, and fix my name in
non-code parts (add diacritical mark).
Link: https://lkml.kernel.org/r/20210325171123.28093-2-kabel@kernel.org
Signed-off-by: Marek Behún <kabel@kernel.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/ABI/testing/debugfs-moxtet | 4 ++--
Documentation/ABI/testing/debugfs-turris-mox-rwtm | 2 +-
Documentation/ABI/testing/sysfs-bus-moxtet-devices | 6 +++---
Documentation/ABI/testing/sysfs-class-led-driver-turris-omnia | 2 +-
Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm | 10 +++++-----
Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml | 2 +-
MAINTAINERS | 2 +-
arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts | 2 +-
drivers/bus/moxtet.c | 4 ++--
drivers/firmware/turris-mox-rwtm.c | 4 ++--
drivers/gpio/gpio-moxtet.c | 4 ++--
drivers/leds/leds-turris-omnia.c | 4 ++--
drivers/mailbox/armada-37xx-rwtm-mailbox.c | 4 ++--
drivers/watchdog/armada_37xx_wdt.c | 4 ++--
include/dt-bindings/bus/moxtet.h | 2 +-
include/linux/armada-37xx-rwtm-mailbox.h | 2 +-
include/linux/moxtet.h | 2 +-
17 files changed, 30 insertions(+), 30 deletions(-)
--- a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts~treewide-change-my-e-mail-address-fix-my-name
+++ a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Device Tree file for CZ.NIC Turris Mox Board
- * 2019 by Marek Behun <marek.behun@nic.cz>
+ * 2019 by Marek Behún <kabel@kernel.org>
*/
/dts-v1/;
--- a/Documentation/ABI/testing/debugfs-moxtet~treewide-change-my-e-mail-address-fix-my-name
+++ a/Documentation/ABI/testing/debugfs-moxtet
@@ -1,7 +1,7 @@
What: /sys/kernel/debug/moxtet/input
Date: March 2019
KernelVersion: 5.3
-Contact: Marek Behún <marek.behun@nic.cz>
+Contact: Marek Behún <kabel@kernel.org>
Description: (Read) Read input from the shift registers, in hexadecimal.
Returns N+1 bytes, where N is the number of Moxtet connected
modules. The first byte is from the CPU board itself.
@@ -19,7 +19,7 @@ Description: (Read) Read input from the
What: /sys/kernel/debug/moxtet/output
Date: March 2019
KernelVersion: 5.3
-Contact: Marek Behún <marek.behun@nic.cz>
+Contact: Marek Behún <kabel@kernel.org>
Description: (RW) Read last written value to the shift registers, in
hexadecimal, or write values to the shift registers, also
in hexadecimal.
--- a/Documentation/ABI/testing/debugfs-turris-mox-rwtm~treewide-change-my-e-mail-address-fix-my-name
+++ a/Documentation/ABI/testing/debugfs-turris-mox-rwtm
@@ -1,7 +1,7 @@
What: /sys/kernel/debug/turris-mox-rwtm/do_sign
Date: Jun 2020
KernelVersion: 5.8
-Contact: Marek Behún <marek.behun@nic.cz>
+Contact: Marek Behún <kabel@kernel.org>
Description:
======= ===========================================================
--- a/Documentation/ABI/testing/sysfs-bus-moxtet-devices~treewide-change-my-e-mail-address-fix-my-name
+++ a/Documentation/ABI/testing/sysfs-bus-moxtet-devices
@@ -1,17 +1,17 @@
What: /sys/bus/moxtet/devices/moxtet-<name>.<addr>/module_description
Date: March 2019
KernelVersion: 5.3
-Contact: Marek Behún <marek.behun@nic.cz>
+Contact: Marek Behún <kabel@kernel.org>
Description: (Read) Moxtet module description. Format: string
What: /sys/bus/moxtet/devices/moxtet-<name>.<addr>/module_id
Date: March 2019
KernelVersion: 5.3
-Contact: Marek Behún <marek.behun@nic.cz>
+Contact: Marek Behún <kabel@kernel.org>
Description: (Read) Moxtet module ID. Format: %x
What: /sys/bus/moxtet/devices/moxtet-<name>.<addr>/module_name
Date: March 2019
KernelVersion: 5.3
-Contact: Marek Behún <marek.behun@nic.cz>
+Contact: Marek Behún <kabel@kernel.org>
Description: (Read) Moxtet module name. Format: string
--- a/Documentation/ABI/testing/sysfs-class-led-driver-turris-omnia~treewide-change-my-e-mail-address-fix-my-name
+++ a/Documentation/ABI/testing/sysfs-class-led-driver-turris-omnia
@@ -1,7 +1,7 @@
What: /sys/class/leds/<led>/device/brightness
Date: July 2020
KernelVersion: 5.9
-Contact: Marek Behún <marek.behun@nic.cz>
+Contact: Marek Behún <kabel@kernel.org>
Description: (RW) On the front panel of the Turris Omnia router there is also
a button which can be used to control the intensity of all the
LEDs at once, so that if they are too bright, user can dim them.
--- a/Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm~treewide-change-my-e-mail-address-fix-my-name
+++ a/Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm
@@ -1,21 +1,21 @@
What: /sys/firmware/turris-mox-rwtm/board_version
Date: August 2019
KernelVersion: 5.4
-Contact: Marek Behún <marek.behun@nic.cz>
+Contact: Marek Behún <kabel@kernel.org>
Description: (Read) Board version burned into eFuses of this Turris Mox board.
Format: %i
What: /sys/firmware/turris-mox-rwtm/mac_address*
Date: August 2019
KernelVersion: 5.4
-Contact: Marek Behún <marek.behun@nic.cz>
+Contact: Marek Behún <kabel@kernel.org>
Description: (Read) MAC addresses burned into eFuses of this Turris Mox board.
Format: %pM
What: /sys/firmware/turris-mox-rwtm/pubkey
Date: August 2019
KernelVersion: 5.4
-Contact: Marek Behún <marek.behun@nic.cz>
+Contact: Marek Behún <kabel@kernel.org>
Description: (Read) ECDSA public key (in pubkey hex compressed form) computed
as pair to the ECDSA private key burned into eFuses of this
Turris Mox Board.
@@ -24,7 +24,7 @@ Description: (Read) ECDSA public key (in
What: /sys/firmware/turris-mox-rwtm/ram_size
Date: August 2019
KernelVersion: 5.4
-Contact: Marek Behún <marek.behun@nic.cz>
+Contact: Marek Behún <kabel@kernel.org>
Description: (Read) RAM size in MiB of this Turris Mox board as was detected
during manufacturing and burned into eFuses. Can be 512 or 1024.
Format: %i
@@ -32,6 +32,6 @@ Description: (Read) RAM size in MiB of t
What: /sys/firmware/turris-mox-rwtm/serial_number
Date: August 2019
KernelVersion: 5.4
-Contact: Marek Behún <marek.behun@nic.cz>
+Contact: Marek Behún <kabel@kernel.org>
Description: (Read) Serial number burned into eFuses of this Turris Mox device.
Format: %016X
--- a/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml~treewide-change-my-e-mail-address-fix-my-name
+++ a/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-sche
title: CZ.NIC's Turris Omnia LEDs driver
maintainers:
- - Marek Behún <marek.behun@nic.cz>
+ - Marek Behún <kabel@kernel.org>
description:
This module adds support for the RGB LEDs found on the front panel of the
--- a/drivers/bus/moxtet.c~treewide-change-my-e-mail-address-fix-my-name
+++ a/drivers/bus/moxtet.c
@@ -2,7 +2,7 @@
/*
* Turris Mox module configuration bus driver
*
- * Copyright (C) 2019 Marek Behun <marek.behun@nic.cz>
+ * Copyright (C) 2019 Marek Behún <kabel@kernel.org>
*/
#include <dt-bindings/bus/moxtet.h>
@@ -879,6 +879,6 @@ static void __exit moxtet_exit(void)
}
module_exit(moxtet_exit);
-MODULE_AUTHOR("Marek Behun <marek.behun@nic.cz>");
+MODULE_AUTHOR("Marek Behun <kabel@kernel.org>");
MODULE_DESCRIPTION("CZ.NIC's Turris Mox module configuration bus");
MODULE_LICENSE("GPL v2");
--- a/drivers/firmware/turris-mox-rwtm.c~treewide-change-my-e-mail-address-fix-my-name
+++ a/drivers/firmware/turris-mox-rwtm.c
@@ -2,7 +2,7 @@
/*
* Turris Mox rWTM firmware driver
*
- * Copyright (C) 2019 Marek Behun <marek.behun@nic.cz>
+ * Copyright (C) 2019 Marek Behún <kabel@kernel.org>
*/
#include <linux/armada-37xx-rwtm-mailbox.h>
@@ -547,4 +547,4 @@ module_platform_driver(turris_mox_rwtm_d
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("Turris Mox rWTM firmware driver");
-MODULE_AUTHOR("Marek Behun <marek.behun@nic.cz>");
+MODULE_AUTHOR("Marek Behun <kabel@kernel.org>");
--- a/drivers/gpio/gpio-moxtet.c~treewide-change-my-e-mail-address-fix-my-name
+++ a/drivers/gpio/gpio-moxtet.c
@@ -2,7 +2,7 @@
/*
* Turris Mox Moxtet GPIO expander
*
- * Copyright (C) 2018 Marek Behun <marek.behun@nic.cz>
+ * Copyright (C) 2018 Marek Behún <kabel@kernel.org>
*/
#include <linux/bitops.h>
@@ -174,6 +174,6 @@ static struct moxtet_driver moxtet_gpio_
};
module_moxtet_driver(moxtet_gpio_driver);
-MODULE_AUTHOR("Marek Behun <marek.behun@nic.cz>");
+MODULE_AUTHOR("Marek Behun <kabel@kernel.org>");
MODULE_DESCRIPTION("Turris Mox Moxtet GPIO expander");
MODULE_LICENSE("GPL v2");
--- a/drivers/leds/leds-turris-omnia.c~treewide-change-my-e-mail-address-fix-my-name
+++ a/drivers/leds/leds-turris-omnia.c
@@ -2,7 +2,7 @@
/*
* CZ.NIC's Turris Omnia LEDs driver
*
- * 2020 by Marek Behun <marek.behun@nic.cz>
+ * 2020 by Marek Behún <kabel@kernel.org>
*/
#include <linux/i2c.h>
@@ -287,6 +287,6 @@ static struct i2c_driver omnia_leds_driv
module_i2c_driver(omnia_leds_driver);
-MODULE_AUTHOR("Marek Behun <marek.behun@nic.cz>");
+MODULE_AUTHOR("Marek Behun <kabel@kernel.org>");
MODULE_DESCRIPTION("CZ.NIC's Turris Omnia LEDs");
MODULE_LICENSE("GPL v2");
--- a/drivers/mailbox/armada-37xx-rwtm-mailbox.c~treewide-change-my-e-mail-address-fix-my-name
+++ a/drivers/mailbox/armada-37xx-rwtm-mailbox.c
@@ -2,7 +2,7 @@
/*
* rWTM BIU Mailbox driver for Armada 37xx
*
- * Author: Marek Behun <marek.behun@nic.cz>
+ * Author: Marek Behún <kabel@kernel.org>
*/
#include <linux/device.h>
@@ -203,4 +203,4 @@ module_platform_driver(armada_37xx_mbox_
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("rWTM BIU Mailbox driver for Armada 37xx");
-MODULE_AUTHOR("Marek Behun <marek.behun@nic.cz>");
+MODULE_AUTHOR("Marek Behun <kabel@kernel.org>");
--- a/drivers/watchdog/armada_37xx_wdt.c~treewide-change-my-e-mail-address-fix-my-name
+++ a/drivers/watchdog/armada_37xx_wdt.c
@@ -2,7 +2,7 @@
/*
* Watchdog driver for Marvell Armada 37xx SoCs
*
- * Author: Marek Behun <marek.behun@nic.cz>
+ * Author: Marek Behún <kabel@kernel.org>
*/
#include <linux/clk.h>
@@ -366,7 +366,7 @@ static struct platform_driver armada_37x
module_platform_driver(armada_37xx_wdt_driver);
-MODULE_AUTHOR("Marek Behun <marek.behun@nic.cz>");
+MODULE_AUTHOR("Marek Behun <kabel@kernel.org>");
MODULE_DESCRIPTION("Armada 37xx CPU Watchdog");
MODULE_LICENSE("GPL v2");
--- a/include/dt-bindings/bus/moxtet.h~treewide-change-my-e-mail-address-fix-my-name
+++ a/include/dt-bindings/bus/moxtet.h
@@ -2,7 +2,7 @@
/*
* Constant for device tree bindings for Turris Mox module configuration bus
*
- * Copyright (C) 2019 Marek Behun <marek.behun@nic.cz>
+ * Copyright (C) 2019 Marek Behún <kabel@kernel.org>
*/
#ifndef _DT_BINDINGS_BUS_MOXTET_H
--- a/include/linux/armada-37xx-rwtm-mailbox.h~treewide-change-my-e-mail-address-fix-my-name
+++ a/include/linux/armada-37xx-rwtm-mailbox.h
@@ -2,7 +2,7 @@
/*
* rWTM BIU Mailbox driver for Armada 37xx
*
- * Author: Marek Behun <marek.behun@nic.cz>
+ * Author: Marek Behún <kabel@kernel.org>
*/
#ifndef _LINUX_ARMADA_37XX_RWTM_MAILBOX_H_
--- a/include/linux/moxtet.h~treewide-change-my-e-mail-address-fix-my-name
+++ a/include/linux/moxtet.h
@@ -2,7 +2,7 @@
/*
* Turris Mox module configuration bus driver
*
- * Copyright (C) 2019 Marek Behun <marek.behun@nic.cz>
+ * Copyright (C) 2019 Marek Behún <kabel@kernel.org>
*/
#ifndef __LINUX_MOXTET_H
--- a/MAINTAINERS~treewide-change-my-e-mail-address-fix-my-name
+++ a/MAINTAINERS
@@ -1791,7 +1791,7 @@ F: drivers/pinctrl/pinctrl-gemini.c
F: drivers/rtc/rtc-ftrtc010.c
ARM/CZ.NIC TURRIS SUPPORT
-M: Marek Behun <marek.behun@nic.cz>
+M: Marek Behun <kabel@kernel.org>
S: Maintained
W: https://www.turris.cz/
F: Documentation/ABI/testing/debugfs-moxtet
_
^ permalink raw reply [flat|nested] 22+ messages in thread
* [patch 03/16] mailmap: update email address for Jordan Crouse
2021-04-09 20:26 incoming Andrew Morton
2021-04-09 20:27 ` [patch 01/16] MAINTAINERS: update CZ.NIC's Turris information Andrew Morton
2021-04-09 20:27 ` [patch 02/16] treewide: change my e-mail address, fix my name Andrew Morton
@ 2021-04-09 20:27 ` Andrew Morton
2021-04-09 20:27 ` [patch 04/16] .mailmap: fix old email addresses Andrew Morton
` (12 subsequent siblings)
15 siblings, 0 replies; 22+ messages in thread
From: Andrew Morton @ 2021-04-09 20:27 UTC (permalink / raw)
To: akpm, alobakin, corbet, jordan, keescook, linux-mm, mm-commits,
ojeda, torvalds, tsbogend
From: Jordan Crouse <jordan@cosmicpenguin.net>
Subject: mailmap: update email address for Jordan Crouse
jcrouse at codeaurora.org has started bouncing. Redirect to a more
permanent address.
Link: https://lkml.kernel.org/r/20210325143700.1490518-1-jordan@cosmicpenguin.net
Signed-off-by: Jordan Crouse <jordan@cosmicpenguin.net>
Cc: Alexander Lobakin <alobakin@pm.me>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Kees Cook <keescook@chromium.org>
Cc: Miguel Ojeda <ojeda@kernel.org>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
.mailmap | 1 +
1 file changed, 1 insertion(+)
--- a/.mailmap~mailmap-update-email-address-for-jordan-crouse
+++ a/.mailmap
@@ -168,6 +168,7 @@ Johan Hovold <johan@kernel.org> <jhovold
Johan Hovold <johan@kernel.org> <johan@hovoldconsulting.com>
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
John Stultz <johnstul@us.ibm.com>
+Jordan Crouse <jordan@cosmicpenguin.net> <jcrouse@codeaurora.org>
<josh@joshtriplett.org> <josh@freedesktop.org>
<josh@joshtriplett.org> <josh@kernel.org>
<josh@joshtriplett.org> <josht@linux.vnet.ibm.com>
_
^ permalink raw reply [flat|nested] 22+ messages in thread
* [patch 04/16] .mailmap: fix old email addresses
2021-04-09 20:26 incoming Andrew Morton
` (2 preceding siblings ...)
2021-04-09 20:27 ` [patch 03/16] mailmap: update email address for Jordan Crouse Andrew Morton
@ 2021-04-09 20:27 ` Andrew Morton
2021-04-09 20:27 ` [patch 05/16] kasan: fix hwasan build for gcc Andrew Morton
` (11 subsequent siblings)
15 siblings, 0 replies; 22+ messages in thread
From: Andrew Morton @ 2021-04-09 20:27 UTC (permalink / raw)
To: akpm, linux-mm, mm-commits, npiggin, nyc, torvalds, willy
From: Matthew Wilcox <willy@infradead.org>
Subject: .mailmap: fix old email addresses
Update Nick & Nadia's old addresses.
Link: https://lkml.kernel.org/r/20210406134036.GQ2531743@casper.infradead.org
Signed-off-by: Matthew Wilcox <willy@infradead.org>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Nadia Yvette Chambers <nyc@holomorphy.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
.mailmap | 6 ++++++
1 file changed, 6 insertions(+)
--- a/.mailmap~old-email-addresses-in-mailmap
+++ a/.mailmap
@@ -254,8 +254,14 @@ Morten Welinder <welinder@anemone.rentec
Morten Welinder <welinder@darter.rentec.com>
Morten Welinder <welinder@troll.com>
Mythri P K <mythripk@ti.com>
+Nadia Yvette Chambers <nyc@holomorphy.com> William Lee Irwin III <wli@holomorphy.com>
Nathan Chancellor <nathan@kernel.org> <natechancellor@gmail.com>
Nguyen Anh Quynh <aquynh@gmail.com>
+Nicholas Piggin <npiggin@gmail.com> <npiggen@suse.de>
+Nicholas Piggin <npiggin@gmail.com> <npiggin@kernel.dk>
+Nicholas Piggin <npiggin@gmail.com> <npiggin@suse.de>
+Nicholas Piggin <npiggin@gmail.com> <nickpiggin@yahoo.com.au>
+Nicholas Piggin <npiggin@gmail.com> <piggin@cyberone.com.au>
Nicolas Ferre <nicolas.ferre@microchip.com> <nicolas.ferre@atmel.com>
Nicolas Pitre <nico@fluxnic.net> <nicolas.pitre@linaro.org>
Nicolas Pitre <nico@fluxnic.net> <nico@linaro.org>
_
^ permalink raw reply [flat|nested] 22+ messages in thread
* [patch 05/16] kasan: fix hwasan build for gcc
2021-04-09 20:26 incoming Andrew Morton
` (3 preceding siblings ...)
2021-04-09 20:27 ` [patch 04/16] .mailmap: fix old email addresses Andrew Morton
@ 2021-04-09 20:27 ` Andrew Morton
2021-04-09 20:39 ` Andrey Konovalov
2021-04-09 20:27 ` [patch 06/16] kasan: remove redundant config option Andrew Morton
` (10 subsequent siblings)
15 siblings, 1 reply; 22+ messages in thread
From: Andrew Morton @ 2021-04-09 20:27 UTC (permalink / raw)
To: akpm, andreyknvl, arnd, dvyukov, elver, glider, linux-mm,
masahiroy, michal.lkml, mm-commits, nathan, ndesaulniers,
ryabinin.a.a, torvalds
From: Arnd Bergmann <arnd@arndb.de>
Subject: kasan: fix hwasan build for gcc
gcc-11 adds support for -fsanitize=kernel-hwaddress, so it becomes
possible to enable CONFIG_KASAN_SW_TAGS.
Unfortunately this fails to build at the moment, because the corresponding
command line arguments use llvm specific syntax.
Change it to use the cc-param macro instead, which works on both clang and
gcc.
Link: https://lkml.kernel.org/r/20210323124112.1229772-1-arnd@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Marco Elver <elver@google.com>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
scripts/Makefile.kasan | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/scripts/Makefile.kasan~kasan-fix-hwasan-build-for-gcc
+++ a/scripts/Makefile.kasan
@@ -36,14 +36,14 @@ endif # CONFIG_KASAN_GENERIC
ifdef CONFIG_KASAN_SW_TAGS
ifdef CONFIG_KASAN_INLINE
- instrumentation_flags := -mllvm -hwasan-mapping-offset=$(KASAN_SHADOW_OFFSET)
+ instrumentation_flags := $(call cc-param,hwasan-mapping-offset=$(KASAN_SHADOW_OFFSET))
else
- instrumentation_flags := -mllvm -hwasan-instrument-with-calls=1
+ instrumentation_flags := $(call cc-param,hwasan-instrument-with-calls=1)
endif
CFLAGS_KASAN := -fsanitize=kernel-hwaddress \
- -mllvm -hwasan-instrument-stack=$(CONFIG_KASAN_STACK) \
- -mllvm -hwasan-use-short-granules=0 \
+ $(call cc-param,hwasan-instrument-stack=$(CONFIG_KASAN_STACK)) \
+ $(call cc-param,hwasan-use-short-granules=0) \
$(instrumentation_flags)
endif # CONFIG_KASAN_SW_TAGS
_
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [patch 05/16] kasan: fix hwasan build for gcc
2021-04-09 20:27 ` [patch 05/16] kasan: fix hwasan build for gcc Andrew Morton
@ 2021-04-09 20:39 ` Andrey Konovalov
2021-04-09 20:58 ` Andrew Morton
2021-04-09 21:55 ` Linus Torvalds
0 siblings, 2 replies; 22+ messages in thread
From: Andrey Konovalov @ 2021-04-09 20:39 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann
Cc: Dmitry Vyukov, Marco Elver, Alexander Potapenko,
Linux Memory Management List, Masahiro Yamada, Michal Marek,
mm-commits, Nathan Chancellor, Nick Desaulniers, Andrey Ryabinin,
Linus Torvalds
On Fri, Apr 9, 2021 at 10:27 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> From: Arnd Bergmann <arnd@arndb.de>
> Subject: kasan: fix hwasan build for gcc
>
> gcc-11 adds support for -fsanitize=kernel-hwaddress, so it becomes
> possible to enable CONFIG_KASAN_SW_TAGS.
>
> Unfortunately this fails to build at the moment, because the corresponding
> command line arguments use llvm specific syntax.
>
> Change it to use the cc-param macro instead, which works on both clang and
> gcc.
>
> Link: https://lkml.kernel.org/r/20210323124112.1229772-1-arnd@kernel.org
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Reviewed-by: Marco Elver <elver@google.com>
> Cc: Masahiro Yamada <masahiroy@kernel.org>
> Cc: Michal Marek <michal.lkml@markovi.net>
> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
> Cc: Nathan Chancellor <nathan@kernel.org>
> Cc: Nick Desaulniers <ndesaulniers@google.com>
> Cc: Alexander Potapenko <glider@google.com>
> Cc: Andrey Konovalov <andreyknvl@gmail.com>
> Cc: Dmitry Vyukov <dvyukov@google.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> scripts/Makefile.kasan | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> --- a/scripts/Makefile.kasan~kasan-fix-hwasan-build-for-gcc
> +++ a/scripts/Makefile.kasan
> @@ -36,14 +36,14 @@ endif # CONFIG_KASAN_GENERIC
> ifdef CONFIG_KASAN_SW_TAGS
>
> ifdef CONFIG_KASAN_INLINE
> - instrumentation_flags := -mllvm -hwasan-mapping-offset=$(KASAN_SHADOW_OFFSET)
> + instrumentation_flags := $(call cc-param,hwasan-mapping-offset=$(KASAN_SHADOW_OFFSET))
> else
> - instrumentation_flags := -mllvm -hwasan-instrument-with-calls=1
> + instrumentation_flags := $(call cc-param,hwasan-instrument-with-calls=1)
> endif
>
> CFLAGS_KASAN := -fsanitize=kernel-hwaddress \
> - -mllvm -hwasan-instrument-stack=$(CONFIG_KASAN_STACK) \
> - -mllvm -hwasan-use-short-granules=0 \
> + $(call cc-param,hwasan-instrument-stack=$(CONFIG_KASAN_STACK)) \
> + $(call cc-param,hwasan-use-short-granules=0) \
> $(instrumentation_flags)
>
> endif # CONFIG_KASAN_SW_TAGS
> _
Hi,
As I commented on the patch, this breaks SW_TAGS build with Clang for me with:
arch/arm64/include/asm/current.h:19: undefined reference to `__hwasan_tls'
The reason for this is that cc-param is only defined for
KASAN_GENERIC, the definition needs to be moved.
Thanks!
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [patch 05/16] kasan: fix hwasan build for gcc
2021-04-09 20:39 ` Andrey Konovalov
@ 2021-04-09 20:58 ` Andrew Morton
2021-04-12 9:56 ` Marco Elver
2021-04-09 21:55 ` Linus Torvalds
1 sibling, 1 reply; 22+ messages in thread
From: Andrew Morton @ 2021-04-09 20:58 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Arnd Bergmann, Dmitry Vyukov, Marco Elver, Alexander Potapenko,
Linux Memory Management List, Masahiro Yamada, Michal Marek,
mm-commits, Nathan Chancellor, Nick Desaulniers, Andrey Ryabinin,
Linus Torvalds
On Fri, 9 Apr 2021 22:39:46 +0200 Andrey Konovalov <andreyknvl@gmail.com> wrote:
> >
> > endif # CONFIG_KASAN_SW_TAGS
> > _
>
> Hi,
>
> As I commented on the patch, this breaks SW_TAGS build with Clang for me with:
>
> arch/arm64/include/asm/current.h:19: undefined reference to `__hwasan_tls'
>
> The reason for this is that cc-param is only defined for
> KASAN_GENERIC, the definition needs to be moved.
>
Oh. I thought that had been fixed.
Please send a patch?
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [patch 05/16] kasan: fix hwasan build for gcc
2021-04-09 20:58 ` Andrew Morton
@ 2021-04-12 9:56 ` Marco Elver
2021-04-12 12:54 ` Andrey Konovalov
0 siblings, 1 reply; 22+ messages in thread
From: Marco Elver @ 2021-04-12 9:56 UTC (permalink / raw)
To: Andrew Morton
Cc: Andrey Konovalov, Arnd Bergmann, Dmitry Vyukov,
Alexander Potapenko, Linux Memory Management List,
Masahiro Yamada, Michal Marek, mm-commits, Nathan Chancellor,
Nick Desaulniers, Andrey Ryabinin, Linus Torvalds
On Fri, Apr 09, 2021 at 01:58PM -0700, Andrew Morton wrote:
> On Fri, 9 Apr 2021 22:39:46 +0200 Andrey Konovalov <andreyknvl@gmail.com> wrote:
>
> > >
> > > endif # CONFIG_KASAN_SW_TAGS
> > > _
> >
> > Hi,
> >
> > As I commented on the patch, this breaks SW_TAGS build with Clang for me with:
> >
> > arch/arm64/include/asm/current.h:19: undefined reference to `__hwasan_tls'
> >
> > The reason for this is that cc-param is only defined for
> > KASAN_GENERIC, the definition needs to be moved.
> >
>
> Oh. I thought that had been fixed.
>
> Please send a patch?
I think we need something like the below.
Unless a fixed version has already been sent, feel free to squash
(applies immediately after "kasan: fix hwasan build for gcc", and before
the conflicting "kasan: remove redundant config option").
Thanks,
-- Marco
------ >8 ------
From: Marco Elver <elver@google.com>
Date: Sun, 11 Apr 2021 21:32:01 +0200
Subject: [PATCH] fixup for "kasan: fix hwasan build for gcc"
Signed-off-by: Marco Elver <elver@google.com>
---
scripts/Makefile.kasan | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
index 0a2789783d1b..127012f45166 100644
--- a/scripts/Makefile.kasan
+++ b/scripts/Makefile.kasan
@@ -2,6 +2,8 @@
CFLAGS_KASAN_NOSANITIZE := -fno-builtin
KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)
+cc-param = $(call cc-option, -mllvm -$(1), $(call cc-option, --param $(1)))
+
ifdef CONFIG_KASAN_GENERIC
ifdef CONFIG_KASAN_INLINE
@@ -12,8 +14,6 @@ endif
CFLAGS_KASAN_MINIMAL := -fsanitize=kernel-address
-cc-param = $(call cc-option, -mllvm -$(1), $(call cc-option, --param $(1)))
-
# -fasan-shadow-offset fails without -fsanitize
CFLAGS_KASAN_SHADOW := $(call cc-option, -fsanitize=kernel-address \
-fasan-shadow-offset=$(KASAN_SHADOW_OFFSET), \
--
2.31.1.295.g9ea45b61b8-goog
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [patch 05/16] kasan: fix hwasan build for gcc
2021-04-12 9:56 ` Marco Elver
@ 2021-04-12 12:54 ` Andrey Konovalov
0 siblings, 0 replies; 22+ messages in thread
From: Andrey Konovalov @ 2021-04-12 12:54 UTC (permalink / raw)
To: Marco Elver, Andrew Morton
Cc: Arnd Bergmann, Dmitry Vyukov, Alexander Potapenko,
Linux Memory Management List, Masahiro Yamada, Michal Marek,
mm-commits, Nathan Chancellor, Nick Desaulniers, Andrey Ryabinin,
Linus Torvalds
On Mon, Apr 12, 2021 at 11:56 AM Marco Elver <elver@google.com> wrote:
>
> On Fri, Apr 09, 2021 at 01:58PM -0700, Andrew Morton wrote:
> > On Fri, 9 Apr 2021 22:39:46 +0200 Andrey Konovalov <andreyknvl@gmail.com> wrote:
> >
> > > >
> > > > endif # CONFIG_KASAN_SW_TAGS
> > > > _
> > >
> > > Hi,
> > >
> > > As I commented on the patch, this breaks SW_TAGS build with Clang for me with:
> > >
> > > arch/arm64/include/asm/current.h:19: undefined reference to `__hwasan_tls'
> > >
> > > The reason for this is that cc-param is only defined for
> > > KASAN_GENERIC, the definition needs to be moved.
> > >
> >
> > Oh. I thought that had been fixed.
> >
> > Please send a patch?
>
> I think we need something like the below.
>
> Unless a fixed version has already been sent, feel free to squash
> (applies immediately after "kasan: fix hwasan build for gcc", and before
> the conflicting "kasan: remove redundant config option").
>
> Thanks,
> -- Marco
>
> ------ >8 ------
>
> From: Marco Elver <elver@google.com>
> Date: Sun, 11 Apr 2021 21:32:01 +0200
> Subject: [PATCH] fixup for "kasan: fix hwasan build for gcc"
>
> Signed-off-by: Marco Elver <elver@google.com>
> ---
> scripts/Makefile.kasan | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
> index 0a2789783d1b..127012f45166 100644
> --- a/scripts/Makefile.kasan
> +++ b/scripts/Makefile.kasan
> @@ -2,6 +2,8 @@
> CFLAGS_KASAN_NOSANITIZE := -fno-builtin
> KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)
>
> +cc-param = $(call cc-option, -mllvm -$(1), $(call cc-option, --param $(1)))
> +
> ifdef CONFIG_KASAN_GENERIC
>
> ifdef CONFIG_KASAN_INLINE
> @@ -12,8 +14,6 @@ endif
>
> CFLAGS_KASAN_MINIMAL := -fsanitize=kernel-address
>
> -cc-param = $(call cc-option, -mllvm -$(1), $(call cc-option, --param $(1)))
> -
> # -fasan-shadow-offset fails without -fsanitize
> CFLAGS_KASAN_SHADOW := $(call cc-option, -fsanitize=kernel-address \
> -fasan-shadow-offset=$(KASAN_SHADOW_OFFSET), \
> --
> 2.31.1.295.g9ea45b61b8-goog
>
This fix-up looks good to me.
Thank you, Marco!
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [patch 05/16] kasan: fix hwasan build for gcc
2021-04-09 20:39 ` Andrey Konovalov
2021-04-09 20:58 ` Andrew Morton
@ 2021-04-09 21:55 ` Linus Torvalds
1 sibling, 0 replies; 22+ messages in thread
From: Linus Torvalds @ 2021-04-09 21:55 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Andrew Morton, Arnd Bergmann, Dmitry Vyukov, Marco Elver,
Alexander Potapenko, Linux Memory Management List,
Masahiro Yamada, Michal Marek, mm-commits, Nathan Chancellor,
Nick Desaulniers, Andrey Ryabinin
On Fri, Apr 9, 2021 at 1:39 PM Andrey Konovalov <andreyknvl@gmail.com> wrote:
>
> As I commented on the patch, this breaks SW_TAGS build with Clang for me with:
>
> arch/arm64/include/asm/current.h:19: undefined reference to `__hwasan_tls'
I've dropped this patch and the next one ("[PATCH 06/16] kasan: remove
redundant config option") that depended on it.
Linus
^ permalink raw reply [flat|nested] 22+ messages in thread
* [patch 06/16] kasan: remove redundant config option
2021-04-09 20:26 incoming Andrew Morton
` (4 preceding siblings ...)
2021-04-09 20:27 ` [patch 05/16] kasan: fix hwasan build for gcc Andrew Morton
@ 2021-04-09 20:27 ` Andrew Morton
2021-04-09 20:27 ` [patch 07/16] mm/gup: check page posion status for coredump Andrew Morton
` (9 subsequent siblings)
15 siblings, 0 replies; 22+ messages in thread
From: Andrew Morton @ 2021-04-09 20:27 UTC (permalink / raw)
To: akpm, andreyknvl, arnd, dvyukov, glider, linux-mm, mm-commits,
natechancellor, ryabinin.a.a, stable, torvalds, walter-zh.wu
From: Walter Wu <walter-zh.wu@mediatek.com>
Subject: kasan: remove redundant config option
CONFIG_KASAN_STACK and CONFIG_KASAN_STACK_ENABLE both enable KASAN stack
instrumentation, but we should only need one config, so that we remove
CONFIG_KASAN_STACK_ENABLE and make CONFIG_KASAN_STACK workable. see [1].
When enable KASAN stack instrumentation, then for gcc we could do no
prompt and default value y, and for clang prompt and default value n.
This patch fixes the following compilation warning:
include/linux/kasan.h:333:30: warning: 'CONFIG_KASAN_STACK' is not defined, evaluates to 0 [-Wundef]
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=210221
[akpm@linux-foundation.org: fix merge snafu]
Link: https://lkml.kernel.org/r/20210226012531.29231-1-walter-zh.wu@mediatek.com
Fixes: d9b571c885a8 ("kasan: fix KASAN_STACK dependency for HW_TAGS")
Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
Suggested-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Andrey Konovalov <andreyknvl@google.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/arm64/kernel/sleep.S | 2 +-
arch/x86/kernel/acpi/wakeup_64.S | 2 +-
include/linux/kasan.h | 2 +-
lib/Kconfig.kasan | 9 ++-------
mm/kasan/common.c | 2 +-
mm/kasan/kasan.h | 2 +-
mm/kasan/report_generic.c | 2 +-
scripts/Makefile.kasan | 10 ++++++++--
security/Kconfig.hardening | 4 ++--
9 files changed, 18 insertions(+), 17 deletions(-)
--- a/arch/arm64/kernel/sleep.S~kasan-remove-redundant-config-option
+++ a/arch/arm64/kernel/sleep.S
@@ -134,7 +134,7 @@ SYM_FUNC_START(_cpu_resume)
*/
bl cpu_do_resume
-#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
+#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
mov x0, sp
bl kasan_unpoison_task_stack_below
#endif
--- a/arch/x86/kernel/acpi/wakeup_64.S~kasan-remove-redundant-config-option
+++ a/arch/x86/kernel/acpi/wakeup_64.S
@@ -115,7 +115,7 @@ SYM_FUNC_START(do_suspend_lowlevel)
movq pt_regs_r14(%rax), %r14
movq pt_regs_r15(%rax), %r15
-#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
+#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
/*
* The suspend path may have poisoned some areas deeper in the stack,
* which we now need to unpoison.
--- a/include/linux/kasan.h~kasan-remove-redundant-config-option
+++ a/include/linux/kasan.h
@@ -330,7 +330,7 @@ static inline bool kasan_check_byte(cons
#endif /* CONFIG_KASAN */
-#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
+#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
void kasan_unpoison_task_stack(struct task_struct *task);
#else
static inline void kasan_unpoison_task_stack(struct task_struct *task) {}
--- a/lib/Kconfig.kasan~kasan-remove-redundant-config-option
+++ a/lib/Kconfig.kasan
@@ -138,9 +138,10 @@ config KASAN_INLINE
endchoice
-config KASAN_STACK_ENABLE
+config KASAN_STACK
bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
depends on KASAN_GENERIC || KASAN_SW_TAGS
+ default y if CC_IS_GCC
help
The LLVM stack address sanitizer has a know problem that
causes excessive stack usage in a lot of functions, see
@@ -154,12 +155,6 @@ config KASAN_STACK_ENABLE
CONFIG_COMPILE_TEST. On gcc it is assumed to always be safe
to use and enabled by default.
-config KASAN_STACK
- int
- depends on KASAN_GENERIC || KASAN_SW_TAGS
- default 1 if KASAN_STACK_ENABLE || CC_IS_GCC
- default 0
-
config KASAN_SW_TAGS_IDENTIFY
bool "Enable memory corruption identification"
depends on KASAN_SW_TAGS
--- a/mm/kasan/common.c~kasan-remove-redundant-config-option
+++ a/mm/kasan/common.c
@@ -63,7 +63,7 @@ void __kasan_unpoison_range(const void *
kasan_unpoison(address, size);
}
-#if CONFIG_KASAN_STACK
+#ifdef CONFIG_KASAN_STACK
/* Unpoison the entire stack for a task. */
void kasan_unpoison_task_stack(struct task_struct *task)
{
--- a/mm/kasan/kasan.h~kasan-remove-redundant-config-option
+++ a/mm/kasan/kasan.h
@@ -231,7 +231,7 @@ void *kasan_find_first_bad_addr(void *ad
const char *kasan_get_bug_type(struct kasan_access_info *info);
void kasan_metadata_fetch_row(char *buffer, void *row);
-#if defined(CONFIG_KASAN_GENERIC) && CONFIG_KASAN_STACK
+#if defined(CONFIG_KASAN_GENERIC) && defined(CONFIG_KASAN_STACK)
void kasan_print_address_stack_frame(const void *addr);
#else
static inline void kasan_print_address_stack_frame(const void *addr) { }
--- a/mm/kasan/report_generic.c~kasan-remove-redundant-config-option
+++ a/mm/kasan/report_generic.c
@@ -128,7 +128,7 @@ void kasan_metadata_fetch_row(char *buff
memcpy(buffer, kasan_mem_to_shadow(row), META_BYTES_PER_ROW);
}
-#if CONFIG_KASAN_STACK
+#ifdef CONFIG_KASAN_STACK
static bool __must_check tokenize_frame_descr(const char **frame_descr,
char *token, size_t max_tok_len,
unsigned long *value)
--- a/scripts/Makefile.kasan~kasan-remove-redundant-config-option
+++ a/scripts/Makefile.kasan
@@ -2,6 +2,12 @@
CFLAGS_KASAN_NOSANITIZE := -fno-builtin
KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)
+ifdef CONFIG_KASAN_STACK
+ stack_enable := 1
+else
+ stack_enable := 0
+endif
+
ifdef CONFIG_KASAN_GENERIC
ifdef CONFIG_KASAN_INLINE
@@ -27,7 +33,7 @@ else
CFLAGS_KASAN := $(CFLAGS_KASAN_SHADOW) \
$(call cc-param,asan-globals=1) \
$(call cc-param,asan-instrumentation-with-call-threshold=$(call_threshold)) \
- $(call cc-param,asan-stack=$(CONFIG_KASAN_STACK)) \
+ $(call cc-param,asan-stack=$(stack_enable)) \
$(call cc-param,asan-instrument-allocas=1)
endif
@@ -42,7 +48,7 @@ else
endif
CFLAGS_KASAN := -fsanitize=kernel-hwaddress \
- $(call cc-param,hwasan-instrument-stack=$(CONFIG_KASAN_STACK)) \
+ $(call cc-param,hwasan-instrument-stack=$(stack_enable)) \
$(call cc-param,hwasan-use-short-granules=0) \
$(instrumentation_flags)
--- a/security/Kconfig.hardening~kasan-remove-redundant-config-option
+++ a/security/Kconfig.hardening
@@ -64,7 +64,7 @@ choice
config GCC_PLUGIN_STRUCTLEAK_BYREF
bool "zero-init structs passed by reference (strong)"
depends on GCC_PLUGINS
- depends on !(KASAN && KASAN_STACK=1)
+ depends on !(KASAN && KASAN_STACK)
select GCC_PLUGIN_STRUCTLEAK
help
Zero-initialize any structures on the stack that may
@@ -82,7 +82,7 @@ choice
config GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
bool "zero-init anything passed by reference (very strong)"
depends on GCC_PLUGINS
- depends on !(KASAN && KASAN_STACK=1)
+ depends on !(KASAN && KASAN_STACK)
select GCC_PLUGIN_STRUCTLEAK
help
Zero-initialize any stack variables that may be passed
_
^ permalink raw reply [flat|nested] 22+ messages in thread
* [patch 07/16] mm/gup: check page posion status for coredump.
2021-04-09 20:26 incoming Andrew Morton
` (5 preceding siblings ...)
2021-04-09 20:27 ` [patch 06/16] kasan: remove redundant config option Andrew Morton
@ 2021-04-09 20:27 ` Andrew Morton
2021-04-09 20:27 ` [patch 08/16] nds32: flush_dcache_page: use page_mapping_file to avoid races with swapoff Andrew Morton
` (8 subsequent siblings)
15 siblings, 0 replies; 22+ messages in thread
From: Andrew Morton @ 2021-04-09 20:27 UTC (permalink / raw)
To: akpm, david, linux-mm, mike.kravetz, mm-commits, naoya.horiguchi,
osalvador, torvalds, willy, yaoaili
From: Aili Yao <yaoaili@kingsoft.com>
Subject: mm/gup: check page posion status for coredump.
When we do coredump for user process signal, this may be an SIGBUS signal
with BUS_MCEERR_AR or BUS_MCEERR_AO code, which means this signal is
resulted from ECC memory fail like SRAR or SRAO, we expect the memory
recovery work is finished correctly, then the get_dump_page() will not
return the error page as its process pte is set invalid by
memory_failure().
But memory_failure() may fail, and the process's related pte may not be
correctly set invalid, for current code, we will return the poison page,
get it dumped, and then lead to system panic as its in kernel code.
So check the poison status in get_dump_page(), and if TRUE, return NULL.
There maybe other scenario that is also better to check the posion status
and not to panic, so make a wrapper for this check, Thanks to David's
suggestion(<david@redhat.com>).
[akpm@linux-foundation.org: s/0/false/]
[yaoaili@kingsoft.com: is_page_poisoned() arg cannot be null, per Matthew]
Link: https://lkml.kernel.org/r/20210319104437.6f30e80d@alex-virtual-machine
Link: https://lkml.kernel.org/r/20210322115233.05e4e82a@alex-virtual-machine
Link: https://lkml.kernel.org/r/20210319104437.6f30e80d@alex-virtual-machine
Signed-off-by: Aili Yao <yaoaili@kingsoft.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Aili Yao <yaoaili@kingsoft.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/gup.c | 4 ++++
mm/internal.h | 20 ++++++++++++++++++++
2 files changed, 24 insertions(+)
--- a/mm/gup.c~mm-gup-check-page-posion-status-for-coredump
+++ a/mm/gup.c
@@ -1535,6 +1535,10 @@ struct page *get_dump_page(unsigned long
FOLL_FORCE | FOLL_DUMP | FOLL_GET);
if (locked)
mmap_read_unlock(mm);
+
+ if (ret == 1 && is_page_poisoned(page))
+ return NULL;
+
return (ret == 1) ? page : NULL;
}
#endif /* CONFIG_ELF_CORE */
--- a/mm/internal.h~mm-gup-check-page-posion-status-for-coredump
+++ a/mm/internal.h
@@ -97,6 +97,26 @@ static inline void set_page_refcounted(s
set_page_count(page, 1);
}
+/*
+ * When kernel touch the user page, the user page may be have been marked
+ * poison but still mapped in user space, if without this page, the kernel
+ * can guarantee the data integrity and operation success, the kernel is
+ * better to check the posion status and avoid touching it, be good not to
+ * panic, coredump for process fatal signal is a sample case matching this
+ * scenario. Or if kernel can't guarantee the data integrity, it's better
+ * not to call this function, let kernel touch the poison page and get to
+ * panic.
+ */
+static inline bool is_page_poisoned(struct page *page)
+{
+ if (PageHWPoison(page))
+ return true;
+ else if (PageHuge(page) && PageHWPoison(compound_head(page)))
+ return true;
+
+ return false;
+}
+
extern unsigned long highest_memmap_pfn;
/*
_
^ permalink raw reply [flat|nested] 22+ messages in thread
* [patch 08/16] nds32: flush_dcache_page: use page_mapping_file to avoid races with swapoff
2021-04-09 20:26 incoming Andrew Morton
` (6 preceding siblings ...)
2021-04-09 20:27 ` [patch 07/16] mm/gup: check page posion status for coredump Andrew Morton
@ 2021-04-09 20:27 ` Andrew Morton
2021-04-09 20:27 ` [patch 09/16] gcov: re-fix clang-11+ support Andrew Morton
` (7 subsequent siblings)
15 siblings, 0 replies; 22+ messages in thread
From: Andrew Morton @ 2021-04-09 20:27 UTC (permalink / raw)
To: akpm, deanbo422, green.hu, linux-mm, mm-commits, nickhu, rppt,
stable, torvalds, willy, ying.huang
From: Mike Rapoport <rppt@linux.ibm.com>
Subject: nds32: flush_dcache_page: use page_mapping_file to avoid races with swapoff
Commit cb9f753a3731 ("mm: fix races between swapoff and flush dcache")
updated flush_dcache_page implementations on several architectures to use
page_mapping_file() in order to avoid races between page_mapping() and
swapoff().
This update missed arch/nds32 and there is a possibility of a race there.
Replace page_mapping() with page_mapping_file() in nds32 implementation of
flush_dcache_page().
Link: https://lkml.kernel.org/r/20210330175126.26500-1-rppt@kernel.org
Fixes: cb9f753a3731 ("mm: fix races between swapoff and flush dcache")
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Acked-by: Greentime Hu <green.hu@gmail.com>
Cc: Huang Ying <ying.huang@intel.com>
Cc: Nick Hu <nickhu@andestech.com>
Cc: Vincent Chen <deanbo422@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/nds32/mm/cacheflush.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/nds32/mm/cacheflush.c~nds32-flush_dcache_page-use-page_mapping_file-to-avoid-races-with-swapoff
+++ a/arch/nds32/mm/cacheflush.c
@@ -238,7 +238,7 @@ void flush_dcache_page(struct page *page
{
struct address_space *mapping;
- mapping = page_mapping(page);
+ mapping = page_mapping_file(page);
if (mapping && !mapping_mapped(mapping))
set_bit(PG_dcache_dirty, &page->flags);
else {
_
^ permalink raw reply [flat|nested] 22+ messages in thread
* [patch 09/16] gcov: re-fix clang-11+ support
2021-04-09 20:26 incoming Andrew Morton
` (7 preceding siblings ...)
2021-04-09 20:27 ` [patch 08/16] nds32: flush_dcache_page: use page_mapping_file to avoid races with swapoff Andrew Morton
@ 2021-04-09 20:27 ` Andrew Morton
2021-04-09 20:27 ` [patch 10/16] ocfs2: fix deadlock between setattr and dio_end_io_write Andrew Morton
` (6 subsequent siblings)
15 siblings, 0 replies; 22+ messages in thread
From: Andrew Morton @ 2021-04-09 20:27 UTC (permalink / raw)
To: akpm, linux-mm, mm-commits, nathan, ndesaulniers, psodagud,
stable, torvalds
From: Nick Desaulniers <ndesaulniers@google.com>
Subject: gcov: re-fix clang-11+ support
LLVM changed the expected function signature for llvm_gcda_emit_function()
in the clang-11 release. Users of clang-11 or newer may have noticed
their kernels producing invalid coverage information:
$ llvm-cov gcov -a -c -u -f -b <input>.gcda -- gcno=<input>.gcno
1 <func>: checksum mismatch, \
(<lineno chksum A>, <cfg chksum B>) != (<lineno chksum A>, <cfg chksum C>)
2 Invalid .gcda File!
...
Fix up the function signatures so calling this function interprets its
parameters correctly and computes the correct cfg checksum. In
particular, in clang-11, the additional checksum is no longer optional.
Link: https://reviews.llvm.org/rG25544ce2df0daa4304c07e64b9c8b0f7df60c11d
Link: https://lkml.kernel.org/r/20210408184631.1156669-1-ndesaulniers@google.com
Reported-by: Prasad Sodagudi <psodagud@quicinc.com>
Tested-by: Prasad Sodagudi <psodagud@quicinc.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Cc: <stable@vger.kernel.org> [5.4+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/gcov/clang.c | 29 +++++++++++++++++++----------
1 file changed, 19 insertions(+), 10 deletions(-)
--- a/kernel/gcov/clang.c~gcov-re-fix-clang-11-support
+++ a/kernel/gcov/clang.c
@@ -70,7 +70,9 @@ struct gcov_fn_info {
u32 ident;
u32 checksum;
+#if CONFIG_CLANG_VERSION < 110000
u8 use_extra_checksum;
+#endif
u32 cfg_checksum;
u32 num_counters;
@@ -145,10 +147,8 @@ void llvm_gcda_emit_function(u32 ident,
list_add_tail(&info->head, ¤t_info->functions);
}
-EXPORT_SYMBOL(llvm_gcda_emit_function);
#else
-void llvm_gcda_emit_function(u32 ident, u32 func_checksum,
- u8 use_extra_checksum, u32 cfg_checksum)
+void llvm_gcda_emit_function(u32 ident, u32 func_checksum, u32 cfg_checksum)
{
struct gcov_fn_info *info = kzalloc(sizeof(*info), GFP_KERNEL);
@@ -158,12 +158,11 @@ void llvm_gcda_emit_function(u32 ident,
INIT_LIST_HEAD(&info->head);
info->ident = ident;
info->checksum = func_checksum;
- info->use_extra_checksum = use_extra_checksum;
info->cfg_checksum = cfg_checksum;
list_add_tail(&info->head, ¤t_info->functions);
}
-EXPORT_SYMBOL(llvm_gcda_emit_function);
#endif
+EXPORT_SYMBOL(llvm_gcda_emit_function);
void llvm_gcda_emit_arcs(u32 num_counters, u64 *counters)
{
@@ -293,11 +292,16 @@ int gcov_info_is_compatible(struct gcov_
!list_is_last(&fn_ptr2->head, &info2->functions)) {
if (fn_ptr1->checksum != fn_ptr2->checksum)
return false;
+#if CONFIG_CLANG_VERSION < 110000
if (fn_ptr1->use_extra_checksum != fn_ptr2->use_extra_checksum)
return false;
if (fn_ptr1->use_extra_checksum &&
fn_ptr1->cfg_checksum != fn_ptr2->cfg_checksum)
return false;
+#else
+ if (fn_ptr1->cfg_checksum != fn_ptr2->cfg_checksum)
+ return false;
+#endif
fn_ptr1 = list_next_entry(fn_ptr1, head);
fn_ptr2 = list_next_entry(fn_ptr2, head);
}
@@ -529,17 +533,22 @@ static size_t convert_to_gcda(char *buff
list_for_each_entry(fi_ptr, &info->functions, head) {
u32 i;
- u32 len = 2;
-
- if (fi_ptr->use_extra_checksum)
- len++;
pos += store_gcov_u32(buffer, pos, GCOV_TAG_FUNCTION);
- pos += store_gcov_u32(buffer, pos, len);
+#if CONFIG_CLANG_VERSION < 110000
+ pos += store_gcov_u32(buffer, pos,
+ fi_ptr->use_extra_checksum ? 3 : 2);
+#else
+ pos += store_gcov_u32(buffer, pos, 3);
+#endif
pos += store_gcov_u32(buffer, pos, fi_ptr->ident);
pos += store_gcov_u32(buffer, pos, fi_ptr->checksum);
+#if CONFIG_CLANG_VERSION < 110000
if (fi_ptr->use_extra_checksum)
pos += store_gcov_u32(buffer, pos, fi_ptr->cfg_checksum);
+#else
+ pos += store_gcov_u32(buffer, pos, fi_ptr->cfg_checksum);
+#endif
pos += store_gcov_u32(buffer, pos, GCOV_TAG_COUNTER_BASE);
pos += store_gcov_u32(buffer, pos, fi_ptr->num_counters * 2);
_
^ permalink raw reply [flat|nested] 22+ messages in thread
* [patch 10/16] ocfs2: fix deadlock between setattr and dio_end_io_write
2021-04-09 20:26 incoming Andrew Morton
` (8 preceding siblings ...)
2021-04-09 20:27 ` [patch 09/16] gcov: re-fix clang-11+ support Andrew Morton
@ 2021-04-09 20:27 ` Andrew Morton
2021-04-09 20:27 ` [patch 11/16] ia64: fix user_stack_pointer() for ptrace() Andrew Morton
` (5 subsequent siblings)
15 siblings, 0 replies; 22+ messages in thread
From: Andrew Morton @ 2021-04-09 20:27 UTC (permalink / raw)
To: akpm, gechangwei, ghe, jlbec, joseph.qi, junxiao.bi, linux-mm,
mark, mm-commits, piaojun, stable, torvalds, wen.gang.wang
From: Wengang Wang <wen.gang.wang@oracle.com>
Subject: ocfs2: fix deadlock between setattr and dio_end_io_write
The following deadlock is detected:
truncate -> setattr path is waiting for pending direct IO to be done (
inode->i_dio_count become zero) with inode->i_rwsem held (down_write).
PID: 14827 TASK: ffff881686a9af80 CPU: 20 COMMAND: "ora_p005_hrltd9"
#0 [ffffc9000bcf3c08] __schedule at ffffffff818667cc
#1 [ffffc9000bcf3ca0] schedule at ffffffff81866de6
#2 [ffffc9000bcf3cb8] inode_dio_wait at ffffffff812a2d04
#3 [ffffc9000bcf3d28] ocfs2_setattr at ffffffffc05f322e [ocfs2]
#4 [ffffc9000bcf3e18] notify_change at ffffffff812a5a09
#5 [ffffc9000bcf3e60] do_truncate at ffffffff812808f5
#6 [ffffc9000bcf3ed8] do_sys_ftruncate.constprop.18 at ffffffff81280cf2
#7 [ffffc9000bcf3f18] sys_ftruncate at ffffffff81280d8e
#8 [ffffc9000bcf3f28] do_syscall_64 at ffffffff81003949
#9 [ffffc9000bcf3f50] entry_SYSCALL_64_after_hwframe at ffffffff81a001ad
dio completion path is going to complete one direct IO (decrement
inode->i_dio_count), but before that it hang at locking inode->i_rwsem.
#0 [ffffc90009b47b40] __schedule+700 at ffffffff818667cc
#1 [ffffc90009b47bd8] schedule+54 at ffffffff81866de6
#2 [ffffc90009b47bf0] rwsem_down_write_failed+536 at ffffffff8186aa28
#3 [ffffc90009b47c88] call_rwsem_down_write_failed+23 at ffffffff8185a1b7
#4 [ffffc90009b47cd0] down_write+45 at ffffffff81869c9d
#5 [ffffc90009b47ce8] ocfs2_dio_end_io_write+180 at ffffffffc05d5444 [ocfs2]
#6 [ffffc90009b47dd8] ocfs2_dio_end_io+85 at ffffffffc05d5a85 [ocfs2]
#7 [ffffc90009b47e18] dio_complete+140 at ffffffff812c873c
#8 [ffffc90009b47e50] dio_aio_complete_work+25 at ffffffff812c89f9
#9 [ffffc90009b47e60] process_one_work+361 at ffffffff810b1889
#10 [ffffc90009b47ea8] worker_thread+77 at ffffffff810b233d
#11 [ffffc90009b47f08] kthread+261 at ffffffff810b7fd5
#12 [ffffc90009b47f50] ret_from_fork+62 at ffffffff81a0035e
Thus above forms ABBA deadlock. The same deadlock was mentioned in
upstream commit 28f5a8a7c033cbf3e32277f4cc9c6afd74f05300. well, it seems
that that commit just removed cluster lock (the victim of above dead lock)
from the ABBA deadlock party.
End-user visible effects: Process hang in truncate -> ocfs2_setattr path
and other processes hang at ocfs2_dio_end_io_write path.
This is to fix the deadlock itself. It removes inode_lock() call from dio
completion path to remove the deadlock and add ip_alloc_sem lock in
setattr path to synchronize the inode modifications.
[wen.gang.wang@oracle.com: remove the "had_alloc_lock" as suggested]
Link: https://lkml.kernel.org/r/20210402171344.1605-1-wen.gang.wang@oracle.com
Link: https://lkml.kernel.org/r/20210331203654.3911-1-wen.gang.wang@oracle.com
Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com>
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Cc: Mark Fasheh <mark@fasheh.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Changwei Ge <gechangwei@live.cn>
Cc: Gang He <ghe@suse.com>
Cc: Jun Piao <piaojun@huawei.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/ocfs2/aops.c | 11 +----------
fs/ocfs2/file.c | 8 ++++++--
2 files changed, 7 insertions(+), 12 deletions(-)
--- a/fs/ocfs2/aops.c~ocfs2-fix-deadlock-between-setattr-and-dio_end_io_write
+++ a/fs/ocfs2/aops.c
@@ -2295,7 +2295,7 @@ static int ocfs2_dio_end_io_write(struct
struct ocfs2_alloc_context *meta_ac = NULL;
handle_t *handle = NULL;
loff_t end = offset + bytes;
- int ret = 0, credits = 0, locked = 0;
+ int ret = 0, credits = 0;
ocfs2_init_dealloc_ctxt(&dealloc);
@@ -2306,13 +2306,6 @@ static int ocfs2_dio_end_io_write(struct
!dwc->dw_orphaned)
goto out;
- /* ocfs2_file_write_iter will get i_mutex, so we need not lock if we
- * are in that context. */
- if (dwc->dw_writer_pid != task_pid_nr(current)) {
- inode_lock(inode);
- locked = 1;
- }
-
ret = ocfs2_inode_lock(inode, &di_bh, 1);
if (ret < 0) {
mlog_errno(ret);
@@ -2393,8 +2386,6 @@ out:
if (meta_ac)
ocfs2_free_alloc_context(meta_ac);
ocfs2_run_deallocs(osb, &dealloc);
- if (locked)
- inode_unlock(inode);
ocfs2_dio_free_write_ctx(inode, dwc);
return ret;
--- a/fs/ocfs2/file.c~ocfs2-fix-deadlock-between-setattr-and-dio_end_io_write
+++ a/fs/ocfs2/file.c
@@ -1245,22 +1245,24 @@ int ocfs2_setattr(struct user_namespace
goto bail_unlock;
}
}
+ down_write(&OCFS2_I(inode)->ip_alloc_sem);
handle = ocfs2_start_trans(osb, OCFS2_INODE_UPDATE_CREDITS +
2 * ocfs2_quota_trans_credits(sb));
if (IS_ERR(handle)) {
status = PTR_ERR(handle);
mlog_errno(status);
- goto bail_unlock;
+ goto bail_unlock_alloc;
}
status = __dquot_transfer(inode, transfer_to);
if (status < 0)
goto bail_commit;
} else {
+ down_write(&OCFS2_I(inode)->ip_alloc_sem);
handle = ocfs2_start_trans(osb, OCFS2_INODE_UPDATE_CREDITS);
if (IS_ERR(handle)) {
status = PTR_ERR(handle);
mlog_errno(status);
- goto bail_unlock;
+ goto bail_unlock_alloc;
}
}
@@ -1273,6 +1275,8 @@ int ocfs2_setattr(struct user_namespace
bail_commit:
ocfs2_commit_trans(osb, handle);
+bail_unlock_alloc:
+ up_write(&OCFS2_I(inode)->ip_alloc_sem);
bail_unlock:
if (status && inode_locked) {
ocfs2_inode_unlock_tracker(inode, 1, &oh, had_lock);
_
^ permalink raw reply [flat|nested] 22+ messages in thread
* [patch 11/16] ia64: fix user_stack_pointer() for ptrace()
2021-04-09 20:26 incoming Andrew Morton
` (9 preceding siblings ...)
2021-04-09 20:27 ` [patch 10/16] ocfs2: fix deadlock between setattr and dio_end_io_write Andrew Morton
@ 2021-04-09 20:27 ` Andrew Morton
2021-04-09 20:27 ` [patch 12/16] fs: direct-io: fix missing sdio->boundary Andrew Morton
` (4 subsequent siblings)
15 siblings, 0 replies; 22+ messages in thread
From: Andrew Morton @ 2021-04-09 20:27 UTC (permalink / raw)
To: akpm, ldv, linux-mm, mm-commits, oleg, slyfox, stable, torvalds
From: Sergei Trofimovich <slyfox@gentoo.org>
Subject: ia64: fix user_stack_pointer() for ptrace()
ia64 has two stacks:
- memory stack (or stack), pointed at by by r12
- register backing store (register stack), pointed at
ar.bsp/ar.bspstore with complications around dirty
register frame on CPU.
In https://bugs.gentoo.org/769614 Dmitry noticed that
PTRACE_GET_SYSCALL_INFO returns register stack instead
memory stack.
The bug comes from the fact that user_stack_pointer() and
current_user_stack_pointer() don't return the same register:
ulong user_stack_pointer(struct pt_regs *regs) { return regs->ar_bspstore; }
#define current_user_stack_pointer() (current_pt_regs()->r12)
The change gets both back in sync.
I think ptrace(PTRACE_GET_SYSCALL_INFO) is the only affected user
by this bug on ia64.
The change fixes 'rt_sigreturn.gen.test' strace test where
it was observed initially.
Link: https://lkml.kernel.org/r/20210331084447.2561532-1-slyfox@gentoo.org
Link: https://bugs.gentoo.org/769614
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Reported-by: Dmitry V. Levin <ldv@altlinux.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/ia64/include/asm/ptrace.h | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
--- a/arch/ia64/include/asm/ptrace.h~ia64-fix-user_stack_pointer-for-ptrace
+++ a/arch/ia64/include/asm/ptrace.h
@@ -54,8 +54,7 @@
static inline unsigned long user_stack_pointer(struct pt_regs *regs)
{
- /* FIXME: should this be bspstore + nr_dirty regs? */
- return regs->ar_bspstore;
+ return regs->r12;
}
static inline int is_syscall_success(struct pt_regs *regs)
@@ -79,11 +78,6 @@ static inline long regs_return_value(str
unsigned long __ip = instruction_pointer(regs); \
(__ip & ~3UL) + ((__ip & 3UL) << 2); \
})
-/*
- * Why not default? Because user_stack_pointer() on ia64 gives register
- * stack backing store instead...
- */
-#define current_user_stack_pointer() (current_pt_regs()->r12)
/* given a pointer to a task_struct, return the user's pt_regs */
# define task_pt_regs(t) (((struct pt_regs *) ((char *) (t) + IA64_STK_OFFSET)) - 1)
_
^ permalink raw reply [flat|nested] 22+ messages in thread
* [patch 12/16] fs: direct-io: fix missing sdio->boundary
2021-04-09 20:26 incoming Andrew Morton
` (10 preceding siblings ...)
2021-04-09 20:27 ` [patch 11/16] ia64: fix user_stack_pointer() for ptrace() Andrew Morton
@ 2021-04-09 20:27 ` Andrew Morton
2021-04-09 20:27 ` [patch 13/16] kasan: fix conflict with page poisoning Andrew Morton
` (3 subsequent siblings)
15 siblings, 0 replies; 22+ messages in thread
From: Andrew Morton @ 2021-04-09 20:27 UTC (permalink / raw)
To: akpm, jack.qiu, jack, linux-mm, mm-commits, stable, torvalds
From: Jack Qiu <jack.qiu@huawei.com>
Subject: fs: direct-io: fix missing sdio->boundary
I encountered a hung task issue, but not a performance one. I run DIO
on a device (need lba continuous, for example open channel ssd), maybe
hungtask in below case:
DIO: Checkpoint:
get addr A(at boundary), merge into BIO,
no submit because boundary missing
flush dirty data(get addr A+1), wait IO(A+1)
writeback timeout, because DIO(A) didn't submit
get addr A+2 fail, because checkpoint is doing
dio_send_cur_page() may clear sdio->boundary, so prevent it from
missing a boundary.
Link: https://lkml.kernel.org/r/20210322042253.38312-1-jack.qiu@huawei.com
Fixes: b1058b981272 ("direct-io: submit bio after boundary buffer is
added to it")
Signed-off-by: Jack Qiu <jack.qiu@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/direct-io.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/fs/direct-io.c~fs-direct-io-fix-missing-sdio-boundary
+++ a/fs/direct-io.c
@@ -812,6 +812,7 @@ submit_page_section(struct dio *dio, str
struct buffer_head *map_bh)
{
int ret = 0;
+ int boundary = sdio->boundary; /* dio_send_cur_page may clear it */
if (dio->op == REQ_OP_WRITE) {
/*
@@ -850,10 +851,10 @@ submit_page_section(struct dio *dio, str
sdio->cur_page_fs_offset = sdio->block_in_file << sdio->blkbits;
out:
/*
- * If sdio->boundary then we want to schedule the IO now to
+ * If boundary then we want to schedule the IO now to
* avoid metadata seeks.
*/
- if (sdio->boundary) {
+ if (boundary) {
ret = dio_send_cur_page(dio, sdio, map_bh);
if (sdio->bio)
dio_bio_submit(dio, sdio);
_
^ permalink raw reply [flat|nested] 22+ messages in thread
* [patch 13/16] kasan: fix conflict with page poisoning
2021-04-09 20:26 incoming Andrew Morton
` (11 preceding siblings ...)
2021-04-09 20:27 ` [patch 12/16] fs: direct-io: fix missing sdio->boundary Andrew Morton
@ 2021-04-09 20:27 ` Andrew Morton
2021-04-09 20:27 ` [patch 14/16] lib/test_kasan_module.c: suppress unused var warning Andrew Morton
` (2 subsequent siblings)
15 siblings, 0 replies; 22+ messages in thread
From: Andrew Morton @ 2021-04-09 20:27 UTC (permalink / raw)
To: akpm, andreyknvl, andreyknvl, aryabinin, dvyukov, elver, glider,
linux-mm, mm-commits, torvalds
From: Andrey Konovalov <andreyknvl@google.com>
Subject: kasan: fix conflict with page poisoning
When page poisoning is enabled, it accesses memory that is marked as
poisoned by KASAN, which leas to false-positive KASAN reports.
Suppress the reports by adding KASAN annotations to unpoison_page()
(poison_page() already has them).
Link: https://lkml.kernel.org/r/2dc799014d31ac13fd97bd906bad33e16376fc67.1617118501.git.andreyknvl@google.com
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Marco Elver <elver@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/page_poison.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/mm/page_poison.c~kasan-fix-conflict-with-page-poisoning
+++ a/mm/page_poison.c
@@ -77,12 +77,14 @@ static void unpoison_page(struct page *p
void *addr;
addr = kmap_atomic(page);
+ kasan_disable_current();
/*
* Page poisoning when enabled poisons each and every page
* that is freed to buddy. Thus no extra check is done to
* see if a page was poisoned.
*/
- check_poison_mem(addr, PAGE_SIZE);
+ check_poison_mem(kasan_reset_tag(addr), PAGE_SIZE);
+ kasan_enable_current();
kunmap_atomic(addr);
}
_
^ permalink raw reply [flat|nested] 22+ messages in thread
* [patch 14/16] lib/test_kasan_module.c: suppress unused var warning
2021-04-09 20:26 incoming Andrew Morton
` (12 preceding siblings ...)
2021-04-09 20:27 ` [patch 13/16] kasan: fix conflict with page poisoning Andrew Morton
@ 2021-04-09 20:27 ` Andrew Morton
2021-04-09 20:27 ` [patch 15/16] kfence, x86: fix preemptible warning on KPTI-enabled systems Andrew Morton
2021-04-09 20:27 ` [patch 16/16] lib: fix kconfig dependency on ARCH_WANT_FRAME_POINTERS Andrew Morton
15 siblings, 0 replies; 22+ messages in thread
From: Andrew Morton @ 2021-04-09 20:27 UTC (permalink / raw)
To: akpm, elver, glider, linux-mm, lkp, mm-commits, torvalds
From: Andrew Morton <akpm@linux-foundation.org>
Subject: lib/test_kasan_module.c: suppress unused var warning
Local `unused' is intentionally unused - it is there to suppress
__must_check warnings.
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lkml.kernel.org/r/202104050216.HflRxfJm-lkp@intel.com
Cc: Marco Elver <elver@google.com>
Cc: Alexander Potapenko <glider@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/test_kasan_module.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/lib/test_kasan_module.c~lib-test_kasan_modulec-suppress-unused-var-warning
+++ a/lib/test_kasan_module.c
@@ -22,7 +22,7 @@ static noinline void __init copy_user_te
char *kmem;
char __user *usermem;
size_t size = 10;
- int unused;
+ int __maybe_unused unused;
kmem = kmalloc(size, GFP_KERNEL);
if (!kmem)
_
^ permalink raw reply [flat|nested] 22+ messages in thread
* [patch 15/16] kfence, x86: fix preemptible warning on KPTI-enabled systems
2021-04-09 20:26 incoming Andrew Morton
` (13 preceding siblings ...)
2021-04-09 20:27 ` [patch 14/16] lib/test_kasan_module.c: suppress unused var warning Andrew Morton
@ 2021-04-09 20:27 ` Andrew Morton
2021-04-09 20:27 ` [patch 16/16] lib: fix kconfig dependency on ARCH_WANT_FRAME_POINTERS Andrew Morton
15 siblings, 0 replies; 22+ messages in thread
From: Andrew Morton @ 2021-04-09 20:27 UTC (permalink / raw)
To: akpm, andreyknvl, dvyukov, elver, glider, jannh, linux-mm,
mm-commits, tomi.p.sarvela, torvalds
From: Marco Elver <elver@google.com>
Subject: kfence, x86: fix preemptible warning on KPTI-enabled systems
On systems with KPTI enabled, we can currently observe the following
warning:
BUG: using smp_processor_id() in preemptible
caller is invalidate_user_asid+0x13/0x50
CPU: 6 PID: 1075 Comm: dmesg Not tainted 5.12.0-rc4-gda4a2b1a5479-kfence_1+ #1
Hardware name: Hewlett-Packard HP Pro 3500 Series/2ABF, BIOS 8.11 10/24/2012
Call Trace:
dump_stack+0x7f/0xad
check_preemption_disabled+0xc8/0xd0
invalidate_user_asid+0x13/0x50
flush_tlb_one_kernel+0x5/0x20
kfence_protect+0x56/0x80
...
While it normally makes sense to require preemption to be off, so that the
expected CPU's TLB is flushed and not another, in our case it really is
best-effort (see comments in kfence_protect_page()).
Avoid the warning by disabling preemption around flush_tlb_one_kernel().
Link: https://lore.kernel.org/lkml/YGIDBAboELGgMgXy@elver.google.com/
Link: https://lkml.kernel.org/r/20210330065737.652669-1-elver@google.com
Signed-off-by: Marco Elver <elver@google.com>
Reported-by: Tomi Sarvela <tomi.p.sarvela@intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Jann Horn <jannh@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/x86/include/asm/kfence.h | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/arch/x86/include/asm/kfence.h~kfence-x86-fix-preemptible-warning-on-kpti-enabled-systems
+++ a/arch/x86/include/asm/kfence.h
@@ -56,8 +56,13 @@ static inline bool kfence_protect_page(u
else
set_pte(pte, __pte(pte_val(*pte) | _PAGE_PRESENT));
- /* Flush this CPU's TLB. */
+ /*
+ * Flush this CPU's TLB, assuming whoever did the allocation/free is
+ * likely to continue running on this CPU.
+ */
+ preempt_disable();
flush_tlb_one_kernel(addr);
+ preempt_enable();
return true;
}
_
^ permalink raw reply [flat|nested] 22+ messages in thread
* [patch 16/16] lib: fix kconfig dependency on ARCH_WANT_FRAME_POINTERS
2021-04-09 20:26 incoming Andrew Morton
` (14 preceding siblings ...)
2021-04-09 20:27 ` [patch 15/16] kfence, x86: fix preemptible warning on KPTI-enabled systems Andrew Morton
@ 2021-04-09 20:27 ` Andrew Morton
15 siblings, 0 replies; 22+ messages in thread
From: Andrew Morton @ 2021-04-09 20:27 UTC (permalink / raw)
To: akpm, fazilyildiran, geert, julianbraha, linux-mm, mm-commits,
schwab, torvalds
From: Julian Braha <julianbraha@gmail.com>
Subject: lib: fix kconfig dependency on ARCH_WANT_FRAME_POINTERS
When LATENCYTOP, LOCKDEP, or FAULT_INJECTION_STACKTRACE_FILTER is enabled
and ARCH_WANT_FRAME_POINTERS is disabled, Kbuild gives a warning such as:
WARNING: unmet direct dependencies detected for FRAME_POINTER
Depends on [n]: DEBUG_KERNEL [=y] && (M68K || UML || SUPERH) || ARCH_WANT_FRAME_POINTERS [=n] || MCOUNT [=n]
Selected by [y]:
- LATENCYTOP [=y] && DEBUG_KERNEL [=y] && STACKTRACE_SUPPORT [=y] && PROC_FS [=y] && !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM && !ARC && !X86
Depending on ARCH_WANT_FRAME_POINTERS causes a recursive dependency error.
ARCH_WANT_FRAME_POINTERS is to be selected by the architecture, and is
not supposed to be overridden by other config options.
Link: https://lkml.kernel.org/r/20210329165329.27994-1-julianbraha@gmail.com
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Cc: Andreas Schwab <schwab@linux-m68k.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Necip Fazil Yildiran <fazilyildiran@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/Kconfig.debug | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/lib/Kconfig.debug~lib-fix-kconfig-dependency-on-arch_want_frame_pointers
+++ a/lib/Kconfig.debug
@@ -1363,7 +1363,7 @@ config LOCKDEP
bool
depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
select STACKTRACE
- select FRAME_POINTER if !MIPS && !PPC && !ARM && !S390 && !MICROBLAZE && !ARC && !X86
+ depends on FRAME_POINTER || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86
select KALLSYMS
select KALLSYMS_ALL
@@ -1665,7 +1665,7 @@ config LATENCYTOP
depends on DEBUG_KERNEL
depends on STACKTRACE_SUPPORT
depends on PROC_FS
- select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM && !ARC && !X86
+ depends on FRAME_POINTER || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86
select KALLSYMS
select KALLSYMS_ALL
select STACKTRACE
@@ -1918,7 +1918,7 @@ config FAULT_INJECTION_STACKTRACE_FILTER
depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT
depends on !X86_64
select STACKTRACE
- select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM && !ARC && !X86
+ depends on FRAME_POINTER || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86
help
Provide stacktrace filter for fault-injection capabilities
_
^ permalink raw reply [flat|nested] 22+ messages in thread