date:20200605

Add maintainer entry for new Broadcom VK Driver

Signed-off-by: Scott Branden 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 411cd97bb485..ced084c526df 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3656,6 +3656,13 @@ L:   net...@vger.kernel.org
 S: Supported
 F: drivers/net/ethernet/broadcom/tg3.*
 
+BROADCOM VK DRIVER
+M: Scott Branden 
+L: bcm-kernel-feedback-l...@broadcom.com
+S: Supported
+F: drivers/misc/bcm-vk/
+F: include/uapi/linux/misc/bcm_vk.h
+
 BROCADE BFA FC SCSI DRIVER
 M: Anil Gurumurthy 
 M: Sudarsana Kalluru 
-- 
2.17.1

[PATCH v7 8/8] ima: add FIRMWARE_PARTIAL_READ support

Add FIRMWARE_PARTIAL_READ support for integrity
measurement on partial reads of firmware files.

Signed-off-by: Scott Branden 
---
 drivers/base/firmware_loader/main.c |  6 +-
 fs/exec.c   |  6 --
 include/linux/fs.h  |  1 +
 security/integrity/ima/ima_main.c   | 24 +++-
 4 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/drivers/base/firmware_loader/main.c 
b/drivers/base/firmware_loader/main.c
index 93e7fee42cd4..d0c42194af17 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -483,7 +483,11 @@ fw_get_filesystem_firmware(struct device *device, struct 
fw_priv *fw_priv,
/* Already populated data member means we're loading into a buffer */
if (!decompress && fw_priv->data) {
buffer = fw_priv->data;
-   id = READING_FIRMWARE_PREALLOC_BUFFER;
+   if (fw_priv->opt == KERNEL_PREAD_PART)
+   id = READING_FIRMWARE_PARTIAL_READ;
+   else
+   id = READING_FIRMWARE_PREALLOC_BUFFER;
+
msize = fw_priv->allocated_size;
}
 
diff --git a/fs/exec.c b/fs/exec.c
index 751f5ddc7538..06e2465d8d40 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -970,7 +970,8 @@ int kernel_pread_file(struct file *file, void **buf, loff_t 
*size,
goto out;
}
 
-   if (id != READING_FIRMWARE_PREALLOC_BUFFER)
+   if ((id != READING_FIRMWARE_PARTIAL_READ) &&
+   (id != READING_FIRMWARE_PREALLOC_BUFFER))
*buf = vmalloc(alloc_size);
if (!*buf) {
ret = -ENOMEM;
@@ -1002,7 +1003,8 @@ int kernel_pread_file(struct file *file, void **buf, 
loff_t *size,
 
 out_free:
if (ret < 0) {
-   if (id != READING_FIRMWARE_PREALLOC_BUFFER) {
+   if ((id != READING_FIRMWARE_PARTIAL_READ) &&
+   (id != READING_FIRMWARE_PREALLOC_BUFFER)) {
vfree(*buf);
*buf = NULL;
}
diff --git a/include/linux/fs.h b/include/linux/fs.h
index aee7600958ef..1180091d704d 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -3020,6 +3020,7 @@ extern int do_pipe_flags(int *, int);
 #define __kernel_read_file_id(id) \
id(UNKNOWN, unknown)\
id(FIRMWARE, firmware)  \
+   id(FIRMWARE_PARTIAL_READ, firmware) \
id(FIRMWARE_PREALLOC_BUFFER, firmware)  \
id(FIRMWARE_EFI_EMBEDDED, firmware) \
id(MODULE, kernel-module)   \
diff --git a/security/integrity/ima/ima_main.c 
b/security/integrity/ima/ima_main.c
index 800fb3bba418..fc5134807acf 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -609,6 +609,9 @@ void ima_post_path_mknod(struct dentry *dentry)
  */
 int ima_read_file(struct file *file, enum kernel_read_file_id read_id)
 {
+   enum ima_hooks func;
+   u32 secid;
+
/*
 * READING_FIRMWARE_PREALLOC_BUFFER
 *
@@ -617,11 +620,27 @@ int ima_read_file(struct file *file, enum 
kernel_read_file_id read_id)
 * of IMA's signature verification any more than when using two
 * buffers?
 */
-   return 0;
+   if (read_id != READING_FIRMWARE_PARTIAL_READ)
+   return 0;
+
+   if (!file) {
+   if ((ima_appraise & IMA_APPRAISE_FIRMWARE) &&
+   (ima_appraise & IMA_APPRAISE_ENFORCE)) {
+   pr_err("Prevent firmware loading_store.\n");
+   return -EACCES; /* INTEGRITY_UNKNOWN */
+   }
+   return 0;
+   }
+
+   func = read_idmap[read_id] ?: FILE_CHECK;
+   security_task_getsecid(current, );
+   return process_measurement(file, current_cred(), secid, NULL,
+  0, MAY_READ, func);
 }
 
 const int read_idmap[READING_MAX_ID] = {
[READING_FIRMWARE] = FIRMWARE_CHECK,
+   [READING_FIRMWARE_PARTIAL_READ] = FIRMWARE_CHECK,
[READING_FIRMWARE_PREALLOC_BUFFER] = FIRMWARE_CHECK,
[READING_MODULE] = MODULE_CHECK,
[READING_KEXEC_IMAGE] = KEXEC_KERNEL_CHECK,
@@ -648,6 +667,9 @@ int ima_post_read_file(struct file *file, void *buf, loff_t 
size,
enum ima_hooks func;
u32 secid;
 
+   if (read_id == READING_FIRMWARE_PARTIAL_READ)
+   return 0;
+
if (!file && read_id == READING_FIRMWARE) {
if ((ima_appraise & IMA_APPRAISE_FIRMWARE) &&
(ima_appraise & IMA_APPRAISE_ENFORCE)) {
-- 
2.17.1

[PATCH v7 6/8] misc: bcm-vk: add Broadcom VK driver

Add Broadcom VK driver offload engine.
This driver interfaces to the VK PCIe offload engine to perform
should offload functions as video transcoding on multiple streams
in parallel.  VK device is booted from files loaded using
request_firmware_into_buf mechanism.  After booted card status is updated
and messages can then be sent to the card.
Such messages contain scatter gather list of addresses
to pull data from the host to perform operations on.

Signed-off-by: Scott Branden 
Signed-off-by: Desmond Yan 
Signed-off-by: James Hu 
---
 drivers/misc/Kconfig |1 +
 drivers/misc/Makefile|1 +
 drivers/misc/bcm-vk/Kconfig  |   29 +
 drivers/misc/bcm-vk/Makefile |   11 +
 drivers/misc/bcm-vk/bcm_vk.h |  408 +
 drivers/misc/bcm-vk/bcm_vk_dev.c | 1312 +++
 drivers/misc/bcm-vk/bcm_vk_msg.c | 1438 ++
 drivers/misc/bcm-vk/bcm_vk_msg.h |  201 +
 drivers/misc/bcm-vk/bcm_vk_sg.c  |  271 ++
 drivers/misc/bcm-vk/bcm_vk_sg.h  |   60 ++
 drivers/misc/bcm-vk/bcm_vk_tty.c |  352 
 11 files changed, 4084 insertions(+)
 create mode 100644 drivers/misc/bcm-vk/Kconfig
 create mode 100644 drivers/misc/bcm-vk/Makefile
 create mode 100644 drivers/misc/bcm-vk/bcm_vk.h
 create mode 100644 drivers/misc/bcm-vk/bcm_vk_dev.c
 create mode 100644 drivers/misc/bcm-vk/bcm_vk_msg.c
 create mode 100644 drivers/misc/bcm-vk/bcm_vk_msg.h
 create mode 100644 drivers/misc/bcm-vk/bcm_vk_sg.c
 create mode 100644 drivers/misc/bcm-vk/bcm_vk_sg.h
 create mode 100644 drivers/misc/bcm-vk/bcm_vk_tty.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index edd5dd5ebfdc..986fea8ea0f3 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -469,6 +469,7 @@ source "drivers/misc/genwqe/Kconfig"
 source "drivers/misc/echo/Kconfig"
 source "drivers/misc/cxl/Kconfig"
 source "drivers/misc/ocxl/Kconfig"
+source "drivers/misc/bcm-vk/Kconfig"
 source "drivers/misc/cardreader/Kconfig"
 source "drivers/misc/habanalabs/Kconfig"
 source "drivers/misc/uacce/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index c7bd01ac6291..766837e4b961 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_ECHO)+= echo/
 obj-$(CONFIG_CXL_BASE) += cxl/
 obj-$(CONFIG_PCI_ENDPOINT_TEST)+= pci_endpoint_test.o
 obj-$(CONFIG_OCXL) += ocxl/
+obj-$(CONFIG_BCM_VK)   += bcm-vk/
 obj-y  += cardreader/
 obj-$(CONFIG_PVPANIC)  += pvpanic.o
 obj-$(CONFIG_HABANA_AI)+= habanalabs/
diff --git a/drivers/misc/bcm-vk/Kconfig b/drivers/misc/bcm-vk/Kconfig
new file mode 100644
index ..a3a020b19e3b
--- /dev/null
+++ b/drivers/misc/bcm-vk/Kconfig
@@ -0,0 +1,29 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Broadcom VK device
+#
+config BCM_VK
+   tristate "Support for Broadcom VK Accelerators"
+   depends on PCI_MSI
+   help
+ Select this option to enable support for Broadcom
+ VK Accelerators.  VK is used for performing
+ specific offload processing.
+ This driver enables userspace programs to access these
+ accelerators via /dev/bcm-vk.N devices.
+
+ If unsure, say N.
+
+if BCM_VK
+
+config BCM_VK_QSTATS
+   bool "VK Queue Statistics"
+   help
+ Turn on to enable Queue Statistics.
+ These are useful for debugging purposes.
+ Some performance loss by enabling this debug config.
+ For properly operating PCIe hardware no need to enable this.
+
+ If unsure, say N.
+
+endif
diff --git a/drivers/misc/bcm-vk/Makefile b/drivers/misc/bcm-vk/Makefile
new file mode 100644
index ..05cb213ee826
--- /dev/null
+++ b/drivers/misc/bcm-vk/Makefile
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for Broadcom VK driver
+#
+
+obj-$(CONFIG_BCM_VK) += bcm_vk.o
+bcm_vk-objs := \
+   bcm_vk_dev.o \
+   bcm_vk_msg.o \
+   bcm_vk_sg.o \
+   bcm_vk_tty.o
diff --git a/drivers/misc/bcm-vk/bcm_vk.h b/drivers/misc/bcm-vk/bcm_vk.h
new file mode 100644
index ..1a241074296d
--- /dev/null
+++ b/drivers/misc/bcm-vk/bcm_vk.h
@@ -0,0 +1,408 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright 2018-2020 Broadcom.
+ */
+
+#ifndef BCM_VK_H
+#define BCM_VK_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "bcm_vk_msg.h"
+
+#define DRV_MODULE_NAME"bcm-vk"
+
+/*
+ * Load Image is completed in two stages:
+ *
+ * 1) When the VK device boot-up, M7 CPU runs and executes the BootROM.
+ * The Secure Boot Loader (SBL) as part of the BootROM will run
+ * to open up ITCM for host to push BOOT1 image.
+ * SBL will authenticate the image before jumping to BOOT1 image.
+ *
+ * 2) Because BOOT1 image is a secured image, we also called it the
+ * Secure Boot Image (SBI). At second stage, SBI

[PATCH v7 4/8] firmware: test partial file reads of request_firmware_into_buf

Add firmware tests for partial file reads of request_firmware_into_buf.

Signed-off-by: Scott Branden 
---
 .../selftests/firmware/fw_filesystem.sh   | 80 +++
 1 file changed, 80 insertions(+)

diff --git a/tools/testing/selftests/firmware/fw_filesystem.sh 
b/tools/testing/selftests/firmware/fw_filesystem.sh
index fcc281373b4d..38e89ba1b4d3 100755
--- a/tools/testing/selftests/firmware/fw_filesystem.sh
+++ b/tools/testing/selftests/firmware/fw_filesystem.sh
@@ -149,6 +149,26 @@ config_unset_into_buf()
echo 0 >  $DIR/config_into_buf
 }
 
+config_set_buf_size()
+{
+   echo $1 >  $DIR/config_buf_size
+}
+
+config_set_file_offset()
+{
+   echo $1 >  $DIR/config_file_offset
+}
+
+config_set_partial()
+{
+   echo 1 >  $DIR/config_partial
+}
+
+config_unset_partial()
+{
+   echo 0 >  $DIR/config_partial
+}
+
 config_set_sync_direct()
 {
echo 1 >  $DIR/config_sync_direct
@@ -207,6 +227,35 @@ read_firmwares()
done
 }
 
+read_firmwares_partial()
+{
+   if [ "$(cat $DIR/config_into_buf)" == "1" ]; then
+   fwfile="${FW_INTO_BUF}"
+   else
+   fwfile="${FW}"
+   fi
+
+   if [ "$1" = "xzonly" ]; then
+   fwfile="${fwfile}-orig"
+   fi
+
+   # Strip fwfile down to match partial offset and length
+   partial_data="$(cat $fwfile)"
+   partial_data="${partial_data:$2:$3}"
+
+   for i in $(seq 0 3); do
+   config_set_read_fw_idx $i
+
+   read_firmware="$(cat $DIR/read_firmware)"
+
+   # Verify the contents are what we expect.
+   if [ $read_firmware != $partial_data ]; then
+   echo "request #$i: partial firmware was not loaded" >&2
+   exit 1
+   fi
+   done
+}
+
 read_firmwares_expect_nofile()
 {
for i in $(seq 0 3); do
@@ -319,6 +368,21 @@ test_batched_request_firmware_into_buf()
echo "OK"
 }
 
+test_batched_request_firmware_into_buf_partial()
+{
+   echo -n "Batched request_firmware_into_buf_partial() $2 off=$3 size=$4 
try #$1: "
+   config_reset
+   config_set_name $TEST_FIRMWARE_INTO_BUF_FILENAME
+   config_set_into_buf
+   config_set_partial
+   config_set_buf_size $4
+   config_set_file_offset $3
+   config_trigger_sync
+   read_firmwares_partial $2 $3 $4
+   release_all_firmware
+   echo "OK"
+}
+
 test_batched_request_firmware_direct()
 {
echo -n "Batched request_firmware_direct() $2 try #$1: "
@@ -371,6 +435,22 @@ for i in $(seq 1 5); do
test_batched_request_firmware_into_buf $i normal
 done
 
+for i in $(seq 1 5); do
+   test_batched_request_firmware_into_buf_partial $i normal 0 10
+done
+
+for i in $(seq 1 5); do
+   test_batched_request_firmware_into_buf_partial $i normal 0 5
+done
+
+for i in $(seq 1 5); do
+   test_batched_request_firmware_into_buf_partial $i normal 1 6
+done
+
+for i in $(seq 1 5); do
+   test_batched_request_firmware_into_buf_partial $i normal 2 10
+done
+
 for i in $(seq 1 5); do
test_batched_request_firmware_direct $i normal
 done
-- 
2.17.1

[PATCH v7 3/8] test_firmware: add partial read support for request_firmware_into_buf

Add additional hooks to test_firmware to pass in support
for partial file read using request_firmware_into_buf.
buf_size: size of buffer to request firmware into
partial: indicates that a partial file request is being made
file_offset: to indicate offset into file to request

Signed-off-by: Scott Branden 
---
 lib/test_firmware.c | 146 +---
 1 file changed, 136 insertions(+), 10 deletions(-)

diff --git a/lib/test_firmware.c b/lib/test_firmware.c
index af747660fe29..1a79611cae78 100644
--- a/lib/test_firmware.c
+++ b/lib/test_firmware.c
@@ -50,6 +50,9 @@ struct test_batched_req {
  * @name: the name of the firmware file to look for
  * @into_buf: when the into_buf is used if this is true
  * request_firmware_into_buf() will be used instead.
+ * @buf_size: size of buf to allocate when into_buf is true
+ * @file_offset: file offset to request when calling request_firmware_into_buf
+ * @partial: partial read opt when calling request_firmware_into_buf
  * @sync_direct: when the sync trigger is used if this is true
  * request_firmware_direct() will be used instead.
  * @send_uevent: whether or not to send a uevent for async requests
@@ -89,6 +92,9 @@ struct test_batched_req {
 struct test_config {
char *name;
bool into_buf;
+   size_t buf_size;
+   size_t file_offset;
+   bool partial;
bool sync_direct;
bool send_uevent;
u8 num_requests;
@@ -183,6 +189,9 @@ static int __test_firmware_config_init(void)
test_fw_config->num_requests = TEST_FIRMWARE_NUM_REQS;
test_fw_config->send_uevent = true;
test_fw_config->into_buf = false;
+   test_fw_config->buf_size = TEST_FIRMWARE_BUF_SIZE;
+   test_fw_config->file_offset = 0;
+   test_fw_config->partial = false;
test_fw_config->sync_direct = false;
test_fw_config->req_firmware = request_firmware;
test_fw_config->test_result = 0;
@@ -236,28 +245,35 @@ static ssize_t config_show(struct device *dev,
dev_name(dev));
 
if (test_fw_config->name)
-   len += scnprintf(buf+len, PAGE_SIZE - len,
+   len += scnprintf(buf + len, PAGE_SIZE - len,
"name:\t%s\n",
test_fw_config->name);
else
-   len += scnprintf(buf+len, PAGE_SIZE - len,
+   len += scnprintf(buf + len, PAGE_SIZE - len,
"name:\tEMTPY\n");
 
-   len += scnprintf(buf+len, PAGE_SIZE - len,
+   len += scnprintf(buf + len, PAGE_SIZE - len,
"num_requests:\t%u\n", test_fw_config->num_requests);
 
-   len += scnprintf(buf+len, PAGE_SIZE - len,
+   len += scnprintf(buf + len, PAGE_SIZE - len,
"send_uevent:\t\t%s\n",
test_fw_config->send_uevent ?
"FW_ACTION_HOTPLUG" :
"FW_ACTION_NOHOTPLUG");
-   len += scnprintf(buf+len, PAGE_SIZE - len,
+   len += scnprintf(buf + len, PAGE_SIZE - len,
"into_buf:\t\t%s\n",
test_fw_config->into_buf ? "true" : "false");
-   len += scnprintf(buf+len, PAGE_SIZE - len,
+   len += scnprintf(buf + len, PAGE_SIZE - len,
+   "buf_size:\t%zu\n", test_fw_config->buf_size);
+   len += scnprintf(buf + len, PAGE_SIZE - len,
+   "file_offset:\t%zu\n", test_fw_config->file_offset);
+   len += scnprintf(buf + len, PAGE_SIZE - len,
+   "partial:\t\t%s\n",
+   test_fw_config->partial ? "true" : "false");
+   len += scnprintf(buf + len, PAGE_SIZE - len,
"sync_direct:\t\t%s\n",
test_fw_config->sync_direct ? "true" : "false");
-   len += scnprintf(buf+len, PAGE_SIZE - len,
+   len += scnprintf(buf + len, PAGE_SIZE - len,
"read_fw_idx:\t%u\n", test_fw_config->read_fw_idx);
 
mutex_unlock(_fw_mutex);
@@ -315,6 +331,30 @@ static ssize_t test_dev_config_show_bool(char *buf, bool 
val)
return snprintf(buf, PAGE_SIZE, "%d\n", val);
 }
 
+static int test_dev_config_update_size_t(const char *buf,
+size_t size,
+size_t *cfg)
+{
+   int ret;
+   long new;
+
+   ret = kstrtol(buf, 10, );
+   if (ret)
+   return ret;
+
+   mutex_lock(_fw_mutex);
+   *(size_t *)cfg = new;
+   mutex_unlock(_fw_mutex);
+
+   /* Always return full write size even if we didn't consume all */
+   return size;
+}
+
+static ssize_t test_dev_config_show_size_t(char *buf, size_t val)
+{
+   return snprintf(buf, PAGE_SIZE, "%zu\n", val);
+}
+
 static ssize_t test_dev_config_show_int(char *buf, int val)
 {
return snprintf(buf, PAGE_SIZE, "%d\n", val);
@@ -400,6 +440,83 @@ static ssize_t

[PATCH v7 2/8] firmware: add offset to request_firmware_into_buf

Add offset to request_firmware_into_buf to allow for portions
of firmware file to be read into a buffer.  Necessary where firmware
needs to be loaded in portions from file in memory constrained systems.

Signed-off-by: Scott Branden 
---
 drivers/base/firmware_loader/firmware.h |  5 +++
 drivers/base/firmware_loader/main.c | 53 +
 drivers/i2c/i2c-slave-eeprom.c  |  4 +-
 drivers/soc/qcom/mdt_loader.c   |  7 +++-
 include/linux/firmware.h|  8 +++-
 lib/test_firmware.c |  4 +-
 6 files changed, 59 insertions(+), 22 deletions(-)

diff --git a/drivers/base/firmware_loader/firmware.h 
b/drivers/base/firmware_loader/firmware.h
index 933e2192fbe8..c9b6ba8d29d8 100644
--- a/drivers/base/firmware_loader/firmware.h
+++ b/drivers/base/firmware_loader/firmware.h
@@ -32,6 +32,8 @@
  * @FW_OPT_FALLBACK_PLATFORM: Enable fallback to device fw copy embedded in
  * the platform's main firmware. If both this fallback and the sysfs
  *  fallback are enabled, then this fallback will be tried first.
+ * @FW_OPT_PARTIAL: Allow partial read of firmware instead of needing to read
+ * entire file.
  */
 enum fw_opt {
FW_OPT_UEVENT   = BIT(0),
@@ -41,6 +43,7 @@ enum fw_opt {
FW_OPT_NOCACHE  = BIT(4),
FW_OPT_NOFALLBACK_SYSFS = BIT(5),
FW_OPT_FALLBACK_PLATFORM= BIT(6),
+   FW_OPT_PARTIAL  = BIT(7),
 };
 
 enum fw_status {
@@ -68,6 +71,8 @@ struct fw_priv {
void *data;
size_t size;
size_t allocated_size;
+   size_t offset;
+   enum kernel_pread_opt opt;
 #ifdef CONFIG_FW_LOADER_PAGED_BUF
bool is_paged_buf;
struct page **pages;
diff --git a/drivers/base/firmware_loader/main.c 
b/drivers/base/firmware_loader/main.c
index ca871b13524e..93e7fee42cd4 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -167,7 +167,9 @@ static int fw_cache_piggyback_on_request(const char *name);
 
 static struct fw_priv *__allocate_fw_priv(const char *fw_name,
  struct firmware_cache *fwc,
- void *dbuf, size_t size)
+ void *dbuf, size_t size,
+ size_t offset,
+ enum kernel_pread_opt opt)
 {
struct fw_priv *fw_priv;
 
@@ -185,6 +187,8 @@ static struct fw_priv *__allocate_fw_priv(const char 
*fw_name,
fw_priv->fwc = fwc;
fw_priv->data = dbuf;
fw_priv->allocated_size = size;
+   fw_priv->offset = offset;
+   fw_priv->opt = opt;
fw_state_init(fw_priv);
 #ifdef CONFIG_FW_LOADER_USER_HELPER
INIT_LIST_HEAD(_priv->pending_list);
@@ -210,9 +214,11 @@ static struct fw_priv *__lookup_fw_priv(const char 
*fw_name)
 static int alloc_lookup_fw_priv(const char *fw_name,
struct firmware_cache *fwc,
struct fw_priv **fw_priv, void *dbuf,
-   size_t size, u32 opt_flags)
+   size_t size, u32 opt_flags,
+   size_t offset)
 {
struct fw_priv *tmp;
+   enum kernel_pread_opt pread_opt;
 
spin_lock(>lock);
if (!(opt_flags & FW_OPT_NOCACHE)) {
@@ -226,7 +232,12 @@ static int alloc_lookup_fw_priv(const char *fw_name,
}
}
 
-   tmp = __allocate_fw_priv(fw_name, fwc, dbuf, size);
+   if (opt_flags & FW_OPT_PARTIAL)
+   pread_opt = KERNEL_PREAD_PART;
+   else
+   pread_opt = KERNEL_PREAD_WHOLE;
+
+   tmp = __allocate_fw_priv(fw_name, fwc, dbuf, size, offset, pread_opt);
if (tmp) {
INIT_LIST_HEAD(>list);
if (!(opt_flags & FW_OPT_NOCACHE))
@@ -495,8 +506,10 @@ fw_get_filesystem_firmware(struct device *device, struct 
fw_priv *fw_priv,
fw_priv->size = 0;
 
/* load firmware files from the mount namespace of init */
-   rc = kernel_read_file_from_path_initns(path, ,
-  , msize, id);
+   rc = kernel_pread_file_from_path_initns(path, ,
+   , fw_priv->offset,
+   msize,
+   fw_priv->opt, id);
if (rc) {
if (rc != -ENOENT)
dev_warn(device, "loading %s failed with error 
%d\n",
@@ -683,7 +696,7 @@ int assign_fw(struct firmware *fw, struct device *device, 
u32 opt_flags)
 static int
 _request_firmware_prepare(struct firmware **firmware_p, const char *name,
  struct device *device, void *dbuf, size_t size,
- u32 opt_flags)

[PATCH v7 5/8] bcm-vk: add bcm_vk UAPI

Add user space api for bcm-vk driver.

Signed-off-by: Scott Branden 
---
 include/uapi/linux/misc/bcm_vk.h | 99 
 1 file changed, 99 insertions(+)
 create mode 100644 include/uapi/linux/misc/bcm_vk.h

diff --git a/include/uapi/linux/misc/bcm_vk.h b/include/uapi/linux/misc/bcm_vk.h
new file mode 100644
index ..783087b7c31f
--- /dev/null
+++ b/include/uapi/linux/misc/bcm_vk.h
@@ -0,0 +1,99 @@
+/* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR 
BSD-2-Clause) */
+/*
+ * Copyright 2018-2020 Broadcom.
+ */
+
+#ifndef __UAPI_LINUX_MISC_BCM_VK_H
+#define __UAPI_LINUX_MISC_BCM_VK_H
+
+#include 
+#include 
+
+#define BCM_VK_MAX_FILENAME 64
+
+struct vk_image {
+   __u32 type; /* Type of image */
+#define VK_IMAGE_TYPE_BOOT1 1 /* 1st stage (load to SRAM) */
+#define VK_IMAGE_TYPE_BOOT2 2 /* 2nd stage (load to DDR) */
+   char filename[BCM_VK_MAX_FILENAME]; /* Filename of image */
+};
+
+struct vk_reset {
+   __u32 arg1;
+   __u32 arg2;
+};
+
+#define VK_MAGIC   0x5e
+
+/* Load image to Valkyrie */
+#define VK_IOCTL_LOAD_IMAGE_IOW(VK_MAGIC, 0x2, struct vk_image)
+
+/* Send Reset to Valkyrie */
+#define VK_IOCTL_RESET _IOW(VK_MAGIC, 0x4, struct vk_reset)
+
+/*
+ * message block - basic unit in the message where a message's size is always
+ *N x sizeof(basic_block)
+ */
+struct vk_msg_blk {
+   __u8 function_id;
+#define VK_FID_TRANS_BUF   5
+#define VK_FID_SHUTDOWN8
+   __u8 size;
+   __u16 trans_id; /* transport id, queue & msg_id */
+   __u32 context_id;
+   __u32 args[2];
+#define VK_CMD_PLANES_MASK 0x000f /* number of planes to up/download */
+#define VK_CMD_UPLOAD  0x0400 /* memory transfer to vk */
+#define VK_CMD_DOWNLOAD0x0500 /* memory transfer from vk */
+#define VK_CMD_MASK0x0f00 /* command mask */
+};
+
+#define VK_BAR_FWSTS   0x41c
+#define VK_BAR_COP_FWSTS   0x428
+/* VK_FWSTS definitions */
+#define VK_FWSTS_RELOCATION_ENTRY  BIT(0)
+#define VK_FWSTS_RELOCATION_EXIT   BIT(1)
+#define VK_FWSTS_INIT_STARTBIT(2)
+#define VK_FWSTS_ARCH_INIT_DONEBIT(3)
+#define VK_FWSTS_PRE_KNL1_INIT_DONEBIT(4)
+#define VK_FWSTS_PRE_KNL2_INIT_DONEBIT(5)
+#define VK_FWSTS_POST_KNL_INIT_DONEBIT(6)
+#define VK_FWSTS_INIT_DONE BIT(7)
+#define VK_FWSTS_APP_INIT_STARTBIT(8)
+#define VK_FWSTS_APP_INIT_DONE BIT(9)
+#define VK_FWSTS_MASK  0x
+#define VK_FWSTS_READY (VK_FWSTS_INIT_START | \
+VK_FWSTS_ARCH_INIT_DONE | \
+VK_FWSTS_PRE_KNL1_INIT_DONE | \
+VK_FWSTS_PRE_KNL2_INIT_DONE | \
+VK_FWSTS_POST_KNL_INIT_DONE | \
+VK_FWSTS_INIT_DONE | \
+VK_FWSTS_APP_INIT_START | \
+VK_FWSTS_APP_INIT_DONE)
+/* Deinit */
+#define VK_FWSTS_APP_DEINIT_START  BIT(23)
+#define VK_FWSTS_APP_DEINIT_DONE   BIT(24)
+#define VK_FWSTS_DRV_DEINIT_START  BIT(25)
+#define VK_FWSTS_DRV_DEINIT_DONE   BIT(26)
+#define VK_FWSTS_RESET_DONEBIT(27)
+#define VK_FWSTS_DEINIT_TRIGGERED  (VK_FWSTS_APP_DEINIT_START | \
+VK_FWSTS_APP_DEINIT_DONE  | \
+VK_FWSTS_DRV_DEINIT_START | \
+VK_FWSTS_DRV_DEINIT_DONE)
+/* Last nibble for reboot reason */
+#define VK_FWSTS_RESET_REASON_SHIFT28
+#define VK_FWSTS_RESET_REASON_MASK (0xf << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_SYS_PWRUP   (0x0 << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_MBOX_DB (0x1 << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_M7_WDOG (0x2 << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_TEMP(0x3 << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_PCI_FLR (0x4 << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_PCI_HOT (0x5 << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_PCI_WARM(0x6 << 
VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_PCI_COLD(0x7 << 
VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_L1  (0x8 << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_L0  (0x9 << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_UNKNOWN (0xf << VK_FWSTS_RESET_REASON_SHIFT)
+
+#endif /* __UAPI_LINUX_MISC_BCM_VK_H */
-- 
2.17.1

[PATCH v7 1/8] fs: introduce kernel_pread_file* support

Add kernel_pread_file* support to kernel to allow for partial read
of files with an offset into the file.  Existing kernel_read_file
functions call new kernel_pread_file functions with offset=0 and
opt=KERNEL_PREAD_WHOLE.

Signed-off-by: Scott Branden 
---
 fs/exec.c  | 95 --
 include/linux/fs.h | 29 ++
 2 files changed, 103 insertions(+), 21 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
index 306fc566171e..751f5ddc7538 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -927,10 +927,15 @@ struct file *open_exec(const char *name)
 }
 EXPORT_SYMBOL(open_exec);
 
-int kernel_read_file(struct file *file, void **buf, loff_t *size,
-loff_t max_size, enum kernel_read_file_id id)
-{
-   loff_t i_size, pos;
+int kernel_pread_file(struct file *file, void **buf, loff_t *size,
+ loff_t pos, loff_t max_size,
+ enum kernel_pread_opt opt,
+ enum kernel_read_file_id id)
+{
+   loff_t alloc_size;
+   loff_t buf_pos;
+   loff_t read_end;
+   loff_t i_size;
ssize_t bytes = 0;
int ret;
 
@@ -950,21 +955,31 @@ int kernel_read_file(struct file *file, void **buf, 
loff_t *size,
ret = -EINVAL;
goto out;
}
-   if (i_size > SIZE_MAX || (max_size > 0 && i_size > max_size)) {
+
+   /* Default read to end of file */
+   read_end = i_size;
+
+   /* Allow reading partial portion of file */
+   if ((opt == KERNEL_PREAD_PART) &&
+   (i_size > (pos + max_size)))
+   read_end = pos + max_size;
+
+   alloc_size = read_end - pos;
+   if (i_size > SIZE_MAX || (max_size > 0 && alloc_size > max_size)) {
ret = -EFBIG;
goto out;
}
 
if (id != READING_FIRMWARE_PREALLOC_BUFFER)
-   *buf = vmalloc(i_size);
+   *buf = vmalloc(alloc_size);
if (!*buf) {
ret = -ENOMEM;
goto out;
}
 
-   pos = 0;
-   while (pos < i_size) {
-   bytes = kernel_read(file, *buf + pos, i_size - pos, );
+   buf_pos = 0;
+   while (pos < read_end) {
+   bytes = kernel_read(file, *buf + buf_pos, read_end - pos, );
if (bytes < 0) {
ret = bytes;
goto out_free;
@@ -972,14 +987,16 @@ int kernel_read_file(struct file *file, void **buf, 
loff_t *size,
 
if (bytes == 0)
break;
+
+   buf_pos += bytes;
}
 
-   if (pos != i_size) {
+   if (pos != read_end) {
ret = -EIO;
goto out_free;
}
 
-   ret = security_kernel_post_read_file(file, *buf, i_size, id);
+   ret = security_kernel_post_read_file(file, *buf, alloc_size, id);
if (!ret)
*size = pos;
 
@@ -995,10 +1012,20 @@ int kernel_read_file(struct file *file, void **buf, 
loff_t *size,
allow_write_access(file);
return ret;
 }
+
+int kernel_read_file(struct file *file, void **buf, loff_t *size,
+loff_t max_size, enum kernel_read_file_id id)
+{
+   return kernel_pread_file(file, buf, size, 0, max_size,
+KERNEL_PREAD_WHOLE, id);
+}
 EXPORT_SYMBOL_GPL(kernel_read_file);
 
-int kernel_read_file_from_path(const char *path, void **buf, loff_t *size,
-  loff_t max_size, enum kernel_read_file_id id)
+int kernel_pread_file_from_path(const char *path, void **buf,
+   loff_t *size, loff_t pos,
+   loff_t max_size,
+   enum kernel_pread_opt opt,
+   enum kernel_read_file_id id)
 {
struct file *file;
int ret;
@@ -1010,15 +1037,24 @@ int kernel_read_file_from_path(const char *path, void 
**buf, loff_t *size,
if (IS_ERR(file))
return PTR_ERR(file);
 
-   ret = kernel_read_file(file, buf, size, max_size, id);
+   ret = kernel_pread_file(file, buf, size, pos, max_size, opt, id);
fput(file);
return ret;
 }
+
+int kernel_read_file_from_path(const char *path, void **buf, loff_t *size,
+  loff_t max_size, enum kernel_read_file_id id)
+{
+   return kernel_pread_file_from_path(path, buf, size, 0, max_size,
+  KERNEL_PREAD_WHOLE, id);
+}
 EXPORT_SYMBOL_GPL(kernel_read_file_from_path);
 
-int kernel_read_file_from_path_initns(const char *path, void **buf,
- loff_t *size, loff_t max_size,
- enum kernel_read_file_id id)
+int kernel_pread_file_from_path_initns(const char *path, void **buf,
+  loff_t *size, loff_t pos,
+  loff_t max_size,
+

[PATCH v7 0/8] firmware: add partial read support in request_firmware_into_buf

This patch series adds partial read support in request_firmware_into_buf.
In order to accept the enhanced API it has been requested that kernel
selftests and upstreamed driver utilize the API enhancement and so
are included in this patch series.

Also in this patch series is the addition of a new Broadcom VK driver
utilizing the new request_firmware_into_buf enhanced API.

Further comment followed to add IMA support of the partial reads
originating from request_firmware_into_buf calls.

Changes from v6:
 - update ima_post_read_file check on IMA_FIRMWARE_PARTIAL_READ
 - adjust new driver i2c-slave-eeprom.c use of request_firmware_into_buf
 - remove an extern
Changes from v5:
 - add IMA FIRMWARE_PARTIAL_READ support
 - change kernel pread flags to enum
 - removed legacy support from driver
 - driver fixes
Changes from v4:
 - handle reset issues if card crashes
 - allow driver to have min required msix
 - add card utilization information
Changes from v3:
 - fix sparse warnings
 - fix printf format specifiers for size_t
 - fix 32-bit cross-compiling reports 32-bit shifts
 - use readl/writel,_relaxed to access pci ioremap memory,
  removed memory barriers and volatile keyword with such change
 - driver optimizations for interrupt/poll functionalities
Changes from v2:
 - remove unnecessary code and mutex locks in lib/test_firmware.c
 - remove VK_IOCTL_ACCESS_BAR support from driver and use pci sysfs instead
 - remove bitfields
 - remove Kconfig default m
 - adjust formatting and some naming based on feedback
 - fix error handling conditions
 - use appropriate return codes
 - use memcpy_toio instead of direct access to PCIE bar

Scott Branden (8):
  fs: introduce kernel_pread_file* support
  firmware: add offset to request_firmware_into_buf
  test_firmware: add partial read support for request_firmware_into_buf
  firmware: test partial file reads of request_firmware_into_buf
  bcm-vk: add bcm_vk UAPI
  misc: bcm-vk: add Broadcom VK driver
  MAINTAINERS: bcm-vk: add maintainer for Broadcom VK Driver
  ima: add FIRMWARE_PARTIAL_READ support

 MAINTAINERS   |7 +
 drivers/base/firmware_loader/firmware.h   |5 +
 drivers/base/firmware_loader/main.c   |   59 +-
 drivers/i2c/i2c-slave-eeprom.c|4 +-
 drivers/misc/Kconfig  |1 +
 drivers/misc/Makefile |1 +
 drivers/misc/bcm-vk/Kconfig   |   29 +
 drivers/misc/bcm-vk/Makefile  |   11 +
 drivers/misc/bcm-vk/bcm_vk.h  |  408 +
 drivers/misc/bcm-vk/bcm_vk_dev.c  | 1312 +++
 drivers/misc/bcm-vk/bcm_vk_msg.c  | 1438 +
 drivers/misc/bcm-vk/bcm_vk_msg.h  |  201 +++
 drivers/misc/bcm-vk/bcm_vk_sg.c   |  271 
 drivers/misc/bcm-vk/bcm_vk_sg.h   |   60 +
 drivers/misc/bcm-vk/bcm_vk_tty.c  |  352 
 drivers/soc/qcom/mdt_loader.c |7 +-
 fs/exec.c |  101 +-
 include/linux/firmware.h  |8 +-
 include/linux/fs.h|   30 +
 include/uapi/linux/misc/bcm_vk.h  |   99 ++
 lib/test_firmware.c   |  144 +-
 security/integrity/ima/ima_main.c |   24 +-
 .../selftests/firmware/fw_filesystem.sh   |   80 +
 23 files changed, 4598 insertions(+), 54 deletions(-)
 create mode 100644 drivers/misc/bcm-vk/Kconfig
 create mode 100644 drivers/misc/bcm-vk/Makefile
 create mode 100644 drivers/misc/bcm-vk/bcm_vk.h
 create mode 100644 drivers/misc/bcm-vk/bcm_vk_dev.c
 create mode 100644 drivers/misc/bcm-vk/bcm_vk_msg.c
 create mode 100644 drivers/misc/bcm-vk/bcm_vk_msg.h
 create mode 100644 drivers/misc/bcm-vk/bcm_vk_sg.c
 create mode 100644 drivers/misc/bcm-vk/bcm_vk_sg.h
 create mode 100644 drivers/misc/bcm-vk/bcm_vk_tty.c
 create mode 100644 include/uapi/linux/misc/bcm_vk.h

-- 
2.17.1

Re: [RFC PATCH] KVM: x86: Fix APIC page invalidation race

2020-06-05 Thread Eiichi Tsukata

Hello

The race window I mentioned in the commit message is pretty small. So it’s 
difficult to reproduce it.
But with the following ‘delay’ patch, it can be very easy to reproduce.

```
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c17e6eb9ad43..b6728bf80a7d 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -55,6 +55,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -8161,8 +8162,10 @@ int kvm_arch_mmu_notifier_invalidate_range(struct kvm 
*kvm,
 * Update it when it becomes invalid.
 */
apic_address = gfn_to_hva(kvm, APIC_DEFAULT_PHYS_BASE >> PAGE_SHIFT);
-   if (start <= apic_address && apic_address < end)
+   if (start <= apic_address && apic_address < end) {
kvm_make_all_cpus_request(kvm, KVM_REQ_APIC_PAGE_RELOAD);
+   mdelay(1000);
+   }
 
return 0;
 }
```

Steps to Reproduce:
- start Windows VM(ex: Windows Server 2016) and watch YouTube video to 
stimulate VM_ENTER/EXIT
- ’stress —vm X —vm-bytes Y’ to make the APIC page swapped out
- Windows OS will crash with BugCheck 0x109

Thanks,

Eiichi

> On Jun 6, 2020, at 13:26, Eiichi Tsukata  wrote:
> 
> Commit b1394e745b94 ("KVM: x86: fix APIC page invalidation") tried to
> fix inappropriate APIC page invalidation by re-introducing arch specific
> kvm_arch_mmu_notifier_invalidate_range() and calling it from
> kvm_mmu_notifier_invalidate_range_start. But threre could be the
> following race because VMCS APIC address cache can be updated
> *before* it is unmapped.
> 
> Race:
>  (Invalidator) kvm_mmu_notifier_invalidate_range_start()
>  (Invalidator) kvm_make_all_cpus_request(kvm, KVM_REQ_APIC_PAGE_RELOAD)
>  (KVM VCPU) vcpu_enter_guest()
>  (KVM VCPU) kvm_vcpu_reload_apic_access_page()
>  (Invalidator) actually unmap page
> 
> Symptom:
>  The above race can make Guest OS see already freed page and Guest OS
> will see broken APIC register values. Especially, Windows OS checks
> LAPIC modification so it can cause BSOD crash with BugCheck
> CRITICAL_STRUCTURE_CORRUPTION (109). These symptoms are the same as we
> previously saw in 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.kernel.org_show-5Fbug.cgi-3Fid-3D197951=DwIDAg=s883GpUCOChKOHiocYtGcg=dy01Dr4Ly8mhvnUdx1pZhhT1bkq4h9z5aVWu3paoZtk=0Tyk-14RQ4E7qUHEz3qfkUGJEUisqm5fr6wFgen6m9o=uTkyasbUNMoptgfsLkg3D5IDb_xxOSjklf2IfLLUzgI=
>   and
> we are currently seeing in
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1751017=DwIDAg=s883GpUCOChKOHiocYtGcg=dy01Dr4Ly8mhvnUdx1pZhhT1bkq4h9z5aVWu3paoZtk=0Tyk-14RQ4E7qUHEz3qfkUGJEUisqm5fr6wFgen6m9o=pyRkFbs1A9a9AXxWMqiDEOoGJGBbmF8uJdLu8vKSPCs=
>  .
> 
> To prevent Guest OS from accessing already freed page, this patch calls
> kvm_arch_mmu_notifier_invalidate_range() from
> kvm_mmu_notifier_invalidate_range() instead of ..._range_start().
> 
> Fixes: b1394e745b94 ("KVM: x86: fix APIC page invalidation")
> Signed-off-by: Eiichi Tsukata 
> ---
> arch/x86/kvm/x86.c   |  7 ++-
> include/linux/kvm_host.h |  4 ++--
> virt/kvm/kvm_main.c  | 26 --
> 3 files changed, 20 insertions(+), 17 deletions(-)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index c17e6eb9ad43..1700aade39d1 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -8150,9 +8150,8 @@ static void vcpu_load_eoi_exitmap(struct kvm_vcpu *vcpu)
>   kvm_x86_ops.load_eoi_exitmap(vcpu, eoi_exit_bitmap);
> }
> 
> -int kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
> - unsigned long start, unsigned long end,
> - bool blockable)
> +void kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
> + unsigned long start, unsigned long 
> end)
> {
>   unsigned long apic_address;
> 
> @@ -8163,8 +8162,6 @@ int kvm_arch_mmu_notifier_invalidate_range(struct kvm 
> *kvm,
>   apic_address = gfn_to_hva(kvm, APIC_DEFAULT_PHYS_BASE >> PAGE_SHIFT);
>   if (start <= apic_address && apic_address < end)
>   kvm_make_all_cpus_request(kvm, KVM_REQ_APIC_PAGE_RELOAD);
> -
> - return 0;
> }
> 
> void kvm_vcpu_reload_apic_access_page(struct kvm_vcpu *vcpu)
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 131cc1527d68..92efa39ea3d7 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -1406,8 +1406,8 @@ static inline long kvm_arch_vcpu_async_ioctl(struct 
> file *filp,
> }
> #endif /* CONFIG_HAVE_KVM_VCPU_ASYNC_IOCTL */
> 
> -int kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
> - unsigned long start, unsigned long end, bool blockable);
> +void kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
> + unsigned long start, unsigned long 
> end);
> 
> #ifdef CONFIG_HAVE_KVM_VCPU_RUN_PID_CHANGE
> int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu);
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>

Re: [PATCH v6 1/8] fs: introduce kernel_pread_file* support


Hi Matthew,

On 2020-06-05 8:20 p.m., Matthew Wilcox wrote:

On Fri, Jun 05, 2020 at 03:59:52PM -0700, Scott Branden wrote:

-int kernel_read_file(struct file *file, void **buf, loff_t *size,
-loff_t max_size, enum kernel_read_file_id id)
-{
-   loff_t i_size, pos;
+int kernel_pread_file(struct file *file, void **buf, loff_t *size,
+ loff_t pos, loff_t max_size,
+ enum kernel_pread_opt opt,
+ enum kernel_read_file_id id)

What is this 'kernel_pread_opt' foolishness?  Why not just pass in
~0UL as max_size if you want the entire file?

That is not how existing kernel_read_file api works - max_size is specified.
I guess not everyone has unlimited memory to read a file on any size.



-int kernel_read_file_from_path_initns(const char *path, void **buf,
- loff_t *size, loff_t max_size,
- enum kernel_read_file_id id)
+extern int kernel_pread_file_from_path_initns(const char *path, void **buf,

extern?  really?  i'm shocked gcc doesn't vomit on that.

A typo.  thanks.  You'll have to ask the compiler gods about your shock.

Re: [PATCH] scsi: megaraid_sas: fix kdump kernel boot hung caused by JBOD

2020-06-05 Thread Kai Liu


On 2020/06/05 Fri 21:00, Chandrakanth Patil wrote:

Hi Kai Liu,

Tomcat (Device ID: 0017) belongs to Gen3.5 controllers (Ventura family of
controllers). So this issue is applicable.
As this is an OEM specific firmware, Please contact Broadcom support team in
order get the correct firmware image.


Thanks for your help, Chandrakanth.

Best regards,
Kai

[PATCH] powerpc/fadump: update kernel logs before fadump crash begins

2020-06-05 Thread Sourabh Jain

When we hit the fadump crash via the panic path the pstore update is
missing. This is observed when commit 8341f2f222d7 ("sysrq: Use panic()
to force a crash") changed the sysrq-trigger to take panic path instead
of die path.

The PPC panic event handler addresses the system panic in two different
ways based on the system configuration. It first allows the FADump (if
configured) to handle the kernel panic else forwards the call to platform
specific panic function. Now pstore update is missing only if FADump
handles the kernel panic, the platform-specific panic function do update
the pstore by calling panic_flush_kmsg_end function.

The simplest approach to handle this issue is to add pstore update in PPC
panic handler before FADump handles the panic. But this leads to multiple
pstore updates in case FADump is not configured and platform-specific
panic function serves the kernel panic.

Hence the function panic_flush_kmsg_end (used by the platform-specific
panic function to update the kernel logs) is split into two functions, one
will update the pstore (called in ppc panic event handler) and others will
flush the kmsg on the console (called in platform specific panic function).

Signed-off-by: Sourabh Jain 
---
 arch/powerpc/include/asm/bug.h |  2 ++
 arch/powerpc/kernel/setup-common.c |  1 +
 arch/powerpc/kernel/traps.c| 12 +++-
 arch/powerpc/platforms/ps3/setup.c |  2 +-
 arch/powerpc/platforms/pseries/setup.c |  2 +-
 5 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
index 338f36cd9934..9268551a69bc 100644
--- a/arch/powerpc/include/asm/bug.h
+++ b/arch/powerpc/include/asm/bug.h
@@ -118,6 +118,8 @@ extern void _exception_pkey(struct pt_regs *, unsigned 
long, int);
 extern void die(const char *, struct pt_regs *, long);
 extern bool die_will_crash(void);
 extern void panic_flush_kmsg_start(void);
+extern void panic_flush_kmsg_dump(void);
+extern void panic_flush_kmsg_console(void);
 extern void panic_flush_kmsg_end(void);
 #endif /* !__ASSEMBLY__ */
 
diff --git a/arch/powerpc/kernel/setup-common.c 
b/arch/powerpc/kernel/setup-common.c
index 7f8c890360fe..2d546a9e8bb1 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -699,6 +699,7 @@ static int ppc_panic_event(struct notifier_block *this,
 * want interrupts to be hard disabled.
 */
hard_irq_disable();
+   panic_flush_kmsg_dump();
 
/*
 * If firmware-assisted dump has been registered then trigger
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 82a3438300fd..bb6bc19992b3 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -169,15 +169,25 @@ extern void panic_flush_kmsg_start(void)
bust_spinlocks(1);
 }
 
-extern void panic_flush_kmsg_end(void)
+extern void panic_flush_kmsg_dump(void)
 {
printk_safe_flush_on_panic();
kmsg_dump(KMSG_DUMP_PANIC);
+}
+
+extern void panic_flush_kmsg_console(void)
+{
bust_spinlocks(0);
debug_locks_off();
console_flush_on_panic(CONSOLE_FLUSH_PENDING);
 }
 
+extern void panic_flush_kmsg_end(void)
+{
+   panic_flush_kmsg_dump();
+   panic_flush_kmsg_console();
+}
+
 static unsigned long oops_begin(struct pt_regs *regs)
 {
int cpu;
diff --git a/arch/powerpc/platforms/ps3/setup.c 
b/arch/powerpc/platforms/ps3/setup.c
index b29368931c56..f96ba34284a1 100644
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -101,7 +101,7 @@ static void ps3_panic(char *str)
printk("   System does not reboot automatically.\n");
printk("   Please press POWER button.\n");
printk("\n");
-   panic_flush_kmsg_end();
+   panic_flush_kmsg_console();
 
while(1)
lv1_pause(1);
diff --git a/arch/powerpc/platforms/pseries/setup.c 
b/arch/powerpc/platforms/pseries/setup.c
index 0c8421dd01ab..66ecb88c4b8e 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -788,7 +788,7 @@ static void __init pSeries_setup_arch(void)
 
 static void pseries_panic(char *str)
 {
-   panic_flush_kmsg_end();
+   panic_flush_kmsg_console();
rtas_os_term(str);
 }
 
-- 
2.25.4

[RFC PATCH] KVM: x86: Fix APIC page invalidation race

2020-06-05 Thread Eiichi Tsukata

Commit b1394e745b94 ("KVM: x86: fix APIC page invalidation") tried to
fix inappropriate APIC page invalidation by re-introducing arch specific
kvm_arch_mmu_notifier_invalidate_range() and calling it from
kvm_mmu_notifier_invalidate_range_start. But threre could be the
following race because VMCS APIC address cache can be updated
*before* it is unmapped.

Race:
  (Invalidator) kvm_mmu_notifier_invalidate_range_start()
  (Invalidator) kvm_make_all_cpus_request(kvm, KVM_REQ_APIC_PAGE_RELOAD)
  (KVM VCPU) vcpu_enter_guest()
  (KVM VCPU) kvm_vcpu_reload_apic_access_page()
  (Invalidator) actually unmap page

Symptom:
  The above race can make Guest OS see already freed page and Guest OS
will see broken APIC register values. Especially, Windows OS checks
LAPIC modification so it can cause BSOD crash with BugCheck
CRITICAL_STRUCTURE_CORRUPTION (109). These symptoms are the same as we
previously saw in https://bugzilla.kernel.org/show_bug.cgi?id=197951 and
we are currently seeing in
https://bugzilla.redhat.com/show_bug.cgi?id=1751017.

To prevent Guest OS from accessing already freed page, this patch calls
kvm_arch_mmu_notifier_invalidate_range() from
kvm_mmu_notifier_invalidate_range() instead of ..._range_start().

Fixes: b1394e745b94 ("KVM: x86: fix APIC page invalidation")
Signed-off-by: Eiichi Tsukata 
---
 arch/x86/kvm/x86.c   |  7 ++-
 include/linux/kvm_host.h |  4 ++--
 virt/kvm/kvm_main.c  | 26 --
 3 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c17e6eb9ad43..1700aade39d1 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -8150,9 +8150,8 @@ static void vcpu_load_eoi_exitmap(struct kvm_vcpu *vcpu)
kvm_x86_ops.load_eoi_exitmap(vcpu, eoi_exit_bitmap);
 }
 
-int kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
-   unsigned long start, unsigned long end,
-   bool blockable)
+void kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
+   unsigned long start, unsigned long 
end)
 {
unsigned long apic_address;
 
@@ -8163,8 +8162,6 @@ int kvm_arch_mmu_notifier_invalidate_range(struct kvm 
*kvm,
apic_address = gfn_to_hva(kvm, APIC_DEFAULT_PHYS_BASE >> PAGE_SHIFT);
if (start <= apic_address && apic_address < end)
kvm_make_all_cpus_request(kvm, KVM_REQ_APIC_PAGE_RELOAD);
-
-   return 0;
 }
 
 void kvm_vcpu_reload_apic_access_page(struct kvm_vcpu *vcpu)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 131cc1527d68..92efa39ea3d7 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -1406,8 +1406,8 @@ static inline long kvm_arch_vcpu_async_ioctl(struct file 
*filp,
 }
 #endif /* CONFIG_HAVE_KVM_VCPU_ASYNC_IOCTL */
 
-int kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
-   unsigned long start, unsigned long end, bool blockable);
+void kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
+   unsigned long start, unsigned long 
end);
 
 #ifdef CONFIG_HAVE_KVM_VCPU_RUN_PID_CHANGE
 int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu);
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 731c1e517716..77aa91fb08d2 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -155,10 +155,9 @@ static void kvm_uevent_notify_change(unsigned int type, 
struct kvm *kvm);
 static unsigned long long kvm_createvm_count;
 static unsigned long long kvm_active_vms;
 
-__weak int kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
-   unsigned long start, unsigned long end, bool blockable)
+__weak void kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
+  unsigned long start, 
unsigned long end)
 {
-   return 0;
 }
 
 bool kvm_is_zone_device_pfn(kvm_pfn_t pfn)
@@ -384,6 +383,18 @@ static inline struct kvm *mmu_notifier_to_kvm(struct 
mmu_notifier *mn)
return container_of(mn, struct kvm, mmu_notifier);
 }
 
+static void kvm_mmu_notifier_invalidate_range(struct mmu_notifier *mn,
+ struct mm_struct *mm,
+ unsigned long start, unsigned 
long end)
+{
+   struct kvm *kvm = mmu_notifier_to_kvm(mn);
+   int idx;
+
+   idx = srcu_read_lock(>srcu);
+   kvm_arch_mmu_notifier_invalidate_range(kvm, start, end);
+   srcu_read_unlock(>srcu, idx);
+}
+
 static void kvm_mmu_notifier_change_pte(struct mmu_notifier *mn,
struct mm_struct *mm,
unsigned long address,
@@ -408,7 +419,6 @@ static int kvm_mmu_notifier_invalidate_range_start(struct 
mmu_notifier *mn,
 {
struct kvm *kvm = mmu_notifier_to_kvm(mn);
int need_tlb_flush = 0, idx;
-   int ret;
 
idx = srcu_read_lock(>srcu);
spin_lock(>mmu_lock);
@@ -425,14 +435,9

Re: [PATCH v8 14/16] s390/vfio-ap: handle host AP config change notification

Hi Tony,

I love your patch! Perhaps something to improve:

[auto build test WARNING on kvms390/next]
[also build test WARNING on linus/master v5.7]
[cannot apply to s390/features linux/master next-20200605]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Tony-Krowiak/s390-vfio-ap-dynamic-configuration-support/20200606-054350
base:   https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git next
config: s390-allyesconfig (attached as .config)
compiler: s390-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=s390 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>, old ones prefixed by <<):

drivers/s390/crypto/vfio_ap_ops.c:52:23: warning: no previous prototype for 
'vfio_ap_get_mdev_queue' [-Wmissing-prototypes]
52 | struct vfio_ap_queue *vfio_ap_get_mdev_queue(struct ap_matrix_mdev 
*matrix_mdev,
|   ^~
drivers/s390/crypto/vfio_ap_ops.c:142:24: warning: no previous prototype for 
'vfio_ap_irq_disable' [-Wmissing-prototypes]
142 | struct ap_queue_status vfio_ap_irq_disable(struct vfio_ap_queue *q)
|^~~
drivers/s390/crypto/vfio_ap_ops.c:1484:5: warning: no previous prototype for 
'vfio_ap_mdev_reset_queue' [-Wmissing-prototypes]
1484 | int vfio_ap_mdev_reset_queue(unsigned int apid, unsigned int apqi,
| ^~~~
>> drivers/s390/crypto/vfio_ap_ops.c:1746:6: warning: no previous prototype for 
>> 'vfio_ap_mdev_unassign_apids' [-Wmissing-prototypes]
1746 | bool vfio_ap_mdev_unassign_apids(struct ap_matrix_mdev *matrix_mdev,
|  ^~~
>> drivers/s390/crypto/vfio_ap_ops.c:1779:6: warning: no previous prototype for 
>> 'vfio_ap_mdev_unassign_apqis' [-Wmissing-prototypes]
1779 | bool vfio_ap_mdev_unassign_apqis(struct ap_matrix_mdev *matrix_mdev,
|  ^~~

vim +/vfio_ap_mdev_unassign_apids +1746 drivers/s390/crypto/vfio_ap_ops.c

  1733  
  1734  /**
  1735   * vfio_ap_mdev_unassign_apids
  1736   *
  1737   * @matrix_mdev: The matrix mediated device
  1738   *
  1739   * @aqm: A bitmap with 256 bits. Each bit in the map represents an APID 
from 0
  1740   *   to 255 (with the leftmost bit corresponding to APID 0).
  1741   *
  1742   * Unassigns each APID specified in @aqm that is assigned to the shadow 
CRYCB
  1743   * of @matrix_mdev. Returns true if at least one APID is unassigned; 
otherwise,
  1744   * returns false.
  1745   */
> 1746  bool vfio_ap_mdev_unassign_apids(struct ap_matrix_mdev *matrix_mdev,
  1747   unsigned long *apm_unassign)
  1748  {
  1749  unsigned long apid;
  1750  bool unassigned = false;
  1751  
  1752  /*
  1753   * If the matrix mdev is not in use by a KVM guest, return 
indicating
  1754   * that no APIDs have been unassigned.
  1755   */
  1756  if (!vfio_ap_mdev_has_crycb(matrix_mdev))
  1757  return false;
  1758  
  1759  for_each_set_bit_inv(apid, apm_unassign, AP_DEVICES) {
  1760  unassigned |= 
vfio_ap_mdev_unassign_guest_apid(matrix_mdev,
  1761 apid);
  1762  }
  1763  
  1764  return unassigned;
  1765  }
  1766  
  1767  /**
  1768   * vfio_ap_mdev_unassign_apqis
  1769   *
  1770   * @matrix_mdev: The matrix mediated device
  1771   *
  1772   * @aqm: A bitmap with 256 bits. Each bit in the map represents an APQI 
from 0
  1773   *   to 255 (with the leftmost bit corresponding to APQI 0).
  1774   *
  1775   * Unassigns each APQI specified in @aqm that is assigned to the shadow 
CRYCB
  1776   * of @matrix_mdev. Returns true if at least one APQI is unassigned; 
otherwise,
  1777   * returns false.
  1778   */
> 1779  bool vfio_ap_mdev_unassign_apqis(struct ap_matrix_mdev *matrix_mdev,
  1780   unsigned long *aqm_unassign)
  1781  {
  1782  unsigned long apqi;
  1783  bool unassigned = false;
  1784  
  1785  /*
  1786   * If the matrix mdev is not in use by a KVM guest, return 
indicating
  1787   * that no APQIs have been unassigned.
  1788   */
  1789  if (!vfio_ap_mdev_has_crycb(matrix_mdev))
  1790  return false;
  1791  
  1792  for_each_set_bit_in

[PATCH v3 4/6] arm64: dts: qcom: SDM845: Enable GPU DDR bw scaling

This patch adds the interconnects property for the gpu node and the
opp-peak-kBps property to the opps of the gpu opp table. This should
help enable DDR bandwidth scaling dynamically and proportionally to the
GPU frequency.

Signed-off-by: Sharat Masetty 
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 11fc3f24..6ea6f54 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -3240,6 +3240,8 @@

qcom,gmu = <>;

+   interconnects = <_noc MASTER_GFX3D _noc 
SLAVE_EBI1>;
+
zap_shader: zap-shader {
memory-region = <_mem>;
};
@@ -3250,36 +3252,43 @@
opp-71000 {
opp-hz = /bits/ 64 <71000>;
opp-level = 
;
+   opp-peak-kBps = <7216000>;
};

opp-67500 {
opp-hz = /bits/ 64 <67500>;
opp-level = 
;
+   opp-peak-kBps = <7216000>;
};

opp-59600 {
opp-hz = /bits/ 64 <59600>;
opp-level = 
;
+   opp-peak-kBps = <622>;
};

opp-52000 {
opp-hz = /bits/ 64 <52000>;
opp-level = ;
+   opp-peak-kBps = <622>;
};

opp-41400 {
opp-hz = /bits/ 64 <41400>;
opp-level = 
;
+   opp-peak-kBps = <4068000>;
};

opp-34200 {
opp-hz = /bits/ 64 <34200>;
opp-level = ;
+   opp-peak-kBps = <2724000>;
};

opp-25700 {
opp-hz = /bits/ 64 <25700>;
opp-level = 
;
+   opp-peak-kBps = <1648000>;
};
};
};
--
2.7.4

[PATCH v3 1/6] dt-bindings: drm/msm/gpu: Document gpu opp table

Update documentation to list the gpu opp table bindings including the
newly added "opp-peak-kBps" needed for GPU-DDR bandwidth scaling.

Signed-off-by: Sharat Masetty 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/display/msm/gpu.txt| 28 ++
 1 file changed, 28 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt 
b/Documentation/devicetree/bindings/display/msm/gpu.txt
index 70025cb..48bd4ab 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
@@ -79,6 +79,34 @@ Example a6xx (with GMU):

interconnects = <_hlos MASTER_GFX3D _hlos SLAVE_EBI1>;

+   gpu_opp_table: opp-table {
+   compatible = "operating-points-v2";
+
+   opp-43000 {
+   opp-hz = /bits/ 64 <43000>;
+   opp-level = ;
+   opp-peak-kBps = <5412000>;
+   };
+
+   opp-35500 {
+   opp-hz = /bits/ 64 <35500>;
+   opp-level = ;
+   opp-peak-kBps = <3072000>;
+   };
+
+   opp-26700 {
+   opp-hz = /bits/ 64 <26700>;
+   opp-level = ;
+   opp-peak-kBps = <3072000>;
+   };
+
+   opp-18000 {
+   opp-hz = /bits/ 64 <18000>;
+   opp-level = ;
+   opp-peak-kBps = <1804000>;
+   };
+   };
+
qcom,gmu = <>;

zap-shader {
--
2.7.4

[PATCH v3 2/6] drm: msm: a6xx: send opp instead of a frequency

This patch changes the plumbing to send the devfreq recommended opp rather
than the frequency. Also consolidate and rearrange the code in a6xx to set
the GPU frequency and the icc vote in preparation for the upcoming
changes for GPU->DDR scaling votes.

Signed-off-by: Sharat Masetty 
---
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 62 +++
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h |  2 +-
 drivers/gpu/drm/msm/msm_gpu.c |  3 +-
 drivers/gpu/drm/msm/msm_gpu.h |  3 +-
 4 files changed, 38 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 748cd37..2d8124b 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -100,17 +100,30 @@ bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF));
 }

-static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
+void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct dev_pm_opp *opp)
 {
-   struct a6xx_gpu *a6xx_gpu = container_of(gmu, struct a6xx_gpu, gmu);
-   struct adreno_gpu *adreno_gpu = _gpu->base;
-   struct msm_gpu *gpu = _gpu->base;
-   int ret;
+   struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+   struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
+   struct a6xx_gmu *gmu = _gpu->gmu;
+   u32 perf_index;
+   unsigned long gpu_freq;
+   int ret = 0;
+
+   gpu_freq = dev_pm_opp_get_freq(opp);
+
+   if (gpu_freq == gmu->freq)
+   return;
+
+   for (perf_index = 0; perf_index < gmu->nr_gpu_freqs - 1; perf_index++)
+   if (gpu_freq == gmu->gpu_freqs[perf_index])
+   break;
+
+   gmu->current_perf_index = perf_index;

gmu_write(gmu, REG_A6XX_GMU_DCVS_ACK_OPTION, 0);

gmu_write(gmu, REG_A6XX_GMU_DCVS_PERF_SETTING,
-   ((3 & 0xf) << 28) | index);
+   ((3 & 0xf) << 28) | perf_index);

/*
 * Send an invalid index as a vote for the bus bandwidth and let the
@@ -126,7 +139,7 @@ static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int 
index)
if (ret)
dev_err(gmu->dev, "GMU set GPU frequency error: %d\n", ret);

-   gmu->freq = gmu->gpu_freqs[index];
+   gmu->freq = gmu->gpu_freqs[perf_index];

/*
 * Eventually we will want to scale the path vote with the frequency but
@@ -135,25 +148,6 @@ static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int 
index)
icc_set_bw(gpu->icc_path, 0, MBps_to_icc(7216));
 }

-void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq)
-{
-   struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
-   struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
-   struct a6xx_gmu *gmu = _gpu->gmu;
-   u32 perf_index = 0;
-
-   if (freq == gmu->freq)
-   return;
-
-   for (perf_index = 0; perf_index < gmu->nr_gpu_freqs - 1; perf_index++)
-   if (freq == gmu->gpu_freqs[perf_index])
-   break;
-
-   gmu->current_perf_index = perf_index;
-
-   __a6xx_gmu_set_freq(gmu, perf_index);
-}
-
 unsigned long a6xx_gmu_get_freq(struct msm_gpu *gpu)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -708,6 +702,19 @@ static void a6xx_gmu_force_off(struct a6xx_gmu *gmu)
a6xx_gmu_rpmh_off(gmu);
 }

+static void a6xx_gmu_set_initial_freq(struct msm_gpu *gpu, struct a6xx_gmu 
*gmu)
+{
+   struct dev_pm_opp *gpu_opp;
+   unsigned long gpu_freq = gmu->gpu_freqs[gmu->current_perf_index];
+
+   gpu_opp = dev_pm_opp_find_freq_exact(>pdev->dev, gpu_freq, true);
+   if (IS_ERR_OR_NULL(gpu_opp))
+   return;
+
+   a6xx_gmu_set_freq(gpu, gpu_opp);
+   dev_pm_opp_put(gpu_opp);
+}
+
 int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
 {
struct adreno_gpu *adreno_gpu = _gpu->base;
@@ -759,8 +766,7 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
gmu_write(gmu, REG_A6XX_GMU_GMU2HOST_INTR_MASK, ~A6XX_HFI_IRQ_MASK);
enable_irq(gmu->hfi_irq);

-   /* Set the GPU to the current freq */
-   __a6xx_gmu_set_freq(gmu, gmu->current_perf_index);
+   a6xx_gmu_set_initial_freq(gpu, gmu);

/*
 * "enable" the GX power domain which won't actually do anything but it
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
index 7239b8b..03ba60d 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
@@ -63,7 +63,7 @@ void a6xx_gmu_clear_oob(struct a6xx_gmu *gmu, enum 
a6xx_gmu_oob_state state);
 int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct device_node *node);
 void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu);

-void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq);
+void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct dev_pm_opp *opp);
 unsigned long a6xx_gmu_get_freq(struct msm_gpu *gpu);

 void

[PATCH v3 6/6] arm64: dts: qcom: sc7180: Add opp-peak-kBps to GPU opp

Add opp-peak-kBps bindings to the GPU opp table, listing the peak
GPU -> DDR bandwidth requirement for each opp level. This will be
used to scale the DDR bandwidth along with the GPU frequency dynamically.

Signed-off-by: Sharat Masetty 
Reviewed-by: Matthias Kaehlcke 
---
 arch/arm64/boot/dts/qcom/sc7180.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi 
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 34004ad..7bef42b 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -1505,36 +1505,43 @@
opp-8 {
opp-hz = /bits/ 64 <8>;
opp-level = 
;
+   opp-peak-kBps = <8532000>;
};

opp-65000 {
opp-hz = /bits/ 64 <65000>;
opp-level = 
;
+   opp-peak-kBps = <7216000>;
};

opp-56500 {
opp-hz = /bits/ 64 <56500>;
opp-level = ;
+   opp-peak-kBps = <5412000>;
};

opp-43000 {
opp-hz = /bits/ 64 <43000>;
opp-level = 
;
+   opp-peak-kBps = <5412000>;
};

opp-35500 {
opp-hz = /bits/ 64 <35500>;
opp-level = ;
+   opp-peak-kBps = <3072000>;
};

opp-26700 {
opp-hz = /bits/ 64 <26700>;
opp-level = 
;
+   opp-peak-kBps = <3072000>;
};

opp-18000 {
opp-hz = /bits/ 64 <18000>;
opp-level = 
;
+   opp-peak-kBps = <1804000>;
};
};
};
--
2.7.4

[PATCH v3 3/6] drm: msm: a6xx: use dev_pm_opp_set_bw to scale DDR

This patches replaces the previously used static DDR vote and uses
dev_pm_opp_set_bw() to scale GPU->DDR bandwidth along with scaling
GPU frequency. Also since the icc path voting is handled completely
in the opp driver, remove the icc_path handle and its usage in the
drm driver.

Signed-off-by: Sharat Masetty 
---
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c   | 23 ---
 drivers/gpu/drm/msm/adreno/adreno_gpu.c |  8 
 drivers/gpu/drm/msm/msm_gpu.h   |  2 --
 3 files changed, 16 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 2d8124b..1dd8fc5 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -141,11 +141,7 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct 
dev_pm_opp *opp)

gmu->freq = gmu->gpu_freqs[perf_index];

-   /*
-* Eventually we will want to scale the path vote with the frequency but
-* for now leave it at max so that the performance is nominal.
-*/
-   icc_set_bw(gpu->icc_path, 0, MBps_to_icc(7216));
+   dev_pm_opp_set_bw(>pdev->dev, opp);
 }

 unsigned long a6xx_gmu_get_freq(struct msm_gpu *gpu)
@@ -715,6 +711,19 @@ static void a6xx_gmu_set_initial_freq(struct msm_gpu *gpu, 
struct a6xx_gmu *gmu)
dev_pm_opp_put(gpu_opp);
 }

+static void a6xx_gmu_set_initial_bw(struct msm_gpu *gpu, struct a6xx_gmu *gmu)
+{
+   struct dev_pm_opp *gpu_opp;
+   unsigned long gpu_freq = gmu->gpu_freqs[gmu->current_perf_index];
+
+   gpu_opp = dev_pm_opp_find_freq_exact(>pdev->dev, gpu_freq, true);
+   if (IS_ERR_OR_NULL(gpu_opp))
+   return;
+
+   dev_pm_opp_set_bw(>pdev->dev, gpu_opp);
+   dev_pm_opp_put(gpu_opp);
+}
+
 int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
 {
struct adreno_gpu *adreno_gpu = _gpu->base;
@@ -739,7 +748,7 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
}

/* Set the bus quota to a reasonable value for boot */
-   icc_set_bw(gpu->icc_path, 0, MBps_to_icc(3072));
+   a6xx_gmu_set_initial_bw(gpu, gmu);

/* Enable the GMU interrupt */
gmu_write(gmu, REG_A6XX_GMU_AO_HOST_INTERRUPT_CLR, ~0);
@@ -907,7 +916,7 @@ int a6xx_gmu_stop(struct a6xx_gpu *a6xx_gpu)
a6xx_gmu_shutdown(gmu);

/* Remove the bus vote */
-   icc_set_bw(gpu->icc_path, 0, 0);
+   dev_pm_opp_set_bw(>pdev->dev, NULL);

/*
 * Make sure the GX domain is off before turning off the GMU (CX)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 2d13694..718c705 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -913,11 +913,6 @@ static int adreno_get_pwrlevels(struct device *dev,

DBG("fast_rate=%u, slow_rate=2700", gpu->fast_rate);

-   /* Check for an interconnect path for the bus */
-   gpu->icc_path = of_icc_get(dev, NULL);
-   if (IS_ERR(gpu->icc_path))
-   gpu->icc_path = NULL;
-
return 0;
 }

@@ -958,13 +953,10 @@ int adreno_gpu_init(struct drm_device *drm, struct 
platform_device *pdev,

 void adreno_gpu_cleanup(struct adreno_gpu *adreno_gpu)
 {
-   struct msm_gpu *gpu = _gpu->base;
unsigned int i;

for (i = 0; i < ARRAY_SIZE(adreno_gpu->info->fw); i++)
release_firmware(adreno_gpu->fw[i]);

-   icc_put(gpu->icc_path);
-
msm_gpu_cleanup(_gpu->base);
 }
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index cf0dc6d..c7d74a9 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -112,8 +112,6 @@ struct msm_gpu {
struct clk *ebi1_clk, *core_clk, *rbbmtimer_clk;
uint32_t fast_rate;

-   struct icc_path *icc_path;
-
/* Hang and Inactivity Detection:
 */
 #define DRM_MSM_INACTIVE_PERIOD   66 /* in ms (roughly four frames) */
--
2.7.4

[PATCH v3 5/6] arm64: dts: qcom: sc7180: Add interconnects property for GPU

This patch adds the interconnects property to the GPU node. This enables
the GPU->DDR path bandwidth voting.

Signed-off-by: Sharat Masetty 
---
 arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi 
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index eaede5e..34004ad 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -1497,6 +1497,8 @@
operating-points-v2 = <_opp_table>;
qcom,gmu = <>;

+   interconnects = <_noc MASTER_GFX3D _virt 
SLAVE_EBI1>;
+
gpu_opp_table: opp-table {
compatible = "operating-points-v2";

--
2.7.4

[PATCH v3 0/6] Add support for GPU DDR BW scaling

This is a respin of [1]. Incorported review feedback and fixed issues observed
during testing. Picked up the Georgi's series from opp/linux-next [2], and this
series is also dependent on a helper function needed to set and clear ddr
bandwidth vote [3]. Patch number 4 in the series adds support for SDM845 as well
but its not tested yet(WIP), but the SC7180 patches are well tested now.

[1] https://patchwork.freedesktop.org/series/75291/
[2] 
https://kernel.googlesource.com/pub/scm/linux/kernel/git/vireshk/pm/+log/opp/linux-next/
[3] https://patchwork.kernel.org/patch/11590563/

Sharat Masetty (6):
  dt-bindings: drm/msm/gpu: Document gpu opp table
  drm: msm: a6xx: send opp instead of a frequency
  drm: msm: a6xx: use dev_pm_opp_set_bw to scale DDR
  arm64: dts: qcom: SDM845: Enable GPU DDR bw scaling
  arm64: dts: qcom: sc7180: Add interconnects property for GPU
  arm64: dts: qcom: sc7180: Add opp-peak-kBps to GPU opp

 .../devicetree/bindings/display/msm/gpu.txt| 28 +++
 arch/arm64/boot/dts/qcom/sc7180.dtsi   |  9 +++
 arch/arm64/boot/dts/qcom/sdm845.dtsi   |  9 +++
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c  | 85 +-
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h  |  2 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.c|  8 --
 drivers/gpu/drm/msm/msm_gpu.c  |  3 +-
 drivers/gpu/drm/msm/msm_gpu.h  |  5 +-
 8 files changed, 100 insertions(+), 49 deletions(-)

--
2.7.4

IS THIS EMAIL ACTIVE?

2020-06-05 Thread Anders Karlsson

I have an urgent message for you, reply me now


Anders Karlsson, CFO Swedbank

[PATCH v8 2/5] KUnit: KASAN Integration

From: Patricia Alfonso 

Integrate KASAN into KUnit testing framework.
- Fail tests when KASAN reports an error that is not expected
- Use KUNIT_EXPECT_KASAN_FAIL to expect a KASAN error in KASAN
tests
- Expected KASAN reports pass tests and are still printed when run
without kunit_tool (kunit_tool still bypasses the report due to the
test passing)
- KUnit struct in current task used to keep track of the current
test from KASAN code

This patch makes use of "kunit: generalize kunit_resource API beyond
allocated resources" and "kunit: add support for named resources" from
Alan Maguire [1]
- A named resource is added to a test when a KASAN report is
expected
- This resource contains a struct for kasan_data containing
booleans representing if a KASAN report is expected and if a KASAN
report is found

[1] 
https://lore.kernel.org/linux-kselftest/cafd5g46uu_5tg89uom0dj5cmq+11cwjbnsd-k_cvy6bqueu...@mail.gmail.com/T/#t

Signed-off-by: Patricia Alfonso 
Signed-off-by: David Gow 
Reviewed-by: Dmitry Vyukov 
Reviewed-by: Andrey Konovalov 
---
 include/kunit/test.h  |  5 +
 include/linux/kasan.h |  6 ++
 lib/kunit/test.c  | 13 +++-
 lib/test_kasan.c  | 47 +--
 mm/kasan/report.c | 32 +
 5 files changed, 96 insertions(+), 7 deletions(-)

diff --git a/include/kunit/test.h b/include/kunit/test.h
index 59f3144f009a..3391f38389f8 100644
--- a/include/kunit/test.h
+++ b/include/kunit/test.h
@@ -224,6 +224,11 @@ struct kunit {
struct list_head resources; /* Protected by lock. */
 };
 
+static inline void kunit_set_failure(struct kunit *test)
+{
+   WRITE_ONCE(test->success, false);
+}
+
 void kunit_init_test(struct kunit *test, const char *name, char *log);
 
 int kunit_run_tests(struct kunit_suite *suite);
diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index 31314ca7c635..d58db2f67f43 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -14,6 +14,12 @@ struct task_struct;
 #include 
 #include 
 
+/* kasan_data struct is used in KUnit tests for KASAN expected failures */
+struct kunit_kasan_expectation {
+   bool report_expected;
+   bool report_found;
+};
+
 extern unsigned char kasan_early_shadow_page[PAGE_SIZE];
 extern pte_t kasan_early_shadow_pte[PTRS_PER_PTE];
 extern pmd_t kasan_early_shadow_pmd[PTRS_PER_PMD];
diff --git a/lib/kunit/test.c b/lib/kunit/test.c
index c36037200310..dcc35fd30d95 100644
--- a/lib/kunit/test.c
+++ b/lib/kunit/test.c
@@ -10,16 +10,12 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "debugfs.h"
 #include "string-stream.h"
 #include "try-catch-impl.h"
 
-static void kunit_set_failure(struct kunit *test)
-{
-   WRITE_ONCE(test->success, false);
-}
-
 static void kunit_print_tap_version(void)
 {
static bool kunit_has_printed_tap_version;
@@ -288,6 +284,10 @@ static void kunit_try_run_case(void *data)
struct kunit_suite *suite = ctx->suite;
struct kunit_case *test_case = ctx->test_case;
 
+#if (IS_ENABLED(CONFIG_KASAN) && IS_ENABLED(CONFIG_KUNIT))
+   current->kunit_test = test;
+#endif /* IS_ENABLED(CONFIG_KASAN) && IS_ENABLED(CONFIG_KUNIT) */
+
/*
 * kunit_run_case_internal may encounter a fatal error; if it does,
 * abort will be called, this thread will exit, and finally the parent
@@ -602,6 +602,9 @@ void kunit_cleanup(struct kunit *test)
spin_unlock(>lock);
kunit_remove_resource(test, res);
}
+#if (IS_ENABLED(CONFIG_KASAN) && IS_ENABLED(CONFIG_KUNIT))
+   current->kunit_test = NULL;
+#endif /* IS_ENABLED(CONFIG_KASAN) && IS_ENABLED(CONFIG_KUNIT)*/
 }
 EXPORT_SYMBOL_GPL(kunit_cleanup);
 
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index dc2c6a51d11a..842adcd30943 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -23,19 +23,62 @@
 
 #include 
 
+#include 
+
 /*
  * We assign some test results to these globals to make sure the tests
  * are not eliminated as dead code.
  */
 
-int kasan_int_result;
 void *kasan_ptr_result;
+int kasan_int_result;
+
+static struct kunit_resource resource;
+static struct kunit_kasan_expectation fail_data;
+static bool multishot;
+
+static int kasan_test_init(struct kunit *test)
+{
+   /*
+* Temporarily enable multi-shot mode and set panic_on_warn=0.
+* Otherwise, we'd only get a report for the first case.
+*/
+   multishot = kasan_save_enable_multi_shot();
+
+   return 0;
+}
+
+static void kasan_test_exit(struct kunit *test)
+{
+   kasan_restore_multi_shot(multishot);
+}
+
+/**
+ * KUNIT_EXPECT_KASAN_FAIL() - Causes a test failure when the expression does
+ * not cause a KASAN error. This uses a KUnit resource named "kasan_data." Do
+ * Do not use this name for a KUnit resource outside here.
+ *
+ */
+#define KUNIT_EXPECT_KASAN_FAIL(test, condition) do { \
+

[PATCH v8 3/5] KASAN: Port KASAN Tests to KUnit

From: Patricia Alfonso 

Transfer all previous tests for KASAN to KUnit so they can be run
more easily. Using kunit_tool, developers can run these tests with their
other KUnit tests and see "pass" or "fail" with the appropriate KASAN
report instead of needing to parse each KASAN report to test KASAN
functionalities. All KASAN reports are still printed to dmesg.

Stack tests do not work properly when KASAN_STACK is enabled so
those tests use a check for "if IS_ENABLED(CONFIG_KASAN_STACK)" so they
only run if stack instrumentation is enabled. If KASAN_STACK is not
enabled, KUnit will print a statement to let the user know this test
was not run with KASAN_STACK enabled.

copy_user_test cannot be run in KUnit so there is a separate test file
for those tests, which can be run as before as a module.

Signed-off-by: Patricia Alfonso 
Reviewed-by: Dmitry Vyukov 
Reviewed-by: Brendan Higgins 
Reviewed-by: Andrey Konovalov 
Signed-off-by: David Gow 
---
 lib/Kconfig.kasan   |  19 +-
 lib/Makefile|   3 +-
 lib/test_kasan.c| 647 
 lib/test_kasan_module.c |  76 +
 4 files changed, 347 insertions(+), 398 deletions(-)
 create mode 100644 lib/test_kasan_module.c

diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index 81f5464ea9e1..e30942e88054 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -158,10 +158,19 @@ config KASAN_VMALLOC
  for KASAN to detect more sorts of errors (and to support vmapped
  stacks), but at the cost of higher memory usage.
 
-config TEST_KASAN
-   tristate "Module for testing KASAN for bug detection"
-   depends on m && KASAN
+config TEST_KASAN_KUNIT
+   tristate "KUnit-compatible tests of KASAN bug detection capabilities" 
if !KUNIT_ALL_TESTS
+   depends on KASAN && KUNIT
+   default KUNIT_ALL_TESTS
help
- This is a test module doing various nasty things like
- out of bounds accesses, use after free. It is useful for testing
+ This is a KUnit test suite doing various nasty things like
+ out of bounds and use after free accesses. It is useful for testing
  kernel debugging features like KASAN.
+
+config TEST_KASAN_MODULE
+   tristate "KUnit-incompatible tests of KASAN bug detection capabilities"
+   depends on m && KASAN
+   help
+ This is a part of the KASAN test suite that is incompatible with
+ KUnit. Currently includes tests that do bad copy_from/to_user
+ accesses.
diff --git a/lib/Makefile b/lib/Makefile
index 685aee60de1d..361f438c066a 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -59,9 +59,10 @@ obj-$(CONFIG_TEST_FIRMWARE) += test_firmware.o
 obj-$(CONFIG_TEST_SYSCTL) += test_sysctl.o
 obj-$(CONFIG_TEST_HASH) += test_hash.o test_siphash.o
 obj-$(CONFIG_TEST_IDA) += test_ida.o
-obj-$(CONFIG_TEST_KASAN) += test_kasan.o
+obj-$(CONFIG_TEST_KASAN_KUNIT) += test_kasan.o
 CFLAGS_test_kasan.o += -fno-builtin
 CFLAGS_test_kasan.o += $(call cc-disable-warning, vla)
+obj-$(CONFIG_TEST_KASAN_MODULE) += test_kasan_module.o
 obj-$(CONFIG_TEST_UBSAN) += test_ubsan.o
 CFLAGS_test_ubsan.o += $(call cc-disable-warning, vla)
 UBSAN_SANITIZE_test_ubsan.o := y
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index 842adcd30943..9949e99667b5 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -5,8 +5,6 @@
  * Author: Andrey Ryabinin 
  */
 
-#define pr_fmt(fmt) "kasan test: %s " fmt, __func__
-
 #include 
 #include 
 #include 
@@ -73,405 +71,327 @@ static void kasan_test_exit(struct kunit *test)
fail_data.report_found); \
 } while (0)
 
-
-
-/*
- * Note: test functions are marked noinline so that their names appear in
- * reports.
- */
-static noinline void __init kmalloc_oob_right(void)
+static void kmalloc_oob_right(struct kunit *test)
 {
char *ptr;
size_t size = 123;
 
-   pr_info("out-of-bounds to right\n");
ptr = kmalloc(size, GFP_KERNEL);
-   if (!ptr) {
-   pr_err("Allocation failed\n");
-   return;
-   }
+   KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr);
 
-   ptr[size] = 'x';
+   KUNIT_EXPECT_KASAN_FAIL(test, ptr[size] = 'x');
kfree(ptr);
 }
 
-static noinline void __init kmalloc_oob_left(void)
+static void kmalloc_oob_left(struct kunit *test)
 {
char *ptr;
size_t size = 15;
 
-   pr_info("out-of-bounds to left\n");
ptr = kmalloc(size, GFP_KERNEL);
-   if (!ptr) {
-   pr_err("Allocation failed\n");
-   return;
-   }
+   KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr);
 
-   *ptr = *(ptr - 1);
+   KUNIT_EXPECT_KASAN_FAIL(test, *ptr = *(ptr - 1));
kfree(ptr);
 }
 
-static noinline void __init kmalloc_node_oob_right(void)
+static void kmalloc_node_oob_right(struct kunit *test)
 {
char *ptr;
size_t size = 4096;
 
-   pr_info("kmalloc_node(): out-of-bounds to right\n");
ptr = kmalloc_node(size, GFP_KERNEL, 0);
-

[PATCH v2 1/2] MIPS: Set page access bit with pgprot on platforms with RIXI

2020-06-05 Thread Bibo Mao

On MIPS system which has rixi hardware bit, page access bit is not
set in pgrot. For memory reading, there will be one page fault to
allocate physical page; however valid bit is not set, there will
be the second fast tlb-miss fault handling to set valid/access bit.

This patch set page access/valid bit with pgrot if there is reading
access privilege. It will reduce one tlb-miss handling for memory
reading access.

The valid/access bit will be cleared in order to track memory
accessing activity. If the page is accessed, tlb-miss fast handling
will set valid/access bit, pte_sw_mkyoung is not necessary in slow
page fault path. This patch removes pte_sw_mkyoung function which
is defined as empty function except MIPS system.

Signed-off-by: Bibo Mao 
Acked-by: Andrew Morton 
---
v2:
- refine commit log title
---
 arch/mips/include/asm/pgtable.h | 10 --
 arch/mips/mm/cache.c| 34 +-
 include/asm-generic/pgtable.h   | 16 
 mm/memory.c |  3 ---
 4 files changed, 25 insertions(+), 38 deletions(-)

diff --git a/arch/mips/include/asm/pgtable.h b/arch/mips/include/asm/pgtable.h
index 85b39c9..d066469 100644
--- a/arch/mips/include/asm/pgtable.h
+++ b/arch/mips/include/asm/pgtable.h
@@ -25,6 +25,14 @@
 struct mm_struct;
 struct vm_area_struct;
 
+#define __PP   _PAGE_PRESENT
+#define __NX   _PAGE_NO_EXEC
+#define __NR   _PAGE_NO_READ
+#define ___W   _PAGE_WRITE
+#define ___A   _PAGE_ACCESSED
+#define ___R   (_PAGE_SILENT_READ | _PAGE_ACCESSED)
+#define __PC   _page_cachable_default
+
 #define PAGE_NONE  __pgprot(_PAGE_PRESENT | _PAGE_NO_READ | \
 _page_cachable_default)
 #define PAGE_SHARED__pgprot(_PAGE_PRESENT | _PAGE_WRITE | \
@@ -414,8 +422,6 @@ static inline pte_t pte_mkyoung(pte_t pte)
return pte;
 }
 
-#define pte_sw_mkyoung pte_mkyoung
-
 #ifdef CONFIG_MIPS_HUGE_TLB_SUPPORT
 static inline int pte_huge(pte_t pte)  { return pte_val(pte) & _PAGE_HUGE; }
 
diff --git a/arch/mips/mm/cache.c b/arch/mips/mm/cache.c
index ad6df1c..f814e43 100644
--- a/arch/mips/mm/cache.c
+++ b/arch/mips/mm/cache.c
@@ -158,23 +158,23 @@ void __update_cache(unsigned long address, pte_t pte)
 static inline void setup_protection_map(void)
 {
if (cpu_has_rixi) {
-   protection_map[0]  = __pgprot(_page_cachable_default | 
_PAGE_PRESENT | _PAGE_NO_EXEC | _PAGE_NO_READ);
-   protection_map[1]  = __pgprot(_page_cachable_default | 
_PAGE_PRESENT | _PAGE_NO_EXEC);
-   protection_map[2]  = __pgprot(_page_cachable_default | 
_PAGE_PRESENT | _PAGE_NO_EXEC | _PAGE_NO_READ);
-   protection_map[3]  = __pgprot(_page_cachable_default | 
_PAGE_PRESENT | _PAGE_NO_EXEC);
-   protection_map[4]  = __pgprot(_page_cachable_default | 
_PAGE_PRESENT);
-   protection_map[5]  = __pgprot(_page_cachable_default | 
_PAGE_PRESENT);
-   protection_map[6]  = __pgprot(_page_cachable_default | 
_PAGE_PRESENT);
-   protection_map[7]  = __pgprot(_page_cachable_default | 
_PAGE_PRESENT);
-
-   protection_map[8]  = __pgprot(_page_cachable_default | 
_PAGE_PRESENT | _PAGE_NO_EXEC | _PAGE_NO_READ);
-   protection_map[9]  = __pgprot(_page_cachable_default | 
_PAGE_PRESENT | _PAGE_NO_EXEC);
-   protection_map[10] = __pgprot(_page_cachable_default | 
_PAGE_PRESENT | _PAGE_NO_EXEC | _PAGE_WRITE | _PAGE_NO_READ);
-   protection_map[11] = __pgprot(_page_cachable_default | 
_PAGE_PRESENT | _PAGE_NO_EXEC | _PAGE_WRITE);
-   protection_map[12] = __pgprot(_page_cachable_default | 
_PAGE_PRESENT);
-   protection_map[13] = __pgprot(_page_cachable_default | 
_PAGE_PRESENT);
-   protection_map[14] = __pgprot(_page_cachable_default | 
_PAGE_PRESENT | _PAGE_WRITE);
-   protection_map[15] = __pgprot(_page_cachable_default | 
_PAGE_PRESENT | _PAGE_WRITE);
+   protection_map[0]  = __pgprot(__PC | __PP | __NX | __NR);
+   protection_map[1]  = __pgprot(__PC | __PP | __NX | ___R);
+   protection_map[2]  = __pgprot(__PC | __PP | __NX | __NR);
+   protection_map[3]  = __pgprot(__PC | __PP | __NX | ___R);
+   protection_map[4]  = __pgprot(__PC | __PP | ___R);
+   protection_map[5]  = __pgprot(__PC | __PP | ___R);
+   protection_map[6]  = __pgprot(__PC | __PP | ___R);
+   protection_map[7]  = __pgprot(__PC | __PP | ___R);
+
+   protection_map[8]  = __pgprot(__PC | __PP | __NX | __NR);
+   protection_map[9]  = __pgprot(__PC | __PP | __NX | ___R);
+   protection_map[10] = __pgprot(__PC | __PP | __NX | ___W | __NR);
+   protection_map[11] = __pgprot(__PC | __PP | __NX | ___W | ___R);
+   protection_map[12] = __pgprot(__PC | __PP | ___R);
+   protection_map[13] = __pgprot(__PC | __PP | ___R);
+

[PATCH v8 5/5] mm: kasan: Do not panic if both panic_on_warn and kasan_multishot set

KASAN errors will currently trigger a panic when panic_on_warn is set.
This renders kasan_multishot useless, as further KASAN errors won't be
reported if the kernel has already paniced. By making kasan_multishot
disable this behaviour for KASAN errors, we can still have the benefits
of panic_on_warn for non-KASAN warnings, yet be able to use
kasan_multishot.

This is particularly important when running KASAN tests, which need to
trigger multiple KASAN errors: previously these would panic the system
if panic_on_warn was set, now they can run (and will panic the system
should non-KASAN warnings show up).

Signed-off-by: David Gow 
Reviewed-by: Andrey Konovalov 
---
 mm/kasan/report.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 45f3c23f54cb..dc9fc5c09ea3 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -94,7 +94,7 @@ static void end_report(unsigned long *flags)

pr_err("==\n");
add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE);
spin_unlock_irqrestore(_lock, *flags);
-   if (panic_on_warn) {
+   if (panic_on_warn && !test_bit(KASAN_BIT_MULTI_SHOT, _flags)) {
/*
 * This thread may hit another WARN() in the panic path.
 * Resetting this prevents additional WARN() from panicking the
-- 
2.27.0.278.ge193c7cf3a9-goog

[PATCH v8 4/5] KASAN: Testing Documentation

From: Patricia Alfonso 

Include documentation on how to test KASAN using CONFIG_TEST_KASAN_KUNIT
and CONFIG_TEST_KASAN_MODULE.

Signed-off-by: Patricia Alfonso 
Reviewed-by: Dmitry Vyukov 
Signed-off-by: David Gow 
Reviewed-by: Andrey Konovalov 

---
 Documentation/dev-tools/kasan.rst | 70 +++
 1 file changed, 70 insertions(+)

diff --git a/Documentation/dev-tools/kasan.rst 
b/Documentation/dev-tools/kasan.rst
index c652d740735d..b4b109d88f9e 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -281,3 +281,73 @@ unmapped. This will require changes in arch-specific code.
 
 This allows ``VMAP_STACK`` support on x86, and can simplify support of
 architectures that do not have a fixed module region.
+
+CONFIG_TEST_KASAN_KUNIT & CONFIG_TEST_KASAN_MODULE
+--
+
+``CONFIG_TEST_KASAN_KUNIT`` utilizes the KUnit Test Framework for testing.
+This means each test focuses on a small unit of functionality and
+there are a few ways these tests can be run.
+
+Each test will print the KASAN report if an error is detected and then
+print the number of the test and the status of the test:
+
+pass::
+
+ok 28 - kmalloc_double_kzfree
+or, if kmalloc failed::
+
+# kmalloc_large_oob_right: ASSERTION FAILED at lib/test_kasan.c:163
+Expected ptr is not null, but is
+not ok 4 - kmalloc_large_oob_right
+or, if a KASAN report was expected, but not found::
+
+# kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:629
+Expected kasan_data->report_expected == kasan_data->report_found, but
+kasan_data->report_expected == 1
+kasan_data->report_found == 0
+not ok 28 - kmalloc_double_kzfree
+
+All test statuses are tracked as they run and an overall status will
+be printed at the end::
+
+ok 1 - kasan_kunit_test
+
+or::
+
+not ok 1 - kasan_kunit_test
+
+(1) Loadable Module
+
+
+With ``CONFIG_KUNIT`` enabled, ``CONFIG_TEST_KASAN_KUNIT`` can be built as
+a loadable module and run on any architecture that supports KASAN
+using something like insmod or modprobe.
+
+(2) Built-In
+~
+
+With ``CONFIG_KUNIT`` built-in, ``CONFIG_TEST_KASAN_KUNIT`` can be built-in
+on any architecure that supports KASAN. These and any other KUnit
+tests enabled will run and print the results at boot as a late-init
+call.
+
+(3) Using kunit_tool
+~
+
+With ``CONFIG_KUNIT`` and ``CONFIG_TEST_KASAN_KUNIT`` built-in, we can also
+use kunit_tool to see the results of these along with other KUnit
+tests in a more readable way. This will not print the KASAN reports
+of tests that passed. Use `KUnit documentation 
`_ for more 
up-to-date
+information on kunit_tool.
+
+.. _KUnit: https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html
+
+``CONFIG_TEST_KASAN_MODULE`` is a set of KASAN tests that could not be
+converted to KUnit. These tests can be run only as a module with
+``CONFIG_TEST_KASAN_MODULE`` built as a loadable module and
+``CONFIG_KASAN`` built-in. The type of error expected and the
+function being run is printed before the expression expected to give
+an error. Then the error is printed, if found, and that test
+should be interpretted to pass only if the error was the one expected
+by the test.
-- 
2.27.0.278.ge193c7cf3a9-goog

[PATCH v8 1/5] Add KUnit Struct to Current Task

From: Patricia Alfonso 

In order to integrate debugging tools like KASAN into the KUnit
framework, add KUnit struct to the current task to keep track of the
current KUnit test.

Signed-off-by: Patricia Alfonso 
Reviewed-by: Brendan Higgins 
Signed-off-by: David Gow 
---
 include/linux/sched.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 4418f5cb8324..e50c568a8dc7 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1188,6 +1188,10 @@ struct task_struct {
unsigned intkasan_depth;
 #endif
 
+#if IS_ENABLED(CONFIG_KUNIT)
+   struct kunit*kunit_test;
+#endif
+
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
/* Index of current stored address in ret_stack: */
int curr_ret_stack;
-- 
2.27.0.278.ge193c7cf3a9-goog

[PATCH v8 0/5] KUnit-KASAN Integration

This patchset contains everything needed to integrate KASAN and KUnit.

KUnit will be able to:
(1) Fail tests when an unexpected KASAN error occurs
(2) Pass tests when an expected KASAN error occurs

Convert KASAN tests to KUnit with the exception of copy_user_test
because KUnit is unable to test those.

Add documentation on how to run the KASAN tests with KUnit and what to
expect when running these tests.

This patchset depends on:
- "kunit: extend kunit resources API" [1]
- "Fix some incompatibilites between KASAN and FORTIFY_SOURCE" [2]
- This is already upstream for 5.8[3,4]

Changes from v7:
- Rebased on top of kselftest/kunit
- Rebased on top of v4 of the kunit resources API[1]
- Rebased on top of v4 of the FORTIFY_SOURCE fix[2,3,4]
- Updated the Kconfig entry to support KUNIT_ALL_TESTS

Changes from v6:
- Rebased on top of kselftest/kunit
- Rebased on top of Daniel Axtens' fix for FORTIFY_SOURCE
incompatibilites [2]
- Removed a redundant report_enabled() check.
- Fixed some places with out of date Kconfig names in the
documentation.

Changes from v5:
- Split out the panic_on_warn changes to a separate patch.
- Fix documentation to fewer to the new Kconfig names.
- Fix some changes which were in the wrong patch.
- Rebase on top of kselftest/kunit (currently identical to 5.7-rc1)

Changes from v4:
- KASAN no longer will panic on errors if both panic_on_warn and
kasan_multishot are enabled.
- As a result, the KASAN tests will no-longer disable panic_on_warn.
- This also means panic_on_warn no-longer needs to be exported.
- The use of temporary "kasan_data" variables has been cleaned up
somewhat.
- A potential refcount/resource leak should multiple KASAN errors
appear during an assertion was fixed.
- Some wording changes to the KASAN test Kconfig entries.

Changes from v3:
- KUNIT_SET_KASAN_DATA and KUNIT_DO_EXPECT_KASAN_FAIL have been
combined and included in KUNIT_DO_EXPECT_KASAN_FAIL() instead.
- Reordered logic in kasan_update_kunit_status() in report.c to be
easier to read.
- Added comment to not use the name "kasan_data" for any kunit tests
outside of KUNIT_EXPECT_KASAN_FAIL().

Changes since v2:
- Due to Alan's changes in [1], KUnit can be built as a module.
- The name of the tests that could not be run with KUnit has been
changed to be more generic: test_kasan_module.
- Documentation on how to run the new KASAN tests and what to expect
when running them has been added.
- Some variables and functions are now static.
- Now save/restore panic_on_warn in a similar way to kasan_multi_shot
and renamed the init/exit functions to be more generic to accommodate.
- Due to [4] in kasan_strings, kasan_memchr, and
kasan_memcmp will fail if CONFIG_AMD_MEM_ENCRYPT is enabled so return
early and print message explaining this circumstance.
- Changed preprocessor checks to C checks where applicable.

Changes since v1:
- Make use of Alan Maguire's suggestion to use his patch that allows
static resources for integration instead of adding a new attribute to
the kunit struct
- All KUNIT_EXPECT_KASAN_FAIL statements are local to each test
- The definition of KUNIT_EXPECT_KASAN_FAIL is local to the
test_kasan.c file since it seems this is the only place this will
be used.
- Integration relies on KUnit being builtin
- copy_user_test has been separated into its own file since KUnit
is unable to test these. This can be run as a module just as before,
using CONFIG_TEST_KASAN_USER
- The addition to the current task has been separated into its own
patch as this is a significant enough change to be on its own.

[1]
https://lore.kernel.org/linux-kselftest/cafd5g46uu_5tg89uom0dj5cmq+11cwjbnsd-k_cvy6bqueu...@mail.gmail.com/T/#t
[2] https://lore.kernel.org/linux-mm/20200424145521.8203-1-...@axtens.net/
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=adb72ae1915db28f934e9e02c18bfcea2f3ed3b7
[4]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=47227d27e2fcb01a9e8f5958d8997cf47a820afc
[5] https://bugzilla.kernel.org/show_bug.cgi?id=206337

David Gow (1):
mm: kasan: Do not panic if both panic_on_warn and kasan_multishot set

Patricia Alfonso (4):
Add KUnit Struct to Current Task
KUnit: KASAN Integration
KASAN: Port KASAN Tests to KUnit
KASAN: Testing Documentation

--
2.27.0.278.ge193c7cf3a9-goog

[PATCH v2 2/2] MIPS: Add writable-applies-readable policy with pgrot

2020-06-05 Thread Bibo Mao

On Linux system, writable applies readable privilege in most
architectures, this patch adds this policy on MIPS platform
where hardware rixi is supported.

Signed-off-by: Bibo Mao 
---
 arch/mips/mm/cache.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/mm/cache.c b/arch/mips/mm/cache.c
index f814e43..dae0617 100644
--- a/arch/mips/mm/cache.c
+++ b/arch/mips/mm/cache.c
@@ -160,7 +160,7 @@ static inline void setup_protection_map(void)
if (cpu_has_rixi) {
protection_map[0]  = __pgprot(__PC | __PP | __NX | __NR);
protection_map[1]  = __pgprot(__PC | __PP | __NX | ___R);
-   protection_map[2]  = __pgprot(__PC | __PP | __NX | __NR);
+   protection_map[2]  = __pgprot(__PC | __PP | __NX | ___R);
protection_map[3]  = __pgprot(__PC | __PP | __NX | ___R);
protection_map[4]  = __pgprot(__PC | __PP | ___R);
protection_map[5]  = __pgprot(__PC | __PP | ___R);
@@ -169,7 +169,7 @@ static inline void setup_protection_map(void)
 
protection_map[8]  = __pgprot(__PC | __PP | __NX | __NR);
protection_map[9]  = __pgprot(__PC | __PP | __NX | ___R);
-   protection_map[10] = __pgprot(__PC | __PP | __NX | ___W | __NR);
+   protection_map[10] = __pgprot(__PC | __PP | __NX | ___W | ___R);
protection_map[11] = __pgprot(__PC | __PP | __NX | ___W | ___R);
protection_map[12] = __pgprot(__PC | __PP | ___R);
protection_map[13] = __pgprot(__PC | __PP | ___R);
-- 
1.8.3.1

Re: [PATCH v3 02/10] dmaengine: Actions: Add support for S700 DMA engine

Hi Amit,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on robh/for-next]
[also build test WARNING on clk/clk-next pza/reset/next linus/master v5.7 
next-20200605]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Amit-Singh-Tomar/Add-MMC-and-DMA-support-for-Actions-S700/20200603-013935
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-randconfig-r024-20200605 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
6dd738e2f0609f7d3313b574a1d471263d2d3ba1)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>, old ones prefixed by <<):

>> drivers/dma/owl-dma.c:1102:14: warning: cast to smaller integer type 'enum 
>> owl_dma_id' from 'const void *' [-Wvoid-pointer-to-enum-cast]
od->devid = (enum owl_dma_id)of_id->data;
^~~~
1 warning generated.

vim +1102 drivers/dma/owl-dma.c

  1070  
  1071  static int owl_dma_probe(struct platform_device *pdev)
  1072  {
  1073  struct device_node *np = pdev->dev.of_node;
  1074  struct owl_dma *od;
  1075  int ret, i, nr_channels, nr_requests;
  1076  const struct of_device_id *of_id =
  1077  of_match_device(owl_dma_match, 
>dev);
  1078  
  1079  od = devm_kzalloc(>dev, sizeof(*od), GFP_KERNEL);
  1080  if (!od)
  1081  return -ENOMEM;
  1082  
  1083  od->base = devm_platform_ioremap_resource(pdev, 0);
  1084  if (IS_ERR(od->base))
  1085  return PTR_ERR(od->base);
  1086  
  1087  ret = of_property_read_u32(np, "dma-channels", _channels);
  1088  if (ret) {
  1089  dev_err(>dev, "can't get dma-channels\n");
  1090  return ret;
  1091  }
  1092  
  1093  ret = of_property_read_u32(np, "dma-requests", _requests);
  1094  if (ret) {
  1095  dev_err(>dev, "can't get dma-requests\n");
  1096  return ret;
  1097  }
  1098  
  1099  dev_info(>dev, "dma-channels %d, dma-requests %d\n",
  1100   nr_channels, nr_requests);
  1101  
> 1102  od->devid = (enum owl_dma_id)of_id->data;
  1103  
  1104  od->nr_pchans = nr_channels;
  1105  od->nr_vchans = nr_requests;
  1106  
  1107  pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
  1108  
  1109  platform_set_drvdata(pdev, od);
  1110  spin_lock_init(>lock);
    
  1112  dma_cap_set(DMA_MEMCPY, od->dma.cap_mask);
  1113  dma_cap_set(DMA_SLAVE, od->dma.cap_mask);
  1114  dma_cap_set(DMA_CYCLIC, od->dma.cap_mask);
  1115  
  1116  od->dma.dev = >dev;
  1117  od->dma.device_free_chan_resources = 
owl_dma_free_chan_resources;
  1118  od->dma.device_tx_status = owl_dma_tx_status;
  1119  od->dma.device_issue_pending = owl_dma_issue_pending;
  1120  od->dma.device_prep_dma_memcpy = owl_dma_prep_memcpy;
  1121  od->dma.device_prep_slave_sg = owl_dma_prep_slave_sg;
  1122  od->dma.device_prep_dma_cyclic = owl_prep_dma_cyclic;
  1123  od->dma.device_config = owl_dma_config;
  1124  od->dma.device_pause = owl_dma_pause;
  1125  od->dma.device_resume = owl_dma_resume;
  1126  od->dma.device_terminate_all = owl_dma_terminate_all;
  1127  od->dma.src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
  1128  od->dma.dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
  1129  od->dma.directions = BIT(DMA_MEM_TO_MEM);
  1130  od->dma.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
  1131  
  1132  INIT_LIST_HEAD(>dma.channels);
  1133  
  1134  od->clk = devm_clk_get(>dev, NULL);
  1135  if (IS_ERR(od->clk)) {
  1136  dev_err(>dev, "unable to get clock\n");
  1137  return PTR_ERR(od->clk);
  1138  }
  1139  
  1140  /*
  1141

Re: [kbuild-all] Re: [PATCH 1/3] dma-direct: provide the ability to reserve per-numa CMA

2020-06-05 Thread Philip Li

On Fri, Jun 05, 2020 at 11:57:51AM +0300, Dan Carpenter wrote:
> On Fri, Jun 05, 2020 at 06:04:31AM +, Song Bao Hua (Barry Song) wrote:
> > 
> > 
> > > -Original Message-
> > > From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> > > Sent: Thursday, June 4, 2020 11:37 PM
> > > To: kbu...@lists.01.org; Song Bao Hua (Barry Song)
> > > ; h...@lst.de; m.szyprow...@samsung.com;
> > > robin.mur...@arm.com; catalin.mari...@arm.com
> > > Cc: l...@intel.com; Dan Carpenter ;
> > > kbuild-...@lists.01.org; io...@lists.linux-foundation.org;
> > > linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; 
> > > Linuxarm
> > > ; Jonathan Cameron
> > > ; John Garry 
> > > Subject: Re: [PATCH 1/3] dma-direct: provide the ability to reserve 
> > > per-numa
> > > CMA
> > > 
> > > Hi Barry,
> > > 
> > > url:
> > > https://github.com/0day-ci/linux/commits/Barry-Song/support-per-numa-CM
> > > A-for-ARM-server/20200603-104821
> > > base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
> > > for-next/core
> > > config: x86_64-randconfig-m001-20200603 (attached as .config)
> > > compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
> > > 
> > > If you fix the issue, kindly add following tag as appropriate
> > > Reported-by: kernel test robot 
> > > Reported-by: Dan Carpenter 
> > 
> > Dan, thanks! Good catch!
> > as this patch has not been in mainline yet, is it correct to add these 
> > "reported-by" in patch v2?
Hi Barry, we provides the suggestion here, but you may decide
to add or not as appropriate for your situation. For the
patch still under development, it is not that necessary to add i think.

> 
> These are just an automated email from the zero day bot.  I look over
> the Smatch warnings and then forward them on.
> 
> regards,
> dan carpenter
> ___
> kbuild-all mailing list -- kbuild-...@lists.01.org
> To unsubscribe send an email to kbuild-all-le...@lists.01.org

Re: [PATCH v6 1/8] fs: introduce kernel_pread_file* support

2020-06-05 Thread Matthew Wilcox

On Fri, Jun 05, 2020 at 03:59:52PM -0700, Scott Branden wrote:
> -int kernel_read_file(struct file *file, void **buf, loff_t *size,
> -  loff_t max_size, enum kernel_read_file_id id)
> -{
> - loff_t i_size, pos;
> +int kernel_pread_file(struct file *file, void **buf, loff_t *size,
> +   loff_t pos, loff_t max_size,
> +   enum kernel_pread_opt opt,
> +   enum kernel_read_file_id id)

What is this 'kernel_pread_opt' foolishness?  Why not just pass in
~0UL as max_size if you want the entire file?

> -int kernel_read_file_from_path_initns(const char *path, void **buf,
> -   loff_t *size, loff_t max_size,
> -   enum kernel_read_file_id id)
> +extern int kernel_pread_file_from_path_initns(const char *path, void **buf,

extern?  really?  i'm shocked gcc doesn't vomit on that.

Re: [PATCH v5 1/3] open: add close_range()

2020-06-05 Thread Kyle Evans

On Fri, Jun 5, 2020 at 9:54 PM Kyle Evans  wrote:
>
> On Fri, Jun 5, 2020 at 9:55 AM Szabolcs Nagy  wrote:
> >
> > * Christian Brauner  [2020-06-02 22:42:17 
> > +0200]:
> > > [... snip ...]
> > >
> > > First, it helps to close all file descriptors of an exec()ing task. This
> > > can be done safely via (quoting Al's example from [1] verbatim):
> > >
> > > /* that exec is sensitive */
> > > unshare(CLONE_FILES);
> > > /* we don't want anything past stderr here */
> > > close_range(3, ~0U);
> > > execve();
> >
> > this api needs a documentation patch if there isn't yet.
> >
> > currently there is no libc interface contract in place that
> > says which calls may use libc internal fds e.g. i've seen
> >
> >   openlog(...) // opens libc internal syslog fd
> >   ...
> >   fork()
> >   closefrom(...) // close syslog fd
> >   open(...) // something that reuses the closed fd
> >   syslog(...) // unsafe: uses the wrong fd
> >   execve(...)
> >
> > syslog uses a libc internal fd that the user trampled on and
> > this can go bad in many ways depending on what libc apis are
> > used between closefrom (or equivalent) and exec.
> >
>
> Documentation is good. :-) I think you'll find that while this example
> seems to be innocuous on FreeBSD (and likely other *BSD), this is an
> atypical scenario and generally not advised.  You would usually not
> start closing until you're actually ready to exec/fail.
>

Minor correction: not innocuous here, either; O_CLOFORK is not yet a thing. :-)

Re: [PATCH] x86/cpu: Reinitialize IA32_FEAT_CTL MSR on BSP during wakeup

Hi Sean,

I love your patch! Yet something to improve:

[auto build test ERROR on tip/x86/core]
[also build test ERROR on tip/auto-latest v5.7 next-20200605]
[cannot apply to bp/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Sean-Christopherson/x86-cpu-Reinitialize-IA32_FEAT_CTL-MSR-on-BSP-during-wakeup/20200606-040921
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
9cb1fd0efd195590b828b9b865421ad345a4a145
config: x86_64-allyesconfig (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
6dd738e2f0609f7d3313b574a1d471263d2d3ba1)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>, old ones prefixed by <<):

>> arch/x86/kernel/cpu/centaur.c:219:2: error: implicit declaration of function 
>> 'init_ia32_feat_ctl' [-Werror,-Wimplicit-function-declaration]
init_ia32_feat_ctl(c);
^
1 error generated.
--
>> arch/x86/kernel/cpu/zhaoxin.c:110:2: error: implicit declaration of function 
>> 'init_ia32_feat_ctl' [-Werror,-Wimplicit-function-declaration]
init_ia32_feat_ctl(c);
^
1 error generated.

vim +/init_ia32_feat_ctl +219 arch/x86/kernel/cpu/centaur.c

60882cc159e141 arch/x86/kernel/cpu/centaur.c  David Wang  2018-04-20  
218  
501444905fcb41 arch/x86/kernel/cpu/centaur.c  Sean Christopherson 2019-12-20 
@219   init_ia32_feat_ctl(c);
^1da177e4c3f41 arch/i386/kernel/cpu/centaur.c Linus Torvalds  2005-04-16  
220  }
^1da177e4c3f41 arch/i386/kernel/cpu/centaur.c Linus Torvalds  2005-04-16  
221  

:: The code at line 219 was first introduced by commit
:: 501444905fcb4166589fda99497c273ac5efc65e x86/centaur: Use common 
IA32_FEAT_CTL MSR initialization

:: TO: Sean Christopherson 
:: CC: Borislav Petkov 

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [net] a6211caa63: dmesg.UBSAN:signed-integer-overflow_in_arch/x86/include/asm/atomic.h

2020-06-05 Thread Chen, Rong A





On 6/5/2020 10:05 PM, Peter Zijlstra wrote:

On Fri, Jun 05, 2020 at 06:17:51AM -0700, Eric Dumazet wrote:

On Fri, Jun 5, 2020 at 1:10 AM kernel test robot  wrote:
There you go.

We decided this was a bogus report, and that UBSAN requires sane compilers.

Please read the fine comment that was added in this commit and update
your compiler or do not mess with compiler flags.

+   /* If UBSAN reports an error there, please make sure your compiler
+* supports -fno-strict-overflow before reporting it that was a bug
+* in UBSAN, and it has been fixed in GCC-8.
+*/
+   return atomic_add_return(segs + delta, p_id) - segs;

 make HOSTCC=gcc-4.9 CC=gcc-4.9 ARCH=i386 olddefconfig prepare 
modules_prepare bzImage

Rong, can you make sure to exclude gcc<8 for UBSAN reports ?


Got it, thank's for your warning.

Best Regards,
Rong Chen

Re: [PATCH] x86/split_lock: Sanitize userspace and guest error output

2020-06-05 Thread Xiaoyao Li


On 6/6/2020 12:42 AM, Prarit Bhargava wrote:



On 6/5/20 11:29 AM, Xiaoyao Li wrote:

On 6/5/2020 7:44 PM, Prarit Bhargava wrote:

There are two problems with kernel messages in fatal mode that
were found during testing of guests and userspace programs.

The first is that no kernel message is output when the split lock detector
is triggered with a userspace program.  As a result the userspace process
dies from receiving SIGBUS with no indication to the user of what caused
the process to die.

The second problem is that only the first triggering guest causes a kernel
message to be output because the message is output with pr_warn_once().
This also results in a loss of information to the user.

While fixing these I noticed that the same message was being output
three times so I'm cleaning that up too.

Fix fatal mode output, and use consistent messages for fatal and
warn modes for both userspace and guests.

Signed-off-by: Prarit Bhargava 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: x...@kernel.org
Cc: "H. Peter Anvin" 
Cc: Tony Luck 
Cc: "Peter Zijlstra (Intel)" 
Cc: Sean Christopherson 
Cc: Rahul Tanwar 
Cc: Xiaoyao Li 
Cc: Ricardo Neri 
Cc: Dave Hansen 
---
   arch/x86/kernel/cpu/intel.c | 24 ++--
   1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 166d7c355896..463022aa9b7a 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -1074,10 +1074,14 @@ static void split_lock_init(void)
   split_lock_verify_msr(sld_state != sld_off);
   }
   -static void split_lock_warn(unsigned long ip)
+static bool split_lock_warn(unsigned long ip, int fatal)
   {
-    pr_warn_ratelimited("#AC: %s/%d took a split_lock trap at address: 
0x%lx\n",
-    current->comm, current->pid, ip);
+    pr_warn_ratelimited("#AC: %s/%d %ssplit_lock trap at address: 0x%lx\n",
+    current->comm, current->pid,
+    sld_state == sld_fatal ? "fatal " : "", ip);
+
+    if (sld_state == sld_fatal || fatal)
+    return false;
     /*
    * Disable the split lock detection for this task so it can make
@@ -1086,18 +1090,13 @@ static void split_lock_warn(unsigned long ip)
    */
   sld_update_msr(false);
   set_tsk_thread_flag(current, TIF_SLD);
+    return true;
   }
     bool handle_guest_split_lock(unsigned long ip)
   {
-    if (sld_state == sld_warn) {
-    split_lock_warn(ip);
+    if (split_lock_warn(ip, 0))
   return true;
-    }
-
-    pr_warn_once("#AC: %s/%d %s split_lock trap at address: 0x%lx\n",
- current->comm, current->pid,
- sld_state == sld_fatal ? "fatal" : "bogus", ip);
     current->thread.error_code = 0;
   current->thread.trap_nr = X86_TRAP_AC;
@@ -1108,10 +1107,7 @@ EXPORT_SYMBOL_GPL(handle_guest_split_lock);
     bool handle_user_split_lock(struct pt_regs *regs, long error_code)
   {
-    if ((regs->flags & X86_EFLAGS_AC) || sld_state == sld_fatal)
-    return false;
-    split_lock_warn(regs->ip);
-    return true;
+    return split_lock_warn(regs->ip, regs->flags & X86_EFLAGS_AC);


It's incorrect. You change the behavior that it will print the split lock
warning even when CPL 3 Alignment Check is turned on.


Do you want the message to be displayed in the fatal case of CPL 3 Alignment 
check?



No. It should never be displayed if #AC happens in CPL 3 and 
X86_EFLAGS_AC is set. In this case, an unaligned access triggers #AC 
regardless of #LOCK prefix. What's more, even there is a #LOCK prefix, 
we still cannot tell the cause because we don't know the priority of 
legacy alignment check #AC and split lock #AC.


If you do want a message, we can only say "unaligned access at address xxx".

Re: [PATCH v5 1/3] open: add close_range()

2020-06-05 Thread Kyle Evans

On Fri, Jun 5, 2020 at 9:55 AM Szabolcs Nagy  wrote:
>
> * Christian Brauner  [2020-06-02 22:42:17 
> +0200]:
> > [... snip ...]
> >
> > First, it helps to close all file descriptors of an exec()ing task. This
> > can be done safely via (quoting Al's example from [1] verbatim):
> >
> > /* that exec is sensitive */
> > unshare(CLONE_FILES);
> > /* we don't want anything past stderr here */
> > close_range(3, ~0U);
> > execve();
>
> this api needs a documentation patch if there isn't yet.
>
> currently there is no libc interface contract in place that
> says which calls may use libc internal fds e.g. i've seen
>
>   openlog(...) // opens libc internal syslog fd
>   ...
>   fork()
>   closefrom(...) // close syslog fd
>   open(...) // something that reuses the closed fd
>   syslog(...) // unsafe: uses the wrong fd
>   execve(...)
>
> syslog uses a libc internal fd that the user trampled on and
> this can go bad in many ways depending on what libc apis are
> used between closefrom (or equivalent) and exec.
>

Documentation is good. :-) I think you'll find that while this example
seems to be innocuous on FreeBSD (and likely other *BSD), this is an
atypical scenario and generally not advised.  You would usually not
start closing until you're actually ready to exec/fail.

> > The code snippet above is one way of working around the problem that file
> > descriptors are not cloexec by default. This is aggravated by the fact that
> > we can't just switch them over without massively regressing userspace. For
>
> why is a switch_to_cloexec_range worse than close_range?
> the former seems safer to me. (and allows libc calls
> to be made between such switch and exec: libc internal
> fds have to be cloexec anyway)
>

I wouldn't say it's worse, but it only solves half the problem. While
closefrom -> exec is the most common usage by a long shot, there are
also times (e.g. post-fork without intent to exec for a daemon/service
type) that you want to go ahead and close everything except maybe a
pipe fd that you've opened for IPC. While uncommon, there's no reason
this needs to devolve into a loop to close 'all the fds' when you can
instead introduce close_range to solve both the exec case and other
less common scenarios.

> > a whole class of programs having an in-kernel method of closing all file
> > descriptors is very helpful (e.g. demons, service managers, programming
> > language standard libraries, container managers etc.).
> > (Please note, unshare(CLONE_FILES) should only be needed if the calling
> > task is multi-threaded and shares the file descriptor table with another
> > thread in which case two threads could race with one thread allocating file
> > descriptors and the other one closing them via close_range(). For the
> > general case close_range() before the execve() is sufficient.)
> >
> > Second, it allows userspace to avoid implementing closing all file
> > descriptors by parsing through /proc//fd/* and calling close() on each
> > file descriptor. From looking at various large(ish) userspace code bases
> > this or similar patterns are very common in:
> > - service managers (cf. [4])
> > - libcs (cf. [6])
> > - container runtimes (cf. [5])
> > - programming language runtimes/standard libraries
> >   - Python (cf. [2])
> >   - Rust (cf. [7], [8])
> > As Dmitry pointed out there's even a long-standing glibc bug about missing
> > kernel support for this task (cf. [3]).
> > In addition, the syscall will also work for tasks that do not have procfs
> > mounted and on kernels that do not have procfs support compiled in. In such
> > situations the only way to make sure that all file descriptors are closed
> > is to call close() on each file descriptor up to UINT_MAX or RLIMIT_NOFILE,
> > OPEN_MAX trickery (cf. comment [8] on Rust).
>
> close_range still seems like a bad operation to expose.
>
> if users really want closing behaviour (instead of marking
> fds cloexec) then they likely need coordination with libc
> and other libraries.
>
> e.g. this usage does not work:
>
>   maxfd = findmaxfd();
>   call_that_may_leak_fds();
>   close_range(maxfd,~0U);
>
> as far as i can tell only the close right before exec works.

I don't have much to say on this one, except that's also an unusual
case. I don't know that I'd anticipate close_range getting used for
that kind of cleanup job (I've never seen a similar use of closefrom),
which seems to just be papering over application/library bugs.

Coordination with libc is generally not much of an issue, because this
is really one of the last things you do before exec() or swiftly
failing miserably. Applications that currently loop over all fd <=
maxfd and close(fd) right now are subject to the very same
constraints, this is just a much more efficient way and
debugger-friendly way to accomplish it. You've absolutely not lived
life until you've had to watch thousands of close() calls painfully
scroll by in truss/strace.

Thank,

Kyle Evans

Re: [PATCH v8 09/16] s390/vfio_ap: add qlink from ap_matrix_mdev struct to vfio_ap_queue struct

Hi Tony,

I love your patch! Perhaps something to improve:

[auto build test WARNING on kvms390/next]
[also build test WARNING on linus/master v5.7]
[cannot apply to s390/features linux/master next-20200605]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Tony-Krowiak/s390-vfio-ap-dynamic-configuration-support/20200606-054350
base:   https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git next
config: s390-allyesconfig (attached as .config)
compiler: s390-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=s390 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>, old ones prefixed by <<):

>> drivers/s390/crypto/vfio_ap_ops.c:53:23: warning: no previous prototype for 
>> 'vfio_ap_get_mdev_queue' [-Wmissing-prototypes]
53 | struct vfio_ap_queue *vfio_ap_get_mdev_queue(struct ap_matrix_mdev 
*matrix_mdev,
|   ^~
drivers/s390/crypto/vfio_ap_ops.c:143:24: warning: no previous prototype for 
'vfio_ap_irq_disable' [-Wmissing-prototypes]
143 | struct ap_queue_status vfio_ap_irq_disable(struct vfio_ap_queue *q)
|^~~
drivers/s390/crypto/vfio_ap_ops.c:1453:5: warning: no previous prototype for 
'vfio_ap_mdev_reset_queue' [-Wmissing-prototypes]
1453 | int vfio_ap_mdev_reset_queue(unsigned int apid, unsigned int apqi,
| ^~~~

vim +/vfio_ap_get_mdev_queue +53 drivers/s390/crypto/vfio_ap_ops.c

52  
  > 53  struct vfio_ap_queue *vfio_ap_get_mdev_queue(struct ap_matrix_mdev 
*matrix_mdev,
54   unsigned long apqn)
55  {
56  struct vfio_ap_queue *q;
57  
58  hash_for_each_possible(matrix_mdev->qtable, q, mdev_qnode, 
apqn) {
59  if (q && (q->apqn == apqn))
60  return q;
61  }
62  
63  return NULL;
64  }
65  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [PATCH] x86/split_lock: Don't write MSR_TEST_CTRL on CPUs that aren't whitelisted

2020-06-05 Thread Xiaoyao Li


On 6/6/2020 3:26 AM, Sean Christopherson wrote:

Choo! Choo!  All aboard the Split Lock Express, with direct service to
Wreckage!

Skip split_lock_verify_msr() if the CPU isn't whitelisted as a possible
SLD-enabled CPU model to avoid writing MSR_TEST_CTRL.  MSR_TEST_CTRL
exists, and is writable, on many generations of CPUs.  Writing the MSR,
even with '0', can result in bizarre, undocumented behavior.

This fixes a crash on Haswell when resuming from suspend with a live KVM
guest.  Because APs use the standard SMP boot flow for resume, they will
go through split_lock_init() and the subsequent RDMSR/WRMSR sequence,
which runs even when sld_state==sld_off to ensure SLD is disabled.  On
Haswell (at least, my Haswell), writing MSR_TEST_CTRL with '0' will
succeed and _may_ take the SMT _sibling_ out of VMX root mode.

When KVM has an active guest, KVM performs VMXON as part of CPU onlining
(see kvm_starting_cpu()).  Because SMP boot is serialized, the resulting
flow is effectively:

   on_each_ap_cpu() {
  WRMSR(MSR_TEST_CTRL, 0)
  VMXON
   }

As a result, the WRMSR can disable VMX on a different CPU that has
already done VMXON.  This ultimately results in a #UD on VMPTRLD when
KVM regains control and attempt run its vCPUs.

The above voodoo was confirmed by reworking KVM's VMXON flow to write
MSR_TEST_CTRL prior to VMXON, and to serialize the sequence as above.
Further verification of the insanity was done by redoing VMXON on all
APs after the initial WRMSR->VMXON sequence.  The additional VMXON,
which should VM-Fail, occasionally succeeded, and also eliminated the
unexpected #UD on VMPTRLD.

The damage done by writing MSR_TEST_CTRL doesn't appear to be limited
to VMX, e.g. after suspend with an active KVM guest, subsequent reboots
almost always hang (even when fudging VMXON), a #UD on a random Jcc was
observed, suspend/resume stability is qualitatively poor, and so on and
so forth.



I'm wondering if all those side-effects of MSR_TEST_CTRL exist on CPUs 
have SLD feature, have you ever tested on a SLD capable CPU?

Re: [PATCH v6 2/8] firmware: add offset to request_firmware_into_buf

Hi Scott,

I love your patch! Yet something to improve:

[auto build test ERROR on next-20200605]
[cannot apply to char-misc/char-misc-testing driver-core/driver-core-testing 
kselftest/next integrity/next-integrity linus/master v5.7 v5.7-rc7 v5.7-rc6 
v5.7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Scott-Branden/firmware-add-partial-read-support-in-request_firmware_into_buf/20200606-070430
base:af30725c132e2e5c5369b60369ff0771fde7d4ff
config: nios2-allyesconfig (attached as .config)
compiler: nios2-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=nios2 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>, old ones prefixed by <<):

drivers/i2c/i2c-slave-eeprom.c: In function 'i2c_slave_init_eeprom_data':
>> drivers/i2c/i2c-slave-eeprom.c:131:9: error: too few arguments to function 
>> 'request_firmware_into_buf'
131 |   ret = request_firmware_into_buf(, eeprom_data, >dev,
| ^
In file included from drivers/i2c/i2c-slave-eeprom.c:20:
include/linux/firmware.h:55:5: note: declared here
55 | int request_firmware_into_buf(const struct firmware **firmware_p,
| ^

vim +/request_firmware_into_buf +131 drivers/i2c/i2c-slave-eeprom.c

389be323cfac38 Wolfram Sang 2014-11-18  122  
e804f0a78e9e43 Björn Ardö   2020-04-24  123  static int 
i2c_slave_init_eeprom_data(struct eeprom_data *eeprom, struct i2c_client 
*client,
e804f0a78e9e43 Björn Ardö   2020-04-24  124   
unsigned int size)
e804f0a78e9e43 Björn Ardö   2020-04-24  125  {
e804f0a78e9e43 Björn Ardö   2020-04-24  126 const struct firmware *fw;
e804f0a78e9e43 Björn Ardö   2020-04-24  127 const char *eeprom_data;
e804f0a78e9e43 Björn Ardö   2020-04-24  128 int ret = 
device_property_read_string(>dev, "firmware-name", _data);
e804f0a78e9e43 Björn Ardö   2020-04-24  129  
e804f0a78e9e43 Björn Ardö   2020-04-24  130 if (!ret) {
e804f0a78e9e43 Björn Ardö   2020-04-24 @131 ret = 
request_firmware_into_buf(, eeprom_data, >dev,
e804f0a78e9e43 Björn Ardö   2020-04-24  132 
eeprom->buffer, size);
e804f0a78e9e43 Björn Ardö   2020-04-24  133 if (ret)
e804f0a78e9e43 Björn Ardö   2020-04-24  134 return ret;
e804f0a78e9e43 Björn Ardö   2020-04-24  135 release_firmware(fw);
e804f0a78e9e43 Björn Ardö   2020-04-24  136 } else {
e804f0a78e9e43 Björn Ardö   2020-04-24  137 /* An empty eeprom 
typically has all bits set to 1 */
e804f0a78e9e43 Björn Ardö   2020-04-24  138 memset(eeprom->buffer, 
0xff, size);
e804f0a78e9e43 Björn Ardö   2020-04-24  139 }
e804f0a78e9e43 Björn Ardö   2020-04-24  140 return 0;
e804f0a78e9e43 Björn Ardö   2020-04-24  141  }
e804f0a78e9e43 Björn Ardö   2020-04-24  142  

:: The code at line 131 was first introduced by commit
:: e804f0a78e9e43f0105e1bc3e264894b3898e970 i2c: slave-eeprom: Make it 
possible to pre-load eeprom data

:: TO: Björn Ardö 
:: CC: Wolfram Sang 

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

[rcu:dev.2020.06.02a] BUILD REGRESSION 5216948905dd07a84cef8a7dc72c2ec076802efd

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git  
dev.2020.06.02a
branch HEAD: 5216948905dd07a84cef8a7dc72c2ec076802efd  torture: Create qemu-cmd 
in --buildonly runs

Error/Warning in current branch:

(.text+0x80c): undefined reference to `__aeabi_uldivmod'
arm-linux-gnueabi-ld: (.text+0x860): undefined reference to `__aeabi_uldivmod'
kernel/smp.c:122: undefined reference to `__udivdi3'
ld: kernel/smp.c:128: undefined reference to `__udivdi3'
ld: kernel/smp.c:136: undefined reference to `__umoddi3'
ld: smp.c:(.text+0x5a3): undefined reference to `__udivdi3'
ld: smp.c:(.text+0x648): undefined reference to `__umoddi3'
smp.c:(.text+0x55a): undefined reference to `__udivdi3'

Error/Warning ids grouped by kconfigs:

recent_errors
|-- arm-allyesconfig
|   |-- (.text):undefined-reference-to-__aeabi_uldivmod
|   `-- arm-linux-gnueabi-ld:(.text):undefined-reference-to-__aeabi_uldivmod
|-- i386-allmodconfig
|   |-- ld:smp.c:(.text):undefined-reference-to-__udivdi3
|   |-- ld:smp.c:(.text):undefined-reference-to-__umoddi3
|   `-- smp.c:(.text):undefined-reference-to-__udivdi3
|-- i386-allyesconfig
|   |-- ld:smp.c:(.text):undefined-reference-to-__udivdi3
|   |-- ld:smp.c:(.text):undefined-reference-to-__umoddi3
|   `-- smp.c:(.text):undefined-reference-to-__udivdi3
`-- i386-randconfig-c001-20200605
|-- kernel-smp.c:undefined-reference-to-__udivdi3
|-- ld:kernel-smp.c:undefined-reference-to-__udivdi3
`-- ld:kernel-smp.c:undefined-reference-to-__umoddi3


i386-tinyconfig vmlinux size:


 TOTAL  TEXT  arch/x86/events/zhaoxin/built-in.*


-1 0  b3e2d20973db rcuperf: Fix 
printk format warning   
  -233  -233+136  6f1a383dd3b1 Merge branch 
'kcsan-dev.2020.04.13c' into HEAD   
 0 0   0  191a685f4f2f Merge branch 
'lkmm-dev.2020.05.16a' into HEAD
 0 0   0  78df41a9c13a torture:  Remove 
qemu dependency on EFI firmware 
 0 0   0  571b05c483d2 torture: Add 
script to smoke-test commits in a branch
   +38   +38   0  e88deb89ed6a fork: Annotate a 
data race in vm_area_dup()  
 0 0   0  e534895edc55 x86/mm/pat: Mark 
an intentional data race
 0 0   0  bce3f442b911 rculist: Add 
ASSERT_EXCLUSIVE_ACCESS() to __list_splice_init 
 0 0   0  afa06b508109 locktorture: Use 
true and false to assign to bool variables  
 0 0   0  1318fb21873e srcu: Fix a typo 
in comment "amoritized"->"amortized"
 0 0   0  c4c78437db28 rcu: Simplify 
the calculation of rcu_state.ncpus 
 0 0   0  97e3dab5cebc docs: RCU: 
Convert checklist.txt to ReST 
 0 0   0  890bb7fe302c docs: RCU: 
Convert lockdep-splat.txt to ReST 
 0 0   0  8c8b194c3a41 docs: RCU: 
Convert lockdep.txt to ReST   
 0 0   0  c999e5cd7aa7 docs: RCU: 
Convert rculist_nulls.txt to ReST 
 0 0   0  09f2ded72f2e docs: RCU: 
Convert torture.txt to ReST   
 0 0   0  e68e913d34a2 docs: RCU: 
Convert rcuref.txt to ReST
 0 0   0  91080f1874d1 docs: RCU: 
Convert stallwarn.txt to ReST 
 0 0   0  c89ecb29b2d8 docs: RCU: Don't 
duplicate chapter names in rculist_nulls.rs 
 0 0   0  ddca16397b69 rcutorture: Add 
races with task-exit processing  
 0 0   0  59c16d050ff8 torture: Set 
configfile variable to current scenario 
 0 0   0  54351dd51082 rcutorture: 
Handle non-statistic bang-string error messages  
 0 0   0  5a510624b945 rcutorture: NULL 
rcu_torture_current earlier in cleanup code 
 0 0   0  eaf2dde8be47 kcsan: Add test 
suite
 0 0

Re: [PATCH] checkpatch: Add test for possible misuse of IS_ENABLED() without CONFIG_

2020-06-05 Thread Joe Perches

On Fri, 2020-06-05 at 17:32 -0700, Andrew Morton wrote:
> On Fri, 05 Jun 2020 11:24:43 -0700 Joe Perches  wrote:
> 
> > IS_ENABLED is almost always used with CONFIG_ defines.
> > 
> > Add a test to verify that the #define being tested starts with CONFIG_.
> 
> Yay.
> 
> I wonder if there's a simple way of testing whether the CONFIG_ thing
> can *ever* be enabled.  So detect if someone does
> 
>   if (IS_ENABLED(CONFIG_BLOCKK))

No, not really. There's no simple way to do that.
It's doable, but it's not at all simple.

I think it would require something similar to the
checkpatch seed_camelcase_includes function to look
for all current config symbols and verify whatever
CONFIG_ against that list.

$ git grep -P -oh "^\s*config\s+\w+" -- '*/Kconfig*' | \
  sed -r -e 's/^\s+//' -e 's/\s+/ /g' | \
  sort | uniq -cym

Right now that takes ~1.5 seconds with my laptop
against an uncached git tree, and ~0.25 seconds cached.

Without a git tree it takes 20+ seconds.

Anyway, maybe this.

It only does the time consuming lookup when
it finds a IS_ENABLED line.

---
 scripts/checkpatch.pl | 101 ++
 1 file changed, 101 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 5f00df2c3f59..aabb01cf1e6c 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -47,6 +47,7 @@ my $gitroot = $ENV{'GIT_DIR'};
 $gitroot = ".git" if !defined($gitroot);
 my %debug;
 my %camelcase = ();
+my %Kconfig_syms = ();
 my %use_type = ();
 my @use = ();
 my %ignore_type = ();
@@ -911,6 +912,90 @@ sub is_SPDX_License_valid {
return 1;
 }
 
+sub seed_Kconfig_file {
+   my ($file) = @_;
+
+   return if (!(-f $file));
+
+   local $/;
+
+   open(my $Kconfig_file, '<', "$file")
+   or warn "$P: Can't read '$file' $!\n";
+   my $text = <$Kconfig_file>;
+   close($Kconfig_file);
+
+   my @lines = split('\n', $text);
+
+   foreach my $line (@lines) {
+   next if ($line !~ /^\s*config\s+(\w+)/);
+   $Kconfig_syms{$1} = 1;
+   }
+}
+
+my $Kconfig_symbols_seeded = 0;
+sub seed_Kconfig_symbols {
+   return if ($Kconfig_symbols_seeded);
+
+   my $files;
+   my @Kconfig_files = ();
+   my $Kconfig_syms_cache = "";
+
+   $Kconfig_symbols_seeded = 1;
+
+   if (-e "$gitroot") {
+   my $git_last_include_commit = `${git_command} log --no-merges 
--pretty=format:"%h%n" -1 -- include`;
+   chomp $git_last_include_commit;
+   $Kconfig_syms_cache = 
".checkpatch-Kconfig_syms.git.$git_last_include_commit";
+   } else {
+   my $last_mod_date = 0;
+   $files = `find $root/ -name "Kconfig*"`;
+   @Kconfig_files = split('\n', $files);
+   foreach my $file (@Kconfig_files) {
+   my $date = POSIX::strftime("%Y%m%d%H%M",
+  localtime((stat $file)[9]));
+   $last_mod_date = $date if ($last_mod_date < $date);
+   }
+   $Kconfig_syms_cache = 
".checkpatch-Kconfig_syms.date.$last_mod_date";
+   }
+
+   if ($Kconfig_syms_cache ne "" && -f $Kconfig_syms_cache) {
+   open(my $Kconfig_syms_file, '<', "$Kconfig_syms_cache")
+   or warn "$P: Can't read '$Kconfig_syms_cache' $!\n";
+   while (<$Kconfig_syms_file>) {
+   chomp;
+   $Kconfig_syms{$_} = 1;
+   }
+   close($Kconfig_syms_file);
+
+   return;
+   }
+
+   if (-e "$gitroot") {
+   my @syms = `${git_command} grep -P -oh '^\\s*config\\s+\\w+' -- 
'*/Kconfig*'`;
+   s/^\s+// for @syms;
+   s/config\s+// for @syms;
+   s/\n$// for @syms;
+   @syms = sort(uniq(@syms));
+   foreach my $sym (@syms) {
+   $Kconfig_syms{$sym} = 1;
+   }
+   } else {
+   foreach my $file (@Kconfig_files) {
+   seed_Kconfig_file($file);
+   }
+   }
+
+   if ($Kconfig_syms_cache ne "") {
+   unlink glob ".checkpatch-Kconfig_syms.*";
+   open(my $Kconfig_syms_file, '>', "$Kconfig_syms_cache")
+   or warn "$P: Can't write '$Kconfig_syms_cache' $!\n";
+   foreach (sort { lc($a) cmp lc($b) } keys(%Kconfig_syms)) {
+   print $Kconfig_syms_file ("$_\n");
+   }
+   close($Kconfig_syms_file);
+   }
+}
+
 my $camelcase_seeded = 0;
 sub seed_camelcase_includes {
return if ($camelcase_seeded);
@@ -6480,6 +6565,22 @@ sub process {
}
}
 
+# check for IS_ENABLED() used without CONFIG_ ($rawline for comment use)
+# or if the CONFIG_ symbol is not a known Kconfig entry
+   if ($rawline =~ /\bIS_ENABLED\s*\(\s*(\w+)\s*\)/) {
+

Re: [PATCH 18/27] afs: Detect cell aliases 1 - Cells with root volumes

2020-06-05 Thread Kees Cook

On Fri, May 29, 2020 at 11:02:15PM +0100, David Howells wrote:
> +static struct afs_volume *afs_sample_volume(struct afs_cell *cell, struct 
> key *key,
> + const char *name, unsigned int 
> namelen)
> +{
> + struct afs_volume *volume;
> + struct afs_fs_context fc = {
> + .type   = 0, /* Explicitly leave it to the VLDB */
> + .volnamesz  = namelen,
> + .volname= name,
> + .net= cell->net,
> + .cell   = cell,
> + .key= key, /* This might need to be something */
> + };
> +
> + volume = afs_create_volume();
> + _leave(" = %px", volume);
> + return volume;
> +}

This really doesn't seem like a justified[1] place for %px. (Even if
_leavel() is debug-only, all the rest of _leave() uses are %p.)

> + default:
> + BUG();

And nothing should add BUG() to new code[2].

-Kees

[1] 
https://www.kernel.org/doc/html/latest/process/deprecated.html#p-format-specifier
[2] 
https://www.kernel.org/doc/html/latest/process/deprecated.html#bug-and-bug-on

-- 
Kees Cook

Re: [RFC PATCH] gpio: uapi: v2 proposal

2020-06-05 Thread Kent Gibson

On Fri, Jun 05, 2020 at 11:53:05AM +0200, Bartosz Golaszewski wrote:
> czw., 4 cze 2020 o 18:00 Kent Gibson  napisał(a):
> >
> 
> [snip!]
> 
> > > > +
> > > > +enum gpioline_edge {
> > > > +   GPIOLINE_EDGE_NONE  = 0,
> > > > +   GPIOLINE_EDGE_RISING= 1,
> > > > +   GPIOLINE_EDGE_FALLING   = 2,
> > > > +   GPIOLINE_EDGE_BOTH  = 3,
> > > > +};
> > >
> > > I would skip the names of the enum types if we're not reusing them 
> > > anywhere.
> > >
> >
> > I thought it was useful to name them even if it was just to be able to
> > reference them in the documentation for relevant fields, such as that in
> > struct gpioline_config below, rather than having to either list all
> > possible values or a GPIOLINE_EDGE_* glob.
> >
> > And I'm currently using enum gpioline_edge in my edge detector
> > implementation - is that sufficient?
> >
> 
> The documentation argument is more convincing. :)
> 

I know - but your criteria was reuse... ;-).

> > > > +
> > > > +/* Line flags - V2 */
> > > > +#define GPIOLINE_FLAG_V2_KERNEL(1UL << 0) /* Line used 
> > > > by the kernel */
> > >
> > > In v1 this flag is also set if the line is used by user-space. Maybe a
> > > simple GPIOLINE_FLAG_V2_USED would be better?
> > >
> >
> > Agreed - the _KERNEL name is confusing.
> > In my latest draft I've already renamed it GPIOLINE_FLAG_V2_BUSY,
> > as EBUSY is what the ioctl returns when you try to request such a line.
> > Does that work for you?
> > I was also considering _IN_USE, and was using _UNAVAILABLE for a while.
> >
> 
> BUSY sounds less precise to me than USED or IN_USE of which both are
> fine (with a preference for the former).
>

OK, USED it shall be.

> [snip!]
> 
> > > > +
> > > > +/**
> > > > + * struct gpioline_values - Values of GPIO lines
> > > > + * @values: when getting the state of lines this contains the current
> > > > + * state of a line, when setting the state of lines these should 
> > > > contain
> > > > + * the desired target state
> > > > + */
> > > > +struct gpioline_values {
> > > > +   __u8 values[GPIOLINES_MAX];
> > >
> > > Same here for bitfield. And maybe reuse this structure in
> > > gpioline_config for default values?
> > >
> >
> > Can do.  What makes me reticent is the extra level of indirection
> > and the stuttering that would cause when referencing them.
> > e.g. config.default_values.values
> > So not sure the gain is worth the pain.
> >
> 
> I'd say yes - consolidation and reuse of data structures is always
> good and normally they are going to be wrapped in some kind of
> low-level user-space library anyway.
> 

Ok, and I've changed the values field name to bitmap, along with the change
to a bitmap type, so the stuttering is gone.

And, as the change to bitmap substantially reduced the size of
gpioline_config, I now embed that in the gpioline_info instead of
duplicating all the other fields.  The values field will be zeroed
when returned within info.

> > And I've renamed "default_values" to just "values" in my latest draft
> > which doesn't help with the stuttering.
> >
> 
> Why though? Aren't these always default values for output?
> 

To me "default" implies a fallback value, and that de-emphasises the
fact that the lines will be immediately set to those values as they
are switched to outputs.
These are the values the outputs will take - the "default" doesn't add
anything.

> [snip!]
> 
> > > > +
> > > > +/**
> > > > + * struct gpioline_event - The actual event being pushed to userspace
> > > > + * @timestamp: best estimate of time of event occurrence, in 
> > > > nanoseconds
> > > > + * @id: event identifier with value from enum gpioline_event_id
> > > > + * @offset: the offset of the line that triggered the event
> > > > + * @padding: reserved for future use
> > > > + */
> > > > +struct gpioline_event {
> > > > +   __u64 timestamp;
> > >
> > > I'd specify in the comment the type of clock used for the timestamp.
> > >
> >
> > Agreed - as this one will be guaranteed to be CLOCK_MONOTONIC.
> >
> > I'm also kicking around the idea of adding sequence numbers to events,
> > one per line and one per handle, so userspace can more easily detect
> > mis-ordering or buffer overflows.  Does that make any sense?
> >
> 
> Hmm, now that you mention it - and in the light of the recent post by
> Ryan Lovelett about polling precision - I think it makes sense to have
> this. Especially since it's very easy to add.
> 

OK.  I was only thinking about the edge events, but you might want it
for your line info events on the chip fd as well?

> > And would it be useful for userspace to be able to influence the size of
> > the event buffer (currently fixed at 16 events per line)?
> >
> 
> Good question. I would prefer to not overdo it though. The event
> request would need to contain the desired kfifo size and we'd only
> allow to set it on request, right?
>

Yeah, it would only be relevant if edge detection was set and, as per
edge

Re: [PATCH v2 0/3] Relocate execve() sanity checks

2020-06-05 Thread Kees Cook

On Fri, Jun 05, 2020 at 05:40:53PM -0700, Andrew Morton wrote:
> On Fri,  5 Jun 2020 09:00:10 -0700 Kees Cook  wrote:
> 
> > While looking at the code paths for the proposed O_MAYEXEC flag, I saw
> > some things that looked like they should be fixed up.
> > 
> >   exec: Change uselib(2) IS_SREG() failure to EACCES
> > This just regularizes the return code on uselib(2).
> > 
> >   exec: Move S_ISREG() check earlier
> > This moves the S_ISREG() check even earlier than it was already.
> > 
> >   exec: Move path_noexec() check earlier
> > This adds the path_noexec() check to the same place as the
> > S_ISREG() check.
> 
> Thanks.
> 
> These don't seem super-urgent and they aren't super-reviewed, so I
> suggest we hold them off until the next cycle?

Agreed; that's fine by me. It's mostly clean up and preparation for
performing future checking through the MAY_EXEC path.

And I'd love to get an Ack from Al or Aleksa, nudge nudge. :)

-- 
Kees Cook

Re: [PATCH] crypto: hisilicon - fix strncpy warning with strlcpy

2020-06-05 Thread Zhangfei Gao





On 2020/6/5 下午11:49, Eric Biggers wrote:

On Fri, Jun 05, 2020 at 11:26:20PM +0800, Zhangfei Gao wrote:


On 2020/6/5 下午8:17, Herbert Xu wrote:

On Fri, Jun 05, 2020 at 05:34:32PM +0800, Zhangfei Gao wrote:

Will add a check after the copy.

      strlcpy(interface.name, pdev->driver->name, sizeof(interface.name));
      if (strlen(pdev->driver->name) != strlen(interface.name))
      return -EINVAL;

You don't need to do strlen.  The function strlcpy returns the
length of the source string.

Better yet use strscpy which will even return an error for you.



Yes, good idea, we can use strscpy.

+   int ret;

-   strncpy(interface.name, pdev->driver->name, sizeof(interface.name));
+   ret = strscpy(interface.name, pdev->driver->name,
sizeof(interface.name));
+   if (ret < 0)
+   return ret;

You might want to use -ENAMETOOLONG instead of the strscpy return value of
-E2BIG.

Yes, make sense, thanks Eric

Re: [PATCH v8 04/16] s390/zcrypt: driver callback to indicate resource in use

Hi Tony,

I love your patch! Perhaps something to improve:

[auto build test WARNING on kvms390/next]
[also build test WARNING on linus/master v5.7]
[cannot apply to s390/features linux/master next-20200605]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Tony-Krowiak/s390-vfio-ap-dynamic-configuration-support/20200606-054350
base:   https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git next
config: s390-randconfig-r025-20200605 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
6dd738e2f0609f7d3313b574a1d471263d2d3ba1)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install s390 cross compiling tool for clang build
# apt-get install binutils-s390-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=s390 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>, old ones prefixed by <<):

include/uapi/linux/swab.h:19:12: note: expanded from macro '___constant_swab32'
(((__u32)(x) & (__u32)0x00ffUL) << 24) | ^
In file included from drivers/s390/crypto/ap_bus.c:28:
In file included from arch/s390/include/asm/airq.h:14:
In file included from include/linux/dma-mapping.h:11:
In file included from include/linux/scatterlist.h:9:
In file included from arch/s390/include/asm/io.h:72:
include/asm-generic/io.h:492:45: warning: performing pointer arithmetic on a 
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
val = __le32_to_cpu(__raw_readl(PCI_IOBASE + addr));
~~ ^
include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro 
'__le32_to_cpu'
#define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
^
include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32'
___constant_swab32(x) :   ^
include/uapi/linux/swab.h:20:12: note: expanded from macro '___constant_swab32'
(((__u32)(x) & (__u32)0xff00UL) <<  8) | ^
In file included from drivers/s390/crypto/ap_bus.c:28:
In file included from arch/s390/include/asm/airq.h:14:
In file included from include/linux/dma-mapping.h:11:
In file included from include/linux/scatterlist.h:9:
In file included from arch/s390/include/asm/io.h:72:
include/asm-generic/io.h:492:45: warning: performing pointer arithmetic on a 
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
val = __le32_to_cpu(__raw_readl(PCI_IOBASE + addr));
~~ ^
include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro 
'__le32_to_cpu'
#define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
^
include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32'
___constant_swab32(x) :   ^
include/uapi/linux/swab.h:21:12: note: expanded from macro '___constant_swab32'
(((__u32)(x) & (__u32)0x00ffUL) >>  8) | ^
In file included from drivers/s390/crypto/ap_bus.c:28:
In file included from arch/s390/include/asm/airq.h:14:
In file included from include/linux/dma-mapping.h:11:
In file included from include/linux/scatterlist.h:9:
In file included from arch/s390/include/asm/io.h:72:
include/asm-generic/io.h:492:45: warning: performing pointer arithmetic on a 
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
val = __le32_to_cpu(__raw_readl(PCI_IOBASE + addr));
~~ ^
include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro 
'__le32_to_cpu'
#define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
^
include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32'
___constant_swab32(x) :   ^
include/uapi/linux/swab.h:22:12: note: expanded from macro '___constant_swab32'
(((__u32)(x) & (__u32)0xff00UL) >> 24)))
^
In file included from drivers/s390/crypto/ap_bus.c:28:
In file included from arch/s390/include/asm/airq.h:14:
In file included from include/linux/dma-mapping.h:11:
In file included from include/linux/scatterlist.h:9:
In file included from arch/s390/include/asm/io.h:72:
include/asm-generic/io.h:492:45: warning: performing pointer arithmetic on a 
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
val = __le32_to_cpu(__raw_readl(PCI_IOBASE + addr));
~~ ^
include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro 
'__le32_to_cpu'
#define __le32_to_cpu(x) __swab32((__

Re: [PATCH v8 04/16] s390/zcrypt: driver callback to indicate resource in use

Hi Tony,

I love your patch! Perhaps something to improve:

[auto build test WARNING on kvms390/next]
[also build test WARNING on linus/master v5.7]
[cannot apply to s390/features linux/master next-20200605]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Tony-Krowiak/s390-vfio-ap-dynamic-configuration-support/20200606-054350
base:   https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git next
config: s390-allyesconfig (attached as .config)
compiler: s390-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=s390 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>, old ones prefixed by <<):

drivers/s390/crypto/ap_bus.c: In function '__ap_revise_reserved':
drivers/s390/crypto/ap_bus.c:594:6: warning: variable 'rc' set but not used 
[-Wunused-but-set-variable]
594 |  int rc, card, queue, devres, drvres;
|  ^~
drivers/s390/crypto/ap_bus.c: At top level:
>> drivers/s390/crypto/ap_bus.c:1106:5: warning: no previous prototype for 
>> '__verify_card_reservations' [-Wmissing-prototypes]
1106 | int __verify_card_reservations(struct device_driver *drv, void *data)
| ^~
>> drivers/s390/crypto/ap_bus.c:1195:5: warning: no previous prototype for 
>> '__verify_queue_reservations' [-Wmissing-prototypes]
1195 | int __verify_queue_reservations(struct device_driver *drv, void *data)
| ^~~

vim +/__verify_card_reservations +1106 drivers/s390/crypto/ap_bus.c

  1105  
> 1106  int __verify_card_reservations(struct device_driver *drv, void *data)
  1107  {
  1108  int rc = 0;
  1109  struct ap_driver *ap_drv = to_ap_drv(drv);
  1110  unsigned long *newapm = (unsigned long *)data;
    
  1112  /*
  1113   * No need to verify whether the driver is using the queues if 
it is the
  1114   * default driver.
  1115   */
  1116  if (ap_drv->flags & AP_DRIVER_FLAG_DEFAULT)
  1117  return 0;
  1118  
  1119  /* The non-default driver's module must be loaded */
  1120  if (!try_module_get(drv->owner))
  1121  return 0;
  1122  
  1123  if (ap_drv->in_use)
  1124  if (ap_drv->in_use(newapm, ap_perms.aqm))
  1125  rc = -EADDRINUSE;
  1126  
  1127  module_put(drv->owner);
  1128  
  1129  return rc;
  1130  }
  1131  
  1132  static int apmask_commit(unsigned long *newapm)
  1133  {
  1134  int rc;
  1135  unsigned long reserved[BITS_TO_LONGS(AP_DEVICES)];
  1136  
  1137  /*
  1138   * Check if any bits in the apmask have been set which will
  1139   * result in queues being removed from non-default drivers
  1140   */
  1141  if (bitmap_andnot(reserved, newapm, ap_perms.apm, AP_DEVICES)) {
  1142  rc = bus_for_each_drv(_bus_type, NULL, reserved,
  1143__verify_card_reservations);
  1144  if (rc)
  1145  return rc;
  1146  }
  1147  
  1148  memcpy(ap_perms.apm, newapm, APMASKSIZE);
  1149  
  1150  return 0;
  1151  }
  1152  
  1153  static ssize_t apmask_store(struct bus_type *bus, const char *buf,
  1154  size_t count)
  1155  {
  1156  int rc;
  1157  DECLARE_BITMAP(newapm, AP_DEVICES);
  1158  
  1159  if (mutex_lock_interruptible(_perms_mutex))
  1160  return -ERESTARTSYS;
  1161  
  1162  rc = ap_parse_bitmap_str(buf, ap_perms.apm, AP_DEVICES, newapm);
  1163  if (rc)
  1164  goto done;
  1165  
  1166  rc = apmask_commit(newapm);
  1167  
  1168  done:
  1169  mutex_unlock(_perms_mutex);
  1170  if (rc)
  1171  return rc;
  1172  
  1173  ap_bus_revise_bindings();
  1174  
  1175  return count;
  1176  }
  1177  
  1178  static BUS_ATTR_RW(apmask);
  1179  
  1180  static ssize_t aqmask_show(struct bus_type *bus, char *buf)
  1181  {
  1182  int rc;
  1183  
  1184  if (mutex_lock_interruptible(_perms_mutex))
  1185  return -ERESTARTSYS;
  1186  rc = scnprintf(buf, PAGE_SIZE,
  1187 "0x%016lx%016lx%016lx%016lx\n",
  1

linux-next: Signed-off-by missing for commit in the risc-v tree

2020-06-05 Thread Stephen Rothwell

Hi all,

Commit

  1c82ca4f876d ("RISC-V: Force select RISCV_INTC for CONFIG_RISCV")

is missing a Signed-off-by from its committer.

-- 
Cheers,
Stephen Rothwell


pgpTO9ql0kqAM.pgp
Description: OpenPGP digital signature

Re: [RFC] Restrict the untrusted devices, to bind to only a set of "whitelisted" drivers

2020-06-05 Thread Rajat Jain

Hello Greg,

Thank you for continuing to work with me through this.

On Fri, Jun 5, 2020 at 1:02 AM Greg Kroah-Hartman
 wrote:
>
> On Thu, Jun 04, 2020 at 12:38:18PM -0700, Rajat Jain wrote:
> > Hello,
> >
> > I spent some more thoughts into this...
> >
> > On Wed, Jun 3, 2020 at 5:16 AM Greg Kroah-Hartman
> >  wrote:
> > >
> > > On Wed, Jun 03, 2020 at 04:51:18AM -0700, Rajat Jain wrote:
> > > > Hello,
> > > >
> > > > >
> > > > > > Thanks for the pointer! I'm still looking at the details yet, but a
> > > > > > quick look (usb_dev_authorized()) seems to suggest that this API is
> > > > > > "device based". The multiple levels of "authorized" seem to take 
> > > > > > shape
> > > > > > from either how it is wired or from userspace choice. Once 
> > > > > > authorized,
> > > > > > USB device or interface is authorized to be used by *anyone* (can be
> > > > > > attached to any drivers). Do I understand it right that it does not
> > > > > > differentiate between drivers?
> > > > >
> > > > > Yes, and that is what you should do, don't fixate on drivers.  Users
> > > > > know how to control and manage devices.  Us kernel developers are
> > > > > responsible for writing solid drivers and getting them merged into the
> > > > > kernel tree and maintaining them over time.  Drivers in the kernel
> > > > > should always be trusted, ...
> > > >
> > > > 1) Yes, I agree that this would be ideal, and this should be our
> > > > mission. I should clarify that I may have used the wrong term
> > > > "Trusted/Certified drivers". I didn't really mean that the drivers may
> > > > be malicious by intent. What I really meant is that a driver may have
> > > > an attack surface, which is a vulnerability that may be exploited.
> > >
> > > Any code has such a thing, proving otherwise is a tough problem :)
> > >
> > > > Realistically speaking, finding vulnerabilities in drivers, creating
> > > > attacks to exploit them, and fixing them is a never ending cat and
> > > > mouse game. At Least "identifying the vulnerabilities" part is better
> > > > performed by security folks rather than driver writers.
> > >
> > > Are you sure about that?  It's hard to prove a negative :)
> > >
> > > > Earlier in the
> > > > thread I had mentioned certain studies/projects that identified and
> > > > exploited such vulnerabilities in the drivers. I should have used the
> > > > term "Vetted Drivers" maybe to convey the intent better - drivers that
> > > > have been vetted by a security focussed team (admin). What I'm
> > > > advocating here is an administrator's right to control the drivers
> > > > that he wants to allow for external ports on his systems.
> > >
> > > That's an odd thing, but sure, if you want to write up such a policy for
> > > your systems, great.  But that policy does not belong in the kernel, it
> > > belongs in userspace.
> > >
> > > > 2) In addition to the problem of driver negligences / vulnerabilities
> > > > to be exploited, we ran into another problem with the "whitelist
> > > > devices only" approach. We did start with the "device based" approach
> > > > only initially - but quickly realized that anything we use to
> > > > whitelist an external device can only be based on the info provided by
> > > > *that device* itself. So until we have devices that exchange
> > > > certificates with kernel [1], it is easy for a malicious device to
> > > > spoof a whitelisted device (by presenting the same VID:DID or any
> > > > other data that is used by us to whitelist it).
> > > >
> > > > [1] 
> > > > https://www.intel.com/content/www/us/en/io/pci-express/pcie-device-security-enhancements-spec.html
> > > >
> > > > I hope that helps somewhat clarify how / why we reached here?
> > >
> > > Kind of, I still think all you need to do is worry about controling the
> > > devices and if a driver should bind to it or not.  Again, much like USB
> > > has been doing for a very long time now.  The idea of "spoofing" ids
> > > also is not new, and has been around for a very long time as well, and
> > > again, the controls that the USB core gives you allows you to make any
> > > type of policy decision you want to, in userspace.
> >
> > Er, *currently* it doesn't allow the userspace to make the particular
> > policy I want to, right? Specifically, today an administrator can not
> > control which USB *drivers* he wants to allow on an *external* USB
> > port.
>
> Not true, you can do that today with the explicit binding/unbinding of
> devices to drivers in userspace.  Been there for many decades :)

Not sure if I understood. Can you please elaborate how that helps
implement the policy I want?

>
> But, think this through, since when do you have _multiple_ drivers that
> have support to control the same type of device?  We almost never allow
> that in the kernel today as that way lies madness (no heiarchy of
> drivers to bind to what devices and so on.)
>
> We always strive to keep a one-to-one mapping of "this device is only
> allowed to be controlled by this

Re: [PATCH 1/2] MIPS: set page access bit with pgprot on some MIPS platform

On Fri,  5 Jun 2020 17:11:05 +0800 Bibo Mao  wrote:

> On MIPS system which has rixi hardware bit, page access bit is not
> set in pgrot. For memory reading, there will be one page fault to
> allocate physical page; however valid bit is not set, there will
> be the second fast tlb-miss fault handling to set valid/access bit.
> 
> This patch set page access/valid bit with pgrot if there is reading
> access privilege. It will reduce one tlb-miss handling for memory
> reading access.
> 
> The valid/access bit will be cleared in order to track memory
> accessing activity. If the page is accessed, tlb-miss fast handling
> will set valid/access bit, pte_sw_mkyoung is not necessary in slow
> page fault path. This patch removes pte_sw_mkyoung function which
> is defined as empty function except MIPS system.
> 
> ...
>
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -2704,7 +2704,6 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
>   }
>   flush_cache_page(vma, vmf->address, pte_pfn(vmf->orig_pte));
>   entry = mk_pte(new_page, vma->vm_page_prot);
> - entry = pte_sw_mkyoung(entry);
>   entry = maybe_mkwrite(pte_mkdirty(entry), vma);
>   /*
>* Clear the pte entry and flush it first, before updating the
> @@ -3379,7 +3378,6 @@ static vm_fault_t do_anonymous_page(struct vm_fault 
> *vmf)
>   __SetPageUptodate(page);
>  
>   entry = mk_pte(page, vma->vm_page_prot);
> - entry = pte_sw_mkyoung(entry);
>   if (vma->vm_flags & VM_WRITE)
>   entry = pte_mkwrite(pte_mkdirty(entry));
>  
> @@ -3662,7 +3660,6 @@ vm_fault_t alloc_set_pte(struct vm_fault *vmf, struct 
> mem_cgroup *memcg,
>  
>   flush_icache_page(vma, page);
>   entry = mk_pte(page, vma->vm_page_prot);
> - entry = pte_sw_mkyoung(entry);
>   if (write)
>   entry = maybe_mkwrite(pte_mkdirty(entry), vma);
>   /* copy-on-write page */

Only affects mips, so cheerily

Acked-by: Andrew Morton

Re: [PATCH v3 1/7] mm: Add functions to track page directory modifications

On Fri, 5 Jun 2020 12:46:55 +0100 Catalin Marinas  
wrote:

> On Fri, Jun 05, 2020 at 11:08:13AM +0100, Catalin Marinas wrote:
> > This patch causes a kernel panic on arm64 (and possibly powerpc, I
> > haven't tried). arm64 still uses the 5level-fixup.h and pud_alloc()
> > checks for the empty p4d with pgd_none() instead of p4d_none().
> 
> Ah, should have checked the list first
> (https://lore.kernel.org/linux-mm/20200604074446.23944-1-j...@8bytes.org/).
> 

Sorry about that.

Can you confirm that the merge of Mike's 5level_hack zappage has fixed
the arm64 wontboot?

Re: [GIT PULL] sh: remove sh5 support

On Fri, 5 Jun 2020 20:23:07 +0200 Geert Uytterhoeven  
wrote:

> Hi Adrian,
> 
> On Fri, Jun 5, 2020 at 7:58 PM John Paul Adrian Glaubitz
>  wrote:
> > On 6/5/20 5:59 PM, Rich Felker wrote:
> > >> Ah, sorry, I missed that. You're right, it should probably go through
> > >> someone else's tree then.
> > >
> > > Do you know if it's needed to un-break sh4? If so we should push to
> > > get whoever has jurisdiction over it to include it; otherwise I'm
> > > indifferent.
> 
> I think the above is about the asm-generic/vmlinux.lds.h patch?
> https://marc.info/?l=linux-sh=158429470221261=2
> 
> That one falls under Arnd's jurisdiction.
> And AFAIUC, it matters for recent binutils only? So Arnd should know.
> 

Aligning RO_AFTER_INIT_DATA is simply a no-brainer:

--- 
a/include/asm-generic/vmlinux.lds.h~include-asm-generic-vmlinuxldsh-align-ro_after_init
+++ a/include/asm-generic/vmlinux.lds.h
@@ -374,6 +374,7 @@
  */
 #ifndef RO_AFTER_INIT_DATA
 #define RO_AFTER_INIT_DATA \
+   . = ALIGN(8);   \
__start_ro_after_init = .;  \
*(.data..ro_after_init) \
JUMP_TABLE_DATA \

So I'll send this in to Linus for 5.8-rc1.  And I think I'll add a cc:stable to
it, so people can use older kernels with newer toolchains.


I still have a few other sh patches sitting here:

https://ozlabs.org/~akpm/mmotm/broken-out/sh-clkfwk-remove-r8-r16-r32.patch
https://ozlabs.org/~akpm/mmotm/broken-out/sh-remove-call-to-memset-after-dma_alloc_coherent.patch
https://ozlabs.org/~akpm/mmotm/broken-out/sh-use-generic-strncpy.patch
https://ozlabs.org/~akpm/mmotm/broken-out/sh-add-missing-export_symbol-for-__delay.patch

What should I do with those?

Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.8-1 tag

2020-06-05 Thread Michael Ellerman

Linus Torvalds  writes:
> On Fri, Jun 5, 2020 at 12:01 PM Linus Torvalds
>  wrote:
>>
>> ..and then when I actually compared whether I otherwise got the same
>> result as you, I realized that this all depends on the module tree.
>>
>> I'll go merge that first, and then re-do this all. Oh well.
>
> Ok, redone and pushed out. Can you check that the end result makes sense?

Yep, looks good to me. Has passed all my basic build & boot tests.

cheers

Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.8-1 tag

2020-06-05 Thread Michael Ellerman

Linus Torvalds  writes:
> On Fri, Jun 5, 2020 at 9:38 AM Michael Ellerman  wrote:
>>
>> I've pushed the result of my resolution of the conflicts to the powerpc/merge
>> branch, if you want to look at that, though I've also tried to describe it in
>> full below.
>
> I ended up doing the machine_check_exception() differently, because I
> felt the code itself was done wrong and I wanted to add a note about
> that.
>
> Having the same function have completely different semantics depending
> on a platform issue is just fundamentally wrong, and makes not just
> for fragile code, but also means that you can't do single image
> kernels.

Yeah I agree it's not that nicely structured.

In this case CONFIG_PPC_BOOK3S_64 is one of our top-level compile time
switches anyway, so the single image thing at least isn't a concern.

> It should be two different functions, possibly just
>
>non_nmi_fn() { ... }
>
>nmi_fn() { nmi_enter(); non_nmi_fn(); nmi_exit(); }
>
> and now you don't have odd rules for the same function that depends on
> how the platform happens to call it.

Agreed.

> I didn't do the above. I did something that looked like the old code,
> but had a comment. Oh well.

Thanks, we can restructure it later.

> But thanks for describing the merge, I'd have missed the place where
> there was a new use of pgd_oiffset().

Yeah I missed it to begin with :}

> ..and then when I actually compared whether I otherwise got the same
> result as you, I realized that this all depends on the module tree.
>
> I'll go merge that first, and then re-do this all. Oh well.

Darn it. I figured you'd have merged that by the time you saw my pull,
will mention anything similar in future.

cheers

Re: [PATCH v8 02/16] s390/vfio-ap: use new AP bus interface to search for queue devices

Hi Tony,

I love your patch! Perhaps something to improve:

[auto build test WARNING on kvms390/next]
[also build test WARNING on linus/master v5.7]
[cannot apply to s390/features linux/master next-20200605]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Tony-Krowiak/s390-vfio-ap-dynamic-configuration-support/20200606-054350
base:   https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git next
config: s390-allyesconfig (attached as .config)
compiler: s390-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=s390 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>, old ones prefixed by <<):

>> drivers/s390/crypto/vfio_ap_ops.c:130:24: warning: no previous prototype for 
>> 'vfio_ap_irq_disable' [-Wmissing-prototypes]
130 | struct ap_queue_status vfio_ap_irq_disable(struct vfio_ap_queue *q)
|^~~
>> drivers/s390/crypto/vfio_ap_ops.c:1110:5: warning: no previous prototype for 
>> 'vfio_ap_mdev_reset_queue' [-Wmissing-prototypes]
1110 | int vfio_ap_mdev_reset_queue(unsigned int apid, unsigned int apqi,
| ^~~~

vim +/vfio_ap_irq_disable +130 drivers/s390/crypto/vfio_ap_ops.c

ec89b55e3bce7c Pierre Morel  2019-05-21  113  
ec89b55e3bce7c Pierre Morel  2019-05-21  114  /**
ec89b55e3bce7c Pierre Morel  2019-05-21  115   * vfio_ap_irq_disable
ec89b55e3bce7c Pierre Morel  2019-05-21  116   * @q: The vfio_ap_queue
ec89b55e3bce7c Pierre Morel  2019-05-21  117   *
ec89b55e3bce7c Pierre Morel  2019-05-21  118   * Uses ap_aqic to 
disable the interruption and in case of success, reset
ec89b55e3bce7c Pierre Morel  2019-05-21  119   * in progress or IRQ 
disable command already proceeded: calls
ec89b55e3bce7c Pierre Morel  2019-05-21  120   * 
vfio_ap_wait_for_irqclear() to check for the IRQ bit to be clear
ec89b55e3bce7c Pierre Morel  2019-05-21  121   * and calls 
vfio_ap_free_aqic_resources() to free the resources associated
ec89b55e3bce7c Pierre Morel  2019-05-21  122   * with the AP interrupt 
handling.
ec89b55e3bce7c Pierre Morel  2019-05-21  123   *
ec89b55e3bce7c Pierre Morel  2019-05-21  124   * In the case the AP is 
busy, or a reset is in progress,
ec89b55e3bce7c Pierre Morel  2019-05-21  125   * retries after 20ms, up 
to 5 times.
ec89b55e3bce7c Pierre Morel  2019-05-21  126   *
ec89b55e3bce7c Pierre Morel  2019-05-21  127   * Returns if ap_aqic 
function failed with invalid, deconfigured or
ec89b55e3bce7c Pierre Morel  2019-05-21  128   * checkstopped AP.
ec89b55e3bce7c Pierre Morel  2019-05-21  129   */
ec89b55e3bce7c Pierre Morel  2019-05-21 @130  struct ap_queue_status 
vfio_ap_irq_disable(struct vfio_ap_queue *q)
ec89b55e3bce7c Pierre Morel  2019-05-21  131  {
ec89b55e3bce7c Pierre Morel  2019-05-21  132struct ap_qirq_ctrl 
aqic_gisa = {};
ec89b55e3bce7c Pierre Morel  2019-05-21  133struct ap_queue_status 
status;
ec89b55e3bce7c Pierre Morel  2019-05-21  134int retries = 5;
ec89b55e3bce7c Pierre Morel  2019-05-21  135  
ec89b55e3bce7c Pierre Morel  2019-05-21  136do {
ec89b55e3bce7c Pierre Morel  2019-05-21  137status = 
ap_aqic(q->apqn, aqic_gisa, NULL);
ec89b55e3bce7c Pierre Morel  2019-05-21  138switch 
(status.response_code) {
ec89b55e3bce7c Pierre Morel  2019-05-21  139case 
AP_RESPONSE_OTHERWISE_CHANGED:
ec89b55e3bce7c Pierre Morel  2019-05-21  140case 
AP_RESPONSE_NORMAL:
ec89b55e3bce7c Pierre Morel  2019-05-21  141
vfio_ap_wait_for_irqclear(q->apqn);
ec89b55e3bce7c Pierre Morel  2019-05-21  142goto 
end_free;
ec89b55e3bce7c Pierre Morel  2019-05-21  143case 
AP_RESPONSE_RESET_IN_PROGRESS:
ec89b55e3bce7c Pierre Morel  2019-05-21  144case 
AP_RESPONSE_BUSY:
ec89b55e3bce7c Pierre Morel  2019-05-21  145
msleep(20);
ec89b55e3bce7c Pierre Morel  2019-05-21  146break;
ec89b55e3bce7c Pierre Morel  2019-05-21  147case 
AP_RESPONSE_Q_NOT_AVAIL:
ec89b55e3bce7c Pierre Morel  2019-05-21  148case 
AP_RESPONSE_DECONFIGURED:
ec89b55e3b

Re: [PATCH v2 0/3] Relocate execve() sanity checks

On Fri,  5 Jun 2020 09:00:10 -0700 Kees Cook  wrote:

> While looking at the code paths for the proposed O_MAYEXEC flag, I saw
> some things that looked like they should be fixed up.
> 
>   exec: Change uselib(2) IS_SREG() failure to EACCES
>   This just regularizes the return code on uselib(2).
> 
>   exec: Move S_ISREG() check earlier
>   This moves the S_ISREG() check even earlier than it was already.
> 
>   exec: Move path_noexec() check earlier
>   This adds the path_noexec() check to the same place as the
>   S_ISREG() check.

Thanks.

These don't seem super-urgent and they aren't super-reviewed, so I
suggest we hold them off until the next cycle?

[PATCH v1 2/2] of: property: Improve cycle detection when one of the devices is never added

2020-06-05 Thread Saravana Kannan

Consider this example where -> means LHS device is a consumer of RHS
device and indentation represents "child of" of the previous device.

Device A -> Device C

Device B -> Device A
Device C

Without this commit:
1. Device A is added.
2. Device A is added to waiting for supplier list (Device C)
3. Device B is added
4. Device B is linked as a consumer to Device A
5. Device A doesn't probe because it's waiting for Device C to be added.
6. Device B doesn't probe because Device A hasn't probed.
7. Device C will never be added because it's parent hasn't probed.

So, Device A, B and C will be in a probe/add deadlock.

This commit detects this scenario and stops trying to create a device
link between Device A and Device C since doing so would create a cycle:
Device A -> Devic C -(parent)-> Device B -> Device A.

With this commit:
1. Device A is added.
3. Device B is added
4. Device B is linked as a consumer to Device A
5. Device A probes.
6. Device B probes because Device A has probed.
7. Device C is added and probed.

Signed-off-by: Saravana Kannan 
---
 drivers/of/property.c | 44 +--
 1 file changed, 38 insertions(+), 6 deletions(-)

diff --git a/drivers/of/property.c b/drivers/of/property.c
index 1f2086f4e7ce..7eebe21274a4 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -1014,6 +1014,20 @@ static bool of_is_ancestor_of(struct device_node 
*test_ancestor,
return false;
 }
 
+static struct device *of_get_next_parent_dev(struct device_node *np)
+{
+   struct device *dev = NULL;
+
+   of_node_get(np);
+   do {
+   np = of_get_next_parent(np);
+   if (np)
+   dev = get_dev_from_fwnode(>fwnode);
+   } while (np && !dev);
+   of_node_put(np);
+   return dev;
+}
+
 /**
  * of_link_to_phandle - Add device link to supplier from supplier phandle
  * @dev: consumer device
@@ -1035,10 +1049,9 @@ static bool of_is_ancestor_of(struct device_node 
*test_ancestor,
 static int of_link_to_phandle(struct device *dev, struct device_node *sup_np,
  u32 dl_flags)
 {
-   struct device *sup_dev;
+   struct device *sup_dev, *sup_par_dev;
int ret = 0;
struct device_node *tmp_np = sup_np;
-   int is_populated;
 
of_node_get(sup_np);
/*
@@ -1075,16 +1088,35 @@ static int of_link_to_phandle(struct device *dev, 
struct device_node *sup_np,
return -EINVAL;
}
sup_dev = get_dev_from_fwnode(_np->fwnode);
-   is_populated = of_node_check_flag(sup_np, OF_POPULATED);
-   of_node_put(sup_np);
-   if (!sup_dev && is_populated) {
+   if (!sup_dev && of_node_check_flag(sup_np, OF_POPULATED)) {
/* Early device without struct device. */
dev_dbg(dev, "Not linking to %pOFP - No struct device\n",
sup_np);
+   of_node_put(sup_np);
return -ENODEV;
} else if (!sup_dev) {
-   return -EAGAIN;
+   sup_par_dev = of_get_next_parent_dev(sup_np);
+   of_node_put(sup_np);
+
+   /*
+* DL_FLAG_SYNC_STATE_ONLY doesn't block probing, so cycle
+* detection isn't necessary and shouldn't be done.
+*/
+   if (dl_flags & DL_FLAG_SYNC_STATE_ONLY)
+   return -EAGAIN;
+
+   /*
+* If devices haven't been created for any of the ancestors, we
+* can't check for cycles. So let's try again later.
+*/
+   if (!sup_par_dev)
+   return -EAGAIN;
+
+   /* Cyclic dependency detected, don't try to link */
+   if (device_is_dependent(dev, sup_par_dev))
+   return -EINVAL;
}
+   of_node_put(sup_np);
if (!device_link_add(dev, sup_dev, dl_flags))
ret = -EINVAL;
put_device(sup_dev);
-- 
2.27.0.278.ge193c7cf3a9-goog

[PATCH v1 0/2] fw_devlink: Improve cycle detection in DT

2020-06-05 Thread Saravana Kannan

Patch 2/2 explain the series. Just using a cover letter to thread the
series and add CC's.

-Saravana

Saravana Kannan (2):
  driver core: Add device_is_dependent() to linux/device.h
  of: property: Improve cycle detection when one of the devices is never
added

 drivers/base/core.c|  2 +-
 drivers/of/property.c  | 44 --
 include/linux/device.h |  1 +
 3 files changed, 40 insertions(+), 7 deletions(-)

-- 
2.27.0.278.ge193c7cf3a9-goog

[PATCH v1 1/2] driver core: Add device_is_dependent() to linux/device.h

2020-06-05 Thread Saravana Kannan

DT implementation of fw_devlink needs this function to detect cycles. So
make it available.

Signed-off-by: Saravana Kannan 
---
 drivers/base/core.c| 2 +-
 include/linux/device.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 139cdf7e7327..509b13610b56 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -118,7 +118,7 @@ int device_links_read_lock_held(void)
  * Check if @target depends on @dev or any device dependent on it (its child or
  * its consumer etc).  Return 1 if that is the case or 0 otherwise.
  */
-static int device_is_dependent(struct device *dev, void *target)
+int device_is_dependent(struct device *dev, void *target)
 {
struct device_link *link;
int ret;
diff --git a/include/linux/device.h b/include/linux/device.h
index ac8e37cd716a..5c618effc51e 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -829,6 +829,7 @@ extern int device_change_owner(struct device *dev, kuid_t 
kuid, kgid_t kgid);
 extern const char *device_get_devnode(struct device *dev,
  umode_t *mode, kuid_t *uid, kgid_t *gid,
  const char **tmp);
+extern int device_is_dependent(struct device *dev, void *target);
 
 static inline bool device_supports_offline(struct device *dev)
 {
-- 
2.27.0.278.ge193c7cf3a9-goog

Re: [RFC PATCH 5/5] mm, slub: make reclaim_account attribute read-only

On Tue, Jun 02, 2020 at 04:15:19PM +0200, Vlastimil Babka wrote:
> The attribute reflects the SLAB_RECLAIM_ACCOUNT cache flag. It's not clear why
> this attribute was writable in the first place, as it's tied to how the cache
> is used by its creator, it's not a user tunable. Furthermore:
> 
> - it affects slab merging, but that's not being checked while toggled
> - if affects whether __GFP_RECLAIMABLE flag is used to allocate page, but
>   the runtime toggle doesn't update allocflags
> - it affects cache_vmstat_idx() so runtime toggle might lead to incosistency
>   of NR_SLAB_RECLAIMABLE and NR_SLAB_UNRECLAIMABLE
> 
> Thus make it read-only.
> 
> Signed-off-by: Vlastimil Babka 

Acked-by: Roman Gushchin 

> ---
>  mm/slub.c | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index 38dd6f3ebb04..d4a9a097da50 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -5223,16 +5223,7 @@ static ssize_t reclaim_account_show(struct kmem_cache 
> *s, char *buf)
>  {
>   return sprintf(buf, "%d\n", !!(s->flags & SLAB_RECLAIM_ACCOUNT));
>  }
> -
> -static ssize_t reclaim_account_store(struct kmem_cache *s,
> - const char *buf, size_t length)
> -{
> - s->flags &= ~SLAB_RECLAIM_ACCOUNT;
> - if (buf[0] == '1')
> - s->flags |= SLAB_RECLAIM_ACCOUNT;
> - return length;
> -}
> -SLAB_ATTR(reclaim_account);
> +SLAB_ATTR_RO(reclaim_account);
>  
>  static ssize_t hwcache_align_show(struct kmem_cache *s, char *buf)
>  {
> -- 
> 2.26.2
> 
>

Re: [RFC PATCH 4/5] mm, slub: make remaining slub_debug related attributes read-only

On Tue, Jun 02, 2020 at 04:15:18PM +0200, Vlastimil Babka wrote:
> SLUB_DEBUG creates several files under /sys/kernel/slab// that can be
> read to check if the respective debugging options are enabled for given cache.
> Some options, namely sanity_checks, trace, and failslab can be also enabled 
> and
> disabled at runtime by writing into the files.
> 
> The runtime toggling is racy. Some options disable __CMPXCHG_DOUBLE when
> enabled, which means that in case of concurrent allocations, some can still 
> use
> __CMPXCHG_DOUBLE and some not, leading to potential corruption. The s->flags
> field is also not updated or checked atomically. The simplest solution is to
> remove the runtime toggling. The extended slub_debug boot parameter syntax
> introduced by earlier patch should allow to fine-tune the debugging
> configuration during boot with same granularity.
> 
> Signed-off-by: Vlastimil Babka 

Acked-by: Roman Gushchin 

Thanks!

> ---
>  Documentation/vm/slub.rst |  7 ++---
>  mm/slub.c | 62 ++-
>  2 files changed, 5 insertions(+), 64 deletions(-)
> 
> diff --git a/Documentation/vm/slub.rst b/Documentation/vm/slub.rst
> index 61805e984a0d..f240292589bd 100644
> --- a/Documentation/vm/slub.rst
> +++ b/Documentation/vm/slub.rst
> @@ -115,11 +115,8 @@ If the file contains 1, the option is enabled, 0 means 
> disabled. The debug
>   T   trace
>   A   failslab
>  
> -The sanity_checks, trace and failslab files are writable, so writing 1 or 0
> -will enable or disable the option at runtime. The writes to trace and 
> failslab
> -may return -EINVAL if the cache is subject to slab merging. Careful with
> -tracing: It may spew out lots of information and never stop if used on the
> -wrong slab.
> +Careful with tracing: It may spew out lots of information and never stop if
> +used on the wrong slab.
>  
>  Slab merging
>  
> diff --git a/mm/slub.c b/mm/slub.c
> index 58c1e9e7b3b3..38dd6f3ebb04 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -5056,20 +5056,6 @@ static ssize_t show_slab_objects(struct kmem_cache *s,
>   return x + sprintf(buf + x, "\n");
>  }
>  
> -#ifdef CONFIG_SLUB_DEBUG
> -static int any_slab_objects(struct kmem_cache *s)
> -{
> - int node;
> - struct kmem_cache_node *n;
> -
> - for_each_kmem_cache_node(s, node, n)
> - if (atomic_long_read(>total_objects))
> - return 1;
> -
> - return 0;
> -}
> -#endif
> -
>  #define to_slab_attr(n) container_of(n, struct slab_attribute, attr)
>  #define to_slab(n) container_of(n, struct kmem_cache, kobj)
>  
> @@ -5291,43 +5277,13 @@ static ssize_t sanity_checks_show(struct kmem_cache 
> *s, char *buf)
>  {
>   return sprintf(buf, "%d\n", !!(s->flags & SLAB_CONSISTENCY_CHECKS));
>  }
> -
> -static ssize_t sanity_checks_store(struct kmem_cache *s,
> - const char *buf, size_t length)
> -{
> - s->flags &= ~SLAB_CONSISTENCY_CHECKS;
> - if (buf[0] == '1') {
> - s->flags &= ~__CMPXCHG_DOUBLE;
> - s->flags |= SLAB_CONSISTENCY_CHECKS;
> - }
> - return length;
> -}
> -SLAB_ATTR(sanity_checks);
> +SLAB_ATTR_RO(sanity_checks);
>  
>  static ssize_t trace_show(struct kmem_cache *s, char *buf)
>  {
>   return sprintf(buf, "%d\n", !!(s->flags & SLAB_TRACE));
>  }
> -
> -static ssize_t trace_store(struct kmem_cache *s, const char *buf,
> - size_t length)
> -{
> - /*
> -  * Tracing a merged cache is going to give confusing results
> -  * as well as cause other issues like converting a mergeable
> -  * cache into an umergeable one.
> -  */
> - if (s->refcount > 1)
> - return -EINVAL;
> -
> - s->flags &= ~SLAB_TRACE;
> - if (buf[0] == '1') {
> - s->flags &= ~__CMPXCHG_DOUBLE;
> - s->flags |= SLAB_TRACE;
> - }
> - return length;
> -}
> -SLAB_ATTR(trace);
> +SLAB_ATTR_RO(trace);
>  
>  static ssize_t red_zone_show(struct kmem_cache *s, char *buf)
>  {
> @@ -5391,19 +5347,7 @@ static ssize_t failslab_show(struct kmem_cache *s, 
> char *buf)
>  {
>   return sprintf(buf, "%d\n", !!(s->flags & SLAB_FAILSLAB));
>  }
> -
> -static ssize_t failslab_store(struct kmem_cache *s, const char *buf,
> - size_t length)
> -{
> - if (s->refcount > 1)
> - return -EINVAL;
> -
> - s->flags &= ~SLAB_FAILSLAB;
> - if (buf[0] == '1')
> - s->flags |= SLAB_FAILSLAB;
> - return length;
> -}
> -SLAB_ATTR(failslab);
> +SLAB_ATTR_RO(failslab);
>  #endif
>  
>  static ssize_t shrink_show(struct kmem_cache *s, char *buf)
> -- 
> 2.26.2
> 
>

Re: [PATCHSET v5 0/12] Add support for async buffered reads

2020-06-05 Thread Sedat Dilek

On Fri, Jun 5, 2020 at 11:24 PM Jens Axboe  wrote:
>
> On 6/5/20 3:13 PM, Jens Axboe wrote:
> > On 6/5/20 2:53 PM, Jens Axboe wrote:
> >> On 6/5/20 2:36 PM, Andres Freund wrote:
> >>> Hi,
> >>>
> >>> On 2020-06-05 13:20:28 -0700, Andres Freund wrote:
>  I'll go and try to figure out why I don't see an oops...
> >>>
> >>> Err, that probably was a typo on my end in the serial console
> >>> config. After fixing that, I did get the below.
> >>>
> >>> If helpful I can try with debugging enabled or such.
> >>>
> >>> [   67.910265] tee (2577): drop_caches: 3
> >>> [   68.059674] BUG: unable to handle page fault for address: 
> >>> 7f0b16a3c03c
> >>> [   68.062021] #PF: supervisor read access in kernel mode
> >>> [   68.063742] #PF: error_code(0x) - not-present page
> >>> [   68.065517] PGD 102e044067 P4D 102e044067 PUD 102bf7a067 PMD 0
> >>> [   68.067519] Oops:  [#1] SMP NOPTI
> >>> [   68.068800] CPU: 2 PID: 2554 Comm: postgres Not tainted 
> >>> 5.7.0-andres-10123-g87823242260e #44
> >>> [   68.071505] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
> >>> 1.13.0-1 04/01/2014
> >>> [   68.074139] RIP: 0010:__mutex_lock.isra.0+0x76/0x4e0
> >>> [   68.075389] Code: b7 01 00 00 48 39 c6 0f 84 a4 03 00 00 65 48 8b 04 
> >>> 25 80 7d 01 00 48 8b 00 a8 08 75 18 49 8b 06 48 83 e0 f8 0f 84 2f 02 00 
> >>> 00 <8b> 50 3c 85 d2 0f 85 12 02 00 00 65 48 8b 04 25 80 7d 01 00 48 8b
> >>> [   68.079125] RSP: 0018:c9befd50 EFLAGS: 00010206
> >>> [   68.080260] RAX: 7f0b16a3c000 RBX: 889037617910 RCX: 
> >>> 
> >>> [   68.084115] RDX: 7f0b16a3c000 RSI: 88902a4aca80 RDI: 
> >>> 8890376178c0
> >>> [   68.085374] RBP: c9befdf0 R08: 0001 R09: 
> >>> 
> >>> [   68.086409] R10: 889037617920 R11: 88903f8abaf0 R12: 
> >>> c9befe08
> >>> [   68.087447] R13:  R14: 8890376178c0 R15: 
> >>> 
> >>> [   68.088697] FS:  7f0b97743740() GS:88903f88() 
> >>> knlGS:
> >>> [   68.089903] CS:  0010 DS:  ES:  CR0: 80050033
> >>> [   68.090776] CR2: 7f0b16a3c03c CR3: 00102cf7c004 CR4: 
> >>> 00760ee0
> >>> [   68.091834] DR0:  DR1:  DR2: 
> >>> 
> >>> [   68.092902] DR3:  DR6: fffe0ff0 DR7: 
> >>> 0400
> >>> [   68.093967] PKRU: 5554
> >>> [   68.094427] Call Trace:
> >>> [   68.094845]  ? __schedule+0x2ac/0x720
> >>> [   68.095350]  ? schedule+0x55/0xc0
> >>> [   68.095797]  ? ep_read_events_proc+0xd0/0xd0
> >>> [   68.096354]  ep_scan_ready_list.constprop.0+0x16c/0x190
> >>> [   68.097016]  ep_poll+0x2a3/0x440
> >>> [   68.097449]  ? wait_woken+0x70/0x70
> >>> [   68.097904]  do_epoll_wait+0xb0/0xd0
> >>> [   68.098375]  __x64_sys_epoll_wait+0x1a/0x20
> >>> [   68.098913]  do_syscall_64+0x48/0x130
> >>> [   68.099393]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >>> [   68.100030] RIP: 0033:0x7f0b97845606
> >>> [   68.100498] Code: 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 
> >>> 44 00 00 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 11 b8 e8 00 00 00 0f 
> >>> 05 <48> 3d 00 f0 ff ff 77 5a c3 90 48 83 ec 28 89 54 24 18 48 89 74 24
> >>> [   68.102718] RSP: 002b:7ffe80ffdba8 EFLAGS: 0246 ORIG_RAX: 
> >>> 00e8
> >>> [   68.103644] RAX: ffda RBX: 55fb76a9a998 RCX: 
> >>> 7f0b97845606
> >>> [   68.104533] RDX: 0001 RSI: 55fb76a9aa10 RDI: 
> >>> 0005
> >>> [   68.105418] RBP: 0507 R08: 0507 R09: 
> >>> 0003
> >>> [   68.106296] R10:  R11: 0246 R12: 
> >>> 55fb76a9a998
> >>> [   68.107187] R13: 0001 R14: 0009 R15: 
> >>> 55fb76a9a998
> >>> [   68.108104] Modules linked in: 9pnet_virtio isst_if_common xhci_pci 
> >>> 9pnet iTCO_wdt intel_pmc_bxt xhci_hcd iTCO_vendor_support
> >>> [   68.109505] CR2: 7f0b16a3c03c
> >>> [   68.109962] ---[ end trace 0ca39a5ed99162ce ]---
> >>> [   68.110547] RIP: 0010:__mutex_lock.isra.0+0x76/0x4e0
> >>> [   68.111214] Code: b7 01 00 00 48 39 c6 0f 84 a4 03 00 00 65 48 8b 04 
> >>> 25 80 7d 01 00 48 8b 00 a8 08 75 18 49 8b 06 48 83 e0 f8 0f 84 2f 02 00 
> >>> 00 <8b> 50 3c 85 d2 0f 85 12 02 00 00 65 48 8b 04 25 80 7d 01 00 48 8b
> >>> [   68.113435] RSP: 0018:c9befd50 EFLAGS: 00010206
> >>> [   68.114111] RAX: 7f0b16a3c000 RBX: 889037617910 RCX: 
> >>> 
> >>> [   68.115016] RDX: 7f0b16a3c000 RSI: 88902a4aca80 RDI: 
> >>> 8890376178c0
> >>> [   68.115902] RBP: c9befdf0 R08: 0001 R09: 
> >>> 
> >>> [   68.116810] R10: 889037617920 R11: 88903f8abaf0 R12: 
> >>> c9befe08
> >>> [   68.117663] R13:  R14: 8890376178c0 R15: 
> >>> 
> >>> [   68.118520] FS:  7f0b97743740() GS:88903f88() 
> >>>

Re: [RFC PATCH 3/5] mm, slub: remove runtime allocation order changes

On Tue, Jun 02, 2020 at 04:15:17PM +0200, Vlastimil Babka wrote:
> SLUB allows runtime changing of page allocation order by writing into the
> /sys/kernel/slab//order file. Jann has reported [1] that this interface
> allows the order to be set too small, leading to crashes.
> 
> While it's possible to fix the immediate issue, closer inspection reveals
> potential races. Storing the new order calls calculate_sizes() which
> non-atomically updates a lot of kmem_cache fields while the cache is still in
> use. Unexpected behavior might occur even if the fields are set to the same
> value as they were.
> 
> This could be fixed by splitting out the part of calculate_sizes() that 
> depends
> on forced_order, so that we only update kmem_cache.oo field. This could still
> race with init_cache_random_seq(), shuffle_freelist(), allocate_slab(). 
> Perhaps
> it's possible to audit and e.g. add some READ_ONCE/WRITE_ONCE accesses, it
> might be easier just to remove the runtime order changes, which is what this
> patch does. If there are valid usecases for per-cache order setting, we could
> e.g. extend the boot parameters to do that.
> 
> [1] 
> https://lore.kernel.org/r/cag48ez31pp--h6_fzvyfj4h86qyczafpdxtjhueean+7vje...@mail.gmail.com
> 
> Reported-by: Jann Horn 
> Signed-off-by: Vlastimil Babka 

Acked-by: Roman Gushchin 

Thanks!

> ---
>  mm/slub.c | 19 +--
>  1 file changed, 1 insertion(+), 18 deletions(-)
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index ac198202dbb0..58c1e9e7b3b3 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -5111,28 +5111,11 @@ static ssize_t objs_per_slab_show(struct kmem_cache 
> *s, char *buf)
>  }
>  SLAB_ATTR_RO(objs_per_slab);
>  
> -static ssize_t order_store(struct kmem_cache *s,
> - const char *buf, size_t length)
> -{
> - unsigned int order;
> - int err;
> -
> - err = kstrtouint(buf, 10, );
> - if (err)
> - return err;
> -
> - if (order > slub_max_order || order < slub_min_order)
> - return -EINVAL;
> -
> - calculate_sizes(s, order);
> - return length;
> -}
> -
>  static ssize_t order_show(struct kmem_cache *s, char *buf)
>  {
>   return sprintf(buf, "%u\n", oo_order(s->oo));
>  }
> -SLAB_ATTR(order);
> +SLAB_ATTR_RO(order);
>  
>  static ssize_t min_partial_show(struct kmem_cache *s, char *buf)
>  {
> -- 
> 2.26.2
> 
>

Re: [RFC PATCH 2/5] mm, slub: make some slub_debug related attributes read-only

On Tue, Jun 02, 2020 at 04:15:16PM +0200, Vlastimil Babka wrote:
> SLUB_DEBUG creates several files under /sys/kernel/slab// that can be
> read to check if the respective debugging options are enabled for given cache.
> The options can be also toggled at runtime by writing into the files. Some of
> those, namely red_zone, poison, and store_user can be toggled only when no
> objects yet exist in the cache.
> 
> Vijayanand reports [1] that there is a problem with freelist randomization if
> changing the debugging option's state results in different number of objects
> per page, and the random sequence cache needs thus needs to be recomputed.
> 
> However, another problem is that the check for "no objects yet exist in the
> cache" is racy, as noted by Jann [2] and fixing that would add overhead or
> otherwise complicate the allocation/freeing paths. Thus it would be much
> simpler just to remove the runtime toggling support. The documentation
> describes it's "In case you forgot to enable debugging on the kernel command
> line", but the neccessity of having no objects limits its usefulness anyway 
> for
> many caches.
> 
> Vijayanand describes an use case [3] where debugging is enabled for all but
> zram caches for memory overhead reasons, and using the runtime toggles was the
> only way to achieve such configuration. After the previous patch it's now
> possible to do that directly from the kernel boot option, so we can remove the
> dangerous runtime toggles by making the /sys attribute files read-only.
> 
> While updating it, also improve the documentation of the debugging /sys files.
> 
> [1] 
> https://lkml.kernel.org/r/1580379523-32272-1-git-send-email-vji...@codeaurora.org
> [2] 
> https://lore.kernel.org/r/cag48ez31pp--h6_fzvyfj4h86qyczafpdxtjhueean+7vje...@mail.gmail.com
> [3] 
> https://lore.kernel.org/r/1383cd32-1ddc-4dac-b5f8-9c42282fa...@codeaurora.org
> 
> Reported-by: Vijayanand Jitta 
> Reported-by: Jann Horn 
> Signed-off-by: Vlastimil Babka 

Acked-by: Roman Gushchin 

Thanks!

> ---
>  Documentation/vm/slub.rst | 28 ++--
>  mm/slub.c | 46 +++
>  2 files changed, 20 insertions(+), 54 deletions(-)
> 
> diff --git a/Documentation/vm/slub.rst b/Documentation/vm/slub.rst
> index f1154f707e06..61805e984a0d 100644
> --- a/Documentation/vm/slub.rst
> +++ b/Documentation/vm/slub.rst
> @@ -100,20 +100,26 @@ except some that are deemed too performance critical 
> and don't need to be
>  
>   slub_debug=FZ;-,zs_handle,zspage
>  
> -In case you forgot to enable debugging on the kernel command line: It is
> -possible to enable debugging manually when the kernel is up. Look at the
> -contents of::
> +The state of each debug option for a slab can be found in the respective 
> files
> +under::
>  
>   /sys/kernel/slab//
>  
> -Look at the writable files. Writing 1 to them will enable the
> -corresponding debug option. All options can be set on a slab that does
> -not contain objects. If the slab already contains objects then sanity checks
> -and tracing may only be enabled. The other options may cause the realignment
> -of objects.
> -
> -Careful with tracing: It may spew out lots of information and never stop if
> -used on the wrong slab.
> +If the file contains 1, the option is enabled, 0 means disabled. The debug
> +options from the ``slub_debug`` parameter translate to the following files::
> +
> + F   sanity_checks
> + Z   red_zone
> + P   poison
> + U   store_user
> + T   trace
> + A   failslab
> +
> +The sanity_checks, trace and failslab files are writable, so writing 1 or 0
> +will enable or disable the option at runtime. The writes to trace and 
> failslab
> +may return -EINVAL if the cache is subject to slab merging. Careful with
> +tracing: It may spew out lots of information and never stop if used on the
> +wrong slab.
>  
>  Slab merging
>  
> diff --git a/mm/slub.c b/mm/slub.c
> index 47430aad9a65..ac198202dbb0 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -5351,61 +5351,21 @@ static ssize_t red_zone_show(struct kmem_cache *s, 
> char *buf)
>   return sprintf(buf, "%d\n", !!(s->flags & SLAB_RED_ZONE));
>  }
>  
> -static ssize_t red_zone_store(struct kmem_cache *s,
> - const char *buf, size_t length)
> -{
> - if (any_slab_objects(s))
> - return -EBUSY;
> -
> - s->flags &= ~SLAB_RED_ZONE;
> - if (buf[0] == '1') {
> - s->flags |= SLAB_RED_ZONE;
> - }
> - calculate_sizes(s, -1);
> - return length;
> -}
> -SLAB_ATTR(red_zone);
> +SLAB_ATTR_RO(red_zone);
>  
>  static ssize_t poison_show(struct kmem_cache *s, char *buf)
>  {
>   return sprintf(buf, "%d\n", !!(s->flags & SLAB_POISON));
>  }
>  
> -static ssize_t poison_store(struct kmem_cache *s,
> - const char *buf, size_t length)
> -{
> - if (any_slab_objects(s))
> - return -EBUSY;
>

Re: [PATCH] checkpatch: Add test for possible misuse of IS_ENABLED() without CONFIG_

On Fri, 05 Jun 2020 11:24:43 -0700 Joe Perches  wrote:

> IS_ENABLED is almost always used with CONFIG_ defines.
> 
> Add a test to verify that the #define being tested starts with CONFIG_.

Yay.

I wonder if there's a simple way of testing whether the CONFIG_ thing
can *ever* be enabled.  So detect if someone does

if (IS_ENABLED(CONFIG_BLOCKK))

Re: [rcu:dev.2020.06.02a 67/90] kernel/rcu/rcuperf.c:727:38: warning: format specifies type 'size_t' (aka 'unsigned int') but the argument has type 'unsigned long'

2020-06-05 Thread Paul E. McKenney

On Sat, Jun 06, 2020 at 07:07:10AM +0800, kernel test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
> dev.2020.06.02a
> head:   5216948905dd07a84cef8a7dc72c2ec076802efd
> commit: 7d16add62717136b1839f0b3d7ea4cbb98f38c2a [67/90] rcuperf: Fix 
> kfree_mult to match printk() format
> config: arm-randconfig-r004-20200605 (attached as .config)
> compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
> 6dd738e2f0609f7d3313b574a1d471263d2d3ba1)
> reproduce (this is a W=1 build):
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install arm cross compiling tool for clang build
> # apt-get install binutils-arm-linux-gnueabi
> git checkout 7d16add62717136b1839f0b3d7ea4cbb98f38c2a
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm 
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 

Adding Kefeng on CC.  Kefeng, thoughts?

Thanx, Paul

> All warnings (new ones prefixed by >>, old ones prefixed by <<):
> 
> >> kernel/rcu/rcuperf.c:727:38: warning: format specifies type 'size_t' (aka 
> >> 'unsigned int') but the argument has type 'unsigned long' [-Wformat]
> pr_alert("kfree object size=%zun", kfree_mult * sizeof(struct kfree_obj));
> ~~~ ^
> %lu
> include/linux/printk.h:295:35: note: expanded from macro 'pr_alert'
> printk(KERN_ALERT pr_fmt(fmt), ##__VA_ARGS__)
> ~~~ ^~~
> 1 warning generated.
> 
> vim +727 kernel/rcu/rcuperf.c
> 
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  709) 
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  710) static int __init
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  711) kfree_perf_init(void)
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  712) {
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  713)   long i;
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  714)   int firsterr = 
> 0;
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  715) 
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  716)   
> kfree_nrealthreads = compute_real(kfree_nthreads);
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  717)   /* Start up the 
> kthreads. */
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  718)   if (shutdown) {
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  719)   
> init_waitqueue_head(_wq);
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  720)   
> firsterr = torture_create_kthread(kfree_perf_shutdown, NULL,
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  721)   
>   shutdown_task);
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  722)   if 
> (firsterr)
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  723)   
> goto unwind;
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  724)   
> schedule_timeout_uninterruptible(1);
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  725)   }
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  726) 
> b3e2d20973db3e Kefeng Wang 2020-04-17 @727pr_alert("kfree 
> object size=%zu\n", kfree_mult * sizeof(struct kfree_obj));
> f87dc808009ac8 Joel Fernandes (Google  2020-03-16  728) 
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  729)   
> kfree_reader_tasks = kcalloc(kfree_nrealthreads, 
> sizeof(kfree_reader_tasks[0]),
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  730)   
>GFP_KERNEL);
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  731)   if 
> (kfree_reader_tasks == NULL) {
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  732)   
> firsterr = -ENOMEM;
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  733)   goto 
> unwind;
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  734)   }
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  735) 
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  736)   for (i = 0; i < 
> kfree_nrealthreads; i++) {
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  737)   
> firsterr = torture_create_kthread(kfree_perf_thread, (void *)i,
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  738)   
>   kfree_reader_tasks[i]);
> e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  739)   if 
> (firsterr)
&

Re: [Patch v2] lib: test get_count_order/long in test_bitops.c

On Fri, 5 Jun 2020 23:06:10 + Wei Yang  wrote:

> On Thu, Jun 04, 2020 at 02:51:40PM +0200, Geert Uytterhoeven wrote:
> >Hi Wei,
> >
> >On Thu, Jun 4, 2020 at 2:28 PM Wei Yang  wrote:
> [...]
> >>
> >> You mean
> >>
> >>{0x0003,  2},
> >>{0x0004,  2},
> >>{0x1fff, 13},
> >>{0x2000, 13},
> >>{0x5000, 31},
> >>{0x8000, 31},
> >>{0x80003000, 32},
> >
> >Yes, those values.  And those should work with get_count_order_long()
> >on both 32-bit and 64-bit.

Geert meant "no, the values in order_comb[]" :)

We have a table of numbers in order_comb[] so we may as well feed them
into get_count_order_long() (as well as get_count_order()) just for a
bit more testing.

So how about the below?  order_comb_long[] just can't be used on 32-bit
machines because their longs are 32-bit.  If we had a
get_count_order_u64() then we could use it.

I haven't runtime tested this - could you please do so?


static unsigned int order_comb[][2] = {
{0x0003,  2},
{0x0004,  2},
{0x1fff, 13},
{0x2000, 13},
{0x5000, 31},
{0x8000, 31},
{0x80003000, 32},
};

#ifdef CONFIG_64BIT
static unsigned long order_comb_long[][2] = {
{0x0003, 34},
{0x0004, 34},
{0x1fff, 45},
{0x2000, 45},
{0x5000, 63},
{0x8000, 63},
{0x80003000, 64},
};
#endif

static int __init test_bitops_startup(void)
{
int i;

pr_warn("Loaded test module\n");
set_bit(BITOPS_4, g_bitmap);
set_bit(BITOPS_7, g_bitmap);
set_bit(BITOPS_11, g_bitmap);
set_bit(BITOPS_31, g_bitmap);
set_bit(BITOPS_88, g_bitmap);

for (i = 0; i < ARRAY_SIZE(order_comb); i++) {
if (order_comb[i][1] != get_count_order(order_comb[i][0]))
pr_warn("get_count_order wrong for %x\n",
   order_comb[i][0]);
}

for (i = 0; i < ARRAY_SIZE(order_comb); i++) {
if (order_comb[i][1] != get_count_order_long(order_comb[i][0]))
pr_warn("get_count_order_long wrong for %x\n",
   order_comb[i][0]);
}

#ifdef CONFIG_64BIT
for (i = 0; i < ARRAY_SIZE(order_comb); i++) {
if (order_comb_long[i][1] !=
   get_count_order_long(order_comb_long[i][0]))
pr_warn("get_count_order_long wrong for %lx\n",
   order_comb_long[i][0]);
}
#endif
return 0;
}


From: Andrew Morton 
Subject: lib-test-get_count_order-long-in-test_bitopsc-fix

Cc: Andy Shevchenko 
Cc: Christian Brauner 
Cc: Wei Yang 
Signed-off-by: Andrew Morton 
---

 lib/test_bitops.c |   23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

--- a/lib/test_bitops.c~lib-test-get_count_order-long-in-test_bitopsc-fix
+++ a/lib/test_bitops.c
@@ -28,7 +28,7 @@ enum bitops_fun {
 
 static DECLARE_BITMAP(g_bitmap, BITOPS_LENGTH);
 
-unsigned int order_comb[][2] = {
+static unsigned int order_comb[][2] = {
{0x0003,  2},
{0x0004,  2},
{0x1fff, 13},
@@ -38,7 +38,8 @@ unsigned int order_comb[][2] = {
{0x80003000, 32},
 };
 
-unsigned long order_comb_long[][2] = {
+#ifdef CONFIG_64BIT
+static unsigned long order_comb_long[][2] = {
{0x0003, 34},
{0x0004, 34},
{0x1fff, 45},
@@ -47,6 +48,7 @@ unsigned long order_comb_long[][2] = {
{0x8000, 63},
{0x80003000, 64},
 };
+#endif
 
 static int __init test_bitops_startup(void)
 {
@@ -62,14 +64,23 @@ static int __init test_bitops_startup(vo
for (i = 0; i < ARRAY_SIZE(order_comb); i++) {
if (order_comb[i][1] != get_count_order(order_comb[i][0]))
pr_warn("get_count_order wrong for %x\n",
-  order_comb[i][0]); }
+  order_comb[i][0]);
+   }
 
-   for (i = 0; i < ARRAY_SIZE(order_comb_long); i++) {
+   for (i = 0; i < ARRAY_SIZE(order_comb); i++) {
+   if (order_comb[i][1] != get_count_order_long(order_comb[i][0]))
+   pr_warn("get_count_order_long wrong for %x\n",
+  order_comb[i][0]);
+   }
+
+#ifdef CONFIG_64BIT
+   for (i = 0; i < ARRAY_SIZE(order_comb); i++) {
if (order_comb_long[i][1] !=
   get_count_order_long(order_comb_long[i][0]))
pr_warn("get_count_order_long wrong for %lx\n",
-  order_comb_long[i][0]); }
-
+  order_comb_long[i][0]);
+

Re: [PATCHv9 00/12] PCI: Recode Mobiveil driver and add PCIe Gen4 driver for NXP Layerscape SoCs

2020-06-05 Thread Russell King - ARM Linux admin

On Sat, Feb 29, 2020 at 11:04:56AM +, Russell King - ARM Linux admin wrote:
> Adding Ted and Andreas...
> 
> Here's the debugfs -n "id" output for dpkg.status.5.gz (which is fine,
> and probably a similar size):
> 
> debugfs:  id <917527>
>   a481  30ff 0300 bd8e 475e bd77 4f5e  0.G^.wO^
> 0020  29ca 345e    0100 0002   ).4^
> 0040   0800 0100  0af3 0100 0400   
> 0060      4000  8087 3800  @.8.
> 0100           
> *
> 0140    c40b 4c0a      ..L.
> 0160        3884   8...
> 0200  2000 95f2 44b8 bdc9 a4d2 9883 c861 dc92   ...Da..
> 0220  bd31 4a5e ecc5 260c      .1J^..&.
> 0240           
> *
> 
> and for the affected inode:
> debugfs:  id <917524>
>   a481  30ff 0300 3d3d 465e bd77 4f5e  0...==F^.wO^
> 0020  29ca 345e    0100 0002   ).4^
> 0040   0800 0100  0af3 0100 0400   
> 0060      4000  c088 3800  @.8.
> 0100           
> *
> 0140    5fc4 cfb4      _...
> 0160        af23   .#..
> 0200  2000 1cc3 ac95 c9c8 a4d2 9883 583e addf   ...X>..
> 0220  3de0 485e b04d 7151      =.H^.MqQ
> 0240           
> *
> 
> and "stat" output:
> debugfs:  stat <917527>
> Inode: 917527   Type: regularMode:  0644   Flags: 0x8
> Generation: 172755908Version: 0x:0001
> User: 0   Group: 0   Project: 0   Size: 261936
> File ACL: 0
> Links: 1   Blockcount: 512
> Fragment:  Address: 0Number: 0Size: 0
>  ctime: 0x5e4f77bd:c9bdb844 -- Fri Feb 21 06:25:01 2020
>  atime: 0x5e478ebd:92dc61c8 -- Sat Feb 15 06:25:01 2020
>  mtime: 0x5e34ca29:8398d2a4 -- Sat Feb  1 00:45:29 2020
> crtime: 0x5e4a31bd:0c26c5ec -- Mon Feb 17 06:25:01 2020
> Size of extra inode fields: 32
> Inode checksum: 0xf2958438
> EXTENTS:
> (0-63):3704704-3704767
> debugfs:  stat <917524>
> Inode: 917524   Type: regularMode:  0644   Flags: 0x8
> Generation: 3033515103Version: 0x:0001
> User: 0   Group: 0   Project: 0   Size: 261936
> File ACL: 0
> Links: 1   Blockcount: 512
> Fragment:  Address: 0Number: 0Size: 0
>  ctime: 0x5e4f77bd:c8c995ac -- Fri Feb 21 06:25:01 2020
>  atime: 0x5e463d3d:dfad3e58 -- Fri Feb 14 06:25:01 2020
>  mtime: 0x5e34ca29:8398d2a4 -- Sat Feb  1 00:45:29 2020
> crtime: 0x5e48e03d:51714db0 -- Sun Feb 16 06:25:01 2020
> Size of extra inode fields: 32
> Inode checksum: 0xc31c23af
> EXTENTS:
> (0-63):3705024-3705087
> 
> When using sif (set_inode_info) to re-set the UID to 0 on this (so
> provoke the checksum to be updated):
> 
> debugfs:  id <917524>
>   a481  30ff 0300 3d3d 465e bd77 4f5e  0...==F^.wO^
> 0020  29ca 345e    0100 0002   ).4^
> 0040   0800 0100  0af3 0100 0400   
> 0060      4000  c088 3800  @.8.
> 0100           
> *
> 0140    5fc4 cfb4      _...
> 0160        b61f   
> 
> 0200  2000 aa15 ac95 c9c8 a4d2 9883 583e addf   ...X>..
>
> 0220  3de0 485e b04d 7151      =.H^.MqQ
> 0240           
> *
> 
> The values with "" are the checksum, which are the only values
> that have changed here - the checksum is now 0x15aa1fb6 rather than
> 0xc31c23af.
> 
> With that changed, running e2fsck -n on the filesystem results in a
> pass:
> 
> root@cex7:~# e2fsck -n /dev/nvme0n1p2
> e2fsck 1.44.5 (15-Dec-2018)
> Warning: skipping journal recovery because doing a read-only filesystem check.
> /dev/nvme0n1p2 contains a file system with errors, check forced.
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> /dev/nvme0n1p2: 121163/2097152 files (0.1% non-contiguous), 1349227/8388608 
> blocks
> 
> and the file now appears to be intact (being a gzip file, gzip verifies
> that the contents are now as it expects.)
> 
> So, it looks like the _only_ issue is that the checksum on the inode
> became invalid, which seems to suggest that it *isn't* a NVMe nor PCIe
> issue.
> 
> I wonder whether the journal would contain anything useful, but I don't
> know how to use debugfs to find that out - while I can dump the journal,
> I'd need to know which block

Re: I await your urgent reply.

2020-06-05 Thread John Robinson

-- 
Attention: Please,

I am John Robinson, the Head of file Department in Tesco Bank Plc here
in London United Kingdom. I wish to notify you again that you were
listed as a beneficiary to the total sum of Twelve Million Five
Hundred thousand British pounds in the codicil and last testament of
our deceased customer Late (NAME WITHHELD). I contacted you because
you bear the same surname identity and therefore I can present you as
the beneficiary to the inheritance.

I therefore reckoned that you can receive these funds as you are
qualified by your name identity. I shall provide you with the legal
papers in my possession that you will present to our bank as prove of
your claim for immediate processing of the fund release to you, in
your acceptance to co-operate with me on this deal.

Kindly forward to me your letter of acceptance; your current telephone
and fax numbers and a forwarding address to enable me file in an
application of claim with our bank on your behalf.

Yours Faithfully,
Head of file Department,
John Robinson.
Tel: +447520641086.

Re: [GIT PULL] ext4 changes for 5.8-rc1

2020-06-05 Thread pr-tracker-bot

The pull request you sent on Thu, 4 Jun 2020 19:12:59 -0400:

> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git 
> tags/ext4_for_linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0b166a57e6222666292a481b742af92b50c3ba50

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT PULL] dlm updates for 5.8

2020-06-05 Thread pr-tracker-bot

The pull request you sent on Fri, 5 Jun 2020 13:18:03 -0500:

> git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm.git dlm-5.8

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e3cea0cad147a9ab4f0e74a2fbdf15d18df1f820

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT PULL] afs: Improvements for v5.8

2020-06-05 Thread pr-tracker-bot

The pull request you sent on Thu, 04 Jun 2020 17:58:19 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git 
> tags/afs-next-20200604

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9daa0a27a0bce6596be287fb1df372ff80bb1087

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [PATCH v6 8/8] ima: add FIRMWARE_PARTIAL_READ support

2020-06-05 Thread Mimi Zohar

On Fri, 2020-06-05 at 16:31 -0700, Scott Branden wrote:
> Hi Mimi,
> 
> On 2020-06-05 4:19 p.m., Mimi Zohar wrote:
> > Hi Scott,
> >
> > On Fri, 2020-06-05 at 15:59 -0700, Scott Branden wrote:
> >> @@ -648,6 +667,9 @@ int ima_post_read_file(struct file *file, void *buf, 
> >> loff_t size,
> >>enum ima_hooks func;
> >>u32 secid;
> >>   
> >> +  if (!file && read_id == READING_FIRMWARE_PARTIAL_READ)
> >> +  return 0;
> > The file should be measured on the pre security hook, not here on the
> > post security hook.  Here, whether "file" is defined or not, is
> > irrelevant.  The test should just check "read_id".
> OK, will remove the !file from here.

thanks!

> >
> > Have you tested measuring the firmware by booting a system with
> > "ima_policy=tcb" specified on the boot command line and compared the
> > measurement entry in the IMA measurement list with the file hash (eg.
> > sha1sum, sha256sum)?
> Yes, I enabled IMA in my kernel and added ima_policy=tsb to the boot 
> command line,
> 
> Here are the entries from 
> /sys/kernel/security/ima/ascii_runtime_measurements of the files I am 
> accessing.
> Please let me know if I am doing anything incorrectly.
> 
> 10 4612bce355b2dbc45ecd95e17001636be8832c7f ima-ng 
> sha1:fddd9a28c2b15acf3b0fc9ec0cf187cb2153d7f2 
> /lib/firmware/vk-boot1-bcm958401m2.ecdsa.bin
> 10 4c0eb0fc30eb7ac3a30a27f05c1d2a8d28d6a9ec ima-ng 
> sha1:b16d343dd63352d10309690c71b110762a9444c3 
> /lib/firmware/vk-boot2-bcm958401m2_a72.ecdsn
> 
> The sha1 sum matches:
> root@genericx86-64:/sys/kernel/security/ima# sha1sum 
> /lib/firmware/vk-boot1-bcm958401m2.ecdsa.bin
> fddd9a28c2b15acf3b0fc9ec0cf187cb2153d7f2 
> /lib/firmware/vk-boot1-bcm958401m2.ecdsa.bin
> 
> root@genericx86-64:/sys/kernel/security/ima# sha1sum 
> /lib/firmware/vk-boot2-bcm958401m2_a72.ecdsa.bin
> b16d343dd63352d10309690c71b110762a9444c3 
> /lib/firmware/vk-boot2-bcm958401m2_a72.ecdsa.bin

Looks good!

(FYI, a larger hash algorithm can be specified in the Kconfig or
"ima_hash=" on the boot command line.)

Mimi

Re: [PATCH v2] docs: block: Create blk-mq documentation

2020-06-05 Thread Dongli Zhang

Hi André,

On 6/5/20 10:55 AM, André Almeida wrote:
> Create a documentation providing a background and explanation around the
> operation of the Multi-Queue Block IO Queueing Mechanism (blk-mq).
> 
> The reference for writing this documentation was the source code and
> "Linux Block IO: Introducing Multi-queue SSD Access on Multi-core
> Systems", by Axboe et al.
> 
> Signed-off-by: André Almeida 
> ---
> Changes from v1:
> - Fixed typos
> - Reworked blk_mq_hw_ctx
> 
> Hello,
> 
> This commit was tested using "make htmldocs" and the HTML output has
> been verified.
> 
> Thanks,
>   André
> ---
>  Documentation/block/blk-mq.rst | 154 +
>  Documentation/block/index.rst  |   1 +
>  2 files changed, 155 insertions(+)
>  create mode 100644 Documentation/block/blk-mq.rst
> 
> diff --git a/Documentation/block/blk-mq.rst b/Documentation/block/blk-mq.rst
> new file mode 100644
> index ..1f702adbc577
> --- /dev/null
> +++ b/Documentation/block/blk-mq.rst
> @@ -0,0 +1,154 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +
> +Multi-Queue Block IO Queueing Mechanism (blk-mq)
> +
> +
> +The Multi-Queue Block IO Queueing Mechanism is an API to enable fast storage
> +devices to achieve a huge number of input/output operations per second (IOPS)
> +through queueing and submitting IO requests to block devices simultaneously,
> +benefiting from the parallelism offered by modern storage devices.
> +
> +Introduction
> +
> +
> +Background
> +--
> +
> +Magnetic hard disks have been the de facto standard from the beginning of the
> +development of the kernel. The Block IO subsystem aimed to achieve the best
> +performance possible for those devices with a high penalty when doing random
> +access, and the bottleneck was the mechanical moving parts, a lot more slower
> +than any layer on the storage stack. One example of such optimization 
> technique
> +involves ordering read/write requests accordingly to the current position of
> +the hard disk head.
> +
> +However, with the development of Solid State Drives and Non-Volatile Memories
> +without mechanical parts nor random access penalty and capable of performing
> +high parallel access, the bottleneck of the stack had moved from the storage
> +device to the operating system. In order to  take advantage of the 
> parallelism
> +in those devices design, the multi-queue mechanism was introduced.
> +
> +The former design had a single queue to store block IO requests with a single
> +lock. That did not scale well in SMP systems due to dirty data in cache and 
> the
> +bottleneck of having a single lock for multiple processors. This setup also
> +suffered with congestion when different processes (or the same process, 
> moving
> +to different CPUs) wanted to perform block IO. Instead of this, the blk-mq 
> API
> +spawns multiple queues with individual entry points local to the CPU, 
> removing
> +the need for a lock. A deeper explanation on how this works is covered in the
> +following section (`Operation`_).
> +
> +Operation
> +-
> +
> +When the userspace performs IO to a block device (reading or writing a file,
> +for instance), blk-mq takes action: it will store and manage IO requests to
> +the block device, acting as middleware between the userspace (and a file
> +system, if present) and the block device driver.
> +
> +blk-mq has two group of queues: software staging queues and hardware dispatch
> +queues. When the request arrives at the block layer, it will try the shortest
> +path possible: send it directly to the hardware queue. However, there are two
> +cases that it might not do that: if there's an IO scheduler attached at the
> +layer or if we want to try to merge requests. In both cases, requests will be
> +sent to the software queue.
> +
> +Then, after the requests are processed by software queues, they will be 
> placed
> +at the hardware queue, a second stage queue were the hardware has direct 
> access
> +to process those requests. However, if the hardware does not have enough
> +resources to accept more requests, blk-mq will places requests on a temporary
> +queue, to be sent in the future, when the hardware is able.
> +
> +Software staging queues
> +~~~
> +
> +The block IO subsystem adds requests (represented by struct
> +:c:type:`blk_mq_ctx`) in the software staging queues in case that they 
> weren't
> +sent directly to the driver. A request is a collection of BIOs. They arrived 
> at
> +the block layer through the data structure struct :c:type:`bio`. The block
> +layer will then build a new structure from it, the struct :c:type:`request`
> +that will be used to communicate with the device driver. Each queue has its
> +own lock and the number of queues is defined by a per-CPU or per-node basis.
> +
> +The staging queue can be used to merge requests for adjacent sectors. For
>

[PATCH RT 7/8] mm/zswap: Use local lock to protect per-CPU data

5.4.44-rt27-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Sebastian Andrzej Siewior 

This is an incremental update of the zswap patch. Addtional spots were
identified, which were lacking proper locking, during the rework of the
patch for upstream.
The complete patch description is available as commit
   79410590ae87e ("mm/zswap: Use local lock to protect per-CPU data")

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Steven Rostedt (VMware) 
---
 mm/zswap.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/mm/zswap.c b/mm/zswap.c
index 21d2d3ed3d6d..3c9644b51f3f 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -372,6 +372,8 @@ static struct zswap_entry *zswap_entry_find_get(struct 
rb_root *root,
 * per-cpu code
 **/
 static DEFINE_PER_CPU(u8 *, zswap_dstmem);
+/* Used for zswap_dstmem and tfm */
+static DEFINE_LOCAL_IRQ_LOCK(zswap_cpu_lock);
 
 static int zswap_dstmem_prepare(unsigned int cpu)
 {
@@ -889,10 +891,11 @@ static int zswap_writeback_entry(struct zpool *pool, 
unsigned long handle)
dlen = PAGE_SIZE;
src = (u8 *)zhdr + sizeof(struct zswap_header);
dst = kmap_atomic(page);
-   tfm = *get_cpu_ptr(entry->pool->tfm);
+   local_lock(zswap_cpu_lock);
+   tfm = *this_cpu_ptr(entry->pool->tfm);
ret = crypto_comp_decompress(tfm, src, entry->length,
 dst, );
-   put_cpu_ptr(entry->pool->tfm);
+   local_unlock(zswap_cpu_lock);
kunmap_atomic(dst);
BUG_ON(ret);
BUG_ON(dlen != PAGE_SIZE);
@@ -981,8 +984,6 @@ static void zswap_fill_page(void *ptr, unsigned long value)
memset_l(page, value, PAGE_SIZE / sizeof(unsigned long));
 }
 
-/* protect zswap_dstmem from concurrency */
-static DEFINE_LOCAL_IRQ_LOCK(zswap_dstmem_lock);
 /*
 * frontswap hooks
 **/
@@ -1060,7 +1061,8 @@ static int zswap_frontswap_store(unsigned type, pgoff_t 
offset,
}
 
/* compress */
-   dst = get_locked_var(zswap_dstmem_lock, zswap_dstmem);
+   local_lock(zswap_cpu_lock);
+   dst = *this_cpu_ptr(_dstmem);
tfm = *this_cpu_ptr(entry->pool->tfm);
src = kmap_atomic(page);
ret = crypto_comp_compress(tfm, src, PAGE_SIZE, dst, );
@@ -1088,7 +1090,7 @@ static int zswap_frontswap_store(unsigned type, pgoff_t 
offset,
memcpy(buf, , hlen);
memcpy(buf + hlen, dst, dlen);
zpool_unmap_handle(entry->pool->zpool, handle);
-   put_locked_var(zswap_dstmem_lock, zswap_dstmem);
+   local_unlock(zswap_cpu_lock);
 
/* populate entry */
entry->offset = offset;
@@ -1116,7 +1118,7 @@ static int zswap_frontswap_store(unsigned type, pgoff_t 
offset,
return 0;
 
 put_dstmem:
-   put_locked_var(zswap_dstmem_lock, zswap_dstmem);
+   local_unlock(zswap_cpu_lock);
zswap_pool_put(entry->pool);
 freepage:
zswap_entry_cache_free(entry);
@@ -1161,9 +1163,10 @@ static int zswap_frontswap_load(unsigned type, pgoff_t 
offset,
if (zpool_evictable(entry->pool->zpool))
src += sizeof(struct zswap_header);
dst = kmap_atomic(page);
-   tfm = *get_cpu_ptr(entry->pool->tfm);
+   local_lock(zswap_cpu_lock);
+   tfm = *this_cpu_ptr(entry->pool->tfm);
ret = crypto_comp_decompress(tfm, src, entry->length, dst, );
-   put_cpu_ptr(entry->pool->tfm);
+   local_unlock(zswap_cpu_lock);
kunmap_atomic(dst);
zpool_unmap_handle(entry->pool->zpool, entry->handle);
BUG_ON(ret);
-- 
2.26.2

[PATCH RT 4/8] mm: Dont warn about atomic memory allocations during suspend

5.4.44-rt27-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Liwei Song 

The ACPI code allocates larger amount of memory during resume. This
triggers a warning because the allocation happens with disabled
interrupts.
At this stage only one CPU is active so there should be no lock
contention. If SLUB needs to call into the buddy allocator for more
memory then it should not enable interrupts.

Limit the check to system state with more CPUs and scheduling and only
enable interrupts in SLUB at this stage.

Signed-off-by: Liwei Song 
Signed-off-by: Steven Rostedt (VMware) 
[bigeasy: commit description, allocate_slab() hunk]
Signed-off-by: Sebastian Andrzej Siewior 
---
 mm/slub.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
index 44a602fc8a16..bea18bbae247 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1635,7 +1635,7 @@ static struct page *allocate_slab(struct kmem_cache *s, 
gfp_t flags, int node)
enableirqs = true;
 
 #ifdef CONFIG_PREEMPT_RT
-   if (system_state > SYSTEM_BOOTING)
+   if (system_state > SYSTEM_BOOTING && system_state < SYSTEM_SUSPEND)
enableirqs = true;
 #endif
if (enableirqs)
@@ -2751,7 +2751,8 @@ static __always_inline void *slab_alloc_node(struct 
kmem_cache *s,
unsigned long tid;
 
if (IS_ENABLED(CONFIG_PREEMPT_RT) && 
IS_ENABLED(CONFIG_DEBUG_ATOMIC_SLEEP))
-   WARN_ON_ONCE(!preemptible() && system_state >= 
SYSTEM_SCHEDULING);
+   WARN_ON_ONCE(!preemptible() &&
+(system_state > SYSTEM_BOOTING && system_state < 
SYSTEM_SUSPEND));
 
s = slab_pre_alloc_hook(s, gfpflags);
if (!s)
@@ -3216,7 +3217,8 @@ int kmem_cache_alloc_bulk(struct kmem_cache *s, gfp_t 
flags, size_t size,
int i;
 
if (IS_ENABLED(CONFIG_PREEMPT_RT) && 
IS_ENABLED(CONFIG_DEBUG_ATOMIC_SLEEP))
-   WARN_ON_ONCE(!preemptible() && system_state >= 
SYSTEM_SCHEDULING);
+   WARN_ON_ONCE(!preemptible() &&
+(system_state > SYSTEM_BOOTING && system_state < 
SYSTEM_SUSPEND));
 
/* memcg and kmem_cache debug support */
s = slab_pre_alloc_hook(s, flags);
-- 
2.26.2

[PATCH RT 5/8] mm: slub: Always flush the delayed empty slubs in flush_all()

5.4.44-rt27-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Kevin Hao 

After commit f0b231101c94 ("mm/SLUB: delay giving back empty slubs to
IRQ enabled regions"), when the free_slab() is invoked with the IRQ
disabled, the empty slubs are moved to a per-CPU list and will be
freed after IRQ enabled later. But in the current codes, there is
a check to see if there really has the cpu slub on a specific cpu
before flushing the delayed empty slubs, this may cause a reference
of already released kmem_cache in a scenario like below:
cpu 0   cpu 1
  kmem_cache_destroy()
flush_all()
 --->IPI   flush_cpu_slab()
 flush_slab()
   deactivate_slab()
 discard_slab()
   free_slab()
 c->page = NULL;
  for_each_online_cpu(cpu)
if (!has_cpu_slab(1, s))
  continue
this skip to flush the delayed
empty slub released by cpu1
kmem_cache_free(kmem_cache, s)

   kmalloc()
 __slab_alloc()
free_delayed()
__free_slab()
reference to released kmem_cache

Fixes: f0b231101c94 ("mm/SLUB: delay giving back empty slubs to IRQ enabled 
regions")
Signed-off-by: Kevin Hao 
Signed-off-by: Sebastian Andrzej Siewior 
Cc: stable...@vger.kernel.org
Signed-off-by: Steven Rostedt (VMware) 
---
 mm/slub.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
index bea18bbae247..b2809a9ca8f8 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2382,9 +2382,6 @@ static void flush_all(struct kmem_cache *s)
for_each_online_cpu(cpu) {
struct slub_free_list *f;
 
-   if (!has_cpu_slab(cpu, s))
-   continue;
-
f = _cpu(slub_free_list, cpu);
raw_spin_lock_irq(>lock);
list_splice_init(>list, );
-- 
2.26.2

[PATCH RT 1/8] printk: console must not schedule for drivers

5.4.44-rt27-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: John Ogness 

Even though the printk kthread is always preemptible, it is still not
allowed to call cond_resched() from within console drivers. The
task may become non-preemptible in the console driver call chain. For
example, vt_console_print() takes a spinlock and then can call into
fbcon_redraw(), which can conditionally invoke cond_resched():

|BUG: sleeping function called from invalid context at 
kernel/printk/printk.c:2322
|in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 177, name: printk
|CPU: 0 PID: 177 Comm: printk Not tainted 5.6.2-00011-ga536059557f1d9 #1
|Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
|Call Trace:
| dump_stack+0x66/0x8b
| ___might_sleep+0x102/0x120
| console_conditional_schedule+0x24/0x30
| fbcon_redraw+0x96/0x1c0
| fbcon_scroll+0x556/0xd70
| con_scroll+0x147/0x1e0
| lf+0x9e/0xb0
| vt_console_print+0x253/0x3d0
| printk_kthread_func+0x1d5/0x3b0

Disable cond_resched() for the call into the console drivers.

Reported-by: kernel test robot 
Signed-off-by: John Ogness 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Steven Rostedt (VMware) 
---
 kernel/printk/printk.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 2affe95866a4..9600373bcf55 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2746,6 +2746,7 @@ static int printk_kthread_func(void *data)
, printk_time);
 
console_lock();
+   console_may_schedule = 0;
call_console_drivers(master_seq, ext_text, ext_len, text, len,
 msg->level, msg->facility);
if (len > 0 || ext_len > 0)
-- 
2.26.2

[PATCH RT 2/8] fs/dcache: Include swait.h header

5.4.44-rt27-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Sebastian Andrzej Siewior 

Include the swait.h header so it compiles even if not all patches are
applied.

Reported-by: kbuild test robot 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Steven Rostedt (VMware) 
---
 fs/proc/base.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 2dcd8fb3abb5..dc6cfa5de1df 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -95,6 +95,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "internal.h"
 #include "fd.h"
 
-- 
2.26.2

[PATCH RT 8/8] Linux 5.4.44-rt27-rc1

5.4.44-rt27-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: "Steven Rostedt (VMware)" 

---
 localversion-rt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/localversion-rt b/localversion-rt
index 2e9afd4a0afd..3b0c6038dae9 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt26
+-rt27-rc1
-- 
2.26.2

[PATCH RT 0/8] Linux 5.4.44-rt27-rc1



Dear RT Folks,

This is the RT stable review cycle of patch 5.4.44-rt27-rc1.

Please scream at me if I messed something up. Please test the patches too.

The -rc release will be uploaded to kernel.org and will be deleted when
the final release is out. This is just a review release (or release candidate).

The pre-releases will not be pushed to the git repository, only the
final release is.

If all goes well, this patch will be converted to the next main release
on 6/9/2020.

Enjoy,

-- Steve


To build 5.4.44-rt27-rc1 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v5.x/linux-5.4.tar.xz

  http://www.kernel.org/pub/linux/kernel/v5.x/patch-5.4.44.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/5.4/patch-5.4.44-rt27-rc1.patch.xz

You can also build from 5.4.44-rt26 by applying the incremental patch:

http://www.kernel.org/pub/linux/kernel/projects/rt/5.4/incr/patch-5.4.44-rt26-rt27-rc1.patch.xz


Changes from 5.4.44-rt26:

---


John Ogness (1):
  printk: console must not schedule for drivers

Kevin Hao (1):
  mm: slub: Always flush the delayed empty slubs in flush_all()

Liwei Song (1):
  mm: Don't warn about atomic memory allocations during suspend

Sebastian Andrzej Siewior (3):
  fs/dcache: Include swait.h header
  Revert "rt: Improve the serial console PASS_LIMIT"
  mm/zswap: Use local lock to protect per-CPU data

Steven Rostedt (VMware) (1):
  Linux 5.4.44-rt27-rc1

æ±ªå10269566 (1):
  printk: Force a line break on pr_cont(" ")


 drivers/tty/serial/8250/8250_core.c | 11 +--
 fs/proc/base.c  |  1 +
 kernel/printk/printk.c  |  2 ++
 localversion-rt |  2 +-
 mm/slub.c   | 11 +--
 mm/zswap.c  | 21 -
 6 files changed, 22 insertions(+), 26 deletions(-)

[PATCH RT 3/8] Revert "rt: Improve the serial console PASS_LIMIT"

5.4.44-rt27-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Sebastian Andrzej Siewior 

There is no need to loop for longer. The message of too much work was
removed in commit
9d7c249a1ef9b ("serial: 8250: drop the printk from serial8250_interrupt()")

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Steven Rostedt (VMware) 
---
 drivers/tty/serial/8250/8250_core.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_core.c 
b/drivers/tty/serial/8250/8250_core.c
index 809a65f68028..02bfafa8a672 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -55,16 +55,7 @@ static struct uart_driver serial8250_reg;
 
 static unsigned int skip_txen_test; /* force skip of txen test at init time */
 
-/*
- * On -rt we can have a more delays, and legitimately
- * so - so don't drop work spuriously and spam the
- * syslog:
- */
-#ifdef CONFIG_PREEMPT_RT
-# define PASS_LIMIT100
-#else
-# define PASS_LIMIT512
-#endif
+#define PASS_LIMIT 512
 
 #include 
 /*
-- 
2.26.2

Re: [GIT PULL] afs: Improvements for v5.8

2020-06-05 Thread Linus Torvalds

On Thu, Jun 4, 2020 at 9:58 AM David Howells  wrote:
>
>  (4) Improve Ext4's time updating.  Konstantin Khlebnikov said "For now,
>  I've plugged this issue with try-lock in ext4 lazy time update.  This
>  solution is much better."

It would have been good to get acks on this from the ext4 people, but
I've merged this as-is (but it's still going through my sanity tests,
so if that triggers something it might get unpulled again).

  Linus

Re: [PATCH v6 8/8] ima: add FIRMWARE_PARTIAL_READ support


Hi Mimi,

On 2020-06-05 4:19 p.m., Mimi Zohar wrote:

Hi Scott,

On Fri, 2020-06-05 at 15:59 -0700, Scott Branden wrote:

@@ -648,6 +667,9 @@ int ima_post_read_file(struct file *file, void *buf, loff_t 
size,
enum ima_hooks func;
u32 secid;
  
+	if (!file && read_id == READING_FIRMWARE_PARTIAL_READ)

+   return 0;

The file should be measured on the pre security hook, not here on the
post security hook.  Here, whether "file" is defined or not, is
irrelevant.  The test should just check "read_id".

OK, will remove the !file from here.


Have you tested measuring the firmware by booting a system with
"ima_policy=tcb" specified on the boot command line and compared the
measurement entry in the IMA measurement list with the file hash (eg.
sha1sum, sha256sum)?
Yes, I enabled IMA in my kernel and added ima_policy=tsb to the boot 
command line,


Here are the entries from 
/sys/kernel/security/ima/ascii_runtime_measurements of the files I am 
accessing.

Please let me know if I am doing anything incorrectly.

10 4612bce355b2dbc45ecd95e17001636be8832c7f ima-ng 
sha1:fddd9a28c2b15acf3b0fc9ec0cf187cb2153d7f2 
/lib/firmware/vk-boot1-bcm958401m2.ecdsa.bin
10 4c0eb0fc30eb7ac3a30a27f05c1d2a8d28d6a9ec ima-ng 
sha1:b16d343dd63352d10309690c71b110762a9444c3 
/lib/firmware/vk-boot2-bcm958401m2_a72.ecdsn


The sha1 sum matches:
root@genericx86-64:/sys/kernel/security/ima# sha1sum 
/lib/firmware/vk-boot1-bcm958401m2.ecdsa.bin
fddd9a28c2b15acf3b0fc9ec0cf187cb2153d7f2 
/lib/firmware/vk-boot1-bcm958401m2.ecdsa.bin


root@genericx86-64:/sys/kernel/security/ima# sha1sum 
/lib/firmware/vk-boot2-bcm958401m2_a72.ecdsa.bin
b16d343dd63352d10309690c71b110762a9444c3 
/lib/firmware/vk-boot2-bcm958401m2_a72.ecdsa.bin





Mimi


+
if (!file && read_id == READING_FIRMWARE) {
if ((ima_appraise & IMA_APPRAISE_FIRMWARE) &&
(ima_appraise & IMA_APPRAISE_ENFORCE)) {

[rcu:dev.2020.06.02a 67/90] kernel/rcu/rcuperf.c:727:38: warning: format specifies type 'size_t' (aka 'unsigned int') but the argument has type 'unsigned long'

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
dev.2020.06.02a
head:   5216948905dd07a84cef8a7dc72c2ec076802efd
commit: 7d16add62717136b1839f0b3d7ea4cbb98f38c2a [67/90] rcuperf: Fix 
kfree_mult to match printk() format
config: arm-randconfig-r004-20200605 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
6dd738e2f0609f7d3313b574a1d471263d2d3ba1)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm cross compiling tool for clang build
# apt-get install binutils-arm-linux-gnueabi
git checkout 7d16add62717136b1839f0b3d7ea4cbb98f38c2a
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>, old ones prefixed by <<):

>> kernel/rcu/rcuperf.c:727:38: warning: format specifies type 'size_t' (aka 
>> 'unsigned int') but the argument has type 'unsigned long' [-Wformat]
pr_alert("kfree object size=%zun", kfree_mult * sizeof(struct kfree_obj));
~~~ ^
%lu
include/linux/printk.h:295:35: note: expanded from macro 'pr_alert'
printk(KERN_ALERT pr_fmt(fmt), ##__VA_ARGS__)
~~~ ^~~
1 warning generated.

vim +727 kernel/rcu/rcuperf.c

e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  709) 
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  710) static int __init
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  711) kfree_perf_init(void)
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  712) {
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  713) long i;
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  714) int firsterr = 
0;
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  715) 
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  716) 
kfree_nrealthreads = compute_real(kfree_nthreads);
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  717) /* Start up the 
kthreads. */
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  718) if (shutdown) {
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  719) 
init_waitqueue_head(_wq);
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  720) 
firsterr = torture_create_kthread(kfree_perf_shutdown, NULL,
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  721) 
  shutdown_task);
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  722) if 
(firsterr)
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  723) 
goto unwind;
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  724) 
schedule_timeout_uninterruptible(1);
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  725) }
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  726) 
b3e2d20973db3e Kefeng Wang 2020-04-17 @727  pr_alert("kfree 
object size=%zu\n", kfree_mult * sizeof(struct kfree_obj));
f87dc808009ac8 Joel Fernandes (Google  2020-03-16  728) 
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  729) 
kfree_reader_tasks = kcalloc(kfree_nrealthreads, sizeof(kfree_reader_tasks[0]),
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  730) 
   GFP_KERNEL);
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  731) if 
(kfree_reader_tasks == NULL) {
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  732) 
firsterr = -ENOMEM;
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  733) goto 
unwind;
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  734) }
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  735) 
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  736) for (i = 0; i < 
kfree_nrealthreads; i++) {
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  737) 
firsterr = torture_create_kthread(kfree_perf_thread, (void *)i,
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  738) 
  kfree_reader_tasks[i]);
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  739) if 
(firsterr)
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  740) 
goto unwind;
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  741) }
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  742) 
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  743) while 
(atomic_read(_kfree_perf_thread_started) < kfree_nrealthreads)
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  744) 
schedule_timeout_uninterruptible(1);
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  745) 
e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  746

Re: [PATCH v6 8/8] ima: add FIRMWARE_PARTIAL_READ support

2020-06-05 Thread Mimi Zohar

Hi Scott,

On Fri, 2020-06-05 at 15:59 -0700, Scott Branden wrote:
> 
> @@ -648,6 +667,9 @@ int ima_post_read_file(struct file *file, void *buf, 
> loff_t size,
>   enum ima_hooks func;
>   u32 secid;
>  
> + if (!file && read_id == READING_FIRMWARE_PARTIAL_READ)
> + return 0;

The file should be measured on the pre security hook, not here on the
post security hook.  Here, whether "file" is defined or not, is
irrelevant.  The test should just check "read_id".

Have you tested measuring the firmware by booting a system with
"ima_policy=tcb" specified on the boot command line and compared the
measurement entry in the IMA measurement list with the file hash (eg.
sha1sum, sha256sum)?

Mimi

> +
>   if (!file && read_id == READING_FIRMWARE) {
>   if ((ima_appraise & IMA_APPRAISE_FIRMWARE) &&
>   (ima_appraise & IMA_APPRAISE_ENFORCE)) {

Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU

2020-06-05 Thread Bjorn Helgaas

On Thu, Jun 04, 2020 at 09:33:07PM +0800, Zhangfei Gao wrote:
> On 2020/6/2 上午1:41, Bjorn Helgaas wrote:
> > On Thu, May 28, 2020 at 09:33:44AM +0200, Joerg Roedel wrote:
> > > On Wed, May 27, 2020 at 01:18:42PM -0500, Bjorn Helgaas wrote:
> > > > Is this slowdown significant?  We already iterate over every device
> > > > when applying PCI_FIXUP_FINAL quirks, so if we used the existing
> > > > PCI_FIXUP_FINAL, we wouldn't be adding a new loop.  We would only be
> > > > adding two more iterations to the loop in pci_do_fixups() that tries
> > > > to match quirks against the current device.  I doubt that would be a
> > > > measurable slowdown.
> > > I don't know how significant it is, but I remember people complaining
> > > about adding new PCI quirks because it takes too long for them to run
> > > them all. That was in the discussion about the quirk disabling ATS on
> > > AMD Stoney systems.
> > > 
> > > So it probably depends on how many PCI devices are in the system whether
> > > it causes any measureable slowdown.
> > I found this [1] from Paul Menzel, which was a slowdown caused by
> > quirk_usb_early_handoff().  I think the real problem is individual
> > quirks that take a long time.
> > 
> > The PCI_FIXUP_IOMMU things we're talking about should be fast, and of
> > course, they're only run for matching devices anyway.  So I'd rather
> > keep them as PCI_FIXUP_FINAL than add a whole new phase.
> > 
> Thanks Bjorn for taking time for this.
> If so, it would be much simpler.
> 
> +++ b/drivers/iommu/iommu.c
> @@ -2418,6 +2418,10 @@ int iommu_fwspec_init(struct device *dev, struct
> fwnode_handle *iommu_fwnode,
>     fwspec->iommu_fwnode = iommu_fwnode;
>     fwspec->ops = ops;
>     dev_iommu_fwspec_set(dev, fwspec);
> +
> +   if (dev_is_pci(dev))
> +   pci_fixup_device(pci_fixup_final, to_pci_dev(dev));
> +
> 
> Then pci_fixup_final will be called twice, the first in pci_bus_add_device.
> Here in iommu_fwspec_init is the second time, specifically for iommu_fwspec.
> Will send this when 5.8-rc1 is open.

Wait, this whole fixup approach seems wrong to me.  No matter how you
do the fixup, it's still a fixup, which means it requires ongoing
maintenance.  Surely we don't want to have to add the Vendor/Device ID
for every new AMBA device that comes along, do we?

Bjorn

Re: [PATCH] power: reset: gpio-poweroff: add missing '\n' in dev_err()

Hi,

On Wed, Jun 03, 2020 at 06:21:18PM +0200, Luca Ceresoli wrote:
> dev_err() needs a terminating newline.
> 
> Signed-off-by: Luca Ceresoli 
> ---

Thanks, queued.

-- Sebastian

>  drivers/power/reset/gpio-poweroff.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/power/reset/gpio-poweroff.c 
> b/drivers/power/reset/gpio-poweroff.c
> index 6a4bbb506551..c5067eb75370 100644
> --- a/drivers/power/reset/gpio-poweroff.c
> +++ b/drivers/power/reset/gpio-poweroff.c
> @@ -54,7 +54,7 @@ static int gpio_poweroff_probe(struct platform_device *pdev)
>   /* If a pm_power_off function has already been added, leave it alone */
>   if (pm_power_off != NULL) {
>   dev_err(>dev,
> - "%s: pm_power_off function already registered",
> + "%s: pm_power_off function already registered\n",
>  __func__);
>   return -EBUSY;
>   }
> -- 
> 2.26.2
> 


signature.asc
Description: PGP signature

[PATCHv2 2/2] power: supply: sbs-battery: add PEC support

SBS batteries optionally have support for PEC. This enables
PEC handling based on the implemented SBS version as suggested
by the standard. The support for PEC is re-evaluated when the
battery is hotplugged into the system, since there might be
systems supporting batteries from different SBS generations.

Signed-off-by: Sebastian Reichel 
---
 drivers/power/supply/sbs-battery.c | 64 --
 1 file changed, 61 insertions(+), 3 deletions(-)

diff --git a/drivers/power/supply/sbs-battery.c 
b/drivers/power/supply/sbs-battery.c
index 74221b9279a9..49c3508a6b79 100644
--- a/drivers/power/supply/sbs-battery.c
+++ b/drivers/power/supply/sbs-battery.c
@@ -51,6 +51,14 @@ enum {
REG_CHARGE_VOLTAGE,
 };
 
+#define REG_ADDR_SPEC_INFO 0x1A
+#define SPEC_INFO_VERSION_MASK GENMASK(7, 4)
+#define SPEC_INFO_VERSION_SHIFT4
+
+#define SBS_VERSION_1_01
+#define SBS_VERSION_1_12
+#define SBS_VERSION_1_1_WITH_PEC   3
+
 #define REG_ADDR_MANUFACTURE_DATE  0x1B
 
 /* Battery Mode defines */
@@ -224,14 +232,57 @@ static void sbs_disable_charger_broadcasts(struct 
sbs_info *chip)
 
 static int sbs_update_presence(struct sbs_info *chip, bool is_present)
 {
+   struct i2c_client *client = chip->client;
+   int retries = chip->i2c_retry_count;
+   s32 ret = 0;
+   u8 version;
+
if (chip->is_present == is_present)
return 0;
 
if (!is_present) {
chip->is_present = false;
+   /* Disable PEC when no device is present */
+   client->flags &= ~I2C_CLIENT_PEC;
return 0;
}
 
+   /* Check if device supports packet error checking and use it */
+   while (retries > 0) {
+   ret = i2c_smbus_read_word_data(client, REG_ADDR_SPEC_INFO);
+   if (ret >= 0)
+   break;
+
+   /*
+* Some batteries trigger the detection pin before the
+* I2C bus is properly connected. This works around the
+* issue.
+*/
+   msleep(100);
+
+   retries--;
+   }
+
+   if (ret < 0) {
+   dev_dbg(>dev, "failed to read spec info: %d\n", ret);
+
+   /* fallback to old behaviour */
+   client->flags &= ~I2C_CLIENT_PEC;
+   chip->is_present = true;
+
+   return ret;
+   }
+
+   version = (ret & SPEC_INFO_VERSION_MASK) >> SPEC_INFO_VERSION_SHIFT;
+
+   if (version == SBS_VERSION_1_1_WITH_PEC)
+   client->flags |= I2C_CLIENT_PEC;
+   else
+   client->flags &= ~I2C_CLIENT_PEC;
+
+   dev_dbg(>dev, "PEC: %s\n", (client->flags & I2C_CLIENT_PEC) ?
+   "enabled" : "disabled");
+
if (!chip->is_present && is_present && !chip->charger_broadcasts)
sbs_disable_charger_broadcasts(chip);
 
@@ -273,7 +324,8 @@ static int sbs_read_string_data_fallback(struct i2c_client 
*client, u8 address,
retries_length = chip->i2c_retry_count;
retries_block = chip->i2c_retry_count;
 
-   dev_warn_once(>dev, "I2C adapter does not support 
I2C_FUNC_SMBUS_READ_BLOCK_DATA.\n");
+   dev_warn_once(>dev, "I2C adapter does not support 
I2C_FUNC_SMBUS_READ_BLOCK_DATA.\n"
+   "Fallback method does not support PEC.\n");
 
/* Adapter needs to support these two functions */
if (!i2c_check_functionality(client->adapter,
@@ -336,8 +388,14 @@ static int sbs_read_string_data(struct i2c_client *client, 
u8 address, char *val
int retries = chip->i2c_retry_count;
int ret = 0;
 
-   if (!i2c_check_functionality(client->adapter, 
I2C_FUNC_SMBUS_READ_BLOCK_DATA))
-   return sbs_read_string_data_fallback(client, address, values);
+   if (!i2c_check_functionality(client->adapter, 
I2C_FUNC_SMBUS_READ_BLOCK_DATA)) {
+   bool pec = client->flags & I2C_CLIENT_PEC;
+   client->flags &= ~I2C_CLIENT_PEC;
+   ret = sbs_read_string_data_fallback(client, address, values);
+   if (pec)
+   client->flags |= I2C_CLIENT_PEC;
+   return ret;
+   }
 
while (retries > 0) {
ret = i2c_smbus_read_block_data(client, address, values);
-- 
2.26.2

[PATCHv2 0/2] SBS battery PEC support

Hi,

Second try to enable PEC for SBS battery. Mainline currently
has 3 different platforms using sbs-battery with an I2C driver
not implementing I2C_M_RECV_LEN:

 * i2c-exynos5
 * i2c-rk3x
 * i2c-tegra

On those platforms PEC will be temporarly disabled for SBS
functions requesting strings. I considered moving the emulation
to I2C core, but it's specific to the SBS battery. The hack
only works because the strings are constant.

Changes since PATCHv1:
 * dropped all applied changes
 * rebased on top of power-supply's for-next branch
 * keep existing string reading method as fallback

-- Sebastian

Sebastian Reichel (2):
  power: supply: sbs-battery: use i2c_smbus_read_block_data()
  power: supply: sbs-battery: add PEC support"

 drivers/power/supply/sbs-battery.c | 89 +-
 1 file changed, 87 insertions(+), 2 deletions(-)

-- 
2.26.2

Re: [Patch v2] lib: test get_count_order/long in test_bitops.c

2020-06-05 Thread Wei Yang

On Thu, Jun 04, 2020 at 02:51:40PM +0200, Geert Uytterhoeven wrote:
>Hi Wei,
>
>On Thu, Jun 4, 2020 at 2:28 PM Wei Yang  wrote:
[...]
>>
>> You mean
>>
>>{0x0003,  2},
>>{0x0004,  2},
>>{0x1fff, 13},
>>{0x2000, 13},
>>{0x5000, 31},
>>{0x8000, 31},
>>{0x80003000, 32},
>
>Yes, those values.  And those should work with get_count_order_long()
>on both 32-bit and 64-bit.

Hi, Geert

To be frank, I am afraid I lack some of the skill to achieve this. Maybe you
could give some guide.

get_count_order_long() takes one parameter, which is of type unsigned long.
This one has different size on 32bit and 64bit platform. On 32bit platform,
those value would be truncated.

Would you mind giving me a hint on this?

What we may achieve is like the implementation of fls_long(). This one check
the size of unsigned long on running, and choose different function. We could
use ifdef to check the size of unsigned long and use different data to feed
get_count_order_long(). But I don't find a way to feed get_count_order_long()
with 64bit data on 32bit platform.

>
>Gr{oetje,eeting}s,
>
>Geert
>
>-- 
>Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
>
>In personal conversations with technical people, I call myself a hacker. But
>when I'm talking to journalists I just say "programmer" or something like that.
>-- Linus Torvalds

-- 
Wei Yang
Help you, Help me

[PATCHv2 1/2] power: supply: sbs-battery: use i2c_smbus_read_block_data()

The SBS battery implements SMBus block reads. Currently the
driver "emulates" this by doing an I2C byte read for the
length followed by an I2C block read. The I2C subsystem
actually provides a proper API for doing SMBus block reads,
which can and should be used instead. The current implementation
does not properly handle packet error checking (PEC).

Not all upstream systems using sbs-battery have I2C bus drivers
supporting I2C_M_RECV_LEN, so old implementation is kept as
fallback to keep things working. But this prints a warning,
which hopefully results in people implementing support for it.

Signed-off-by: Sebastian Reichel 
---
 drivers/power/supply/sbs-battery.c | 31 --
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/power/supply/sbs-battery.c 
b/drivers/power/supply/sbs-battery.c
index 83b9924033bd..74221b9279a9 100644
--- a/drivers/power/supply/sbs-battery.c
+++ b/drivers/power/supply/sbs-battery.c
@@ -263,8 +263,7 @@ static int sbs_read_word_data(struct i2c_client *client, u8 
address)
return ret;
 }
 
-static int sbs_read_string_data(struct i2c_client *client, u8 address,
-   char *values)
+static int sbs_read_string_data_fallback(struct i2c_client *client, u8 
address, char *values)
 {
struct sbs_info *chip = i2c_get_clientdata(client);
s32 ret = 0, block_length = 0;
@@ -274,6 +273,8 @@ static int sbs_read_string_data(struct i2c_client *client, 
u8 address,
retries_length = chip->i2c_retry_count;
retries_block = chip->i2c_retry_count;
 
+   dev_warn_once(>dev, "I2C adapter does not support 
I2C_FUNC_SMBUS_READ_BLOCK_DATA.\n");
+
/* Adapter needs to support these two functions */
if (!i2c_check_functionality(client->adapter,
 I2C_FUNC_SMBUS_BYTE_DATA |
@@ -329,6 +330,32 @@ static int sbs_read_string_data(struct i2c_client *client, 
u8 address,
return ret;
 }
 
+static int sbs_read_string_data(struct i2c_client *client, u8 address, char 
*values)
+{
+   struct sbs_info *chip = i2c_get_clientdata(client);
+   int retries = chip->i2c_retry_count;
+   int ret = 0;
+
+   if (!i2c_check_functionality(client->adapter, 
I2C_FUNC_SMBUS_READ_BLOCK_DATA))
+   return sbs_read_string_data_fallback(client, address, values);
+
+   while (retries > 0) {
+   ret = i2c_smbus_read_block_data(client, address, values);
+   if (ret >= 0)
+   break;
+   retries--;
+   }
+
+   if (ret < 0) {
+   dev_dbg(>dev, "failed to read block 0x%x: %d\n", 
address, ret);
+   return ret;
+   }
+
+   /* add string termination */
+   values[ret] = '\0';
+   return ret;
+}
+
 static int sbs_write_word_data(struct i2c_client *client, u8 address,
u16 value)
 {
-- 
2.26.2

Re: [PATCHSET v5 0/12] Add support for async buffered reads

2020-06-05 Thread Andres Freund

Hi,

On 2020-06-05 16:56:44 -0600, Jens Axboe wrote:
> On 6/5/20 4:54 PM, Andres Freund wrote:
> > On 2020-06-05 16:49:24 -0600, Jens Axboe wrote:
> >> Yes that's expected, if we have to fallback to ->readpage(), then it'll
> >> go to a worker. read-ahead is what drives the async nature of it, as we
> >> issue the range (plus more, depending on RA window) as read-ahead for
> >> the normal read, then wait for it.
> > 
> > But I assume async would still work for files with POSIX_FADV_RANDOM
> > set, or not? Assuming the system wide setting isn't zero, of course.
> 
> Yes it'll work if FADV_RANDOM is set.

Cool.


> But just not if read-ahead is totally disabled. I guess we could make
> that work too, though not sure that it's super important.

It's not from my end. I was just trying to check if the reduced
performance I saw was related to interactions between PG prefetching and
kernel level prefetching. And changing the /sys entry seemed easier than
making postgres set POSIX_FADV_RANDOM...

Greetings,

Andres Freund

[PATCH v6 5/8] bcm-vk: add bcm_vk UAPI

Add user space api for bcm-vk driver.

Signed-off-by: Scott Branden 
---
 include/uapi/linux/misc/bcm_vk.h | 99 
 1 file changed, 99 insertions(+)
 create mode 100644 include/uapi/linux/misc/bcm_vk.h

diff --git a/include/uapi/linux/misc/bcm_vk.h b/include/uapi/linux/misc/bcm_vk.h
new file mode 100644
index ..783087b7c31f
--- /dev/null
+++ b/include/uapi/linux/misc/bcm_vk.h
@@ -0,0 +1,99 @@
+/* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR 
BSD-2-Clause) */
+/*
+ * Copyright 2018-2020 Broadcom.
+ */
+
+#ifndef __UAPI_LINUX_MISC_BCM_VK_H
+#define __UAPI_LINUX_MISC_BCM_VK_H
+
+#include 
+#include 
+
+#define BCM_VK_MAX_FILENAME 64
+
+struct vk_image {
+   __u32 type; /* Type of image */
+#define VK_IMAGE_TYPE_BOOT1 1 /* 1st stage (load to SRAM) */
+#define VK_IMAGE_TYPE_BOOT2 2 /* 2nd stage (load to DDR) */
+   char filename[BCM_VK_MAX_FILENAME]; /* Filename of image */
+};
+
+struct vk_reset {
+   __u32 arg1;
+   __u32 arg2;
+};
+
+#define VK_MAGIC   0x5e
+
+/* Load image to Valkyrie */
+#define VK_IOCTL_LOAD_IMAGE_IOW(VK_MAGIC, 0x2, struct vk_image)
+
+/* Send Reset to Valkyrie */
+#define VK_IOCTL_RESET _IOW(VK_MAGIC, 0x4, struct vk_reset)
+
+/*
+ * message block - basic unit in the message where a message's size is always
+ *N x sizeof(basic_block)
+ */
+struct vk_msg_blk {
+   __u8 function_id;
+#define VK_FID_TRANS_BUF   5
+#define VK_FID_SHUTDOWN8
+   __u8 size;
+   __u16 trans_id; /* transport id, queue & msg_id */
+   __u32 context_id;
+   __u32 args[2];
+#define VK_CMD_PLANES_MASK 0x000f /* number of planes to up/download */
+#define VK_CMD_UPLOAD  0x0400 /* memory transfer to vk */
+#define VK_CMD_DOWNLOAD0x0500 /* memory transfer from vk */
+#define VK_CMD_MASK0x0f00 /* command mask */
+};
+
+#define VK_BAR_FWSTS   0x41c
+#define VK_BAR_COP_FWSTS   0x428
+/* VK_FWSTS definitions */
+#define VK_FWSTS_RELOCATION_ENTRY  BIT(0)
+#define VK_FWSTS_RELOCATION_EXIT   BIT(1)
+#define VK_FWSTS_INIT_STARTBIT(2)
+#define VK_FWSTS_ARCH_INIT_DONEBIT(3)
+#define VK_FWSTS_PRE_KNL1_INIT_DONEBIT(4)
+#define VK_FWSTS_PRE_KNL2_INIT_DONEBIT(5)
+#define VK_FWSTS_POST_KNL_INIT_DONEBIT(6)
+#define VK_FWSTS_INIT_DONE BIT(7)
+#define VK_FWSTS_APP_INIT_STARTBIT(8)
+#define VK_FWSTS_APP_INIT_DONE BIT(9)
+#define VK_FWSTS_MASK  0x
+#define VK_FWSTS_READY (VK_FWSTS_INIT_START | \
+VK_FWSTS_ARCH_INIT_DONE | \
+VK_FWSTS_PRE_KNL1_INIT_DONE | \
+VK_FWSTS_PRE_KNL2_INIT_DONE | \
+VK_FWSTS_POST_KNL_INIT_DONE | \
+VK_FWSTS_INIT_DONE | \
+VK_FWSTS_APP_INIT_START | \
+VK_FWSTS_APP_INIT_DONE)
+/* Deinit */
+#define VK_FWSTS_APP_DEINIT_START  BIT(23)
+#define VK_FWSTS_APP_DEINIT_DONE   BIT(24)
+#define VK_FWSTS_DRV_DEINIT_START  BIT(25)
+#define VK_FWSTS_DRV_DEINIT_DONE   BIT(26)
+#define VK_FWSTS_RESET_DONEBIT(27)
+#define VK_FWSTS_DEINIT_TRIGGERED  (VK_FWSTS_APP_DEINIT_START | \
+VK_FWSTS_APP_DEINIT_DONE  | \
+VK_FWSTS_DRV_DEINIT_START | \
+VK_FWSTS_DRV_DEINIT_DONE)
+/* Last nibble for reboot reason */
+#define VK_FWSTS_RESET_REASON_SHIFT28
+#define VK_FWSTS_RESET_REASON_MASK (0xf << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_SYS_PWRUP   (0x0 << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_MBOX_DB (0x1 << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_M7_WDOG (0x2 << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_TEMP(0x3 << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_PCI_FLR (0x4 << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_PCI_HOT (0x5 << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_PCI_WARM(0x6 << 
VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_PCI_COLD(0x7 << 
VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_L1  (0x8 << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_L0  (0x9 << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_UNKNOWN (0xf << VK_FWSTS_RESET_REASON_SHIFT)
+
+#endif /* __UAPI_LINUX_MISC_BCM_VK_H */
-- 
2.17.1

[PATCH v6 8/8] ima: add FIRMWARE_PARTIAL_READ support