[PATCH v4 07/17] fs/kernel_read_file: Switch buffer size arg to size_t

2020-07-29 Thread Kees Cook
In preparation for further refactoring of kernel_read_file*(), rename
the "max_size" argument to the more accurate "buf_size", and correct
its type to size_t. Add kerndoc to explain the specifics of how the
arguments will be used. Note that with buf_size now size_t, it can no
longer be negative (and was never called with a negative value). Adjust
callers to use it as a "maximum size" when *buf is NULL.

Acked-by: Scott Branden 
Reviewed-by: Mimi Zohar 
Reviewed-by: Luis Chamberlain 
Signed-off-by: Kees Cook 
---
 fs/kernel_read_file.c| 34 +++-
 include/linux/kernel_read_file.h |  8 
 security/integrity/digsig.c  |  2 +-
 security/integrity/ima/ima_fs.c  |  2 +-
 4 files changed, 31 insertions(+), 15 deletions(-)

diff --git a/fs/kernel_read_file.c b/fs/kernel_read_file.c
index dc28a8def597..e21a76001fff 100644
--- a/fs/kernel_read_file.c
+++ b/fs/kernel_read_file.c
@@ -5,15 +5,31 @@
 #include 
 #include 
 
+/**
+ * kernel_read_file() - read file contents into a kernel buffer
+ *
+ * @file   file to read from
+ * @bufpointer to a "void *" buffer for reading into (if
+ * *@buf is NULL, a buffer will be allocated, and
+ * @buf_size will be ignored)
+ * @buf_size   size of buf, if already allocated. If @buf not
+ * allocated, this is the largest size to allocate.
+ * @id the kernel_read_file_id identifying the type of
+ * file contents being read (for LSMs to examine)
+ *
+ * Returns number of bytes read (no single read will be bigger
+ * than INT_MAX), or negative on error.
+ *
+ */
 int kernel_read_file(struct file *file, void **buf,
-loff_t max_size, enum kernel_read_file_id id)
+size_t buf_size, enum kernel_read_file_id id)
 {
loff_t i_size, pos;
ssize_t bytes = 0;
void *allocated = NULL;
int ret;
 
-   if (!S_ISREG(file_inode(file)->i_mode) || max_size < 0)
+   if (!S_ISREG(file_inode(file)->i_mode))
return -EINVAL;
 
ret = deny_write_access(file);
@@ -29,7 +45,7 @@ int kernel_read_file(struct file *file, void **buf,
ret = -EINVAL;
goto out;
}
-   if (i_size > INT_MAX || (max_size > 0 && i_size > max_size)) {
+   if (i_size > INT_MAX || i_size > buf_size) {
ret = -EFBIG;
goto out;
}
@@ -75,7 +91,7 @@ int kernel_read_file(struct file *file, void **buf,
 EXPORT_SYMBOL_GPL(kernel_read_file);
 
 int kernel_read_file_from_path(const char *path, void **buf,
-  loff_t max_size, enum kernel_read_file_id id)
+  size_t buf_size, enum kernel_read_file_id id)
 {
struct file *file;
int ret;
@@ -87,14 +103,14 @@ int kernel_read_file_from_path(const char *path, void 
**buf,
if (IS_ERR(file))
return PTR_ERR(file);
 
-   ret = kernel_read_file(file, buf, max_size, id);
+   ret = kernel_read_file(file, buf, buf_size, id);
fput(file);
return ret;
 }
 EXPORT_SYMBOL_GPL(kernel_read_file_from_path);
 
 int kernel_read_file_from_path_initns(const char *path, void **buf,
- loff_t max_size,
+ size_t buf_size,
  enum kernel_read_file_id id)
 {
struct file *file;
@@ -113,13 +129,13 @@ int kernel_read_file_from_path_initns(const char *path, 
void **buf,
if (IS_ERR(file))
return PTR_ERR(file);
 
-   ret = kernel_read_file(file, buf, max_size, id);
+   ret = kernel_read_file(file, buf, buf_size, id);
fput(file);
return ret;
 }
 EXPORT_SYMBOL_GPL(kernel_read_file_from_path_initns);
 
-int kernel_read_file_from_fd(int fd, void **buf, loff_t max_size,
+int kernel_read_file_from_fd(int fd, void **buf, size_t buf_size,
 enum kernel_read_file_id id)
 {
struct fd f = fdget(fd);
@@ -128,7 +144,7 @@ int kernel_read_file_from_fd(int fd, void **buf, loff_t 
max_size,
if (!f.file)
goto out;
 
-   ret = kernel_read_file(f.file, buf, max_size, id);
+   ret = kernel_read_file(f.file, buf, buf_size, id);
 out:
fdput(f);
return ret;
diff --git a/include/linux/kernel_read_file.h b/include/linux/kernel_read_file.h
index 0ca0bdbed1bd..910039e7593e 100644
--- a/include/linux/kernel_read_file.h
+++ b/include/linux/kernel_read_file.h
@@ -36,16 +36,16 @@ static inline const char *kernel_read_file_id_str(enum 
kernel_read_file_id id)
 }
 
 int kernel_read_file(struct file *file,
-void **buf, loff_t max_size,
+void **buf, size_t buf_size,
 enum kernel_read_file_id id);
 int kernel_read_file_from_path(const char *path,
-  void **buf, loff_t max_size,
+  void **buf, size_t 

[PATCH v4 06/17] fs/kernel_read_file: Remove redundant size argument

2020-07-29 Thread Kees Cook
In preparation for refactoring kernel_read_file*(), remove the redundant
"size" argument which is not needed: it can be included in the return
code, with callers adjusted. (VFS reads already cannot be larger than
INT_MAX.)

Acked-by: Scott Branden 
Reviewed-by: Mimi Zohar 
Reviewed-by: Luis Chamberlain 
Signed-off-by: Kees Cook 
---
 drivers/base/firmware_loader/main.c | 10 ++
 fs/kernel_read_file.c   | 20 +---
 include/linux/kernel_read_file.h|  8 
 kernel/kexec_file.c | 14 +++---
 kernel/module.c |  7 +++
 security/integrity/digsig.c |  5 +++--
 security/integrity/ima/ima_fs.c |  6 --
 7 files changed, 36 insertions(+), 34 deletions(-)

diff --git a/drivers/base/firmware_loader/main.c 
b/drivers/base/firmware_loader/main.c
index 7fd677281806..9b425437afe6 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -462,7 +462,7 @@ fw_get_filesystem_firmware(struct device *device, struct 
fw_priv *fw_priv,
 size_t in_size,
 const void *in_buffer))
 {
-   loff_t size;
+   size_t size;
int i, len;
int rc = -ENOENT;
char *path;
@@ -494,10 +494,9 @@ 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,
+   rc = kernel_read_file_from_path_initns(path, , msize,
   READING_FIRMWARE);
-   if (rc) {
+   if (rc < 0) {
if (rc != -ENOENT)
dev_warn(device, "loading %s failed with error 
%d\n",
 path, rc);
@@ -506,6 +505,9 @@ fw_get_filesystem_firmware(struct device *device, struct 
fw_priv *fw_priv,
 path);
continue;
}
+   size = rc;
+   rc = 0;
+
dev_dbg(device, "Loading firmware from %s\n", path);
if (decompress) {
dev_dbg(device, "f/w decompressing %s\n",
diff --git a/fs/kernel_read_file.c b/fs/kernel_read_file.c
index 54d972d4befc..dc28a8def597 100644
--- a/fs/kernel_read_file.c
+++ b/fs/kernel_read_file.c
@@ -5,7 +5,7 @@
 #include 
 #include 
 
-int kernel_read_file(struct file *file, void **buf, loff_t *size,
+int kernel_read_file(struct file *file, void **buf,
 loff_t max_size, enum kernel_read_file_id id)
 {
loff_t i_size, pos;
@@ -29,7 +29,7 @@ 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)) {
+   if (i_size > INT_MAX || (max_size > 0 && i_size > max_size)) {
ret = -EFBIG;
goto out;
}
@@ -59,8 +59,6 @@ int kernel_read_file(struct file *file, void **buf, loff_t 
*size,
}
 
ret = security_kernel_post_read_file(file, *buf, i_size, id);
-   if (!ret)
-   *size = pos;
 
 out_free:
if (ret < 0) {
@@ -72,11 +70,11 @@ int kernel_read_file(struct file *file, void **buf, loff_t 
*size,
 
 out:
allow_write_access(file);
-   return ret;
+   return ret == 0 ? pos : ret;
 }
 EXPORT_SYMBOL_GPL(kernel_read_file);
 
-int kernel_read_file_from_path(const char *path, void **buf, loff_t *size,
+int kernel_read_file_from_path(const char *path, void **buf,
   loff_t max_size, enum kernel_read_file_id id)
 {
struct file *file;
@@ -89,14 +87,14 @@ 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_read_file(file, buf, max_size, id);
fput(file);
return ret;
 }
 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,
+ loff_t max_size,
  enum kernel_read_file_id id)
 {
struct file *file;
@@ -115,13 +113,13 @@ int kernel_read_file_from_path_initns(const char *path, 
void **buf,
if (IS_ERR(file))
return PTR_ERR(file);
 
-   ret = kernel_read_file(file, buf, size, max_size, id);
+   ret = kernel_read_file(file, buf, max_size, id);
fput(file);
return ret;
 }
 EXPORT_SYMBOL_GPL(kernel_read_file_from_path_initns);
 
-int 

[PATCH v4 10/17] firmware_loader: Use security_post_load_data()

2020-07-29 Thread Kees Cook
Now that security_post_load_data() is wired up, use it instead
of the NULL file argument style of security_post_read_file(),
and update the security_kernel_load_data() call to indicate that a
security_kernel_post_load_data() call is expected.

Wire up the IMA check to match earlier logic. Perhaps a generalized
change to ima_post_load_data() might look something like this:

return process_buffer_measurement(buf, size,
  kernel_load_data_id_str(load_id),
  read_idmap[load_id] ?: FILE_CHECK,
  0, NULL);

Signed-off-by: Kees Cook 
---
 drivers/base/firmware_loader/fallback.c   |  8 
 .../base/firmware_loader/fallback_platform.c  |  7 ++-
 security/integrity/ima/ima_main.c | 20 +--
 3 files changed, 20 insertions(+), 15 deletions(-)

diff --git a/drivers/base/firmware_loader/fallback.c 
b/drivers/base/firmware_loader/fallback.c
index a196aacce22c..7cfdfdcb819c 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -272,9 +272,9 @@ static ssize_t firmware_loading_store(struct device *dev,
dev_err(dev, "%s: map pages failed\n",
__func__);
else
-   rc = security_kernel_post_read_file(NULL,
-   fw_priv->data, fw_priv->size,
-   READING_FIRMWARE);
+   rc = 
security_kernel_post_load_data(fw_priv->data,
+   fw_priv->size,
+   LOADING_FIRMWARE);
 
/*
 * Same logic as fw_load_abort, only the DONE bit
@@ -613,7 +613,7 @@ static bool fw_run_sysfs_fallback(u32 opt_flags)
return false;
 
/* Also permit LSMs and IMA to fail firmware sysfs fallback */
-   ret = security_kernel_load_data(LOADING_FIRMWARE, false);
+   ret = security_kernel_load_data(LOADING_FIRMWARE, true);
if (ret < 0)
return false;
 
diff --git a/drivers/base/firmware_loader/fallback_platform.c 
b/drivers/base/firmware_loader/fallback_platform.c
index a12c79d47efc..4d1157af0e86 100644
--- a/drivers/base/firmware_loader/fallback_platform.c
+++ b/drivers/base/firmware_loader/fallback_platform.c
@@ -17,7 +17,7 @@ int firmware_fallback_platform(struct fw_priv *fw_priv, u32 
opt_flags)
if (!(opt_flags & FW_OPT_FALLBACK_PLATFORM))
return -ENOENT;
 
-   rc = security_kernel_load_data(LOADING_FIRMWARE, false);
+   rc = security_kernel_load_data(LOADING_FIRMWARE, true);
if (rc)
return rc;
 
@@ -27,6 +27,11 @@ int firmware_fallback_platform(struct fw_priv *fw_priv, u32 
opt_flags)
 
if (fw_priv->data && size > fw_priv->allocated_size)
return -ENOMEM;
+
+   rc = security_kernel_post_load_data((u8 *)data, size, LOADING_FIRMWARE);
+   if (rc)
+   return rc;
+
if (!fw_priv->data)
fw_priv->data = vmalloc(size);
if (!fw_priv->data)
diff --git a/security/integrity/ima/ima_main.c 
b/security/integrity/ima/ima_main.c
index 85000dc8595c..1a7bc4c7437d 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -648,15 +648,6 @@ 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) {
-   if ((ima_appraise & IMA_APPRAISE_FIRMWARE) &&
-   (ima_appraise & IMA_APPRAISE_ENFORCE)) {
-   pr_err("Prevent firmware loading_store.\n");
-   return -EACCES; /* INTEGRITY_UNKNOWN */
-   }
-   return 0;
-   }
-
/* permit signed certs */
if (!file && read_id == READING_X509_CERTIFICATE)
return 0;
@@ -706,7 +697,7 @@ int ima_load_data(enum kernel_load_data_id id, bool 
contents)
}
break;
case LOADING_FIRMWARE:
-   if (ima_enforce && (ima_appraise & IMA_APPRAISE_FIRMWARE)) {
+   if (ima_enforce && (ima_appraise & IMA_APPRAISE_FIRMWARE) && 
!contents) {
pr_err("Prevent firmware sysfs fallback loading.\n");
return -EACCES; /* INTEGRITY_UNKNOWN */
}
@@ -739,6 +730,15 @@ int ima_load_data(enum kernel_load_data_id id, bool 
contents)
  */
 int ima_post_load_data(char *buf, loff_t size, enum kernel_load_data_id 
load_id)
 {
+   if (load_id == LOADING_FIRMWARE) {
+   if ((ima_appraise & IMA_APPRAISE_FIRMWARE) &&
+   (ima_appraise & IMA_APPRAISE_ENFORCE)) {
+   pr_err("Prevent firmware loading_store.\n");
+ 

[PATCH v4 02/17] fs/kernel_read_file: Remove FIRMWARE_PREALLOC_BUFFER enum

2020-07-29 Thread Kees Cook
FIRMWARE_PREALLOC_BUFFER is a "how", not a "what", and confuses the LSMs
that are interested in filtering between types of things. The "how"
should be an internal detail made uninteresting to the LSMs.

Fixes: a098ecd2fa7d ("firmware: support loading into a pre-allocated buffer")
Fixes: fd90bc559bfb ("ima: based on policy verify firmware signatures 
(pre-allocated buffer)")
Fixes: 4f0496d8ffa3 ("ima: based on policy warn about loading firmware 
(pre-allocated buffer)")
Cc: sta...@vger.kernel.org
Acked-by: Scott Branden 
Reviewed-by: Mimi Zohar 
Reviewed-by: Luis Chamberlain 
Signed-off-by: Kees Cook 
---
To aid in backporting, this change is made before moving
kernel_read_file() to separate header/source files.
---
 drivers/base/firmware_loader/main.c | 5 ++---
 fs/exec.c   | 7 ---
 include/linux/fs.h  | 2 +-
 kernel/module.c | 2 +-
 security/integrity/digsig.c | 2 +-
 security/integrity/ima/ima_fs.c | 2 +-
 security/integrity/ima/ima_main.c   | 6 ++
 7 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/drivers/base/firmware_loader/main.c 
b/drivers/base/firmware_loader/main.c
index 9da0c9d5f538..fe68ae278201 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -465,14 +465,12 @@ fw_get_filesystem_firmware(struct device *device, struct 
fw_priv *fw_priv,
int i, len;
int rc = -ENOENT;
char *path;
-   enum kernel_read_file_id id = READING_FIRMWARE;
size_t msize = INT_MAX;
void *buffer = NULL;
 
/* 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;
msize = fw_priv->allocated_size;
}
 
@@ -496,7 +494,8 @@ fw_get_filesystem_firmware(struct device *device, struct 
fw_priv *fw_priv,
 
/* load firmware files from the mount namespace of init */
rc = kernel_read_file_from_path_initns(path, ,
-  , msize, id);
+  , msize,
+  READING_FIRMWARE);
if (rc) {
if (rc != -ENOENT)
dev_warn(device, "loading %s failed with error 
%d\n",
diff --git a/fs/exec.c b/fs/exec.c
index e6e8a9a70327..2bf549757ce7 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -927,6 +927,7 @@ int kernel_read_file(struct file *file, void **buf, loff_t 
*size,
 {
loff_t i_size, pos;
ssize_t bytes = 0;
+   void *allocated = NULL;
int ret;
 
if (!S_ISREG(file_inode(file)->i_mode) || max_size < 0)
@@ -950,8 +951,8 @@ int kernel_read_file(struct file *file, void **buf, loff_t 
*size,
goto out;
}
 
-   if (id != READING_FIRMWARE_PREALLOC_BUFFER)
-   *buf = vmalloc(i_size);
+   if (!*buf)
+   *buf = allocated = vmalloc(i_size);
if (!*buf) {
ret = -ENOMEM;
goto out;
@@ -980,7 +981,7 @@ int kernel_read_file(struct file *file, void **buf, loff_t 
*size,
 
 out_free:
if (ret < 0) {
-   if (id != READING_FIRMWARE_PREALLOC_BUFFER) {
+   if (allocated) {
vfree(*buf);
*buf = NULL;
}
diff --git a/include/linux/fs.h b/include/linux/fs.h
index f5abba86107d..f34d47ba49de 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2993,10 +2993,10 @@ static inline void i_readcount_inc(struct inode *inode)
 #endif
 extern int do_pipe_flags(int *, int);
 
+/* This is a list of *what* is being read, not *how*. */
 #define __kernel_read_file_id(id) \
id(UNKNOWN, unknown)\
id(FIRMWARE, firmware)  \
-   id(FIRMWARE_PREALLOC_BUFFER, firmware)  \
id(FIRMWARE_EFI_EMBEDDED, firmware) \
id(MODULE, kernel-module)   \
id(KEXEC_IMAGE, kexec-image)\
diff --git a/kernel/module.c b/kernel/module.c
index aa183c9ac0a2..d2d12c299dd8 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3991,7 +3991,7 @@ SYSCALL_DEFINE3(finit_module, int, fd, const char __user 
*, uargs, int, flags)
 {
struct load_info info = { };
loff_t size;
-   void *hdr;
+   void *hdr = NULL;
int err;
 
err = may_init_module();
diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index e9cbadade74b..ac02b7632353 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -169,7 +169,7 @@ int __init integrity_add_key(const unsigned int id, const 
void *data,
 
 int __init integrity_load_x509(const unsigned int id, const char *path)
 {
-   void *data;
+   void *data = NULL;
loff_t size;
int rc;

[PATCH v4 13/17] IMA: Add support for file reads without contents

2020-07-29 Thread Kees Cook
From: Scott Branden 

When the kernel_read_file LSM hook is called with contents=false, IMA
can appraise the file directly, without requiring a filled buffer. When
such a buffer is available, though, IMA can continue to use it instead
of forcing a double read here.

Signed-off-by: Scott Branden 
Link: 
https://lore.kernel.org/lkml/20200706232309.12010-10-scott.bran...@broadcom.com/
Reviewed-by: Mimi Zohar 
Signed-off-by: Kees Cook 
---
 security/integrity/ima/ima_main.c | 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/security/integrity/ima/ima_main.c 
b/security/integrity/ima/ima_main.c
index dc4f90660aa6..de57fce5bced 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -613,11 +613,8 @@ void ima_post_path_mknod(struct dentry *dentry)
 int ima_read_file(struct file *file, enum kernel_read_file_id read_id,
  bool contents)
 {
-   /* Reject all partial reads during appraisal. */
-   if (!contents) {
-   if (ima_appraise & IMA_APPRAISE_ENFORCE)
-   return -EACCES;
-   }
+   enum ima_hooks func;
+   u32 secid;
 
/*
 * Do devices using pre-allocated memory run the risk of the
@@ -626,7 +623,20 @@ int ima_read_file(struct file *file, enum 
kernel_read_file_id read_id,
 * buffers? It may be desirable to include the buffer address
 * in this API and walk all the dma_map_single() mappings to check.
 */
-   return 0;
+
+   /*
+* There will be a call made to ima_post_read_file() with
+* a filled buffer, so we don't need to perform an extra
+* read early here.
+*/
+   if (contents)
+   return 0;
+
+   /* Read entire file for all partial reads. */
+   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] = {
-- 
2.25.1



[PATCH] lib: kunit: add bitfield test conversion to KUnit

2020-07-29 Thread Vitor Massaru Iha
This adds the conversion of the runtime tests of test_bitfield,
from `lib/test_bitfield.c` to KUnit tests.

Please apply this commit first (linux-kselftest/kunit-fixes):
3f37d14b8a3152441f36b6bc74000996679f0998 kunit: kunit_config: Fix parsing of 
CONFIG options with space

Code Style Documentation: [0]

Signed-off-by: Vitor Massaru Iha 
Link: [0] 
https://lore.kernel.org/linux-kselftest/20200620054944.167330-1-david...@google.com/T/#u
---
 lib/Kconfig.debug | 23 --
 lib/Makefile  |  2 +-
 lib/{test_bitfield.c => bitfield_kunit.c} | 92 ++-
 3 files changed, 57 insertions(+), 60 deletions(-)
 rename lib/{test_bitfield.c => bitfield_kunit.c} (66%)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 9ad9210d70a1..16c5574bf103 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1986,13 +1986,6 @@ config TEST_BITMAP
 
  If unsure, say N.
 
-config TEST_BITFIELD
-   tristate "Test bitfield functions at runtime"
-   help
- Enable this option to test the bitfield functions at boot.
-
- If unsure, say N.
-
 config TEST_UUID
tristate "Test functions located in the uuid module at runtime"
 
@@ -2142,6 +2135,22 @@ config TEST_SYSCTL
 
  If unsure, say N.
 
+config BITFIELD_KUNIT
+   tristate "KUnit test bitfield functions at runtime"
+   depends on KUNIT
+   help
+ Enable this option to test the bitfield functions at boot.
+
+ KUnit tests run during boot and output the results to the debug log
+ in TAP format (http://testanything.org/). Only useful for kernel devs
+ running the KUnit test harness, and not intended for inclusion into a
+ production build.
+
+ For more information on KUnit and unit tests in general please refer
+ to the KUnit documentation in Documentation/dev-tools/kunit/.
+
+ If unsure, say N.
+
 config SYSCTL_KUNIT_TEST
tristate "KUnit test for sysctl" if !KUNIT_ALL_TESTS
depends on KUNIT
diff --git a/lib/Makefile b/lib/Makefile
index b1c42c10073b..56019c34f5ed 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -84,7 +84,6 @@ obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_key_base.o
 obj-$(CONFIG_TEST_PRINTF) += test_printf.o
 obj-$(CONFIG_TEST_BITMAP) += test_bitmap.o
 obj-$(CONFIG_TEST_STRSCPY) += test_strscpy.o
-obj-$(CONFIG_TEST_BITFIELD) += test_bitfield.o
 obj-$(CONFIG_TEST_UUID) += test_uuid.o
 obj-$(CONFIG_TEST_XARRAY) += test_xarray.o
 obj-$(CONFIG_TEST_PARMAN) += test_parman.o
@@ -316,5 +315,6 @@ obj-$(CONFIG_GENERIC_LIB_UCMPDI2) += ucmpdi2.o
 obj-$(CONFIG_OBJAGG) += objagg.o
 
 # KUnit tests
+obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o
 obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
 obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
diff --git a/lib/test_bitfield.c b/lib/bitfield_kunit.c
similarity index 66%
rename from lib/test_bitfield.c
rename to lib/bitfield_kunit.c
index 5b8f4108662d..d63a2be5aff8 100644
--- a/lib/test_bitfield.c
+++ b/lib/bitfield_kunit.c
@@ -5,8 +5,7 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
-#include 
-#include 
+#include 
 #include 
 
 #define CHECK_ENC_GET_U(tp, v, field, res) do {
\
@@ -14,13 +13,11 @@
u##tp _res; \
\
_res = u##tp##_encode_bits(v, field);   \
-   if (_res != res) {  \
-   pr_warn("u" #tp "_encode_bits(" #v ", " #field 
") is 0x%llx != " #res "\n",\
-   (u64)_res); \
-   return -EINVAL; \
-   }   \
-   if (u##tp##_get_bits(_res, field) != v) \
-   return -EINVAL; \
+   KUNIT_ASSERT_FALSE_MSG(context, _res != res,\
+  "u" #tp "_encode_bits(" #v ", " #field 
") is 0x%llx != " #res "\n",  \
+  (u64)_res);  \
+   KUNIT_ASSERT_FALSE(context, \
+  u##tp##_get_bits(_res, field) != v); \
}   \
} while (0)
 
@@ -29,14 +26,13 @@
__le##tp _res;  \
\
_res = le##tp##_encode_bits(v, field);  \
-   if (_res != cpu_to_le##tp(res)) {   \
-   pr_warn("le" #tp "_encode_bits(" #v ", " #field 
") is 0x%llx != 0x%llx\n",\
-

[PATCH v4 11/17] module: Call security_kernel_post_load_data()

2020-07-29 Thread Kees Cook
Now that there is an API for checking loaded contents for modules
loaded without a file, call into the LSM hooks.

Cc: Jessica Yu 
Signed-off-by: Kees Cook 
---
 kernel/module.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index d773f32f8dfd..72e33e25d7b9 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2970,7 +2970,7 @@ static int copy_module_from_user(const void __user *umod, 
unsigned long len,
if (info->len < sizeof(*(info->hdr)))
return -ENOEXEC;
 
-   err = security_kernel_load_data(LOADING_MODULE, false);
+   err = security_kernel_load_data(LOADING_MODULE, true);
if (err)
return err;
 
@@ -2980,11 +2980,17 @@ static int copy_module_from_user(const void __user 
*umod, unsigned long len,
return -ENOMEM;
 
if (copy_chunked_from_user(info->hdr, umod, info->len) != 0) {
-   vfree(info->hdr);
-   return -EFAULT;
+   err = -EFAULT;
+   goto out;
}
 
-   return 0;
+   err = security_kernel_post_load_data((char *)info->hdr, info->len,
+LOADING_MODULE);
+out:
+   if (err)
+   vfree(info->hdr);
+
+   return err;
 }
 
 static void free_copy(struct load_info *info)
-- 
2.25.1



[PATCH v4 09/17] LSM: Introduce kernel_post_load_data() hook

2020-07-29 Thread Kees Cook
There are a few places in the kernel where LSMs would like to have
visibility into the contents of a kernel buffer that has been loaded or
read. While security_kernel_post_read_file() (which includes the
buffer) exists as a pairing for security_kernel_read_file(), no such
hook exists to pair with security_kernel_load_data().

Earlier proposals for just using security_kernel_post_read_file() with a
NULL file argument were rejected (i.e. "file" should always be valid for
the security_..._file hooks, but it appears at least one case was
left in the kernel during earlier refactoring. (This will be fixed in
a subsequent patch.)

Since not all cases of security_kernel_load_data() can have a single
contiguous buffer made available to the LSM hook (e.g. kexec image
segments are separately loaded), there needs to be a way for the LSM to
reason about its expectations of the hook coverage. In order to handle
this, add a "contents" argument to the "kernel_load_data" hook that
indicates if the newly added "kernel_post_load_data" hook will be called
with the full contents once loaded. That way, LSMs requiring full contents
can choose to unilaterally reject "kernel_load_data" with contents=false
(which is effectively the existing hook coverage), but when contents=true
they can allow it and later evaluate the "kernel_post_load_data" hook
once the buffer is loaded.

With this change, LSMs can gain coverage over non-file-backed data loads
(e.g. init_module(2) and firmware userspace helper), which will happen
in subsequent patches.

Additionally prepare IMA to start processing these cases.

Signed-off-by: Kees Cook 
---
 drivers/base/firmware_loader/fallback.c   |  2 +-
 .../base/firmware_loader/fallback_platform.c  |  2 +-
 include/linux/ima.h   | 12 +--
 include/linux/lsm_hook_defs.h |  4 +++-
 include/linux/lsm_hooks.h |  9 
 include/linux/security.h  | 12 +--
 kernel/kexec.c|  2 +-
 kernel/module.c   |  2 +-
 security/integrity/ima/ima_main.c | 21 ++-
 security/loadpin/loadpin.c|  2 +-
 security/security.c   | 18 +---
 security/selinux/hooks.c  |  2 +-
 12 files changed, 73 insertions(+), 15 deletions(-)

diff --git a/drivers/base/firmware_loader/fallback.c 
b/drivers/base/firmware_loader/fallback.c
index 5327bfc6ba71..a196aacce22c 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -613,7 +613,7 @@ static bool fw_run_sysfs_fallback(u32 opt_flags)
return false;
 
/* Also permit LSMs and IMA to fail firmware sysfs fallback */
-   ret = security_kernel_load_data(LOADING_FIRMWARE);
+   ret = security_kernel_load_data(LOADING_FIRMWARE, false);
if (ret < 0)
return false;
 
diff --git a/drivers/base/firmware_loader/fallback_platform.c 
b/drivers/base/firmware_loader/fallback_platform.c
index 6958ab1a8059..a12c79d47efc 100644
--- a/drivers/base/firmware_loader/fallback_platform.c
+++ b/drivers/base/firmware_loader/fallback_platform.c
@@ -17,7 +17,7 @@ int firmware_fallback_platform(struct fw_priv *fw_priv, u32 
opt_flags)
if (!(opt_flags & FW_OPT_FALLBACK_PLATFORM))
return -ENOENT;
 
-   rc = security_kernel_load_data(LOADING_FIRMWARE);
+   rc = security_kernel_load_data(LOADING_FIRMWARE, false);
if (rc)
return rc;
 
diff --git a/include/linux/ima.h b/include/linux/ima.h
index 148636bfcc8f..502e36ad7804 100644
--- a/include/linux/ima.h
+++ b/include/linux/ima.h
@@ -20,7 +20,9 @@ extern void ima_post_create_tmpfile(struct inode *inode);
 extern void ima_file_free(struct file *file);
 extern int ima_file_mmap(struct file *file, unsigned long prot);
 extern int ima_file_mprotect(struct vm_area_struct *vma, unsigned long prot);
-extern int ima_load_data(enum kernel_load_data_id id);
+extern int ima_load_data(enum kernel_load_data_id id, bool contents);
+extern int ima_post_load_data(char *buf, loff_t size,
+ enum kernel_load_data_id id);
 extern int ima_read_file(struct file *file, enum kernel_read_file_id id);
 extern int ima_post_read_file(struct file *file, void *buf, loff_t size,
  enum kernel_read_file_id id);
@@ -78,7 +80,13 @@ static inline int ima_file_mprotect(struct vm_area_struct 
*vma,
return 0;
 }
 
-static inline int ima_load_data(enum kernel_load_data_id id)
+static inline int ima_load_data(enum kernel_load_data_id id, bool contents)
+{
+   return 0;
+}
+
+static inline int ima_post_load_data(char *buf, loff_t size,
+enum kernel_load_data_id id)
 {
return 0;
 }
diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
index af998f93d256..7ed5d31ac9cc 100644
--- 

[PATCH v4 01/17] test_firmware: Test platform fw loading on non-EFI systems

2020-07-29 Thread Kees Cook
On non-EFI systems, it wasn't possible to test the platform firmware
loader because it will have never set "checked_fw" during __init.
Instead, allow the test code to override this check. Additionally split
the declarations into a private header file so it there is greater
enforcement of the symbol visibility.

Fixes: 548193cba2a7 ("test_firmware: add support for firmware_request_platform")
Cc: sta...@vger.kernel.org
Acked-by: Scott Branden 
Reviewed-by: Luis Chamberlain 
Signed-off-by: Kees Cook 
---
 drivers/firmware/efi/embedded-firmware.c | 21 -
 drivers/firmware/efi/embedded-firmware.h | 21 +
 include/linux/efi_embedded_fw.h  | 13 -
 lib/test_firmware.c  |  5 +
 4 files changed, 42 insertions(+), 18 deletions(-)
 create mode 100644 drivers/firmware/efi/embedded-firmware.h

diff --git a/drivers/firmware/efi/embedded-firmware.c 
b/drivers/firmware/efi/embedded-firmware.c
index a1b199de9006..0fb03cd0a5a2 100644
--- a/drivers/firmware/efi/embedded-firmware.c
+++ b/drivers/firmware/efi/embedded-firmware.c
@@ -14,11 +14,22 @@
 #include 
 #include 
 
+#include "embedded-firmware.h"
+
+#ifdef CONFIG_TEST_FIRMWARE
+# define EFI_EMBEDDED_FW_VISIBILITY
+#else
+# define EFI_EMBEDDED_FW_VISIBILITY static
+#endif
+
+EFI_EMBEDDED_FW_VISIBILITY LIST_HEAD(efi_embedded_fw_list);
+EFI_EMBEDDED_FW_VISIBILITY bool efi_embedded_fw_checked;
+
 /* Exported for use by lib/test_firmware.c only */
-LIST_HEAD(efi_embedded_fw_list);
+#ifdef CONFIG_TEST_FIRMWARE
 EXPORT_SYMBOL_GPL(efi_embedded_fw_list);
-
-static bool checked_for_fw;
+EXPORT_SYMBOL_GPL(efi_embedded_fw_checked);
+#endif
 
 static const struct dmi_system_id * const embedded_fw_table[] = {
 #ifdef CONFIG_TOUCHSCREEN_DMI
@@ -119,14 +130,14 @@ void __init efi_check_for_embedded_firmwares(void)
}
}
 
-   checked_for_fw = true;
+   efi_embedded_fw_checked = true;
 }
 
 int efi_get_embedded_fw(const char *name, const u8 **data, size_t *size)
 {
struct efi_embedded_fw *iter, *fw = NULL;
 
-   if (!checked_for_fw) {
+   if (!efi_embedded_fw_checked) {
pr_warn("Warning %s called while we did not check for embedded 
fw\n",
__func__);
return -ENOENT;
diff --git a/drivers/firmware/efi/embedded-firmware.h 
b/drivers/firmware/efi/embedded-firmware.h
new file mode 100644
index ..bb894eae0906
--- /dev/null
+++ b/drivers/firmware/efi/embedded-firmware.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _EFI_EMBEDDED_FW_INTERNAL_H_
+#define _EFI_EMBEDDED_FW_INTERNAL_H_
+
+/*
+ * This struct and efi_embedded_fw_list are private to the efi-embedded fw
+ * implementation they only in separate header for use by lib/test_firmware.c.
+ */
+struct efi_embedded_fw {
+   struct list_head list;
+   const char *name;
+   const u8 *data;
+   size_t length;
+};
+
+#ifdef CONFIG_TEST_FIRMWARE
+extern struct list_head efi_embedded_fw_list;
+extern bool efi_embedded_fw_checked;
+#endif
+
+#endif /* _EFI_EMBEDDED_FW_INTERNAL_H_ */
diff --git a/include/linux/efi_embedded_fw.h b/include/linux/efi_embedded_fw.h
index 57eac5241303..4ad5db9f5312 100644
--- a/include/linux/efi_embedded_fw.h
+++ b/include/linux/efi_embedded_fw.h
@@ -7,19 +7,6 @@
 
 #define EFI_EMBEDDED_FW_PREFIX_LEN 8
 
-/*
- * This struct and efi_embedded_fw_list are private to the efi-embedded fw
- * implementation they are in this header for use by lib/test_firmware.c only!
- */
-struct efi_embedded_fw {
-   struct list_head list;
-   const char *name;
-   const u8 *data;
-   size_t length;
-};
-
-extern struct list_head efi_embedded_fw_list;
-
 /**
  * struct efi_embedded_fw_desc - This struct is used by the EFI embedded-fw
  *   code to search for embedded firmwares.
diff --git a/lib/test_firmware.c b/lib/test_firmware.c
index 9fee2b93a8d1..62af792e151c 100644
--- a/lib/test_firmware.c
+++ b/lib/test_firmware.c
@@ -489,6 +489,7 @@ static ssize_t trigger_request_store(struct device *dev,
 static DEVICE_ATTR_WO(trigger_request);
 
 #ifdef CONFIG_EFI_EMBEDDED_FIRMWARE
+#include "../drivers/firmware/efi/embedded-firmware.h"
 static ssize_t trigger_request_platform_store(struct device *dev,
  struct device_attribute *attr,
  const char *buf, size_t count)
@@ -501,6 +502,7 @@ static ssize_t trigger_request_platform_store(struct device 
*dev,
};
struct efi_embedded_fw efi_embedded_fw;
const struct firmware *firmware = NULL;
+   bool saved_efi_embedded_fw_checked;
char *name;
int rc;
 
@@ -513,6 +515,8 @@ static ssize_t trigger_request_platform_store(struct device 
*dev,
efi_embedded_fw.data = (void *)test_data;
efi_embedded_fw.length = sizeof(test_data);
list_add(_embedded_fw.list, _embedded_fw_list);
+

[PATCH v4 16/17] firmware: Add request_partial_firmware_into_buf()

2020-07-29 Thread Kees Cook
From: Scott Branden 

Add request_partial_firmware_into_buf() to allow for portions of a
firmware file to be read into a buffer. This is needed when large firmware
must be loaded in portions from a file on memory constrained systems.

Signed-off-by: Scott Branden 
Co-developed-by: Kees Cook 
Signed-off-by: Kees Cook 
---
 drivers/base/firmware_loader/firmware.h |   4 +
 drivers/base/firmware_loader/main.c | 101 +++-
 include/linux/firmware.h|  12 +++
 3 files changed, 99 insertions(+), 18 deletions(-)

diff --git a/drivers/base/firmware_loader/firmware.h 
b/drivers/base/firmware_loader/firmware.h
index 7ad5fe52bc72..3f6eda46b3a2 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,7 @@ struct fw_priv {
void *data;
size_t size;
size_t allocated_size;
+   size_t offset;
u32 opt_flags;
 #ifdef CONFIG_FW_LOADER_PAGED_BUF
bool is_paged_buf;
diff --git a/drivers/base/firmware_loader/main.c 
b/drivers/base/firmware_loader/main.c
index 67d8afa91ae0..54c5d57b6327 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -170,10 +170,19 @@ static struct fw_priv *__allocate_fw_priv(const char 
*fw_name,
  struct firmware_cache *fwc,
  void *dbuf,
  size_t size,
+ size_t offset,
  u32 opt_flags)
 {
struct fw_priv *fw_priv;
 
+   /* For a partial read, the buffer must be preallocated. */
+   if ((opt_flags & FW_OPT_PARTIAL) && !dbuf)
+   return NULL;
+
+   /* Only partial reads are allowed to use an offset. */
+   if (offset != 0 && !(opt_flags & FW_OPT_PARTIAL))
+   return NULL;
+
fw_priv = kzalloc(sizeof(*fw_priv), GFP_ATOMIC);
if (!fw_priv)
return NULL;
@@ -188,6 +197,7 @@ 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_flags = opt_flags;
fw_state_init(fw_priv);
 #ifdef CONFIG_FW_LOADER_USER_HELPER
@@ -216,12 +226,17 @@ static int alloc_lookup_fw_priv(const char *fw_name,
struct fw_priv **fw_priv,
void *dbuf,
size_t size,
+   size_t offset,
u32 opt_flags)
 {
struct fw_priv *tmp;
 
spin_lock(>lock);
-   if (!(opt_flags & FW_OPT_NOCACHE)) {
+   /*
+* Do not merge requests that are marked to be non-cached or
+* are performing partial reads.
+*/
+   if (!(opt_flags & (FW_OPT_NOCACHE | FW_OPT_PARTIAL))) {
tmp = __lookup_fw_priv(fw_name);
if (tmp) {
kref_get(>ref);
@@ -232,7 +247,7 @@ static int alloc_lookup_fw_priv(const char *fw_name,
}
}
 
-   tmp = __allocate_fw_priv(fw_name, fwc, dbuf, size, opt_flags);
+   tmp = __allocate_fw_priv(fw_name, fwc, dbuf, size, offset, opt_flags);
if (tmp) {
INIT_LIST_HEAD(>list);
if (!(opt_flags & FW_OPT_NOCACHE))
@@ -485,6 +500,9 @@ fw_get_filesystem_firmware(struct device *device, struct 
fw_priv *fw_priv,
return -ENOMEM;
 
for (i = 0; i < ARRAY_SIZE(fw_path); i++) {
+   size_t file_size = 0;
+   size_t *file_size_ptr = NULL;
+
/* skip the unset customized path */
if (!fw_path[i][0])
continue;
@@ -498,9 +516,18 @@ fw_get_filesystem_firmware(struct device *device, struct 
fw_priv *fw_priv,
 
fw_priv->size = 0;
 
+   /*
+* The total file size is only examined when doing a partial
+* read; the "full read" case needs to fail if the whole
+* firmware was not completely loaded.
+*/
+   if ((fw_priv->opt_flags & FW_OPT_PARTIAL) && buffer)
+   file_size_ptr = 

[PATCH v4 14/17] fs/kernel_file_read: Add "offset" arg for partial reads

2020-07-29 Thread Kees Cook
To perform partial reads, callers of kernel_read_file*() must have a
non-NULL file_size argument and a preallocated buffer. The new "offset"
argument can then be used to seek to specific locations in the file to
fill the buffer to, at most, "buf_size" per call.

Where possible, the LSM hooks can report whether a full file has been
read or not so that the contents can be reasoned about.

Signed-off-by: Kees Cook 
---
 drivers/base/firmware_loader/main.c |  2 +-
 fs/kernel_read_file.c   | 78 -
 include/linux/kernel_read_file.h|  8 +--
 kernel/kexec_file.c |  4 +-
 kernel/module.c |  2 +-
 security/integrity/digsig.c |  2 +-
 security/integrity/ima/ima_fs.c |  3 +-
 7 files changed, 65 insertions(+), 34 deletions(-)

diff --git a/drivers/base/firmware_loader/main.c 
b/drivers/base/firmware_loader/main.c
index 6a5d407279e3..ff1808ed7547 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -494,7 +494,7 @@ 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,
+   rc = kernel_read_file_from_path_initns(path, 0, , msize,
   NULL,
   READING_FIRMWARE);
if (rc < 0) {
diff --git a/fs/kernel_read_file.c b/fs/kernel_read_file.c
index d73bc3fa710a..90d255fbdd9b 100644
--- a/fs/kernel_read_file.c
+++ b/fs/kernel_read_file.c
@@ -9,6 +9,7 @@
  * kernel_read_file() - read file contents into a kernel buffer
  *
  * @file   file to read from
+ * @offset where to start reading from (see below).
  * @bufpointer to a "void *" buffer for reading into (if
  * *@buf is NULL, a buffer will be allocated, and
  * @buf_size will be ignored)
@@ -19,19 +20,31 @@
  * @id the kernel_read_file_id identifying the type of
  * file contents being read (for LSMs to examine)
  *
+ * @offset must be 0 unless both @buf and @file_size are non-NULL
+ * (i.e. the caller must be expecting to read partial file contents
+ * via an already-allocated @buf, in at most @buf_size chunks, and
+ * will be able to determine when the entire file was read by
+ * checking @file_size). This isn't a recommended way to read a
+ * file, though, since it is possible that the contents might
+ * change between calls to kernel_read_file().
+ *
  * Returns number of bytes read (no single read will be bigger
  * than INT_MAX), or negative on error.
  *
  */
-int kernel_read_file(struct file *file, void **buf,
+int kernel_read_file(struct file *file, loff_t offset, void **buf,
 size_t buf_size, size_t *file_size,
 enum kernel_read_file_id id)
 {
loff_t i_size, pos;
-   ssize_t bytes = 0;
+   size_t copied;
void *allocated = NULL;
+   bool whole_file;
int ret;
 
+   if (offset != 0 && (!*buf || !file_size))
+   return -EINVAL;
+
if (!S_ISREG(file_inode(file)->i_mode))
return -EINVAL;
 
@@ -39,19 +52,27 @@ int kernel_read_file(struct file *file, void **buf,
if (ret)
return ret;
 
-   ret = security_kernel_read_file(file, id, true);
-   if (ret)
-   goto out;
-
i_size = i_size_read(file_inode(file));
if (i_size <= 0) {
ret = -EINVAL;
goto out;
}
-   if (i_size > INT_MAX || i_size > buf_size) {
+   /* The file is too big for sane activities. */
+   if (i_size > INT_MAX) {
+   ret = -EFBIG;
+   goto out;
+   }
+   /* The entire file cannot be read in one buffer. */
+   if (!file_size && offset == 0 && i_size > buf_size) {
ret = -EFBIG;
goto out;
}
+
+   whole_file = (offset == 0 && i_size <= buf_size);
+   ret = security_kernel_read_file(file, id, whole_file);
+   if (ret)
+   goto out;
+
if (file_size)
*file_size = i_size;
 
@@ -62,9 +83,14 @@ int kernel_read_file(struct file *file, void **buf,
goto out;
}
 
-   pos = 0;
-   while (pos < i_size) {
-   bytes = kernel_read(file, *buf + pos, i_size - pos, );
+   pos = offset;
+   copied = 0;
+   while (copied < buf_size) {
+   ssize_t bytes;
+   size_t wanted = min_t(size_t, buf_size - copied,
+ i_size - pos);
+
+   bytes = kernel_read(file, *buf + copied, wanted, );
if (bytes < 0) {
ret = bytes;
goto out_free;
@@ -72,14 +98,17 @@ int kernel_read_file(struct 

[PATCH v4 08/17] fs/kernel_read_file: Add file_size output argument

2020-07-29 Thread Kees Cook
In preparation for adding partial read support, add an optional output
argument to kernel_read_file*() that reports the file size so callers
can reason more easily about their reading progress.

Acked-by: Scott Branden 
Reviewed-by: Mimi Zohar 
Reviewed-by: Luis Chamberlain 
Signed-off-by: Kees Cook 
---
 drivers/base/firmware_loader/main.c |  1 +
 fs/kernel_read_file.c   | 19 +--
 include/linux/kernel_read_file.h|  4 
 kernel/kexec_file.c |  4 ++--
 kernel/module.c |  2 +-
 security/integrity/digsig.c |  2 +-
 security/integrity/ima/ima_fs.c |  2 +-
 7 files changed, 23 insertions(+), 11 deletions(-)

diff --git a/drivers/base/firmware_loader/main.c 
b/drivers/base/firmware_loader/main.c
index 9b425437afe6..6a5d407279e3 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -495,6 +495,7 @@ fw_get_filesystem_firmware(struct device *device, struct 
fw_priv *fw_priv,
 
/* load firmware files from the mount namespace of init */
rc = kernel_read_file_from_path_initns(path, , msize,
+  NULL,
   READING_FIRMWARE);
if (rc < 0) {
if (rc != -ENOENT)
diff --git a/fs/kernel_read_file.c b/fs/kernel_read_file.c
index e21a76001fff..2e29c38eb4df 100644
--- a/fs/kernel_read_file.c
+++ b/fs/kernel_read_file.c
@@ -14,6 +14,8 @@
  * @buf_size will be ignored)
  * @buf_size   size of buf, if already allocated. If @buf not
  * allocated, this is the largest size to allocate.
+ * @file_size  if non-NULL, the full size of @file will be
+ * written here.
  * @id the kernel_read_file_id identifying the type of
  * file contents being read (for LSMs to examine)
  *
@@ -22,7 +24,8 @@
  *
  */
 int kernel_read_file(struct file *file, void **buf,
-size_t buf_size, enum kernel_read_file_id id)
+size_t buf_size, size_t *file_size,
+enum kernel_read_file_id id)
 {
loff_t i_size, pos;
ssize_t bytes = 0;
@@ -49,6 +52,8 @@ int kernel_read_file(struct file *file, void **buf,
ret = -EFBIG;
goto out;
}
+   if (file_size)
+   *file_size = i_size;
 
if (!*buf)
*buf = allocated = vmalloc(i_size);
@@ -91,7 +96,8 @@ int kernel_read_file(struct file *file, void **buf,
 EXPORT_SYMBOL_GPL(kernel_read_file);
 
 int kernel_read_file_from_path(const char *path, void **buf,
-  size_t buf_size, enum kernel_read_file_id id)
+  size_t buf_size, size_t *file_size,
+  enum kernel_read_file_id id)
 {
struct file *file;
int ret;
@@ -103,14 +109,14 @@ int kernel_read_file_from_path(const char *path, void 
**buf,
if (IS_ERR(file))
return PTR_ERR(file);
 
-   ret = kernel_read_file(file, buf, buf_size, id);
+   ret = kernel_read_file(file, buf, buf_size, file_size, id);
fput(file);
return ret;
 }
 EXPORT_SYMBOL_GPL(kernel_read_file_from_path);
 
 int kernel_read_file_from_path_initns(const char *path, void **buf,
- size_t buf_size,
+ size_t buf_size, size_t *file_size,
  enum kernel_read_file_id id)
 {
struct file *file;
@@ -129,13 +135,14 @@ int kernel_read_file_from_path_initns(const char *path, 
void **buf,
if (IS_ERR(file))
return PTR_ERR(file);
 
-   ret = kernel_read_file(file, buf, buf_size, id);
+   ret = kernel_read_file(file, buf, buf_size, file_size, id);
fput(file);
return ret;
 }
 EXPORT_SYMBOL_GPL(kernel_read_file_from_path_initns);
 
 int kernel_read_file_from_fd(int fd, void **buf, size_t buf_size,
+size_t *file_size,
 enum kernel_read_file_id id)
 {
struct fd f = fdget(fd);
@@ -144,7 +151,7 @@ int kernel_read_file_from_fd(int fd, void **buf, size_t 
buf_size,
if (!f.file)
goto out;
 
-   ret = kernel_read_file(f.file, buf, buf_size, id);
+   ret = kernel_read_file(f.file, buf, buf_size, file_size, id);
 out:
fdput(f);
return ret;
diff --git a/include/linux/kernel_read_file.h b/include/linux/kernel_read_file.h
index 910039e7593e..023293eaf948 100644
--- a/include/linux/kernel_read_file.h
+++ b/include/linux/kernel_read_file.h
@@ -37,15 +37,19 @@ static inline const char *kernel_read_file_id_str(enum 
kernel_read_file_id id)
 
 int kernel_read_file(struct file *file,
 void **buf, size_t buf_size,
+size_t *file_size,
 enum kernel_read_file_id id);
 int 

[PATCH v4 15/17] firmware: Store opt_flags in fw_priv

2020-07-29 Thread Kees Cook
Instead of passing opt_flags around so much, store it in the private
structure so it can be examined by internals without needing to add more
arguments to functions.

Co-developed-by: Scott Branden 
Signed-off-by: Scott Branden 
Signed-off-by: Kees Cook 
---
 drivers/base/firmware_loader/fallback.c   | 11 +++-
 drivers/base/firmware_loader/fallback.h   |  5 ++--
 .../base/firmware_loader/fallback_platform.c  |  4 +--
 drivers/base/firmware_loader/firmware.h   |  3 ++-
 drivers/base/firmware_loader/main.c   | 25 +++
 5 files changed, 25 insertions(+), 23 deletions(-)

diff --git a/drivers/base/firmware_loader/fallback.c 
b/drivers/base/firmware_loader/fallback.c
index 7cfdfdcb819c..0a94c8739959 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -490,13 +490,11 @@ fw_create_instance(struct firmware *firmware, const char 
*fw_name,
 /**
  * fw_load_sysfs_fallback() - load a firmware via the sysfs fallback mechanism
  * @fw_sysfs: firmware sysfs information for the firmware to load
- * @opt_flags: flags of options, FW_OPT_*
  * @timeout: timeout to wait for the load
  *
  * In charge of constructing a sysfs fallback interface for firmware loading.
  **/
-static int fw_load_sysfs_fallback(struct fw_sysfs *fw_sysfs,
- u32 opt_flags, long timeout)
+static int fw_load_sysfs_fallback(struct fw_sysfs *fw_sysfs, long timeout)
 {
int retval = 0;
struct device *f_dev = _sysfs->dev;
@@ -518,7 +516,7 @@ static int fw_load_sysfs_fallback(struct fw_sysfs *fw_sysfs,
list_add(_priv->pending_list, _fw_head);
mutex_unlock(_lock);
 
-   if (opt_flags & FW_OPT_UEVENT) {
+   if (fw_priv->opt_flags & FW_OPT_UEVENT) {
fw_priv->need_uevent = true;
dev_set_uevent_suppress(f_dev, false);
dev_dbg(f_dev, "firmware: requesting %s\n", fw_priv->fw_name);
@@ -580,10 +578,10 @@ static int fw_load_from_user_helper(struct firmware 
*firmware,
}
 
fw_sysfs->fw_priv = firmware->priv;
-   ret = fw_load_sysfs_fallback(fw_sysfs, opt_flags, timeout);
+   ret = fw_load_sysfs_fallback(fw_sysfs, timeout);
 
if (!ret)
-   ret = assign_fw(firmware, device, opt_flags);
+   ret = assign_fw(firmware, device);
 
 out_unlock:
usermodehelper_read_unlock();
@@ -625,7 +623,6 @@ static bool fw_run_sysfs_fallback(u32 opt_flags)
  * @fw: pointer to firmware image
  * @name: name of firmware file to look for
  * @device: device for which firmware is being loaded
- * @opt_flags: options to control firmware loading behaviour
  * @ret: return value from direct lookup which triggered the fallback mechanism
  *
  * This function is called if direct lookup for the firmware failed, it enables
diff --git a/drivers/base/firmware_loader/fallback.h 
b/drivers/base/firmware_loader/fallback.h
index 2afdb6adb23f..3af7205b302f 100644
--- a/drivers/base/firmware_loader/fallback.h
+++ b/drivers/base/firmware_loader/fallback.h
@@ -67,10 +67,9 @@ static inline void unregister_sysfs_loader(void)
 #endif /* CONFIG_FW_LOADER_USER_HELPER */
 
 #ifdef CONFIG_EFI_EMBEDDED_FIRMWARE
-int firmware_fallback_platform(struct fw_priv *fw_priv, u32 opt_flags);
+int firmware_fallback_platform(struct fw_priv *fw_priv);
 #else
-static inline int firmware_fallback_platform(struct fw_priv *fw_priv,
-u32 opt_flags)
+static inline int firmware_fallback_platform(struct fw_priv *fw_priv)
 {
return -ENOENT;
 }
diff --git a/drivers/base/firmware_loader/fallback_platform.c 
b/drivers/base/firmware_loader/fallback_platform.c
index 4d1157af0e86..38de68d7e973 100644
--- a/drivers/base/firmware_loader/fallback_platform.c
+++ b/drivers/base/firmware_loader/fallback_platform.c
@@ -8,13 +8,13 @@
 #include "fallback.h"
 #include "firmware.h"
 
-int firmware_fallback_platform(struct fw_priv *fw_priv, u32 opt_flags)
+int firmware_fallback_platform(struct fw_priv *fw_priv)
 {
const u8 *data;
size_t size;
int rc;
 
-   if (!(opt_flags & FW_OPT_FALLBACK_PLATFORM))
+   if (!(fw_priv->opt_flags & FW_OPT_FALLBACK_PLATFORM))
return -ENOENT;
 
rc = security_kernel_load_data(LOADING_FIRMWARE, true);
diff --git a/drivers/base/firmware_loader/firmware.h 
b/drivers/base/firmware_loader/firmware.h
index 933e2192fbe8..7ad5fe52bc72 100644
--- a/drivers/base/firmware_loader/firmware.h
+++ b/drivers/base/firmware_loader/firmware.h
@@ -68,6 +68,7 @@ struct fw_priv {
void *data;
size_t size;
size_t allocated_size;
+   u32 opt_flags;
 #ifdef CONFIG_FW_LOADER_PAGED_BUF
bool is_paged_buf;
struct page **pages;
@@ -136,7 +137,7 @@ static inline void fw_state_done(struct fw_priv *fw_priv)
__fw_state_set(fw_priv, FW_STATUS_DONE);
 }
 
-int assign_fw(struct firmware *fw, struct device *device, u32 opt_flags);
+int 

drivers/tty/synclinkmp.c:3642:29: sparse: sparse: incorrect type in argument 1 (different address spaces)

2020-07-29 Thread kernel test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   6ba1b005ffc388c2aeaddae20da29e4810dea298
commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to 
define address spaces
date:   6 weeks ago
config: microblaze-randconfig-s032-20200729 (attached as .config)
compiler: microblaze-linux-gcc (GCC) 9.3.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-97-gee4aea9a-dirty
git checkout 670d0a4b10704667765f7d18f7592993d02783aa
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=microblaze 

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


sparse warnings: (new ones prefixed by >>)

   drivers/tty/synclinkmp.c:3562:27: sparse: sparse: incorrect type in 
assignment (different address spaces) @@ expected unsigned char *[usertype] 
memory_base @@ got void [noderef] __iomem * @@
   drivers/tty/synclinkmp.c:3562:27: sparse: expected unsigned char 
*[usertype] memory_base
   drivers/tty/synclinkmp.c:3562:27: sparse: got void [noderef] __iomem *
   drivers/tty/synclinkmp.c:3571:24: sparse: sparse: incorrect type in 
assignment (different address spaces) @@ expected unsigned char *[usertype] 
lcr_base @@ got void [noderef] __iomem * @@
   drivers/tty/synclinkmp.c:3571:24: sparse: expected unsigned char 
*[usertype] lcr_base
   drivers/tty/synclinkmp.c:3571:24: sparse: got void [noderef] __iomem *
   drivers/tty/synclinkmp.c:3580:24: sparse: sparse: incorrect type in 
assignment (different address spaces) @@ expected unsigned char *[usertype] 
sca_base @@ got void [noderef] __iomem * @@
   drivers/tty/synclinkmp.c:3580:24: sparse: expected unsigned char 
*[usertype] sca_base
   drivers/tty/synclinkmp.c:3580:24: sparse: got void [noderef] __iomem *
   drivers/tty/synclinkmp.c:3589:29: sparse: sparse: incorrect type in 
assignment (different address spaces) @@ expected unsigned char *[usertype] 
statctrl_base @@ got void [noderef] __iomem * @@
   drivers/tty/synclinkmp.c:3589:29: sparse: expected unsigned char 
*[usertype] statctrl_base
   drivers/tty/synclinkmp.c:3589:29: sparse: got void [noderef] __iomem *
>> drivers/tty/synclinkmp.c:3642:29: sparse: sparse: incorrect type in argument 
>> 1 (different address spaces) @@ expected void [noderef] __iomem *addr @@ 
>> got unsigned char *[usertype] memory_base @@
>> drivers/tty/synclinkmp.c:3642:29: sparse: expected void [noderef] 
>> __iomem *addr
   drivers/tty/synclinkmp.c:3642:29: sparse: got unsigned char *[usertype] 
memory_base
>> drivers/tty/synclinkmp.c:3647:40: sparse: sparse: incorrect type in argument 
>> 1 (different address spaces) @@ expected void [noderef] __iomem *addr @@ 
>> got unsigned char * @@
   drivers/tty/synclinkmp.c:3647:40: sparse: expected void [noderef] 
__iomem *addr
   drivers/tty/synclinkmp.c:3647:40: sparse: got unsigned char *
   drivers/tty/synclinkmp.c:3652:45: sparse: sparse: incorrect type in argument 
1 (different address spaces) @@ expected void [noderef] __iomem *addr @@
 got unsigned char * @@
   drivers/tty/synclinkmp.c:3652:45: sparse: expected void [noderef] 
__iomem *addr
   drivers/tty/synclinkmp.c:3652:45: sparse: got unsigned char *
   drivers/tty/synclinkmp.c:3657:40: sparse: sparse: incorrect type in argument 
1 (different address spaces) @@ expected void [noderef] __iomem *addr @@
 got unsigned char * @@
   drivers/tty/synclinkmp.c:3657:40: sparse: expected void [noderef] 
__iomem *addr
   drivers/tty/synclinkmp.c:3657:40: sparse: got unsigned char *
   drivers/tty/synclinkmp.c:5383:15: sparse: sparse: memset with byte count of 
262144
--
>> drivers/scsi/aacraid/nark.c:35:28: sparse: sparse: incorrect type in 
>> argument 1 (different modifiers) @@ expected void [noderef] __iomem 
>> *addr @@ got void volatile [noderef] __iomem *base @@
>> drivers/scsi/aacraid/nark.c:35:28: sparse: expected void [noderef] 
>> __iomem *addr
>> drivers/scsi/aacraid/nark.c:35:28: sparse: got void volatile [noderef] 
>> __iomem *base

vim +3642 drivers/tty/synclinkmp.c

^1da177e4c3f415 drivers/char/synclinkmp.c Linus Torvalds  2005-04-16  3612  
ce9f9f73af0338a drivers/char/synclinkmp.c Harvey Harrison 2008-04-28  3613  
static void release_resources(SLMP_INFO *info)
^1da177e4c3f415 drivers/char/synclinkmp.c Linus Torvalds  2005-04-16  3614  {
^1da177e4c3f415 drivers/char/synclinkmp.c Linus Torvalds  2005-04-16  3615  
if ( debug_level >= DEBUG_LEVEL_INFO )
^1da177e4c3f415 drivers/char/synclin

[PATCH] erofs: fix extended inode could cross boundary

2020-07-29 Thread Gao Xiang
Each ondisk inode should be aligned with inode slot boundary
(32-byte alignment) because of nid calculation formula, so all
compact inodes (32 byte) cannot across page boundary. However,
extended inode is now 64-byte form, which can across page boundary
in principle if the location is specified on purpose, although
it's hard to be generated by mkfs due to the allocation policy
and rarely used by Android use case now mainly for > 4GiB files.

For now, only two fields `i_ctime_nsec` and `i_nlink' couldn't
be read from disk properly and cause out-of-bound memory read
with random value.

Let's fix now.

Fixes: 431339ba9042 ("staging: erofs: add inode operations")
Cc:  # 4.19+
Signed-off-by: Gao Xiang 
---
The attachment is a designed image for reference.

 fs/erofs/inode.c | 121 +++
 1 file changed, 79 insertions(+), 42 deletions(-)

diff --git a/fs/erofs/inode.c b/fs/erofs/inode.c
index 7dd4bbe9674f..586f9d0a8b2f 100644
--- a/fs/erofs/inode.c
+++ b/fs/erofs/inode.c
@@ -8,31 +8,80 @@
 
 #include 
 
-/* no locking */
-static int erofs_read_inode(struct inode *inode, void *data)
+/*
+ * if inode is successfully read, return its inode page (or sometimes
+ * the inode payload page if it's an extended inode) in order to fill
+ * inline data if possible.
+ */
+static struct page *erofs_read_inode(struct inode *inode,
+unsigned int *ofs)
 {
+   struct super_block *sb = inode->i_sb;
+   struct erofs_sb_info *sbi = EROFS_SB(sb);
struct erofs_inode *vi = EROFS_I(inode);
-   struct erofs_inode_compact *dic = data;
-   struct erofs_inode_extended *die;
+   const erofs_off_t inode_loc = iloc(sbi, vi->nid);
+
+   erofs_blk_t blkaddr, nblks = 0;
+   struct page *page;
+   struct erofs_inode_compact *dic;
+   struct erofs_inode_extended *die, *copied = NULL;
+   unsigned int ifmt;
+   int err;
 
-   const unsigned int ifmt = le16_to_cpu(dic->i_format);
-   struct erofs_sb_info *sbi = EROFS_SB(inode->i_sb);
-   erofs_blk_t nblks = 0;
+   blkaddr = erofs_blknr(inode_loc);
+   *ofs = erofs_blkoff(inode_loc);
 
-   vi->datalayout = erofs_inode_datalayout(ifmt);
+   erofs_dbg("%s, reading inode nid %llu at %u of blkaddr %u",
+ __func__, vi->nid, *ofs, blkaddr);
+
+   page = erofs_get_meta_page(sb, blkaddr);
+   if (IS_ERR(page)) {
+   erofs_err(sb, "failed to get inode (nid: %llu) page, err %ld",
+ vi->nid, PTR_ERR(page));
+   return page;
+   }
 
+   dic = page_address(page) + *ofs;
+   ifmt = le16_to_cpu(dic->i_format);
+
+   vi->datalayout = erofs_inode_datalayout(ifmt);
if (vi->datalayout >= EROFS_INODE_DATALAYOUT_MAX) {
erofs_err(inode->i_sb, "unsupported datalayout %u of nid %llu",
  vi->datalayout, vi->nid);
-   DBG_BUGON(1);
-   return -EOPNOTSUPP;
+   err = -EOPNOTSUPP;
+   goto err_out;
}
 
switch (erofs_inode_version(ifmt)) {
case EROFS_INODE_LAYOUT_EXTENDED:
-   die = data;
-
vi->inode_isize = sizeof(struct erofs_inode_extended);
+   /* check if the inode acrosses page boundary */
+   if (*ofs + vi->inode_isize <= PAGE_SIZE) {
+   *ofs += vi->inode_isize;
+   die = (struct erofs_inode_extended *)dic;
+   } else {
+   const unsigned int gotten = PAGE_SIZE - *ofs;
+
+   copied = kmalloc(vi->inode_isize, GFP_NOFS);
+   if (!copied) {
+   err = -ENOMEM;
+   goto err_out;
+   }
+   memcpy(copied, dic, gotten);
+   unlock_page(page);
+   put_page(page);
+
+   page = erofs_get_meta_page(sb, blkaddr + 1);
+   if (IS_ERR(page)) {
+   erofs_err(sb, "failed to get inode payload page 
(nid: %llu), err %ld",
+ vi->nid, PTR_ERR(page));
+   kfree(copied);
+   return page;
+   }
+   *ofs = vi->inode_isize - gotten;
+   memcpy((u8 *)copied + gotten, page_address(page), *ofs);
+   die = copied;
+   }
vi->xattr_isize = erofs_xattr_ibody_size(die->i_xattr_icount);
 
inode->i_mode = le16_to_cpu(die->i_mode);
@@ -69,9 +118,12 @@ static int erofs_read_inode(struct inode *inode, void *data)
/* total blocks for compressed files */
if (erofs_inode_is_data_compressed(vi->datalayout))
nblks = le32_to_cpu(die->i_u.compressed_blocks);
+
+   

Re: Should perf version match kernel version?

2020-07-29 Thread Vitaly Chikunov
Peter, Arnaldo,

On Wed, Jul 29, 2020 at 01:27:32PM -0300, Arnaldo Carvalho de Melo wrote:
> 
> 
> On July 29, 2020 1:02:20 PM GMT-03:00, pet...@infradead.org wrote:
> >On Wed, Jul 29, 2020 at 06:56:47PM +0300, Vitaly Chikunov wrote:
> >> Hi,
> >> 
> >> It seems that most distros try to have perf version to match with
> >> running kernel version. Is is requirement? Would it be better to have
> >> single perf from kernel mainline to work with any (older) kernel
> >> version?
> >> 
> >> We have different kernel versions in ALT Linux (stable for 4.19, 5.4,
> >> and 5.7) and I want to understand if we should have three perfs or
> >> single package will be enough.
> >
> >We strive to have it all compatible, older perf should work on newer
> >kernel and newer perf should work on older kernel.
> >
> >How well it's all tested is another.
> >
> >Personally I often use a very old perf.
> 
> Yeah, never was a requirement, if you find some problem using a new perf on 
> an old kernel or the other way around, please report.

That's great to know. Thanks for the answers!



Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor

2020-07-29 Thread Madhavan T. Venkataraman



On 7/29/20 3:36 AM, David Laight wrote:
> From: Madhavan T. Venkataraman
>> Sent: 28 July 2020 19:52
> ...
>> trampfd faults are instruction faults that go through a different code path 
>> than
>> the one that calls handle_mm_fault(). Perhaps, it is the handle_mm_fault() 
>> that
>> is time consuming. Could you clarify?
> Given that the expectation is a few instructions in userspace
> (eg to pick up the original arguments for a nested call)
> the (probable) thousands of clocks taken by entering the
> kernel (especially with page table separation) is a massive
> delta.
>
> If entering the kernel were cheap no one would have added
> the DSO functions for getting the time of day.

I hear you. BTW, I did not say that the overhead was trivial.
I only said that in most cases, applications may not mind that
extra overhead.

However, since multiple people have raised that as an issue,
I will address it. I mentioned before that the kernel can actually
supply the code page that sets the context and jumps to
a PC and map it so the performance issue can be addressed.
I was planning to do that as a future enhancement.

If there is a consensus that I must address it immediately, I
could do that.

I will continue this discussion in my reply to Andy's email. Let
us pick it up from there.

Thanks.

Madhavan
>
>   David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 
> 1PT, UK
> Registration No: 1397386 (Wales)



Re: [char-misc-next] mei: hdcp: fix mei_hdcp_verify_mprime() input paramter

2020-07-29 Thread Gustavo A. R. Silva



On 7/29/20 12:32, Tomas Winkler wrote:
> wired_cmd_repeater_auth_stream_req_in has a variable
> length array at the end. we use struct_size() overflow
> macro to determine the size for the allocation and sending
> size.
> 
> Fixes: c56967d674e3 (mei: hdcp: Replace one-element array with flexible-array 
> member)

This also fixes:

commit 0a1af1b5c18d ("misc/mei/hdcp: Verify M_prime")

which introduced a potential stack overflow back in Feb 2019, hence it should be
fixed in -stable, too.

So, either both commit c56967d674e3 (mei: hdcp: Replace one-element array with 
flexible-array member)
and this patch should be ported to -stable in order to fix a potential
stack overflow due to commit 0a1af1b5c18d ("misc/mei/hdcp: Verify M_prime"),
or a separate fix that doesn't touch the one-element array streams[1] in struct
wired_cmd_repeater_auth_stream_req_in, but addresses the stack overflow should
be crafted and applied to -stable.

I can write that fix up for -stable if you want to go in that direction. Just 
let
me know.

> Cc: Ramalingam C 
> Cc: Gustavo A. R. Silva 
> Signed-off-by: Tomas Winkler 
> ---
>  drivers/misc/mei/hdcp/mei_hdcp.c | 38 ++--
>  1 file changed, 22 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c 
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index d1d3e025ca0e..0e8f12e38494 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -546,38 +546,44 @@ static int mei_hdcp_verify_mprime(struct device *dev,
> struct hdcp_port_data *data,
> struct hdcp2_rep_stream_ready *stream_ready)
>  {
> - struct wired_cmd_repeater_auth_stream_req_in
> - verify_mprime_in = { { 0 } };
> + struct wired_cmd_repeater_auth_stream_req_in *verify_mprime_in;
>   struct wired_cmd_repeater_auth_stream_req_out
>   verify_mprime_out = { { 0 } };
>   struct mei_cl_device *cldev;
>   ssize_t byte;
> + size_t cmd_size;
>  
>   if (!dev || !stream_ready || !data)
>   return -EINVAL;
>  
>   cldev = to_mei_cl_device(dev);
>  
> - verify_mprime_in.header.api_version = HDCP_API_VERSION;
> - verify_mprime_in.header.command_id = WIRED_REPEATER_AUTH_STREAM_REQ;
> - verify_mprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
> - verify_mprime_in.header.buffer_len =
> + cmd_size = struct_size(verify_mprime_in, streams, data->k);
> + if (cmd_size == SIZE_MAX)
> + return -EINVAL;
> +
> + verify_mprime_in = kzalloc(cmd_size, GFP_KERNEL);
> +
> + verify_mprime_in->header.api_version = HDCP_API_VERSION;
> + verify_mprime_in->header.command_id = WIRED_REPEATER_AUTH_STREAM_REQ;
> + verify_mprime_in->header.status = ME_HDCP_STATUS_SUCCESS;
> + verify_mprime_in->header.buffer_len =
>   WIRED_CMD_BUF_LEN_REPEATER_AUTH_STREAM_REQ_MIN_IN;
>  
> - verify_mprime_in.port.integrated_port_type = data->port_type;
> - verify_mprime_in.port.physical_port = (u8)data->fw_ddi;
> - verify_mprime_in.port.attached_transcoder = (u8)data->fw_tc;
> + verify_mprime_in->port.integrated_port_type = data->port_type;
> + verify_mprime_in->port.physical_port = (u8)data->fw_ddi;
> + verify_mprime_in->port.attached_transcoder = (u8)data->fw_tc;
> +
> + memcpy(verify_mprime_in->m_prime, stream_ready->m_prime, 
> HDCP_2_2_MPRIME_LEN);
> + drm_hdcp_cpu_to_be24(verify_mprime_in->seq_num_m, data->seq_num_m);
>  
> - memcpy(verify_mprime_in.m_prime, stream_ready->m_prime,
> -HDCP_2_2_MPRIME_LEN);
> - drm_hdcp_cpu_to_be24(verify_mprime_in.seq_num_m, data->seq_num_m);
> - memcpy(verify_mprime_in.streams, data->streams,
> + memcpy(verify_mprime_in->streams, data->streams,
>  array_size(data->k, sizeof(*data->streams)));

Please, use flex_array_size() instead of array_size() here, like this:

memcpy(verify_mprime_in->streams, data->streams,
   flex_array_size(verify_mprime_in, streams, data->k));


Thanks
--
Gustavo

>  
> - verify_mprime_in.k = cpu_to_be16(data->k);
> + verify_mprime_in->k = cpu_to_be16(data->k);
>  
> - byte = mei_cldev_send(cldev, (u8 *)_mprime_in,
> -   sizeof(verify_mprime_in));
> + byte = mei_cldev_send(cldev, (u8 *)_mprime_in, cmd_size);
> + kfree(verify_mprime_in);
>   if (byte < 0) {
>   dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
>   return byte;
> 


Re: [PATCH] cpufreq: intel_pstate: Implement passive mode with HWP enabled

2020-07-29 Thread Rafael J. Wysocki
On Wednesday, July 29, 2020 7:46:08 AM CEST Francisco Jerez wrote:
> 
> --==-=-=
> Content-Type: multipart/mixed; boundary="=-=-="
> 
> --=-=-=
> Content-Type: text/plain; charset=utf-8
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> "Rafael J. Wysocki"  writes:
> 
> > On Tuesday, July 28, 2020 4:32:22 AM CEST Francisco Jerez wrote:
> >>
> >> "Rafael J. Wysocki"  writes:
> >>=20
> >> > On Tuesday, July 21, 2020 1:20:14 AM CEST Francisco Jerez wrote:
> >> >
> >> > [cut]
> >> >
> >> >> >
> >> >> > However, in the active mode the only updater of hwp_req_cached is
> >> >> > intel_pstate_hwp_set() and this patch doesn't introduce any
> >> >> > differences in behavior in that case.
> >> >> >
> >> >>=3D20
> >> >> intel_pstate_hwp_set() is the only updater, but there are other
> >> >> consumers that can get out of sync with the HWP request value written=
>  by
> >> >> intel_pstate_set_energy_pref_index().  intel_pstate_hwp_boost_up() se=
> ems
> >> >> like the most concerning example I named earlier.
> >> >>=3D20
> >> >> >> > So there may be a short time window after the
> >> >> >> > intel_pstate_set_energy_pref_index() invocation in which the new=
>  EPP
> >> >> >> > value may not be in effect, but in general there is no guarantee=
>  th=3D
> >> at
> >> >> >> > the new EPP will take effect immediately after updating the MSR
> >> >> >> > anyway, so that race doesn't matter.
> >> >> >> >
> >> >> >> > That said, that race is avoidable, but I was thinking that tryin=
> g to
> >> >> >> > avoid it might not be worth it.  Now I see a better way to avoid=
>  it,
> >> >> >> > though, so I'm going to update the patch to that end.
> >> >> >> >
> >> >> >> >> Seems like a bug to me.
> >> >> >> >
> >> >> >> > It is racy, but not every race is a bug.
> >> >> >> >
> >> >> >>
> >> >> >> Still seems like there is a bug in intel_pstate_set_energy_pref_in=
> dex=3D
> >> ()
> >> >> >> AFAICT.
> >> >> >
> >> >> > If there is a bug, then what exactly is it, from the users' perspec=
> tiv=3D
> >> e?
> >> >> >
> >> >>=3D20
> >> >> It can be reproduced easily as follows:
> >> >>=3D20
> >> >> | echo 1 > /sys/devices/system/cpu/intel_pstate/hwp_dynamic_boost
> >> >> | for p in /sys/devices/system/cpu/cpufreq/policy*/energy_performance=
> _pr=3D
> >> eference; do echo performance > $p; done
> >> >
> >> > Is this the active mode or the passive mode with the $subject patch ap=
> pli=3D
> >> ed?
> >> >
> >> > If the former, the issue is there regardless of the patch, so it needs=
>  to=3D
> >>  be
> >> > fixed.
> >> >
> >> > If the latter, there should be no effect of hwp_dynamic_boost (which w=
> as
> >> > overlooked by me).
> >> >
> >>=20
> >> This seems to be a problem in active mode only, so yeah the bug exists
> >> regardless of your patch, but the fix is likely to allow you to simplify
> >> this series slightly if it allows you to take full advantage of
> >> hwp_req_cached and drop the additional EPP cache.
> >
> > The additional EPP cache is there to avoid synchronizing the scheduler
> > context directly with a random process running on another CPU and doing
> > things that may take time.
> >
> > The difference between the active mode and the passive mode in this respe=
> ct
> > is that in the latter case hwp_req_cached generally needs to be updated f=
> rom
> > the scheduler context, whereas in the former case it does not.
> >
> 
> Hm, that's unfortunate.  Though I'd be surprised to see any appreciable
> performance penalty from synchronizing with a sysfs handler that should
> hardly ever be called.  Anyway thanks for the fix.

No problem.

> > [cut]
> >
> >> >> No, I explicitly dismissed that in my previous reply.
> >> >
> >> > But at the same time you seem to agree that without the non-CPU compon=
> ent
> >> > (or thermal pressure) the existing CPU performance scaling would be
> >> > sufficient.
> >> >
> >>=20
> >> Yes, but not necessarily in order to allow the non-CPU component to draw
> >> more power as you said above, but also because the existence of a
> >> bottleneck in a non-CPU component gives us an opportunity to improve the
> >> energy efficiency of the CPU, regardless of whether that allows the
> >> workload to run faster.
> >
> > But why would the bottleneck be there otherwise?
> >
> 
> Because some resource of the system (e.g. memory bandwidth, GPU fill
> rate) may be close to 100% utilized, causing a bottleneck for reasons
> unrelated to its energy usage.

Well, not quite.  Or at least in that case the performance cannot be improved
by limiting the CPU frequency below the frequency looked for by scaling
governors, AFAICS.

Scaling governors generally look for the maximum frequency at which there is no
CPU idle time in the workload.  At that frequency the CPU time required by the
workload to achieve the maximum performance is equal to the total CPU time
available to it.  I till refer to that frequency as the maximum effective
frequency (MEF) of the workload.

By definition, running at 

Re: [PATCH v17 18/21] mm/lru: introduce the relock_page_lruvec function

2020-07-29 Thread Alexander Duyck
On Sat, Jul 25, 2020 at 6:00 AM Alex Shi  wrote:
>
> Use this new function to replace repeated same code, no func change.
>
> Signed-off-by: Alex Shi 
> Cc: Johannes Weiner 
> Cc: Andrew Morton 
> Cc: Thomas Gleixner 
> Cc: Andrey Ryabinin 
> Cc: Matthew Wilcox 
> Cc: Mel Gorman 
> Cc: Konstantin Khlebnikov 
> Cc: Hugh Dickins 
> Cc: Tejun Heo 
> Cc: linux-kernel@vger.kernel.org
> Cc: cgro...@vger.kernel.org
> Cc: linux...@kvack.org
> ---
>  include/linux/memcontrol.h | 40 
>  mm/mlock.c |  9 +
>  mm/swap.c  | 33 +++--
>  mm/vmscan.c|  8 +---
>  4 files changed, 49 insertions(+), 41 deletions(-)
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 258901021c6c..6e670f991b42 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -1313,6 +1313,46 @@ static inline void 
> unlock_page_lruvec_irqrestore(struct lruvec *lruvec,
> spin_unlock_irqrestore(>lru_lock, flags);
>  }
>
> +/* Don't lock again iff page's lruvec locked */
> +static inline struct lruvec *relock_page_lruvec_irq(struct page *page,
> +   struct lruvec *locked_lruvec)
> +{
> +   struct pglist_data *pgdat = page_pgdat(page);
> +   bool locked;
> +
> +   rcu_read_lock();
> +   locked = mem_cgroup_page_lruvec(page, pgdat) == locked_lruvec;
> +   rcu_read_unlock();
> +
> +   if (locked)
> +   return locked_lruvec;
> +
> +   if (locked_lruvec)
> +   unlock_page_lruvec_irq(locked_lruvec);
> +
> +   return lock_page_lruvec_irq(page);
> +}
> +
> +/* Don't lock again iff page's lruvec locked */
> +static inline struct lruvec *relock_page_lruvec_irqsave(struct page *page,
> +   struct lruvec *locked_lruvec, unsigned long *flags)
> +{
> +   struct pglist_data *pgdat = page_pgdat(page);
> +   bool locked;
> +
> +   rcu_read_lock();
> +   locked = mem_cgroup_page_lruvec(page, pgdat) == locked_lruvec;
> +   rcu_read_unlock();
> +
> +   if (locked)
> +   return locked_lruvec;
> +
> +   if (locked_lruvec)
> +   unlock_page_lruvec_irqrestore(locked_lruvec, *flags);
> +
> +   return lock_page_lruvec_irqsave(page, flags);
> +}
> +

So looking these over they seem to be pretty inefficient for what they
do. Basically in worst case (locked_lruvec == NULL) you end up calling
mem_cgoup_page_lruvec and all the rcu_read_lock/unlock a couple times
for a single page. It might make more sense to structure this like:
if (locked_lruvec) {
if (lruvec_holds_page_lru_lock(page, locked_lruvec))
return locked_lruvec;

unlock_page_lruvec_irqrestore(locked_lruvec, *flags);
}
return lock_page_lruvec_irqsave(page, flags);

The other piece that has me scratching my head is that I wonder if we
couldn't do this without needing the rcu_read_lock. For example, what
if we were to compare the page mem_cgroup pointer to the memcg back
pointer stored in the mem_cgroup_per_node? It seems like ordering
things this way would significantly reduce the overhead due to the
pointer chasing to see if the page is in the locked lruvec or not.

>  #ifdef CONFIG_CGROUP_WRITEBACK
>
>  struct wb_domain *mem_cgroup_wb_domain(struct bdi_writeback *wb);
> diff --git a/mm/mlock.c b/mm/mlock.c
> index 5d40d259a931..bc2fb3bfbe7a 100644
> --- a/mm/mlock.c
> +++ b/mm/mlock.c
> @@ -303,17 +303,10 @@ static void __munlock_pagevec(struct pagevec *pvec, 
> struct zone *zone)
> /* Phase 1: page isolation */
> for (i = 0; i < nr; i++) {
> struct page *page = pvec->pages[i];
> -   struct lruvec *new_lruvec;
>
> /* block memcg change in mem_cgroup_move_account */
> lock_page_memcg(page);
> -   new_lruvec = mem_cgroup_page_lruvec(page, page_pgdat(page));
> -   if (new_lruvec != lruvec) {
> -   if (lruvec)
> -   unlock_page_lruvec_irq(lruvec);
> -   lruvec = lock_page_lruvec_irq(page);
> -   }
> -
> +   lruvec = relock_page_lruvec_irq(page, lruvec);
> if (TestClearPageMlocked(page)) {
> /*
>  * We already have pin from follow_page_mask()
> diff --git a/mm/swap.c b/mm/swap.c
> index 09edac441eb6..6d9c7288f7de 100644
> --- a/mm/swap.c
> +++ b/mm/swap.c
> @@ -209,19 +209,12 @@ static void pagevec_lru_move_fn(struct pagevec *pvec,
>
> for (i = 0; i < pagevec_count(pvec); i++) {
> struct page *page = pvec->pages[i];
> -   struct lruvec *new_lruvec;
>
> /* block memcg migration during page moving between lru */
> if (!TestClearPageLRU(page))
> continue;
>
> -   new_lruvec = mem_cgroup_page_lruvec(page, page_pgdat(page));
> -   if 

Re: [Intel-gfx] [PATCH v12 2/3] drm/i915: add syncobj timeline support

2020-07-29 Thread Linus Torvalds
On Wed, Jul 29, 2020 at 5:24 AM Daniel Vetter  wrote:
>
> Do we have a access_ok_array or so? Instead of duplicating overflow checks
> everywhere and getting it all wrong ...

I really really think you should get away from access_ok() entirely.

Please just get rid of it, and use "copy_from_user()" instead.

Seriously.

access_ok() is completely wrong, because

 (a) it doesn't actually protect from any fault returns, it only doe
sthe high-level check of "is the pointer even ok".

So you can't say "ok, I did access_ok(), so I don't have to check the
return value", and you're actually making the source code more
complicated, and only introducing the possibility of bugs.

Overflow is just _one_ such bug. Missing the access_ok() entirely
because it was in some caller but not another is another common bug.

 (b) it no longer even makes the code faster.

It never really did for the the copy_to/from_user() case _anyway_, it
was always for the "I will now do several get/put_user() accesses and
I only want to do the range check once".

And that has simply not been true for the last few CPU generations -
because the cost isn't in the range check any more. Now allk the real
costs are about CLAC/STAC. The range check takes two cycles and
schedules well (so it's generally not even visible). The CLAC/STAC
takes 30+ cycles, and stalls the pipeline.

>Similar I guess for copy_from/to_user_array.

No. I refuse to add complexity onto the garbage that is access_ok().

Just remove it. It's not helping. People who think it's helping
haven't actually looked at profiles, or are working with hardware that
is no longer relevant.

Linus


[PATCH] interconnect: Show bandwidth for disabled paths as zero in debugfs

2020-07-29 Thread Matthias Kaehlcke
For disabled paths the 'interconnect_summary' in debugfs currently shows
the orginally requested bandwidths. This is confusing, since the bandwidth
requests aren't active. Instead show the bandwidths for disabled
paths/requests as zero.

Signed-off-by: Matthias Kaehlcke 
---

 drivers/interconnect/core.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
index 609e206bf598..3491175304d1 100644
--- a/drivers/interconnect/core.c
+++ b/drivers/interconnect/core.c
@@ -55,12 +55,18 @@ static int icc_summary_show(struct seq_file *s, void *data)
 
icc_summary_show_one(s, n);
hlist_for_each_entry(r, >req_list, req_node) {
+   u32 avg_bw = 0, peak_bw = 0;
+
if (!r->dev)
continue;
 
+   if (r->enabled) {
+   avg_bw = r->avg_bw;
+   peak_bw = r->peak_bw;
+   }
+
seq_printf(s, "  %-27s %12u %12u %12u\n",
-  dev_name(r->dev), r->tag, r->avg_bw,
-  r->peak_bw);
+  dev_name(r->dev), r->tag, avg_bw, 
peak_bw);
}
}
}
-- 
2.28.0.rc0.142.g3c755180ce-goog



Re: [PATCH 0/2] locking/qspinlock: Break qspinlock_types.h header loop

2020-07-29 Thread Sergey Senozhatsky
On (20/07/29 22:28), Herbert Xu wrote:
> This miniseries breaks a header loop involving qspinlock_types.h.
> The issue is that qspinlock_types.h includes atomic.h, which then
> eventually includes kernel.h which could lead back to the original
> file via spinlock_types.h.
> 
> The first patch moves ATOMIC_INIT into linux/types.h while the second
> patch actuallys breaks the loop by no longer including atomic.h
> in qspinlock_types.h.

Thanks for staying on this.

I pulled locking/header, run some cross-compilation tests locally
(powerpc, arm, arm64, x86) and pushed printk/for-next. Let's see.

-ss


Re: [PATCH 3/7] ARM: s3c: Remove plat-samsung/.../samsung-time.h

2020-07-29 Thread Tomasz Figa
2020年7月29日(水) 18:11 Krzysztof Kozlowski :
>
> Remove the arch/arm/plat-samsung/include/plat/samsung-time.h header and
> move the contents to common.h headers in mach-s3c24xx and mach-s3c64xx.
> The definition of declared functions is already in common.c in mach
> directories, so it is logically to put declaration next to them.
>
> This is also one step further towards removal of plat-samsung directory
> and it fixes W=1 build warnings:
>
> arch/arm/mach-s3c64xx/common.c:174:13: warning:
> no previous prototype for 'samsung_set_timer_source' 
> [-Wmissing-prototypes]
>   174 | void __init samsung_set_timer_source(unsigned int event, unsigned 
> int source)
>
> arch/arm/mach-s3c64xx/common.c:180:13: warning:
> no previous prototype for 'samsung_timer_init' [-Wmissing-prototypes]
>   180 | void __init samsung_timer_init(void)
>
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  arch/arm/mach-s3c24xx/common.h| 12 +
>  arch/arm/mach-s3c24xx/mach-amlm5900.c |  2 --
>  arch/arm/mach-s3c24xx/mach-anubis.c   |  1 -
>  arch/arm/mach-s3c24xx/mach-at2440evb.c|  1 -
>  arch/arm/mach-s3c24xx/mach-bast.c |  1 -
>  arch/arm/mach-s3c24xx/mach-gta02.c|  1 -
>  arch/arm/mach-s3c24xx/mach-h1940.c|  1 -
>  arch/arm/mach-s3c24xx/mach-jive.c |  1 -
>  arch/arm/mach-s3c24xx/mach-mini2440.c |  1 -
>  arch/arm/mach-s3c24xx/mach-n30.c  |  1 -
>  arch/arm/mach-s3c24xx/mach-nexcoder.c |  1 -
>  arch/arm/mach-s3c24xx/mach-osiris.c   |  1 -
>  arch/arm/mach-s3c24xx/mach-otom.c |  1 -
>  arch/arm/mach-s3c24xx/mach-qt2410.c   |  1 -
>  arch/arm/mach-s3c24xx/mach-rx1950.c   |  1 -
>  arch/arm/mach-s3c24xx/mach-rx3715.c   |  1 -
>  arch/arm/mach-s3c24xx/mach-smdk2410.c |  1 -
>  arch/arm/mach-s3c24xx/mach-smdk2413.c |  1 -
>  arch/arm/mach-s3c24xx/mach-smdk2416.c |  1 -
>  arch/arm/mach-s3c24xx/mach-smdk2440.c |  1 -
>  arch/arm/mach-s3c24xx/mach-smdk2443.c |  1 -
>  arch/arm/mach-s3c24xx/mach-tct_hammer.c   |  1 -
>  arch/arm/mach-s3c24xx/mach-vr1000.c   |  1 -
>  arch/arm/mach-s3c24xx/mach-vstms.c|  1 -
>  arch/arm/mach-s3c64xx/common.h| 13 ++
>  arch/arm/mach-s3c64xx/mach-anw6410.c  |  1 -
>  arch/arm/mach-s3c64xx/mach-crag6410.c |  1 -
>  arch/arm/mach-s3c64xx/mach-hmt.c  |  1 -
>  arch/arm/mach-s3c64xx/mach-mini6410.c |  1 -
>  arch/arm/mach-s3c64xx/mach-ncp.c  |  1 -
>  arch/arm/mach-s3c64xx/mach-real6410.c |  1 -
>  arch/arm/mach-s3c64xx/mach-smartq.c   |  1 -
>  arch/arm/mach-s3c64xx/mach-smartq5.c  |  1 -
>  arch/arm/mach-s3c64xx/mach-smartq7.c  |  1 -
>  arch/arm/mach-s3c64xx/mach-smdk6400.c |  1 -
>  arch/arm/mach-s3c64xx/mach-smdk6410.c |  1 -
>  .../plat-samsung/include/plat/samsung-time.h  | 26 ---
>  37 files changed, 25 insertions(+), 61 deletions(-)
>  delete mode 100644 arch/arm/plat-samsung/include/plat/samsung-time.h
>

For the s3c64xx bits:

Reviewed-by: Tomasz Figa 

I suppose the next step would be renaming those functions to s3c24xx_*
and s3c64xx_* to avoid naming collisions?

Best regards,
Tomasz


Re: [RFC PATCH v5 12/14] gpu: host1x: mipi: Keep MIPI clock enabled till calibration is done

2020-07-29 Thread Sowjanya Komatineni



On 7/29/20 10:08 AM, Dmitry Osipenko wrote:

28.07.2020 19:04, Sowjanya Komatineni пишет:
...

+void tegra_mipi_cancel_calibration(struct tegra_mipi_device *device)
+{

Doesn't MIPI_CAL need to be reset here?

No need to reset MIPI CAL

Could you please explain why. There is a calibration state-machine that
apparently needs to be returned into initial state, does it return by
itself?

TRM says that MIPI block needs to be reset before of starting
calibration process. The reset is completely missing in the driver, I
assume it needs to be corrected with another patch.


TRM documented incorrectly. There is no need to reset MIPI_CAL.

MIPI CAL is FSM and it does not hang and done bit is to indicate if 
results are applied to pads or not.


If we don't see done bit set meaning, MIPI CAL did not see LP-11 and 
results are not applied to pads.


Also while multiple streams can happen in parallel and we can't reset 
MIPI CAL as other CSI channel streams (using other pads) may also be 
going thru calibration process in parallel depending and also DSI pads 
also are calibrated thru same MIPI CAL controller.





[PATCH] Revert "kconfig: qconf: Change title for the item window"

2020-07-29 Thread Masahiro Yamada
This reverts commit 5752ff07fd90d764d96e3c586cc95c09598abfdd.

It added pointless dead code to ConfigList:ConfigList().

The constructor of ConfigList has the initializer, mode(singleMode).

if (mode == symbolMode)
   setHeaderLabels(QStringList() << "Item" << "Name" << "N" << "M" << 
"Y" << "Value");
else
   setHeaderLabels(QStringList() << "Option" << "Name" << "N" << "M" << 
"Y" << "Value");

... always takes the else part.

The change to ConfigList::updateSelection() is strange too.
When you click the split view icon for the first time, the titles in
both windows show "Option". After you click something in the right
window, the title suddenly changes to "Item".

ConfigList::updateSelection() is not the right place to do this,
at least. It was not a good idea, I think.

Signed-off-by: Masahiro Yamada 
---

 scripts/kconfig/qconf.cc | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
index 1c61c768b99e..dfd0b5863a9b 100644
--- a/scripts/kconfig/qconf.cc
+++ b/scripts/kconfig/qconf.cc
@@ -308,10 +308,7 @@ ConfigList::ConfigList(ConfigView* p, const char *name)
setVerticalScrollMode(ScrollPerPixel);
setHorizontalScrollMode(ScrollPerPixel);
 
-   if (mode == symbolMode)
-   setHeaderLabels(QStringList() << "Item" << "Name" << "N" << "M" 
<< "Y" << "Value");
-   else
-   setHeaderLabels(QStringList() << "Option" << "Name" << "N" << 
"M" << "Y" << "Value");
+   setHeaderLabels(QStringList() << "Option" << "Name" << "N" << "M" << 
"Y" << "Value");
 
connect(this, SIGNAL(itemSelectionChanged(void)),
SLOT(updateSelection(void)));
@@ -392,11 +389,6 @@ void ConfigList::updateSelection(void)
struct menu *menu;
enum prop_type type;
 
-   if (mode == symbolMode)
-   setHeaderLabels(QStringList() << "Item" << "Name" << "N" << "M" 
<< "Y" << "Value");
-   else
-   setHeaderLabels(QStringList() << "Option" << "Name" << "N" << 
"M" << "Y" << "Value");
-
if (selectedItems().count() == 0)
return;
 
-- 
2.25.1



Re: [PATCH 2/7] ARM: s3c64xx: Include header to fix -Wmissing-prototypes

2020-07-29 Thread Tomasz Figa
2020年7月29日(水) 18:11 Krzysztof Kozlowski :
>
> Include the spi-s3c64xx.h header to fix W=1 build warning:
>
> arch/arm/mach-s3c64xx/setup-spi.c:11:5: warning:
> no previous prototype for 's3c64xx_spi0_cfg_gpio' 
> [-Wmissing-prototypes]
>11 | int s3c64xx_spi0_cfg_gpio(void)
>
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  arch/arm/mach-s3c64xx/setup-spi.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-s3c64xx/setup-spi.c 
> b/arch/arm/mach-s3c64xx/setup-spi.c
> index 39dfae1f46e7..03c9d296bb0f 100644
> --- a/arch/arm/mach-s3c64xx/setup-spi.c
> +++ b/arch/arm/mach-s3c64xx/setup-spi.c
> @@ -4,6 +4,7 @@
>  // http://www.samsung.com/
>
>  #include 
> +#include 
>  #include 
>  #include 
>
> --
> 2.17.1
>

Reviewed-by: Tomasz Figa 

Best regards,
Tomasz


[PATCH] MAINTAINERS: edac: socfpga: transfer SoCFPGA EDAC maintainership

2020-07-29 Thread Dinh Nguyen
Thor Thayer is leaving Intel and will no longer be able to maintain the
EDAC for SoCFPGA, thus transfer maintainership to Dinh Nguyen.

Signed-off-by: Dinh Nguyen 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index f0569cf304ca..c53fc9febf12 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2466,7 +2466,7 @@ S:Maintained
 F: drivers/clk/socfpga/
 
 ARM/SOCFPGA EDAC SUPPORT
-M: Thor Thayer 
+M: Dinh Nguyen 
 S: Maintained
 F: drivers/edac/altera_edac.
 
-- 
2.17.1



Re: [PATCH v3 18/19] firmware: Add request_partial_firmware_into_buf()

2020-07-29 Thread Kees Cook
On Wed, Jul 29, 2020 at 08:22:17AM +0200, Takashi Iwai wrote:
> On Wed, 29 Jul 2020 03:17:39 +0200,
> Luis Chamberlain wrote:
> > 
> > Long ago Takashi had some points about this strategy breaking
> > compressed file use. Was that considered?
> 
> As long as I read the patch, it tries to skip both the compressed and
> the fallback loading when FW_OPT_PARTIAL is set, which is good.
> 
> However...
> 
> > > @@ -771,18 +805,20 @@ _request_firmware(const struct firmware 
> > > **firmware_p, const char *name,
> > >   }
> > >  
> > >   ret = _request_firmware_prepare(, name, device, buf, size,
> > > - opt_flags);
> > > + offset, opt_flags);
> > >   if (ret <= 0) /* error or already assigned */
> > >   goto out;
> > >  
> > >   ret = fw_get_filesystem_firmware(device, fw->priv, "", NULL);
> > > -#ifdef CONFIG_FW_LOADER_COMPRESS
> > > - if (ret == -ENOENT)
> > > +
> > > + /* Only full reads can support decompression, platform, and sysfs. */
> > > + if (!(opt_flags & FW_OPT_PARTIAL))
> > > + nondirect = true;
> > > +
> > > + if (ret == -ENOENT && nondirect)
> > >   ret = fw_get_filesystem_firmware(device, fw->priv, ".xz",
> > >fw_decompress_xz);
> > > -#endif
> 
> ... by dropping this ifdef, the fw loader would try to access *.xz
> file unnecessarily even if CONFIG_FW_LOADER_COMPRESS is disabled.

Ah, good point. I'd added the -ENOENT fw_decompress_xz, but I take your
point about the needless access. I will switch this back to an #ifdef.

-- 
Kees Cook


[PATCH v5 2/2] remoteproc: core: Register the character device interface

2020-07-29 Thread Siddharth Gupta
Add the character device during rproc_add. This would create
a character device node at /dev/remoteproc. Userspace
applications can interact with the remote processor using this
interface.

Signed-off-by: Rishabh Bhatnagar 
Signed-off-by: Siddharth Gupta 
---
 drivers/remoteproc/remoteproc_core.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/remoteproc/remoteproc_core.c 
b/drivers/remoteproc/remoteproc_core.c
index 277d3bf..7f90eee 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1986,6 +1986,11 @@ int rproc_add(struct rproc *rproc)
/* create debugfs entries */
rproc_create_debug_dir(rproc);
 
+   /* add char device for this remoteproc */
+   ret = rproc_char_device_add(rproc);
+   if (ret < 0)
+   return ret;
+
/*
 * Remind ourselves the remote processor has been attached to rather
 * than booted by the remoteproc core.  This is important because the
@@ -2262,6 +2267,7 @@ int rproc_del(struct rproc *rproc)
mutex_unlock(>lock);
 
rproc_delete_debug_dir(rproc);
+   rproc_char_device_remove(rproc);
 
/* the rproc is downref'ed as soon as it's removed from the klist */
mutex_lock(_list_mutex);
@@ -2430,6 +2436,7 @@ static int __init remoteproc_init(void)
 {
rproc_init_sysfs();
rproc_init_debugfs();
+   rproc_init_cdev();
rproc_init_panic();
 
return 0;
-- 
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH v5 0/2] Add character device interface to remoteproc

2020-07-29 Thread Siddharth Gupta
This patch series adds a character device interface to remoteproc
framework. Currently there is only a sysfs interface which the userspace
clients can use. If a usersapce application crashes after booting
the remote processor through the sysfs interface the remote processor
does not get any indication about the crash. It might still assume
that the  application is running.
For example modem uses remotefs service to data from disk/flash memory.
If the remotefs service crashes, modem still keeps on requesting data
which might lead to crash on modem. Even if the service is restarted the
file handles modem requested previously would become stale.
Adding a character device interface makes the remote processor tightly
coupled with the user space application. A crash of the application
leads to a close on the file descriptors therefore shutting down the
remoteproc.

Changelog:
v4 -> v5:
- Addressed comments from Bjorn and Mathieu.
- Added cdev_set_parent call to set remoteproc device as parent of cdev.
- Fixed error with rproc_major introduced in the last patch.
- Fixed implementation for compat calls. With previous implementation 64bit
  userspace applications failed to perform the ioctl call, returning errno 25,
  or "Inappropriate ioctl for device."
- Removed exit functions from the driver as remoteproc framework is statically
  compiled.

v3 -> v4:
- Addressed comments from Mathieu and Arnaud.
- Added locks while writing/reading from the automatic-shutdown-on-release bool.
- Changed return value when failing to copy to/from userspace.
- Changed logic for calling shutdown on release.
- Moved around code after the increase of max line length from 80 to 100.
- Moved the call adding character device before device_add in rproc_add to add
  both sysfs and character device interface together.

v2 -> v3:
- Move booting of remoteproc from open to a write call.
- Add ioctl interface for future functionality extension.
- Add an ioctl call to default to rproc shutdown on release.

v1 -> v2:
- Fixed comments from Bjorn and Matthew.

Siddharth Gupta (2):
  remoteproc: Add remoteproc character device interface
  remoteproc: core: Register the character device interface

 Documentation/userspace-api/ioctl/ioctl-number.rst |   1 +
 drivers/remoteproc/Kconfig |   9 ++
 drivers/remoteproc/Makefile|   1 +
 drivers/remoteproc/remoteproc_cdev.c   | 124 +
 drivers/remoteproc/remoteproc_core.c   |   7 ++
 drivers/remoteproc/remoteproc_internal.h   |  28 +
 include/linux/remoteproc.h |   5 +
 include/uapi/linux/remoteproc_cdev.h   |  37 ++
 8 files changed, 212 insertions(+)
 create mode 100644 drivers/remoteproc/remoteproc_cdev.c
 create mode 100644 include/uapi/linux/remoteproc_cdev.h

-- 
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH v5 1/2] remoteproc: Add remoteproc character device interface

2020-07-29 Thread Siddharth Gupta
Add the character device interface into remoteproc framework.
This interface can be used in order to boot/shutdown remote
subsystems and provides a basic ioctl based interface to implement
supplementary functionality. An ioctl call is implemented to enable
the shutdown on release feature which will allow remote processors to
be shutdown when the controlling userpsace application crashes or hangs.

Signed-off-by: Rishabh Bhatnagar 
Signed-off-by: Siddharth Gupta 
---
 Documentation/userspace-api/ioctl/ioctl-number.rst |   1 +
 drivers/remoteproc/Kconfig |   9 ++
 drivers/remoteproc/Makefile|   1 +
 drivers/remoteproc/remoteproc_cdev.c   | 124 +
 drivers/remoteproc/remoteproc_internal.h   |  28 +
 include/linux/remoteproc.h |   5 +
 include/uapi/linux/remoteproc_cdev.h   |  37 ++
 7 files changed, 205 insertions(+)
 create mode 100644 drivers/remoteproc/remoteproc_cdev.c
 create mode 100644 include/uapi/linux/remoteproc_cdev.h

diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst 
b/Documentation/userspace-api/ioctl/ioctl-number.rst
index 59472cd..2a19883 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -339,6 +339,7 @@ Code  Seq#Include File  
 Comments
 0xB4  00-0F  linux/gpio.h

 0xB5  00-0F  uapi/linux/rpmsg.h  

 0xB6  alllinux/fpga-dfl.h
+0xB7  alluapi/linux/remoteproc_cdev.h

 0xC0  00-0F  linux/usb/iowarrior.h
 0xCA  00-0F  uapi/misc/cxl.h
 0xCA  10-2F  uapi/misc/ocxl.h
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 48315dc..c6659dfe 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -14,6 +14,15 @@ config REMOTEPROC
 
 if REMOTEPROC
 
+config REMOTEPROC_CDEV
+   bool "Remoteproc character device interface"
+   help
+ Say y here to have a character device interface for the remoteproc
+ framework. Userspace can boot/shutdown remote processors through
+ this interface.
+
+ It's safe to say N if you don't want to use this interface.
+
 config IMX_REMOTEPROC
tristate "IMX6/7 remoteproc support"
depends on ARCH_MXC
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 4d4307d..3dfa28e 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -10,6 +10,7 @@ remoteproc-y  += remoteproc_debugfs.o
 remoteproc-y   += remoteproc_sysfs.o
 remoteproc-y   += remoteproc_virtio.o
 remoteproc-y   += remoteproc_elf_loader.o
+obj-$(CONFIG_REMOTEPROC_CDEV)  += remoteproc_cdev.o
 obj-$(CONFIG_IMX_REMOTEPROC)   += imx_rproc.o
 obj-$(CONFIG_INGENIC_VPU_RPROC)+= ingenic_rproc.o
 obj-$(CONFIG_MTK_SCP)  += mtk_scp.o mtk_scp_ipi.o
diff --git a/drivers/remoteproc/remoteproc_cdev.c 
b/drivers/remoteproc/remoteproc_cdev.c
new file mode 100644
index 000..a7ac11c
--- /dev/null
+++ b/drivers/remoteproc/remoteproc_cdev.c
@@ -0,0 +1,124 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Character device interface driver for Remoteproc framework.
+ *
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "remoteproc_internal.h"
+
+#define NUM_RPROC_DEVICES  64
+static dev_t rproc_major;
+
+static ssize_t rproc_cdev_write(struct file *filp, const char __user *buf, 
size_t len, loff_t *pos)
+{
+   struct rproc *rproc = container_of(filp->f_inode->i_cdev, struct rproc, 
cdev);
+   int ret = 0;
+   char cmd[10];
+
+   if (!len || len > sizeof(cmd))
+   return -EINVAL;
+
+   ret = copy_from_user(cmd, buf, len);
+   if (ret)
+   return -EFAULT;
+
+   if (!strncmp(cmd, "start", len)) {
+   if (rproc->state == RPROC_RUNNING)
+   return -EBUSY;
+
+   ret = rproc_boot(rproc);
+   } else if (!strncmp(cmd, "stop", len)) {
+   if (rproc->state != RPROC_RUNNING)
+   return -EINVAL;
+
+   rproc_shutdown(rproc);
+   } else {
+   dev_err(>dev, "Unrecognized option\n");
+   ret = -EINVAL;
+   }
+
+   return ret ? ret : len;
+}
+
+static long rproc_device_ioctl(struct file *filp, unsigned int ioctl, unsigned 
long arg)
+{
+   struct rproc *rproc = container_of(filp->f_inode->i_cdev, struct rproc, 
cdev);
+   void __user *argp = (void __user *)arg;
+   int32_t param;
+
+ 

Re: [PATCH 1/7] clk: samsung: s3c64xx: Declare s3c64xx_clk_init() in shared header

2020-07-29 Thread Tomasz Figa
2020年7月29日(水) 18:11 Krzysztof Kozlowski :
>
> The s3c64xx_clk_init() is defined and used by clk-s3c64xx driver and
> also used in mach-s3c64xx machine code.  Move the declaration to a
> header to fix W=1 build warning:
>
> drivers/clk/samsung/clk-s3c64xx.c:391:13: warning: no previous prototype 
> for 's3c64xx_clk_init' [-Wmissing-prototypes]
>   391 | void __init s3c64xx_clk_init(struct device_node *np, unsigned 
> long xtal_f,
>
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  MAINTAINERS   |  1 +
>  arch/arm/mach-s3c64xx/common.c|  1 +
>  arch/arm/mach-s3c64xx/common.h|  2 --
>  drivers/clk/samsung/clk-s3c64xx.c |  1 +
>  include/linux/clk/samsung.h   | 21 +
>  5 files changed, 24 insertions(+), 2 deletions(-)
>  create mode 100644 include/linux/clk/samsung.h
>

Reviewed-by: Tomasz Figa 

Best regards,
Tomasz


[PATCH v2] hv_utils: Add validation for untrusted Hyper-V values

2020-07-29 Thread Andres Beltran
For additional robustness in the face of Hyper-V errors or malicious
behavior, validate all values that originate from packets that Hyper-V
has sent to the guest in the host-to-guest ring buffer. Ensure that
invalid values cannot cause indexing off the end of the icversion_data
array in vmbus_prep_negotiate_resp().

Signed-off-by: Andres Beltran 
---
Changes in v2:
-Use ratelimited form of kernel logging to print error messages.

 drivers/hv/channel_mgmt.c |  17 ++-
 drivers/hv/hv_fcopy.c |  36 +++--
 drivers/hv/hv_kvp.c   | 122 +
 drivers/hv/hv_snapshot.c  |  89 +++--
 drivers/hv/hv_util.c  | 267 +++---
 include/linux/hyperv.h|   9 +-
 6 files changed, 332 insertions(+), 208 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 591106cf58fc..ed29f0f10f04 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -202,8 +202,8 @@ static u16 hv_get_dev_type(const struct vmbus_channel 
*channel)
  * Set up and fill in default negotiate response message.
  * Mainly used by Hyper-V drivers.
  */
-bool vmbus_prep_negotiate_resp(struct icmsg_hdr *icmsghdrp,
-   u8 *buf, const int *fw_version, int fw_vercnt,
+bool vmbus_prep_negotiate_resp(struct icmsg_hdr *icmsghdrp, u8 *buf,
+   u32 buflen, const int *fw_version, int 
fw_vercnt,
const int *srv_version, int srv_vercnt,
int *nego_fw_version, int *nego_srv_version)
 {
@@ -216,9 +216,7 @@ bool vmbus_prep_negotiate_resp(struct icmsg_hdr *icmsghdrp,
struct icmsg_negotiate *negop;
 
icmsghdrp->icmsgsize = 0x10;
-   negop = (struct icmsg_negotiate *)[
-   sizeof(struct vmbuspipe_hdr) +
-   sizeof(struct icmsg_hdr)];
+   negop = (struct icmsg_negotiate *)[ICMSG_HDR];
 
icframe_major = negop->icframe_vercnt;
icframe_minor = 0;
@@ -226,6 +224,15 @@ bool vmbus_prep_negotiate_resp(struct icmsg_hdr *icmsghdrp,
icmsg_major = negop->icmsg_vercnt;
icmsg_minor = 0;
 
+   /* Validate negop packet */
+   if (icframe_major > IC_VERSION_NEGOTIATION_MAX_VER_COUNT ||
+   icmsg_major > IC_VERSION_NEGOTIATION_MAX_VER_COUNT ||
+   ICMSG_NEGOTIATE_PKT_SIZE(icframe_major, icmsg_major) > buflen) {
+   pr_err_ratelimited("Invalid icmsg negotiate - icframe_major: 
%u, icmsg_major: %u",
+  icframe_major, icmsg_major);
+   goto fw_error;
+   }
+
/*
 * Select the framework version number we will
 * support.
diff --git a/drivers/hv/hv_fcopy.c b/drivers/hv/hv_fcopy.c
index 5040d7e0cd9e..59ce85e00a02 100644
--- a/drivers/hv/hv_fcopy.c
+++ b/drivers/hv/hv_fcopy.c
@@ -235,15 +235,27 @@ void hv_fcopy_onchannelcallback(void *context)
if (fcopy_transaction.state > HVUTIL_READY)
return;
 
-   vmbus_recvpacket(channel, recv_buffer, HV_HYP_PAGE_SIZE * 2, ,
-);
-   if (recvlen <= 0)
+   if (vmbus_recvpacket(channel, recv_buffer, HV_HYP_PAGE_SIZE * 2, 
, )) {
+   pr_err_ratelimited("Fcopy request received. Could not read into 
recv buf\n");
return;
+   }
+
+   if (!recvlen)
+   return;
+
+   /* Ensure recvlen is big enough to read header data */
+   if (recvlen < ICMSG_HDR) {
+   pr_err_ratelimited("Fcopy request received. Packet length too 
small: %d\n",
+  recvlen);
+   return;
+   }
 
icmsghdr = (struct icmsg_hdr *)_buffer[
sizeof(struct vmbuspipe_hdr)];
+
if (icmsghdr->icmsgtype == ICMSGTYPE_NEGOTIATE) {
-   if (vmbus_prep_negotiate_resp(icmsghdr, recv_buffer,
+   if (vmbus_prep_negotiate_resp(icmsghdr,
+   recv_buffer, recvlen,
fw_versions, FW_VER_COUNT,
fcopy_versions, FCOPY_VER_COUNT,
NULL, _srv_version)) {
@@ -252,10 +264,14 @@ void hv_fcopy_onchannelcallback(void *context)
fcopy_srv_version >> 16,
fcopy_srv_version & 0x);
}
-   } else {
-   fcopy_msg = (struct hv_fcopy_hdr *)_buffer[
-   sizeof(struct vmbuspipe_hdr) +
-   sizeof(struct icmsg_hdr)];
+   } else if (icmsghdr->icmsgtype == ICMSGTYPE_FCOPY) {
+   /* Ensure recvlen is big enough to contain hv_fcopy_hdr */
+   if (recvlen < ICMSG_HDR + sizeof(struct hv_fcopy_hdr)) {
+   pr_err_ratelimited("Invalid Fcopy hdr. Packet length 
too small: %u\n",
+  recvlen);
+   return;
+   }
+

Re: [PATCH 5/7] ARM: samsung: Kill useless HAVE_S3C2410_WATCHDOG

2020-07-29 Thread Tomasz Figa
2020年7月29日(水) 19:02 Guenter Roeck :
>
> On Wed, Jul 29, 2020 at 06:09:40PM +0200, Krzysztof Kozlowski wrote:
> > A separate Kconfig option HAVE_S3C2410_WATCHDOG for Samsung SoCs does
> > not have sense, because:
> > 1. All ARMv7 and ARMv8 Samsung SoCs have watchdog,
> > 2. All architecture Kconfigs were selecting it (if WATCHDOG framework is
> >chosen),
> > 3. HAVE_S3C2410_WATCHDOG is doing nothing except being a dependency of
> >actual Samsung SoC watchdog driver, which is enabled manually by
> >specific defconfigs.
> >
> > HAVE_S3C2410_WATCHDOG can be safely removed.
> >
>
> That is not really correct. HAVE_S3C2410_WATCHDOG is used to ensure
> that users can only enable S3C2410_WATCHDOG if the watchdog actually
> exists in a system. With this change, it can be enabled for all
> architectures and platforms.
>
> NACK.
>
> Guenter
>

I'd side with Guenter on this. We better not flood users' screens with
options that are not relevant to their hardware.

An alternative here could be making CONFIG_S3C2410_WATCHDOG depend on
a general symbol for Samsung SoC support if there is such, but then,
are we 100% sure that all the Samsung SoCs would actually have exactly
this watchdog? If a new one shows up, one would have to bring back
this HAVE_S3C2410_WATCHDOG symbol.

Best regards,
Tomasz

> > Signed-off-by: Krzysztof Kozlowski 
> > ---
> >  arch/arm/Kconfig  | 1 -
> >  arch/arm/mach-exynos/Kconfig  | 1 -
> >  arch/arm/mach-s3c64xx/Kconfig | 2 --
> >  arch/arm/mach-s5pv210/Kconfig | 1 -
> >  arch/arm64/Kconfig.platforms  | 1 -
> >  drivers/watchdog/Kconfig  | 8 
> >  6 files changed, 14 deletions(-)
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 7564f293f107..fe95777af653 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -504,7 +504,6 @@ config ARCH_S3C24XX
> >   select GPIOLIB
> >   select GENERIC_IRQ_MULTI_HANDLER
> >   select HAVE_S3C2410_I2C if I2C
> > - select HAVE_S3C2410_WATCHDOG if WATCHDOG
> >   select HAVE_S3C_RTC if RTC_CLASS
> >   select NEED_MACH_IO_H
> >   select SAMSUNG_ATAGS
> > diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> > index f185cd3d4c62..d2d249706ebb 100644
> > --- a/arch/arm/mach-exynos/Kconfig
> > +++ b/arch/arm/mach-exynos/Kconfig
> > @@ -24,7 +24,6 @@ menuconfig ARCH_EXYNOS
> >   select HAVE_ARM_ARCH_TIMER if ARCH_EXYNOS5
> >   select HAVE_ARM_SCU if SMP
> >   select HAVE_S3C2410_I2C if I2C
> > - select HAVE_S3C2410_WATCHDOG if WATCHDOG
> >   select HAVE_S3C_RTC if RTC_CLASS
> >   select PINCTRL
> >   select PINCTRL_EXYNOS
> > diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
> > index ac3e3563487f..e208c2b48853 100644
> > --- a/arch/arm/mach-s3c64xx/Kconfig
> > +++ b/arch/arm/mach-s3c64xx/Kconfig
> > @@ -13,7 +13,6 @@ menuconfig ARCH_S3C64XX
> >   select GPIO_SAMSUNG if ATAGS
> >   select GPIOLIB
> >   select HAVE_S3C2410_I2C if I2C
> > - select HAVE_S3C2410_WATCHDOG if WATCHDOG
> >   select HAVE_TCM
> >   select PLAT_SAMSUNG
> >   select PM_GENERIC_DOMAINS if PM
> > @@ -165,7 +164,6 @@ config MACH_SMDK6410
> >   bool "SMDK6410"
> >   depends on ATAGS
> >   select CPU_S3C6410
> > - select HAVE_S3C2410_WATCHDOG if WATCHDOG
> >   select S3C64XX_SETUP_FB_24BPP
> >   select S3C64XX_SETUP_I2C1
> >   select S3C64XX_SETUP_IDE
> > diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
> > index 03984a791879..b3db1191e437 100644
> > --- a/arch/arm/mach-s5pv210/Kconfig
> > +++ b/arch/arm/mach-s5pv210/Kconfig
> > @@ -14,7 +14,6 @@ config ARCH_S5PV210
> >   select COMMON_CLK_SAMSUNG
> >   select GPIOLIB
> >   select HAVE_S3C2410_I2C if I2C
> > - select HAVE_S3C2410_WATCHDOG if WATCHDOG
> >   select HAVE_S3C_RTC if RTC_CLASS
> >   select PINCTRL
> >   select PINCTRL_EXYNOS
> > diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> > index cd58f8495c45..d235b27cf372 100644
> > --- a/arch/arm64/Kconfig.platforms
> > +++ b/arch/arm64/Kconfig.platforms
> > @@ -80,7 +80,6 @@ config ARCH_EXYNOS
> >   select EXYNOS_CHIPID
> >   select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
> >   select EXYNOS_PMU
> > - select HAVE_S3C2410_WATCHDOG if WATCHDOG
> >   select HAVE_S3C_RTC if RTC_CLASS
> >   select PINCTRL
> >   select PINCTRL_EXYNOS
> > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> > index 4f4687c46d38..ae86ea135d2b 100644
> > --- a/drivers/watchdog/Kconfig
> > +++ b/drivers/watchdog/Kconfig
> > @@ -478,16 +478,8 @@ config IXP4XX_WATCHDOG
> >
> > Say N if you are unsure.
> >
> > -config HAVE_S3C2410_WATCHDOG
> > - bool
> > - help
> > -   This will include watchdog timer support for Samsung SoCs. If
> > -   you want to include watchdog support for any machine, kindly
> > -   select this in the respective mach-/Kconfig file.
> > 

INVESTMENT PROPOSAL.

2020-07-29 Thread Daouda Ali
It’s my pleasure to contact you through this media because I need an
investment assistance in your country. However I have a profitable
investment proposal with  good interest to share with you, amounted
the sum of (Twenty Eight Million Four Hundred Thousand United State
Dollar ($28.400.000.00). If you  are willing to handle this project
kindly reply urgent to enable me provide you more information about
the investment funds and the project.

I am waiting to hear from you through this my private
email(daoudaali2...@gmail.com) so we can proceed further.

Best Regards.
Mr. Daouda Ali.


Re: [PATCH v4 1/5] dt-bindings: irqchip: Add PRU-ICSS interrupt controller bindings

2020-07-29 Thread David Lechner

On 7/28/20 4:18 AM, Grzegorz Jaszczyk wrote:

From: Suman Anna 

The Programmable Real-Time Unit and Industrial Communication Subsystem
(PRU-ICSS or simply PRUSS) contains an interrupt controller (INTC) that
can handle various system input events and post interrupts back to the
device-level initiators. The INTC can support upto 64 input events on


nit: "up to" is two separate words


most SoCs with individual control configuration and h/w prioritization.
These events are mapped onto 10 output interrupt lines through two levels
of many-to-one mapping support. Different interrupt lines are routed to
the individual PRU cores or to the host CPU or to other PRUSS instances.

The K3 AM65x and J721E SoCs have the next generation of the PRU-ICSS IP,
commonly called ICSSG. The ICSSG interrupt controller on K3 SoCs provide
a higher number of host interrupts (20 vs 10) and can handle an increased
number of input events (160 vs 64) from various SoC interrupt sources.

Add the bindings document for these interrupt controllers on all the
applicable SoCs. It covers the OMAP architecture SoCs - AM33xx, AM437x
and AM57xx; the Keystone 2 architecture based 66AK2G SoC; the Davinci
architecture based OMAPL138 SoCs, and the K3 architecture based AM65x
and J721E SoCs.

Signed-off-by: Suman Anna 
Signed-off-by: Andrew F. Davis 
Signed-off-by: Roger Quadros 
Signed-off-by: Grzegorz Jaszczyk 
---
v3->v4:
- Drop allOf references to interrupt-controller.yaml and
   interrupts.yaml.
- Drop items descriptions and use only maxItems: 1 as suggested by Rob.
- Convert irqs-reserved property from uint8-array to bitmask.
- Minor descriptions updates.
- Change interrupt-cells to 3 in order to provide 2-level mapping
   description for interrupts routed to the main CPU (as Marc requested).
- Merge the irqs-reserved and irqs-shared to one property since they
   can be handled by one logic.
- Drop reviewed-by due to introduced changes.
- Add another example illustrating irqs-reserved property usage.
v2->v3:
- Convert dt-binding to YAML
v1->v2:
- https://patchwork.kernel.org/patch/11069767/
---
  .../interrupt-controller/ti,pruss-intc.yaml| 157 +
  1 file changed, 157 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml 
b/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml
new file mode 100644
index 000..7336b11
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml
@@ -0,0 +1,157 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/ti,pruss-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI PRU-ICSS Local Interrupt Controller
+
+maintainers:
+  - Suman Anna 
+
+description: |
+  Each PRU-ICSS has a single interrupt controller instance that is common
+  to all the PRU cores. Most interrupt controllers can route 64 input events
+  which are then mapped to 10 possible output interrupts through two levels
+  of mapping. The input events can be triggered by either the PRUs and/or
+  various other PRUSS internal and external peripherals. The first 2 output
+  interrupts (0, 1) are fed exclusively to the internal PRU cores, with the
+  remaining 8 (2 through 9) connected to external interrupt controllers
+  including the MPU and/or other PRUSS instances, DSPs or devices.
+
+  The property "ti,irqs-reserved" is used for denoting the connection
+  differences on the output interrupts 2 through 9. If this property is not
+  defined, it implies that all the PRUSS INTC output interrupts 2 through 9
+  (host_intr0 through host_intr7) are connected exclusively to the Arm 
interrupt
+  controller.
+
+  The K3 family of SoCs can handle 160 input events that can be mapped to 20
+  different possible output interrupts. The additional output interrupts (10
+  through 19) are connected to new sub-modules within the ICSSG instances.
+
+  This interrupt-controller node should be defined as a child node of the
+  corresponding PRUSS node. The node should be named "interrupt-controller".
+
+properties:
+  compatible:
+enum:
+  - ti,pruss-intc
+  - ti,icssg-intc
+description: |
+  Use "ti,pruss-intc" for OMAP-L13x/AM18x/DA850 SoCs,
+  AM335x family of SoCs,
+  AM437x family of SoCs,
+  AM57xx family of SoCs
+  66AK2G family of SoCs
+  Use "ti,icssg-intc" for K3 AM65x & J721E family of SoCs
+
+  reg:
+maxItems: 1
+
+  interrupts:
+minItems: 1
+maxItems: 8
+description: |
+  All the interrupts generated towards the main host processor in the SoC.
+  A shared interrupt can be skipped if the desired destination and usage is
+  by a different processor/device.



Re: [PATCH 6/7] ARM: s3c64xx: Switch to generic watchdog driver reset

2020-07-29 Thread Tomasz Figa
Hi Krzysztof,

2020年7月29日(水) 18:11 Krzysztof Kozlowski :
>
> Similarly to commit f6361c6b3880 ("ARM: S3C24XX: remove separate restart
> code"), the platform watchdog reset code can be removed in favor of
> a generic watchdog driver which already handles reset.
>
> This allows removal of a bunch of machine code and fixes also W=1
> compile warnings:
>
> arch/arm/plat-samsung/watchdog-reset.c:29:6: warning: no previous 
> prototype for 'samsung_wdt_reset' [-Wmissing-prototypes]
>29 | void samsung_wdt_reset(void)
>   |  ^
> arch/arm/plat-samsung/watchdog-reset.c:69:13: warning: no previous 
> prototype for 'samsung_wdt_reset_of_init' [-Wmissing-prototypes]
>69 | void __init samsung_wdt_reset_of_init(void)
>   | ^
> arch/arm/plat-samsung/watchdog-reset.c:89:13: warning: no previous 
> prototype for 'samsung_wdt_reset_init' [-Wmissing-prototypes]
>89 | void __init samsung_wdt_reset_init(void __iomem *base)
>
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  arch/arm/mach-s3c64xx/Kconfig   |  3 +-
>  arch/arm/mach-s3c64xx/common.c  | 15 +---
>  arch/arm/mach-s3c64xx/common.h  |  2 -
>  arch/arm/mach-s3c64xx/mach-anw6410.c|  1 -
>  arch/arm/mach-s3c64xx/mach-crag6410.c   |  1 -
>  arch/arm/mach-s3c64xx/mach-hmt.c|  1 -
>  arch/arm/mach-s3c64xx/mach-mini6410.c   |  1 -
>  arch/arm/mach-s3c64xx/mach-ncp.c|  1 -
>  arch/arm/mach-s3c64xx/mach-real6410.c   |  1 -
>  arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c | 17 -
>  arch/arm/mach-s3c64xx/mach-smartq5.c|  1 -
>  arch/arm/mach-s3c64xx/mach-smartq7.c|  1 -
>  arch/arm/mach-s3c64xx/mach-smdk6400.c   |  1 -
>  arch/arm/mach-s3c64xx/mach-smdk6410.c   |  1 -
>  arch/arm/mach-s3c64xx/watchdog-reset.h  | 16 -
>  arch/arm/plat-samsung/Kconfig   |  6 --
>  arch/arm/plat-samsung/Makefile  |  1 -
>  arch/arm/plat-samsung/watchdog-reset.c  | 93 -
>  18 files changed, 5 insertions(+), 158 deletions(-)
>  delete mode 100644 arch/arm/mach-s3c64xx/watchdog-reset.h
>  delete mode 100644 arch/arm/plat-samsung/watchdog-reset.c
>

Thanks for the patch! Please see my comments inline.

> diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
> index e208c2b48853..f3fcb570edf5 100644
> --- a/arch/arm/mach-s3c64xx/Kconfig
> +++ b/arch/arm/mach-s3c64xx/Kconfig
> @@ -18,9 +18,10 @@ menuconfig ARCH_S3C64XX
> select PM_GENERIC_DOMAINS if PM
> select S3C_DEV_NAND if ATAGS
> select S3C_GPIO_TRACK if ATAGS
> +   select S3C2410_WATCHDOG
> select SAMSUNG_ATAGS if ATAGS
> select SAMSUNG_WAKEMASK if PM
> -   select SAMSUNG_WDT_RESET
> +   select WATCHDOG
> help
>   Samsung S3C64XX series based systems
>
> diff --git a/arch/arm/mach-s3c64xx/common.c b/arch/arm/mach-s3c64xx/common.c
> index a655bf0c7802..42e96d196f61 100644
> --- a/arch/arm/mach-s3c64xx/common.c
> +++ b/arch/arm/mach-s3c64xx/common.c
> @@ -50,7 +50,6 @@
>
>  #include "common.h"
>  #include "irq-uart.h"
> -#include "watchdog-reset.h"
>
>  /* External clock frequency */
>  static unsigned long xtal_f __ro_after_init = 1200;
> @@ -232,10 +231,11 @@ void __init s3c64xx_init_irq(u32 vic0_valid, u32 
> vic1_valid)
> /*
>  * FIXME: there is no better place to put this at the moment
>  * (s3c64xx_clk_init needs ioremap and must happen before init_time
> -* samsung_wdt_reset_init needs clocks)
> +* samsung_wdt_reset_init needs clocks).  However
> +* samsung_wdt_reset_init() was removed in favor of watchdog driver
> +* so this should be revised.

This leaves the comment referring to an inexistent function.

I wonder if this being here is actually a problem at all. It's legacy
code and probably there isn't much value in reshuffling it further.
Rather than that, we would probably want to make sure that everything
migrated to DT and just drop the board files.

>  */
> s3c64xx_clk_init(NULL, xtal_f, xusbxti_f, soc_is_s3c6400(), 
> S3C_VA_SYS);
> -   samsung_wdt_reset_init(S3C_VA_WATCHDOG);
>
> printk(KERN_DEBUG "%s: initialising interrupts\n", __func__);
>
> @@ -429,12 +429,3 @@ static int __init s3c64xx_init_irq_eint(void)
> return 0;
>  }
>  arch_initcall(s3c64xx_init_irq_eint);
> -
> -void s3c64xx_restart(enum reboot_mode mode, const char *cmd)
> -{
> -   if (mode != REBOOT_SOFT)
> -   samsung_wdt_reset();
> -
> -   /* if all else fails, or mode was for soft, jump to 0 */
> -   soft_restart(0);

Does this remove the soft reboot capability? I'm not sure how much of
a problem that would be, though.

[snip]
> diff --git a/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c 
> b/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
> index 1724f5ea5c46..09c4e8742629 100644
> --- a/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
> +++ b/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
> @@ 

Re: [PATCH v1 2/6] mm/page_isolation: don't dump_page(NULL) in set_migratetype_isolate()

2020-07-29 Thread Mike Kravetz
On 6/30/20 7:26 AM, David Hildenbrand wrote:
> Right now, if we have two isolations racing, we might trigger the
> WARN_ON_ONCE() and to dump_page(NULL), dereferencing NULL. Let's just
> return directly.

Just curious, what call path has the WARN_ON_ONCE()/dump_page(NULL)?

> 
> In the future, we might want to report -EAGAIN to the caller instead, as
> this could indicate a temporary isolation failure only.
> 
> Cc: Andrew Morton 
> Cc: Michal Hocko 
> Cc: Michael S. Tsirkin 
> Signed-off-by: David Hildenbrand 

Hi David,

That 'return -EAGAIN' was added as a sort of synchronization mechanism.
See commit message for 2c7452a075d4d.  Before adding the 'return -EAGAIN',
I could create races which would abandon isolated pageblocks.  Repeating
those races over and over would result in a good chunk of system memory
being isolated and unusable.

Admittedly, these races are rare and I had to work really hard to produce
them.  I'll try to find my testing mechanism.  My concern is reintroducing
this abandoning of pageblocks.  I have not looked further in your series
to see if this potentially addressed later.  If not, then we should not
remove the return code.

-- 
Mike Kravetz

> ---
>  mm/page_isolation.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> index f6d07c5f0d34d..553b49a34cf71 100644
> --- a/mm/page_isolation.c
> +++ b/mm/page_isolation.c
> @@ -29,10 +29,12 @@ static int set_migratetype_isolate(struct page *page, int 
> migratetype, int isol_
>   /*
>* We assume the caller intended to SET migrate type to isolate.
>* If it is already set, then someone else must have raced and
> -  * set it before us.  Return -EBUSY
> +  * set it before us.
>*/
> - if (is_migrate_isolate_page(page))
> - goto out;
> + if (is_migrate_isolate_page(page)) {
> + spin_unlock_irqrestore(>lock, flags);
> + return -EBUSY;
> + }
>  
>   /*
>* FIXME: Now, memory hotplug doesn't call shrink_slab() by itself.
> 


[char-misc-next] mei: hdcp: fix mei_hdcp_verify_mprime() input paramter

2020-07-29 Thread Tomas Winkler
wired_cmd_repeater_auth_stream_req_in has a variable
length array at the end. we use struct_size() overflow
macro to determine the size for the allocation and sending
size.

Fixes: c56967d674e3 (mei: hdcp: Replace one-element array with flexible-array 
member)
Cc: Ramalingam C 
Cc: Gustavo A. R. Silva 
Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 38 ++--
 1 file changed, 22 insertions(+), 16 deletions(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index d1d3e025ca0e..0e8f12e38494 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -546,38 +546,44 @@ static int mei_hdcp_verify_mprime(struct device *dev,
  struct hdcp_port_data *data,
  struct hdcp2_rep_stream_ready *stream_ready)
 {
-   struct wired_cmd_repeater_auth_stream_req_in
-   verify_mprime_in = { { 0 } };
+   struct wired_cmd_repeater_auth_stream_req_in *verify_mprime_in;
struct wired_cmd_repeater_auth_stream_req_out
verify_mprime_out = { { 0 } };
struct mei_cl_device *cldev;
ssize_t byte;
+   size_t cmd_size;
 
if (!dev || !stream_ready || !data)
return -EINVAL;
 
cldev = to_mei_cl_device(dev);
 
-   verify_mprime_in.header.api_version = HDCP_API_VERSION;
-   verify_mprime_in.header.command_id = WIRED_REPEATER_AUTH_STREAM_REQ;
-   verify_mprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
-   verify_mprime_in.header.buffer_len =
+   cmd_size = struct_size(verify_mprime_in, streams, data->k);
+   if (cmd_size == SIZE_MAX)
+   return -EINVAL;
+
+   verify_mprime_in = kzalloc(cmd_size, GFP_KERNEL);
+
+   verify_mprime_in->header.api_version = HDCP_API_VERSION;
+   verify_mprime_in->header.command_id = WIRED_REPEATER_AUTH_STREAM_REQ;
+   verify_mprime_in->header.status = ME_HDCP_STATUS_SUCCESS;
+   verify_mprime_in->header.buffer_len =
WIRED_CMD_BUF_LEN_REPEATER_AUTH_STREAM_REQ_MIN_IN;
 
-   verify_mprime_in.port.integrated_port_type = data->port_type;
-   verify_mprime_in.port.physical_port = (u8)data->fw_ddi;
-   verify_mprime_in.port.attached_transcoder = (u8)data->fw_tc;
+   verify_mprime_in->port.integrated_port_type = data->port_type;
+   verify_mprime_in->port.physical_port = (u8)data->fw_ddi;
+   verify_mprime_in->port.attached_transcoder = (u8)data->fw_tc;
+
+   memcpy(verify_mprime_in->m_prime, stream_ready->m_prime, 
HDCP_2_2_MPRIME_LEN);
+   drm_hdcp_cpu_to_be24(verify_mprime_in->seq_num_m, data->seq_num_m);
 
-   memcpy(verify_mprime_in.m_prime, stream_ready->m_prime,
-  HDCP_2_2_MPRIME_LEN);
-   drm_hdcp_cpu_to_be24(verify_mprime_in.seq_num_m, data->seq_num_m);
-   memcpy(verify_mprime_in.streams, data->streams,
+   memcpy(verify_mprime_in->streams, data->streams,
   array_size(data->k, sizeof(*data->streams)));
 
-   verify_mprime_in.k = cpu_to_be16(data->k);
+   verify_mprime_in->k = cpu_to_be16(data->k);
 
-   byte = mei_cldev_send(cldev, (u8 *)_mprime_in,
- sizeof(verify_mprime_in));
+   byte = mei_cldev_send(cldev, (u8 *)_mprime_in, cmd_size);
+   kfree(verify_mprime_in);
if (byte < 0) {
dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
return byte;
-- 
2.25.4



Re: Re: Re: [PATCH v18 02/14] mm: Introduce Data Access MONitor (DAMON)

2020-07-29 Thread SeongJae Park
On Wed, 29 Jul 2020 08:31:29 -0700 Shakeel Butt  wrote:

> On Sat, Jul 18, 2020 at 6:31 AM SeongJae Park  wrote:
> >
> > On Fri, 17 Jul 2020 19:47:50 -0700 Shakeel Butt  wrote:
> >
> > > On Mon, Jul 13, 2020 at 1:43 AM SeongJae Park  wrote:
> > > >
> > > > From: SeongJae Park 
> > > >
> > > > DAMON is a data access monitoring framework subsystem for the Linux
> > > > kernel.  The core mechanisms of DAMON make it
> > > >
> > > >  - accurate (the monitoring output is useful enough for DRAM level
> > > >memory management; It might not appropriate for CPU Cache levels,
> > > >though),
> > > >  - light-weight (the monitoring overhead is low enough to be applied
> > > >online), and
> > > >  - scalable (the upper-bound of the overhead is in constant range
> > > >regardless of the size of target workloads).
> > > >
> > > > Using this framework, therefore, the kernel's memory management
> > > > mechanisms can make advanced decisions.  Experimental memory management
> > > > optimization works that incurring high data accesses monitoring overhead
> > > > could implemented again.  In user space, meanwhile, users who have some
> > > > special workloads can write personalized applications for better
> > > > understanding and optimizations of their workloads and systems.
> > > >
> > > > This commit is implementing only the stub for the module load/unload,
> > > > basic data structures, and simple manipulation functions of the
> > > > structures to keep the size of commit small.  The core mechanisms of
> > > > DAMON will be implemented one by one by following commits.
> > > >
> > > > Signed-off-by: SeongJae Park 
> > > > Reviewed-by: Leonard Foerster 
> > > > Reviewed-by: Varad Gautam 
> > > > ---
> > > >  include/linux/damon.h |  63 ++
> > > >  mm/Kconfig|  12 +++
> > > >  mm/Makefile   |   1 +
> > > >  mm/damon.c| 188 ++
> > > >  4 files changed, 264 insertions(+)
> > > >  create mode 100644 include/linux/damon.h
> > > >  create mode 100644 mm/damon.c
> > > >
> > > > diff --git a/include/linux/damon.h b/include/linux/damon.h
> > > > new file mode 100644
> > > > index ..c8f8c1c41a45
> > > > --- /dev/null
> > > > +++ b/include/linux/damon.h
> > > > @@ -0,0 +1,63 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > > +/*
> > > > + * DAMON api
> > > > + *
> > > > + * Copyright 2019-2020 Amazon.com, Inc. or its affiliates.
> > > > + *
> > > > + * Author: SeongJae Park 
> > > > + */
> > > > +
> > [...]
> > > > +
> > > > +/**
> > > > + * struct damon_task - Represents a monitoring target task.
> > > > + * @pid:   Process id of the task.
> > > > + * @regions_list:  Head of the monitoring target regions of this 
> > > > task.
> > > > + * @list:  List head for siblings.
> > > > + *
> > > > + * If the monitoring target address space is task independent (e.g., 
> > > > physical
> > > > + * memory address space monitoring), @pid should be '-1'.
> > > > + */
> > > > +struct damon_task {
> > > > +   int pid;
> > >
> > > Storing and accessing pid like this is racy. Why not save the "struct
> > > pid" after getting the reference? I am still going over the usage,
> > > maybe storing mm_struct would be an even better choice.
> > >
> > > > +   struct list_head regions_list;
> > > > +   struct list_head list;
> > > > +};
> > > > +
> > [...]
> > > > +
> > > > +#define damon_get_task_struct(t) \
> > > > +   (get_pid_task(find_vpid(t->pid), PIDTYPE_PID))
> > >
> > > You need at least rcu lock around find_vpid(). Also you need to be
> > > careful about the context. If you accept my previous suggestion then
> > > you just need to do this in the process context which is registering
> > > the pid (no need to worry about the pid namespace).
> > >
> > > I am wondering if there should be an interface to register processes
> > > with DAMON using pidfd instead of integer pid.
> >
> > Good points!  I will use pidfd for this purpose, instead.
> >
> > BTW, 'struct damon_task' was introduced while DAMON supports only virtual
> > address spaces and recently extended to support physical memory address
> > monitoring case by defining an exceptional pid (-1) for such case.  I think 
> > it
> > doesn't smoothly fit with the design.
> >
> > Therefore, I would like to change it with more general named struct, e.g.,
> >
> > struct damon_target {
> > void *id;
> > struct list_head regions_list;
> > struct list_head list;
> > };
> >
> > The 'id' field will be able to store or point pid_t, struct mm_struct, 
> > struct
> > pid, or anything relevant, depending on the target address space.
> >
> > Only one part of the address space independent logics of DAMON, namely
> > 'kdamon_need_stop()', uses '->pid' of the 'struct damon_task'.  It will be
> > introduced by the next patch ("mm/damon: Implement region based sampling").
> > Therefore, the conversion will be easy.  

Re: mmotm 2020-07-27-18-18 uploaded (mm/page_alloc.c)

2020-07-29 Thread Randy Dunlap
On 7/29/20 9:14 AM, David Hildenbrand wrote:
> On 29.07.20 16:38, David Hildenbrand wrote:
>> On 29.07.20 16:18, Michael S. Tsirkin wrote:
>>> On Tue, Jul 28, 2020 at 03:31:43PM -0700, Andrew Morton wrote:
 On Wed, 29 Jul 2020 08:20:53 +1000 Stephen Rothwell 
  wrote:

> Hi Andrew,
>
> On Tue, 28 Jul 2020 14:55:53 -0700 Andrew Morton 
>  wrote:
>> config CONTIG_ALLOC
>> def_bool (MEMORY_ISOLATION && COMPACTION) || CMA
>>
>> says this is an improper combination.  And `make oldconfig' fixes it up.
>>
>> What's happening here?
>
> CONFIG_VIRTIO_MEM selects CONFIG_CONTIG_ALLOC ...

 Argh, select strikes again.

 So I guess VIRTIO_MEM should also select COMPACTION?
>>>
>>> +Cc the maintainer.
>>>
>>
>> We had select CONFIG_CONTIG_ALLOC before and that seemed to be wrong. I
>> was told select might be the wrong approach.
>>
>> We want memory isolation and contig_alloc with virtio-mem (which depends
>> on memory hot(un)plug). What would be the right way to achieve this?
>>
> 
> Okay, I think I am confused. I thought we had that already fixed. @mst
> what happened to
> 
> https://lkml.kernel.org/r/d03c88ea-200d-54ab-d7f3-f3e5b7a0a...@redhat.com
> 
> That patch is almost a month old, can you pick it, I already acked it.

That patch works for me.

Acked-by: Randy Dunlap  # build-tested

thanks.
-- 
~Randy


Re: [PATCH 2/7] modules: mark find_symbol static

2020-07-29 Thread Joe Lawrence

On 7/29/20 12:24 PM, Greg Kroah-Hartman wrote:

On Wed, Jul 29, 2020 at 06:13:18PM +0200, Jessica Yu wrote:

+++ Christoph Hellwig [29/07/20 08:27 +0200]:

find_symbol is only used in module.c.

Signed-off-by: Christoph Hellwig 


CCing the livepatching ML, as this may or may not impact its users.

AFAIK, the out-of-tree kpatch module had used find_symbol() in the
past, I am not sure what its current status is. I suspect all of its
functionality has been migrated to upstream livepatch already.


We still have symbol_get(), which is what I thought they were using.



The deprecated (though still in the repo) kpatch.ko still references 
find_symbol(), but that module is no longer officially supported by the 
project.


Jessica is correct that the functionality has been migrated upstream.

I don't see any references to symbol_get() either, so we're good on that 
front, too.


Thanks,

-- Joe



Re: [RFC PATCH 14/14] dts: bindings: coresight: ETMv4.4 system register access only units

2020-07-29 Thread Mathieu Poirier
On Wed, Jul 22, 2020 at 06:20:40PM +0100, Suzuki K Poulose wrote:
> Document the bindings for ETMv4.4 and later with only system register
> access.
> 
> Cc: Rob Herring 
> Cc: devicet...@vger.kernel.org
> Cc: Mathieu Poirier 
> Cc: Mike Leach 
> Signed-off-by: Suzuki K Poulose 
> ---
>  Documentation/devicetree/bindings/arm/coresight.txt | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt 
> b/Documentation/devicetree/bindings/arm/coresight.txt
> index d711676b4a51..cfe47bdda728 100644
> --- a/Documentation/devicetree/bindings/arm/coresight.txt
> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
> @@ -34,9 +34,13 @@ its hardware characteristcs.
>   Program Flow Trace Macrocell:
>   "arm,coresight-etm3x", "arm,primecell";
>  
> - - Embedded Trace Macrocell (version 4.x):
> + - Embedded Trace Macrocell (version 4.x), with memory mapped 
> access.
>   "arm,coresight-etm4x", "arm,primecell";
>  
> + - Embedded Trace Macrocell (version 4.4 and later) with system
> +   register access only.
> + "arm,coresight-etm-v4.4";

I would rather call this "arm,coresight-etm-v4.4+" so that the binding's
semantic is still relevant when dealing with ETM v4.5 and onward. 

Thanks,
Mathieu

> +
>   - Coresight programmable Replicator :
>   "arm,coresight-dynamic-replicator", "arm,primecell";
>  
> -- 
> 2.24.1
> 


Re: [PATCH] atm: Fix atm_dev reference count leaks in atmtcp_remove_persistent()

2020-07-29 Thread Markus Elfring
…
> The refcount leaks issues occur in two error handling paths.

Can it be nicer to use the term “reference count” for the commit message?


> Fix the issue by …

I suggest to replace this wording by the tag “Fixes”.


…
> +++ b/drivers/atm/atmtcp.c
> @@ -433,9 +433,15 @@  static int atmtcp_remove_persistent(int itf)
>   return -EMEDIUMTYPE;
>   }
>   dev_data = PRIV(dev);
> - if (!dev_data->persist) return 0;
> + if (!dev_data->persist) {
> + atm_dev_put(dev);
> + return 0;
> + }
…

I propose to add a jump target for the desired exception handling
in this function implementation.

+   if (!dev_data->persist)
+   goto put_device;


Regards,
Markus


Re: [PATCH rdma-next 0/4] Fix bugs around RDMA CM destroying state

2020-07-29 Thread Jason Gunthorpe
On Thu, Jul 23, 2020 at 10:07:03AM +0300, Leon Romanovsky wrote:

> This small series simplifies some of the RDMA CM state transitions
> connected with DESTROYING states and in the process resolves a bug
> discovered by syzkaller.
> 
> Thanks
> 
> Jason Gunthorpe (4):
>   RDMA/cma: Simplify DEVICE_REMOVAL for internal_id
>   RDMA/cma: Using the standard locking pattern when delivering the
> removal event
>   RDMA/cma: Remove unneeded locking for req paths
>   RDMA/cma: Execute rdma_cm destruction from a handler properly

Applied to for-next

Jason


Re: [PATCH 1/2] firmware: qcom_scm: Add memory protect virtual address ranges

2020-07-29 Thread Elliot Berman
++

On 7/24/2020 8:04 AM, Stanimir Varbanov wrote:
> Hi,
> 
> Gentle ping for review.
> 
> On 7/9/20 2:58 PM, Stanimir Varbanov wrote:
>> This adds a new SCM memprotect command to set virtual address ranges.
>>
>> Signed-off-by: Stanimir Varbanov 
>> ---
>>  drivers/firmware/qcom_scm.c | 24 
>>  drivers/firmware/qcom_scm.h |  1 +
>>  include/linux/qcom_scm.h|  8 +++-
>>  3 files changed, 32 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
>> index 0e7233a20f34..a73870255c2e 100644
>> --- a/drivers/firmware/qcom_scm.c
>> +++ b/drivers/firmware/qcom_scm.c
>> @@ -864,6 +864,30 @@ int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t 
>> mem_sz,
>>  }
>>  EXPORT_SYMBOL(qcom_scm_assign_mem);
>>  
>> +int qcom_scm_mem_protect_video_var(u32 cp_start, u32 cp_size,
>> +   u32 cp_nonpixel_start,
>> +   u32 cp_nonpixel_size)
>> +{
>> +int ret;
>> +struct qcom_scm_desc desc = {
>> +.svc = QCOM_SCM_SVC_MP,
>> +.cmd = QCOM_SCM_MP_VIDEO_VAR,
>> +.arginfo = QCOM_SCM_ARGS(4, QCOM_SCM_VAL, QCOM_SCM_VAL,
>> + QCOM_SCM_VAL, QCOM_SCM_VAL),
>> +.args[0] = cp_start,
>> +.args[1] = cp_size,
>> +.args[2] = cp_nonpixel_start,
>> +.args[3] = cp_nonpixel_size,
>> +.owner = ARM_SMCCC_OWNER_SIP,
>> +};
>> +struct qcom_scm_res res;
>> +
>> +ret = qcom_scm_call(__scm->dev, , );
>> +
>> +return ret ? : res.result[0];
>> +}
>> +EXPORT_SYMBOL(qcom_scm_mem_protect_video_var);
>> +

Small nit, can you bump the function above assign_mem? It would keep order 
aligned with
the macros in qcom_scm.h

>>  /**
>>   * qcom_scm_ocmem_lock_available() - is OCMEM lock/unlock interface 
>> available
>>   */
>> diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
>> index d9ed670da222..14da834ac593 100644
>> --- a/drivers/firmware/qcom_scm.h
>> +++ b/drivers/firmware/qcom_scm.h
>> @@ -97,6 +97,7 @@ extern int scm_legacy_call(struct device *dev, const 
>> struct qcom_scm_desc *desc,
>>  #define QCOM_SCM_MP_RESTORE_SEC_CFG 0x02
>>  #define QCOM_SCM_MP_IOMMU_SECURE_PTBL_SIZE  0x03
>>  #define QCOM_SCM_MP_IOMMU_SECURE_PTBL_INIT  0x04
>> +#define QCOM_SCM_MP_VIDEO_VAR   0x08
>>  #define QCOM_SCM_MP_ASSIGN  0x16
>>  
>>  #define QCOM_SCM_SVC_OCMEM  0x0f
>> diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
>> index 3d6a24697761..19b5188d17f4 100644
>> --- a/include/linux/qcom_scm.h
>> +++ b/include/linux/qcom_scm.h
>> @@ -81,7 +81,9 @@ extern int qcom_scm_assign_mem(phys_addr_t mem_addr, 
>> size_t mem_sz,
>> unsigned int *src,
>> const struct qcom_scm_vmperm *newvm,
>> unsigned int dest_cnt);
>> -
>> +extern int qcom_scm_mem_protect_video_var(u32 cp_start, u32 cp_size,
>> +  u32 cp_nonpixel_start,
>> +  u32 cp_nonpixel_size);

Same here.

>>  extern bool qcom_scm_ocmem_lock_available(void);
>>  extern int qcom_scm_ocmem_lock(enum qcom_scm_ocmem_client id, u32 offset,
>> u32 size, u32 mode);
>> @@ -131,6 +133,10 @@ static inline int qcom_scm_iommu_secure_ptbl_init(u64 
>> addr, u32 size, u32 spare)
>>  static inline int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz,
>>  unsigned int *src, const struct qcom_scm_vmperm *newvm,
>>  unsigned int dest_cnt) { return -ENODEV; }
>> +extern inline int qcom_scm_mem_protect_video_var(u32 cp_start, u32 cp_size,
>> + u32 cp_nonpixel_start,
>> + u32 cp_nonpixel_size)
>> +{ return -ENODEV; }

Same here.

>>  
>>  static inline bool qcom_scm_ocmem_lock_available(void) { return false; }
>>  static inline int qcom_scm_ocmem_lock(enum qcom_scm_ocmem_client id, u32 
>> offset,
>>
> 

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


[PATCH] kconfig: qconf: remove "goBack" debug message

2020-07-29 Thread Masahiro Yamada
Every time the goback icon is clicked, the annoying message "goBack"
is displayed on the console.

I guess this line is the left-over debug code of commit af737b4defe1
("kconfig: qconf: simplify the goBack() logic").

Signed-off-by: Masahiro Yamada 
---

 scripts/kconfig/qconf.cc | 1 -
 1 file changed, 1 deletion(-)

diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
index 006e7493306c..1c61c768b99e 100644
--- a/scripts/kconfig/qconf.cc
+++ b/scripts/kconfig/qconf.cc
@@ -1735,7 +1735,6 @@ void ConfigMainWindow::listFocusChanged(void)
 
 void ConfigMainWindow::goBack(void)
 {
-qInfo() << __FUNCTION__;
if (configList->rootEntry == )
return;
 
-- 
2.25.1



RE: [Intel-wired-lan] [PATCH 4/4] ixgbe/ixgbe_ethtool.c: Remove unnecessary usages of memset.

2020-07-29 Thread Bowers, AndrewX
> -Original Message-
> From: Intel-wired-lan  On Behalf Of
> Suraj Upadhyay
> Sent: Tuesday, July 14, 2020 12:42 PM
> To: Kirsher, Jeffrey T ; da...@davemloft.net;
> k...@kernel.org
> Cc: net...@vger.kernel.org; kernel-janit...@vger.kernel.org; intel-wired-
> l...@lists.osuosl.org; linux-kernel@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH 4/4] ixgbe/ixgbe_ethtool.c: Remove
> unnecessary usages of memset.
> 
> Replace memsets of 1 byte with simple assignment.
> Issue found with checkpatch.pl
> 
> Signed-off-by: Suraj Upadhyay 
> ---
>  drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Tested-by: Andrew Bowers 




Re: [PATCH 1/6] dt-bindings: display: Document NewVision NV3052C DT node

2020-07-29 Thread Laurent Pinchart
Hi Paul,

Thank you for the patch.

On Mon, Jul 27, 2020 at 06:46:08PM +0200, Paul Cercueil wrote:
> Add documentation for the Device Tree node for LCD panels based on the
> NewVision NV3052C controller.
> 
> Signed-off-by: Paul Cercueil 
> ---
>  .../display/panel/newvision,nv3052c.yaml  | 69 +++
>  1 file changed, 69 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/newvision,nv3052c.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/newvision,nv3052c.yaml 
> b/Documentation/devicetree/bindings/display/panel/newvision,nv3052c.yaml
> new file mode 100644
> index ..751a28800fc2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/newvision,nv3052c.yaml
> @@ -0,0 +1,69 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/newvision,nv3052c.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NewVision NV3052C TFT LCD panel driver with SPI control bus

s/driver/driver IC/ (or driver chip, or controller, or any other similar
term) to avoid confusion with device drivers.

Do I understand that the NV3052C also supports control through DSI ?
Shouldn't this appear in the DT bindings ? Do I assume correctly that
the panel will be controlled either through SPI or through DSI, but not
through both ?

> +
> +maintainers:
> +  - Paul Cercueil 
> +
> +description: |
> +  This is a driver for 320x240 TFT panels, accepting a variety of input
> +  streams that get adapted and scaled to the panel. The panel output has
> +  960 TFT source driver pins and 240 TFT gate driver pins, VCOM, VCOML and
> +  VCOMH outputs.
> +
> +  The panel must obey the rules for a SPI slave device as specified in
> +  spi/spi-controller.yaml
> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +
> +properties:
> +  compatible:
> +items:
> +  - enum:
> +- leadtek,ltk035c5444t-spi

According to its datasheet, that panel is 640x480 :-)

I think you need a bit of documentation to explain that two compatible
strings are needed, one matching the panel type, and a second one
matching the chip.

> +
> +  - const: newvision,nv3052c
> +
> +  reg:
> +maxItems: 1
> +
> +  reset-gpios: true
> +  port: true

The NV3052C requires multiple power supplies, I think this needs to be
taken into account here.

> +
> +required:
> +  - compatible
> +  - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +#include 
> +spi {
> +  #address-cells = <1>;
> +  #size-cells = <0>;
> +
> +  display@0 {
> +compatible = "leadtek,ltk035c5444t-spi", "newvision,nv3052c";
> +reg = <0>;
> +
> +spi-max-frequency = <1500>;
> +spi-3wire;
> +reset-gpios = < 2 GPIO_ACTIVE_LOW>;
> +backlight = <>;
> +power-supply = <>;
> +
> +port {
> +  panel_input: endpoint {
> +  remote-endpoint = <_output>;
> +  };
> +};
> +  };
> +};
> +
> +...

-- 
Regards,

Laurent Pinchart


Re: [PATCH v3 4/5] mm: memcg: charge memcg percpu memory to the parent cgroup

2020-07-29 Thread Michal Koutný
Hello.

On Tue, Jun 23, 2020 at 11:45:14AM -0700, Roman Gushchin  wrote:
> Because the size of memory cgroup internal structures can dramatically
> exceed the size of object or page which is pinning it in the memory, it's
> not a good idea to simple ignore it.  It actually breaks the isolation
> between cgroups.
No doubt about accounting the memory if it's significant amount.

> Let's account the consumed percpu memory to the parent cgroup.
Why did you choose charging to the parent of the created cgroup?

Should the charge go the cgroup _that is creating_ the new memcg?

One reason is that there are the throttling mechanisms for memory limits
and those are better exercised when the actor and its memory artefact
are the same cgroup, aren't they?

The second reason is based on the example Dlegation Containment
(Documentation/admin-guide/cgroup-v2.rst)

> For an example, let's assume cgroups C0 and C1 have been delegated to
> user U0 who created C00, C01 under C0 and C10 under C1 as follows and
> all processes under C0 and C1 belong to U0::
> 
>   ~ - C0 - C00
>   ~ cgroup~  \ C01
>   ~ hierarchy ~
>   ~ - C1 - C10

Thanks to permissions a task running in C0 creating a cgroup in C1 would
deplete C1's supply victimizing tasks inside C1.

Thanks,
Michal


signature.asc
Description: Digital signature


Re: [RFC PATCH v5 12/14] gpu: host1x: mipi: Keep MIPI clock enabled till calibration is done

2020-07-29 Thread Dmitry Osipenko
28.07.2020 19:04, Sowjanya Komatineni пишет:
...
>>> +void tegra_mipi_cancel_calibration(struct tegra_mipi_device *device)
>>> +{
>> Doesn't MIPI_CAL need to be reset here?
> No need to reset MIPI CAL

Could you please explain why. There is a calibration state-machine that
apparently needs to be returned into initial state, does it return by
itself?

TRM says that MIPI block needs to be reset before of starting
calibration process. The reset is completely missing in the driver, I
assume it needs to be corrected with another patch.


Re: [PATCH 6/7] modules: return licensing information from find_symbol

2020-07-29 Thread Christoph Hellwig
On Wed, Jul 29, 2020 at 06:48:00PM +0200, Jessica Yu wrote:
> Just a small nit. Most of module.c uses license rather than licence -
> could we unify the spelling to remain consistent? Sigh, American vs.
> British English.. :)

Sure, I can fix that up.


Re: [PATCH 2/7] modules: mark find_symbol static

2020-07-29 Thread Christoph Hellwig
On Wed, Jul 29, 2020 at 06:24:35PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 29, 2020 at 06:13:18PM +0200, Jessica Yu wrote:
> > +++ Christoph Hellwig [29/07/20 08:27 +0200]:
> > > find_symbol is only used in module.c.
> > > 
> > > Signed-off-by: Christoph Hellwig 
> > 
> > CCing the livepatching ML, as this may or may not impact its users.
> > 
> > AFAIK, the out-of-tree kpatch module had used find_symbol() in the
> > past, I am not sure what its current status is. I suspect all of its
> > functionality has been migrated to upstream livepatch already.
> 
> We still have symbol_get(), which is what I thought they were using.

And even if it didn't out of tree modules really don't matter.


Re: [PATCH] remoteproc: virtio: support sharing vdev buffer

2020-07-29 Thread Mathieu Poirier
Hi Peng,

On Wed, Jul 22, 2020 at 09:15:43PM +0800, Peng Fan wrote:
> Support sharing vdev buffer between multiple vdevs by using name
> "vdevbuffer".
> 
> Reviewed-by: Richard Zhu 
> Signed-off-by: Peng Fan 
> ---
>  drivers/remoteproc/remoteproc_virtio.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/remoteproc/remoteproc_virtio.c 
> b/drivers/remoteproc/remoteproc_virtio.c
> index dfd3808c34fd..5d78ebea111e 100644
> --- a/drivers/remoteproc/remoteproc_virtio.c
> +++ b/drivers/remoteproc/remoteproc_virtio.c
> @@ -343,6 +343,8 @@ int rproc_add_virtio_dev(struct rproc_vdev *rvdev, int id)
>  
>   /* Try to find dedicated vdev buffer carveout */
>   mem = rproc_find_carveout_by_name(rproc, "vdev%dbuffer", rvdev->index);
> + if (!mem)
> + mem = rproc_find_carveout_by_name(rproc, "vdevbuffer");

We already have a way to share buffers [1], do you think it would work for you? 
 I
would rather proceed that way to avoid introducing a 3rd way to deal with vdev
buffers.

Thanks,
Mathieu

[1]. 
https://elixir.bootlin.com/linux/v5.8-rc4/source/drivers/remoteproc/remoteproc_virtio.c#L389

>   if (mem) {
>   phys_addr_t pa;
>  
> -- 
> 2.16.4
> 


Re: [PATCH] ext4: Fix comment typo "the the".

2020-07-29 Thread Jan Kara
On Sat 25-04-20 02:16:24, kyoungho koo wrote:
> I have found double typed comments "the the". So i modified it to
> one "the"
> 
> Signed-off-by: kyoungho koo 

Ted, this seems to have fallen through the cracks...

Honza

> ---
>  fs/ext4/inline.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
> index f35e289e17aa..bb8d7cb7bdec 100644
> --- a/fs/ext4/inline.c
> +++ b/fs/ext4/inline.c
> @@ -276,7 +276,7 @@ static int ext4_create_inline_data(handle_t *handle,
>   len = 0;
>   }
>  
> - /* Insert the the xttr entry. */
> + /* Insert the xttr entry. */
>   i.value = value;
>   i.value_len = len;
>  
> -- 
> 2.17.1
> 
-- 
Jan Kara 
SUSE Labs, CR


[PATCH v2 3/3] kconfig: qconf: use delete[] instead of delete to free array

2020-07-29 Thread Masahiro Yamada
cppcheck reports "Mismatching allocation and deallocation".

$ cppcheck scripts/kconfig/qconf.cc
Checking scripts/kconfig/qconf.cc ...
scripts/kconfig/qconf.cc:1242:10: error: Mismatching allocation and 
deallocation: data [mismatchAllocDealloc]
  delete data;
 ^
scripts/kconfig/qconf.cc:1236:15: note: Mismatching allocation and 
deallocation: data
 char *data = new char[count + 1];
  ^
scripts/kconfig/qconf.cc:1242:10: note: Mismatching allocation and 
deallocation: data
  delete data;
 ^
scripts/kconfig/qconf.cc:1255:10: error: Mismatching allocation and 
deallocation: data [mismatchAllocDealloc]
  delete data;
 ^
scripts/kconfig/qconf.cc:1236:15: note: Mismatching allocation and 
deallocation: data
 char *data = new char[count + 1];
  ^
scripts/kconfig/qconf.cc:1255:10: note: Mismatching allocation and 
deallocation: data
  delete data;
 ^

Fixes: c4f7398bee9c ("kconfig: qconf: make debug links work again")
Reported-by: David Binderman 
Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Remove the description about the remaining qconf.moc

 scripts/kconfig/qconf.cc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
index bb0a0bd511b9..3a11940ff5dc 100644
--- a/scripts/kconfig/qconf.cc
+++ b/scripts/kconfig/qconf.cc
@@ -1238,7 +1238,7 @@ void ConfigInfoView::clicked(const QUrl )
 
if (count < 1) {
qInfo() << "Clicked link is empty";
-   delete data;
+   delete[] data;
return;
}
 
@@ -1251,7 +1251,7 @@ void ConfigInfoView::clicked(const QUrl )
result = sym_re_search(data);
if (!result) {
qInfo() << "Clicked symbol is invalid:" << data;
-   delete data;
+   delete[] data;
return;
}
 
-- 
2.25.1



[PATCH v2 2/3] kconfig: qconf: compile moc object separately

2020-07-29 Thread Masahiro Yamada
Currently, qconf.moc is included from qconf.cc but they can be compiled
independently.

When you modify qconf.cc, qconf.moc does not need recompiling.

Rename qconf.moc to qconf.moc.cc, and split it out as an independent
compilation unit.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - New patch

 scripts/kconfig/.gitignore |  2 +-
 scripts/kconfig/Makefile   | 11 ++-
 scripts/kconfig/qconf.cc   |  1 -
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/scripts/kconfig/.gitignore b/scripts/kconfig/.gitignore
index 12a67fdab541..5914a3f5408c 100644
--- a/scripts/kconfig/.gitignore
+++ b/scripts/kconfig/.gitignore
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
-*.moc
+/qconf.moc.cc
 *conf-cfg
 
 #
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index a5e770e75653..96d015473288 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -181,21 +181,22 @@ $(addprefix $(obj)/, mconf.o $(lxdialog)): 
$(obj)/mconf-cfg
 
 # qconf: Used for the xconfig target based on Qt
 hostprogs  += qconf
-qconf-cxxobjs  := qconf.o
+qconf-cxxobjs  := qconf.o qconf.moc.o
 qconf-objs := images.o $(common-objs)
 
 HOSTLDLIBS_qconf   = $(shell . $(obj)/qconf-cfg && echo $$libs)
 HOSTCXXFLAGS_qconf.o   = $(shell . $(obj)/qconf-cfg && echo $$cflags)
+HOSTCXXFLAGS_qconf.moc.o = $(shell . $(obj)/qconf-cfg && echo $$cflags)
 
-$(obj)/qconf.o: $(obj)/qconf-cfg $(obj)/qconf.moc
+$(obj)/qconf.o: $(obj)/qconf-cfg
 
 quiet_cmd_moc = MOC $@
-  cmd_moc = $(shell . $(obj)/qconf-cfg && echo $$moc) -i $< -o $@
+  cmd_moc = $(shell . $(obj)/qconf-cfg && echo $$moc) $< -o $@
 
-$(obj)/%.moc: $(src)/%.h $(obj)/qconf-cfg FORCE
+$(obj)/qconf.moc.cc: $(src)/qconf.h $(obj)/qconf-cfg FORCE
$(call if_changed,moc)
 
-targets += qconf.moc
+targets += qconf.moc.cc
 
 # gconf: Used for the gconfig target based on GTK+
 hostprogs  += gconf
diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
index 4a616128a154..bb0a0bd511b9 100644
--- a/scripts/kconfig/qconf.cc
+++ b/scripts/kconfig/qconf.cc
@@ -23,7 +23,6 @@
 #include "lkc.h"
 #include "qconf.h"
 
-#include "qconf.moc"
 #include "images.h"
 
 
-- 
2.25.1



[PATCH v2 1/3] kconfig: qconf: use if_changed for qconf.moc rule

2020-07-29 Thread Masahiro Yamada
Regenerate qconf.moc when the moc command is changed.

This also allows 'make mrproper' to clean it up. Previously, it was
not cleaned up because 'clean-files += qconf.moc' was missing.
Now 'make mrproper' correctly cleans it up because files listed in
'targets' are cleaned.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Use 'targets' instead of 'clean-files'

 scripts/kconfig/Makefile | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 426881ea954f..a5e770e75653 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -192,8 +192,10 @@ $(obj)/qconf.o: $(obj)/qconf-cfg $(obj)/qconf.moc
 quiet_cmd_moc = MOC $@
   cmd_moc = $(shell . $(obj)/qconf-cfg && echo $$moc) -i $< -o $@
 
-$(obj)/%.moc: $(src)/%.h $(obj)/qconf-cfg
-   $(call cmd,moc)
+$(obj)/%.moc: $(src)/%.h $(obj)/qconf-cfg FORCE
+   $(call if_changed,moc)
+
+targets += qconf.moc
 
 # gconf: Used for the gconfig target based on GTK+
 hostprogs  += gconf
-- 
2.25.1



Re: [PATCH 5/7] ARM: samsung: Kill useless HAVE_S3C2410_WATCHDOG

2020-07-29 Thread Guenter Roeck
On Wed, Jul 29, 2020 at 06:09:40PM +0200, Krzysztof Kozlowski wrote:
> A separate Kconfig option HAVE_S3C2410_WATCHDOG for Samsung SoCs does
> not have sense, because:
> 1. All ARMv7 and ARMv8 Samsung SoCs have watchdog,
> 2. All architecture Kconfigs were selecting it (if WATCHDOG framework is
>chosen),
> 3. HAVE_S3C2410_WATCHDOG is doing nothing except being a dependency of
>actual Samsung SoC watchdog driver, which is enabled manually by
>specific defconfigs.
> 
> HAVE_S3C2410_WATCHDOG can be safely removed.
> 

That is not really correct. HAVE_S3C2410_WATCHDOG is used to ensure
that users can only enable S3C2410_WATCHDOG if the watchdog actually
exists in a system. With this change, it can be enabled for all
architectures and platforms.

NACK.

Guenter

> Signed-off-by: Krzysztof Kozlowski 
> ---
>  arch/arm/Kconfig  | 1 -
>  arch/arm/mach-exynos/Kconfig  | 1 -
>  arch/arm/mach-s3c64xx/Kconfig | 2 --
>  arch/arm/mach-s5pv210/Kconfig | 1 -
>  arch/arm64/Kconfig.platforms  | 1 -
>  drivers/watchdog/Kconfig  | 8 
>  6 files changed, 14 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 7564f293f107..fe95777af653 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -504,7 +504,6 @@ config ARCH_S3C24XX
>   select GPIOLIB
>   select GENERIC_IRQ_MULTI_HANDLER
>   select HAVE_S3C2410_I2C if I2C
> - select HAVE_S3C2410_WATCHDOG if WATCHDOG
>   select HAVE_S3C_RTC if RTC_CLASS
>   select NEED_MACH_IO_H
>   select SAMSUNG_ATAGS
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index f185cd3d4c62..d2d249706ebb 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -24,7 +24,6 @@ menuconfig ARCH_EXYNOS
>   select HAVE_ARM_ARCH_TIMER if ARCH_EXYNOS5
>   select HAVE_ARM_SCU if SMP
>   select HAVE_S3C2410_I2C if I2C
> - select HAVE_S3C2410_WATCHDOG if WATCHDOG
>   select HAVE_S3C_RTC if RTC_CLASS
>   select PINCTRL
>   select PINCTRL_EXYNOS
> diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
> index ac3e3563487f..e208c2b48853 100644
> --- a/arch/arm/mach-s3c64xx/Kconfig
> +++ b/arch/arm/mach-s3c64xx/Kconfig
> @@ -13,7 +13,6 @@ menuconfig ARCH_S3C64XX
>   select GPIO_SAMSUNG if ATAGS
>   select GPIOLIB
>   select HAVE_S3C2410_I2C if I2C
> - select HAVE_S3C2410_WATCHDOG if WATCHDOG
>   select HAVE_TCM
>   select PLAT_SAMSUNG
>   select PM_GENERIC_DOMAINS if PM
> @@ -165,7 +164,6 @@ config MACH_SMDK6410
>   bool "SMDK6410"
>   depends on ATAGS
>   select CPU_S3C6410
> - select HAVE_S3C2410_WATCHDOG if WATCHDOG
>   select S3C64XX_SETUP_FB_24BPP
>   select S3C64XX_SETUP_I2C1
>   select S3C64XX_SETUP_IDE
> diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
> index 03984a791879..b3db1191e437 100644
> --- a/arch/arm/mach-s5pv210/Kconfig
> +++ b/arch/arm/mach-s5pv210/Kconfig
> @@ -14,7 +14,6 @@ config ARCH_S5PV210
>   select COMMON_CLK_SAMSUNG
>   select GPIOLIB
>   select HAVE_S3C2410_I2C if I2C
> - select HAVE_S3C2410_WATCHDOG if WATCHDOG
>   select HAVE_S3C_RTC if RTC_CLASS
>   select PINCTRL
>   select PINCTRL_EXYNOS
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index cd58f8495c45..d235b27cf372 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -80,7 +80,6 @@ config ARCH_EXYNOS
>   select EXYNOS_CHIPID
>   select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
>   select EXYNOS_PMU
> - select HAVE_S3C2410_WATCHDOG if WATCHDOG
>   select HAVE_S3C_RTC if RTC_CLASS
>   select PINCTRL
>   select PINCTRL_EXYNOS
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 4f4687c46d38..ae86ea135d2b 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -478,16 +478,8 @@ config IXP4XX_WATCHDOG
>  
> Say N if you are unsure.
>  
> -config HAVE_S3C2410_WATCHDOG
> - bool
> - help
> -   This will include watchdog timer support for Samsung SoCs. If
> -   you want to include watchdog support for any machine, kindly
> -   select this in the respective mach-/Kconfig file.
> -
>  config S3C2410_WATCHDOG
>   tristate "S3C2410 Watchdog"
> - depends on HAVE_S3C2410_WATCHDOG || COMPILE_TEST
>   select WATCHDOG_CORE
>   select MFD_SYSCON if ARCH_EXYNOS
>   help
> -- 
> 2.17.1
> 


Re: [PATCH -next] irqchip/imx-intmux: Fix irqdata regs save in imx_intmux_runtime_suspend()

2020-07-29 Thread Marc Zyngier

On 2020-07-29 16:58, Wei Yongjun wrote:

Gcc report warning as follows:

drivers/irqchip/irq-imx-intmux.c:316:29: warning:
 variable 'irqchip_data' set but not used [-Wunused-but-set-variable]
  316 |  struct intmux_irqchip_data irqchip_data;
  | ^~~~

irqdata regs is stored to this variable on the stack in
imx_intmux_runtime_suspend(), which means a nop. this commit
fix to save regs to the right place.

Fixes: bb403111e017 ("irqchip/imx-intmux: Implement intmux runtime
power management")
Reported-by: Hulk Robot 
Signed-off-by: Wei Yongjun 
---
 drivers/irqchip/irq-imx-intmux.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/irqchip/irq-imx-intmux.c 
b/drivers/irqchip/irq-imx-intmux.c

index 4c9e40d193d6..e35b7b09c3ab 100644
--- a/drivers/irqchip/irq-imx-intmux.c
+++ b/drivers/irqchip/irq-imx-intmux.c
@@ -313,12 +313,12 @@ static int imx_intmux_remove(struct 
platform_device *pdev)

 static int imx_intmux_runtime_suspend(struct device *dev)
 {
struct intmux_data *data = dev_get_drvdata(dev);
-   struct intmux_irqchip_data irqchip_data;
+   struct intmux_irqchip_data *irqchip_data;
int i;

for (i = 0; i < data->channum; i++) {
-   irqchip_data = data->irqchip_data[i];
-   irqchip_data.saved_reg = readl_relaxed(data->regs + CHANIER(i));
+   irqchip_data = >irqchip_data[i];
+   irqchip_data->saved_reg = readl_relaxed(data->regs + 
CHANIER(i));
}

clk_disable_unprepare(data->ipg_clk);
@@ -329,7 +329,7 @@ static int imx_intmux_runtime_suspend(struct device 
*dev)

 static int imx_intmux_runtime_resume(struct device *dev)
 {
struct intmux_data *data = dev_get_drvdata(dev);
-   struct intmux_irqchip_data irqchip_data;
+   struct intmux_irqchip_data *irqchip_data;
int ret, i;

ret = clk_prepare_enable(data->ipg_clk);
@@ -339,8 +339,8 @@ static int imx_intmux_runtime_resume(struct device 
*dev)

}

for (i = 0; i < data->channum; i++) {
-   irqchip_data = data->irqchip_data[i];
-   writel_relaxed(irqchip_data.saved_reg, data->regs + CHANIER(i));
+   irqchip_data = >irqchip_data[i];
+   writel_relaxed(irqchip_data->saved_reg, data->regs + 
CHANIER(i));
}

return 0;


Amazing. Thanks for fixing this.

Johakim: I guess this was never tested, was it?

M.
--
Jazz is not dead. It just smells funny...


Re: [PATCH 1/2] power: supply: cpcap-battery: Fix kerneldoc of cpcap_battery_read_accumulated()

2020-07-29 Thread Sebastian Reichel
Hi,

On Wed, Jul 29, 2020 at 09:43:47AM +0200, Krzysztof Kozlowski wrote:
> Fix W=1 compile warnings (invalid kerneldoc):
> 
> drivers/power/supply/cpcap-battery.c:292: warning: Function parameter or 
> member 'ccd' not described in 'cpcap_battery_read_accumulated'
> drivers/power/supply/cpcap-battery.c:292: warning: Excess function 
> parameter 'regs' description in 'cpcap_battery_read_accumulated'
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---

Thanks, merged.

-- Sebastian

>  drivers/power/supply/cpcap-battery.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/power/supply/cpcap-battery.c 
> b/drivers/power/supply/cpcap-battery.c
> index 6e9392901b0a..90eba364664b 100644
> --- a/drivers/power/supply/cpcap-battery.c
> +++ b/drivers/power/supply/cpcap-battery.c
> @@ -274,7 +274,7 @@ static int cpcap_battery_cc_to_ua(struct 
> cpcap_battery_ddata *ddata,
>  /**
>   * cpcap_battery_read_accumulated - reads cpcap coulomb counter
>   * @ddata: device driver data
> - * @regs: coulomb counter values
> + * @ccd: coulomb counter values
>   *
>   * Based on Motorola mapphone kernel function data_read_regs().
>   * Looking at the registers, the coulomb counter seems similar to
> -- 
> 2.17.1
> 


signature.asc
Description: PGP signature


Re: [PATCH 2/2] power: supply: Fix kerneldoc of power_supply_temp2resist_simple()

2020-07-29 Thread Sebastian Reichel
Hi,

On Wed, Jul 29, 2020 at 09:43:48AM +0200, Krzysztof Kozlowski wrote:
> Fix W=1 compile warnings (invalid kerneldoc):
> 
> drivers/power/supply/power_supply_core.c:747: warning: Function parameter 
> or member 'temp' not described in 'power_supply_temp2resist_simple'
> drivers/power/supply/power_supply_core.c:747: warning: Excess function 
> parameter 'ocv' description in 'power_supply_temp2resist_simple'
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---

Thanks, merged.

-- Sebastian

>  drivers/power/supply/power_supply_core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/power/supply/power_supply_core.c 
> b/drivers/power/supply/power_supply_core.c
> index 90e56736d479..ccbad435ed12 100644
> --- a/drivers/power/supply/power_supply_core.c
> +++ b/drivers/power/supply/power_supply_core.c
> @@ -733,7 +733,7 @@ EXPORT_SYMBOL_GPL(power_supply_put_battery_info);
>   * percent
>   * @table: Pointer to battery resistance temperature table
>   * @table_len: The table length
> - * @ocv: Current temperature
> + * @temp: Current temperature
>   *
>   * This helper function is used to look up battery internal resistance 
> percent
>   * according to current temperature value from the resistance temperature 
> table,
> -- 
> 2.17.1
> 


signature.asc
Description: PGP signature


Re: [PATCH v5 2/4] power: supply: bq27xxx_battery: Add the BQ27z561 Battery monitor

2020-07-29 Thread Sebastian Reichel
Hi,

On Wed, Jul 29, 2020 at 10:55:54AM -0500, Dan Murphy wrote:
> > +<<< HEAD
> 
> Need to remove this artifact from a rebase.
> 
> Not sure how this got here as it does not appear in my source.

You don't see it in your source, since you removed it in patch 4.

-- Sebastian


signature.asc
Description: PGP signature


Re: [patch V5 05/15] entry: Provide infrastructure for work before transitioning to guest mode

2020-07-29 Thread Qian Cai
On Wed, Jul 22, 2020 at 11:59:59PM +0200, Thomas Gleixner wrote:
> From: Thomas Gleixner 
> 
> Entering a guest is similar to exiting to user space. Pending work like
> handling signals, rescheduling, task work etc. needs to be handled before
> that.
> 
> Provide generic infrastructure to avoid duplication of the same handling
> code all over the place.
> 
> The transfer to guest mode handling is different from the exit to usermode
> handling, e.g. vs. rseq and live patching, so a separate function is used.
> 
> The initial list of work items handled is:
> 
> TIF_SIGPENDING, TIF_NEED_RESCHED, TIF_NOTIFY_RESUME
> 
> Architecture specific TIF flags can be added via defines in the
> architecture specific include files.
> 
> The calling convention is also different from the syscall/interrupt entry
> functions as KVM invokes this from the outer vcpu_run() loop with
> interrupts and preemption enabled. To prevent missing a pending work item
> it invokes a check for pending TIF work from interrupt disabled code right
> before transitioning to guest mode. The lockdep, RCU and tracing state
> handling is also done directly around the switch to and from guest mode.
> 
> Signed-off-by: Thomas Gleixner 

SR-IOV will start trigger a warning below in this commit,

A reproducer:
# echo 1 > /sys/class/net/eno58/device/sriov_numvfs (bnx2x)
# git clone https://gitlab.com/cailca/linux-mm
# cd linux-mm; make
# ./random -x 0-100 -k:02:09.0

https://gitlab.com/cailca/linux-mm/-/blob/master/random.c#L1247
(x86.config is also included in the repo.)

[  765.409027] [ cut here ]
[  765.434611] WARNING: CPU: 13 PID: 3377 at include/linux/entry-kvm.h:75 
kvm_arch_vcpu_ioctl_run+0xb52/0x1320 [kvm]
[  765.487229] Modules linked in: vfio_pci vfio_virqfd vfio_iommu_type1 vfio 
loop nls_ascii nls_cp437 vfat fat
[  766.118568] CPU: 13 PID: 3377 Comm: qemu-kvm Not tainted 
5.8.0-rc7-next-20200729 #2
[  766.147011]  ? kthread_create_worker_on_cpu+0xc0/0xc0
[  766.147016]  ret_from_fork+0x22/0x30
[  766.782999] Hardware name: HP ProLiant BL660c Gen9, BIOS I38 10/17/2018
[  766.817799] RIP: 0010:kvm_arch_vcpu_ioctl_run+0xb52/0x1320 [kvm]
[  766.850054] Code: e8 03 0f b6 04 18 84 c0 74 06 0f 8e 4a 03 00 00 41 c6 85 
50 2d 00 00 00 e9 24 f8 ff ff 4c 89 ef e8 93 a8 02 00 e9 3d f8 ff ff <0f> 0b e9 
f2 f8 ff ff 48 81 c6 c0 01 00 00 4c 89 ef e8 18 4c fe
 ff
[  766.942485] RSP: 0018:c90007017b58 EFLAGS: 00010202
[  766.970899] RAX: 0001 RBX: dc00 RCX: c0f0ef8a
[  767.008488] RDX:  RSI: 0001 RDI: 88956a3821a0
[  767.045726] RBP: c90007017bb8 R08: ed1269290010 R09: ed1269290010
[  767.083242] R10: 88934948007f R11: ed126929000f R12: 889349480424
[  767.120809] R13: 889349480040 R14: 88934948006c R15: 88980e2da000
[  767.160531] FS:  7f12b0e98700() GS:88985fa4() 
knlGS:
[  767.203199] CS:  0010 DS:  ES:  CR0: 80050033
[  767.235083] CR2:  CR3: 00120d186002 CR4: 001726e0
[  767.272303] Call Trace:
[  767.272303] Call Trace:
[  767.286947]  kvm_vcpu_ioctl+0x3e9/0xb30 [kvm]
[  767.311162]  ? kvm_vcpu_block+0xd30/0xd30 [kvm]
[  767.335281]  ? find_held_lock+0x33/0x1c0
[  767.357492]  ? __fget_files+0x1cb/0x300
[  767.378687]  ? lock_downgrade+0x730/0x730
[  767.401410]  ? rcu_read_lock_held+0xaa/0xc0
[  767.424228]  ? rcu_read_lock_sched_held+0xd0/0xd0
[  767.450078]  ? find_held_lock+0x33/0x1c0
[  767.471876]  ? __fget_files+0x1e5/0x300
[  767.493841]  __x64_sys_ioctl+0x315/0x102f
[  767.516579]  ? generic_block_fiemap+0x60/0x60
[  767.540678]  ? syscall_enter_from_user_mode+0x1b/0x210
[  767.568612]  ? rcu_read_lock_sched_held+0xaa/0xd0
[  767.593950]  ? lockdep_hardirqs_on_prepare+0x33e/0x4e0
[  767.621355]  ? syscall_enter_from_user_mode+0x20/0x210
[  767.649283]  ? trace_hardirqs_on+0x20/0x1b5
[  767.673770]  do_syscall_64+0x33/0x40
[  767.694699]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  767.723392] RIP: 0033:0x7f12b999a87b
[  767.744252] Code: 0f 1e fa 48 8b 05 0d 96 2c 00 64 c7 00 26 00 00 00 48 c7 
c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d dd 95 2c 00 f7 d8 64 89  8
[  767.837418] RSP: 002b:7f12b0e97678 EFLAGS: 0246 ORIG_RAX: 
0010
[  767.877074] RAX: ffda RBX: 55712c857c60 RCX: 7f12b999a87b
[  767.914242] RDX:  RSI: ae80 RDI: 0014
[  767.951945] RBP: 55712c857cfb R08: 55712ac4fad0 R09: 55712b3f2080
[  767.989036] R10:  R11: 0246 R12: 55712ac38100
[  768.025851] R13: 7ffd996e9edf R14: 7f12becc5000 R15: 55712c857c60
[  768.063363] irq event stamp: 5257
[  768.082559] hardirqs last  enabled at (5273): [] 
asm_sysvec_call_function_single+0x12/

[PATCH v2 1/2] thermal: qcom-spmi-temp-alarm: Don't suppress negative temp

2020-07-29 Thread Guru Das Srinagesh
From: Veera Vegivada 

Currently driver is suppressing the negative temperature
readings from the vadc. Consumers of the thermal zones need
to read the negative temperature too. Don't suppress the
readings.

Fixes: c610afaa21d3c6e ("thermal: Add QPNP PMIC temperature alarm driver")
Signed-off-by: Veera Vegivada 
Signed-off-by: Guru Das Srinagesh 
---
 drivers/thermal/qcom/qcom-spmi-temp-alarm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/qcom/qcom-spmi-temp-alarm.c 
b/drivers/thermal/qcom/qcom-spmi-temp-alarm.c
index bf7bae4..6dc879f 100644
--- a/drivers/thermal/qcom/qcom-spmi-temp-alarm.c
+++ b/drivers/thermal/qcom/qcom-spmi-temp-alarm.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /*
- * Copyright (c) 2011-2015, 2017, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2011-2015, 2017, 2020, The Linux Foundation. All rights 
reserved.
  */
 
 #include 
@@ -191,7 +191,7 @@ static int qpnp_tm_get_temp(void *data, int *temp)
chip->temp = mili_celsius;
}
 
-   *temp = chip->temp < 0 ? 0 : chip->temp;
+   *temp = chip->temp;
 
return 0;
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH v2 2/2] thermal: qcom-spmi-temp-alarm: add support for GEN2 rev 1 PMIC peripherals

2020-07-29 Thread Guru Das Srinagesh
From: David Collins 

Add support for TEMP_ALARM GEN2 PMIC peripherals with digital
major revision 1.  This revision utilizes a different temperature
threshold mapping than earlier revisions.

Signed-off-by: David Collins 
Signed-off-by: Guru Das Srinagesh 
---
Changes from v1:
- Added space padding for the arrays, moved "||" to previous line

 drivers/thermal/qcom/qcom-spmi-temp-alarm.c | 91 +++--
 1 file changed, 61 insertions(+), 30 deletions(-)

diff --git a/drivers/thermal/qcom/qcom-spmi-temp-alarm.c 
b/drivers/thermal/qcom/qcom-spmi-temp-alarm.c
index 6dc879f..7419e19 100644
--- a/drivers/thermal/qcom/qcom-spmi-temp-alarm.c
+++ b/drivers/thermal/qcom/qcom-spmi-temp-alarm.c
@@ -17,6 +17,7 @@
 
 #include "../thermal_core.h"
 
+#define QPNP_TM_REG_DIG_MAJOR  0x01
 #define QPNP_TM_REG_TYPE   0x04
 #define QPNP_TM_REG_SUBTYPE0x05
 #define QPNP_TM_REG_STATUS 0x08
@@ -38,26 +39,30 @@
 
 #define ALARM_CTRL_FORCE_ENABLEBIT(7)
 
-/*
- * Trip point values based on threshold control
- * 0 = {105 C, 125 C, 145 C}
- * 1 = {110 C, 130 C, 150 C}
- * 2 = {115 C, 135 C, 155 C}
- * 3 = {120 C, 140 C, 160 C}
-*/
-#define TEMP_STAGE_STEP2   /* Stage step: 20.000 C 
*/
-#define TEMP_STAGE_HYSTERESIS  2000
+#define THRESH_COUNT   4
+#define STAGE_COUNT3
+
+/* Over-temperature trip point values in mC */
+static const long temp_map_gen1[THRESH_COUNT][STAGE_COUNT] = {
+   { 105000, 125000, 145000 },
+   { 11, 13, 15 },
+   { 115000, 135000, 155000 },
+   { 12, 14, 16 },
+};
+
+static const long temp_map_gen2_v1[THRESH_COUNT][STAGE_COUNT] = {
+   {  9, 11, 14 },
+   {  95000, 115000, 145000 },
+   { 10, 12, 15 },
+   { 105000, 125000, 155000 },
+};
 
-#define TEMP_THRESH_MIN105000  /* Threshold Min: 105 C 
*/
-#define TEMP_THRESH_STEP   5000/* Threshold step: 5 C */
+#define TEMP_THRESH_STEP   5000 /* Threshold step: 5 C */
 
 #define THRESH_MIN 0
 #define THRESH_MAX 3
 
-/* Stage 2 Threshold Min: 125 C */
-#define STAGE2_THRESHOLD_MIN   125000
-/* Stage 2 Threshold Max: 140 C */
-#define STAGE2_THRESHOLD_MAX   14
+#define TEMP_STAGE_HYSTERESIS  2000
 
 /* Temperature in Milli Celsius reported during stage 0 if no ADC is present */
 #define DEFAULT_TEMP   37000
@@ -77,6 +82,7 @@ struct qpnp_tm_chip {
boolinitialized;
 
struct iio_channel  *adc;
+   const long  (*temp_map)[THRESH_COUNT][STAGE_COUNT];
 };
 
 /* This array maps from GEN2 alarm state to GEN1 alarm stage */
@@ -101,6 +107,23 @@ static int qpnp_tm_write(struct qpnp_tm_chip *chip, u16 
addr, u8 data)
 }
 
 /**
+ * qpnp_tm_decode_temp() - return temperature in mC corresponding to the
+ * specified over-temperature stage
+ * @chip:  Pointer to the qpnp_tm chip
+ * @stage: Over-temperature stage
+ *
+ * Return: temperature in mC
+ */
+static long qpnp_tm_decode_temp(struct qpnp_tm_chip *chip, unsigned int stage)
+{
+   if (!chip->temp_map || chip->thresh >= THRESH_COUNT || stage == 0 ||
+   stage > STAGE_COUNT)
+   return 0;
+
+   return (*chip->temp_map)[chip->thresh][stage - 1];
+}
+
+/**
  * qpnp_tm_get_temp_stage() - return over-temperature stage
  * @chip:  Pointer to the qpnp_tm chip
  *
@@ -149,14 +172,12 @@ static int qpnp_tm_update_temp_no_adc(struct qpnp_tm_chip 
*chip)
 
if (stage_new > stage_old) {
/* increasing stage, use lower bound */
-   chip->temp = (stage_new - 1) * TEMP_STAGE_STEP +
-chip->thresh * TEMP_THRESH_STEP +
-TEMP_STAGE_HYSTERESIS + TEMP_THRESH_MIN;
+   chip->temp = qpnp_tm_decode_temp(chip, stage_new)
+   + TEMP_STAGE_HYSTERESIS;
} else if (stage_new < stage_old) {
/* decreasing stage, use upper bound */
-   chip->temp = stage_new * TEMP_STAGE_STEP +
-chip->thresh * TEMP_THRESH_STEP -
-TEMP_STAGE_HYSTERESIS + TEMP_THRESH_MIN;
+   chip->temp = qpnp_tm_decode_temp(chip, stage_new + 1)
+   - TEMP_STAGE_HYSTERESIS;
}
 
chip->stage = stage;
@@ -199,26 +220,28 @@ static int qpnp_tm_get_temp(void *data, int *temp)
 static int qpnp_tm_update_critical_trip_temp(struct qpnp_tm_chip *chip,
 int temp)
 {
-   u8 reg;
+   long stage2_threshold_min = (*chip->temp_map)[THRESH_MIN][1];
+   long stage2_threshold_max = (*chip->temp_map)[THRESH_MAX][1];
bool disable_s2_shutdown = false;
+   u8 reg;
 
 

Error: invalid switch -me200

2020-07-29 Thread kernel test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   6ba1b005ffc388c2aeaddae20da29e4810dea298
commit: ca9b31f6bb9c6aa9b4e5f0792f39a97bbffb8c51 Makefile: Fix 
GCC_TOOLCHAIN_DIR prefix for Clang cross compilation
date:   7 days ago
config: powerpc-randconfig-r014-20200729 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
417d3d495f1cfb0a2f7b60d00829925126fdcfd9)
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 powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
git checkout ca9b31f6bb9c6aa9b4e5f0792f39a97bbffb8c51
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc 

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

All errors (new ones prefixed by >>):

   Assembler messages:
>> Error: invalid switch -me200
>> Error: unrecognized option -me200
   clang-12: error: assembler command failed with exit code 1 (use -v to see 
invocation)
   make[2]: *** [scripts/Makefile.build:281: scripts/mod/empty.o] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [Makefile:1174: prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [Makefile:185: __sub-make] Error 2
   make: Target 'prepare' not remade because of errors.

---
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] drm/amd/display: Clear dm_state for fast updates

2020-07-29 Thread Kazlauskas, Nicholas

On 2020-07-28 5:08 a.m., dan...@ffwll.ch wrote:

On Mon, Jul 27, 2020 at 10:49:48PM -0400, Kazlauskas, Nicholas wrote:

On 2020-07-27 5:32 p.m., Daniel Vetter wrote:

On Mon, Jul 27, 2020 at 11:11 PM Mazin Rezk  wrote:


On Monday, July 27, 2020 4:29 PM, Daniel Vetter  wrote:


On Mon, Jul 27, 2020 at 9:28 PM Christian König
 wrote:


Am 27.07.20 um 16:05 schrieb Kazlauskas, Nicholas:

On 2020-07-27 9:39 a.m., Christian König wrote:

Am 27.07.20 um 07:40 schrieb Mazin Rezk:

This patch fixes a race condition that causes a use-after-free during
amdgpu_dm_atomic_commit_tail. This can occur when 2 non-blocking
commits
are requested and the second one finishes before the first.
Essentially,
this bug occurs when the following sequence of events happens:

1. Non-blocking commit #1 is requested w/ a new dm_state #1 and is
deferred to the workqueue.

2. Non-blocking commit #2 is requested w/ a new dm_state #2 and is
deferred to the workqueue.

3. Commit #2 starts before commit #1, dm_state #1 is used in the
commit_tail and commit #2 completes, freeing dm_state #1.

4. Commit #1 starts after commit #2 completes, uses the freed dm_state
1 and dereferences a freelist pointer while setting the context.


Well I only have a one mile high view on this, but why don't you let
the work items execute in order?

That would be better anyway cause this way we don't trigger a cache
line ping pong between CPUs.

Christian.


We use the DRM helpers for managing drm_atomic_commit_state and those
helpers internally push non-blocking commit work into the system
unbound work queue.


Mhm, well if you send those helper atomic commits in the order A,B and
they execute it in the order B,A I would call that a bug :)


The way it works is it pushes all commits into unbound work queue, but
then forces serialization as needed. We do _not_ want e.g. updates on
different CRTC to be serialized, that would result in lots of judder.
And hw is funny enough that there's all kinds of dependencies.

The way you force synchronization is by adding other CRTC state
objects. So if DC is busted and can only handle a single update per
work item, then I guess you always need all CRTC states and everything
will be run in order. But that also totally kills modern multi-screen
compositors. Xorg isn't modern, just in case that's not clear :-)

Lucking at the code it seems like you indeed have only a single dm
state, so yeah global sync is what you'll need as immediate fix, and
then maybe fix up DM to not be quite so silly ... or at least only do
the dm state stuff when really needed.

We could also sprinkle the drm_crtc_commit structure around a bit
(it's the glue that provides the synchronization across commits), but
since your dm state is global just grabbing all crtc states
unconditionally as part of that is probably best.


While we could duplicate a copy of that code with nothing but the
workqueue changed that isn't something I'd really like to maintain
going forward.


I'm not talking about duplicating the code, I'm talking about fixing the
helpers. I don't know that code well, but from the outside it sounds
like a bug there.

And executing work items in the order they are submitted is trivial.

Had anybody pinged Daniel or other people familiar with the helper code
about it?


Yeah something is wrong here, and the fix looks horrible :-)

Aside, I've also seen some recent discussion flare up about
drm_atomic_state_get/put used to paper over some other use-after-free,
but this time related to interrupt handlers. Maybe a few rules about
that:
- dont
- especially not when it's interrupt handlers, because you can't call
drm_atomic_state_put from interrupt handlers.

Instead have an spin_lock_irq to protect the shared date with your
interrupt handler, and _copy_ the date over. This is e.g. what
drm_crtc_arm_vblank_event does.


Nicholas wrote a patch that attempted to resolve the issue by adding every
CRTC into the commit to use use the stall checks. [1] While this forces
synchronisation on commits, it's kind of a hacky method that may take a
toll on performance.

Is it possible to have a DRM helper that forces synchronisation on some
commits without having to add every CRTC into the commit?

Also, is synchronisation really necessary for fast updates in amdgpu?
I'll admit, the idea of eliminating the use-after-free bug by eliminating
the use entirely doesn't seem ideal; but is forcing synchronisation on
these updates that much better?


Well clearing the dc_state pointer here and then allocating another
one in atomic_commit_tail also looks fishy. The proper fix is probably
a lot more involved, but yeah interim fix is to grab all crtc states
iff you also grabbed the dm_atomic_state structure. Real fix is to
only do this when necessary, which pretty much means the dc_state
needs to be somehow split up, or there needs to be some guarantees
about when it's necessary and when not. Otherwise parallel commits on
different CRTC are not possible with the current dc 

Re: [PATCH 6/7] modules: return licensing information from find_symbol

2020-07-29 Thread Jessica Yu

+++ Christoph Hellwig [29/07/20 08:27 +0200]:

Report the GPLONLY status through a new argument.

Signed-off-by: Christoph Hellwig 
---
include/linux/module.h |  2 +-
kernel/module.c| 16 +++-
2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/include/linux/module.h b/include/linux/module.h
index b79219eed83c56..c9bc3412ae4465 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -582,7 +582,7 @@ struct module *find_module(const char *name);
struct symsearch {
const struct kernel_symbol *start, *stop;
const s32 *crcs;
-   enum {
+   enum mod_licence {
NOT_GPL_ONLY,
GPL_ONLY,
WILL_BE_GPL_ONLY,
diff --git a/kernel/module.c b/kernel/module.c
index 54e853c7212f72..a907bc57d343f9 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -495,6 +495,7 @@ struct find_symbol_arg {
struct module *owner;
const s32 *crc;
const struct kernel_symbol *sym;
+   enum mod_licence licence;


Just a small nit. Most of module.c uses license rather than licence -
could we unify the spelling to remain consistent? Sigh, American vs.
British English.. :)



Re: [PATCH v18 2/4] dt-bindings: power: Convert battery.txt to battery.yaml

2020-07-29 Thread Sebastian Reichel
Hi Ricardo and Dan,

On Tue, Jul 28, 2020 at 03:08:12PM -0500, Ricardo Rivera-Matos wrote:
> From: Dan Murphy 
> 
> Convert the battery.txt file to yaml and fix up the examples.
> 
> Signed-off-by: Dan Murphy 
> Reviewed-by: Rob Herring 
> ---

I merged this doing some modifcations while applying, so that this
is not postponed and risking conflicts due to added properties:


> [...]
> +patternProperties:
> +  '^ocv-capacity-table-[0-100]$':
> [...]

[0-100] is a valid regex, but counterintuitively only allows 0 and
1. For example it does not apply for ocv-capacity-table-2.

I used [0-9]+ instead, which is being used by pinctrl.

> +examples:
> +  - |
> +power {
> +  #address-cells = <1>;
> +  #size-cells = <0>;
> +
> +  battery: battery {
> +compatible = "simple-battery";
> +over-voltage-threshold-microvolt = <450>;
> +re-charge-voltage-microvolt = <25>;
> +voltage-min-design-microvolt = <320>;
> +voltage-max-design-microvolt = <420>;
> +energy-full-design-microwatt-hours = <529>;
> +charge-full-design-microamp-hours = <143>;
> +precharge-current-microamp = <256000>;
> +precharge-upper-limit-microvolt = <250>;
> +charge-term-current-microamp = <128000>;
> +constant-charge-current-max-microamp = <90>;
> +constant-charge-voltage-max-microvolt = <420>;
> +factory-internal-resistance-micro-ohms = <25>;
> +ocv-capacity-celsius = <(-10) 10>;

You state, that there is a table for -10 degrees and one for 10
degrees...

> +ocv-capacity-table-0 = <4185000 100>, <4113000 95>, <4066000 90>;

... and then you provide only the table for -10 degrees. I fixed
this by simply using the previous example (tables for -10, 0 and 10
degrees) and 3 tables and added a comment above the tables.

-- Sebastian


signature.asc
Description: PGP signature


Re: drivers/net/ethernet/pensando/ionic/ionic_lif.c:2004:3-9: preceding lock on line 1998 (fwd)

2020-07-29 Thread Shannon Nelson

On 7/29/20 9:37 AM, Julia Lawall wrote:

Hello,

It looks like an unlock may be wanted on line 2004.

julia


Thanks for catching that, Julia.  I'll follow up shortly.

sln



-- Forwarded message --
Date: Thu, 30 Jul 2020 00:08:47 +0800
From: kernel test robot 
To: kbu...@lists.01.org
Cc: l...@intel.com, Julia Lawall 
Subject: drivers/net/ethernet/pensando/ionic/ionic_lif.c:2004:3-9: preceding
 lock on line 1998

CC: kbuild-...@lists.01.org
CC: linux-kernel@vger.kernel.org
TO: Shannon Nelson 

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   6ba1b005ffc388c2aeaddae20da29e4810dea298
commit: 0925e9db4dc86daf666d9a3d53c7db14ac6d5d00 ionic: use mutex to protect 
queue operations
date:   9 days ago
:: branch date: 21 hours ago
:: commit date: 9 days ago
config: powerpc-randconfig-c004-20200728 (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0

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


coccinelle warnings: (new ones prefixed by >>)


drivers/net/ethernet/pensando/ionic/ionic_lif.c:2004:3-9: preceding lock on 
line 1998

# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0925e9db4dc86daf666d9a3d53c7db14ac6d5d00
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git remote update linus
git checkout 0925e9db4dc86daf666d9a3d53c7db14ac6d5d00
vim +2004 drivers/net/ethernet/pensando/ionic/ionic_lif.c

beead698b1736df Shannon Nelson 2019-09-03  1992
086c18f2452d002 Shannon Nelson 2020-07-07  1993  int ionic_reset_queues(struct 
ionic_lif *lif, ionic_reset_cb cb, void *arg)
beead698b1736df Shannon Nelson 2019-09-03  1994  {
beead698b1736df Shannon Nelson 2019-09-03  1995 bool running;
beead698b1736df Shannon Nelson 2019-09-03  1996 int err = 0;
beead698b1736df Shannon Nelson 2019-09-03  1997
0925e9db4dc86da Shannon Nelson 2020-07-20 @1998 
mutex_lock(>queue_lock);
beead698b1736df Shannon Nelson 2019-09-03  1999 running = 
netif_running(lif->netdev);
b59eabd23ee53e8 Shannon Nelson 2020-06-18  2000 if (running) {
b59eabd23ee53e8 Shannon Nelson 2020-06-18  2001 
netif_device_detach(lif->netdev);
beead698b1736df Shannon Nelson 2019-09-03  2002 err = 
ionic_stop(lif->netdev);
086c18f2452d002 Shannon Nelson 2020-07-07  2003 if (err)
0925e9db4dc86da Shannon Nelson 2020-07-20 @2004 return 
err;
b59eabd23ee53e8 Shannon Nelson 2020-06-18  2005 }
086c18f2452d002 Shannon Nelson 2020-07-07  2006
086c18f2452d002 Shannon Nelson 2020-07-07  2007 if (cb)
086c18f2452d002 Shannon Nelson 2020-07-07  2008 cb(lif, arg);
086c18f2452d002 Shannon Nelson 2020-07-07  2009
086c18f2452d002 Shannon Nelson 2020-07-07  2010 if (running) {
086c18f2452d002 Shannon Nelson 2020-07-07  2011 err = 
ionic_open(lif->netdev);
b59eabd23ee53e8 Shannon Nelson 2020-06-18  2012 
netif_device_attach(lif->netdev);
b59eabd23ee53e8 Shannon Nelson 2020-06-18  2013 }
0925e9db4dc86da Shannon Nelson 2020-07-20  2014 
mutex_unlock(>queue_lock);
beead698b1736df Shannon Nelson 2019-09-03  2015
beead698b1736df Shannon Nelson 2019-09-03  2016 return err;
beead698b1736df Shannon Nelson 2019-09-03  2017  }
beead698b1736df Shannon Nelson 2019-09-03  2018

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




Re: [PATCH] scsi: sd: add runtime pm to open / release

2020-07-29 Thread Martin Kepplinger



Am 29. Juli 2020 17:44:42 MESZ schrieb James Bottomley 
:
>On Wed, 2020-07-29 at 17:40 +0200, Martin Kepplinger wrote:
>> On 29.07.20 16:53, James Bottomley wrote:
>> > On Wed, 2020-07-29 at 07:46 -0700, James Bottomley wrote:
>> > > On Wed, 2020-07-29 at 10:32 -0400, Alan Stern wrote:
>[...]
>> > > > This error report comes from the SCSI layer, not the block
>> > > > layer.
>> > > 
>> > > That sense code means "NOT READY TO READY CHANGE, MEDIUM MAY HAVE
>> > > CHANGED" so it sounds like it something we should be
>> > > ignoring.  Usually this signals a problem, like you changed the
>> > > medium manually (ejected the CD).  But in this case you can tell
>> > > us to expect this by setting
>> > > 
>> > > sdev->expecting_cc_ua
>> > > 
>> > > And we'll retry.  I think you need to set this on all resumed
>> > > devices.
>> > 
>> > Actually, it's not quite that easy, we filter out this ASC/ASCQ
>> > combination from the check because we should never ignore medium
>> > might have changed events on running devices.  We could ignore it
>> > if we had a flag to say the power has been yanked (perhaps an
>> > additional sdev flag you set on resume) but we would still miss the
>> > case where you really had powered off the drive and then changed
>> > the media ... if you can regard this as the user's problem, then we
>> > might have a solution.
>> > 
>> > James
>> >  
>> 
>> oh I see what you mean now, thanks for the ellaboration.
>> 
>> if I do the following change, things all look normal and runtime pm
>> works. I'm not 100% sure if just setting expecting_cc_ua in resume()
>> is "correct" but that looks like it is what you're talking about:
>> 
>> (note that this is of course with the one block layer diff applied
>> that Alan posted a few emails back)
>> 
>> 
>> --- a/drivers/scsi/scsi_error.c
>> +++ b/drivers/scsi/scsi_error.c
>> @@ -554,16 +554,8 @@ int scsi_check_sense(struct scsi_cmnd *scmd)
>>  * so that we can deal with it there.
>>  */
>> if (scmd->device->expecting_cc_ua) {
>> -   /*
>> -* Because some device does not queue unit
>> -* attentions correctly, we carefully check
>> -* additional sense code and qualifier so as
>> -* not to squash media change unit attention.
>> -*/
>> -   if (sshdr.asc != 0x28 || sshdr.ascq != 0x00)
>> {
>> -   scmd->device->expecting_cc_ua = 0;
>> -   return NEEDS_RETRY;
>> -   }
>> +   scmd->device->expecting_cc_ua = 0;
>> +   return NEEDS_RETRY;
>
>Well, yes, but you can't do this because it would lose us media change
>events in the non-suspend/resume case which we really don't want. 
>That's why I was suggesting a new flag.
>
>James

also if I set expecting_cc_ua in resume() only, like I did?

-- 
Martin Kepplinger
xmpp: mart...@jabber.at
Sent from mobile.


Wine List

2020-07-29 Thread Meggan Berg



Hello,

Would you be interested in acquiring an email list of "Wine Enthusiasts List" 
from USA?

We also have data for Beer Enthusiasts List, Liquor Enthusiasts List, Beverage 
Enthusiasts List and many more.

Each record in the list contains Contact Name (First, Middle and Last Name), 
Mailing Address, List type and Opt-in email address.

All the contacts are opt-in verified, 100% permission based and can be used for 
unlimited multi-channel marketing.

Please let me know your thoughts towards procuring the Wine Enthusiasts List.

Best Regards,
Meggan Berg
Research Analyst

We respect your privacy, if you do not wish to receive any further emails from our end, 
please reply with a subject "Remove".



Re: [PATCH 0/2] locking/qspinlock: Break qspinlock_types.h header loop

2020-07-29 Thread Sergey Senozhatsky
On (20/07/29 16:28), pet...@infradead.org wrote:
> On Wed, Jul 29, 2020 at 10:28:49PM +0900, Sergey Senozhatsky wrote:
> > On (20/07/29 15:00), pet...@infradead.org wrote:
> > > On Wed, Jul 29, 2020 at 10:51:44PM +1000, Herbert Xu wrote:
> > > > On Wed, Jul 29, 2020 at 02:47:44PM +0200, pet...@infradead.org wrote:
> > > > >
> > [..]
> > > > > Anyway, the patches look sane enough, I'll go stick them in
> > > > > tip/locking/core or somesuch.
> > > > 
> > > > Perhaps add them on top of the other two patches in locking/header?
> > > 
> > > Can do,
> > 
> > locking/header would be better
> 
> Done.

Thanks a lot!
I'll run some cross-compilation tests.

-ss


Re: [PATCH v4 2/2] soc: mediatek: add mtk-devapc driver

2020-07-29 Thread Chun-Kuang Hu
Hi, Neal:

Neal Liu  於 2020年7月29日 週三 下午4:29寫道:
>
> MediaTek bus fabric provides TrustZone security support and data
> protection to prevent slaves from being accessed by unexpected
> masters.
> The security violation is logged and sent to the processor for
> further analysis or countermeasures.
>
> Any occurrence of security violation would raise an interrupt, and
> it will be handled by mtk-devapc driver. The violation
> information is printed in order to find the murderer.
>
> Signed-off-by: Neal Liu 
> ---

[snip]

> +
> +static int get_shift_group(struct mtk_devapc_context *ctx)
> +{
> +   u32 vio_shift_sta;
> +   void __iomem *reg;
> +
> +   reg = ctx->devapc_pd_base + ctx->offset->vio_shift_sta;
> +   vio_shift_sta = readl(reg);
> +
> +   if (vio_shift_sta)
> +   return __ffs(vio_shift_sta);
> +
> +   return -EIO;
> +}

get_shift_group() is a small function, I would like to merge this
function into sync_vio_dbg() to make code more simple.

> +

[snip]

> +
> +#define PHY_DEVAPC_TIMEOUT 0x1
> +
> +/*
> + * sync_vio_dbg - do "shift" mechansim" to get full violation information.
> + *shift mechanism is depends on devapc hardware design.
> + *Mediatek devapc set multiple slaves as a group. When 
> violation
> + *is triggered, violation info is kept inside devapc 
> hardware.
> + *Driver should do shift mechansim to "shift" full violation
> + *info to VIO_DBGs registers.
> + *
> + */
> +static int sync_vio_dbg(struct mtk_devapc_context *ctx, u32 shift_bit)
> +{
> +   void __iomem *pd_vio_shift_sta_reg;
> +   void __iomem *pd_vio_shift_sel_reg;
> +   void __iomem *pd_vio_shift_con_reg;
> +   int ret;
> +   u32 val;
> +
> +   pd_vio_shift_sta_reg = ctx->devapc_pd_base + 
> ctx->offset->vio_shift_sta;
> +   pd_vio_shift_sel_reg = ctx->devapc_pd_base + 
> ctx->offset->vio_shift_sel;
> +   pd_vio_shift_con_reg = ctx->devapc_pd_base + 
> ctx->offset->vio_shift_con;
> +
> +   /* Enable shift mechansim */
> +   writel(0x1 << shift_bit, pd_vio_shift_sel_reg);
> +   writel(0x1, pd_vio_shift_con_reg);
> +
> +   ret = readl_poll_timeout(pd_vio_shift_con_reg, val, val == 0x3, 0,
> +PHY_DEVAPC_TIMEOUT);
> +   if (ret)
> +   dev_err(ctx->dev, "%s: Shift violation info failed\n", 
> __func__);
> +
> +   /* Disable shift mechanism */
> +   writel(0x0, pd_vio_shift_con_reg);
> +   writel(0x0, pd_vio_shift_sel_reg);
> +   writel(0x1 << shift_bit, pd_vio_shift_sta_reg);
> +
> +   return ret;
> +}
> +

[snip]

> +
> +/*
> + * devapc_extract_vio_dbg - extract full violation information after doing
> + *  shift mechanism.
> + */
> +static void devapc_extract_vio_dbg(struct mtk_devapc_context *ctx)
> +{
> +   const struct mtk_devapc_vio_dbgs *vio_dbgs;
> +   struct mtk_devapc_vio_info *vio_info;
> +   void __iomem *vio_dbg0_reg;
> +   void __iomem *vio_dbg1_reg;
> +   u32 dbg0;
> +
> +   vio_dbg0_reg = ctx->devapc_pd_base + ctx->offset->vio_dbg0;
> +   vio_dbg1_reg = ctx->devapc_pd_base + ctx->offset->vio_dbg1;
> +
> +   vio_dbgs = ctx->vio_dbgs;
> +   vio_info = ctx->vio_info;
> +
> +   /* Starts to extract violation information */
> +   dbg0 = readl(vio_dbg0_reg);
> +   vio_info->vio_addr = readl(vio_dbg1_reg);
> +
> +   vio_info->master_id = (dbg0 & vio_dbgs->mstid.mask) >>
> + vio_dbgs->mstid.start;

What is master_id? How could we use it to debug? For example, if we
get a master_id = 1, what should we do for this?

> +   vio_info->domain_id = (dbg0 & vio_dbgs->dmnid.mask) >>
> + vio_dbgs->dmnid.start;

What is domain_id? How could we use it to debug? For example, if we
get a domain_id = 2, what should we do for this?

> +   vio_info->write = ((dbg0 & vio_dbgs->vio_w.mask) >>
> +   vio_dbgs->vio_w.start) == 1;
> +   vio_info->read = ((dbg0 & vio_dbgs->vio_r.mask) >>
> + vio_dbgs->vio_r.start) == 1;
> +   vio_info->vio_addr_high = (dbg0 & vio_dbgs->addr_h.mask) >>
> + vio_dbgs->addr_h.start;

What is vio_addr_high? As I know all register address are 32 bits, is
vio_addr_high the address above 32 bits?

> +
> +   devapc_vio_info_print(ctx);
> +}
> +

[snip]

> +
> +/*
> + * devapc_violation_irq - the devapc Interrupt Service Routine (ISR) will 
> dump
> + *violation information including which master 
> violates
> + *access slave.
> + */
> +static irqreturn_t devapc_violation_irq(int irq_number,
> +   struct mtk_devapc_context *ctx)
> +{
> +   u32 vio_idx;
> +
> +   /*
> +* Mask slave's irq before clearing vio status.
> +* Must do it to avoid nested 

drivers/net/ethernet/pensando/ionic/ionic_lif.c:2004:3-9: preceding lock on line 1998 (fwd)

2020-07-29 Thread Julia Lawall
Hello,

It looks like an unlock may be wanted on line 2004.

julia

-- Forwarded message --
Date: Thu, 30 Jul 2020 00:08:47 +0800
From: kernel test robot 
To: kbu...@lists.01.org
Cc: l...@intel.com, Julia Lawall 
Subject: drivers/net/ethernet/pensando/ionic/ionic_lif.c:2004:3-9: preceding
lock on line 1998

CC: kbuild-...@lists.01.org
CC: linux-kernel@vger.kernel.org
TO: Shannon Nelson 

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   6ba1b005ffc388c2aeaddae20da29e4810dea298
commit: 0925e9db4dc86daf666d9a3d53c7db14ac6d5d00 ionic: use mutex to protect 
queue operations
date:   9 days ago
:: branch date: 21 hours ago
:: commit date: 9 days ago
config: powerpc-randconfig-c004-20200728 (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0

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


coccinelle warnings: (new ones prefixed by >>)

>> drivers/net/ethernet/pensando/ionic/ionic_lif.c:2004:3-9: preceding lock on 
>> line 1998

# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0925e9db4dc86daf666d9a3d53c7db14ac6d5d00
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git remote update linus
git checkout 0925e9db4dc86daf666d9a3d53c7db14ac6d5d00
vim +2004 drivers/net/ethernet/pensando/ionic/ionic_lif.c

beead698b1736df Shannon Nelson 2019-09-03  1992
086c18f2452d002 Shannon Nelson 2020-07-07  1993  int ionic_reset_queues(struct 
ionic_lif *lif, ionic_reset_cb cb, void *arg)
beead698b1736df Shannon Nelson 2019-09-03  1994  {
beead698b1736df Shannon Nelson 2019-09-03  1995 bool running;
beead698b1736df Shannon Nelson 2019-09-03  1996 int err = 0;
beead698b1736df Shannon Nelson 2019-09-03  1997
0925e9db4dc86da Shannon Nelson 2020-07-20 @1998 
mutex_lock(>queue_lock);
beead698b1736df Shannon Nelson 2019-09-03  1999 running = 
netif_running(lif->netdev);
b59eabd23ee53e8 Shannon Nelson 2020-06-18  2000 if (running) {
b59eabd23ee53e8 Shannon Nelson 2020-06-18  2001 
netif_device_detach(lif->netdev);
beead698b1736df Shannon Nelson 2019-09-03  2002 err = 
ionic_stop(lif->netdev);
086c18f2452d002 Shannon Nelson 2020-07-07  2003 if (err)
0925e9db4dc86da Shannon Nelson 2020-07-20 @2004 return 
err;
b59eabd23ee53e8 Shannon Nelson 2020-06-18  2005 }
086c18f2452d002 Shannon Nelson 2020-07-07  2006
086c18f2452d002 Shannon Nelson 2020-07-07  2007 if (cb)
086c18f2452d002 Shannon Nelson 2020-07-07  2008 cb(lif, arg);
086c18f2452d002 Shannon Nelson 2020-07-07  2009
086c18f2452d002 Shannon Nelson 2020-07-07  2010 if (running) {
086c18f2452d002 Shannon Nelson 2020-07-07  2011 err = 
ionic_open(lif->netdev);
b59eabd23ee53e8 Shannon Nelson 2020-06-18  2012 
netif_device_attach(lif->netdev);
b59eabd23ee53e8 Shannon Nelson 2020-06-18  2013 }
0925e9db4dc86da Shannon Nelson 2020-07-20  2014 
mutex_unlock(>queue_lock);
beead698b1736df Shannon Nelson 2019-09-03  2015
beead698b1736df Shannon Nelson 2019-09-03  2016 return err;
beead698b1736df Shannon Nelson 2019-09-03  2017  }
beead698b1736df Shannon Nelson 2019-09-03  2018

---
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 v3 12/19] firmware_loader: Use security_post_load_data()

2020-07-29 Thread Mimi Zohar
On Tue, 2020-07-28 at 12:43 -0700, Kees Cook wrote:
> On Mon, Jul 27, 2020 at 06:57:45AM -0400, Mimi Zohar wrote:
> > On Fri, 2020-07-24 at 14:36 -0700, Kees Cook wrote:
> > > Now that security_post_load_data() is wired up, use it instead
> > > of the NULL file argument style of security_post_read_file(),
> > > and update the security_kernel_load_data() call to indicate that a
> > > security_kernel_post_load_data() call is expected.
> > > 
> > > Wire up the IMA check to match earlier logic. Perhaps a generalized
> > > change to ima_post_load_data() might look something like this:
> > > 
> > > return process_buffer_measurement(buf, size,
> > >   kernel_load_data_id_str(load_id),
> > >   read_idmap[load_id] ?: FILE_CHECK,
> > >   0, NULL);
> > > 
> > > Signed-off-by: Kees Cook 
> > 
> > process_measurement() measures, verifies a file signature -  both
> > signatures stored as an xattr and as an appended buffer signature -
> > and augments audit records with the file hash. (Support for measuring,
> > augmenting audit records, and/or verifying fs-verity signatures has
> > yet to be added.)
> > 
> > As explained in my response to 11/19, the file descriptor provides the
> > file pathname associated with the buffer data.  In addition, IMA
> > policy rules may be defined in terms of other file descriptor info -
> > uid, euid, uuid, etc.
> > 
> > Recently support was added for measuring the kexec boot command line,
> > certificates being loaded onto a keyring, and blacklisted file hashes
> > (limited to appended signatures).  None of these buffers are signed.
> >  process_buffer_measurement() was added for this reason and as a
> > result is limited to just measuring the buffer data.
> > 
> > Whether process_measurement() or process_buffer_measurement() should
> > be modified, needs to be determined.  In either case to support the
> > init_module syscall, would at minimum require the associated file
> > pathname.
> 
> Right -- I don't intend to make changes to the init_module() syscall
> since it's deprecated, so this hook is more of a "fuller LSM coverage
> for old syscalls" addition.
> 
> IMA can happily continue to ignore it, which is what I have here, but I
> thought I'd at least show what it *might* look like. Perhaps BPF LSM is
> a better example.
> 
> Does anything need to change for this patch?

I wasn't aware that init_syscall was deprecated.  From your original comments,
it sounded like you wanted a new LSM for verifying kernel module signatures, as
they're currently supported via init_module().

I was mistaken.  Without a file descriptor, security_post_load_data() will
measure the firmware, as Scott confirmed, but won't be able to verify the
signature, whether he signed it using evmctl or not.

Mimi




[tip: locking/core] kcsan: Improve IRQ state trace reporting

2020-07-29 Thread tip-bot2 for Marco Elver
The following commit has been merged into the locking/core branch of tip:

Commit-ID: 47490fdd411675707624fdfbf7bcfcd5f6a5e706
Gitweb:
https://git.kernel.org/tip/47490fdd411675707624fdfbf7bcfcd5f6a5e706
Author:Marco Elver 
AuthorDate:Wed, 29 Jul 2020 13:09:16 +02:00
Committer: Ingo Molnar 
CommitterDate: Wed, 29 Jul 2020 16:30:41 +02:00

kcsan: Improve IRQ state trace reporting

To improve the general usefulness of the IRQ state trace events with
KCSAN enabled, save and restore the trace information when entering and
exiting the KCSAN runtime as well as when generating a KCSAN report.

Without this, reporting the IRQ trace events (whether via a KCSAN report
or outside of KCSAN via a lockdep report) is rather useless due to
continuously being touched by KCSAN. This is because if KCSAN is
enabled, every instrumented memory access causes changes to IRQ trace
events (either by KCSAN disabling/enabling interrupts or taking
report_lock when generating a report).

Before "lockdep: Prepare for NMI IRQ state tracking", KCSAN avoided
touching the IRQ trace events via raw_local_irq_save/restore() and
lockdep_off/on().

Fixes: 248591f5d257 ("kcsan: Make KCSAN compatible with new IRQ state tracking")
Signed-off-by: Marco Elver 
Signed-off-by: Ingo Molnar 
Link: https://lore.kernel.org/r/20200729110916.3920464-2-el...@google.com
---
 include/linux/sched.h |  4 
 kernel/kcsan/core.c   | 23 +++
 kernel/kcsan/kcsan.h  |  7 +++
 kernel/kcsan/report.c |  3 +++
 4 files changed, 37 insertions(+)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 26adabe..2ede13a 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1184,8 +1184,12 @@ struct task_struct {
 #ifdef CONFIG_KASAN
unsigned intkasan_depth;
 #endif
+
 #ifdef CONFIG_KCSAN
struct kcsan_ctxkcsan_ctx;
+#ifdef CONFIG_TRACE_IRQFLAGS
+   struct irqtrace_events  kcsan_save_irqtrace;
+#endif
 #endif
 
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
diff --git a/kernel/kcsan/core.c b/kernel/kcsan/core.c
index 732623c..0fe0681 100644
--- a/kernel/kcsan/core.c
+++ b/kernel/kcsan/core.c
@@ -291,6 +291,20 @@ static inline unsigned int get_delay(void)
0);
 }
 
+void kcsan_save_irqtrace(struct task_struct *task)
+{
+#ifdef CONFIG_TRACE_IRQFLAGS
+   task->kcsan_save_irqtrace = task->irqtrace;
+#endif
+}
+
+void kcsan_restore_irqtrace(struct task_struct *task)
+{
+#ifdef CONFIG_TRACE_IRQFLAGS
+   task->irqtrace = task->kcsan_save_irqtrace;
+#endif
+}
+
 /*
  * Pull everything together: check_access() below contains the performance
  * critical operations; the fast-path (including check_access) functions should
@@ -336,9 +350,11 @@ static noinline void kcsan_found_watchpoint(const volatile 
void *ptr,
flags = user_access_save();
 
if (consumed) {
+   kcsan_save_irqtrace(current);
kcsan_report(ptr, size, type, KCSAN_VALUE_CHANGE_MAYBE,
 KCSAN_REPORT_CONSUMED_WATCHPOINT,
 watchpoint - watchpoints);
+   kcsan_restore_irqtrace(current);
} else {
/*
 * The other thread may not print any diagnostics, as it has
@@ -396,6 +412,12 @@ kcsan_setup_watchpoint(const volatile void *ptr, size_t 
size, int type)
goto out;
}
 
+   /*
+* Save and restore the IRQ state trace touched by KCSAN, since KCSAN's
+* runtime is entered for every memory access, and potentially useful
+* information is lost if dirtied by KCSAN.
+*/
+   kcsan_save_irqtrace(current);
if (!kcsan_interrupt_watcher)
local_irq_save(irq_flags);
 
@@ -539,6 +561,7 @@ kcsan_setup_watchpoint(const volatile void *ptr, size_t 
size, int type)
 out_unlock:
if (!kcsan_interrupt_watcher)
local_irq_restore(irq_flags);
+   kcsan_restore_irqtrace(current);
 out:
user_access_restore(ua_flags);
 }
diff --git a/kernel/kcsan/kcsan.h b/kernel/kcsan/kcsan.h
index 763d6d0..2948001 100644
--- a/kernel/kcsan/kcsan.h
+++ b/kernel/kcsan/kcsan.h
@@ -9,6 +9,7 @@
 #define _KERNEL_KCSAN_KCSAN_H
 
 #include 
+#include 
 
 /* The number of adjacent watchpoints to check. */
 #define KCSAN_CHECK_ADJACENT 1
@@ -23,6 +24,12 @@ extern unsigned int kcsan_udelay_interrupt;
 extern bool kcsan_enabled;
 
 /*
+ * Save/restore IRQ flags state trace dirtied by KCSAN.
+ */
+void kcsan_save_irqtrace(struct task_struct *task);
+void kcsan_restore_irqtrace(struct task_struct *task);
+
+/*
  * Initialize debugfs file.
  */
 void kcsan_debugfs_init(void);
diff --git a/kernel/kcsan/report.c b/kernel/kcsan/report.c
index 6b2fb1a..9d07e17 100644
--- a/kernel/kcsan/report.c
+++ b/kernel/kcsan/report.c
@@ -308,6 +308,9 @@ static void print_verbose_info(struct task_struct *task)
if (!task)
return;
 
+   /* Restore 

Re: Should perf version match kernel version?

2020-07-29 Thread Arnaldo Carvalho de Melo



On July 29, 2020 1:02:20 PM GMT-03:00, pet...@infradead.org wrote:
>On Wed, Jul 29, 2020 at 06:56:47PM +0300, Vitaly Chikunov wrote:
>> Hi,
>> 
>> It seems that most distros try to have perf version to match with
>> running kernel version. Is is requirement? Would it be better to have
>> single perf from kernel mainline to work with any (older) kernel
>> version?
>> 
>> We have different kernel versions in ALT Linux (stable for 4.19, 5.4,
>> and 5.7) and I want to understand if we should have three perfs or
>> single package will be enough.
>
>We strive to have it all compatible, older perf should work on newer
>kernel and newer perf should work on older kernel.
>
>How well it's all tested is another.
>
>Personally I often use a very old perf.

Yeah, never was a requirement, if you find some problem using a new perf on an 
old kernel or the other way around, please report.

- Arnaldo

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


[tip: locking/core] lockdep: Refactor IRQ trace events fields into struct

2020-07-29 Thread tip-bot2 for Marco Elver
The following commit has been merged into the locking/core branch of tip:

Commit-ID: 9cd8b723f823d007bd70a3252e681fde07143f6d
Gitweb:
https://git.kernel.org/tip/9cd8b723f823d007bd70a3252e681fde07143f6d
Author:Marco Elver 
AuthorDate:Wed, 29 Jul 2020 13:09:15 +02:00
Committer: Ingo Molnar 
CommitterDate: Wed, 29 Jul 2020 16:30:40 +02:00

lockdep: Refactor IRQ trace events fields into struct

Refactor the IRQ trace events fields, used for printing information
about the IRQ trace events, into a separate struct 'irqtrace_events'.

This improves readability by separating the information only used in
reporting, as well as enables (simplified) storing/restoring of
irqtrace_events snapshots.

No functional change intended.

Signed-off-by: Marco Elver 
Signed-off-by: Ingo Molnar 
Link: https://lore.kernel.org/r/20200729110916.3920464-1-el...@google.com
---
 include/linux/irqflags.h | 13 +-
 include/linux/sched.h| 11 +--
 kernel/fork.c| 16 +++
 kernel/locking/lockdep.c | 58 ---
 4 files changed, 50 insertions(+), 48 deletions(-)

diff --git a/include/linux/irqflags.h b/include/linux/irqflags.h
index 5811ee8..bd5c557 100644
--- a/include/linux/irqflags.h
+++ b/include/linux/irqflags.h
@@ -33,6 +33,19 @@
 
 #ifdef CONFIG_TRACE_IRQFLAGS
 
+/* Per-task IRQ trace events information. */
+struct irqtrace_events {
+   unsigned intirq_events;
+   unsigned long   hardirq_enable_ip;
+   unsigned long   hardirq_disable_ip;
+   unsigned inthardirq_enable_event;
+   unsigned inthardirq_disable_event;
+   unsigned long   softirq_disable_ip;
+   unsigned long   softirq_enable_ip;
+   unsigned intsoftirq_disable_event;
+   unsigned intsoftirq_enable_event;
+};
+
 DECLARE_PER_CPU(int, hardirqs_enabled);
 DECLARE_PER_CPU(int, hardirq_context);
 
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 9a9d826..26adabe 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -980,17 +981,9 @@ struct task_struct {
 #endif
 
 #ifdef CONFIG_TRACE_IRQFLAGS
-   unsigned intirq_events;
+   struct irqtrace_events  irqtrace;
unsigned inthardirq_threaded;
-   unsigned long   hardirq_enable_ip;
-   unsigned long   hardirq_disable_ip;
-   unsigned inthardirq_enable_event;
-   unsigned inthardirq_disable_event;
u64 hardirq_chain_key;
-   unsigned long   softirq_disable_ip;
-   unsigned long   softirq_enable_ip;
-   unsigned intsoftirq_disable_event;
-   unsigned intsoftirq_enable_event;
int softirqs_enabled;
int softirq_context;
int irq_config;
diff --git a/kernel/fork.c b/kernel/fork.c
index fc72f09..f831b82 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -2035,17 +2035,11 @@ static __latent_entropy struct task_struct 
*copy_process(
seqcount_spinlock_init(>mems_allowed_seq, >alloc_lock);
 #endif
 #ifdef CONFIG_TRACE_IRQFLAGS
-   p->irq_events = 0;
-   p->hardirq_enable_ip = 0;
-   p->hardirq_enable_event = 0;
-   p->hardirq_disable_ip = _THIS_IP_;
-   p->hardirq_disable_event = 0;
-   p->softirqs_enabled = 1;
-   p->softirq_enable_ip = _THIS_IP_;
-   p->softirq_enable_event = 0;
-   p->softirq_disable_ip = 0;
-   p->softirq_disable_event = 0;
-   p->softirq_context = 0;
+   memset(>irqtrace, 0, sizeof(p->irqtrace));
+   p->irqtrace.hardirq_disable_ip  = _THIS_IP_;
+   p->irqtrace.softirq_enable_ip   = _THIS_IP_;
+   p->softirqs_enabled = 1;
+   p->softirq_context  = 0;
 #endif
 
p->pagefault_disabled = 0;
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index c9ea05e..7b58003 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -3484,19 +3484,21 @@ check_usage_backwards(struct task_struct *curr, struct 
held_lock *this,
 
 void print_irqtrace_events(struct task_struct *curr)
 {
-   printk("irq event stamp: %u\n", curr->irq_events);
+   const struct irqtrace_events *trace = >irqtrace;
+
+   printk("irq event stamp: %u\n", trace->irq_events);
printk("hardirqs last  enabled at (%u): [<%px>] %pS\n",
-   curr->hardirq_enable_event, (void *)curr->hardirq_enable_ip,
-   (void *)curr->hardirq_enable_ip);
+   trace->hardirq_enable_event, (void *)trace->hardirq_enable_ip,
+   (void *)trace->hardirq_enable_ip);
printk("hardirqs last disabled at (%u): [<%px>] %pS\n",
-   

Re: [PATCH 2/7] modules: mark find_symbol static

2020-07-29 Thread Greg Kroah-Hartman
On Wed, Jul 29, 2020 at 06:13:18PM +0200, Jessica Yu wrote:
> +++ Christoph Hellwig [29/07/20 08:27 +0200]:
> > find_symbol is only used in module.c.
> > 
> > Signed-off-by: Christoph Hellwig 
> 
> CCing the livepatching ML, as this may or may not impact its users.
> 
> AFAIK, the out-of-tree kpatch module had used find_symbol() in the
> past, I am not sure what its current status is. I suspect all of its
> functionality has been migrated to upstream livepatch already.

We still have symbol_get(), which is what I thought they were using.

If only we could get rid of that export one day...

thanks,

greg k-h


Re: [PATCH] arm64: dts: sun50i-pinephone: add led flash

2020-07-29 Thread Luca Weiss
Hi Maxime,

On Mittwoch, 29. Juli 2020 14:34:44 CEST Maxime Ripard wrote:
> Hi!
> 
> On Sat, Jul 25, 2020 at 01:08:12PM +0200, Luca Weiss wrote:
> > All revisions of the PinePhone have an SGM3140 LED flash. The gpios were
> > swapped on v1.0 of the board but this was fixed in later revisions.
> > 
> > Signed-off-by: Luca Weiss 
> > ---
> > 
> >  .../boot/dts/allwinner/sun50i-a64-pinephone-1.0.dts   |  5 +
> >  .../boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts   |  5 +
> >  .../boot/dts/allwinner/sun50i-a64-pinephone-1.2.dts   |  5 +
> >  .../boot/dts/allwinner/sun50i-a64-pinephone.dtsi  | 11 +++
> >  4 files changed, 26 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.0.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.0.dts index
> > 0c42272106afa..b579b03d4e026 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.0.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.0.dts
> > @@ -9,3 +9,8 @@ / {
> > 
> > model = "Pine64 PinePhone Developer Batch (1.0)";
> > compatible = "pine64,pinephone-1.0", "allwinner,sun50i-a64";
> >  
> >  };
> > 
> > +
> > + {
> > +   flash-gpios = < 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
> > +   enable-gpios = < 2 3 GPIO_ACTIVE_HIGH>; /* PC3 */
> > +};
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts index
> > 3e99a87e9ce52..8552587aac248 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts
> > @@ -28,3 +28,8 @@  {
> > 
> > num-interpolated-steps = <50>;
> > default-brightness-level = <400>;
> >  
> >  };
> > 
> > +
> > + {
> > +   flash-gpios = < 2 3 GPIO_ACTIVE_HIGH>; /* PC3 */
> > +   enable-gpios = < 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
> > +};
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.2.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.2.dts index
> > a9f5b670c9b82..ec77715ba4a2a 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.2.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.2.dts
> > @@ -38,3 +38,8 @@  {
> > 
> > interrupt-parent = <>;
> > interrupts = <1 1 IRQ_TYPE_EDGE_RISING>; /* PB1 */
> >  
> >  };
> > 
> > +
> > + {
> > +   flash-gpios = < 2 3 GPIO_ACTIVE_HIGH>; /* PC3 */
> > +   enable-gpios = < 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
> > +};
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi index
> > 25150aba749dc..e0bc1bcc1c1f3 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> > @@ -60,6 +60,17 @@ vibrator {
> > 
> > enable-gpios = < 3 2 GPIO_ACTIVE_HIGH>; /* PD2 */
> > vcc-supply = <_dcdc1>;
> > 
> > };
> > 
> > +
> > +   sgm3140: led-controller {
> 
> The nodes should be ordered by node-name here

Will update the patch, forgot about that.

> > +   compatible = "sgmicro,sgm3140";
> > +   vin-supply = <_dcdc1>;
> > +
> > +   sgm3140_flash: led {
> 
> What do you need the label for?

The label will be used for connecting the flash to the rear camera (which 
hasn't been upstreamed yet) using:

flash-leds = <_flash>;

Hope that clears it up.

> 
> Thanks!
> Maxime

Regards
Luca




Re: [PATCH 2/3] ARM: l2c: update prefetch bits in L2X0_AUX_CTRL using DT value

2020-07-29 Thread Guillaume Tucker
On 29/07/2020 15:18, Russell King - ARM Linux admin wrote:
> On Wed, Jul 29, 2020 at 02:47:32PM +0100, Guillaume Tucker wrote:
>> The L310_PREFETCH_CTRL register bits 28 and 29 to enable data and
>> instruction prefetch respectively can also be accessed via the
>> L2X0_AUX_CTRL register.  They appear to be actually wired together in
>> hardware between the registers.  Changing them in the prefetch
>> register only will get undone when restoring the aux control register
>> later on.  For this reason, set these bits in both registers during
>> initialisation according to the DT attributes.
> 
> How will that happen?
> 
> We write the auxiliary control register before the prefetch control
> register, so the prefetch control register will take precedence.  See
> l2c310_configure() - l2c_configure() writes the auxiliary control
> register, and the function writes the prefetch control register later.

What I'm seeing is that outer_cache.configure() gets called, at
least on exynos4412-odroidx2.  See l2c_enable():

if (outer_cache.configure)
outer_cache.configure(_saved_regs);
else
l2x0_data->configure(base);

Then instead of l2c310_configure(), exynos_l2_configure() gets
called and writes prefetch_ctrl right before aux_ctrl.  Should
exynos_l2_configure() be changed to swap the register writes?


> I think the real issue is that Exynos has been modifying the prefetch
> settings via its machine .aux_mask / .aux_val configuration, and the
> opposite is actually true: the prefetch control register values will
> overwrite the attempt to modify the auxiliary control values set through
> the machine .aux_mask/.aux_val.

Yes with l2c310_configure() but not with exynos_l2_configure().

To be clear, this is what I've found to be happening, if you
switch to using the device tree prefetch attributes and clear
the bits in the default l2c_aux_val (see PATCH 3/3):

1. l2x0_of_init() first gets called with the default aux_val

2. l2c310_of_parse() sets the bits in l2x0_saved_regs.prefetch_ctrl
   but not in aux_val (unless you apply this patch 2/3)

3. l2c_enable() calls exynos_l2_configure() which writes
   prefetch_ctrl and then aux_ctrl - thus setting the prefetch bits
   and then clearing them just after

4. l2c310_enable() reads back aux_ctrl and prefetch, both of which
   now have the bits cleared (the pr_info() message about prefetch
   enabled gets skipped)


That's why I thought it would be safer to set the prefetch bits
in both registers so it should work regardless if the
initialisation sequence.  Also, if we want these bits to be
changed, we should clear them in the aux_mask value to not get
another error message about register corruption - so I'm doing
that too.

Thanks,
Guillaume


>> Fixes: ec3bd0e68a67 ("ARM: 8391/1: l2c: add options to overwrite prefetching 
>> behavior")
>> Signed-off-by: Guillaume Tucker 
>> ---
>>  arch/arm/mm/cache-l2x0.c | 16 
>>  1 file changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
>> index 12c26eb88afb..43d91bfd2360 100644
>> --- a/arch/arm/mm/cache-l2x0.c
>> +++ b/arch/arm/mm/cache-l2x0.c
>> @@ -1249,20 +1249,28 @@ static void __init l2c310_of_parse(const struct 
>> device_node *np,
>>  
>>  ret = of_property_read_u32(np, "prefetch-data", );
>>  if (ret == 0) {
>> -if (val)
>> +if (val) {
>>  prefetch |= L310_PREFETCH_CTRL_DATA_PREFETCH;
>> -else
>> +*aux_val |= L310_PREFETCH_CTRL_DATA_PREFETCH;
>> +} else {
>>  prefetch &= ~L310_PREFETCH_CTRL_DATA_PREFETCH;
>> +*aux_val &= ~L310_PREFETCH_CTRL_DATA_PREFETCH;
>> +}
>> +*aux_mask &= ~L310_PREFETCH_CTRL_DATA_PREFETCH;
>>  } else if (ret != -EINVAL) {
>>  pr_err("L2C-310 OF prefetch-data property value is missing\n");
>>  }
>>  
>>  ret = of_property_read_u32(np, "prefetch-instr", );
>>  if (ret == 0) {
>> -if (val)
>> +if (val) {
>>  prefetch |= L310_PREFETCH_CTRL_INSTR_PREFETCH;
>> -else
>> +*aux_val |= L310_PREFETCH_CTRL_INSTR_PREFETCH;
>> +} else {
>>  prefetch &= ~L310_PREFETCH_CTRL_INSTR_PREFETCH;
>> +*aux_val &= ~L310_PREFETCH_CTRL_INSTR_PREFETCH;
>> +}
>> +*aux_mask &= ~L310_PREFETCH_CTRL_INSTR_PREFETCH;
>>  } else if (ret != -EINVAL) {
>>  pr_err("L2C-310 OF prefetch-instr property value is missing\n");
>>  }
>> -- 
>> 2.20.1
>>
>>
> 



RE: [PATCH] hv_utils: Add validation for untrusted Hyper-V values

2020-07-29 Thread Stephen Hemminger
Ok at least use the ratelimit form of kernel logging.

Netdev_err_ratelimited...

-Original Message-
From: Andres Beltran  
Sent: Wednesday, July 29, 2020 9:10 AM
To: Stephen Hemminger 
Cc: KY Srinivasan ; Haiyang Zhang ; 
Wei Liu ; linux-hyp...@vger.kernel.org; 
linux-kernel@vger.kernel.org; Michael Kelley ; Andrea 
Parri ; Saruhan Karademir 
Subject: Re: [PATCH] hv_utils: Add validation for untrusted Hyper-V values

On Tue, Jul 28, 2020 at 5:04 PM Stephen Hemminger
 wrote:
>
> You may want to use one of the macros that prints this once only.
> This is a "should never happen" type error, so if something goes wrong it 
> might happens so much that journal/syslog would get overloaded.

Certainly, printing error messages once would be ideal if we were only
dealing with Linux kernel bugs. But under the assumption that Hyper-V
can send bogus values at any time, I think it would be better to print
error messages every time so that we are aware of malicious/erroneous
data sent by the host.


Re: [RESEND PATCH v1 2/2] thermal: qcom-spmi-temp-alarm: Don't suppress negative temp

2020-07-29 Thread Guru Das Srinagesh
On Tue, Jul 28, 2020 at 06:09:12PM -0700, Stephen Boyd wrote:
> Quoting Guru Das Srinagesh (2020-07-24 10:46:11)
> > From: Veera Vegivada 
> > 
> > Currently driver is suppressing the negative temperature
> > readings from the vadc. Consumers of the thermal zones need
> > to read the negative temperature too. Don't suppress the
> > readings.
> > 
> > Signed-off-by: Veera Vegivada 
> > Signed-off-by: Guru Das Srinagesh 
> > ---
> 
> Probably needs a fixes tag. And why not make it first in the series?

Will add one and move this to first in the series.

> 
> >  drivers/thermal/qcom/qcom-spmi-temp-alarm.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >


Re: [f2fs-dev] [PATCH] f2fs: fix deadlock between quota writes and checkpoint

2020-07-29 Thread Jaegeuk Kim
On 07/29, Chao Yu wrote:
> On 2020-7-29 15:02, Jaegeuk Kim wrote:
> > f2fs_write_data_pages(quota_mapping)
> >  __f2fs_write_data_pages f2fs_write_checkpoint
> >   * blk_start_plug();
> >   * add bio in write_io[DATA]
> >   - block_operations
> >   - skip syncing quota by
> > 
> > >DEFAULT_RETRY_QUOTA_FLUSH_COUNT
> >   - down_write(>node_write);
> >   - f2fs_write_single_data_page
> 
> After commit 79963d967b49 ("f2fs: shrink node_write lock coverage"),
> node_write lock was moved to f2fs_write_single_data_page() and
> f2fs_write_compressed_pages().
> 
> So it needs to update the callstack.
> 
> - down_write(node_write)

Yeah, applied. :)

> 
> Otherwise it looks good to me.
> 
> Reviewed-by: Chao Yu 
> 
> Thanks,
> 
> > - f2fs_do_write_data_page
> >   - f2fs_outplace_write_data
> > - do_write_page
> >- f2fs_allocate_data_block
> > - down_write(node_write)
> >   - 
> > f2fs_wait_on_all_pages(F2FS_WB_CP_DATA);
> > 
> > Signed-off-by: Daeho Jeong 
> > Signed-off-by: Jaegeuk Kim 
> > ---
> >  fs/f2fs/checkpoint.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> > index 8c782d3f324f0..99c8061da55b9 100644
> > --- a/fs/f2fs/checkpoint.c
> > +++ b/fs/f2fs/checkpoint.c
> > @@ -1269,6 +1269,8 @@ void f2fs_wait_on_all_pages(struct f2fs_sb_info *sbi, 
> > int type)
> > if (type == F2FS_DIRTY_META)
> > f2fs_sync_meta_pages(sbi, META, LONG_MAX,
> > FS_CP_META_IO);
> > +   else if (type == F2FS_WB_CP_DATA)
> > +   f2fs_submit_merged_write(sbi, DATA);
> > io_schedule_timeout(DEFAULT_IO_TIMEOUT);
> > }
> > finish_wait(>cp_wait, );
> > 


Re: [PATCH 2/5] seqlock: Fold seqcount_LOCKNAME_t definition

2020-07-29 Thread peterz
On Wed, Jul 29, 2020 at 05:33:41PM +0200, pet...@infradead.org wrote:
> On Wed, Jul 29, 2020 at 03:55:07PM +0100, Matthew Wilcox wrote:
> > On Wed, Jul 29, 2020 at 03:52:51PM +0200, Peter Zijlstra wrote:
> > > Manual repetition is boring and error prone.
> > 
> > Yes, but generated functions are hard to grep for, and I'm pretty sure
> > that kernel-doc doesn't know how to expand macros into comments that it
> > can then extract documentation from.
> > 
> > I've been thinking about how to cure this (mostly in the context
> > of page-flags.h).  I don't particularly like the C preprocessor, but
> > m4 is worse and defining our own preprocessing language seems like a
> > terrible idea.
> > 
> > So I was thinking about moving the current contents of page-flags.h
> > to include/src/page-flags.h, making linux/page-flags.h depend on
> > src/page-flags.h and run '$(CPP) -C' to generate it.  I've been a little
> > busy recently and haven't had time to do more than muse about this, but
> > I think it might make sense for some of our more heavily macro-templated
> > header files.
> 
> Use ctags and add to scripts/tags.sh.

I'll make the below into a proper patch.

---

diff --git a/scripts/tags.sh b/scripts/tags.sh
index 4e18ae5282a6..63b21881a873 100755
--- a/scripts/tags.sh
+++ b/scripts/tags.sh
@@ -211,6 +211,8 @@ regex_c=(
'/\

Re: [PATCH] scsi: sd: add runtime pm to open / release

2020-07-29 Thread Alan Stern
On Wed, Jul 29, 2020 at 08:49:34AM -0700, James Bottomley wrote:
> On Wed, 2020-07-29 at 11:40 -0400, Alan Stern wrote:
> > On Wed, Jul 29, 2020 at 07:53:52AM -0700, James Bottomley wrote:
> > > On Wed, 2020-07-29 at 07:46 -0700, James Bottomley wrote:
> [...]
> > > > That sense code means "NOT READY TO READY CHANGE, MEDIUM MAY HAVE
> > > > CHANGED" so it sounds like it something we should be
> > > > ignoring.  Usually this signals a problem, like you changed the
> > > > medium manually (ejected the CD).  But in this case you can tell
> > > > us to expect this by setting
> > > > 
> > > > sdev->expecting_cc_ua
> > > > 
> > > > And we'll retry.  I think you need to set this on all resumed
> > > > devices.
> > > 
> > > Actually, it's not quite that easy, we filter out this ASC/ASCQ
> > > combination from the check because we should never ignore medium
> > > might have changed events on running devices.  We could ignore it
> > > if we had a flag to say the power has been yanked (perhaps an
> > > additional sdev flag you set on resume) but we would still miss the
> > > case where you really had powered off the drive and then changed
> > > the media ... if you can regard this as the user's problem, then we
> > > might have a solution.
> > 
> > Indeed, I was going to make the same point.
> > 
> > The only reasonable conclusion is that suspending these SD card
> > readers isn't safe unless they don't contain a card -- or maybe just
> > if the device file isn't open or mounted.
> 
> For standard removable media, I could see issuing an eject before
> suspend to emphasize the point.

That's not a workable approach in general.  For example, you wouldn't 
want to eject a CD just because it hadn't been used for a couple of 
minutes and the drive was therefore about to be suspended.

>  However, sd cards don't work like that
> ... they're not ejectable except manually and mostly used as the HDD of
> embedded, so the 99% use case is that the user will suspend and resume
> the device with the same sdd insert.  It does sound like a use case we
> should support.

Agreed.

> > Although support for this sort of thing could be added to the
> > kernel, for now it's best to rely on userspace doing the right
> > thing.  The kernel doesn't even know which devices suffer from this
> > problem.
> 
> Can we solve from userspace the case where the user hasn't changed the
> media and the resume fails because we don't know?

The difficulty is recognizing situations where the media really was 
changed while the device was suspended.  Most devices, AFAIK, don't have 
any problem with this, but card readers often do.

I suppose the kernel could just rely on users not to change media in 
drives while they are mounted.  Then any problems that arise would be 
the users' fault.  Yes, this is nothing more than passing the buck, but 
it's hard to come up with any better approach.  Doesn't Windows do 
something like this?

Alan Stern


Re: [RESEND PATCH v1 1/2] thermal: qcom-spmi-temp-alarm: add support for GEN2 rev 1 PMIC peripherals

2020-07-29 Thread Guru Das Srinagesh
On Tue, Jul 28, 2020 at 06:08:28PM -0700, Stephen Boyd wrote:
> Quoting Guru Das Srinagesh (2020-07-24 10:46:10)
> > diff --git a/drivers/thermal/qcom/qcom-spmi-temp-alarm.c 
> > b/drivers/thermal/qcom/qcom-spmi-temp-alarm.c
> > index bf7bae4..05a9601 100644
> > --- a/drivers/thermal/qcom/qcom-spmi-temp-alarm.c
> > +++ b/drivers/thermal/qcom/qcom-spmi-temp-alarm.c
> > @@ -38,26 +39,30 @@
> >  
> >  #define ALARM_CTRL_FORCE_ENABLEBIT(7)
> >  
> > -/*
> > - * Trip point values based on threshold control
> > - * 0 = {105 C, 125 C, 145 C}
> > - * 1 = {110 C, 130 C, 150 C}
> > - * 2 = {115 C, 135 C, 155 C}
> > - * 3 = {120 C, 140 C, 160 C}
> > -*/
> > -#define TEMP_STAGE_STEP2   /* Stage step: 
> > 20.000 C */
> > -#define TEMP_STAGE_HYSTERESIS  2000
> > +#define THRESH_COUNT   4
> > +#define STAGE_COUNT3
> > +
> > +/* Over-temperature trip point values in mC */
> > +static const long temp_map_gen1[THRESH_COUNT][STAGE_COUNT] = {
> > +   {105000, 125000, 145000},
> 
> Please add a space after { and before }

Done.

> 
> > +   {11, 13, 15},
> > +   {115000, 135000, 155000},
> > +   {12, 14, 16},
> > +};
> > +
> > +static const long temp_map_gen2_v1[THRESH_COUNT][STAGE_COUNT] = {
> > +   { 9, 11, 14},
> 
> Almost.

Done.

> 
> > +   { 95000, 115000, 145000},
> > +   {10, 12, 15},
> > +   {105000, 125000, 155000},
> > +};
> >  
> > -#define TEMP_THRESH_MIN105000  /* Threshold Min: 
> > 105 C */
> > -#define TEMP_THRESH_STEP   5000/* Threshold step: 5 C */
> > +#define TEMP_THRESH_STEP   5000 /* Threshold step: 5 C */
> >  
> >  #define THRESH_MIN 0
> >  #define THRESH_MAX 3
> >  
> > -/* Stage 2 Threshold Min: 125 C */
> > -#define STAGE2_THRESHOLD_MIN   125000
> > -/* Stage 2 Threshold Max: 140 C */
> > -#define STAGE2_THRESHOLD_MAX   14
> > +#define TEMP_STAGE_HYSTERESIS  2000
> >  
> >  /* Temperature in Milli Celsius reported during stage 0 if no ADC is 
> > present */
> >  #define DEFAULT_TEMP   37000
> > @@ -77,6 +82,7 @@ struct qpnp_tm_chip {
> > boolinitialized;
> >  
> > struct iio_channel  *adc;
> > +   const long  
> > (*temp_map)[THRESH_COUNT][STAGE_COUNT];
> 
> It can be negative Celsius?

It's not unsigned because it has to match struct qpnp_tm_chip's temp
member, which is long - hope I understood your concern correctly. The
temperatures themselves cannot be negative.

> 
> >  };
> >  
> >  /* This array maps from GEN2 alarm state to GEN1 alarm stage */
> > @@ -101,6 +107,23 @@ static int qpnp_tm_write(struct qpnp_tm_chip *chip, 
> > u16 addr, u8 data)
> >  }
> >  
> >  /**
> > + * qpnp_tm_decode_temp() - return temperature in mC corresponding to the
> > + * specified over-temperature stage
> > + * @chip:  Pointer to the qpnp_tm chip
> > + * @stage: Over-temperature stage
> > + *
> > + * Return: temperature in mC
> > + */
> > +static long qpnp_tm_decode_temp(struct qpnp_tm_chip *chip, unsigned int 
> > stage)
> > +{
> > +   if (!chip->temp_map || chip->thresh >= THRESH_COUNT || stage == 0
> > +   || stage > STAGE_COUNT)
> 
> Nitpick: The || goes on the line above.

Done.

> 
> > +   return 0;
> > +
> > +   return (*chip->temp_map)[chip->thresh][stage - 1];
> > +}
> > +
> > +/**
> >   * qpnp_tm_get_temp_stage() - return over-temperature stage
> >   * @chip:  Pointer to the qpnp_tm chip
> >   *


RE: [PATCH v3 03/11] KVM: SVM: Change intercept_dr to generic intercepts

2020-07-29 Thread Babu Moger



> -Original Message-
> From: Jim Mattson 
> Sent: Tuesday, July 28, 2020 6:59 PM
> To: Moger, Babu 
> Cc: Paolo Bonzini ; Vitaly Kuznetsov
> ; Wanpeng Li ; Sean
> Christopherson ; kvm list
> ; Joerg Roedel ; the arch/x86
> maintainers ; LKML ; Ingo
> Molnar ; Borislav Petkov ; H . Peter Anvin
> ; Thomas Gleixner 
> Subject: Re: [PATCH v3 03/11] KVM: SVM: Change intercept_dr to generic
> intercepts
> 
> On Tue, Jul 28, 2020 at 4:38 PM Babu Moger  wrote:
> >
> > Modify intercept_dr to generic intercepts in vmcb_control_area.
> > Use generic __set_intercept, __clr_intercept and __is_intercept to
> > set/clear/test the intercept_dr bits.
> >
> > Signed-off-by: Babu Moger 
> > ---
> >  arch/x86/include/asm/svm.h |   36 ++--
> >  arch/x86/kvm/svm/nested.c  |6 +-
> >  arch/x86/kvm/svm/svm.c |4 ++--
> >  arch/x86/kvm/svm/svm.h |   34 +-
> >  4 files changed, 38 insertions(+), 42 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
> > index d4739f4eae63..ffc89d8e4fcb 100644
> > --- a/arch/x86/include/asm/svm.h
> > +++ b/arch/x86/include/asm/svm.h
> > @@ -11,6 +11,7 @@
> >
> >  enum vector_offset {
> > CR_VECTOR = 0,
> > +   DR_VECTOR,
> > MAX_VECTORS,
> >  };
> >
> > @@ -34,6 +35,23 @@ enum {
> > INTERCEPT_CR6_WRITE,
> > INTERCEPT_CR7_WRITE,
> > INTERCEPT_CR8_WRITE,
> > +   /* Byte offset 004h (Vector 1) */
> > +   INTERCEPT_DR0_READ = 32,
> > +   INTERCEPT_DR1_READ,
> > +   INTERCEPT_DR2_READ,
> > +   INTERCEPT_DR3_READ,
> > +   INTERCEPT_DR4_READ,
> > +   INTERCEPT_DR5_READ,
> > +   INTERCEPT_DR6_READ,
> > +   INTERCEPT_DR7_READ,
> > +   INTERCEPT_DR0_WRITE = 48,
> > +   INTERCEPT_DR1_WRITE,
> > +   INTERCEPT_DR2_WRITE,
> > +   INTERCEPT_DR3_WRITE,
> > +   INTERCEPT_DR4_WRITE,
> > +   INTERCEPT_DR5_WRITE,
> > +   INTERCEPT_DR6_WRITE,
> > +   INTERCEPT_DR7_WRITE,
> >  };
> >
> >  enum {
> > @@ -89,7 +107,6 @@ enum {
> >
> >  struct __attribute__ ((__packed__)) vmcb_control_area {
> > u32 intercepts[MAX_VECTORS];
> > -   u32 intercept_dr;
> > u32 intercept_exceptions;
> > u64 intercept;
> > u8 reserved_1[40];
> > @@ -271,23 +288,6 @@ struct __attribute__ ((__packed__)) vmcb {
> > #define SVM_SELECTOR_READ_MASK SVM_SELECTOR_WRITE_MASK  #define
> > SVM_SELECTOR_CODE_MASK (1 << 3)
> >
> > -#define INTERCEPT_DR0_READ 0
> > -#define INTERCEPT_DR1_READ 1
> > -#define INTERCEPT_DR2_READ 2
> > -#define INTERCEPT_DR3_READ 3
> > -#define INTERCEPT_DR4_READ 4
> > -#define INTERCEPT_DR5_READ 5
> > -#define INTERCEPT_DR6_READ 6
> > -#define INTERCEPT_DR7_READ 7
> > -#define INTERCEPT_DR0_WRITE(16 + 0)
> > -#define INTERCEPT_DR1_WRITE(16 + 1)
> > -#define INTERCEPT_DR2_WRITE(16 + 2)
> > -#define INTERCEPT_DR3_WRITE(16 + 3)
> > -#define INTERCEPT_DR4_WRITE(16 + 4)
> > -#define INTERCEPT_DR5_WRITE(16 + 5)
> > -#define INTERCEPT_DR6_WRITE(16 + 6)
> > -#define INTERCEPT_DR7_WRITE(16 + 7)
> > -
> >  #define SVM_EVTINJ_VEC_MASK 0xff
> >
> >  #define SVM_EVTINJ_TYPE_SHIFT 8
> > diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
> > index 46f5c82d9b45..71ca89afb2a3 100644
> > --- a/arch/x86/kvm/svm/nested.c
> > +++ b/arch/x86/kvm/svm/nested.c
> > @@ -121,7 +121,6 @@ void recalc_intercepts(struct vcpu_svm *svm)
> > for (i = 0; i < MAX_VECTORS; i++)
> > c->intercepts[i] = h->intercepts[i];
> >
> > -   c->intercept_dr = h->intercept_dr;
> > c->intercept_exceptions = h->intercept_exceptions;
> > c->intercept = h->intercept;
> >
> > @@ -144,7 +143,6 @@ void recalc_intercepts(struct vcpu_svm *svm)
> > for (i = 0; i < MAX_VECTORS; i++)
> > c->intercepts[i] |= g->intercepts[i];
> >
> > -   c->intercept_dr |= g->intercept_dr;
> > c->intercept_exceptions |= g->intercept_exceptions;
> > c->intercept |= g->intercept;
> >  }
> > @@ -157,7 +155,6 @@ static void copy_vmcb_control_area(struct
> vmcb_control_area *dst,
> > for (i = 0; i < MAX_VECTORS; i++)
> > dst->intercepts[i] = from->intercepts[i];
> >
> > -   dst->intercept_dr = from->intercept_dr;
> > dst->intercept_exceptions = from->intercept_exceptions;
> > dst->intercept= from->intercept;
> > dst->iopm_base_pa = from->iopm_base_pa;
> > @@ -717,8 +714,7 @@ static int nested_svm_intercept(struct vcpu_svm
> *svm)
> > break;
> > }
> > case SVM_EXIT_READ_DR0 ... SVM_EXIT_WRITE_DR7: {
> > -   u32 bit = 1U << (exit_code - SVM_EXIT_READ_DR0);
> > -   if (svm->nested.ctl.intercept_dr & bit)
> > +   if (__is_intercept(>nested.ctl.intercepts,
> > + exit_code))
> 
> Can I assume that all of these __ calls will become  

Re: mmotm 2020-07-27-18-18 uploaded (mm/page_alloc.c)

2020-07-29 Thread David Hildenbrand
On 29.07.20 16:38, David Hildenbrand wrote:
> On 29.07.20 16:18, Michael S. Tsirkin wrote:
>> On Tue, Jul 28, 2020 at 03:31:43PM -0700, Andrew Morton wrote:
>>> On Wed, 29 Jul 2020 08:20:53 +1000 Stephen Rothwell  
>>> wrote:
>>>
 Hi Andrew,

 On Tue, 28 Jul 2020 14:55:53 -0700 Andrew Morton 
  wrote:
> config CONTIG_ALLOC
> def_bool (MEMORY_ISOLATION && COMPACTION) || CMA
>
> says this is an improper combination.  And `make oldconfig' fixes it up.
>
> What's happening here?

 CONFIG_VIRTIO_MEM selects CONFIG_CONTIG_ALLOC ...
>>>
>>> Argh, select strikes again.
>>>
>>> So I guess VIRTIO_MEM should also select COMPACTION?
>>
>> +Cc the maintainer.
>>
> 
> We had select CONFIG_CONTIG_ALLOC before and that seemed to be wrong. I
> was told select might be the wrong approach.
> 
> We want memory isolation and contig_alloc with virtio-mem (which depends
> on memory hot(un)plug). What would be the right way to achieve this?
> 

Okay, I think I am confused. I thought we had that already fixed. @mst
what happened to

https://lkml.kernel.org/r/d03c88ea-200d-54ab-d7f3-f3e5b7a0a...@redhat.com

That patch is almost a month old, can you pick it, I already acked it.

-- 
Thanks,

David / dhildenb



Re: [PATCH 2/7] modules: mark find_symbol static

2020-07-29 Thread Jessica Yu

+++ Christoph Hellwig [29/07/20 08:27 +0200]:

find_symbol is only used in module.c.

Signed-off-by: Christoph Hellwig 


CCing the livepatching ML, as this may or may not impact its users.

AFAIK, the out-of-tree kpatch module had used find_symbol() in the
past, I am not sure what its current status is. I suspect all of its
functionality has been migrated to upstream livepatch already.


---
include/linux/module.h | 11 ---
kernel/module.c|  3 +--
2 files changed, 1 insertion(+), 13 deletions(-)

diff --git a/include/linux/module.h b/include/linux/module.h
index f1fdbeef2153a8..90bdc362be3681 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -590,17 +590,6 @@ struct symsearch {
bool unused;
};

-/*
- * Search for an exported symbol by name.
- *
- * Must be called with module_mutex held or preemption disabled.
- */
-const struct kernel_symbol *find_symbol(const char *name,
-   struct module **owner,
-   const s32 **crc,
-   bool gplok,
-   bool warn);
-
/*
 * Walk the exported symbol table
 *
diff --git a/kernel/module.c b/kernel/module.c
index 17d64dae756c80..84da96a6d8241c 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -585,7 +585,7 @@ static bool find_exported_symbol_in_section(const struct 
symsearch *syms,

/* Find an exported symbol and return it, along with, (optional) crc and
 * (optional) module which owns it.  Needs preempt disabled or module_mutex. */
-const struct kernel_symbol *find_symbol(const char *name,
+static const struct kernel_symbol *find_symbol(const char *name,
struct module **owner,
const s32 **crc,
bool gplok,
@@ -608,7 +608,6 @@ const struct kernel_symbol *find_symbol(const char *name,
pr_debug("Failed to find symbol %s\n", name);
return NULL;
}
-EXPORT_SYMBOL_GPL(find_symbol);

/*
 * Search for module by name: must hold module_mutex (or preempt disabled
--
2.27.0



[PATCH 7/7] ARM: s3c24xx: Fix missing system reset

2020-07-29 Thread Krzysztof Kozlowski
Commit f6361c6b3880 ("ARM: S3C24XX: remove separate restart code")
removed usage of the watchdog reset platform code in favor of the
Samsung SoC watchdog driver.  However the latter was not selected thus
S3C24xx platforms lost reset abilities.

Cc: 
Fixes: f6361c6b3880 ("ARM: S3C24XX: remove separate restart code")
Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index fe95777af653..063018c387be 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -506,8 +506,10 @@ config ARCH_S3C24XX
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C_RTC if RTC_CLASS
select NEED_MACH_IO_H
+   select S3C2410_WATCHDOG
select SAMSUNG_ATAGS
select USE_OF
+   select WATCHDOG
help
  Samsung S3C2410, S3C2412, S3C2413, S3C2416, S3C2440, S3C2442, S3C2443
  and S3C2450 SoCs based systems, such as the Simtec Electronics BAST
-- 
2.17.1



[PATCH 6/7] ARM: s3c64xx: Switch to generic watchdog driver reset

2020-07-29 Thread Krzysztof Kozlowski
Similarly to commit f6361c6b3880 ("ARM: S3C24XX: remove separate restart
code"), the platform watchdog reset code can be removed in favor of
a generic watchdog driver which already handles reset.

This allows removal of a bunch of machine code and fixes also W=1
compile warnings:

arch/arm/plat-samsung/watchdog-reset.c:29:6: warning: no previous prototype 
for 'samsung_wdt_reset' [-Wmissing-prototypes]
   29 | void samsung_wdt_reset(void)
  |  ^
arch/arm/plat-samsung/watchdog-reset.c:69:13: warning: no previous 
prototype for 'samsung_wdt_reset_of_init' [-Wmissing-prototypes]
   69 | void __init samsung_wdt_reset_of_init(void)
  | ^
arch/arm/plat-samsung/watchdog-reset.c:89:13: warning: no previous 
prototype for 'samsung_wdt_reset_init' [-Wmissing-prototypes]
   89 | void __init samsung_wdt_reset_init(void __iomem *base)

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/mach-s3c64xx/Kconfig   |  3 +-
 arch/arm/mach-s3c64xx/common.c  | 15 +---
 arch/arm/mach-s3c64xx/common.h  |  2 -
 arch/arm/mach-s3c64xx/mach-anw6410.c|  1 -
 arch/arm/mach-s3c64xx/mach-crag6410.c   |  1 -
 arch/arm/mach-s3c64xx/mach-hmt.c|  1 -
 arch/arm/mach-s3c64xx/mach-mini6410.c   |  1 -
 arch/arm/mach-s3c64xx/mach-ncp.c|  1 -
 arch/arm/mach-s3c64xx/mach-real6410.c   |  1 -
 arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c | 17 -
 arch/arm/mach-s3c64xx/mach-smartq5.c|  1 -
 arch/arm/mach-s3c64xx/mach-smartq7.c|  1 -
 arch/arm/mach-s3c64xx/mach-smdk6400.c   |  1 -
 arch/arm/mach-s3c64xx/mach-smdk6410.c   |  1 -
 arch/arm/mach-s3c64xx/watchdog-reset.h  | 16 -
 arch/arm/plat-samsung/Kconfig   |  6 --
 arch/arm/plat-samsung/Makefile  |  1 -
 arch/arm/plat-samsung/watchdog-reset.c  | 93 -
 18 files changed, 5 insertions(+), 158 deletions(-)
 delete mode 100644 arch/arm/mach-s3c64xx/watchdog-reset.h
 delete mode 100644 arch/arm/plat-samsung/watchdog-reset.c

diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index e208c2b48853..f3fcb570edf5 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -18,9 +18,10 @@ menuconfig ARCH_S3C64XX
select PM_GENERIC_DOMAINS if PM
select S3C_DEV_NAND if ATAGS
select S3C_GPIO_TRACK if ATAGS
+   select S3C2410_WATCHDOG
select SAMSUNG_ATAGS if ATAGS
select SAMSUNG_WAKEMASK if PM
-   select SAMSUNG_WDT_RESET
+   select WATCHDOG
help
  Samsung S3C64XX series based systems
 
diff --git a/arch/arm/mach-s3c64xx/common.c b/arch/arm/mach-s3c64xx/common.c
index a655bf0c7802..42e96d196f61 100644
--- a/arch/arm/mach-s3c64xx/common.c
+++ b/arch/arm/mach-s3c64xx/common.c
@@ -50,7 +50,6 @@
 
 #include "common.h"
 #include "irq-uart.h"
-#include "watchdog-reset.h"
 
 /* External clock frequency */
 static unsigned long xtal_f __ro_after_init = 1200;
@@ -232,10 +231,11 @@ void __init s3c64xx_init_irq(u32 vic0_valid, u32 
vic1_valid)
/*
 * FIXME: there is no better place to put this at the moment
 * (s3c64xx_clk_init needs ioremap and must happen before init_time
-* samsung_wdt_reset_init needs clocks)
+* samsung_wdt_reset_init needs clocks).  However
+* samsung_wdt_reset_init() was removed in favor of watchdog driver
+* so this should be revised.
 */
s3c64xx_clk_init(NULL, xtal_f, xusbxti_f, soc_is_s3c6400(), S3C_VA_SYS);
-   samsung_wdt_reset_init(S3C_VA_WATCHDOG);
 
printk(KERN_DEBUG "%s: initialising interrupts\n", __func__);
 
@@ -429,12 +429,3 @@ static int __init s3c64xx_init_irq_eint(void)
return 0;
 }
 arch_initcall(s3c64xx_init_irq_eint);
-
-void s3c64xx_restart(enum reboot_mode mode, const char *cmd)
-{
-   if (mode != REBOOT_SOFT)
-   samsung_wdt_reset();
-
-   /* if all else fails, or mode was for soft, jump to 0 */
-   soft_restart(0);
-}
diff --git a/arch/arm/mach-s3c64xx/common.h b/arch/arm/mach-s3c64xx/common.h
index 6fcfb0e0ffa5..567bf3017171 100644
--- a/arch/arm/mach-s3c64xx/common.h
+++ b/arch/arm/mach-s3c64xx/common.h
@@ -19,8 +19,6 @@
 void s3c64xx_init_irq(u32 vic0, u32 vic1);
 void s3c64xx_init_io(struct map_desc *mach_desc, int size);
 
-void s3c64xx_restart(enum reboot_mode mode, const char *cmd);
-
 struct device_node;
 void s3c64xx_set_xtal_freq(unsigned long freq);
 void s3c64xx_set_xusbxti_freq(unsigned long freq);
diff --git a/arch/arm/mach-s3c64xx/mach-anw6410.c 
b/arch/arm/mach-s3c64xx/mach-anw6410.c
index 495549573d36..e783f5b3593a 100644
--- a/arch/arm/mach-s3c64xx/mach-anw6410.c
+++ b/arch/arm/mach-s3c64xx/mach-anw6410.c
@@ -228,5 +228,4 @@ MACHINE_START(ANW6410, "A")
.map_io = anw6410_map_io,
.init_machine   = anw6410_machine_init,
.init_time  = samsung_timer_init,
-   .restart= s3c64xx_restart,
 MACHINE_END
diff --git 

[PATCH 5/7] ARM: samsung: Kill useless HAVE_S3C2410_WATCHDOG

2020-07-29 Thread Krzysztof Kozlowski
A separate Kconfig option HAVE_S3C2410_WATCHDOG for Samsung SoCs does
not have sense, because:
1. All ARMv7 and ARMv8 Samsung SoCs have watchdog,
2. All architecture Kconfigs were selecting it (if WATCHDOG framework is
   chosen),
3. HAVE_S3C2410_WATCHDOG is doing nothing except being a dependency of
   actual Samsung SoC watchdog driver, which is enabled manually by
   specific defconfigs.

HAVE_S3C2410_WATCHDOG can be safely removed.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/Kconfig  | 1 -
 arch/arm/mach-exynos/Kconfig  | 1 -
 arch/arm/mach-s3c64xx/Kconfig | 2 --
 arch/arm/mach-s5pv210/Kconfig | 1 -
 arch/arm64/Kconfig.platforms  | 1 -
 drivers/watchdog/Kconfig  | 8 
 6 files changed, 14 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 7564f293f107..fe95777af653 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -504,7 +504,6 @@ config ARCH_S3C24XX
select GPIOLIB
select GENERIC_IRQ_MULTI_HANDLER
select HAVE_S3C2410_I2C if I2C
-   select HAVE_S3C2410_WATCHDOG if WATCHDOG
select HAVE_S3C_RTC if RTC_CLASS
select NEED_MACH_IO_H
select SAMSUNG_ATAGS
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index f185cd3d4c62..d2d249706ebb 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -24,7 +24,6 @@ menuconfig ARCH_EXYNOS
select HAVE_ARM_ARCH_TIMER if ARCH_EXYNOS5
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
-   select HAVE_S3C2410_WATCHDOG if WATCHDOG
select HAVE_S3C_RTC if RTC_CLASS
select PINCTRL
select PINCTRL_EXYNOS
diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index ac3e3563487f..e208c2b48853 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -13,7 +13,6 @@ menuconfig ARCH_S3C64XX
select GPIO_SAMSUNG if ATAGS
select GPIOLIB
select HAVE_S3C2410_I2C if I2C
-   select HAVE_S3C2410_WATCHDOG if WATCHDOG
select HAVE_TCM
select PLAT_SAMSUNG
select PM_GENERIC_DOMAINS if PM
@@ -165,7 +164,6 @@ config MACH_SMDK6410
bool "SMDK6410"
depends on ATAGS
select CPU_S3C6410
-   select HAVE_S3C2410_WATCHDOG if WATCHDOG
select S3C64XX_SETUP_FB_24BPP
select S3C64XX_SETUP_I2C1
select S3C64XX_SETUP_IDE
diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
index 03984a791879..b3db1191e437 100644
--- a/arch/arm/mach-s5pv210/Kconfig
+++ b/arch/arm/mach-s5pv210/Kconfig
@@ -14,7 +14,6 @@ config ARCH_S5PV210
select COMMON_CLK_SAMSUNG
select GPIOLIB
select HAVE_S3C2410_I2C if I2C
-   select HAVE_S3C2410_WATCHDOG if WATCHDOG
select HAVE_S3C_RTC if RTC_CLASS
select PINCTRL
select PINCTRL_EXYNOS
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index cd58f8495c45..d235b27cf372 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -80,7 +80,6 @@ config ARCH_EXYNOS
select EXYNOS_CHIPID
select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
select EXYNOS_PMU
-   select HAVE_S3C2410_WATCHDOG if WATCHDOG
select HAVE_S3C_RTC if RTC_CLASS
select PINCTRL
select PINCTRL_EXYNOS
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 4f4687c46d38..ae86ea135d2b 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -478,16 +478,8 @@ config IXP4XX_WATCHDOG
 
  Say N if you are unsure.
 
-config HAVE_S3C2410_WATCHDOG
-   bool
-   help
- This will include watchdog timer support for Samsung SoCs. If
- you want to include watchdog support for any machine, kindly
- select this in the respective mach-/Kconfig file.
-
 config S3C2410_WATCHDOG
tristate "S3C2410 Watchdog"
-   depends on HAVE_S3C2410_WATCHDOG || COMPILE_TEST
select WATCHDOG_CORE
select MFD_SYSCON if ARCH_EXYNOS
help
-- 
2.17.1



[PATCH 2/7] ARM: s3c64xx: Include header to fix -Wmissing-prototypes

2020-07-29 Thread Krzysztof Kozlowski
Include the spi-s3c64xx.h header to fix W=1 build warning:

arch/arm/mach-s3c64xx/setup-spi.c:11:5: warning:
no previous prototype for 's3c64xx_spi0_cfg_gpio' [-Wmissing-prototypes]
   11 | int s3c64xx_spi0_cfg_gpio(void)

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/mach-s3c64xx/setup-spi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-s3c64xx/setup-spi.c 
b/arch/arm/mach-s3c64xx/setup-spi.c
index 39dfae1f46e7..03c9d296bb0f 100644
--- a/arch/arm/mach-s3c64xx/setup-spi.c
+++ b/arch/arm/mach-s3c64xx/setup-spi.c
@@ -4,6 +4,7 @@
 // http://www.samsung.com/
 
 #include 
+#include 
 #include 
 #include 
 
-- 
2.17.1



[PATCH 1/7] clk: samsung: s3c64xx: Declare s3c64xx_clk_init() in shared header

2020-07-29 Thread Krzysztof Kozlowski
The s3c64xx_clk_init() is defined and used by clk-s3c64xx driver and
also used in mach-s3c64xx machine code.  Move the declaration to a
header to fix W=1 build warning:

drivers/clk/samsung/clk-s3c64xx.c:391:13: warning: no previous prototype 
for 's3c64xx_clk_init' [-Wmissing-prototypes]
  391 | void __init s3c64xx_clk_init(struct device_node *np, unsigned long 
xtal_f,

Signed-off-by: Krzysztof Kozlowski 
---
 MAINTAINERS   |  1 +
 arch/arm/mach-s3c64xx/common.c|  1 +
 arch/arm/mach-s3c64xx/common.h|  2 --
 drivers/clk/samsung/clk-s3c64xx.c |  1 +
 include/linux/clk/samsung.h   | 21 +
 5 files changed, 24 insertions(+), 2 deletions(-)
 create mode 100644 include/linux/clk/samsung.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 7f8c6e41a364..f5d7cf3c3aaa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15294,6 +15294,7 @@ F:  
Documentation/devicetree/bindings/clock/samsung,s3c*
 F: Documentation/devicetree/bindings/clock/samsung,s5p*
 F: drivers/clk/samsung/
 F: include/dt-bindings/clock/exynos*.h
+F: include/linux/clk/samsung.h
 
 SAMSUNG SPI DRIVERS
 M: Kukjin Kim 
diff --git a/arch/arm/mach-s3c64xx/common.c b/arch/arm/mach-s3c64xx/common.c
index 13e91074308a..a655bf0c7802 100644
--- a/arch/arm/mach-s3c64xx/common.c
+++ b/arch/arm/mach-s3c64xx/common.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-s3c64xx/common.h b/arch/arm/mach-s3c64xx/common.h
index 03670887a764..f4eca42cdc86 100644
--- a/arch/arm/mach-s3c64xx/common.h
+++ b/arch/arm/mach-s3c64xx/common.h
@@ -22,8 +22,6 @@ void s3c64xx_init_io(struct map_desc *mach_desc, int size);
 void s3c64xx_restart(enum reboot_mode mode, const char *cmd);
 
 struct device_node;
-void s3c64xx_clk_init(struct device_node *np, unsigned long xtal_f,
-   unsigned long xusbxti_f, bool is_s3c6400, void __iomem *reg_base);
 void s3c64xx_set_xtal_freq(unsigned long freq);
 void s3c64xx_set_xusbxti_freq(unsigned long freq);
 
diff --git a/drivers/clk/samsung/clk-s3c64xx.c 
b/drivers/clk/samsung/clk-s3c64xx.c
index b96d33e5eb45..56f95b63f71f 100644
--- a/drivers/clk/samsung/clk-s3c64xx.c
+++ b/drivers/clk/samsung/clk-s3c64xx.c
@@ -7,6 +7,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/include/linux/clk/samsung.h b/include/linux/clk/samsung.h
new file mode 100644
index ..b6b253c46c22
--- /dev/null
+++ b/include/linux/clk/samsung.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2020 Krzysztof Kozlowski 
+ */
+
+#ifndef __LINUX_CLK_SAMSUNG_H_
+#define __LINUX_CLK_SAMSUNG_H_
+
+#ifdef CONFIG_ARCH_S3C64XX
+void __init s3c64xx_clk_init(struct device_node *np, unsigned long xtal_f,
+unsigned long xusbxti_f, bool s3c6400,
+void __iomem *base);
+#else
+static inline void __init s3c64xx_clk_init(struct device_node *np,
+  unsigned long xtal_f,
+  unsigned long xusbxti_f,
+  bool s3c6400,
+  void __iomem *base) { }
+#endif /* CONFIG_ARCH_S3C64XX */
+
+#endif /* __LINUX_CLK_SAMSUNG_H_ */
-- 
2.17.1



[PATCH 3/7] ARM: s3c: Remove plat-samsung/.../samsung-time.h

2020-07-29 Thread Krzysztof Kozlowski
Remove the arch/arm/plat-samsung/include/plat/samsung-time.h header and
move the contents to common.h headers in mach-s3c24xx and mach-s3c64xx.
The definition of declared functions is already in common.c in mach
directories, so it is logically to put declaration next to them.

This is also one step further towards removal of plat-samsung directory
and it fixes W=1 build warnings:

arch/arm/mach-s3c64xx/common.c:174:13: warning:
no previous prototype for 'samsung_set_timer_source' 
[-Wmissing-prototypes]
  174 | void __init samsung_set_timer_source(unsigned int event, unsigned 
int source)

arch/arm/mach-s3c64xx/common.c:180:13: warning:
no previous prototype for 'samsung_timer_init' [-Wmissing-prototypes]
  180 | void __init samsung_timer_init(void)

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/mach-s3c24xx/common.h| 12 +
 arch/arm/mach-s3c24xx/mach-amlm5900.c |  2 --
 arch/arm/mach-s3c24xx/mach-anubis.c   |  1 -
 arch/arm/mach-s3c24xx/mach-at2440evb.c|  1 -
 arch/arm/mach-s3c24xx/mach-bast.c |  1 -
 arch/arm/mach-s3c24xx/mach-gta02.c|  1 -
 arch/arm/mach-s3c24xx/mach-h1940.c|  1 -
 arch/arm/mach-s3c24xx/mach-jive.c |  1 -
 arch/arm/mach-s3c24xx/mach-mini2440.c |  1 -
 arch/arm/mach-s3c24xx/mach-n30.c  |  1 -
 arch/arm/mach-s3c24xx/mach-nexcoder.c |  1 -
 arch/arm/mach-s3c24xx/mach-osiris.c   |  1 -
 arch/arm/mach-s3c24xx/mach-otom.c |  1 -
 arch/arm/mach-s3c24xx/mach-qt2410.c   |  1 -
 arch/arm/mach-s3c24xx/mach-rx1950.c   |  1 -
 arch/arm/mach-s3c24xx/mach-rx3715.c   |  1 -
 arch/arm/mach-s3c24xx/mach-smdk2410.c |  1 -
 arch/arm/mach-s3c24xx/mach-smdk2413.c |  1 -
 arch/arm/mach-s3c24xx/mach-smdk2416.c |  1 -
 arch/arm/mach-s3c24xx/mach-smdk2440.c |  1 -
 arch/arm/mach-s3c24xx/mach-smdk2443.c |  1 -
 arch/arm/mach-s3c24xx/mach-tct_hammer.c   |  1 -
 arch/arm/mach-s3c24xx/mach-vr1000.c   |  1 -
 arch/arm/mach-s3c24xx/mach-vstms.c|  1 -
 arch/arm/mach-s3c64xx/common.h| 13 ++
 arch/arm/mach-s3c64xx/mach-anw6410.c  |  1 -
 arch/arm/mach-s3c64xx/mach-crag6410.c |  1 -
 arch/arm/mach-s3c64xx/mach-hmt.c  |  1 -
 arch/arm/mach-s3c64xx/mach-mini6410.c |  1 -
 arch/arm/mach-s3c64xx/mach-ncp.c  |  1 -
 arch/arm/mach-s3c64xx/mach-real6410.c |  1 -
 arch/arm/mach-s3c64xx/mach-smartq.c   |  1 -
 arch/arm/mach-s3c64xx/mach-smartq5.c  |  1 -
 arch/arm/mach-s3c64xx/mach-smartq7.c  |  1 -
 arch/arm/mach-s3c64xx/mach-smdk6400.c |  1 -
 arch/arm/mach-s3c64xx/mach-smdk6410.c |  1 -
 .../plat-samsung/include/plat/samsung-time.h  | 26 ---
 37 files changed, 25 insertions(+), 61 deletions(-)
 delete mode 100644 arch/arm/plat-samsung/include/plat/samsung-time.h

diff --git a/arch/arm/mach-s3c24xx/common.h b/arch/arm/mach-s3c24xx/common.h
index d087b20e8857..0260b80cffd1 100644
--- a/arch/arm/mach-s3c24xx/common.h
+++ b/arch/arm/mach-s3c24xx/common.h
@@ -123,4 +123,16 @@ void __init s3c2443_common_clk_init(struct device_node 
*np, unsigned long xti_f,
void __iomem *reg_base);
 #endif
 
+enum samsung_timer_mode {
+   SAMSUNG_PWM0,
+   SAMSUNG_PWM1,
+   SAMSUNG_PWM2,
+   SAMSUNG_PWM3,
+   SAMSUNG_PWM4,
+};
+
+extern void __init samsung_set_timer_source(enum samsung_timer_mode event,
+   enum samsung_timer_mode source);
+extern void __init samsung_timer_init(void);
+
 #endif /* __ARCH_ARM_MACH_S3C24XX_COMMON_H */
diff --git a/arch/arm/mach-s3c24xx/mach-amlm5900.c 
b/arch/arm/mach-s3c24xx/mach-amlm5900.c
index 9a9daf526d0c..623c320f8253 100644
--- a/arch/arm/mach-s3c24xx/mach-amlm5900.c
+++ b/arch/arm/mach-s3c24xx/mach-amlm5900.c
@@ -45,8 +45,6 @@
 #include 
 #include 
 
-#include 
-
 #include "common.h"
 
 static struct resource amlm5900_nor_resource =
diff --git a/arch/arm/mach-s3c24xx/mach-anubis.c 
b/arch/arm/mach-s3c24xx/mach-anubis.c
index 072966dcad78..44338dfb5470 100644
--- a/arch/arm/mach-s3c24xx/mach-anubis.c
+++ b/arch/arm/mach-s3c24xx/mach-anubis.c
@@ -44,7 +44,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "anubis.h"
 #include "common.h"
diff --git a/arch/arm/mach-s3c24xx/mach-at2440evb.c 
b/arch/arm/mach-s3c24xx/mach-at2440evb.c
index 58c5ef3cf1d7..02ac2e240bd7 100644
--- a/arch/arm/mach-s3c24xx/mach-at2440evb.c
+++ b/arch/arm/mach-s3c24xx/mach-at2440evb.c
@@ -43,7 +43,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "common.h"
 
diff --git a/arch/arm/mach-s3c24xx/mach-bast.c 
b/arch/arm/mach-s3c24xx/mach-bast.c
index a7c3955ae8f6..cd67d00a46e4 100644
--- a/arch/arm/mach-s3c24xx/mach-bast.c
+++ b/arch/arm/mach-s3c24xx/mach-bast.c
@@ -50,7 +50,6 @@
 #include 
 #include 
 #include 
-#include 
 
 

[PATCH 4/7] ARM: samsung: Fix language typo

2020-07-29 Thread Krzysztof Kozlowski
Fix Complie -> Compile

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/plat-samsung/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 301e572651c0..43a8b2bd16ff 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -154,7 +154,7 @@ config S3C_DEV_WDT
bool
default y if ARCH_S3C24XX
help
- Complie in platform device definition for Watchdog Timer
+ Compile in platform device definition for Watchdog Timer
 
 config S3C_DEV_NAND
bool
@@ -169,7 +169,7 @@ config S3C_DEV_ONENAND
 config S3C_DEV_RTC
bool
help
- Complie in platform device definition for RTC
+ Compile in platform device definition for RTC
 
 config SAMSUNG_DEV_ADC
bool
-- 
2.17.1



<    1   2   3   4   5   6   7   8   9   10   >