[PATCH v5 3/5] crypto: Change LZ4 modules to work with new LZ4 module version

[Sven Schmidt]

This patch updates the crypto modules using LZ4 compression
to work with the new LZ4 module version.

Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de>
---
 crypto/lz4.c   | 21 -
 crypto/lz4hc.c | 21 -
 2 files changed, 16 insertions(+), 26 deletions(-)

diff --git a/crypto/lz4.c b/crypto/lz4.c
index 99c1b2c..40fd2c2 100644
--- a/crypto/lz4.c
+++ b/crypto/lz4.c
@@ -66,15 +66,13 @@ static void lz4_exit(struct crypto_tfm *tfm)
 static int __lz4_compress_crypto(const u8 *src, unsigned int slen,
 u8 *dst, unsigned int *dlen, void *ctx)
 {
-   size_t tmp_len = *dlen;
-   int err;
+   int out_len = LZ4_compress_default(src, dst,
+   slen, (int)((size_t)dlen), ctx);
 
-   err = lz4_compress(src, slen, dst, _len, ctx);
-
-   if (err < 0)
+   if (!out_len)
return -EINVAL;
 
-   *dlen = tmp_len;
+   *dlen = out_len;
return 0;
 }
 
@@ -96,16 +94,13 @@ static int lz4_compress_crypto(struct crypto_tfm *tfm, 
const u8 *src,
 static int __lz4_decompress_crypto(const u8 *src, unsigned int slen,
   u8 *dst, unsigned int *dlen, void *ctx)
 {
-   int err;
-   size_t tmp_len = *dlen;
-   size_t __slen = slen;
+   int out_len = LZ4_decompress_safe(src, dst, slen, (int)((size_t)dlen));
 
-   err = lz4_decompress_unknownoutputsize(src, __slen, dst, _len);
-   if (err < 0)
+   if (out_len < 0)
return -EINVAL;
 
-   *dlen = tmp_len;
-   return err;
+   *dlen = out_len;
+   return out_len;
 }
 
 static int lz4_sdecompress(struct crypto_scomp *tfm, const u8 *src,
diff --git a/crypto/lz4hc.c b/crypto/lz4hc.c
index 75ffc4a..6f16f96 100644
--- a/crypto/lz4hc.c
+++ b/crypto/lz4hc.c
@@ -65,15 +65,13 @@ static void lz4hc_exit(struct crypto_tfm *tfm)
 static int __lz4hc_compress_crypto(const u8 *src, unsigned int slen,
   u8 *dst, unsigned int *dlen, void *ctx)
 {
-   size_t tmp_len = *dlen;
-   int err;
+   int out_len = LZ4_compress_HC(src, dst, slen,
+   (int)((size_t)dlen), LZ4HC_DEFAULT_CLEVEL, ctx);
 
-   err = lz4hc_compress(src, slen, dst, _len, ctx);
-
-   if (err < 0)
+   if (out_len == 0)
return -EINVAL;
 
-   *dlen = tmp_len;
+   *dlen = out_len;
return 0;
 }
 
@@ -97,16 +95,13 @@ static int lz4hc_compress_crypto(struct crypto_tfm *tfm, 
const u8 *src,
 static int __lz4hc_decompress_crypto(const u8 *src, unsigned int slen,
 u8 *dst, unsigned int *dlen, void *ctx)
 {
-   int err;
-   size_t tmp_len = *dlen;
-   size_t __slen = slen;
+   int out_len = LZ4_decompress_safe(src, dst, slen, (int)((size_t)dlen));
 
-   err = lz4_decompress_unknownoutputsize(src, __slen, dst, _len);
-   if (err < 0)
+   if (out_len < 0)
return -EINVAL;
 
-   *dlen = tmp_len;
-   return err;
+   *dlen = out_len;
+   return out_len;
 }
 
 static int lz4hc_sdecompress(struct crypto_scomp *tfm, const u8 *src,
-- 
2.1.4

[PATCH v5 4/5] fs/pstore: fs/squashfs: Change usage of LZ4 to work with new LZ4 version

[Sven Schmidt]

This patch updates fs/pstore and fs/squashfs to use the updated
functions from the new LZ4 module.

Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de>
---
 fs/pstore/platform.c  | 14 +++---
 fs/squashfs/lz4_wrapper.c | 12 ++--
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 729677e..85c4c58 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -342,31 +342,31 @@ static int compress_lz4(const void *in, void *out, size_t 
inlen, size_t outlen)
 {
int ret;
 
-   ret = lz4_compress(in, inlen, out, , workspace);
-   if (ret) {
+   ret = LZ4_compress_default(in, out, inlen, outlen, workspace);
+   if (!ret) {
pr_err("lz4_compress error, ret = %d!\n", ret);
return -EIO;
}
 
-   return outlen;
+   return ret;
 }
 
 static int decompress_lz4(void *in, void *out, size_t inlen, size_t outlen)
 {
int ret;
 
-   ret = lz4_decompress_unknownoutputsize(in, inlen, out, );
-   if (ret) {
+   ret = LZ4_decompress_safe(in, out, inlen, outlen);
+   if (ret < 0) {
pr_err("lz4_decompress error, ret = %d!\n", ret);
return -EIO;
}
 
-   return outlen;
+   return ret;
 }
 
 static void allocate_lz4(void)
 {
-   big_oops_buf_sz = lz4_compressbound(psinfo->bufsize);
+   big_oops_buf_sz = LZ4_compressBound(psinfo->bufsize);
big_oops_buf = kmalloc(big_oops_buf_sz, GFP_KERNEL);
if (big_oops_buf) {
workspace = kmalloc(LZ4_MEM_COMPRESS, GFP_KERNEL);
diff --git a/fs/squashfs/lz4_wrapper.c b/fs/squashfs/lz4_wrapper.c
index ff4468b..95da653 100644
--- a/fs/squashfs/lz4_wrapper.c
+++ b/fs/squashfs/lz4_wrapper.c
@@ -97,7 +97,6 @@ static int lz4_uncompress(struct squashfs_sb_info *msblk, 
void *strm,
struct squashfs_lz4 *stream = strm;
void *buff = stream->input, *data;
int avail, i, bytes = length, res;
-   size_t dest_len = output->length;
 
for (i = 0; i < b; i++) {
avail = min(bytes, msblk->devblksize - offset);
@@ -108,12 +107,13 @@ static int lz4_uncompress(struct squashfs_sb_info *msblk, 
void *strm,
put_bh(bh[i]);
}
 
-   res = lz4_decompress_unknownoutputsize(stream->input, length,
-   stream->output, _len);
-   if (res)
+   res = LZ4_decompress_safe(stream->input, stream->output,
+   length, output->length);
+
+   if (res < 0)
return -EIO;
 
-   bytes = dest_len;
+   bytes = res;
data = squashfs_first_page(output);
buff = stream->output;
while (data) {
@@ -128,7 +128,7 @@ static int lz4_uncompress(struct squashfs_sb_info *msblk, 
void *strm,
}
squashfs_finish_page(output);
 
-   return dest_len;
+   return res;
 }
 
 const struct squashfs_decompressor squashfs_lz4_comp_ops = {
-- 
2.1.4

[PATCH v5 1/5] lib: Update LZ4 compressor module

[Sven Schmidt]

This patch updates LZ4 kernel module to LZ4 v1.7.3 by Yann Collet.
The kernel module is inspired by the previous work by Chanho Min.
The updated LZ4 module will not break existing code since the patchset
contains appropriate changes.

API changes:

New method LZ4_compress_fast which differs from the variant available
in kernel by the new acceleration parameter,
allowing to trade compression ratio for more compression speed
and vice versa.

LZ4_decompress_fast is the respective decompression method, featuring a very
fast decoder (multiple GB/s per core), able to reach RAM speed in multi-core
systems. The decompressor allows to decompress data compressed with
LZ4 fast as well as the LZ4 HC (high compression) algorithm.

Also the useful functions LZ4_decompress_safe_partial
LZ4_compress_destsize were added. The latter reverses the logic by trying to
compress as much data as possible from source to dest while the former aims
to decompress partial blocks of data.

A bunch of streaming functions were also added
which allow compressig/decompressing data in multiple steps
(so called "streaming mode").

The methods lz4_compress and lz4_decompress_unknownoutputsize
are now known as LZ4_compress_default respectivley LZ4_decompress_safe.
The old methods will be removed since there's no callers left in the code.

Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de>
---
 include/linux/lz4.h  |  589 ++---
 lib/lz4/lz4_compress.c   | 1103 --
 lib/lz4/lz4_decompress.c |  694 ++---
 lib/lz4/lz4defs.h|  320 --
 lib/lz4/lz4hc_compress.c |  855 ++-
 5 files changed, 2486 insertions(+), 1075 deletions(-)

diff --git a/include/linux/lz4.h b/include/linux/lz4.h
index 6b784c5..2072255 100644
--- a/include/linux/lz4.h
+++ b/include/linux/lz4.h
@@ -1,87 +1,554 @@
-#ifndef __LZ4_H__
-#define __LZ4_H__
-/*
- * LZ4 Kernel Interface
+/* LZ4 Kernel Interface
  *
  * Copyright (C) 2013, LG Electronics, Kyungsik Lee 
+ * Copyright (C) 2016, Sven Schmidt <4ssch...@informatik.uni-hamburg.de>
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
+ *
+ * This file is based on the original header file
+ * for LZ4 - Fast LZ compression algorithm.
+ *
+ * LZ4 - Fast LZ compression algorithm
+ * Copyright (C) 2011-2016, Yann Collet.
+ * BSD 2-Clause License (http://www.opensource.org/licenses/bsd-license.php)
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are
+ * met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following disclaimer
+ * in the documentation and/or other materials provided with the
+ * distribution.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ * You can contact the author at :
+ * - LZ4 homepage : http://www.lz4.org
+ * - LZ4 source repository : https://github.com/lz4/lz4
+ */
+
+#ifndef __LZ4_H__
+#define __LZ4_H__
+
+#include 
+#include/* memset, memcpy */
+
+/*-
+ * CONSTANTS
+ **/
+/*
+ * LZ4_MEMORY_USAGE :
+ * Memory usage formula : N->2^N Bytes
+ * (examples : 10 -> 1KB; 12 -> 4KB ; 16 -> 64KB; 20 -> 1MB; etc.)
+ * Increasing memory usage improves compression ratio
+ * Reduced memory usage can improve speed, due to cache effect
+ * Default value is 14, for 16KB, which nicely fits into Intel x86 L1 cache
+ */
+#define LZ4_MEMORY_USAGE 10
+
+#define LZ4_MAX_INPUT_SIZE 0x7E00 /* 2 113 929 216 bytes */
+#define LZ4_COMPRESSBOUND(isize)   (\
+   (unsigned int)(isize) > (unsigned int)LZ4_MAX_INPUT_SIZE \
+   ? 0 \
+   : (isize) + ((isize)/255) + 16)
+
+#define 

[PATCH v5 3/5] crypto: Change LZ4 modules to work with new LZ4 module version

[Sven Schmidt]

This patch updates the crypto modules using LZ4 compression
to work with the new LZ4 module version.

Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de>
---
 crypto/lz4.c   | 21 -
 crypto/lz4hc.c | 21 -
 2 files changed, 16 insertions(+), 26 deletions(-)

diff --git a/crypto/lz4.c b/crypto/lz4.c
index 99c1b2c..40fd2c2 100644
--- a/crypto/lz4.c
+++ b/crypto/lz4.c
@@ -66,15 +66,13 @@ static void lz4_exit(struct crypto_tfm *tfm)
 static int __lz4_compress_crypto(const u8 *src, unsigned int slen,
 u8 *dst, unsigned int *dlen, void *ctx)
 {
-   size_t tmp_len = *dlen;
-   int err;
+   int out_len = LZ4_compress_default(src, dst,
+   slen, (int)((size_t)dlen), ctx);
 
-   err = lz4_compress(src, slen, dst, _len, ctx);
-
-   if (err < 0)
+   if (!out_len)
return -EINVAL;
 
-   *dlen = tmp_len;
+   *dlen = out_len;
return 0;
 }
 
@@ -96,16 +94,13 @@ static int lz4_compress_crypto(struct crypto_tfm *tfm, 
const u8 *src,
 static int __lz4_decompress_crypto(const u8 *src, unsigned int slen,
   u8 *dst, unsigned int *dlen, void *ctx)
 {
-   int err;
-   size_t tmp_len = *dlen;
-   size_t __slen = slen;
+   int out_len = LZ4_decompress_safe(src, dst, slen, (int)((size_t)dlen));
 
-   err = lz4_decompress_unknownoutputsize(src, __slen, dst, _len);
-   if (err < 0)
+   if (out_len < 0)
return -EINVAL;
 
-   *dlen = tmp_len;
-   return err;
+   *dlen = out_len;
+   return out_len;
 }
 
 static int lz4_sdecompress(struct crypto_scomp *tfm, const u8 *src,
diff --git a/crypto/lz4hc.c b/crypto/lz4hc.c
index 75ffc4a..6f16f96 100644
--- a/crypto/lz4hc.c
+++ b/crypto/lz4hc.c
@@ -65,15 +65,13 @@ static void lz4hc_exit(struct crypto_tfm *tfm)
 static int __lz4hc_compress_crypto(const u8 *src, unsigned int slen,
   u8 *dst, unsigned int *dlen, void *ctx)
 {
-   size_t tmp_len = *dlen;
-   int err;
+   int out_len = LZ4_compress_HC(src, dst, slen,
+   (int)((size_t)dlen), LZ4HC_DEFAULT_CLEVEL, ctx);
 
-   err = lz4hc_compress(src, slen, dst, _len, ctx);
-
-   if (err < 0)
+   if (out_len == 0)
return -EINVAL;
 
-   *dlen = tmp_len;
+   *dlen = out_len;
return 0;
 }
 
@@ -97,16 +95,13 @@ static int lz4hc_compress_crypto(struct crypto_tfm *tfm, 
const u8 *src,
 static int __lz4hc_decompress_crypto(const u8 *src, unsigned int slen,
 u8 *dst, unsigned int *dlen, void *ctx)
 {
-   int err;
-   size_t tmp_len = *dlen;
-   size_t __slen = slen;
+   int out_len = LZ4_decompress_safe(src, dst, slen, (int)((size_t)dlen));
 
-   err = lz4_decompress_unknownoutputsize(src, __slen, dst, _len);
-   if (err < 0)
+   if (out_len < 0)
return -EINVAL;
 
-   *dlen = tmp_len;
-   return err;
+   *dlen = out_len;
+   return out_len;
 }
 
 static int lz4hc_sdecompress(struct crypto_scomp *tfm, const u8 *src,
-- 
2.1.4

[PATCH v5 4/5] fs/pstore: fs/squashfs: Change usage of LZ4 to work with new LZ4 version

[Sven Schmidt]

This patch updates fs/pstore and fs/squashfs to use the updated
functions from the new LZ4 module.

Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de>
---
 fs/pstore/platform.c  | 14 +++---
 fs/squashfs/lz4_wrapper.c | 12 ++--
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 729677e..85c4c58 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -342,31 +342,31 @@ static int compress_lz4(const void *in, void *out, size_t 
inlen, size_t outlen)
 {
int ret;
 
-   ret = lz4_compress(in, inlen, out, , workspace);
-   if (ret) {
+   ret = LZ4_compress_default(in, out, inlen, outlen, workspace);
+   if (!ret) {
pr_err("lz4_compress error, ret = %d!\n", ret);
return -EIO;
}
 
-   return outlen;
+   return ret;
 }
 
 static int decompress_lz4(void *in, void *out, size_t inlen, size_t outlen)
 {
int ret;
 
-   ret = lz4_decompress_unknownoutputsize(in, inlen, out, );
-   if (ret) {
+   ret = LZ4_decompress_safe(in, out, inlen, outlen);
+   if (ret < 0) {
pr_err("lz4_decompress error, ret = %d!\n", ret);
return -EIO;
}
 
-   return outlen;
+   return ret;
 }
 
 static void allocate_lz4(void)
 {
-   big_oops_buf_sz = lz4_compressbound(psinfo->bufsize);
+   big_oops_buf_sz = LZ4_compressBound(psinfo->bufsize);
big_oops_buf = kmalloc(big_oops_buf_sz, GFP_KERNEL);
if (big_oops_buf) {
workspace = kmalloc(LZ4_MEM_COMPRESS, GFP_KERNEL);
diff --git a/fs/squashfs/lz4_wrapper.c b/fs/squashfs/lz4_wrapper.c
index ff4468b..95da653 100644
--- a/fs/squashfs/lz4_wrapper.c
+++ b/fs/squashfs/lz4_wrapper.c
@@ -97,7 +97,6 @@ static int lz4_uncompress(struct squashfs_sb_info *msblk, 
void *strm,
struct squashfs_lz4 *stream = strm;
void *buff = stream->input, *data;
int avail, i, bytes = length, res;
-   size_t dest_len = output->length;
 
for (i = 0; i < b; i++) {
avail = min(bytes, msblk->devblksize - offset);
@@ -108,12 +107,13 @@ static int lz4_uncompress(struct squashfs_sb_info *msblk, 
void *strm,
put_bh(bh[i]);
}
 
-   res = lz4_decompress_unknownoutputsize(stream->input, length,
-   stream->output, _len);
-   if (res)
+   res = LZ4_decompress_safe(stream->input, stream->output,
+   length, output->length);
+
+   if (res < 0)
return -EIO;
 
-   bytes = dest_len;
+   bytes = res;
data = squashfs_first_page(output);
buff = stream->output;
while (data) {
@@ -128,7 +128,7 @@ static int lz4_uncompress(struct squashfs_sb_info *msblk, 
void *strm,
}
squashfs_finish_page(output);
 
-   return dest_len;
+   return res;
 }
 
 const struct squashfs_decompressor squashfs_lz4_comp_ops = {
-- 
2.1.4

[PATCH v5 1/5] lib: Update LZ4 compressor module

[Sven Schmidt]

This patch updates LZ4 kernel module to LZ4 v1.7.3 by Yann Collet.
The kernel module is inspired by the previous work by Chanho Min.
The updated LZ4 module will not break existing code since the patchset
contains appropriate changes.

API changes:

New method LZ4_compress_fast which differs from the variant available
in kernel by the new acceleration parameter,
allowing to trade compression ratio for more compression speed
and vice versa.

LZ4_decompress_fast is the respective decompression method, featuring a very
fast decoder (multiple GB/s per core), able to reach RAM speed in multi-core
systems. The decompressor allows to decompress data compressed with
LZ4 fast as well as the LZ4 HC (high compression) algorithm.

Also the useful functions LZ4_decompress_safe_partial
LZ4_compress_destsize were added. The latter reverses the logic by trying to
compress as much data as possible from source to dest while the former aims
to decompress partial blocks of data.

A bunch of streaming functions were also added
which allow compressig/decompressing data in multiple steps
(so called "streaming mode").

The methods lz4_compress and lz4_decompress_unknownoutputsize
are now known as LZ4_compress_default respectivley LZ4_decompress_safe.
The old methods will be removed since there's no callers left in the code.

Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de>
---
 include/linux/lz4.h  |  589 ++---
 lib/lz4/lz4_compress.c   | 1103 --
 lib/lz4/lz4_decompress.c |  694 ++---
 lib/lz4/lz4defs.h|  320 --
 lib/lz4/lz4hc_compress.c |  855 ++-
 5 files changed, 2486 insertions(+), 1075 deletions(-)

diff --git a/include/linux/lz4.h b/include/linux/lz4.h
index 6b784c5..2072255 100644
--- a/include/linux/lz4.h
+++ b/include/linux/lz4.h
@@ -1,87 +1,554 @@
-#ifndef __LZ4_H__
-#define __LZ4_H__
-/*
- * LZ4 Kernel Interface
+/* LZ4 Kernel Interface
  *
  * Copyright (C) 2013, LG Electronics, Kyungsik Lee 
+ * Copyright (C) 2016, Sven Schmidt <4ssch...@informatik.uni-hamburg.de>
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
+ *
+ * This file is based on the original header file
+ * for LZ4 - Fast LZ compression algorithm.
+ *
+ * LZ4 - Fast LZ compression algorithm
+ * Copyright (C) 2011-2016, Yann Collet.
+ * BSD 2-Clause License (http://www.opensource.org/licenses/bsd-license.php)
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are
+ * met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following disclaimer
+ * in the documentation and/or other materials provided with the
+ * distribution.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ * You can contact the author at :
+ * - LZ4 homepage : http://www.lz4.org
+ * - LZ4 source repository : https://github.com/lz4/lz4
+ */
+
+#ifndef __LZ4_H__
+#define __LZ4_H__
+
+#include 
+#include/* memset, memcpy */
+
+/*-
+ * CONSTANTS
+ **/
+/*
+ * LZ4_MEMORY_USAGE :
+ * Memory usage formula : N->2^N Bytes
+ * (examples : 10 -> 1KB; 12 -> 4KB ; 16 -> 64KB; 20 -> 1MB; etc.)
+ * Increasing memory usage improves compression ratio
+ * Reduced memory usage can improve speed, due to cache effect
+ * Default value is 14, for 16KB, which nicely fits into Intel x86 L1 cache
+ */
+#define LZ4_MEMORY_USAGE 10
+
+#define LZ4_MAX_INPUT_SIZE 0x7E00 /* 2 113 929 216 bytes */
+#define LZ4_COMPRESSBOUND(isize)   (\
+   (unsigned int)(isize) > (unsigned int)LZ4_MAX_INPUT_SIZE \
+   ? 0 \
+   : (isize) + ((isize)/255) + 16)
+
+#define 

Re: [PATCH v6] mm: Add memory allocation watchdog kernel thread.

[Michal Hocko]

On Wed 25-01-17 14:22:45, Johannes Weiner wrote:
> On Wed, Jan 25, 2017 at 07:45:49PM +0100, Michal Hocko wrote:
> > On Wed 25-01-17 13:11:50, Johannes Weiner wrote:
> > [...]
> > > >From 6420cae52cac8167bd5fb19f45feed2d540bc11d Mon Sep 17 00:00:00 2001
> > > From: Johannes Weiner 
> > > Date: Wed, 25 Jan 2017 12:57:20 -0500
> > > Subject: [PATCH] mm: page_alloc: __GFP_NOWARN shouldn't suppress stall
> > >  warnings
> > > 
> > > __GFP_NOWARN, which is usually added to avoid warnings from callsites
> > > that expect to fail and have fallbacks, currently also suppresses
> > > allocation stall warnings. These trigger when an allocation is stuck
> > > inside the allocator for 10 seconds or longer.
> > > 
> > > But there is no class of allocations that can get legitimately stuck
> > > in the allocator for this long. This always indicates a problem.
> > > 
> > > Always emit stall warnings. Restrict __GFP_NOWARN to alloc failures.
> > 
> > Tetsuo has already suggested something like this and I didn't really
> > like it because it makes the semantic of the flag confusing. The mask
> > says to not warn while the kernel log might contain an allocation splat.
> > You are right that stalling for 10s seconds means a problem on its own
> > but on the other hand I can imagine somebody might really want to have
> > clean logs and the last thing we want is to have another gfp flag for
> > that purpose.
> 
> I don't think it's confusing. __GFP_NOWARN tells the allocator whether
> an allocation failure can be handled or whether it constitutes a bug.
> 
> If we agree that stalling for 10s is a bug, then we should emit the
> warnings.

Yes, in many cases it would be a bug in the MM. Some of them would be
inherent because the allocator doesn't implement any fairness and
starvation cannot be ruled out (would that be a bug?). In general,
looping/spending a lot of time in kernel can be seen as a bug. We have
watchdogs to report those cases and the time has told us that we had to
develop ways to silent those lockups because in some cases we couldn't
handle them. I am worried we will eventually find cases like that for
allocation stalls as well. I might be over sensitive because we have
made some mistakes in the gfp flags land already and I would like to
prevent more to come.

That being said, I will not stand in the way...
-- 
Michal Hocko
SUSE Labs

[PATCH v5 5/5] lib/lz4: Remove back-compat wrappers

[Sven Schmidt]

This patch removes the functions introduced as wrappers for providing
backwards compatibility to the prior LZ4 version.
They're not needed anymore since there's no callers left.

Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de>
---
 include/linux/lz4.h  | 73 
 lib/lz4/lz4_compress.c   | 22 ---
 lib/lz4/lz4_decompress.c | 42 
 lib/lz4/lz4hc_compress.c | 23 ---
 4 files changed, 160 deletions(-)

diff --git a/include/linux/lz4.h b/include/linux/lz4.h
index 2072255..5958f7d 100644
--- a/include/linux/lz4.h
+++ b/include/linux/lz4.h
@@ -173,14 +173,6 @@ static inline int LZ4_compressBound(size_t isize)
 }
 
 /*
- * For backward compatibility
- */
-static inline int lz4_compressbound(size_t isize)
-{
-   return LZ4_COMPRESSBOUND(isize);
-}
-
-/*
  * LZ4_compress_default()
  * Compresses 'sourceSize' bytes from buffer 'source'
  * into already allocated 'dest' buffer of size 'maxOutputSize'.
@@ -249,23 +241,6 @@ int LZ4_compress_fast(const char *source, char *dest, int 
inputSize,
 int LZ4_compress_destSize(const char *source, char *dest, int *sourceSizePtr,
int targetDestSize, void *wrkmem);
 
-/*
- * lz4_compress()
- * src: source address of the original data
- * src_len: size of the original data
- * dst: output buffer address of the compressed data
- *   This requires 'dst' of size LZ4_COMPRESSBOUND.
- * dst_len: is the output size, which is returned after compress done
- * workmem: address of the working memory.
- *   This requires 'workmem' of size LZ4_MEM_COMPRESS.
- * return  : Success if return 0
- *Error if return (< 0)
- * note :  Destination buffer and workmem must be already allocated with
- * the defined size.
- */
-int lz4_compress(const unsigned char *src, size_t src_len, unsigned char *dst,
-   size_t *dst_len, void *wrkmem);
-
 /*-
  * Decompression Functions
  **/
@@ -340,37 +315,6 @@ int LZ4_decompress_safe(const char *source, char *dest, 
int compressedSize,
 int LZ4_decompress_safe_partial(const char *source, char *dest,
int compressedSize, int targetOutputSize, int maxDecompressedSize);
 
-
-/*
- * lz4_decompress_unknownoutputsize() :
- * src : source address of the compressed data
- * src_len : is the input size, therefore the compressed size
- * dest: output buffer address of the decompressed data
- * dest_len: is the max size of the destination buffer, which is
- *returned with actual size of decompressed data after
- *decompress done
- * return: Success if return 0
- * Error if return (< 0)
- * note:   Destination buffer must be already allocated.
- */
-int lz4_decompress_unknownoutputsize(const unsigned char *src, size_t src_len,
-   unsigned char *dest, size_t *dest_len);
-
-/*
- * lz4_decompress() :
- * src: source address of the compressed data
- * src_len: is the input size,
- *   which is returned after decompress done
- * dest   : output buffer address of the decompressed data
- * actual_dest_len: is the size of uncompressed data, supposing it's known
- * return: Success if return 0
- *  Error if return (< 0)
- * note  : Destination buffer must be already allocated.
- *  slightly faster than lz4_decompress_unknownoutputsize()
- */
-int lz4_decompress(const unsigned char *src, size_t *src_len,
-   unsigned char *dest, size_t actual_dest_len);
-
 /*-
  * LZ4 HC Compression
  **/
@@ -399,23 +343,6 @@ int LZ4_compress_HC(const char *src, char *dst, int 
srcSize, int dstCapacity,
int compressionLevel, void *wrkmem);
 
 /*
- * lz4hc_compress()
- * src: source address of the original data
- * src_len: size of the original data
- * dst: output buffer address of the compressed data
- *   This requires 'dst' of size LZ4_COMPRESSBOUND.
- * dst_len: is the output size, which is returned after compress done
- * workmem: address of the working memory.
- *   This requires 'workmem' of size LZ4HC_MEM_COMPRESS.
- * return  : Success if return 0
- *  Error if return (< 0)
- * note   : Destination buffer and workmem must be already allocated with
- *  the defined size.
- */
-int lz4hc_compress(const unsigned char *src, size_t src_len, unsigned char 
*dst,
-   size_t *dst_len, void *wrkmem);
-
-/*
  * These functions compress data in successive blocks of any size,
  * using previous blocks as dictionary. One key assumption is that previous
  * blocks 

Re: [PATCH v6] mm: Add memory allocation watchdog kernel thread.

[Michal Hocko]

On Wed 25-01-17 14:22:45, Johannes Weiner wrote:
> On Wed, Jan 25, 2017 at 07:45:49PM +0100, Michal Hocko wrote:
> > On Wed 25-01-17 13:11:50, Johannes Weiner wrote:
> > [...]
> > > >From 6420cae52cac8167bd5fb19f45feed2d540bc11d Mon Sep 17 00:00:00 2001
> > > From: Johannes Weiner 
> > > Date: Wed, 25 Jan 2017 12:57:20 -0500
> > > Subject: [PATCH] mm: page_alloc: __GFP_NOWARN shouldn't suppress stall
> > >  warnings
> > > 
> > > __GFP_NOWARN, which is usually added to avoid warnings from callsites
> > > that expect to fail and have fallbacks, currently also suppresses
> > > allocation stall warnings. These trigger when an allocation is stuck
> > > inside the allocator for 10 seconds or longer.
> > > 
> > > But there is no class of allocations that can get legitimately stuck
> > > in the allocator for this long. This always indicates a problem.
> > > 
> > > Always emit stall warnings. Restrict __GFP_NOWARN to alloc failures.
> > 
> > Tetsuo has already suggested something like this and I didn't really
> > like it because it makes the semantic of the flag confusing. The mask
> > says to not warn while the kernel log might contain an allocation splat.
> > You are right that stalling for 10s seconds means a problem on its own
> > but on the other hand I can imagine somebody might really want to have
> > clean logs and the last thing we want is to have another gfp flag for
> > that purpose.
> 
> I don't think it's confusing. __GFP_NOWARN tells the allocator whether
> an allocation failure can be handled or whether it constitutes a bug.
> 
> If we agree that stalling for 10s is a bug, then we should emit the
> warnings.

Yes, in many cases it would be a bug in the MM. Some of them would be
inherent because the allocator doesn't implement any fairness and
starvation cannot be ruled out (would that be a bug?). In general,
looping/spending a lot of time in kernel can be seen as a bug. We have
watchdogs to report those cases and the time has told us that we had to
develop ways to silent those lockups because in some cases we couldn't
handle them. I am worried we will eventually find cases like that for
allocation stalls as well. I might be over sensitive because we have
made some mistakes in the gfp flags land already and I would like to
prevent more to come.

That being said, I will not stand in the way...
-- 
Michal Hocko
SUSE Labs

[PATCH v5 5/5] lib/lz4: Remove back-compat wrappers

[Sven Schmidt]

This patch removes the functions introduced as wrappers for providing
backwards compatibility to the prior LZ4 version.
They're not needed anymore since there's no callers left.

Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de>
---
 include/linux/lz4.h  | 73 
 lib/lz4/lz4_compress.c   | 22 ---
 lib/lz4/lz4_decompress.c | 42 
 lib/lz4/lz4hc_compress.c | 23 ---
 4 files changed, 160 deletions(-)

diff --git a/include/linux/lz4.h b/include/linux/lz4.h
index 2072255..5958f7d 100644
--- a/include/linux/lz4.h
+++ b/include/linux/lz4.h
@@ -173,14 +173,6 @@ static inline int LZ4_compressBound(size_t isize)
 }
 
 /*
- * For backward compatibility
- */
-static inline int lz4_compressbound(size_t isize)
-{
-   return LZ4_COMPRESSBOUND(isize);
-}
-
-/*
  * LZ4_compress_default()
  * Compresses 'sourceSize' bytes from buffer 'source'
  * into already allocated 'dest' buffer of size 'maxOutputSize'.
@@ -249,23 +241,6 @@ int LZ4_compress_fast(const char *source, char *dest, int 
inputSize,
 int LZ4_compress_destSize(const char *source, char *dest, int *sourceSizePtr,
int targetDestSize, void *wrkmem);
 
-/*
- * lz4_compress()
- * src: source address of the original data
- * src_len: size of the original data
- * dst: output buffer address of the compressed data
- *   This requires 'dst' of size LZ4_COMPRESSBOUND.
- * dst_len: is the output size, which is returned after compress done
- * workmem: address of the working memory.
- *   This requires 'workmem' of size LZ4_MEM_COMPRESS.
- * return  : Success if return 0
- *Error if return (< 0)
- * note :  Destination buffer and workmem must be already allocated with
- * the defined size.
- */
-int lz4_compress(const unsigned char *src, size_t src_len, unsigned char *dst,
-   size_t *dst_len, void *wrkmem);
-
 /*-
  * Decompression Functions
  **/
@@ -340,37 +315,6 @@ int LZ4_decompress_safe(const char *source, char *dest, 
int compressedSize,
 int LZ4_decompress_safe_partial(const char *source, char *dest,
int compressedSize, int targetOutputSize, int maxDecompressedSize);
 
-
-/*
- * lz4_decompress_unknownoutputsize() :
- * src : source address of the compressed data
- * src_len : is the input size, therefore the compressed size
- * dest: output buffer address of the decompressed data
- * dest_len: is the max size of the destination buffer, which is
- *returned with actual size of decompressed data after
- *decompress done
- * return: Success if return 0
- * Error if return (< 0)
- * note:   Destination buffer must be already allocated.
- */
-int lz4_decompress_unknownoutputsize(const unsigned char *src, size_t src_len,
-   unsigned char *dest, size_t *dest_len);
-
-/*
- * lz4_decompress() :
- * src: source address of the compressed data
- * src_len: is the input size,
- *   which is returned after decompress done
- * dest   : output buffer address of the decompressed data
- * actual_dest_len: is the size of uncompressed data, supposing it's known
- * return: Success if return 0
- *  Error if return (< 0)
- * note  : Destination buffer must be already allocated.
- *  slightly faster than lz4_decompress_unknownoutputsize()
- */
-int lz4_decompress(const unsigned char *src, size_t *src_len,
-   unsigned char *dest, size_t actual_dest_len);
-
 /*-
  * LZ4 HC Compression
  **/
@@ -399,23 +343,6 @@ int LZ4_compress_HC(const char *src, char *dst, int 
srcSize, int dstCapacity,
int compressionLevel, void *wrkmem);
 
 /*
- * lz4hc_compress()
- * src: source address of the original data
- * src_len: size of the original data
- * dst: output buffer address of the compressed data
- *   This requires 'dst' of size LZ4_COMPRESSBOUND.
- * dst_len: is the output size, which is returned after compress done
- * workmem: address of the working memory.
- *   This requires 'workmem' of size LZ4HC_MEM_COMPRESS.
- * return  : Success if return 0
- *  Error if return (< 0)
- * note   : Destination buffer and workmem must be already allocated with
- *  the defined size.
- */
-int lz4hc_compress(const unsigned char *src, size_t src_len, unsigned char 
*dst,
-   size_t *dst_len, void *wrkmem);
-
-/*
  * These functions compress data in successive blocks of any size,
  * using previous blocks as dictionary. One key assumption is that previous
  * blocks 

[PATCH v5 2/5] lib/decompress_unlz4: Change module to work with new LZ4 module version

[Sven Schmidt]

This patch updates the unlz4 wrapper to work with the
updated LZ4 kernel module version.

Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de>
---
 lib/decompress_unlz4.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/lib/decompress_unlz4.c b/lib/decompress_unlz4.c
index 036fc88..1b0baf3 100644
--- a/lib/decompress_unlz4.c
+++ b/lib/decompress_unlz4.c
@@ -72,7 +72,7 @@ STATIC inline int INIT unlz4(u8 *input, long in_len,
error("NULL input pointer and missing fill function");
goto exit_1;
} else {
-   inp = large_malloc(lz4_compressbound(uncomp_chunksize));
+   inp = large_malloc(LZ4_compressBound(uncomp_chunksize));
if (!inp) {
error("Could not allocate input buffer");
goto exit_1;
@@ -136,7 +136,7 @@ STATIC inline int INIT unlz4(u8 *input, long in_len,
inp += 4;
size -= 4;
} else {
-   if (chunksize > lz4_compressbound(uncomp_chunksize)) {
+   if (chunksize > LZ4_compressBound(uncomp_chunksize)) {
error("chunk length is longer than allocated");
goto exit_2;
}
@@ -152,11 +152,14 @@ STATIC inline int INIT unlz4(u8 *input, long in_len,
out_len -= dest_len;
} else
dest_len = out_len;
-   ret = lz4_decompress(inp, , outp, dest_len);
+
+   ret = LZ4_decompress_fast(inp, outp, dest_len);
+   chunksize = ret;
 #else
dest_len = uncomp_chunksize;
-   ret = lz4_decompress_unknownoutputsize(inp, chunksize, outp,
-   _len);
+
+   ret = LZ4_decompress_safe(inp, outp, chunksize, dest_len);
+   dest_len = ret;
 #endif
if (ret < 0) {
error("Decoding failed");
-- 
2.1.4

[PATCH v5 2/5] lib/decompress_unlz4: Change module to work with new LZ4 module version

[Sven Schmidt]

This patch updates the unlz4 wrapper to work with the
updated LZ4 kernel module version.

Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de>
---
 lib/decompress_unlz4.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/lib/decompress_unlz4.c b/lib/decompress_unlz4.c
index 036fc88..1b0baf3 100644
--- a/lib/decompress_unlz4.c
+++ b/lib/decompress_unlz4.c
@@ -72,7 +72,7 @@ STATIC inline int INIT unlz4(u8 *input, long in_len,
error("NULL input pointer and missing fill function");
goto exit_1;
} else {
-   inp = large_malloc(lz4_compressbound(uncomp_chunksize));
+   inp = large_malloc(LZ4_compressBound(uncomp_chunksize));
if (!inp) {
error("Could not allocate input buffer");
goto exit_1;
@@ -136,7 +136,7 @@ STATIC inline int INIT unlz4(u8 *input, long in_len,
inp += 4;
size -= 4;
} else {
-   if (chunksize > lz4_compressbound(uncomp_chunksize)) {
+   if (chunksize > LZ4_compressBound(uncomp_chunksize)) {
error("chunk length is longer than allocated");
goto exit_2;
}
@@ -152,11 +152,14 @@ STATIC inline int INIT unlz4(u8 *input, long in_len,
out_len -= dest_len;
} else
dest_len = out_len;
-   ret = lz4_decompress(inp, , outp, dest_len);
+
+   ret = LZ4_decompress_fast(inp, outp, dest_len);
+   chunksize = ret;
 #else
dest_len = uncomp_chunksize;
-   ret = lz4_decompress_unknownoutputsize(inp, chunksize, outp,
-   _len);
+
+   ret = LZ4_decompress_safe(inp, outp, chunksize, dest_len);
+   dest_len = ret;
 #endif
if (ret < 0) {
error("Decoding failed");
-- 
2.1.4

[PATCH v5 0/5] Update LZ4 compressor module

[Sven Schmidt]

This patchset is for updating the LZ4 compression module to a version based
on LZ4 v1.7.3 allowing to use the fast compression algorithm aka LZ4 fast
which provides an "acceleration" parameter as a tradeoff between
high compression ratio and high compression speed.

We want to use LZ4 fast in order to support compression in lustre
and (mostly, based on that) investigate data reduction techniques in behalf of
storage systems.

Also, it will be useful for other users of LZ4 compression, as with LZ4 fast
it is possible to enable applications to use fast and/or high compression
depending on the usecase.
For instance, ZRAM is offering a LZ4 backend and could benefit from an updated
LZ4 in the kernel.

LZ4 homepage: http://www.lz4.org/
LZ4 source repository: https://github.com/lz4/lz4
Source version: 1.7.3

Benchmark (taken from [1], Core i5-4300U @1.9GHz):
|--||--
Compressor  | Compression  | Decompression  | Ratio
|--||--
memcpy  |  4200 MB/s   |  4200 MB/s | 1.000
LZ4 fast 50 |  1080 MB/s   |  2650 MB/s | 1.375
LZ4 fast 17 |   680 MB/s   |  2220 MB/s | 1.607
LZ4 fast 5  |   475 MB/s   |  1920 MB/s | 1.886
LZ4 default |   385 MB/s   |  1850 MB/s | 2.101

[1] http://fastcompression.blogspot.de/2015/04/sampling-or-faster-lz4.html
fs/pstore: fs/squashfs: Change usage of LZ4 to work with new LZ4 version

[PATCH 1/5] lib: Update LZ4 compressor module
[PATCH 2/5] lib/decompress_unlz4: Change module to work with new LZ4 module 
version
[PATCH 3/5] crypto: Change LZ4 modules to work with new LZ4 module version
[PATCH 4/5] fs/pstore: fs/squashfs: Change usage of LZ4 to work with new LZ4 
version
[PATCH 5/5] lib/lz4: Remove back-compat wrappers

v2:
- Changed order of the patches since in the initial patchset the lz4.h was in 
the
  last patch but was referenced by the other ones
- Split lib/decompress_unlz4.c in an own patch
- Fixed errors reported by the buildbot
- Further refactorings
- Added more appropriate copyright note to include/linux/lz4.h

v3:
- Adjusted the code to satisfy kernel coding style (checkpatch.pl)
- Made sure the changes to LZ4 in Kernel (overflow checks etc.)
  are included in the new module (they are)
- Removed the second LZ4_compressBound function with related name but
  different return type
- Corrected version number (was LZ4 1.7.3)
- Added missing LZ4 streaming functions

v4:
- Fixed kbuild errors
- Re-added lz4_compressbound as alias for LZ4_compressBound
  to ensure backwards compatibility
- Wrapped LZ4_hash5 with check for LZ4_ARCH64 since it is only used there
  and triggers an unused function warning when false

v5:
- Added a fifth patch to remove the back-compat wrappers introduced
  to ensure bisectibility between the patches (the functions are no longer
  needed since there's no callers left)

[PATCH v5 0/5] Update LZ4 compressor module

[Sven Schmidt]

This patchset is for updating the LZ4 compression module to a version based
on LZ4 v1.7.3 allowing to use the fast compression algorithm aka LZ4 fast
which provides an "acceleration" parameter as a tradeoff between
high compression ratio and high compression speed.

We want to use LZ4 fast in order to support compression in lustre
and (mostly, based on that) investigate data reduction techniques in behalf of
storage systems.

Also, it will be useful for other users of LZ4 compression, as with LZ4 fast
it is possible to enable applications to use fast and/or high compression
depending on the usecase.
For instance, ZRAM is offering a LZ4 backend and could benefit from an updated
LZ4 in the kernel.

LZ4 homepage: http://www.lz4.org/
LZ4 source repository: https://github.com/lz4/lz4
Source version: 1.7.3

Benchmark (taken from [1], Core i5-4300U @1.9GHz):
|--||--
Compressor  | Compression  | Decompression  | Ratio
|--||--
memcpy  |  4200 MB/s   |  4200 MB/s | 1.000
LZ4 fast 50 |  1080 MB/s   |  2650 MB/s | 1.375
LZ4 fast 17 |   680 MB/s   |  2220 MB/s | 1.607
LZ4 fast 5  |   475 MB/s   |  1920 MB/s | 1.886
LZ4 default |   385 MB/s   |  1850 MB/s | 2.101

[1] http://fastcompression.blogspot.de/2015/04/sampling-or-faster-lz4.html
fs/pstore: fs/squashfs: Change usage of LZ4 to work with new LZ4 version

[PATCH 1/5] lib: Update LZ4 compressor module
[PATCH 2/5] lib/decompress_unlz4: Change module to work with new LZ4 module 
version
[PATCH 3/5] crypto: Change LZ4 modules to work with new LZ4 module version
[PATCH 4/5] fs/pstore: fs/squashfs: Change usage of LZ4 to work with new LZ4 
version
[PATCH 5/5] lib/lz4: Remove back-compat wrappers

v2:
- Changed order of the patches since in the initial patchset the lz4.h was in 
the
  last patch but was referenced by the other ones
- Split lib/decompress_unlz4.c in an own patch
- Fixed errors reported by the buildbot
- Further refactorings
- Added more appropriate copyright note to include/linux/lz4.h

v3:
- Adjusted the code to satisfy kernel coding style (checkpatch.pl)
- Made sure the changes to LZ4 in Kernel (overflow checks etc.)
  are included in the new module (they are)
- Removed the second LZ4_compressBound function with related name but
  different return type
- Corrected version number (was LZ4 1.7.3)
- Added missing LZ4 streaming functions

v4:
- Fixed kbuild errors
- Re-added lz4_compressbound as alias for LZ4_compressBound
  to ensure backwards compatibility
- Wrapped LZ4_hash5 with check for LZ4_ARCH64 since it is only used there
  and triggers an unused function warning when false

v5:
- Added a fifth patch to remove the back-compat wrappers introduced
  to ensure bisectibility between the patches (the functions are no longer
  needed since there's no callers left)

Re: [PATCH v5 01/13] lockdep: Refactor lookup_chain_cache()

[Byungchul Park]

I added a comment that you recommanded after modifying a bit, like the
following. Please let me know if the my sentence is rather awkward.

Thank you.

->8-
commit bb8ad95a4944eec6ab72e950ef063960791b0d8c
Author: Byungchul Park 
Date:   Tue Jan 24 16:44:16 2017 +0900

lockdep: Refactor lookup_chain_cache()

Currently, lookup_chain_cache() provides both 'lookup' and 'add'
functionalities in a function. However, each is useful. So this
patch makes lookup_chain_cache() only do 'lookup' functionality and
makes add_chain_cahce() only do 'add' functionality. And it's more
readable than before.

Signed-off-by: Byungchul Park 

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 4d7ffc0..0c6e6b7 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -2110,14 +2110,15 @@ static int check_no_collision(struct task_struct *curr,
 }
 
 /*
- * Look up a dependency chain. If the key is not present yet then
- * add it and return 1 - in this case the new dependency chain is
- * validated. If the key is already hashed, return 0.
- * (On return with 1 graph_lock is held.)
+ * Adds a dependency chain into chain hashtable. And must be called with
+ * graph_lock held.
+ *
+ * Return 0 if fail, and graph_lock is released.
+ * Return 1 if succeed, with graph_lock held.
  */
-static inline int lookup_chain_cache(struct task_struct *curr,
-struct held_lock *hlock,
-u64 chain_key)
+static inline int add_chain_cache(struct task_struct *curr,
+ struct held_lock *hlock,
+ u64 chain_key)
 {
struct lock_class *class = hlock_class(hlock);
struct hlist_head *hash_head = chainhashentry(chain_key);
@@ -2125,49 +2126,18 @@ static inline int lookup_chain_cache(struct task_struct 
*curr,
int i, j;
 
/*
+* Allocate a new chain entry from the static array, and add
+* it to the hash:
+*/
+
+   /*
 * We might need to take the graph lock, ensure we've got IRQs
 * disabled to make this an IRQ-safe lock.. for recursion reasons
 * lockdep won't complain about its own locking errors.
 */
if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
return 0;
-   /*
-* We can walk it lock-free, because entries only get added
-* to the hash:
-*/
-   hlist_for_each_entry_rcu(chain, hash_head, entry) {
-   if (chain->chain_key == chain_key) {
-cache_hit:
-   debug_atomic_inc(chain_lookup_hits);
-   if (!check_no_collision(curr, hlock, chain))
-   return 0;
 
-   if (very_verbose(class))
-   printk("\nhash chain already cached, key: "
-   "%016Lx tail class: [%p] %s\n",
-   (unsigned long long)chain_key,
-   class->key, class->name);
-   return 0;
-   }
-   }
-   if (very_verbose(class))
-   printk("\nnew hash chain, key: %016Lx tail class: [%p] %s\n",
-   (unsigned long long)chain_key, class->key, class->name);
-   /*
-* Allocate a new chain entry from the static array, and add
-* it to the hash:
-*/
-   if (!graph_lock())
-   return 0;
-   /*
-* We have to walk the chain again locked - to avoid duplicates:
-*/
-   hlist_for_each_entry(chain, hash_head, entry) {
-   if (chain->chain_key == chain_key) {
-   graph_unlock();
-   goto cache_hit;
-   }
-   }
if (unlikely(nr_lock_chains >= MAX_LOCKDEP_CHAINS)) {
if (!debug_locks_off_graph_unlock())
return 0;
@@ -2219,6 +2189,75 @@ static inline int lookup_chain_cache(struct task_struct 
*curr,
return 1;
 }
 
+/*
+ * Look up a dependency chain.
+ */
+static inline struct lock_chain *lookup_chain_cache(u64 chain_key)
+{
+   struct hlist_head *hash_head = chainhashentry(chain_key);
+   struct lock_chain *chain;
+
+   /*
+* We can walk it lock-free, because entries only get added
+* to the hash:
+*/
+   hlist_for_each_entry_rcu(chain, hash_head, entry) {
+   if (chain->chain_key == chain_key) {
+   debug_atomic_inc(chain_lookup_hits);
+   return chain;
+   }
+   }
+   return NULL;
+}
+
+/*
+ * If the key is not present yet in dependency chain cache then
+ * add it and return 1 - in this case the new dependency chain is
+ * validated. If the key is already hashed, return 0.
+ * (On return with 1 graph_lock is held.)
+ */
+static 

Re: [PATCH v5 01/13] lockdep: Refactor lookup_chain_cache()

[Byungchul Park]

I added a comment that you recommanded after modifying a bit, like the
following. Please let me know if the my sentence is rather awkward.

Thank you.

->8-
commit bb8ad95a4944eec6ab72e950ef063960791b0d8c
Author: Byungchul Park 
Date:   Tue Jan 24 16:44:16 2017 +0900

lockdep: Refactor lookup_chain_cache()

Currently, lookup_chain_cache() provides both 'lookup' and 'add'
functionalities in a function. However, each is useful. So this
patch makes lookup_chain_cache() only do 'lookup' functionality and
makes add_chain_cahce() only do 'add' functionality. And it's more
readable than before.

Signed-off-by: Byungchul Park 

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 4d7ffc0..0c6e6b7 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -2110,14 +2110,15 @@ static int check_no_collision(struct task_struct *curr,
 }
 
 /*
- * Look up a dependency chain. If the key is not present yet then
- * add it and return 1 - in this case the new dependency chain is
- * validated. If the key is already hashed, return 0.
- * (On return with 1 graph_lock is held.)
+ * Adds a dependency chain into chain hashtable. And must be called with
+ * graph_lock held.
+ *
+ * Return 0 if fail, and graph_lock is released.
+ * Return 1 if succeed, with graph_lock held.
  */
-static inline int lookup_chain_cache(struct task_struct *curr,
-struct held_lock *hlock,
-u64 chain_key)
+static inline int add_chain_cache(struct task_struct *curr,
+ struct held_lock *hlock,
+ u64 chain_key)
 {
struct lock_class *class = hlock_class(hlock);
struct hlist_head *hash_head = chainhashentry(chain_key);
@@ -2125,49 +2126,18 @@ static inline int lookup_chain_cache(struct task_struct 
*curr,
int i, j;
 
/*
+* Allocate a new chain entry from the static array, and add
+* it to the hash:
+*/
+
+   /*
 * We might need to take the graph lock, ensure we've got IRQs
 * disabled to make this an IRQ-safe lock.. for recursion reasons
 * lockdep won't complain about its own locking errors.
 */
if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
return 0;
-   /*
-* We can walk it lock-free, because entries only get added
-* to the hash:
-*/
-   hlist_for_each_entry_rcu(chain, hash_head, entry) {
-   if (chain->chain_key == chain_key) {
-cache_hit:
-   debug_atomic_inc(chain_lookup_hits);
-   if (!check_no_collision(curr, hlock, chain))
-   return 0;
 
-   if (very_verbose(class))
-   printk("\nhash chain already cached, key: "
-   "%016Lx tail class: [%p] %s\n",
-   (unsigned long long)chain_key,
-   class->key, class->name);
-   return 0;
-   }
-   }
-   if (very_verbose(class))
-   printk("\nnew hash chain, key: %016Lx tail class: [%p] %s\n",
-   (unsigned long long)chain_key, class->key, class->name);
-   /*
-* Allocate a new chain entry from the static array, and add
-* it to the hash:
-*/
-   if (!graph_lock())
-   return 0;
-   /*
-* We have to walk the chain again locked - to avoid duplicates:
-*/
-   hlist_for_each_entry(chain, hash_head, entry) {
-   if (chain->chain_key == chain_key) {
-   graph_unlock();
-   goto cache_hit;
-   }
-   }
if (unlikely(nr_lock_chains >= MAX_LOCKDEP_CHAINS)) {
if (!debug_locks_off_graph_unlock())
return 0;
@@ -2219,6 +2189,75 @@ static inline int lookup_chain_cache(struct task_struct 
*curr,
return 1;
 }
 
+/*
+ * Look up a dependency chain.
+ */
+static inline struct lock_chain *lookup_chain_cache(u64 chain_key)
+{
+   struct hlist_head *hash_head = chainhashentry(chain_key);
+   struct lock_chain *chain;
+
+   /*
+* We can walk it lock-free, because entries only get added
+* to the hash:
+*/
+   hlist_for_each_entry_rcu(chain, hash_head, entry) {
+   if (chain->chain_key == chain_key) {
+   debug_atomic_inc(chain_lookup_hits);
+   return chain;
+   }
+   }
+   return NULL;
+}
+
+/*
+ * If the key is not present yet in dependency chain cache then
+ * add it and return 1 - in this case the new dependency chain is
+ * validated. If the key is already hashed, return 0.
+ * (On return with 1 graph_lock is held.)
+ */
+static inline int lookup_chain_cache_add(struct 

Re: [PATCH] Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()

[gre...@linuxfoundation.org]

On Thu, Jan 26, 2017 at 07:44:46AM +, Dexuan Cui wrote:
> > From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
> > > Dexuan Cui  wrote:
> > > As I checked against the kernels listed on the homapage,
> > > the below versions are impacted:
> > > v3.16.39
> > > v3.18.47
> > > v4.1.38
> > > v4.8.17
> > > v4.9.5
> > > v4.10-rc5
> > >
> > > It's interesting v4.4.44 is not impacted, but actually it needs both the 
> > > 2 patches:
> > > i.e. this patch, and the previous one:
> > > Commit a389fcfd2cb5 ("Drivers: hv: vmbus: Fix signaling logic in
> > hv_need_to_signal_on_read()")
> > 
> > That patch does not apply to the 4.4-stable tree, which is why it was
> > not included there.  If you feel it should be included, please provide a
> > backport and send it to the sta...@vger.kernel.org mailing list.
> > 
> > greg k-h
> 
> Thanks! I'll do the backport after this patch goes in the mainline.

Why wait?

Re: [PATCH] Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()

[gre...@linuxfoundation.org]

On Thu, Jan 26, 2017 at 07:44:46AM +, Dexuan Cui wrote:
> > From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
> > > Dexuan Cui  wrote:
> > > As I checked against the kernels listed on the homapage,
> > > the below versions are impacted:
> > > v3.16.39
> > > v3.18.47
> > > v4.1.38
> > > v4.8.17
> > > v4.9.5
> > > v4.10-rc5
> > >
> > > It's interesting v4.4.44 is not impacted, but actually it needs both the 
> > > 2 patches:
> > > i.e. this patch, and the previous one:
> > > Commit a389fcfd2cb5 ("Drivers: hv: vmbus: Fix signaling logic in
> > hv_need_to_signal_on_read()")
> > 
> > That patch does not apply to the 4.4-stable tree, which is why it was
> > not included there.  If you feel it should be included, please provide a
> > backport and send it to the sta...@vger.kernel.org mailing list.
> > 
> > greg k-h
> 
> Thanks! I'll do the backport after this patch goes in the mainline.

Why wait?

Linux 4.4.45

[Greg KH]

I'm announcing the release of the 4.4.45 kernel.

All users of the 4.4 kernel series must upgrade.

The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/devicetree/bindings/clock/imx31-clock.txt   |2 
 Makefile  |2 
 arch/arm/boot/dts/da850-evm.dts   |1 
 arch/arm/boot/dts/imx31.dtsi  |   18 +--
 arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi  |4 
 arch/arm/include/asm/cputype.h|3 
 arch/arm/kernel/hw_breakpoint.c   |   16 ++
 arch/arm/kernel/smp_tlb.c |7 +
 arch/arm/mach-ux500/pm.c  |4 
 arch/arm64/include/uapi/asm/ptrace.h  |1 
 arch/arm64/kernel/entry.S |2 
 arch/arm64/kernel/ptrace.c|   16 +-
 arch/arm64/kernel/traps.c |   28 
 arch/x86/kernel/apic/io_apic.c|2 
 arch/x86/kernel/mcount_64.S   |3 
 arch/x86/pci/acpi.c   |   10 +
 drivers/clocksource/exynos_mct.c  |1 
 drivers/dma/pl330.c   |   11 +
 drivers/hid/hid-corsair.c |   60 +++---
 drivers/infiniband/hw/mlx4/ah.c   |6 -
 drivers/infiniband/hw/mlx4/main.c |   29 +++-
 drivers/infiniband/hw/mlx4/qp.c   |3 
 drivers/infiniband/hw/mlx5/mr.c   |   28 
 drivers/infiniband/ulp/ipoib/ipoib_cm.c   |2 
 drivers/media/platform/blackfin/ppi.c |2 
 drivers/media/rc/ite-cir.c|2 
 drivers/mmc/host/mxs-mmc.c|6 -
 drivers/mtd/nand/Kconfig  |2 
 drivers/net/ieee802154/atusb.c|   31 -
 drivers/pci/probe.c   |   12 +-
 drivers/scsi/qla2xxx/qla_os.c |   16 ++
 fs/ceph/mds_client.c  |9 -
 fs/fuse/dev.c |3 
 fs/posix_acl.c|9 -
 fs/ubifs/tnc.c|   25 +++-
 net/sunrpc/auth_gss/svcauth_gss.c |2 
 net/sunrpc/xprtrdma/svc_rdma_recvfrom.c   |2 
 tools/perf/util/trace-event-scripting.c   |6 -
 tools/testing/selftests/powerpc/pmu/ebb/pmc56_overflow_test.c |2 
 39 files changed, 297 insertions(+), 91 deletions(-)

Arnaldo Carvalho de Melo (1):
  perf scripting: Avoid leaking the scripting_context variable

Arnd Bergmann (1):
  ARM: ux500: fix prcmu_is_cpu_in_wfi() calculation

Bjorn Helgaas (2):
  x86/PCI: Ignore _CRS on Supermicro X8DTH-i/6/iF/6F
  PCI: Enumerate switches below PCI-to-PCIe bridges

Dan Carpenter (1):
  blackfin: check devm_pinctrl_get() for errors

Dave Martin (5):
  arm64/ptrace: Preserve previous registers for short regset write
  arm64/ptrace: Preserve previous registers for short regset write - 2
  arm64/ptrace: Preserve previous registers for short regset write - 3
  arm64/ptrace: Avoid uninitialised struct padding in fpr_set()
  arm64/ptrace: Reject attempts to set incomplete hardware breakpoint fields

Eli Cohen (1):
  IB/mlx5: Wait for all async command completions to complete

Eran Ben Elisha (1):
  IB/mlx4: When no DMFS for IPoIB, don't allow NET_IF QPs

Fabien Parent (1):
  ARM: dts: da850-evm: fix read access to SPI flash

Gary Bisson (1):
  ARM: dts: imx6qdl-nitrogen6_max: fix sgtl5000 pinctrl init

Greg Kroah-Hartman (1):
  Linux 4.4.45

Gu Zheng (1):
  tmpfs: clear S_ISGID when setting posix ACLs

Hauke Mehrtens (1):
  mtd: nand: xway: disable module support

J. Bruce Fields (1):
  svcrpc: don't leak contexts on PROC_DESTROY

Jack Morgenstein (1):
  IB/mlx4: Fix out-of-range array index in destroy qp flow

Jeff Layton (1):
  ceph: fix bad endianness handling in parse_reply_info_extra

Johan Hovold (2):
  HID: corsair: fix DMA buffers on stack
  HID: corsair: fix control-transfer error handling

Joonyoung Shim (1):
  clocksource/exynos_mct: Clear interrupt when cpu is 

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

[Lu Baolu]

Hi Ingo,

On 01/26/2017 03:19 PM, Ingo Molnar wrote:
> * Lu Baolu  wrote:
>
>> Fair enough.
>>
>> USB connection is stable enough, unless the user unplugs the
>> USB cable during debugging.
> What does the hardware do in this case? The XHCI registers are in the host 
> hardware, so they won't disappear, right? Is there some cable connection 
> status 
> bit we can extract without interrupts?

Yes, there are register bits for us to know the cable status. I will go
through the spec again and give you more accurate answer later.

I'm sorry. I will be off during the next 7 days for Chinese New Year
holiday. My email access will be very limited during this time. I will
revisit this thread after I am back from holiday.

Sorry for the inconvenience.

Best regards,
Lu Baolu

> I.e. if there's any polling component then it would be reasonable to add an 
> error 
> component: poll the status and if it goes 'disconnected' then disable 
> early-printk 
> altogether in this case and trigger an emergency printk() so that there's 
> chance 
> that the user notices [if the system does not misbehave otherwise].
>
> I.e. try to be as robust and informative as lockdep - yet don't lock up the 
> host 
> kernel: lockdep too is called from very deep internals, there are various 
> conditions where it sees corrupt data structures (i.e. a 'disconnect' - a 
> system 
> environment outside the normal bounds of operation), yet of the kernel and 
> over 
> the last 10+ years of lockdep's existence we had very, very few cases of 
> lockdep 
> itself locking up and behaving unpredictably.
>
> Thanks,
>
>   Ingo
>

Linux 4.4.45

[Greg KH]

I'm announcing the release of the 4.4.45 kernel.

All users of the 4.4 kernel series must upgrade.

The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/devicetree/bindings/clock/imx31-clock.txt   |2 
 Makefile  |2 
 arch/arm/boot/dts/da850-evm.dts   |1 
 arch/arm/boot/dts/imx31.dtsi  |   18 +--
 arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi  |4 
 arch/arm/include/asm/cputype.h|3 
 arch/arm/kernel/hw_breakpoint.c   |   16 ++
 arch/arm/kernel/smp_tlb.c |7 +
 arch/arm/mach-ux500/pm.c  |4 
 arch/arm64/include/uapi/asm/ptrace.h  |1 
 arch/arm64/kernel/entry.S |2 
 arch/arm64/kernel/ptrace.c|   16 +-
 arch/arm64/kernel/traps.c |   28 
 arch/x86/kernel/apic/io_apic.c|2 
 arch/x86/kernel/mcount_64.S   |3 
 arch/x86/pci/acpi.c   |   10 +
 drivers/clocksource/exynos_mct.c  |1 
 drivers/dma/pl330.c   |   11 +
 drivers/hid/hid-corsair.c |   60 +++---
 drivers/infiniband/hw/mlx4/ah.c   |6 -
 drivers/infiniband/hw/mlx4/main.c |   29 +++-
 drivers/infiniband/hw/mlx4/qp.c   |3 
 drivers/infiniband/hw/mlx5/mr.c   |   28 
 drivers/infiniband/ulp/ipoib/ipoib_cm.c   |2 
 drivers/media/platform/blackfin/ppi.c |2 
 drivers/media/rc/ite-cir.c|2 
 drivers/mmc/host/mxs-mmc.c|6 -
 drivers/mtd/nand/Kconfig  |2 
 drivers/net/ieee802154/atusb.c|   31 -
 drivers/pci/probe.c   |   12 +-
 drivers/scsi/qla2xxx/qla_os.c |   16 ++
 fs/ceph/mds_client.c  |9 -
 fs/fuse/dev.c |3 
 fs/posix_acl.c|9 -
 fs/ubifs/tnc.c|   25 +++-
 net/sunrpc/auth_gss/svcauth_gss.c |2 
 net/sunrpc/xprtrdma/svc_rdma_recvfrom.c   |2 
 tools/perf/util/trace-event-scripting.c   |6 -
 tools/testing/selftests/powerpc/pmu/ebb/pmc56_overflow_test.c |2 
 39 files changed, 297 insertions(+), 91 deletions(-)

Arnaldo Carvalho de Melo (1):
  perf scripting: Avoid leaking the scripting_context variable

Arnd Bergmann (1):
  ARM: ux500: fix prcmu_is_cpu_in_wfi() calculation

Bjorn Helgaas (2):
  x86/PCI: Ignore _CRS on Supermicro X8DTH-i/6/iF/6F
  PCI: Enumerate switches below PCI-to-PCIe bridges

Dan Carpenter (1):
  blackfin: check devm_pinctrl_get() for errors

Dave Martin (5):
  arm64/ptrace: Preserve previous registers for short regset write
  arm64/ptrace: Preserve previous registers for short regset write - 2
  arm64/ptrace: Preserve previous registers for short regset write - 3
  arm64/ptrace: Avoid uninitialised struct padding in fpr_set()
  arm64/ptrace: Reject attempts to set incomplete hardware breakpoint fields

Eli Cohen (1):
  IB/mlx5: Wait for all async command completions to complete

Eran Ben Elisha (1):
  IB/mlx4: When no DMFS for IPoIB, don't allow NET_IF QPs

Fabien Parent (1):
  ARM: dts: da850-evm: fix read access to SPI flash

Gary Bisson (1):
  ARM: dts: imx6qdl-nitrogen6_max: fix sgtl5000 pinctrl init

Greg Kroah-Hartman (1):
  Linux 4.4.45

Gu Zheng (1):
  tmpfs: clear S_ISGID when setting posix ACLs

Hauke Mehrtens (1):
  mtd: nand: xway: disable module support

J. Bruce Fields (1):
  svcrpc: don't leak contexts on PROC_DESTROY

Jack Morgenstein (1):
  IB/mlx4: Fix out-of-range array index in destroy qp flow

Jeff Layton (1):
  ceph: fix bad endianness handling in parse_reply_info_extra

Johan Hovold (2):
  HID: corsair: fix DMA buffers on stack
  HID: corsair: fix control-transfer error handling

Joonyoung Shim (1):
  clocksource/exynos_mct: Clear interrupt when cpu is 

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

[Lu Baolu]

Hi Ingo,

On 01/26/2017 03:19 PM, Ingo Molnar wrote:
> * Lu Baolu  wrote:
>
>> Fair enough.
>>
>> USB connection is stable enough, unless the user unplugs the
>> USB cable during debugging.
> What does the hardware do in this case? The XHCI registers are in the host 
> hardware, so they won't disappear, right? Is there some cable connection 
> status 
> bit we can extract without interrupts?

Yes, there are register bits for us to know the cable status. I will go
through the spec again and give you more accurate answer later.

I'm sorry. I will be off during the next 7 days for Chinese New Year
holiday. My email access will be very limited during this time. I will
revisit this thread after I am back from holiday.

Sorry for the inconvenience.

Best regards,
Lu Baolu

> I.e. if there's any polling component then it would be reasonable to add an 
> error 
> component: poll the status and if it goes 'disconnected' then disable 
> early-printk 
> altogether in this case and trigger an emergency printk() so that there's 
> chance 
> that the user notices [if the system does not misbehave otherwise].
>
> I.e. try to be as robust and informative as lockdep - yet don't lock up the 
> host 
> kernel: lockdep too is called from very deep internals, there are various 
> conditions where it sees corrupt data structures (i.e. a 'disconnect' - a 
> system 
> environment outside the normal bounds of operation), yet of the kernel and 
> over 
> the last 10+ years of lockdep's existence we had very, very few cases of 
> lockdep 
> itself locking up and behaving unpredictably.
>
> Thanks,
>
>   Ingo
>

4.10-rc5+ WARNING: CPU: 3 PID: 1 at ./include/drm/drm_crtc.h:857 drm_kms_helper_poll_enable.part.4+0xa8/0xc0

[Borislav Petkov]

Hi all,

I see this brand new warning when booting here.

Top commit is v4.10-rc5-107-g883af14e67e8 from Linus' master.

[2.209255] [drm] Initialized
[2.210636] [drm] Memory usable by graphics device = 2048M
[2.210732] [drm] Replacing VGA console driver
[2.211517] Console: switching to colour dummy device 80x25
[2.218452] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[2.218471] [drm] Driver supports precise vblank timestamp query.
[2.219510] i915 :00:02.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=io+mem:owns=io+mem
[2.297687] [ cut here ]
[2.297714] WARNING: CPU: 3 PID: 1 at ./include/drm/drm_crtc.h:857 
drm_kms_helper_poll_enable.part.4+0xa8/0xc0
[2.297732] Modules linked in:
[2.297745] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc5+ #1
[2.297757] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) 
11/13/2012
[2.297772] Call Trace:
[2.297787]  dump_stack+0x67/0x92
[2.297801]  __warn+0xcb/0xf0
[2.297812]  warn_slowpath_null+0x1d/0x20
[2.297824]  drm_kms_helper_poll_enable.part.4+0xa8/0xc0
[2.297837]  drm_kms_helper_poll_init+0xaa/0xb0
[2.297851]  i915_driver_load+0x1384/0x1430
[2.297864]  i915_pci_probe+0x2d/0x50
[2.297876]  local_pci_probe+0x42/0xa0
[2.297888]  ? pci_match_device+0xe0/0x110
[2.297900]  pci_device_probe+0xdb/0x130
[2.297915]  driver_probe_device+0x204/0x2e0
[2.297927]  __driver_attach+0x9f/0xb0
[2.297938]  ? driver_probe_device+0x2e0/0x2e0
[2.297950]  bus_for_each_dev+0x66/0xa0
[2.297961]  driver_attach+0x1e/0x20
[2.297972]  bus_add_driver+0x1b4/0x230
[2.297986]  ? mipi_dsi_bus_init+0x12/0x12
[2.297998]  driver_register+0x60/0xe0
[2.298009]  ? mipi_dsi_bus_init+0x12/0x12
[2.298020]  __pci_register_driver+0x5d/0x60
[2.298032]  i915_init+0x52/0x55
[2.298045]  do_one_initcall+0x53/0x1a0
[2.298057]  ? parse_args+0x260/0x3e0
[2.298071]  kernel_init_freeable+0x11d/0x1a3
[2.298084]  ? rest_init+0x140/0x140
[2.298094]  kernel_init+0xe/0x100
[2.298104]  ret_from_fork+0x2e/0x40
[2.298120] ---[ end trace a758b84f8e587539 ]---
[2.302699] ACPI: Video Device [VID] (multi-head: yes  rom: no  post: no)
[2.304017] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input3
[2.304287] [drm] Initialized i915 1.6.0 20161121 for :00:02.0 on minor 0


-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

4.10-rc5+ WARNING: CPU: 3 PID: 1 at ./include/drm/drm_crtc.h:857 drm_kms_helper_poll_enable.part.4+0xa8/0xc0

[Borislav Petkov]

Hi all,

I see this brand new warning when booting here.

Top commit is v4.10-rc5-107-g883af14e67e8 from Linus' master.

[2.209255] [drm] Initialized
[2.210636] [drm] Memory usable by graphics device = 2048M
[2.210732] [drm] Replacing VGA console driver
[2.211517] Console: switching to colour dummy device 80x25
[2.218452] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[2.218471] [drm] Driver supports precise vblank timestamp query.
[2.219510] i915 :00:02.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=io+mem:owns=io+mem
[2.297687] [ cut here ]
[2.297714] WARNING: CPU: 3 PID: 1 at ./include/drm/drm_crtc.h:857 
drm_kms_helper_poll_enable.part.4+0xa8/0xc0
[2.297732] Modules linked in:
[2.297745] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc5+ #1
[2.297757] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) 
11/13/2012
[2.297772] Call Trace:
[2.297787]  dump_stack+0x67/0x92
[2.297801]  __warn+0xcb/0xf0
[2.297812]  warn_slowpath_null+0x1d/0x20
[2.297824]  drm_kms_helper_poll_enable.part.4+0xa8/0xc0
[2.297837]  drm_kms_helper_poll_init+0xaa/0xb0
[2.297851]  i915_driver_load+0x1384/0x1430
[2.297864]  i915_pci_probe+0x2d/0x50
[2.297876]  local_pci_probe+0x42/0xa0
[2.297888]  ? pci_match_device+0xe0/0x110
[2.297900]  pci_device_probe+0xdb/0x130
[2.297915]  driver_probe_device+0x204/0x2e0
[2.297927]  __driver_attach+0x9f/0xb0
[2.297938]  ? driver_probe_device+0x2e0/0x2e0
[2.297950]  bus_for_each_dev+0x66/0xa0
[2.297961]  driver_attach+0x1e/0x20
[2.297972]  bus_add_driver+0x1b4/0x230
[2.297986]  ? mipi_dsi_bus_init+0x12/0x12
[2.297998]  driver_register+0x60/0xe0
[2.298009]  ? mipi_dsi_bus_init+0x12/0x12
[2.298020]  __pci_register_driver+0x5d/0x60
[2.298032]  i915_init+0x52/0x55
[2.298045]  do_one_initcall+0x53/0x1a0
[2.298057]  ? parse_args+0x260/0x3e0
[2.298071]  kernel_init_freeable+0x11d/0x1a3
[2.298084]  ? rest_init+0x140/0x140
[2.298094]  kernel_init+0xe/0x100
[2.298104]  ret_from_fork+0x2e/0x40
[2.298120] ---[ end trace a758b84f8e587539 ]---
[2.302699] ACPI: Video Device [VID] (multi-head: yes  rom: no  post: no)
[2.304017] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input3
[2.304287] [drm] Initialized i915 1.6.0 20161121 for :00:02.0 on minor 0


-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: Linux 4.9.6

[Greg KH]

diff --git a/Documentation/devicetree/bindings/clock/imx31-clock.txt 
b/Documentation/devicetree/bindings/clock/imx31-clock.txt
index 19df842c694f..8163d565f697 100644
--- a/Documentation/devicetree/bindings/clock/imx31-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx31-clock.txt
@@ -77,7 +77,7 @@ Examples:
 clks: ccm@53f8{
compatible = "fsl,imx31-ccm";
reg = <0x53f8 0x4000>;
-   interrupts = <0 31 0x04 0 53 0x04>;
+   interrupts = <31>, <53>;
#clock-cells = <1>;
 };
 
diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 37babf91f2cb..922dec8fa07e 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3998,10 +3998,11 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
it if 0 is given (See 
Documentation/cgroup-v1/memory.txt)
 
swiotlb=[ARM,IA-64,PPC,MIPS,X86]
-   Format: {  | force }
+   Format: {  | force | noforce }
 -- Number of I/O TLB slabs
force -- force using of bounce buffers even if they
 wouldn't be automatically used by the kernel
+   noforce -- Never use bounce buffers (for debugging)
 
switches=   [HW,M68k]
 
diff --git a/Makefile b/Makefile
index 2a8af8af7b27..ef95231d1625 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 9
-SUBLEVEL = 5
+SUBLEVEL = 6
 EXTRAVERSION =
 NAME = Roaring Lionus
 
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index bd204bfa29ed..249e10190d20 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -28,7 +28,7 @@ config ARC
select HAVE_KPROBES
select HAVE_KRETPROBES
select HAVE_MEMBLOCK
-   select HAVE_MOD_ARCH_SPECIFIC if ARC_DW2_UNWIND
+   select HAVE_MOD_ARCH_SPECIFIC
select HAVE_OPROFILE
select HAVE_PERF_EVENTS
select HANDLE_DOMAIN_IRQ
diff --git a/arch/arc/include/asm/module.h b/arch/arc/include/asm/module.h
index 6e91d8b339c3..567590ea8f6c 100644
--- a/arch/arc/include/asm/module.h
+++ b/arch/arc/include/asm/module.h
@@ -14,13 +14,13 @@
 
 #include 
 
-#ifdef CONFIG_ARC_DW2_UNWIND
 struct mod_arch_specific {
+#ifdef CONFIG_ARC_DW2_UNWIND
void *unw_info;
int unw_sec_idx;
+#endif
const char *secstr;
 };
-#endif
 
 #define MODULE_PROC_FAMILY "ARC700"
 
diff --git a/arch/arc/kernel/module.c b/arch/arc/kernel/module.c
index 42e964db2967..3d99a6091332 100644
--- a/arch/arc/kernel/module.c
+++ b/arch/arc/kernel/module.c
@@ -32,8 +32,8 @@ int module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr 
*sechdrs,
 #ifdef CONFIG_ARC_DW2_UNWIND
mod->arch.unw_sec_idx = 0;
mod->arch.unw_info = NULL;
-   mod->arch.secstr = secstr;
 #endif
+   mod->arch.secstr = secstr;
return 0;
 }
 
@@ -113,8 +113,10 @@ int apply_relocate_add(Elf32_Shdr *sechdrs,
 
}
 
+#ifdef CONFIG_ARC_DW2_UNWIND
if (strcmp(module->arch.secstr+sechdrs[tgtsec].sh_name, ".eh_frame") == 
0)
module->arch.unw_sec_idx = tgtsec;
+#endif
 
return 0;
 
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c558ba75cbcc..7037201c5e3a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -485,6 +485,7 @@ dtb-$(CONFIG_ARCH_OMAP3) += \
am3517-evm.dtb \
am3517_mt_ventoux.dtb \
logicpd-torpedo-37xx-devkit.dtb \
+   logicpd-som-lv-37xx-devkit.dtb \
omap3430-sdp.dtb \
omap3-beagle.dtb \
omap3-beagle-xm.dtb \
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 194d884c9de1..795c1467fa50 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -16,6 +16,7 @@
interrupt-parent = <>;
#address-cells = <1>;
#size-cells = <1>;
+   chosen { };
 
aliases {
i2c0 = 
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index a275fa956813..a20a71d9d22e 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -16,6 +16,7 @@
interrupt-parent = <>;
#address-cells = <1>;
#size-cells = <1>;
+   chosen { };
 
memory@0 {
device_type = "memory";
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 46d46d894a44..74dd21b7373c 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -104,7 +104,7 @@
reg = <0x7e104000 0x10>;
};
 
-   mailbox: mailbox@7e00b800 {
+   mailbox: mailbox@7e00b880 {
compatible = "brcm,bcm2835-mbox";
reg = <0x7e00b880 0x40>;
interrupts = <0 1>;
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts

Re: Linux 4.9.6

[Greg KH]

diff --git a/Documentation/devicetree/bindings/clock/imx31-clock.txt 
b/Documentation/devicetree/bindings/clock/imx31-clock.txt
index 19df842c694f..8163d565f697 100644
--- a/Documentation/devicetree/bindings/clock/imx31-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx31-clock.txt
@@ -77,7 +77,7 @@ Examples:
 clks: ccm@53f8{
compatible = "fsl,imx31-ccm";
reg = <0x53f8 0x4000>;
-   interrupts = <0 31 0x04 0 53 0x04>;
+   interrupts = <31>, <53>;
#clock-cells = <1>;
 };
 
diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 37babf91f2cb..922dec8fa07e 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3998,10 +3998,11 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
it if 0 is given (See 
Documentation/cgroup-v1/memory.txt)
 
swiotlb=[ARM,IA-64,PPC,MIPS,X86]
-   Format: {  | force }
+   Format: {  | force | noforce }
 -- Number of I/O TLB slabs
force -- force using of bounce buffers even if they
 wouldn't be automatically used by the kernel
+   noforce -- Never use bounce buffers (for debugging)
 
switches=   [HW,M68k]
 
diff --git a/Makefile b/Makefile
index 2a8af8af7b27..ef95231d1625 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 9
-SUBLEVEL = 5
+SUBLEVEL = 6
 EXTRAVERSION =
 NAME = Roaring Lionus
 
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index bd204bfa29ed..249e10190d20 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -28,7 +28,7 @@ config ARC
select HAVE_KPROBES
select HAVE_KRETPROBES
select HAVE_MEMBLOCK
-   select HAVE_MOD_ARCH_SPECIFIC if ARC_DW2_UNWIND
+   select HAVE_MOD_ARCH_SPECIFIC
select HAVE_OPROFILE
select HAVE_PERF_EVENTS
select HANDLE_DOMAIN_IRQ
diff --git a/arch/arc/include/asm/module.h b/arch/arc/include/asm/module.h
index 6e91d8b339c3..567590ea8f6c 100644
--- a/arch/arc/include/asm/module.h
+++ b/arch/arc/include/asm/module.h
@@ -14,13 +14,13 @@
 
 #include 
 
-#ifdef CONFIG_ARC_DW2_UNWIND
 struct mod_arch_specific {
+#ifdef CONFIG_ARC_DW2_UNWIND
void *unw_info;
int unw_sec_idx;
+#endif
const char *secstr;
 };
-#endif
 
 #define MODULE_PROC_FAMILY "ARC700"
 
diff --git a/arch/arc/kernel/module.c b/arch/arc/kernel/module.c
index 42e964db2967..3d99a6091332 100644
--- a/arch/arc/kernel/module.c
+++ b/arch/arc/kernel/module.c
@@ -32,8 +32,8 @@ int module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr 
*sechdrs,
 #ifdef CONFIG_ARC_DW2_UNWIND
mod->arch.unw_sec_idx = 0;
mod->arch.unw_info = NULL;
-   mod->arch.secstr = secstr;
 #endif
+   mod->arch.secstr = secstr;
return 0;
 }
 
@@ -113,8 +113,10 @@ int apply_relocate_add(Elf32_Shdr *sechdrs,
 
}
 
+#ifdef CONFIG_ARC_DW2_UNWIND
if (strcmp(module->arch.secstr+sechdrs[tgtsec].sh_name, ".eh_frame") == 
0)
module->arch.unw_sec_idx = tgtsec;
+#endif
 
return 0;
 
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c558ba75cbcc..7037201c5e3a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -485,6 +485,7 @@ dtb-$(CONFIG_ARCH_OMAP3) += \
am3517-evm.dtb \
am3517_mt_ventoux.dtb \
logicpd-torpedo-37xx-devkit.dtb \
+   logicpd-som-lv-37xx-devkit.dtb \
omap3430-sdp.dtb \
omap3-beagle.dtb \
omap3-beagle-xm.dtb \
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 194d884c9de1..795c1467fa50 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -16,6 +16,7 @@
interrupt-parent = <>;
#address-cells = <1>;
#size-cells = <1>;
+   chosen { };
 
aliases {
i2c0 = 
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index a275fa956813..a20a71d9d22e 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -16,6 +16,7 @@
interrupt-parent = <>;
#address-cells = <1>;
#size-cells = <1>;
+   chosen { };
 
memory@0 {
device_type = "memory";
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 46d46d894a44..74dd21b7373c 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -104,7 +104,7 @@
reg = <0x7e104000 0x10>;
};
 
-   mailbox: mailbox@7e00b800 {
+   mailbox: mailbox@7e00b880 {
compatible = "brcm,bcm2835-mbox";
reg = <0x7e00b880 0x40>;
interrupts = <0 1>;
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts

Re: Linux 4.4.45

[Greg KH]

diff --git a/Documentation/devicetree/bindings/clock/imx31-clock.txt 
b/Documentation/devicetree/bindings/clock/imx31-clock.txt
index 19df842c694f..8163d565f697 100644
--- a/Documentation/devicetree/bindings/clock/imx31-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx31-clock.txt
@@ -77,7 +77,7 @@ Examples:
 clks: ccm@53f8{
compatible = "fsl,imx31-ccm";
reg = <0x53f8 0x4000>;
-   interrupts = <0 31 0x04 0 53 0x04>;
+   interrupts = <31>, <53>;
#clock-cells = <1>;
 };
 
diff --git a/Makefile b/Makefile
index d6a1de0e2bd7..a3dfc73da722 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 4
-SUBLEVEL = 44
+SUBLEVEL = 45
 EXTRAVERSION =
 NAME = Blurry Fish Butt
 
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 4f935ad9f27b..6881757b03e8 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -85,6 +85,7 @@
#size-cells = <1>;
compatible = "m25p64";
spi-max-frequency = <3000>;
+   m25p,fast-read;
reg = <0>;
partition@0 {
label = "U-Boot-SPL";
diff --git a/arch/arm/boot/dts/imx31.dtsi b/arch/arm/boot/dts/imx31.dtsi
index 5fdb222636a7..cbe5fd5ed179 100644
--- a/arch/arm/boot/dts/imx31.dtsi
+++ b/arch/arm/boot/dts/imx31.dtsi
@@ -30,11 +30,11 @@
};
};
 
-   avic: avic-interrupt-controller@6000 {
+   avic: interrupt-controller@6800 {
compatible = "fsl,imx31-avic", "fsl,avic";
interrupt-controller;
#interrupt-cells = <1>;
-   reg = <0x6000 0x10>;
+   reg = <0x6800 0x10>;
};
 
soc {
@@ -110,13 +110,6 @@
interrupts = <19>;
clocks = < 25>;
};
-
-   clks: ccm@53f8{
-   compatible = "fsl,imx31-ccm";
-   reg = <0x53f8 0x4000>;
-   interrupts = <0 31 0x04 0 53 0x04>;
-   #clock-cells = <1>;
-   };
};
 
aips@53f0 { /* AIPS2 */
@@ -126,6 +119,13 @@
reg = <0x53f0 0x10>;
ranges;
 
+   clks: ccm@53f8{
+   compatible = "fsl,imx31-ccm";
+   reg = <0x53f8 0x4000>;
+   interrupts = <31>, <53>;
+   #clock-cells = <1>;
+   };
+
gpt: timer@53f9 {
compatible = "fsl,imx31-gpt";
reg = <0x53f9 0x4000>;
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi 
b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
index a35d54fd9cd3..ddfdb75a6e90 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
@@ -319,8 +319,6 @@
compatible = "fsl,imx6q-nitrogen6_max-sgtl5000",
 "fsl,imx-audio-sgtl5000";
model = "imx6q-nitrogen6_max-sgtl5000";
-   pinctrl-names = "default";
-   pinctrl-0 = <_sgtl5000>;
ssi-controller = <>;
audio-codec = <>;
audio-routing =
@@ -401,6 +399,8 @@
 
codec: sgtl5000@0a {
compatible = "fsl,sgtl5000";
+   pinctrl-names = "default";
+   pinctrl-0 = <_sgtl5000>;
reg = <0x0a>;
clocks = < 201>;
VDDA-supply = <_2p5v>;
diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 85e374f873ac..e9d04f475929 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -81,6 +81,9 @@
 #define ARM_CPU_XSCALE_ARCH_V2 0x4000
 #define ARM_CPU_XSCALE_ARCH_V3 0x6000
 
+/* Qualcomm implemented cores */
+#define ARM_CPU_PART_SCORPION  0x510002d0
+
 extern unsigned int processor_id;
 
 #ifdef CONFIG_CPU_CP15
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index 6284779d64ee..abcbea1ae30b 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -1066,6 +1066,22 @@ static int __init arch_hw_breakpoint_init(void)
return 0;
}
 
+   /*
+* Scorpion CPUs (at least those in APQ8060) seem to set DBGPRSR.SPD
+* whenever a WFI is issued, even if the core is not powered down, in
+* violation of the architecture.  When DBGPRSR.SPD is set, accesses to
+* breakpoint and watchpoint registers are treated as 

Linux 4.9.6

[Greg KH]

I'm announcing the release of the 4.9.6 kernel.

All users of the 4.9 kernel series must upgrade.

The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/devicetree/bindings/clock/imx31-clock.txt   |2 
 Documentation/kernel-parameters.txt   |3 
 Makefile  |2 
 arch/arc/Kconfig  |2 
 arch/arc/include/asm/module.h |4 
 arch/arc/kernel/module.c  |4 
 arch/arm/boot/dts/Makefile|1 
 arch/arm/boot/dts/am33xx.dtsi |1 
 arch/arm/boot/dts/am4372.dtsi |1 
 arch/arm/boot/dts/bcm283x.dtsi|2 
 arch/arm/boot/dts/da850-evm.dts   |1 
 arch/arm/boot/dts/dm814x.dtsi |1 
 arch/arm/boot/dts/dm816x.dtsi |1 
 arch/arm/boot/dts/dra7.dtsi   |2 
 arch/arm/boot/dts/imx31.dtsi  |   18 
 arch/arm/boot/dts/imx6q-cm-fx6.dts|1 
 arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi  |4 
 arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts  |   11 
 arch/arm/boot/dts/omap2.dtsi  |1 
 arch/arm/boot/dts/omap3.dtsi  |1 
 arch/arm/boot/dts/omap4.dtsi  |1 
 arch/arm/boot/dts/omap5.dtsi  |2 
 arch/arm/boot/dts/r8a7794.dtsi|7 
 arch/arm/include/asm/cputype.h|3 
 arch/arm/kernel/hw_breakpoint.c   |   16 
 arch/arm/kernel/smp_tlb.c |7 
 arch/arm/mach-ux500/pm.c  |4 
 arch/arm64/include/asm/memory.h   |2 
 arch/arm64/include/uapi/asm/ptrace.h  |1 
 arch/arm64/kernel/entry.S |2 
 arch/arm64/kernel/ptrace.c|   16 
 arch/arm64/kernel/traps.c |   28 
 arch/arm64/mm/dma-mapping.c   |3 
 arch/arm64/mm/init.c  |5 
 arch/powerpc/include/asm/ppc-opcode.h |   10 
 arch/powerpc/kernel/ptrace.c  |   14 
 arch/powerpc/perf/power9-events-list.h|2 
 arch/powerpc/sysdev/xics/icp-opal.c   |   31 
 arch/s390/kvm/kvm-s390.c  |4 
 arch/x86/kernel/apic/io_apic.c|2 
 arch/x86/kernel/pci-swiotlb.c |2 
 arch/x86/pci/acpi.c   |   10 
 arch/x86/xen/pci-swiotlb-xen.c|2 
 drivers/clocksource/exynos_mct.c  |1 
 drivers/devfreq/devfreq.c |   15 
 drivers/devfreq/exynos-bus.c  |2 
 drivers/dma/pl330.c   |   11 
 drivers/dma/sh/rcar-dmac.c|8 
 drivers/hid/hid-corsair.c |   60 -
 drivers/infiniband/core/cache.c   |   16 
 drivers/infiniband/hw/mlx4/ah.c   |6 
 drivers/infiniband/hw/mlx4/mad.c  |   16 
 drivers/infiniband/hw/mlx4/main.c |   29 
 drivers/infiniband/hw/mlx4/qp.c   |7 
 drivers/infiniband/hw/mlx5/main.c |8 
 drivers/infiniband/hw/mlx5/mr.c   |   31 
 drivers/infiniband/hw/mlx5/qp.c   |   29 
 drivers/infiniband/hw/mlx5/srq.c  |2 
 drivers/infiniband/sw/rxe/rxe_param.h |2 
 drivers/infiniband/sw/rxe/rxe_req.c   |   14 
 drivers/infiniband/ulp/ipoib/ipoib_cm.c   |2 
 drivers/input/mouse/alps.c|   19 
 drivers/media/platform/Kconfig|2 
 drivers/media/platform/blackfin/ppi.c |2 
 

Linux 4.9.6

[Greg KH]

I'm announcing the release of the 4.9.6 kernel.

All users of the 4.9 kernel series must upgrade.

The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/devicetree/bindings/clock/imx31-clock.txt   |2 
 Documentation/kernel-parameters.txt   |3 
 Makefile  |2 
 arch/arc/Kconfig  |2 
 arch/arc/include/asm/module.h |4 
 arch/arc/kernel/module.c  |4 
 arch/arm/boot/dts/Makefile|1 
 arch/arm/boot/dts/am33xx.dtsi |1 
 arch/arm/boot/dts/am4372.dtsi |1 
 arch/arm/boot/dts/bcm283x.dtsi|2 
 arch/arm/boot/dts/da850-evm.dts   |1 
 arch/arm/boot/dts/dm814x.dtsi |1 
 arch/arm/boot/dts/dm816x.dtsi |1 
 arch/arm/boot/dts/dra7.dtsi   |2 
 arch/arm/boot/dts/imx31.dtsi  |   18 
 arch/arm/boot/dts/imx6q-cm-fx6.dts|1 
 arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi  |4 
 arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts  |   11 
 arch/arm/boot/dts/omap2.dtsi  |1 
 arch/arm/boot/dts/omap3.dtsi  |1 
 arch/arm/boot/dts/omap4.dtsi  |1 
 arch/arm/boot/dts/omap5.dtsi  |2 
 arch/arm/boot/dts/r8a7794.dtsi|7 
 arch/arm/include/asm/cputype.h|3 
 arch/arm/kernel/hw_breakpoint.c   |   16 
 arch/arm/kernel/smp_tlb.c |7 
 arch/arm/mach-ux500/pm.c  |4 
 arch/arm64/include/asm/memory.h   |2 
 arch/arm64/include/uapi/asm/ptrace.h  |1 
 arch/arm64/kernel/entry.S |2 
 arch/arm64/kernel/ptrace.c|   16 
 arch/arm64/kernel/traps.c |   28 
 arch/arm64/mm/dma-mapping.c   |3 
 arch/arm64/mm/init.c  |5 
 arch/powerpc/include/asm/ppc-opcode.h |   10 
 arch/powerpc/kernel/ptrace.c  |   14 
 arch/powerpc/perf/power9-events-list.h|2 
 arch/powerpc/sysdev/xics/icp-opal.c   |   31 
 arch/s390/kvm/kvm-s390.c  |4 
 arch/x86/kernel/apic/io_apic.c|2 
 arch/x86/kernel/pci-swiotlb.c |2 
 arch/x86/pci/acpi.c   |   10 
 arch/x86/xen/pci-swiotlb-xen.c|2 
 drivers/clocksource/exynos_mct.c  |1 
 drivers/devfreq/devfreq.c |   15 
 drivers/devfreq/exynos-bus.c  |2 
 drivers/dma/pl330.c   |   11 
 drivers/dma/sh/rcar-dmac.c|8 
 drivers/hid/hid-corsair.c |   60 -
 drivers/infiniband/core/cache.c   |   16 
 drivers/infiniband/hw/mlx4/ah.c   |6 
 drivers/infiniband/hw/mlx4/mad.c  |   16 
 drivers/infiniband/hw/mlx4/main.c |   29 
 drivers/infiniband/hw/mlx4/qp.c   |7 
 drivers/infiniband/hw/mlx5/main.c |8 
 drivers/infiniband/hw/mlx5/mr.c   |   31 
 drivers/infiniband/hw/mlx5/qp.c   |   29 
 drivers/infiniband/hw/mlx5/srq.c  |2 
 drivers/infiniband/sw/rxe/rxe_param.h |2 
 drivers/infiniband/sw/rxe/rxe_req.c   |   14 
 drivers/infiniband/ulp/ipoib/ipoib_cm.c   |2 
 drivers/input/mouse/alps.c|   19 
 drivers/media/platform/Kconfig|2 
 drivers/media/platform/blackfin/ppi.c |2 
 

Re: Linux 4.4.45

[Greg KH]

diff --git a/Documentation/devicetree/bindings/clock/imx31-clock.txt 
b/Documentation/devicetree/bindings/clock/imx31-clock.txt
index 19df842c694f..8163d565f697 100644
--- a/Documentation/devicetree/bindings/clock/imx31-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx31-clock.txt
@@ -77,7 +77,7 @@ Examples:
 clks: ccm@53f8{
compatible = "fsl,imx31-ccm";
reg = <0x53f8 0x4000>;
-   interrupts = <0 31 0x04 0 53 0x04>;
+   interrupts = <31>, <53>;
#clock-cells = <1>;
 };
 
diff --git a/Makefile b/Makefile
index d6a1de0e2bd7..a3dfc73da722 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 4
-SUBLEVEL = 44
+SUBLEVEL = 45
 EXTRAVERSION =
 NAME = Blurry Fish Butt
 
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 4f935ad9f27b..6881757b03e8 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -85,6 +85,7 @@
#size-cells = <1>;
compatible = "m25p64";
spi-max-frequency = <3000>;
+   m25p,fast-read;
reg = <0>;
partition@0 {
label = "U-Boot-SPL";
diff --git a/arch/arm/boot/dts/imx31.dtsi b/arch/arm/boot/dts/imx31.dtsi
index 5fdb222636a7..cbe5fd5ed179 100644
--- a/arch/arm/boot/dts/imx31.dtsi
+++ b/arch/arm/boot/dts/imx31.dtsi
@@ -30,11 +30,11 @@
};
};
 
-   avic: avic-interrupt-controller@6000 {
+   avic: interrupt-controller@6800 {
compatible = "fsl,imx31-avic", "fsl,avic";
interrupt-controller;
#interrupt-cells = <1>;
-   reg = <0x6000 0x10>;
+   reg = <0x6800 0x10>;
};
 
soc {
@@ -110,13 +110,6 @@
interrupts = <19>;
clocks = < 25>;
};
-
-   clks: ccm@53f8{
-   compatible = "fsl,imx31-ccm";
-   reg = <0x53f8 0x4000>;
-   interrupts = <0 31 0x04 0 53 0x04>;
-   #clock-cells = <1>;
-   };
};
 
aips@53f0 { /* AIPS2 */
@@ -126,6 +119,13 @@
reg = <0x53f0 0x10>;
ranges;
 
+   clks: ccm@53f8{
+   compatible = "fsl,imx31-ccm";
+   reg = <0x53f8 0x4000>;
+   interrupts = <31>, <53>;
+   #clock-cells = <1>;
+   };
+
gpt: timer@53f9 {
compatible = "fsl,imx31-gpt";
reg = <0x53f9 0x4000>;
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi 
b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
index a35d54fd9cd3..ddfdb75a6e90 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
@@ -319,8 +319,6 @@
compatible = "fsl,imx6q-nitrogen6_max-sgtl5000",
 "fsl,imx-audio-sgtl5000";
model = "imx6q-nitrogen6_max-sgtl5000";
-   pinctrl-names = "default";
-   pinctrl-0 = <_sgtl5000>;
ssi-controller = <>;
audio-codec = <>;
audio-routing =
@@ -401,6 +399,8 @@
 
codec: sgtl5000@0a {
compatible = "fsl,sgtl5000";
+   pinctrl-names = "default";
+   pinctrl-0 = <_sgtl5000>;
reg = <0x0a>;
clocks = < 201>;
VDDA-supply = <_2p5v>;
diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 85e374f873ac..e9d04f475929 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -81,6 +81,9 @@
 #define ARM_CPU_XSCALE_ARCH_V2 0x4000
 #define ARM_CPU_XSCALE_ARCH_V3 0x6000
 
+/* Qualcomm implemented cores */
+#define ARM_CPU_PART_SCORPION  0x510002d0
+
 extern unsigned int processor_id;
 
 #ifdef CONFIG_CPU_CP15
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index 6284779d64ee..abcbea1ae30b 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -1066,6 +1066,22 @@ static int __init arch_hw_breakpoint_init(void)
return 0;
}
 
+   /*
+* Scorpion CPUs (at least those in APQ8060) seem to set DBGPRSR.SPD
+* whenever a WFI is issued, even if the core is not powered down, in
+* violation of the architecture.  When DBGPRSR.SPD is set, accesses to
+* breakpoint and watchpoint registers are treated as 

Re: [PATCH 8/8] Revert "ext4: fix wrong gfp type under transaction"

[Michal Hocko]

On Thu 19-01-17 10:44:05, Michal Hocko wrote:
> On Thu 19-01-17 10:22:36, Jan Kara wrote:
> > On Thu 19-01-17 09:39:56, Michal Hocko wrote:
> > > On Tue 17-01-17 18:29:25, Jan Kara wrote:
> > > > On Tue 17-01-17 17:16:19, Michal Hocko wrote:
> > > > > > > But before going to play with that I am really wondering whether 
> > > > > > > we need
> > > > > > > all this with no journal at all. AFAIU what Jack told me it is the
> > > > > > > journal lock(s) which is the biggest problem from the reclaim 
> > > > > > > recursion
> > > > > > > point of view. What would cause a deadlock in no journal mode?
> > > > > > 
> > > > > > We still have the original problem for why we need GFP_NOFS even in
> > > > > > ext2.  If we are in a writeback path, and we need to allocate 
> > > > > > memory,
> > > > > > we don't want to recurse back into the file system's writeback path.
> > > > > 
> > > > > But we do not enter the writeback path from the direct reclaim. Or do
> > > > > you mean something other than pageout()'s mapping->a_ops->writepage?
> > > > > There is only try_to_release_page where we get back to the filesystems
> > > > > but I do not see any NOFS protection in ext4_releasepage.
> > > > 
> > > > Maybe to expand a bit: These days, direct reclaim can call 
> > > > ->releasepage()
> > > > callback, ->evict_inode() callback (and only for inodes with i_nlink > 
> > > > 0),
> > > > shrinkers. That's it. So the recursion possibilities are rather more 
> > > > limited
> > > > than they used to be several years ago and we likely do not need as much
> > > > GFP_NOFS protection as we used to.
> > > 
> > > Thanks for making my remark more clear Jack! I would just want to add
> > > that I was playing with the patch below (it is basically
> > > GFP_NOFS->GFP_KERNEL for all allocations which trigger warning from the
> > > debugging patch which means they are called from within transaction) and
> > > it didn't hit the lockdep when running xfstests both with or without the
> > > enabled journal.
> > > 
> > > So am I still missing something or the nojournal mode is safe and the
> > > current series is OK wrt. ext*?
> > 
> > I'm convinced the current series is OK, only real life will tell us whether
> > we missed something or not ;)
> 
> I would like to extend the changelog of "jbd2: mark the transaction
> context with the scope GFP_NOFS context".
> 
> "
> Please note that setups without journal do not suffer from potential
> recursion problems and so they do not need the scope protection because
> neither ->releasepage nor ->evict_inode (which are the only fs entry
> points from the direct reclaim) can reenter a locked context which is
> doing the allocation currently.
> "

Could you comment on this Ted, please?
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 8/8] Revert "ext4: fix wrong gfp type under transaction"

[Michal Hocko]

On Thu 19-01-17 10:44:05, Michal Hocko wrote:
> On Thu 19-01-17 10:22:36, Jan Kara wrote:
> > On Thu 19-01-17 09:39:56, Michal Hocko wrote:
> > > On Tue 17-01-17 18:29:25, Jan Kara wrote:
> > > > On Tue 17-01-17 17:16:19, Michal Hocko wrote:
> > > > > > > But before going to play with that I am really wondering whether 
> > > > > > > we need
> > > > > > > all this with no journal at all. AFAIU what Jack told me it is the
> > > > > > > journal lock(s) which is the biggest problem from the reclaim 
> > > > > > > recursion
> > > > > > > point of view. What would cause a deadlock in no journal mode?
> > > > > > 
> > > > > > We still have the original problem for why we need GFP_NOFS even in
> > > > > > ext2.  If we are in a writeback path, and we need to allocate 
> > > > > > memory,
> > > > > > we don't want to recurse back into the file system's writeback path.
> > > > > 
> > > > > But we do not enter the writeback path from the direct reclaim. Or do
> > > > > you mean something other than pageout()'s mapping->a_ops->writepage?
> > > > > There is only try_to_release_page where we get back to the filesystems
> > > > > but I do not see any NOFS protection in ext4_releasepage.
> > > > 
> > > > Maybe to expand a bit: These days, direct reclaim can call 
> > > > ->releasepage()
> > > > callback, ->evict_inode() callback (and only for inodes with i_nlink > 
> > > > 0),
> > > > shrinkers. That's it. So the recursion possibilities are rather more 
> > > > limited
> > > > than they used to be several years ago and we likely do not need as much
> > > > GFP_NOFS protection as we used to.
> > > 
> > > Thanks for making my remark more clear Jack! I would just want to add
> > > that I was playing with the patch below (it is basically
> > > GFP_NOFS->GFP_KERNEL for all allocations which trigger warning from the
> > > debugging patch which means they are called from within transaction) and
> > > it didn't hit the lockdep when running xfstests both with or without the
> > > enabled journal.
> > > 
> > > So am I still missing something or the nojournal mode is safe and the
> > > current series is OK wrt. ext*?
> > 
> > I'm convinced the current series is OK, only real life will tell us whether
> > we missed something or not ;)
> 
> I would like to extend the changelog of "jbd2: mark the transaction
> context with the scope GFP_NOFS context".
> 
> "
> Please note that setups without journal do not suffer from potential
> recursion problems and so they do not need the scope protection because
> neither ->releasepage nor ->evict_inode (which are the only fs entry
> points from the direct reclaim) can reenter a locked context which is
> doing the allocation currently.
> "

Could you comment on this Ted, please?
-- 
Michal Hocko
SUSE Labs

RE: [PATCH] Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()

[Dexuan Cui]

> From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
> > Dexuan Cui  wrote:
> > As I checked against the kernels listed on the homapage,
> > the below versions are impacted:
> > v3.16.39
> > v3.18.47
> > v4.1.38
> > v4.8.17
> > v4.9.5
> > v4.10-rc5
> >
> > It's interesting v4.4.44 is not impacted, but actually it needs both the 2 
> > patches:
> > i.e. this patch, and the previous one:
> > Commit a389fcfd2cb5 ("Drivers: hv: vmbus: Fix signaling logic in
> hv_need_to_signal_on_read()")
> 
> That patch does not apply to the 4.4-stable tree, which is why it was
> not included there.  If you feel it should be included, please provide a
> backport and send it to the sta...@vger.kernel.org mailing list.
> 
> greg k-h

Thanks! I'll do the backport after this patch goes in the mainline.

Thanks,
-- Dexuan

RE: [PATCH] Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()

[Dexuan Cui]

> From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
> > Dexuan Cui  wrote:
> > As I checked against the kernels listed on the homapage,
> > the below versions are impacted:
> > v3.16.39
> > v3.18.47
> > v4.1.38
> > v4.8.17
> > v4.9.5
> > v4.10-rc5
> >
> > It's interesting v4.4.44 is not impacted, but actually it needs both the 2 
> > patches:
> > i.e. this patch, and the previous one:
> > Commit a389fcfd2cb5 ("Drivers: hv: vmbus: Fix signaling logic in
> hv_need_to_signal_on_read()")
> 
> That patch does not apply to the 4.4-stable tree, which is why it was
> not included there.  If you feel it should be included, please provide a
> backport and send it to the sta...@vger.kernel.org mailing list.
> 
> greg k-h

Thanks! I'll do the backport after this patch goes in the mainline.

Thanks,
-- Dexuan

Re: [PATCH 0/6 v3] kvmalloc

[Michal Hocko]

On Wed 25-01-17 21:16:42, Daniel Borkmann wrote:
> On 01/25/2017 07:14 PM, Alexei Starovoitov wrote:
> > On Wed, Jan 25, 2017 at 5:21 AM, Michal Hocko  wrote:
> > > On Wed 25-01-17 14:10:06, Michal Hocko wrote:
> > > > On Tue 24-01-17 11:17:21, Alexei Starovoitov wrote:
> [...]
> > > > > > Are there any more comments? I would really appreciate to hear from
> > > > > > networking folks before I resubmit the series.
> > > > > 
> > > > > while this patchset was baking the bpf side switched to use 
> > > > > bpf_map_area_alloc()
> > > > > which fixes the issue with missing __GFP_NORETRY that we had to fix 
> > > > > quickly.
> > > > > See commit d407bd25a204 ("bpf: don't trigger OOM killer under 
> > > > > pressure with map alloc")
> > > > > it covers all kmalloc/vmalloc pairs instead of just one place as in 
> > > > > this set.
> > > > > So please rebase and switch bpf_map_area_alloc() to use kvmalloc().
> > > > 
> > > > OK, will do. Thanks for the heads up.
> > > 
> > > Just for the record, I will fold the following into the patch 1
> > > ---
> > > diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> > > index 19b6129eab23..8697f43cf93c 100644
> > > --- a/kernel/bpf/syscall.c
> > > +++ b/kernel/bpf/syscall.c
> > > @@ -53,21 +53,7 @@ void bpf_register_map_type(struct bpf_map_type_list 
> > > *tl)
> > > 
> > >   void *bpf_map_area_alloc(size_t size)
> > >   {
> > > -   /* We definitely need __GFP_NORETRY, so OOM killer doesn't
> > > -* trigger under memory pressure as we really just want to
> > > -* fail instead.
> > > -*/
> > > -   const gfp_t flags = __GFP_NOWARN | __GFP_NORETRY | __GFP_ZERO;
> > > -   void *area;
> > > -
> > > -   if (size <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER)) {
> > > -   area = kmalloc(size, GFP_USER | flags);
> > > -   if (area != NULL)
> > > -   return area;
> > > -   }
> > > -
> > > -   return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM | flags,
> > > -PAGE_KERNEL);
> > > +   return kvzalloc(size, GFP_USER);
> > >   }
> > > 
> > >   void bpf_map_area_free(void *area)
> > 
> > Looks fine by me.
> > Daniel, thoughts?
> 
> I assume that kvzalloc() is still the same from [1], right? If so, then
> it would unfortunately (partially) reintroduce the issue that was fixed.
> If you look above at flags, they're also passed to __vmalloc() to not
> trigger OOM in these situations I've experienced.

Pushing __GFP_NORETRY to __vmalloc doesn't have the effect you might
think it would. It can still trigger the OOM killer becauset the flags
are no propagated all the way down to all allocations requests (e.g.
page tables). This is the same reason why GFP_NOFS is not supported in
vmalloc.

> This is effectively the
> same requirement as in other networking areas f.e. that 5bad87348c70
> ("netfilter: x_tables: avoid warn and OOM killer on vmalloc call") has.
> In your comment in kvzalloc() you eventually say that some of the above
> modifiers are not supported. So there would be two options, i) just leave
> out the kvzalloc() chunk for BPF area to avoid the merge conflict and tackle
> it later (along with similar code from 5bad87348c70), or ii) implement
> support for these modifiers as well to your original set. I guess it's not
> too urgent, so we could also proceed with i) if that is easier for you to
> proceed (I don't mind either way).

Could you clarify why the oom killer in vmalloc matters actually?
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 0/6 v3] kvmalloc

[Michal Hocko]

On Wed 25-01-17 21:16:42, Daniel Borkmann wrote:
> On 01/25/2017 07:14 PM, Alexei Starovoitov wrote:
> > On Wed, Jan 25, 2017 at 5:21 AM, Michal Hocko  wrote:
> > > On Wed 25-01-17 14:10:06, Michal Hocko wrote:
> > > > On Tue 24-01-17 11:17:21, Alexei Starovoitov wrote:
> [...]
> > > > > > Are there any more comments? I would really appreciate to hear from
> > > > > > networking folks before I resubmit the series.
> > > > > 
> > > > > while this patchset was baking the bpf side switched to use 
> > > > > bpf_map_area_alloc()
> > > > > which fixes the issue with missing __GFP_NORETRY that we had to fix 
> > > > > quickly.
> > > > > See commit d407bd25a204 ("bpf: don't trigger OOM killer under 
> > > > > pressure with map alloc")
> > > > > it covers all kmalloc/vmalloc pairs instead of just one place as in 
> > > > > this set.
> > > > > So please rebase and switch bpf_map_area_alloc() to use kvmalloc().
> > > > 
> > > > OK, will do. Thanks for the heads up.
> > > 
> > > Just for the record, I will fold the following into the patch 1
> > > ---
> > > diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> > > index 19b6129eab23..8697f43cf93c 100644
> > > --- a/kernel/bpf/syscall.c
> > > +++ b/kernel/bpf/syscall.c
> > > @@ -53,21 +53,7 @@ void bpf_register_map_type(struct bpf_map_type_list 
> > > *tl)
> > > 
> > >   void *bpf_map_area_alloc(size_t size)
> > >   {
> > > -   /* We definitely need __GFP_NORETRY, so OOM killer doesn't
> > > -* trigger under memory pressure as we really just want to
> > > -* fail instead.
> > > -*/
> > > -   const gfp_t flags = __GFP_NOWARN | __GFP_NORETRY | __GFP_ZERO;
> > > -   void *area;
> > > -
> > > -   if (size <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER)) {
> > > -   area = kmalloc(size, GFP_USER | flags);
> > > -   if (area != NULL)
> > > -   return area;
> > > -   }
> > > -
> > > -   return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM | flags,
> > > -PAGE_KERNEL);
> > > +   return kvzalloc(size, GFP_USER);
> > >   }
> > > 
> > >   void bpf_map_area_free(void *area)
> > 
> > Looks fine by me.
> > Daniel, thoughts?
> 
> I assume that kvzalloc() is still the same from [1], right? If so, then
> it would unfortunately (partially) reintroduce the issue that was fixed.
> If you look above at flags, they're also passed to __vmalloc() to not
> trigger OOM in these situations I've experienced.

Pushing __GFP_NORETRY to __vmalloc doesn't have the effect you might
think it would. It can still trigger the OOM killer becauset the flags
are no propagated all the way down to all allocations requests (e.g.
page tables). This is the same reason why GFP_NOFS is not supported in
vmalloc.

> This is effectively the
> same requirement as in other networking areas f.e. that 5bad87348c70
> ("netfilter: x_tables: avoid warn and OOM killer on vmalloc call") has.
> In your comment in kvzalloc() you eventually say that some of the above
> modifiers are not supported. So there would be two options, i) just leave
> out the kvzalloc() chunk for BPF area to avoid the merge conflict and tackle
> it later (along with similar code from 5bad87348c70), or ii) implement
> support for these modifiers as well to your original set. I guess it's not
> too urgent, so we could also proceed with i) if that is easier for you to
> proceed (I don't mind either way).

Could you clarify why the oom killer in vmalloc matters actually?
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v5 05/13] lockdep: Pass a callback arg to check_prev_add() to handle stack_trace

[Byungchul Park]

I fixed a hole that peterz pointed out. And then, I think the following
is reasonable. Don't you think so?

->8-
commit ac185d1820ee7223773ec3e23f614c1fe5c079fc
Author: Byungchul Park 
Date:   Tue Jan 24 14:46:14 2017 +0900

lockdep: Pass a callback arg to check_prev_add() to handle stack_trace

Currently, a separate stack_trace instance cannot be used in
check_prev_add(). The simplest way to achieve it is to pass a
stack_trace instance to check_prev_add() as an argument after
saving it. However, unnecessary saving can happen if so implemented.

The proper solution is to pass a callback function additionally along
with a stack_trace so that a caller can decide the way to save. Actually,
crossrelease don't need to save stack_trace of current, but only need to
copy stack_traces from temporary buffers to the global stack_trace[].

In addition, check_prev_add() returns 2 in case that the lock does not
need to be added into the dependency graph because it was already in.
However, the return value is not used any more. So, this patch changes
it to mean that lockdep successfully save stack_trace and add the lock
to the graph.

Signed-off-by: Byungchul Park 

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 7fe6af1..9562b29 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -1805,20 +1805,13 @@ static inline void inc_chains(void)
  */
 static int
 check_prev_add(struct task_struct *curr, struct held_lock *prev,
-  struct held_lock *next, int distance, int *stack_saved)
+  struct held_lock *next, int distance, struct stack_trace *trace,
+  int (*save)(struct stack_trace *trace))
 {
struct lock_list *entry;
int ret;
struct lock_list this;
struct lock_list *uninitialized_var(target_entry);
-   /*
-* Static variable, serialized by the graph_lock().
-*
-* We use this static variable to save the stack trace in case
-* we call into this function multiple times due to encountering
-* trylocks in the held lock stack.
-*/
-   static struct stack_trace trace;
 
/*
 * Prove that the new  ->  dependency would not
@@ -1862,15 +1855,12 @@ static inline void inc_chains(void)
if (entry->class == hlock_class(next)) {
if (distance == 1)
entry->distance = 1;
-   return 2;
+   return 1;
}
}
 
-   if (!*stack_saved) {
-   if (!save_trace())
-   return 0;
-   *stack_saved = 1;
-   }
+   if (save && !save(trace))
+   return 0;
 
/*
 * Ok, all validations passed, add the new lock
@@ -1878,14 +1868,14 @@ static inline void inc_chains(void)
 */
ret = add_lock_to_list(hlock_class(prev), hlock_class(next),
   _class(prev)->locks_after,
-  next->acquire_ip, distance, );
+  next->acquire_ip, distance, trace);
 
if (!ret)
return 0;
 
ret = add_lock_to_list(hlock_class(next), hlock_class(prev),
   _class(next)->locks_before,
-  next->acquire_ip, distance, );
+  next->acquire_ip, distance, trace);
if (!ret)
return 0;
 
@@ -1893,8 +1883,6 @@ static inline void inc_chains(void)
 * Debugging printouts:
 */
if (verbose(hlock_class(prev)) || verbose(hlock_class(next))) {
-   /* We drop graph lock, so another thread can overwrite trace. */
-   *stack_saved = 0;
graph_unlock();
printk("\n new dependency: ");
print_lock_name(hlock_class(prev));
@@ -1902,9 +1890,10 @@ static inline void inc_chains(void)
print_lock_name(hlock_class(next));
printk(KERN_CONT "\n");
dump_stack();
-   return graph_lock();
+   if (!graph_lock())
+   return 0;
}
-   return 1;
+   return 2;
 }
 
 /*
@@ -1917,8 +1906,9 @@ static inline void inc_chains(void)
 check_prevs_add(struct task_struct *curr, struct held_lock *next)
 {
int depth = curr->lockdep_depth;
-   int stack_saved = 0;
struct held_lock *hlock;
+   struct stack_trace trace;
+   int (*save)(struct stack_trace *trace) = save_trace;
 
/*
 * Debugging checks.
@@ -1943,9 +1933,18 @@ static inline void inc_chains(void)
 * added:
 */
if (hlock->read != 2 && hlock->check) {
-   if (!check_prev_add(curr, hlock, next,
-

Re: [PATCH v5 05/13] lockdep: Pass a callback arg to check_prev_add() to handle stack_trace

[Byungchul Park]

I fixed a hole that peterz pointed out. And then, I think the following
is reasonable. Don't you think so?

->8-
commit ac185d1820ee7223773ec3e23f614c1fe5c079fc
Author: Byungchul Park 
Date:   Tue Jan 24 14:46:14 2017 +0900

lockdep: Pass a callback arg to check_prev_add() to handle stack_trace

Currently, a separate stack_trace instance cannot be used in
check_prev_add(). The simplest way to achieve it is to pass a
stack_trace instance to check_prev_add() as an argument after
saving it. However, unnecessary saving can happen if so implemented.

The proper solution is to pass a callback function additionally along
with a stack_trace so that a caller can decide the way to save. Actually,
crossrelease don't need to save stack_trace of current, but only need to
copy stack_traces from temporary buffers to the global stack_trace[].

In addition, check_prev_add() returns 2 in case that the lock does not
need to be added into the dependency graph because it was already in.
However, the return value is not used any more. So, this patch changes
it to mean that lockdep successfully save stack_trace and add the lock
to the graph.

Signed-off-by: Byungchul Park 

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 7fe6af1..9562b29 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -1805,20 +1805,13 @@ static inline void inc_chains(void)
  */
 static int
 check_prev_add(struct task_struct *curr, struct held_lock *prev,
-  struct held_lock *next, int distance, int *stack_saved)
+  struct held_lock *next, int distance, struct stack_trace *trace,
+  int (*save)(struct stack_trace *trace))
 {
struct lock_list *entry;
int ret;
struct lock_list this;
struct lock_list *uninitialized_var(target_entry);
-   /*
-* Static variable, serialized by the graph_lock().
-*
-* We use this static variable to save the stack trace in case
-* we call into this function multiple times due to encountering
-* trylocks in the held lock stack.
-*/
-   static struct stack_trace trace;
 
/*
 * Prove that the new  ->  dependency would not
@@ -1862,15 +1855,12 @@ static inline void inc_chains(void)
if (entry->class == hlock_class(next)) {
if (distance == 1)
entry->distance = 1;
-   return 2;
+   return 1;
}
}
 
-   if (!*stack_saved) {
-   if (!save_trace())
-   return 0;
-   *stack_saved = 1;
-   }
+   if (save && !save(trace))
+   return 0;
 
/*
 * Ok, all validations passed, add the new lock
@@ -1878,14 +1868,14 @@ static inline void inc_chains(void)
 */
ret = add_lock_to_list(hlock_class(prev), hlock_class(next),
   _class(prev)->locks_after,
-  next->acquire_ip, distance, );
+  next->acquire_ip, distance, trace);
 
if (!ret)
return 0;
 
ret = add_lock_to_list(hlock_class(next), hlock_class(prev),
   _class(next)->locks_before,
-  next->acquire_ip, distance, );
+  next->acquire_ip, distance, trace);
if (!ret)
return 0;
 
@@ -1893,8 +1883,6 @@ static inline void inc_chains(void)
 * Debugging printouts:
 */
if (verbose(hlock_class(prev)) || verbose(hlock_class(next))) {
-   /* We drop graph lock, so another thread can overwrite trace. */
-   *stack_saved = 0;
graph_unlock();
printk("\n new dependency: ");
print_lock_name(hlock_class(prev));
@@ -1902,9 +1890,10 @@ static inline void inc_chains(void)
print_lock_name(hlock_class(next));
printk(KERN_CONT "\n");
dump_stack();
-   return graph_lock();
+   if (!graph_lock())
+   return 0;
}
-   return 1;
+   return 2;
 }
 
 /*
@@ -1917,8 +1906,9 @@ static inline void inc_chains(void)
 check_prevs_add(struct task_struct *curr, struct held_lock *next)
 {
int depth = curr->lockdep_depth;
-   int stack_saved = 0;
struct held_lock *hlock;
+   struct stack_trace trace;
+   int (*save)(struct stack_trace *trace) = save_trace;
 
/*
 * Debugging checks.
@@ -1943,9 +1933,18 @@ static inline void inc_chains(void)
 * added:
 */
if (hlock->read != 2 && hlock->check) {
-   if (!check_prev_add(curr, hlock, next,
-   distance, _saved))
+ 

Re: [PATCH] mm: migrate: add isolate_movable_page() stub implementation

[Michal Hocko]

JFYI, Yisheng Xie has already posted a new version of the patchset [1]
and I assume Andrew will drop the current one.

[1] http://lkml.kernel.org/r/1485356738-4831-1-git-send-email-ys...@foxmail.com

On Wed 25-01-17 23:27:38, Arnd Bergmann wrote:
> Without CONFIG_MIGRATION, we get a build failure when trying to
> call isolate_movable_page():
> 
> mm/memory-failure.c: In function '__soft_offline_page':
> mm/memory-failure.c:1656:10: error: implicit declaration of function 
> 'isolate_movable_page';did you mean 'isolate_huge_page'? 
> [-Werror=implicit-function-declaration]
> 
> This adds one more static inline helper function in the header
> declaring it. This returns false to indicate that the
> page was not isolated.
> 
> Fixes: mmotm ("HWPOISON: soft offlining for non-lru movable pages")
> Fixes: bda807d44454 ("mm: migrate: support non-lru movable page migration")
> Signed-off-by: Arnd Bergmann 
> ---
>  include/linux/migrate.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/include/linux/migrate.h b/include/linux/migrate.h
> index ae8d475a9385..09dd6e924106 100644
> --- a/include/linux/migrate.h
> +++ b/include/linux/migrate.h
> @@ -57,6 +57,9 @@ static inline int migrate_pages(struct list_head *l, 
> new_page_t new,
>   int reason)
>   { return -ENOSYS; }
>  
> +static inline bool isolate_movable_page(struct page *page, isolate_mode_t 
> mode)
> + { return false; }
> +
>  static inline int migrate_prep(void) { return -ENOSYS; }
>  static inline int migrate_prep_local(void) { return -ENOSYS; }
>  
> -- 
> 2.9.0

-- 
Michal Hocko
SUSE Labs

Re: [PATCH] mm: migrate: add isolate_movable_page() stub implementation

[Michal Hocko]

JFYI, Yisheng Xie has already posted a new version of the patchset [1]
and I assume Andrew will drop the current one.

[1] http://lkml.kernel.org/r/1485356738-4831-1-git-send-email-ys...@foxmail.com

On Wed 25-01-17 23:27:38, Arnd Bergmann wrote:
> Without CONFIG_MIGRATION, we get a build failure when trying to
> call isolate_movable_page():
> 
> mm/memory-failure.c: In function '__soft_offline_page':
> mm/memory-failure.c:1656:10: error: implicit declaration of function 
> 'isolate_movable_page';did you mean 'isolate_huge_page'? 
> [-Werror=implicit-function-declaration]
> 
> This adds one more static inline helper function in the header
> declaring it. This returns false to indicate that the
> page was not isolated.
> 
> Fixes: mmotm ("HWPOISON: soft offlining for non-lru movable pages")
> Fixes: bda807d44454 ("mm: migrate: support non-lru movable page migration")
> Signed-off-by: Arnd Bergmann 
> ---
>  include/linux/migrate.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/include/linux/migrate.h b/include/linux/migrate.h
> index ae8d475a9385..09dd6e924106 100644
> --- a/include/linux/migrate.h
> +++ b/include/linux/migrate.h
> @@ -57,6 +57,9 @@ static inline int migrate_pages(struct list_head *l, 
> new_page_t new,
>   int reason)
>   { return -ENOSYS; }
>  
> +static inline bool isolate_movable_page(struct page *page, isolate_mode_t 
> mode)
> + { return false; }
> +
>  static inline int migrate_prep(void) { return -ENOSYS; }
>  static inline int migrate_prep_local(void) { return -ENOSYS; }
>  
> -- 
> 2.9.0

-- 
Michal Hocko
SUSE Labs

Re: [PATCHv2 10/12] mm: convert page_mapped_in_vma() to page_vma_mapped_walk()

[Hillf Danton]

On January 26, 2017 2:26 AM Kirill A. Shutemov wrote: 
> 
> For consistency, it worth converting all page_check_address() to
> page_vma_mapped_walk(), so we could drop the former.
> 
> Signed-off-by: Kirill A. Shutemov 
> ---
Acked-by: Hillf Danton 

>  mm/page_vma_mapped.c | 30 ++
>  mm/rmap.c| 26 --
>  2 files changed, 30 insertions(+), 26 deletions(-)
> 
> diff --git a/mm/page_vma_mapped.c b/mm/page_vma_mapped.c
> index 63168b4baf19..13929f2418b0 100644
> --- a/mm/page_vma_mapped.c
> +++ b/mm/page_vma_mapped.c
> @@ -179,3 +179,33 @@ next_pte:do {
>   }
>   }
>  }
> +
> +/**
> + * page_mapped_in_vma - check whether a page is really mapped in a VMA
> + * @page: the page to test
> + * @vma: the VMA to test
> + *
> + * Returns 1 if the page is mapped into the page tables of the VMA, 0
> + * if the page is not mapped into the page tables of this VMA.  Only
> + * valid for normal file or anonymous VMAs.
> + */
> +int page_mapped_in_vma(struct page *page, struct vm_area_struct *vma)
> +{
> + struct page_vma_mapped_walk pvmw = {
> + .page = page,
> + .vma = vma,
> + .flags = PVMW_SYNC,
> + };
> + unsigned long start, end;
> +
> + start = __vma_address(page, vma);
> + end = start + PAGE_SIZE * (hpage_nr_pages(page) - 1);
> +
> + if (unlikely(end < vma->vm_start || start >= vma->vm_end))
> + return 0;
> + pvmw.address = max(start, vma->vm_start);

Nit: please see comment in the 05/12 patch in this series.

> + if (!page_vma_mapped_walk())
> + return 0;
> + page_vma_mapped_walk_done();
> + return 1;
> +}

Re: [PATCHv2 10/12] mm: convert page_mapped_in_vma() to page_vma_mapped_walk()

[Hillf Danton]

On January 26, 2017 2:26 AM Kirill A. Shutemov wrote: 
> 
> For consistency, it worth converting all page_check_address() to
> page_vma_mapped_walk(), so we could drop the former.
> 
> Signed-off-by: Kirill A. Shutemov 
> ---
Acked-by: Hillf Danton 

>  mm/page_vma_mapped.c | 30 ++
>  mm/rmap.c| 26 --
>  2 files changed, 30 insertions(+), 26 deletions(-)
> 
> diff --git a/mm/page_vma_mapped.c b/mm/page_vma_mapped.c
> index 63168b4baf19..13929f2418b0 100644
> --- a/mm/page_vma_mapped.c
> +++ b/mm/page_vma_mapped.c
> @@ -179,3 +179,33 @@ next_pte:do {
>   }
>   }
>  }
> +
> +/**
> + * page_mapped_in_vma - check whether a page is really mapped in a VMA
> + * @page: the page to test
> + * @vma: the VMA to test
> + *
> + * Returns 1 if the page is mapped into the page tables of the VMA, 0
> + * if the page is not mapped into the page tables of this VMA.  Only
> + * valid for normal file or anonymous VMAs.
> + */
> +int page_mapped_in_vma(struct page *page, struct vm_area_struct *vma)
> +{
> + struct page_vma_mapped_walk pvmw = {
> + .page = page,
> + .vma = vma,
> + .flags = PVMW_SYNC,
> + };
> + unsigned long start, end;
> +
> + start = __vma_address(page, vma);
> + end = start + PAGE_SIZE * (hpage_nr_pages(page) - 1);
> +
> + if (unlikely(end < vma->vm_start || start >= vma->vm_end))
> + return 0;
> + pvmw.address = max(start, vma->vm_start);

Nit: please see comment in the 05/12 patch in this series.

> + if (!page_vma_mapped_walk())
> + return 0;
> + page_vma_mapped_walk_done();
> + return 1;
> +}

[PATCH] Kbuild: fix file name in comment about extra gcc checks

[Seung-Woo Kim]

Extra gcc checks like W=1 were moved to scripts/Makefile.exrawarn,
so the file name in comment needs to be fixed.

Signed-off-by: Seung-Woo Kim 
---
 Makefile |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index 0988400..dbaada3 100644
--- a/Makefile
+++ b/Makefile
@@ -705,7 +705,7 @@ KBUILD_CFLAGS += $(call cc-option, 
-fcatch-undefined-behavior)
 else
 
 # These warnings generated too much noise in a regular build.
-# Use make W=1 to enable them (see scripts/Makefile.build)
+# Use make W=1 to enable them (see scripts/Makefile.extrawarn)
 KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable)
 KBUILD_CFLAGS += $(call cc-disable-warning, unused-const-variable)
 endif
-- 
1.7.4.1

[PATCH] Kbuild: fix file name in comment about extra gcc checks

[Seung-Woo Kim]

Extra gcc checks like W=1 were moved to scripts/Makefile.exrawarn,
so the file name in comment needs to be fixed.

Signed-off-by: Seung-Woo Kim 
---
 Makefile |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index 0988400..dbaada3 100644
--- a/Makefile
+++ b/Makefile
@@ -705,7 +705,7 @@ KBUILD_CFLAGS += $(call cc-option, 
-fcatch-undefined-behavior)
 else
 
 # These warnings generated too much noise in a regular build.
-# Use make W=1 to enable them (see scripts/Makefile.build)
+# Use make W=1 to enable them (see scripts/Makefile.extrawarn)
 KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable)
 KBUILD_CFLAGS += $(call cc-disable-warning, unused-const-variable)
 endif
-- 
1.7.4.1

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

[Ingo Molnar]

* Lu Baolu  wrote:

> 
> Hi,
> 
> On 01/25/2017 10:38 PM, Peter Zijlstra wrote:
> > On Wed, Jan 25, 2017 at 08:27:38PM +0800, Lu Baolu wrote:
> >> In my driver, udelay() is mostly used to handle time out.
> >>
> >> Xdbc hides most USB things in its firmware. Early printk driver only needs
> >> to setup the registers/data structures and wait until link ready or time 
> >> out.
> >> Without udelay(), I have no means to convert the polling times into waiting
> >> time.
> > What is timeout and why?
> 
> Put it in simple:
> 
> The driver sets the RUN bit in control register and polls READY
> bit in status register for the successful USB device enumeration.
> As the USB device enumeration might fail and the READY bit will
> never be set, the driver must have a timeout logic to avoid
> endless loop.

Is there any error status available in the host registers anywhere that tells 
us 
that enumeration did not succeed?

Thanks,

Ingo

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

[Ingo Molnar]

* Lu Baolu  wrote:

> 
> Hi,
> 
> On 01/25/2017 10:38 PM, Peter Zijlstra wrote:
> > On Wed, Jan 25, 2017 at 08:27:38PM +0800, Lu Baolu wrote:
> >> In my driver, udelay() is mostly used to handle time out.
> >>
> >> Xdbc hides most USB things in its firmware. Early printk driver only needs
> >> to setup the registers/data structures and wait until link ready or time 
> >> out.
> >> Without udelay(), I have no means to convert the polling times into waiting
> >> time.
> > What is timeout and why?
> 
> Put it in simple:
> 
> The driver sets the RUN bit in control register and polls READY
> bit in status register for the successful USB device enumeration.
> As the USB device enumeration might fail and the READY bit will
> never be set, the driver must have a timeout logic to avoid
> endless loop.

Is there any error status available in the host registers anywhere that tells 
us 
that enumeration did not succeed?

Thanks,

Ingo

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

[Ingo Molnar]

* Lu Baolu  wrote:

> Fair enough.
> 
> USB connection is stable enough, unless the user unplugs the
> USB cable during debugging.

What does the hardware do in this case? The XHCI registers are in the host 
hardware, so they won't disappear, right? Is there some cable connection status 
bit we can extract without interrupts?

I.e. if there's any polling component then it would be reasonable to add an 
error 
component: poll the status and if it goes 'disconnected' then disable 
early-printk 
altogether in this case and trigger an emergency printk() so that there's 
chance 
that the user notices [if the system does not misbehave otherwise].

I.e. try to be as robust and informative as lockdep - yet don't lock up the 
host 
kernel: lockdep too is called from very deep internals, there are various 
conditions where it sees corrupt data structures (i.e. a 'disconnect' - a 
system 
environment outside the normal bounds of operation), yet of the kernel and over 
the last 10+ years of lockdep's existence we had very, very few cases of 
lockdep 
itself locking up and behaving unpredictably.

Thanks,

Ingo

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

[Ingo Molnar]

* Lu Baolu  wrote:

> Fair enough.
> 
> USB connection is stable enough, unless the user unplugs the
> USB cable during debugging.

What does the hardware do in this case? The XHCI registers are in the host 
hardware, so they won't disappear, right? Is there some cable connection status 
bit we can extract without interrupts?

I.e. if there's any polling component then it would be reasonable to add an 
error 
component: poll the status and if it goes 'disconnected' then disable 
early-printk 
altogether in this case and trigger an emergency printk() so that there's 
chance 
that the user notices [if the system does not misbehave otherwise].

I.e. try to be as robust and informative as lockdep - yet don't lock up the 
host 
kernel: lockdep too is called from very deep internals, there are various 
conditions where it sees corrupt data structures (i.e. a 'disconnect' - a 
system 
environment outside the normal bounds of operation), yet of the kernel and over 
the last 10+ years of lockdep's existence we had very, very few cases of 
lockdep 
itself locking up and behaving unpredictably.

Thanks,

Ingo

Re: [PATCH 4/7] arm64: dts: exynos: Add clocks to Exynos5433 LPASS module

[Marek Szyprowski]

Hi Krzysztof,


On 2017-01-25 20:50, Krzysztof Kozlowski wrote:

On Wed, Jan 25, 2017 at 12:50:28PM +0100, Marek Szyprowski wrote:

Exynos5433 LPASS module requires some clocks for proper operation with
power domain.

Signed-off-by: Marek Szyprowski 
---
  arch/arm64/boot/dts/exynos/exynos5433.dtsi | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 57c7bbeb65a7..16072c1c3ed3 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -1494,6 +1494,8 @@
audio-subsystem@1140 {
compatible = "samsung,exynos5433-lpass";
reg = <0x1140 0x100>, <0x1150 0x08>;
+   clocks = <_aud CLK_PCLK_SFR0_CTRL>;
+   clock-names = "sfr0_ctrl";

You wrote that 6/7 depends on this. I prefer not to take DTS changes if
the corresponding user (driver) is still under discussion because the
bindings might change. I'll take it when bindings got acked or accepted.


Well, audio support in 4.9 is still not functional due to missing other
patches to ALSA SoC, so nothing will break as for now if we manage to get
this into v4.10.


BTW, the 6/7 is a quite reasonable ABI break, but for the sake of
documentation - why you did not continue with the patch for marking
bidings as experimental/under-development?


Because I had no time to list all breaks, what was requested by Rob.


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH 4/7] arm64: dts: exynos: Add clocks to Exynos5433 LPASS module

[Marek Szyprowski]

Hi Krzysztof,


On 2017-01-25 20:50, Krzysztof Kozlowski wrote:

On Wed, Jan 25, 2017 at 12:50:28PM +0100, Marek Szyprowski wrote:

Exynos5433 LPASS module requires some clocks for proper operation with
power domain.

Signed-off-by: Marek Szyprowski 
---
  arch/arm64/boot/dts/exynos/exynos5433.dtsi | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 57c7bbeb65a7..16072c1c3ed3 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -1494,6 +1494,8 @@
audio-subsystem@1140 {
compatible = "samsung,exynos5433-lpass";
reg = <0x1140 0x100>, <0x1150 0x08>;
+   clocks = <_aud CLK_PCLK_SFR0_CTRL>;
+   clock-names = "sfr0_ctrl";

You wrote that 6/7 depends on this. I prefer not to take DTS changes if
the corresponding user (driver) is still under discussion because the
bindings might change. I'll take it when bindings got acked or accepted.


Well, audio support in 4.9 is still not functional due to missing other
patches to ALSA SoC, so nothing will break as for now if we manage to get
this into v4.10.


BTW, the 6/7 is a quite reasonable ABI break, but for the sake of
documentation - why you did not continue with the patch for marking
bidings as experimental/under-development?


Because I had no time to list all breaks, what was requested by Rob.


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH] Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()

[gre...@linuxfoundation.org]

On Thu, Jan 26, 2017 at 06:10:19AM +, Dexuan Cui wrote:
> > From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > Sent: Wednesday, January 25, 2017 00:08
> > To: Dexuan Cui 
> > Cc: gre...@linuxfoundation.org; driverdev-de...@linuxdriverproject.org; KY
> > Srinivasan ; Haiyang Zhang ;
> > Stephen Hemminger ; o...@aepfle.de; Rolf
> > Neugebauer ; jasow...@redhat.com; linux-
> > ker...@vger.kernel.org; a...@canonical.com
> > Subject: Re: [PATCH] Drivers: hv: vmbus: finally fix 
> > hv_need_to_signal_on_read()
> > 
> > On Tue, 24 Jan 2017 06:54:46 +
> > Dexuan Cui  wrote:
> > 
> > > +static inline void
> > > +init_cached_read_index(struct vmbus_channel *channel)
> > > +{
> > > + struct hv_ring_buffer_info *rbi = >inbound;
> > > +
> > > + rbi->cached_read_index = rbi->ring_buffer->read_index;
> > > +}
> > 
> > Looks good thanks. This should go in right away. Which versions are 
> > impacted?
> > Should it also go to stable?
> 
> Yes, it needs to go to stable.
> I have Cc-ed   in the patch's changelog, so it should 
> be
> included in the stable tree automatically.
> 
> As I checked against the kernels listed on the homapage of www.kernel.org, the
> below versions are impacted:
> v3.16.39
> v3.18.47
> v4.1.38
> v4.8.17
> v4.9.5
> v4.10-rc5
> 
> It's interesting v4.4.44 is not impacted, but actually it needs both the 2 
> patches:
> i.e. this patch, and the previous one:
> Commit a389fcfd2cb5 ("Drivers: hv: vmbus: Fix signaling logic in 
> hv_need_to_signal_on_read()")

That patch does not apply to the 4.4-stable tree, which is why it was
not included there.  If you feel it should be included, please provide a
backport and send it to the sta...@vger.kernel.org mailing list.

thanks,

greg k-h

Re: [PATCH] Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()

[gre...@linuxfoundation.org]

On Thu, Jan 26, 2017 at 06:10:19AM +, Dexuan Cui wrote:
> > From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > Sent: Wednesday, January 25, 2017 00:08
> > To: Dexuan Cui 
> > Cc: gre...@linuxfoundation.org; driverdev-de...@linuxdriverproject.org; KY
> > Srinivasan ; Haiyang Zhang ;
> > Stephen Hemminger ; o...@aepfle.de; Rolf
> > Neugebauer ; jasow...@redhat.com; linux-
> > ker...@vger.kernel.org; a...@canonical.com
> > Subject: Re: [PATCH] Drivers: hv: vmbus: finally fix 
> > hv_need_to_signal_on_read()
> > 
> > On Tue, 24 Jan 2017 06:54:46 +
> > Dexuan Cui  wrote:
> > 
> > > +static inline void
> > > +init_cached_read_index(struct vmbus_channel *channel)
> > > +{
> > > + struct hv_ring_buffer_info *rbi = >inbound;
> > > +
> > > + rbi->cached_read_index = rbi->ring_buffer->read_index;
> > > +}
> > 
> > Looks good thanks. This should go in right away. Which versions are 
> > impacted?
> > Should it also go to stable?
> 
> Yes, it needs to go to stable.
> I have Cc-ed   in the patch's changelog, so it should 
> be
> included in the stable tree automatically.
> 
> As I checked against the kernels listed on the homapage of www.kernel.org, the
> below versions are impacted:
> v3.16.39
> v3.18.47
> v4.1.38
> v4.8.17
> v4.9.5
> v4.10-rc5
> 
> It's interesting v4.4.44 is not impacted, but actually it needs both the 2 
> patches:
> i.e. this patch, and the previous one:
> Commit a389fcfd2cb5 ("Drivers: hv: vmbus: Fix signaling logic in 
> hv_need_to_signal_on_read()")

That patch does not apply to the 4.4-stable tree, which is why it was
not included there.  If you feel it should be included, please provide a
backport and send it to the sta...@vger.kernel.org mailing list.

thanks,

greg k-h

Re: [PATCH 1/2] soc: samsung: pmu: Remove unused and duplicated defines

[Marek Szyprowski]

Hi Krzysztof,


On 2017-01-25 20:34, Krzysztof Kozlowski wrote:

The exynos-regs-pmu.h was never a complete list of PMU registers.  It
contained a lot of holes for registers which are not used.  However, a
lot of unused defines came with porting the code from vendor kernel.

Few of defines were also duplicated.

Remove them so the file will be slightly smaller.

Signed-off-by: Krzysztof Kozlowski 


Thanks for the cleanup!

If you are touching this, you may also want to unify multiple headers for
the Exynos PMU regs:
include/linux/soc/samsung/exynos-regs-pmu.h
linux/mfd/syscon/exynos4-pmu.h
linux/mfd/syscon/exynos5-pmu.h

> [...]

Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH 1/2] soc: samsung: pmu: Remove unused and duplicated defines

[Marek Szyprowski]

Hi Krzysztof,


On 2017-01-25 20:34, Krzysztof Kozlowski wrote:

The exynos-regs-pmu.h was never a complete list of PMU registers.  It
contained a lot of holes for registers which are not used.  However, a
lot of unused defines came with porting the code from vendor kernel.

Few of defines were also duplicated.

Remove them so the file will be slightly smaller.

Signed-off-by: Krzysztof Kozlowski 


Thanks for the cleanup!

If you are touching this, you may also want to unify multiple headers for
the Exynos PMU regs:
include/linux/soc/samsung/exynos-regs-pmu.h
linux/mfd/syscon/exynos4-pmu.h
linux/mfd/syscon/exynos5-pmu.h

> [...]

Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCHv2 05/12] mm, rmap: check all VMAs that PTE-mapped THP can be part of

[Hillf Danton]

On January 26, 2017 2:26 AM Kirill A. Shutemov wrote: 
> @@ -333,12 +333,15 @@ __vma_address(struct page *page, struct vm_area_struct 
> *vma)
>  static inline unsigned long
>  vma_address(struct page *page, struct vm_area_struct *vma)
>  {
> - unsigned long address = __vma_address(page, vma);
> + unsigned long start, end;
> +
> + start = __vma_address(page, vma);
> + end = start + PAGE_SIZE * (hpage_nr_pages(page) - 1);
> 
>   /* page should be within @vma mapping range */
> - VM_BUG_ON_VMA(address < vma->vm_start || address >= vma->vm_end, vma);
> + VM_BUG_ON_VMA(end < vma->vm_start || start >= vma->vm_end, vma);
> 
> - return address;
> + return max(start, vma->vm_start);
>  }
Nit: currently it's buggy if page is not within the mapping range.
In this work fix is added for start if unlikely it goes outside range, and 
its currently relevant debugging is cut off.

Other than that,
Acked-by: Hillf Danton 

Re: [PATCHv2 05/12] mm, rmap: check all VMAs that PTE-mapped THP can be part of

[Hillf Danton]

On January 26, 2017 2:26 AM Kirill A. Shutemov wrote: 
> @@ -333,12 +333,15 @@ __vma_address(struct page *page, struct vm_area_struct 
> *vma)
>  static inline unsigned long
>  vma_address(struct page *page, struct vm_area_struct *vma)
>  {
> - unsigned long address = __vma_address(page, vma);
> + unsigned long start, end;
> +
> + start = __vma_address(page, vma);
> + end = start + PAGE_SIZE * (hpage_nr_pages(page) - 1);
> 
>   /* page should be within @vma mapping range */
> - VM_BUG_ON_VMA(address < vma->vm_start || address >= vma->vm_end, vma);
> + VM_BUG_ON_VMA(end < vma->vm_start || start >= vma->vm_end, vma);
> 
> - return address;
> + return max(start, vma->vm_start);
>  }
Nit: currently it's buggy if page is not within the mapping range.
In this work fix is added for start if unlikely it goes outside range, and 
its currently relevant debugging is cut off.

Other than that,
Acked-by: Hillf Danton 

Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic

[Borislav Petkov]

On Thu, Jan 26, 2017 at 02:30:02PM +0800, Xunlei Pang wrote:
> The hardware machine check is hard to reproduce, but the mce code of
> RHEL7 is quite the same as that of tip/master, anyway we are able to
> inject software mce to reproduce it.

Please give me your exact steps so that I can try to reproduce it here
too.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic

[Borislav Petkov]

On Thu, Jan 26, 2017 at 02:30:02PM +0800, Xunlei Pang wrote:
> The hardware machine check is hard to reproduce, but the mce code of
> RHEL7 is quite the same as that of tip/master, anyway we are able to
> inject software mce to reproduce it.

Please give me your exact steps so that I can try to reproduce it here
too.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic

[Xunlei Pang]

On 01/24/2017 at 08:22 PM, Borislav Petkov wrote:
> On Tue, Jan 24, 2017 at 09:27:45AM +0800, Xunlei Pang wrote:
>> It occurred on real hardware when testing crash dump.
>>
>> 1) SysRq-c was injected for the test in 1st kernel
>> [ 49.897279] SysRq : Trigger a crash 2) The 2nd kernel started for kdump
>>[ 0.00] Command line: BOOT_IMAGE=/vmlinuz-3.10.0-229.el7.x86_64 
>> root=UUID=976a15c8-8cbe-44ad-bb91-23f9b18e8789
> Yeah, no, I'm not debugging the RH Frankenstein kernel.
>
> Please retrigger this with latest tip/master first.
>

The hardware machine check is hard to reproduce, but the mce code of RHEL7 is 
quite
the same as that of tip/master, anyway we are able to inject software mce to 
reproduce it.

It is also clear from the theoretical analysis of the code.

Regards,
Xunlei

Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic

[Xunlei Pang]

On 01/24/2017 at 08:22 PM, Borislav Petkov wrote:
> On Tue, Jan 24, 2017 at 09:27:45AM +0800, Xunlei Pang wrote:
>> It occurred on real hardware when testing crash dump.
>>
>> 1) SysRq-c was injected for the test in 1st kernel
>> [ 49.897279] SysRq : Trigger a crash 2) The 2nd kernel started for kdump
>>[ 0.00] Command line: BOOT_IMAGE=/vmlinuz-3.10.0-229.el7.x86_64 
>> root=UUID=976a15c8-8cbe-44ad-bb91-23f9b18e8789
> Yeah, no, I'm not debugging the RH Frankenstein kernel.
>
> Please retrigger this with latest tip/master first.
>

The hardware machine check is hard to reproduce, but the mce code of RHEL7 is 
quite
the same as that of tip/master, anyway we are able to inject software mce to 
reproduce it.

It is also clear from the theoretical analysis of the code.

Regards,
Xunlei

Re: [PATCH v3 10/14] mmc: jz4740: Let the pinctrl driver configure the pins

[kbuild test robot]

Hi Paul,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc5 next-20170125]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Paul-Cercueil/Ingenic-JZ4740-JZ4780-pinctrl-driver/20170126-030028
config: mips-qi_lb60_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

   drivers/mmc/host/jz4740_mmc.c: In function 'jz4740_mmc_set_ios':
>> drivers/mmc/host/jz4740_mmc.c:864:7: error: implicit declaration of function 
>> 'gpio_is_valid' [-Werror=implicit-function-declaration]
  if (gpio_is_valid(host->pdata->gpio_power))
  ^
>> drivers/mmc/host/jz4740_mmc.c:865:4: error: implicit declaration of function 
>> 'gpio_set_value' [-Werror=implicit-function-declaration]
   gpio_set_value(host->pdata->gpio_power,
   ^~
   drivers/mmc/host/jz4740_mmc.c: In function 'jz4740_mmc_request_gpio':
>> drivers/mmc/host/jz4740_mmc.c:916:8: error: implicit declaration of function 
>> 'gpio_request' [-Werror=implicit-function-declaration]
 ret = gpio_request(gpio, name);
   ^~~~
>> drivers/mmc/host/jz4740_mmc.c:923:3: error: implicit declaration of function 
>> 'gpio_direction_output' [-Werror=implicit-function-declaration]
  gpio_direction_output(gpio, value);
  ^
>> drivers/mmc/host/jz4740_mmc.c:925:3: error: implicit declaration of function 
>> 'gpio_direction_input' [-Werror=implicit-function-declaration]
  gpio_direction_input(gpio);
  ^~~~
   drivers/mmc/host/jz4740_mmc.c: In function 'jz4740_mmc_free_gpios':
>> drivers/mmc/host/jz4740_mmc.c:968:3: error: implicit declaration of function 
>> 'gpio_free' [-Werror=implicit-function-declaration]
  gpio_free(pdata->gpio_power);
  ^
   cc1: some warnings being treated as errors

vim +/gpio_is_valid +864 drivers/mmc/host/jz4740_mmc.c

61bfbdb8 Lars-Peter Clausen 2010-07-15  858 if (ios->clock)
61bfbdb8 Lars-Peter Clausen 2010-07-15  859 
jz4740_mmc_set_clock_rate(host, ios->clock);
61bfbdb8 Lars-Peter Clausen 2010-07-15  860  
61bfbdb8 Lars-Peter Clausen 2010-07-15  861 switch (ios->power_mode) {
61bfbdb8 Lars-Peter Clausen 2010-07-15  862 case MMC_POWER_UP:
61bfbdb8 Lars-Peter Clausen 2010-07-15  863 jz4740_mmc_reset(host);
61bfbdb8 Lars-Peter Clausen 2010-07-15 @864 if 
(gpio_is_valid(host->pdata->gpio_power))
61bfbdb8 Lars-Peter Clausen 2010-07-15 @865 
gpio_set_value(host->pdata->gpio_power,
61bfbdb8 Lars-Peter Clausen 2010-07-15  866 
!host->pdata->power_active_low);
61bfbdb8 Lars-Peter Clausen 2010-07-15  867 host->cmdat |= 
JZ_MMC_CMDAT_INIT;
fca9661c Lars-Peter Clausen 2013-05-12  868 
clk_prepare_enable(host->clk);
61bfbdb8 Lars-Peter Clausen 2010-07-15  869 break;
61bfbdb8 Lars-Peter Clausen 2010-07-15  870 case MMC_POWER_ON:
61bfbdb8 Lars-Peter Clausen 2010-07-15  871 break;
61bfbdb8 Lars-Peter Clausen 2010-07-15  872 default:
61bfbdb8 Lars-Peter Clausen 2010-07-15  873 if 
(gpio_is_valid(host->pdata->gpio_power))
61bfbdb8 Lars-Peter Clausen 2010-07-15  874 
gpio_set_value(host->pdata->gpio_power,
61bfbdb8 Lars-Peter Clausen 2010-07-15  875 
host->pdata->power_active_low);
fca9661c Lars-Peter Clausen 2013-05-12  876 
clk_disable_unprepare(host->clk);
61bfbdb8 Lars-Peter Clausen 2010-07-15  877 break;
61bfbdb8 Lars-Peter Clausen 2010-07-15  878 }
61bfbdb8 Lars-Peter Clausen 2010-07-15  879  
61bfbdb8 Lars-Peter Clausen 2010-07-15  880 switch (ios->bus_width) {
61bfbdb8 Lars-Peter Clausen 2010-07-15  881 case MMC_BUS_WIDTH_1:
61bfbdb8 Lars-Peter Clausen 2010-07-15  882 host->cmdat &= 
~JZ_MMC_CMDAT_BUS_WIDTH_4BIT;
61bfbdb8 Lars-Peter Clausen 2010-07-15  883 break;
61bfbdb8 Lars-Peter Clausen 2010-07-15  884 case MMC_BUS_WIDTH_4:
61bfbdb8 Lars-Peter Clausen 2010-07-15  885 host->cmdat |= 
JZ_MMC_CMDAT_BUS_WIDTH_4BIT;
61bfbdb8 Lars-Peter Clausen 2010-07-15  886 break;
61bfbdb8 Lars-Peter Clausen 2010-07-15  887 default:
61bfbdb8 Lars-Peter Clausen 2010-07-15  888 break;
61bfbdb8 Lars-Peter Clausen 2010-07-15  889 }
61bfbdb8 Lars-Peter Clausen 2010-07-15  890  }
61bfbdb8 Lars-Peter Clausen 2010-07-15  891

Re: [PATCH v3 10/14] mmc: jz4740: Let the pinctrl driver configure the pins

[kbuild test robot]

Hi Paul,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc5 next-20170125]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Paul-Cercueil/Ingenic-JZ4740-JZ4780-pinctrl-driver/20170126-030028
config: mips-qi_lb60_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

   drivers/mmc/host/jz4740_mmc.c: In function 'jz4740_mmc_set_ios':
>> drivers/mmc/host/jz4740_mmc.c:864:7: error: implicit declaration of function 
>> 'gpio_is_valid' [-Werror=implicit-function-declaration]
  if (gpio_is_valid(host->pdata->gpio_power))
  ^
>> drivers/mmc/host/jz4740_mmc.c:865:4: error: implicit declaration of function 
>> 'gpio_set_value' [-Werror=implicit-function-declaration]
   gpio_set_value(host->pdata->gpio_power,
   ^~
   drivers/mmc/host/jz4740_mmc.c: In function 'jz4740_mmc_request_gpio':
>> drivers/mmc/host/jz4740_mmc.c:916:8: error: implicit declaration of function 
>> 'gpio_request' [-Werror=implicit-function-declaration]
 ret = gpio_request(gpio, name);
   ^~~~
>> drivers/mmc/host/jz4740_mmc.c:923:3: error: implicit declaration of function 
>> 'gpio_direction_output' [-Werror=implicit-function-declaration]
  gpio_direction_output(gpio, value);
  ^
>> drivers/mmc/host/jz4740_mmc.c:925:3: error: implicit declaration of function 
>> 'gpio_direction_input' [-Werror=implicit-function-declaration]
  gpio_direction_input(gpio);
  ^~~~
   drivers/mmc/host/jz4740_mmc.c: In function 'jz4740_mmc_free_gpios':
>> drivers/mmc/host/jz4740_mmc.c:968:3: error: implicit declaration of function 
>> 'gpio_free' [-Werror=implicit-function-declaration]
  gpio_free(pdata->gpio_power);
  ^
   cc1: some warnings being treated as errors

vim +/gpio_is_valid +864 drivers/mmc/host/jz4740_mmc.c

61bfbdb8 Lars-Peter Clausen 2010-07-15  858 if (ios->clock)
61bfbdb8 Lars-Peter Clausen 2010-07-15  859 
jz4740_mmc_set_clock_rate(host, ios->clock);
61bfbdb8 Lars-Peter Clausen 2010-07-15  860  
61bfbdb8 Lars-Peter Clausen 2010-07-15  861 switch (ios->power_mode) {
61bfbdb8 Lars-Peter Clausen 2010-07-15  862 case MMC_POWER_UP:
61bfbdb8 Lars-Peter Clausen 2010-07-15  863 jz4740_mmc_reset(host);
61bfbdb8 Lars-Peter Clausen 2010-07-15 @864 if 
(gpio_is_valid(host->pdata->gpio_power))
61bfbdb8 Lars-Peter Clausen 2010-07-15 @865 
gpio_set_value(host->pdata->gpio_power,
61bfbdb8 Lars-Peter Clausen 2010-07-15  866 
!host->pdata->power_active_low);
61bfbdb8 Lars-Peter Clausen 2010-07-15  867 host->cmdat |= 
JZ_MMC_CMDAT_INIT;
fca9661c Lars-Peter Clausen 2013-05-12  868 
clk_prepare_enable(host->clk);
61bfbdb8 Lars-Peter Clausen 2010-07-15  869 break;
61bfbdb8 Lars-Peter Clausen 2010-07-15  870 case MMC_POWER_ON:
61bfbdb8 Lars-Peter Clausen 2010-07-15  871 break;
61bfbdb8 Lars-Peter Clausen 2010-07-15  872 default:
61bfbdb8 Lars-Peter Clausen 2010-07-15  873 if 
(gpio_is_valid(host->pdata->gpio_power))
61bfbdb8 Lars-Peter Clausen 2010-07-15  874 
gpio_set_value(host->pdata->gpio_power,
61bfbdb8 Lars-Peter Clausen 2010-07-15  875 
host->pdata->power_active_low);
fca9661c Lars-Peter Clausen 2013-05-12  876 
clk_disable_unprepare(host->clk);
61bfbdb8 Lars-Peter Clausen 2010-07-15  877 break;
61bfbdb8 Lars-Peter Clausen 2010-07-15  878 }
61bfbdb8 Lars-Peter Clausen 2010-07-15  879  
61bfbdb8 Lars-Peter Clausen 2010-07-15  880 switch (ios->bus_width) {
61bfbdb8 Lars-Peter Clausen 2010-07-15  881 case MMC_BUS_WIDTH_1:
61bfbdb8 Lars-Peter Clausen 2010-07-15  882 host->cmdat &= 
~JZ_MMC_CMDAT_BUS_WIDTH_4BIT;
61bfbdb8 Lars-Peter Clausen 2010-07-15  883 break;
61bfbdb8 Lars-Peter Clausen 2010-07-15  884 case MMC_BUS_WIDTH_4:
61bfbdb8 Lars-Peter Clausen 2010-07-15  885 host->cmdat |= 
JZ_MMC_CMDAT_BUS_WIDTH_4BIT;
61bfbdb8 Lars-Peter Clausen 2010-07-15  886 break;
61bfbdb8 Lars-Peter Clausen 2010-07-15  887 default:
61bfbdb8 Lars-Peter Clausen 2010-07-15  888 break;
61bfbdb8 Lars-Peter Clausen 2010-07-15  889 }
61bfbdb8 Lars-Peter Clausen 2010-07-15  890  }
61bfbdb8 Lars-Peter Clausen 2010-07-15  891

RE: [PATCH] Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()

[Dexuan Cui]

> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Wednesday, January 25, 2017 00:08
> To: Dexuan Cui 
> Cc: gre...@linuxfoundation.org; driverdev-de...@linuxdriverproject.org; KY
> Srinivasan ; Haiyang Zhang ;
> Stephen Hemminger ; o...@aepfle.de; Rolf
> Neugebauer ; jasow...@redhat.com; linux-
> ker...@vger.kernel.org; a...@canonical.com
> Subject: Re: [PATCH] Drivers: hv: vmbus: finally fix 
> hv_need_to_signal_on_read()
> 
> On Tue, 24 Jan 2017 06:54:46 +
> Dexuan Cui  wrote:
> 
> > +static inline void
> > +init_cached_read_index(struct vmbus_channel *channel)
> > +{
> > +   struct hv_ring_buffer_info *rbi = >inbound;
> > +
> > +   rbi->cached_read_index = rbi->ring_buffer->read_index;
> > +}
> 
> Looks good thanks. This should go in right away. Which versions are impacted?
> Should it also go to stable?

Yes, it needs to go to stable.
I have Cc-ed   in the patch's changelog, so it should be
included in the stable tree automatically.

As I checked against the kernels listed on the homapage of www.kernel.org, the
below versions are impacted:
v3.16.39
v3.18.47
v4.1.38
v4.8.17
v4.9.5
v4.10-rc5

It's interesting v4.4.44 is not impacted, but actually it needs both the 2 
patches:
i.e. this patch, and the previous one:
Commit a389fcfd2cb5 ("Drivers: hv: vmbus: Fix signaling logic in 
hv_need_to_signal_on_read()")

> In a future patch, the API function names for interacting with the ring buffer
> should be changed to all have common prefix (hv_) and maybe do a little
> rethinking  about what needs to be in ring buffer and what could be local 
> variables.
> 
> For example, the cached_read_index is only useful over the span of the loop
> reading from the ring buffer. For me, it would be cleaner with a ring_buffer
> iterator object which could abstract the API better.
> 
>   struct vmbus_ringbuffer_iter iter;
> 
>   vmbus_begin_read(, channel);
>   while ((desc = vmbus_next_read(), channel) {
>   ...
>   }
>   vmbus_end_read(, channel);

I agree. Please help to clean all these up.  :-)

Thanks,
-- Dexuan

RE: [PATCH] Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()

[Dexuan Cui]

> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Wednesday, January 25, 2017 00:08
> To: Dexuan Cui 
> Cc: gre...@linuxfoundation.org; driverdev-de...@linuxdriverproject.org; KY
> Srinivasan ; Haiyang Zhang ;
> Stephen Hemminger ; o...@aepfle.de; Rolf
> Neugebauer ; jasow...@redhat.com; linux-
> ker...@vger.kernel.org; a...@canonical.com
> Subject: Re: [PATCH] Drivers: hv: vmbus: finally fix 
> hv_need_to_signal_on_read()
> 
> On Tue, 24 Jan 2017 06:54:46 +
> Dexuan Cui  wrote:
> 
> > +static inline void
> > +init_cached_read_index(struct vmbus_channel *channel)
> > +{
> > +   struct hv_ring_buffer_info *rbi = >inbound;
> > +
> > +   rbi->cached_read_index = rbi->ring_buffer->read_index;
> > +}
> 
> Looks good thanks. This should go in right away. Which versions are impacted?
> Should it also go to stable?

Yes, it needs to go to stable.
I have Cc-ed   in the patch's changelog, so it should be
included in the stable tree automatically.

As I checked against the kernels listed on the homapage of www.kernel.org, the
below versions are impacted:
v3.16.39
v3.18.47
v4.1.38
v4.8.17
v4.9.5
v4.10-rc5

It's interesting v4.4.44 is not impacted, but actually it needs both the 2 
patches:
i.e. this patch, and the previous one:
Commit a389fcfd2cb5 ("Drivers: hv: vmbus: Fix signaling logic in 
hv_need_to_signal_on_read()")

> In a future patch, the API function names for interacting with the ring buffer
> should be changed to all have common prefix (hv_) and maybe do a little
> rethinking  about what needs to be in ring buffer and what could be local 
> variables.
> 
> For example, the cached_read_index is only useful over the span of the loop
> reading from the ring buffer. For me, it would be cleaner with a ring_buffer
> iterator object which could abstract the API better.
> 
>   struct vmbus_ringbuffer_iter iter;
> 
>   vmbus_begin_read(, channel);
>   while ((desc = vmbus_next_read(), channel) {
>   ...
>   }
>   vmbus_end_read(, channel);

I agree. Please help to clean all these up.  :-)

Thanks,
-- Dexuan

Re: [v3 PATCH 04/10] x86/insn-kernel: Add a function to obtain register offset in ModRM

[Ricardo Neri]

Hi Masami,

On Thu, 2017-01-26 at 11:11 +0900, Masami Hiramatsu wrote:
> On Wed, 25 Jan 2017 12:23:47 -0800
> Ricardo Neri  wrote:
> 
> > The function insn_get_reg_offset requires a type to indicate whether
> > the returned offset is that given by by the ModRM or the SIB byte.
> > Callers of this function would need the definition of the type struct.
> > This is not needed. Instead, auxiliary functions can be defined for
> > this purpose.
> > 
> > When the operand is a register, the emulation code for User-Mode
> > Instruction Prevention needs to know the offset of the register indicated
> > in the r/m part of the ModRM byte. Thus, start by adding an auxiliary
> > function for this purpose.
> 
> Hmm, why wouldn't you just rename it to insn_get_reg_offset() and export it?

Do you mean exporting the structure that I mention above? The problem
that I am trying to solve is that callers sometimes want to know the
offset of the register encoded in the SiB or the ModRM bytes. I could
use something 

insn_get_reg_offset(insn, regs, INSN_TYPE_MODRM)
insn_get_reg_offset(insn, regs, INSN_TYPE_SIB)

Instead, I opted for

insn_get_reg_offset_rm(insn, regs)
insn_get_reg_offset_sib(insn, regs)

to avoid exposing an enum with the INSN_TYPE_MODRM, INSN_TYPE_SIB.

If you feel that the former makes more sense, I can change the
implementation.

Thanks and BR,
Ricardo
> 
> Thank you,
> 
> > 
> > Cc: Dave Hansen 
> > Cc: Adam Buchbinder 
> > Cc: Colin Ian King 
> > Cc: Lorenzo Stoakes 
> > Cc: Qiaowei Ren 
> > Cc: Arnaldo Carvalho de Melo 
> > Cc: Masami Hiramatsu 
> > Cc: Adrian Hunter 
> > Cc: Kees Cook 
> > Cc: Thomas Garnier 
> > Cc: Peter Zijlstra 
> > Cc: Borislav Petkov 
> > Cc: Dmitry Vyukov 
> > Cc: Ravi V. Shankar 
> > Cc: x...@kernel.org
> > Signed-off-by: Ricardo Neri 
> > ---
> >  arch/x86/include/asm/insn-kernel.h | 1 +
> >  arch/x86/lib/insn-kernel.c | 5 +
> >  2 files changed, 6 insertions(+)
> > 
> > diff --git a/arch/x86/include/asm/insn-kernel.h 
> > b/arch/x86/include/asm/insn-kernel.h
> > index aef416a..3f34649 100644
> > --- a/arch/x86/include/asm/insn-kernel.h
> > +++ b/arch/x86/include/asm/insn-kernel.h
> > @@ -12,5 +12,6 @@
> >  #include 
> >  
> >  void __user *insn_get_addr_ref(struct insn *insn, struct pt_regs *regs);
> > +int insn_get_reg_offset_rm(struct insn *insn, struct pt_regs *regs);
> >  
> >  #endif /* _ASM_X86_INSN_KERNEL_H */
> > diff --git a/arch/x86/lib/insn-kernel.c b/arch/x86/lib/insn-kernel.c
> > index 8072abe..267cab4 100644
> > --- a/arch/x86/lib/insn-kernel.c
> > +++ b/arch/x86/lib/insn-kernel.c
> > @@ -95,6 +95,11 @@ static int get_reg_offset(struct insn *insn, struct 
> > pt_regs *regs,
> > return regoff[regno];
> >  }
> >  
> > +int insn_get_reg_offset_rm(struct insn *insn, struct pt_regs *regs)
> > +{
> > +   return get_reg_offset(insn, regs, REG_TYPE_RM);
> > +}
> > +
> >  /*
> >   * return the address being referenced be instruction
> >   * for rm=3 returning the content of the rm reg
> > -- 
> > 2.9.3
> > 
> 
> 

Re: [v3 PATCH 04/10] x86/insn-kernel: Add a function to obtain register offset in ModRM

[Ricardo Neri]

Hi Masami,

On Thu, 2017-01-26 at 11:11 +0900, Masami Hiramatsu wrote:
> On Wed, 25 Jan 2017 12:23:47 -0800
> Ricardo Neri  wrote:
> 
> > The function insn_get_reg_offset requires a type to indicate whether
> > the returned offset is that given by by the ModRM or the SIB byte.
> > Callers of this function would need the definition of the type struct.
> > This is not needed. Instead, auxiliary functions can be defined for
> > this purpose.
> > 
> > When the operand is a register, the emulation code for User-Mode
> > Instruction Prevention needs to know the offset of the register indicated
> > in the r/m part of the ModRM byte. Thus, start by adding an auxiliary
> > function for this purpose.
> 
> Hmm, why wouldn't you just rename it to insn_get_reg_offset() and export it?

Do you mean exporting the structure that I mention above? The problem
that I am trying to solve is that callers sometimes want to know the
offset of the register encoded in the SiB or the ModRM bytes. I could
use something 

insn_get_reg_offset(insn, regs, INSN_TYPE_MODRM)
insn_get_reg_offset(insn, regs, INSN_TYPE_SIB)

Instead, I opted for

insn_get_reg_offset_rm(insn, regs)
insn_get_reg_offset_sib(insn, regs)

to avoid exposing an enum with the INSN_TYPE_MODRM, INSN_TYPE_SIB.

If you feel that the former makes more sense, I can change the
implementation.

Thanks and BR,
Ricardo
> 
> Thank you,
> 
> > 
> > Cc: Dave Hansen 
> > Cc: Adam Buchbinder 
> > Cc: Colin Ian King 
> > Cc: Lorenzo Stoakes 
> > Cc: Qiaowei Ren 
> > Cc: Arnaldo Carvalho de Melo 
> > Cc: Masami Hiramatsu 
> > Cc: Adrian Hunter 
> > Cc: Kees Cook 
> > Cc: Thomas Garnier 
> > Cc: Peter Zijlstra 
> > Cc: Borislav Petkov 
> > Cc: Dmitry Vyukov 
> > Cc: Ravi V. Shankar 
> > Cc: x...@kernel.org
> > Signed-off-by: Ricardo Neri 
> > ---
> >  arch/x86/include/asm/insn-kernel.h | 1 +
> >  arch/x86/lib/insn-kernel.c | 5 +
> >  2 files changed, 6 insertions(+)
> > 
> > diff --git a/arch/x86/include/asm/insn-kernel.h 
> > b/arch/x86/include/asm/insn-kernel.h
> > index aef416a..3f34649 100644
> > --- a/arch/x86/include/asm/insn-kernel.h
> > +++ b/arch/x86/include/asm/insn-kernel.h
> > @@ -12,5 +12,6 @@
> >  #include 
> >  
> >  void __user *insn_get_addr_ref(struct insn *insn, struct pt_regs *regs);
> > +int insn_get_reg_offset_rm(struct insn *insn, struct pt_regs *regs);
> >  
> >  #endif /* _ASM_X86_INSN_KERNEL_H */
> > diff --git a/arch/x86/lib/insn-kernel.c b/arch/x86/lib/insn-kernel.c
> > index 8072abe..267cab4 100644
> > --- a/arch/x86/lib/insn-kernel.c
> > +++ b/arch/x86/lib/insn-kernel.c
> > @@ -95,6 +95,11 @@ static int get_reg_offset(struct insn *insn, struct 
> > pt_regs *regs,
> > return regoff[regno];
> >  }
> >  
> > +int insn_get_reg_offset_rm(struct insn *insn, struct pt_regs *regs)
> > +{
> > +   return get_reg_offset(insn, regs, REG_TYPE_RM);
> > +}
> > +
> >  /*
> >   * return the address being referenced be instruction
> >   * for rm=3 returning the content of the rm reg
> > -- 
> > 2.9.3
> > 
> 
> 

Re: [PATCH v2] clk: samsung: mark s3c...._clk_sleep_init() as __init

[Krzysztof Kozlowski]

On Wed, Jan 25, 2017 at 10:42:25PM +0100, mar...@kaiser.cx wrote:
> From: Martin Kaiser 
> 
> These functions are referencing s3c_clk_regs[], which are marked as
> __initdata. When compiling with CONFIG_DEBUG_SECTION_MISMATCH=y, this
> produces warnings like
> 
> WARNING: vmlinux.o(.text+0x198350):
> Section mismatch in reference from the function s3c2410_clk_sleep_init()
> to the (unknown reference) .init.data:(unknown)
> 
> Mark the s3c_clk_sleep_init() functions as __init in
> order to fix this.
> 
> Signed-off-by: Martin Kaiser 
> ---
> v2:
> Fix the commit message, describe what the problem really is.
> (Thanks, Krzysztof)
> 
>  drivers/clk/samsung/clk-s3c2410.c |4 ++--
>  drivers/clk/samsung/clk-s3c2412.c |4 ++--
>  drivers/clk/samsung/clk-s3c2443.c |4 ++--
>  drivers/clk/samsung/clk-s3c64xx.c |4 ++--
>  4 files changed, 8 insertions(+), 8 deletions(-)
> 

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH v2] clk: samsung: mark s3c...._clk_sleep_init() as __init

[Krzysztof Kozlowski]

On Wed, Jan 25, 2017 at 10:42:25PM +0100, mar...@kaiser.cx wrote:
> From: Martin Kaiser 
> 
> These functions are referencing s3c_clk_regs[], which are marked as
> __initdata. When compiling with CONFIG_DEBUG_SECTION_MISMATCH=y, this
> produces warnings like
> 
> WARNING: vmlinux.o(.text+0x198350):
> Section mismatch in reference from the function s3c2410_clk_sleep_init()
> to the (unknown reference) .init.data:(unknown)
> 
> Mark the s3c_clk_sleep_init() functions as __init in
> order to fix this.
> 
> Signed-off-by: Martin Kaiser 
> ---
> v2:
> Fix the commit message, describe what the problem really is.
> (Thanks, Krzysztof)
> 
>  drivers/clk/samsung/clk-s3c2410.c |4 ++--
>  drivers/clk/samsung/clk-s3c2412.c |4 ++--
>  drivers/clk/samsung/clk-s3c2443.c |4 ++--
>  drivers/clk/samsung/clk-s3c64xx.c |4 ++--
>  4 files changed, 8 insertions(+), 8 deletions(-)
> 

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.

[Fu Wei]

Hi Mark, Christopher,

On 26 January 2017 at 01:36, Mark Rutland  wrote:
> On Wed, Jan 25, 2017 at 10:38:01AM -0500, Christopher Covington wrote:
>> On 01/25/2017 01:46 AM, Fu Wei wrote:
>> > On 25 January 2017 at 01:24, Mark Rutland  wrote:
>> >> On Wed, Jan 18, 2017 at 09:25:32PM +0800, fu@linaro.org wrote:
>> >>> From: Fu Wei 
>
>> > And for CNTFRQ(in CNTCTLBase and CNTBaseN) , we can NOT access it in
>> > Linux kernel (EL1),
>> > Because ARMv8 ARM says:
>> > In a system that implements both Secure and Non-secure states, this
>> > register is only accessible by Secure accesses.
>> > That means we still need to get the frequency of the system counter
>> > from CNTFRQ_EL0 in MMIO timer code.
>> > This have been proved when I tested this driver on foundation model, I
>> > got "0" when I access CNTFRQ from Linux kernel (Non-secure EL1)
>>
>> That sounds like a firmware problem. Firmware in EL3 is supposed to write
>> the value into CNTFRQ.
>
> Definitely. FW *should* program the CNTFRQ_EL0 CPU registers and any
> MMIO CNTFRQ registers.

Many thanks for the explanation. This might be the problem. Maybe we
can check the UEFI :-)

>
>> If you're not currently using any firmware, I'd
>> recommend the bootwrapper on models/simulators/emulators.
>>
>> http://git.kernel.org/cgit/linux/kernel/git/mark/boot-wrapper-aarch64.git/tree/arch/aarch64/boot.S#n48
>
> Unfortunately, the boot-wrapper only programs the CNTFRQ_EL0 CPU system
> registers, and does not program any MMIO CNTFRQ registers.
>
> IIRC the models it was originally written for didn't have any (and we
> had no DT binding until far later...). Luckily the model DTs do not
> expose any MMIO timer addresses to the kernel currently.

But according to another document(ARMv8-A Foundation Platform User
Guide  ARM DUI0677K), Table 3-2 ARMv8-A Foundation Platform memory
map,
we may have two frames in the Generic timer block, right?


>
> Thanks,
> Mark.



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.

[Fu Wei]

Hi Mark, Christopher,

On 26 January 2017 at 01:36, Mark Rutland  wrote:
> On Wed, Jan 25, 2017 at 10:38:01AM -0500, Christopher Covington wrote:
>> On 01/25/2017 01:46 AM, Fu Wei wrote:
>> > On 25 January 2017 at 01:24, Mark Rutland  wrote:
>> >> On Wed, Jan 18, 2017 at 09:25:32PM +0800, fu@linaro.org wrote:
>> >>> From: Fu Wei 
>
>> > And for CNTFRQ(in CNTCTLBase and CNTBaseN) , we can NOT access it in
>> > Linux kernel (EL1),
>> > Because ARMv8 ARM says:
>> > In a system that implements both Secure and Non-secure states, this
>> > register is only accessible by Secure accesses.
>> > That means we still need to get the frequency of the system counter
>> > from CNTFRQ_EL0 in MMIO timer code.
>> > This have been proved when I tested this driver on foundation model, I
>> > got "0" when I access CNTFRQ from Linux kernel (Non-secure EL1)
>>
>> That sounds like a firmware problem. Firmware in EL3 is supposed to write
>> the value into CNTFRQ.
>
> Definitely. FW *should* program the CNTFRQ_EL0 CPU registers and any
> MMIO CNTFRQ registers.

Many thanks for the explanation. This might be the problem. Maybe we
can check the UEFI :-)

>
>> If you're not currently using any firmware, I'd
>> recommend the bootwrapper on models/simulators/emulators.
>>
>> http://git.kernel.org/cgit/linux/kernel/git/mark/boot-wrapper-aarch64.git/tree/arch/aarch64/boot.S#n48
>
> Unfortunately, the boot-wrapper only programs the CNTFRQ_EL0 CPU system
> registers, and does not program any MMIO CNTFRQ registers.
>
> IIRC the models it was originally written for didn't have any (and we
> had no DT binding until far later...). Luckily the model DTs do not
> expose any MMIO timer addresses to the kernel currently.

But according to another document(ARMv8-A Foundation Platform User
Guide  ARM DUI0677K), Table 3-2 ARMv8-A Foundation Platform memory
map,
we may have two frames in the Generic timer block, right?


>
> Thanks,
> Mark.



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

Re: [v3 PATCH 07/10] x86: Add emulation code for UMIP instructions

[Ricardo Neri]

On Wed, 2017-01-25 at 12:38 -0800, H. Peter Anvin wrote:
> On 01/25/17 12:23, Ricardo Neri wrote:
> > +   case UMIP_SMSW:
> > +   dummy_value = CR0_STATE;
> 
> Unless the user space process is running in 64-bit mode this value
> should be & 0x.

But wouldn't that prevent the bits CR0[63:16] or CR0[31:16] from being
copied when a register operand is used? According to the Intel Software
Development manual, SMSW returns 

SMSW r16 operand size 16, store CR0[15:0] in r16
SMSW r32 operand size 32, zero-extend CR0[31:0], and store in r32
SMSW r64 operand size 64, zero-extend CR0[63:0], and store in r64

The number of bytes returned by the emulated results is controlled by
the data_size variable. If it finds that the result will be saved in a
memory location, it will only copy CR0[15:0], which is the expected
behavior of SMSW if the result is to be copied in memory.

>  I'm not sure if we should even support fixing up
> UMIP instructions in 64-bit mode.

Probably not. The whole point of the emulation was to support
virtual-8086 mode and 32-bit mode.
> 
> Also, please put an explicit /* fall through */ here.

Will do.
> 
> > +   /*
> > +* These two instructions return a 16-bit value. We return
> > +* all zeros. This is equivalent to a null descriptor for
> > +* str and sldt.
> > +*/
> > +   case UMIP_SLDT:
> > +   case UMIP_STR:
> > +   /* if operand is a register, it is zero-extended*/
> > +   if (X86_MODRM_MOD(insn->modrm.value) == 3) {
> > +   memset(data, 0, insn->opnd_bytes);
> > +   *data_size = insn->opnd_bytes;
> > +   /* if not, only the two least significant bytes are copied */
> > +   } else {
> > +   *data_size = 2;
> > +   }
> > +   memcpy(data, _value, sizeof(dummy_value));
> > +   break;

The code above controls how many bytes are copied as the result of SMSW.

> > +   default:
> > +   return -EINVAL;
> > +   }
> > +   return 0;
> 
> 
> > +bool fixup_umip_exception(struct pt_regs *regs)
> > +{
> > +   struct insn insn;
> > +   unsigned char buf[MAX_INSN_SIZE];
> > +   /* 10 bytes is the maximum size of the result of UMIP instructions */
> > +   unsigned char dummy_data[10] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
> > +#ifdef CONFIG_X86_64
> > +   int x86_64 = user_64bit_mode(regs);
> > +#else
> > +   int x86_64 = 0;
> > +#endif
> 
> Again, could we simply do:
> 
>   if (user_64bit_mode(regs))
>   return false;
> 
> or are there known users of these instructions *in 64-bit mode*?

I am not aware of any. In that case, I will make this code return in
this case.

Thanks and BR,
Ricardo
> 
>   -hpa
> 
> 

Re: [v3 PATCH 07/10] x86: Add emulation code for UMIP instructions

[Ricardo Neri]

On Wed, 2017-01-25 at 12:38 -0800, H. Peter Anvin wrote:
> On 01/25/17 12:23, Ricardo Neri wrote:
> > +   case UMIP_SMSW:
> > +   dummy_value = CR0_STATE;
> 
> Unless the user space process is running in 64-bit mode this value
> should be & 0x.

But wouldn't that prevent the bits CR0[63:16] or CR0[31:16] from being
copied when a register operand is used? According to the Intel Software
Development manual, SMSW returns 

SMSW r16 operand size 16, store CR0[15:0] in r16
SMSW r32 operand size 32, zero-extend CR0[31:0], and store in r32
SMSW r64 operand size 64, zero-extend CR0[63:0], and store in r64

The number of bytes returned by the emulated results is controlled by
the data_size variable. If it finds that the result will be saved in a
memory location, it will only copy CR0[15:0], which is the expected
behavior of SMSW if the result is to be copied in memory.

>  I'm not sure if we should even support fixing up
> UMIP instructions in 64-bit mode.

Probably not. The whole point of the emulation was to support
virtual-8086 mode and 32-bit mode.
> 
> Also, please put an explicit /* fall through */ here.

Will do.
> 
> > +   /*
> > +* These two instructions return a 16-bit value. We return
> > +* all zeros. This is equivalent to a null descriptor for
> > +* str and sldt.
> > +*/
> > +   case UMIP_SLDT:
> > +   case UMIP_STR:
> > +   /* if operand is a register, it is zero-extended*/
> > +   if (X86_MODRM_MOD(insn->modrm.value) == 3) {
> > +   memset(data, 0, insn->opnd_bytes);
> > +   *data_size = insn->opnd_bytes;
> > +   /* if not, only the two least significant bytes are copied */
> > +   } else {
> > +   *data_size = 2;
> > +   }
> > +   memcpy(data, _value, sizeof(dummy_value));
> > +   break;

The code above controls how many bytes are copied as the result of SMSW.

> > +   default:
> > +   return -EINVAL;
> > +   }
> > +   return 0;
> 
> 
> > +bool fixup_umip_exception(struct pt_regs *regs)
> > +{
> > +   struct insn insn;
> > +   unsigned char buf[MAX_INSN_SIZE];
> > +   /* 10 bytes is the maximum size of the result of UMIP instructions */
> > +   unsigned char dummy_data[10] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
> > +#ifdef CONFIG_X86_64
> > +   int x86_64 = user_64bit_mode(regs);
> > +#else
> > +   int x86_64 = 0;
> > +#endif
> 
> Again, could we simply do:
> 
>   if (user_64bit_mode(regs))
>   return false;
> 
> or are there known users of these instructions *in 64-bit mode*?

I am not aware of any. In that case, I will make this code return in
this case.

Thanks and BR,
Ricardo
> 
>   -hpa
> 
> 

Re: [PATCH] NFC: remove TI nfcwilink driver

[Marcel Holtmann]

Hi Rob,

> It appears that TI WiLink devices including NFC (WL185x/WL189x) never
> shipped. The only information I found were announcements in Feb
> 2012 about the parts. There's been no activity on this driver besided
> common changes since initially added in Jan 2012. There's also no in
> users that instantiate the platform device (nor DT bindings).
> 
> This is a first step in removing TI ST (shared transport) driver in
> favor of extending the BT hci_ll driver to support WL183x chips.

since the firmware files TINfcInit_* also never made it into the linux-firmware 
tree, I have no idea who is using this driver. I am actually fine with removing 
it since it would be easy enough to bring back based on hci_ll driver once 
there is hardware to test this on.

Regards

Marcel

Re: [PATCH] NFC: remove TI nfcwilink driver

[Marcel Holtmann]

Hi Rob,

> It appears that TI WiLink devices including NFC (WL185x/WL189x) never
> shipped. The only information I found were announcements in Feb
> 2012 about the parts. There's been no activity on this driver besided
> common changes since initially added in Jan 2012. There's also no in
> users that instantiate the platform device (nor DT bindings).
> 
> This is a first step in removing TI ST (shared transport) driver in
> favor of extending the BT hci_ll driver to support WL183x chips.

since the firmware files TINfcInit_* also never made it into the linux-firmware 
tree, I have no idea who is using this driver. I am actually fine with removing 
it since it would be easy enough to bring back based on hci_ll driver once 
there is hardware to test this on.

Regards

Marcel

Re: [PATCH v2] openrisc: migrate exception table users off module.h and onto extable.h

[Stafford Horne]

On Wed, Jan 25, 2017 at 04:40:46PM -0500, Paul Gortmaker wrote:
> These files were only including module.h for exception table related
> functions.  We've now separated that content out into its own file
> "extable.h" so now move over to that and avoid all the extra header
> content in module.h that we don't really need to compile these files.
> 
> Reported-by: kbuild test robot 
> Cc: Jonas Bonn 
> Cc: Stefan Kristiansson 
> Cc: Stafford Horne 
> Cc: openr...@lists.librecores.org
> Signed-off-by: Paul Gortmaker 
> ---
> 
> [v2: add traps.c to conversion, as without a toolchain, I'm at the
>  mercy of the things found by kbuild; fixing them iteratively... ]
> 
>  arch/openrisc/kernel/traps.c | 2 +-
>  arch/openrisc/mm/fault.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/openrisc/kernel/traps.c b/arch/openrisc/kernel/traps.c
> index a4574cb4b0fb..73abb3ff4fa3 100644
> --- a/arch/openrisc/kernel/traps.c
> +++ b/arch/openrisc/kernel/traps.c
> @@ -23,7 +23,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 

Is this correct or did you want extable.h?

>  #include 
>  #include 
>  #include 
> diff --git a/arch/openrisc/mm/fault.c b/arch/openrisc/mm/fault.c
> index b1a7435e786a..53592a639744 100644
> --- a/arch/openrisc/mm/fault.c
> +++ b/arch/openrisc/mm/fault.c
> @@ -17,7 +17,7 @@
>  
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  
>  #include 
> -- 
> 2.11.0
> 

Re: [PATCH v2] openrisc: migrate exception table users off module.h and onto extable.h

[Stafford Horne]

On Wed, Jan 25, 2017 at 04:40:46PM -0500, Paul Gortmaker wrote:
> These files were only including module.h for exception table related
> functions.  We've now separated that content out into its own file
> "extable.h" so now move over to that and avoid all the extra header
> content in module.h that we don't really need to compile these files.
> 
> Reported-by: kbuild test robot 
> Cc: Jonas Bonn 
> Cc: Stefan Kristiansson 
> Cc: Stafford Horne 
> Cc: openr...@lists.librecores.org
> Signed-off-by: Paul Gortmaker 
> ---
> 
> [v2: add traps.c to conversion, as without a toolchain, I'm at the
>  mercy of the things found by kbuild; fixing them iteratively... ]
> 
>  arch/openrisc/kernel/traps.c | 2 +-
>  arch/openrisc/mm/fault.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/openrisc/kernel/traps.c b/arch/openrisc/kernel/traps.c
> index a4574cb4b0fb..73abb3ff4fa3 100644
> --- a/arch/openrisc/kernel/traps.c
> +++ b/arch/openrisc/kernel/traps.c
> @@ -23,7 +23,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 

Is this correct or did you want extable.h?

>  #include 
>  #include 
>  #include 
> diff --git a/arch/openrisc/mm/fault.c b/arch/openrisc/mm/fault.c
> index b1a7435e786a..53592a639744 100644
> --- a/arch/openrisc/mm/fault.c
> +++ b/arch/openrisc/mm/fault.c
> @@ -17,7 +17,7 @@
>  
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  
>  #include 
> -- 
> 2.11.0
> 

Re: [RFC PATCH 0/5] userfaultfd: non-cooperative: better tracking for mapping changes

[Hillf Danton]

On January 24, 2017 9:52 PM Mike Rapoport wrote: 
> Hi,
> 
> These patches try to address issues I've encountered during integration of
> userfaultfd with CRIU.
> Previously added userfaultfd events for fork(), madvise() and mremap()
> unfortunately do not cover all possible changes to a process virtual memory
> layout required for uffd monitor.
> When one or more VMAs is removed from the process mm, the external uffd
> monitor has no way to detect those changes and will attempt to fill the
> removed regions with userfaultfd_copy.
> Another problematic event is the exit() of the process. Here again, the
> external uffd monitor will try to use userfaultfd_copy, although mm owning
> the memory has already gone.
> 
> The first patch in the series is a minor cleanup and it's not strictly
> related to the rest of the series.
> 
> The patches 2 and 3 below add UFFD_EVENT_UNMAP and UFFD_EVENT_EXIT to allow
> the uffd monitor track changes in the memory layout of a process.
> 
> The patches 4 and 5 amend error codes returned by userfaultfd_copy to make
> the uffd monitor able to cope with races that might occur between delivery
> of unmap and exit events and outstanding userfaultfd_copy's.
> 
> The patches are agains current -mm tree.
> 
> Mike Rapoport (5):
>   mm: call vm_munmap in munmap syscall instead of using open coded version
>   userfaultfd: non-cooperative: add event for memory unmaps
>   userfaultfd: non-cooperative: add event for exit() notification
>   userfaultfd: mcopy_atomic: return -ENOENT when no compatible VMA found
>   userfaultfd_copy: return -ENOSPC in case mm has gone
> 
>  arch/tile/mm/elf.c   |  2 +-
>  arch/x86/entry/vdso/vma.c|  2 +-
>  arch/x86/mm/mpx.c|  2 +-
>  fs/aio.c |  2 +-
>  fs/proc/vmcore.c |  4 +-
>  fs/userfaultfd.c | 91 
> 
>  include/linux/mm.h   | 14 ---
>  include/linux/userfaultfd_k.h| 25 +++
>  include/uapi/linux/userfaultfd.h |  8 +++-
>  ipc/shm.c|  6 +--
>  kernel/exit.c|  2 +
>  mm/mmap.c| 55 ++--
>  mm/mremap.c  | 23 ++
>  mm/userfaultfd.c | 42 ++-
>  mm/util.c|  5 ++-
>  15 files changed, 215 insertions(+), 68 deletions(-)
> 
> --
Acked-by: Hillf Danton 

Re: [RFC PATCH 0/5] userfaultfd: non-cooperative: better tracking for mapping changes

[Hillf Danton]

On January 24, 2017 9:52 PM Mike Rapoport wrote: 
> Hi,
> 
> These patches try to address issues I've encountered during integration of
> userfaultfd with CRIU.
> Previously added userfaultfd events for fork(), madvise() and mremap()
> unfortunately do not cover all possible changes to a process virtual memory
> layout required for uffd monitor.
> When one or more VMAs is removed from the process mm, the external uffd
> monitor has no way to detect those changes and will attempt to fill the
> removed regions with userfaultfd_copy.
> Another problematic event is the exit() of the process. Here again, the
> external uffd monitor will try to use userfaultfd_copy, although mm owning
> the memory has already gone.
> 
> The first patch in the series is a minor cleanup and it's not strictly
> related to the rest of the series.
> 
> The patches 2 and 3 below add UFFD_EVENT_UNMAP and UFFD_EVENT_EXIT to allow
> the uffd monitor track changes in the memory layout of a process.
> 
> The patches 4 and 5 amend error codes returned by userfaultfd_copy to make
> the uffd monitor able to cope with races that might occur between delivery
> of unmap and exit events and outstanding userfaultfd_copy's.
> 
> The patches are agains current -mm tree.
> 
> Mike Rapoport (5):
>   mm: call vm_munmap in munmap syscall instead of using open coded version
>   userfaultfd: non-cooperative: add event for memory unmaps
>   userfaultfd: non-cooperative: add event for exit() notification
>   userfaultfd: mcopy_atomic: return -ENOENT when no compatible VMA found
>   userfaultfd_copy: return -ENOSPC in case mm has gone
> 
>  arch/tile/mm/elf.c   |  2 +-
>  arch/x86/entry/vdso/vma.c|  2 +-
>  arch/x86/mm/mpx.c|  2 +-
>  fs/aio.c |  2 +-
>  fs/proc/vmcore.c |  4 +-
>  fs/userfaultfd.c | 91 
> 
>  include/linux/mm.h   | 14 ---
>  include/linux/userfaultfd_k.h| 25 +++
>  include/uapi/linux/userfaultfd.h |  8 +++-
>  ipc/shm.c|  6 +--
>  kernel/exit.c|  2 +
>  mm/mmap.c| 55 ++--
>  mm/mremap.c  | 23 ++
>  mm/userfaultfd.c | 42 ++-
>  mm/util.c|  5 ++-
>  15 files changed, 215 insertions(+), 68 deletions(-)
> 
> --
Acked-by: Hillf Danton 

Re: [v3 PATCH 00/10] x86: Enable User-Mode Instruction Prevention

[Ricardo Neri]

Hi Peter,
On Wed, 2017-01-25 at 12:34 -0800, H. Peter Anvin wrote:
> On 01/25/17 12:23, Ricardo Neri wrote:
> >  * SMSW returns the value with which the CR0 register is programmed in
> >head_32/64.S at boot time. This is, the following bits are enabed:
> >CR0.0 for Protection Enable, CR.1 for Monitor Coprocessor, CR.4 for
> >Extension Type, which will always be 1 in recent processors with UMIP;
> >CR.5 for Numeric Error, CR0.16 for Write Protect, CR0.18 for Alignment
> >Mask. Additionally, in x86_64, CR0.31 for Paging is set.
> 
> SMSW only returns CR0[15:0], so the reference here to CR0[31:16] seems odd.

I checked again the latest version (from Dec 2016) of the Intel Software
Development Manual. The documentation for SMSW states the following:

SMSW r16 operand size 16, store CR0[15:0] in r16
SMSW r32 operand size 32, zero-extend CR0[31:0], and store in r32
SMSW r64 operand size 64, zero-extend CR0[63:0], and store in r64

When the operand is a memory location, yes, it only returns CR0[15:0]

Also, in the tests that I ran I wrote the result of SMSW to a 64-bit
register. I get 0x80050033. It seems to me that it does write as many
bits as the register operand can hold.

Am I missing something?

Thanks and BR,
Ricardo
> 
>   -hpa
> 
> 

Re: [v3 PATCH 00/10] x86: Enable User-Mode Instruction Prevention

[Ricardo Neri]

Hi Peter,
On Wed, 2017-01-25 at 12:34 -0800, H. Peter Anvin wrote:
> On 01/25/17 12:23, Ricardo Neri wrote:
> >  * SMSW returns the value with which the CR0 register is programmed in
> >head_32/64.S at boot time. This is, the following bits are enabed:
> >CR0.0 for Protection Enable, CR.1 for Monitor Coprocessor, CR.4 for
> >Extension Type, which will always be 1 in recent processors with UMIP;
> >CR.5 for Numeric Error, CR0.16 for Write Protect, CR0.18 for Alignment
> >Mask. Additionally, in x86_64, CR0.31 for Paging is set.
> 
> SMSW only returns CR0[15:0], so the reference here to CR0[31:16] seems odd.

I checked again the latest version (from Dec 2016) of the Intel Software
Development Manual. The documentation for SMSW states the following:

SMSW r16 operand size 16, store CR0[15:0] in r16
SMSW r32 operand size 32, zero-extend CR0[31:0], and store in r32
SMSW r64 operand size 64, zero-extend CR0[63:0], and store in r64

When the operand is a memory location, yes, it only returns CR0[15:0]

Also, in the tests that I ran I wrote the result of SMSW to a 64-bit
register. I get 0x80050033. It seems to me that it does write as many
bits as the register operand can hold.

Am I missing something?

Thanks and BR,
Ricardo
> 
>   -hpa
> 
> 

Re: [v3 PATCH 05/10] x86/insn-kernel: Add support to resolve 16-bit addressing encodings

[Ricardo Neri]

On Wed, 2017-01-25 at 13:58 -0800, Andy Lutomirski wrote:
> On Wed, Jan 25, 2017 at 12:23 PM, Ricardo Neri
>  wrote:
> > Tasks running in virtual-8086 mode will use 16-bit addressing form
> > encodings as described in the Intel 64 and IA-32 Architecture Software
> > Developer's Manual Volume 2A Section 2.1.5. 16-bit addressing encodings
> > differ in several ways from the 32-bit/64-bit addressing form encodings:
> > the r/m part of the ModRM byte points to different registers and, in some
> > cases, addresses can be indicated by the addition of the value of two
> > registers. Also, there is no support for SiB bytes. Thus, a separate
> > function is needed to parse this form of addressing.
> >
> > Furthermore, virtual-8086 mode tasks will use real-mode addressing. This
> > implies that the segment selectors do not point to a segment descriptor
> > but are used to compute logical addresses. Hence, there is a need to
> > add support to compute addresses using the segment selectors. If segment-
> > override prefixes are present in the instructions, they take precedence.
> >
> > Lastly, it is important to note that when a tasks is running in virtual-
> > 8086 mode and an interrupt/exception occurs, the CPU pushes to the stack
> > the segment selectors for ds, es, fs and gs. These are accesible via the
> > struct kernel_vm86_regs rather than pt_regs.
> >
> > Code for 16-bit addressing encodings is likely to be used only by virtual-
> > 8086 mode tasks. Thus, this code is wrapped to be built only if the
> > option CONFIG_VM86 is selected.
> 
> That's not true.  It's used in 16-bit protected mode, too.  And there
> are (ugh!) six possibilities:

Thanks for the clarification. I will enable the decoding of addresses
for 16-bit as well... and test the emulation code. 
> 
>  - Normal 32-bit protected mode.  This should already work.
>  - Normal 64-bit protected mode.  This should also already work.  (I
> forget whether a 16-bit SS is either illegal or has no effect in this
> case.)

For these two cases I am just taking the effective address that the user
space application provides, given that the segment selectors were set
beforehand (and with a base of 0).

copy_to/from_user(kernel_buf, effective_address, sizeof(kernel_buf));

>  - Virtual 8086 mode

In this case I calculate the linear address as:
 (segment_select << 4) + effective address.

>  - Normal 16-bit protected mode, used by DOSEMU and Wine.  (16-bit CS,
> 16-bit address segment)
>  - 16-bit CS, 32-bit address segment.  IIRC this might be used by some
> 32-bit DOS programs to call BIOS.
>  - 32-bit CS, 16-bit address segment.  I don't know whether anything uses 
> this.

In all these protected modes, are you referring to the size in bits of
the base address of in the descriptor selected in the CS register? In
such a case I would need to get the base address and add it to the
effective address given in the operands of the instructions, right?
> 
> I don't know if anything you're doing cares about SS's, DS's, etc.

For 16-bit addressing encodings, I use DS for the BX, DI and SI
registers, and no register at all. I use SS for BP and SP. This can be
overridden by the segment selector prefixes. For 32/64-bit, I need to
implement segment selector awareness.

> size, but I suspect you'll need to handle 16-bit CS.

Unless I am missing what is special with the 16-bit base address, I only
would need to add that base address to whatever effective address (aka,
offset) is encoded in the ModRM and displacement bytes.

At this moment my implementation is able to decode the ModRM, SiB and
displacement bytes for 16-bit and 32/64-bit address encodings.

Thanks and BR,
Ricardo

Re: [v3 PATCH 05/10] x86/insn-kernel: Add support to resolve 16-bit addressing encodings

[Ricardo Neri]

On Wed, 2017-01-25 at 13:58 -0800, Andy Lutomirski wrote:
> On Wed, Jan 25, 2017 at 12:23 PM, Ricardo Neri
>  wrote:
> > Tasks running in virtual-8086 mode will use 16-bit addressing form
> > encodings as described in the Intel 64 and IA-32 Architecture Software
> > Developer's Manual Volume 2A Section 2.1.5. 16-bit addressing encodings
> > differ in several ways from the 32-bit/64-bit addressing form encodings:
> > the r/m part of the ModRM byte points to different registers and, in some
> > cases, addresses can be indicated by the addition of the value of two
> > registers. Also, there is no support for SiB bytes. Thus, a separate
> > function is needed to parse this form of addressing.
> >
> > Furthermore, virtual-8086 mode tasks will use real-mode addressing. This
> > implies that the segment selectors do not point to a segment descriptor
> > but are used to compute logical addresses. Hence, there is a need to
> > add support to compute addresses using the segment selectors. If segment-
> > override prefixes are present in the instructions, they take precedence.
> >
> > Lastly, it is important to note that when a tasks is running in virtual-
> > 8086 mode and an interrupt/exception occurs, the CPU pushes to the stack
> > the segment selectors for ds, es, fs and gs. These are accesible via the
> > struct kernel_vm86_regs rather than pt_regs.
> >
> > Code for 16-bit addressing encodings is likely to be used only by virtual-
> > 8086 mode tasks. Thus, this code is wrapped to be built only if the
> > option CONFIG_VM86 is selected.
> 
> That's not true.  It's used in 16-bit protected mode, too.  And there
> are (ugh!) six possibilities:

Thanks for the clarification. I will enable the decoding of addresses
for 16-bit as well... and test the emulation code. 
> 
>  - Normal 32-bit protected mode.  This should already work.
>  - Normal 64-bit protected mode.  This should also already work.  (I
> forget whether a 16-bit SS is either illegal or has no effect in this
> case.)

For these two cases I am just taking the effective address that the user
space application provides, given that the segment selectors were set
beforehand (and with a base of 0).

copy_to/from_user(kernel_buf, effective_address, sizeof(kernel_buf));

>  - Virtual 8086 mode

In this case I calculate the linear address as:
 (segment_select << 4) + effective address.

>  - Normal 16-bit protected mode, used by DOSEMU and Wine.  (16-bit CS,
> 16-bit address segment)
>  - 16-bit CS, 32-bit address segment.  IIRC this might be used by some
> 32-bit DOS programs to call BIOS.
>  - 32-bit CS, 16-bit address segment.  I don't know whether anything uses 
> this.

In all these protected modes, are you referring to the size in bits of
the base address of in the descriptor selected in the CS register? In
such a case I would need to get the base address and add it to the
effective address given in the operands of the instructions, right?
> 
> I don't know if anything you're doing cares about SS's, DS's, etc.

For 16-bit addressing encodings, I use DS for the BX, DI and SI
registers, and no register at all. I use SS for BP and SP. This can be
overridden by the segment selector prefixes. For 32/64-bit, I need to
implement segment selector awareness.

> size, but I suspect you'll need to handle 16-bit CS.

Unless I am missing what is special with the 16-bit base address, I only
would need to add that base address to whatever effective address (aka,
offset) is encoded in the ModRM and displacement bytes.

At this moment my implementation is able to decode the ModRM, SiB and
displacement bytes for 16-bit and 32/64-bit address encodings.

Thanks and BR,
Ricardo

Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.

[Fu Wei]

Hi Mark,

On 26 January 2017 at 01:25, Mark Rutland  wrote:
> On Wed, Jan 25, 2017 at 02:46:12PM +0800, Fu Wei wrote:
>> Hi Mark,
>
> Hi,
>
>> On 25 January 2017 at 01:24, Mark Rutland  wrote:
>> > On Wed, Jan 18, 2017 at 09:25:32PM +0800, fu@linaro.org wrote:
>> >> From: Fu Wei 
>> >>
>> >> The counter frequency detection call(arch_timer_detect_rate) combines two
>> >> ways to get counter frequency: system coprocessor register and MMIO timer.
>> >> But in a specific timer init code, we only need one way to try:
>> >> getting frequency from MMIO timer register will be needed only when we
>> >> init MMIO timer; getting frequency from system coprocessor register will
>> >> be needed only when we init arch timer.
>> >
>> > When I mentioned this splitting before, I had mean that we'd completely
>> > separate the two, with separate mmio_rate and sysreg_rate variables.
>>
>> sorry for misunderstanding.
>>
>> Are you saying :
>>
>> diff --git a/drivers/clocksource/arm_arch_timer.c
>> b/drivers/clocksource/arm_arch_timer.c
>> index 663a57a..eec92f6 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -65,7 +65,8 @@ struct arch_timer {
>>
>>  #define to_arch_timer(e) container_of(e, struct arch_timer, evt)
>>
>> -static u32 arch_timer_rate;
>> +static u32 arch_timer_sysreg_rate ;
>> +static u32 arch_timer_mmio_rate;
>>  static int arch_timer_ppi[ARCH_TIMER_MAX_TIMER_PPI];
>>
>>  static struct clock_event_device __percpu *arch_timer_evt;
>>
>>
>> But what have I learned From ARMv8 ARM is
>> AArch64 System register CNTFRQ_EL0 is provided so that software can
>> discover the frequency of the system counter.
>> CNTFRQ(in CNTCTLBase and CNTBaseN) is provided so that software can
>> discover the frequency of the system counter.
>> The bit assignments of the registers are identical in the System
>> register interface and in the memory-mapped system level interface.
>
> This means that the bits in the registers have the same meaning.
>
> However, they are separate registers, and must be written separately. A
> write to one does not propagate to the other, and they are not
> guaranteed to contain the same value.

Ah, Sorry for misunderstanding this, and thanks for correcting it,
I thought they point to the same register.

>
>> So I think they both contain the same value : the frequency of the
>> system counter, just in different view, and can be accessed in
>> different ways.
>
> Certainly, in theory, these *should* contain the same value.
>
> Unfortunately, in practice, on several systems, they do not. It is very
> easy to forget to initialise one of these registers correctly, and it's
> possible for some software to work (masking the issue), while other
> software will fail very quickly. I very much suspect we will see the
> same class of issue on ACPI systems.

Ah, thanks , that makes sense to me :-)

So can I say:
In normal case, CNTFRQ_EL0, CNTCTLBase.CNTFRQ and CNTBaseN.CNTFRQ
should be set to the same value.
But in some special case, some CNTFRQ maybe set to a different number
for some reason(maybe on purpose).

>
> Consider a system where the sysreg CNTFRQ was correct, but the MMIO
> CNTFRQ contains an erroneous non-zero value.
>
> If we get the frequency out of CNTFRQ_EL0 first, and assign this to
> arch_timer_rate, we won't bother to look at the MMIO registers (which
> could contain erroneous values). If we read an erroneous CNTBaseN.CNTFRQ
> value first, and assign this to arch_timer_rate, we won't look at
> CNTFRQ_EL0.
>
> This is *very* fragile w.r.t. probe order. I don't like the fragility of
> setting a common arch_timer_rate depending on which gets probed first,
> as this masks a bug, which will adversely affect us later.
>
> This is already a problem for DT systems, and I do not want this problem
> to spread to ACPI systems.
>
> For ACPI, the approach I'd personally like to take is to keep the two
> rates separate. Probe the sysreg timer first and subsequently probe the
> MMIO timers. If the MMIO CNTFRQ (of all frames) does not match the
> sysreg CNTFRQ, we log a warning and give up probing the MMIO timers.

OK, I think I got your point, will do this way. Thanks :-)

>
> For legacy reasons, DT is going to be more complicated, but I believe we
> can apply that approach to ACPI.
>
>> So do we really need to separate mmio_rate and sysreg_rate variables?
>>
>> And for CNTFRQ(in CNTCTLBase and CNTBaseN) , we can NOT access it in
>> Linux kernel (EL1),
>> Because ARMv8 ARM says:
>> In a system that implements both Secure and Non-secure states, this
>> register is only accessible by Secure accesses.
>
> CNTCTLBase.CNTFRQ can only be accessed in secure states. That is clear
> from Table I1-3 in ARM DDI 0487A.k_iss10775). I agree that we cannot
> access this.

yes , got it.
And we don't do it in the driver, we try to access  CNTBaseN.CNTFRQ
(in a frame) instead.

>
> For CNT{,EL0}BaseN.CNTFRQ, I am 

Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.

[Fu Wei]

Hi Mark,

On 26 January 2017 at 01:25, Mark Rutland  wrote:
> On Wed, Jan 25, 2017 at 02:46:12PM +0800, Fu Wei wrote:
>> Hi Mark,
>
> Hi,
>
>> On 25 January 2017 at 01:24, Mark Rutland  wrote:
>> > On Wed, Jan 18, 2017 at 09:25:32PM +0800, fu@linaro.org wrote:
>> >> From: Fu Wei 
>> >>
>> >> The counter frequency detection call(arch_timer_detect_rate) combines two
>> >> ways to get counter frequency: system coprocessor register and MMIO timer.
>> >> But in a specific timer init code, we only need one way to try:
>> >> getting frequency from MMIO timer register will be needed only when we
>> >> init MMIO timer; getting frequency from system coprocessor register will
>> >> be needed only when we init arch timer.
>> >
>> > When I mentioned this splitting before, I had mean that we'd completely
>> > separate the two, with separate mmio_rate and sysreg_rate variables.
>>
>> sorry for misunderstanding.
>>
>> Are you saying :
>>
>> diff --git a/drivers/clocksource/arm_arch_timer.c
>> b/drivers/clocksource/arm_arch_timer.c
>> index 663a57a..eec92f6 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -65,7 +65,8 @@ struct arch_timer {
>>
>>  #define to_arch_timer(e) container_of(e, struct arch_timer, evt)
>>
>> -static u32 arch_timer_rate;
>> +static u32 arch_timer_sysreg_rate ;
>> +static u32 arch_timer_mmio_rate;
>>  static int arch_timer_ppi[ARCH_TIMER_MAX_TIMER_PPI];
>>
>>  static struct clock_event_device __percpu *arch_timer_evt;
>>
>>
>> But what have I learned From ARMv8 ARM is
>> AArch64 System register CNTFRQ_EL0 is provided so that software can
>> discover the frequency of the system counter.
>> CNTFRQ(in CNTCTLBase and CNTBaseN) is provided so that software can
>> discover the frequency of the system counter.
>> The bit assignments of the registers are identical in the System
>> register interface and in the memory-mapped system level interface.
>
> This means that the bits in the registers have the same meaning.
>
> However, they are separate registers, and must be written separately. A
> write to one does not propagate to the other, and they are not
> guaranteed to contain the same value.

Ah, Sorry for misunderstanding this, and thanks for correcting it,
I thought they point to the same register.

>
>> So I think they both contain the same value : the frequency of the
>> system counter, just in different view, and can be accessed in
>> different ways.
>
> Certainly, in theory, these *should* contain the same value.
>
> Unfortunately, in practice, on several systems, they do not. It is very
> easy to forget to initialise one of these registers correctly, and it's
> possible for some software to work (masking the issue), while other
> software will fail very quickly. I very much suspect we will see the
> same class of issue on ACPI systems.

Ah, thanks , that makes sense to me :-)

So can I say:
In normal case, CNTFRQ_EL0, CNTCTLBase.CNTFRQ and CNTBaseN.CNTFRQ
should be set to the same value.
But in some special case, some CNTFRQ maybe set to a different number
for some reason(maybe on purpose).

>
> Consider a system where the sysreg CNTFRQ was correct, but the MMIO
> CNTFRQ contains an erroneous non-zero value.
>
> If we get the frequency out of CNTFRQ_EL0 first, and assign this to
> arch_timer_rate, we won't bother to look at the MMIO registers (which
> could contain erroneous values). If we read an erroneous CNTBaseN.CNTFRQ
> value first, and assign this to arch_timer_rate, we won't look at
> CNTFRQ_EL0.
>
> This is *very* fragile w.r.t. probe order. I don't like the fragility of
> setting a common arch_timer_rate depending on which gets probed first,
> as this masks a bug, which will adversely affect us later.
>
> This is already a problem for DT systems, and I do not want this problem
> to spread to ACPI systems.
>
> For ACPI, the approach I'd personally like to take is to keep the two
> rates separate. Probe the sysreg timer first and subsequently probe the
> MMIO timers. If the MMIO CNTFRQ (of all frames) does not match the
> sysreg CNTFRQ, we log a warning and give up probing the MMIO timers.

OK, I think I got your point, will do this way. Thanks :-)

>
> For legacy reasons, DT is going to be more complicated, but I believe we
> can apply that approach to ACPI.
>
>> So do we really need to separate mmio_rate and sysreg_rate variables?
>>
>> And for CNTFRQ(in CNTCTLBase and CNTBaseN) , we can NOT access it in
>> Linux kernel (EL1),
>> Because ARMv8 ARM says:
>> In a system that implements both Secure and Non-secure states, this
>> register is only accessible by Secure accesses.
>
> CNTCTLBase.CNTFRQ can only be accessed in secure states. That is clear
> from Table I1-3 in ARM DDI 0487A.k_iss10775). I agree that we cannot
> access this.

yes , got it.
And we don't do it in the driver, we try to access  CNTBaseN.CNTFRQ
(in a frame) instead.

>
> For CNT{,EL0}BaseN.CNTFRQ, I am very concerned by the wording in the
> current ARMv8 ARM ARM. 

Re: linux-next: Tree for Jan 19

[Stafford Horne]

On Wed, Jan 25, 2017 at 11:37:11AM -0500, Paul Gortmaker wrote:
> [Re: linux-next: Tree for Jan 19] On 23/01/2017 (Mon 23:11) Stafford Horne 
> wrote:
> 
> [...]
> 
> > 
> > Are all of these builds using the tests from lkp-tests [0]?
> 
> Not using any specific tests, other than compiling allmodconfig and
> defconfig.
> 
> > 
> > If so and no one is working on openrisc toolchain updates I will package up
> > a modern toolchain for the cdn [1] and send patches for lkp-test.
> > 
> > If there is something else that needs to be done let me know.
> > 
> > [0] git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> > [1] https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1/
> 
> If you could work with Tony (his email is at the bottom of the crosstool
> front page in [1]) to get the or32 binutils updated, that would be
> great.  With all the arch currrently in linux, I pretty much have to
> just use what is available from kernel.org as prebuilts.
> 

Thanks,

I will followup with Tony.

Re: linux-next: Tree for Jan 19

[Stafford Horne]

On Wed, Jan 25, 2017 at 11:37:11AM -0500, Paul Gortmaker wrote:
> [Re: linux-next: Tree for Jan 19] On 23/01/2017 (Mon 23:11) Stafford Horne 
> wrote:
> 
> [...]
> 
> > 
> > Are all of these builds using the tests from lkp-tests [0]?
> 
> Not using any specific tests, other than compiling allmodconfig and
> defconfig.
> 
> > 
> > If so and no one is working on openrisc toolchain updates I will package up
> > a modern toolchain for the cdn [1] and send patches for lkp-test.
> > 
> > If there is something else that needs to be done let me know.
> > 
> > [0] git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> > [1] https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1/
> 
> If you could work with Tony (his email is at the bottom of the crosstool
> front page in [1]) to get the or32 binutils updated, that would be
> great.  With all the arch currrently in linux, I pretty much have to
> just use what is available from kernel.org as prebuilts.
> 

Thanks,

I will followup with Tony.

Re: [PATCH 0/5] mm: vmscan: fix kswapd writeback regression

[Hillf Danton]

On January 24, 2017 2:17 AM Johannes Weiner wrote:
> 
> We noticed a regression on multiple hadoop workloads when moving from
> 3.10 to 4.0 and 4.6, which involves kswapd getting tangled up in page
> writeout, causing direct reclaim herds that also don't make progress.
> 
> I tracked it down to the thrash avoidance efforts after 3.10 that make
> the kernel better at keeping use-once cache and use-many cache sorted
> on the inactive and active list, with more aggressive protection of
> the active list as long as there is inactive cache. Unfortunately, our
> workload's use-once cache is mostly from streaming writes. Waiting for
> writes to avoid potential reloads in the future is not a good tradeoff.
> 
> These patches do the following:
> 
> 1. Wake the flushers when kswapd sees a lump of dirty pages. It's
>possible to be below the dirty background limit and still have
>cache velocity push them through the LRU. So start a-flushin'.
> 
> 2. Let kswapd only write pages that have been rotated twice. This
>makes sure we really tried to get all the clean pages on the
>inactive list before resorting to horrible LRU-order writeback.
> 
> 3. Move rotating dirty pages off the inactive list. Instead of
>churning or waiting on page writeback, we'll go after clean active
>cache. This might lead to thrashing, but in this state memory
>demand outstrips IO speed anyway, and reads are faster than writes.
> 
> More details in the individual changelogs.
> 
>  include/linux/mm_inline.h|  7 
>  include/linux/mmzone.h   |  2 --
>  include/linux/writeback.h|  2 +-
>  include/trace/events/writeback.h |  2 +-
>  mm/swap.c|  9 ++---
>  mm/vmscan.c  | 68 +++---
>  6 files changed, 41 insertions(+), 49 deletions(-)
> 
Acked-by: Hillf Danton 

Re: [PATCH 0/5] mm: vmscan: fix kswapd writeback regression

[Hillf Danton]

On January 24, 2017 2:17 AM Johannes Weiner wrote:
> 
> We noticed a regression on multiple hadoop workloads when moving from
> 3.10 to 4.0 and 4.6, which involves kswapd getting tangled up in page
> writeout, causing direct reclaim herds that also don't make progress.
> 
> I tracked it down to the thrash avoidance efforts after 3.10 that make
> the kernel better at keeping use-once cache and use-many cache sorted
> on the inactive and active list, with more aggressive protection of
> the active list as long as there is inactive cache. Unfortunately, our
> workload's use-once cache is mostly from streaming writes. Waiting for
> writes to avoid potential reloads in the future is not a good tradeoff.
> 
> These patches do the following:
> 
> 1. Wake the flushers when kswapd sees a lump of dirty pages. It's
>possible to be below the dirty background limit and still have
>cache velocity push them through the LRU. So start a-flushin'.
> 
> 2. Let kswapd only write pages that have been rotated twice. This
>makes sure we really tried to get all the clean pages on the
>inactive list before resorting to horrible LRU-order writeback.
> 
> 3. Move rotating dirty pages off the inactive list. Instead of
>churning or waiting on page writeback, we'll go after clean active
>cache. This might lead to thrashing, but in this state memory
>demand outstrips IO speed anyway, and reads are faster than writes.
> 
> More details in the individual changelogs.
> 
>  include/linux/mm_inline.h|  7 
>  include/linux/mmzone.h   |  2 --
>  include/linux/writeback.h|  2 +-
>  include/trace/events/writeback.h |  2 +-
>  mm/swap.c|  9 ++---
>  mm/vmscan.c  | 68 +++---
>  6 files changed, 41 insertions(+), 49 deletions(-)
> 
Acked-by: Hillf Danton 

Re: [PATCH v2] netfilter: nf_ct_helper: warn when not applying default helper assignment

[Joe Perches]

On Wed, 2017-01-25 at 21:43 +0100, Jiri Kosina wrote:
> Rewrite the code a little bit as suggested by Linus, so that we avoid
> spaghettiing the code even more -- namely the whole decision making
> process regarding helper selection (either automatic or not) is being
> separated, so that the whole logic can be simplified and code (condition)
> duplication reduced.
[]
> diff --git a/net/netfilter/nf_conntrack_helper.c 
> b/net/netfilter/nf_conntrack_helper.c
[]
> @@ -188,6 +188,39 @@ struct nf_conn_help *
>  }
>  EXPORT_SYMBOL_GPL(nf_ct_helper_ext_add);
>  
> +static struct nf_conntrack_helper *find_auto_helper(struct nf_conn *ct)
> +{
> + return __nf_ct_helper_find(>tuplehash[IP_CT_DIR_REPLY].tuple);
> +}
> +
> +static struct nf_conntrack_helper *ct_lookup_helper(struct nf_conn *ct, 
> struct net *net)
> +{
> + struct nf_conntrack_helper *ret;
> +
> + if (!net->ct.sysctl_auto_assign_helper) {
> + if (net->ct.auto_assign_helper_warned)
> + return NULL;
> + if (!find_auto_helper(ct))
> + return NULL;
> + pr_info("nf_conntrack: default automatic helper assignment "
> + "has been turned off for security reasons and CT-based "
> + " firewall rule not found. Use the iptables CT target "
> + "to attach helpers instead.\n");
> + net->ct.auto_assign_helper_warned = 1;
> + return NULL;
> + }
> +
> + ret = find_auto_helper(ct);
> + if (!ret || net->ct.auto_assign_helper_warned)
> + return ret;
> + pr_info("nf_conntrack: automatic helper assignment is deprecated and it 
> will "
> + "be removed soon. Use the iptables CT target to attach helpers "
> + " instead.\n");
> + net->ct.auto_assign_helper_warned = 1;
> + return ret;
> +}

There are whitespece defects concatenating these multi-line strings.

How about an exit block that emits the message like

{
[...]
const char *msg;

[...]

if (!net->ct.sysctl_auto_assign_helper) {
if (net->ct.auto_assign_helper_warned)
return NULL;
if (!find_auto_helper(ct))
return NULL;
msg = "default automatic helper assignment has been turned off 
for security reasons and CT-based firewall rule not found";
ret = NULL;
} else {
ret = find_auto_helper(ct);
if (!ret || net->ct.auto_assign_helper_warned)
return ret;
msg = "automatic helper assignment is deprecated and it will be 
removed soon";
net->ct.auto_assign_helper_warned = 1;
}

pr_info("nf_conntrack: %s.  Use the iptables CT target to attach 
helpers instead.\n", msg);
return ret;
}

Re: [PATCH v2] netfilter: nf_ct_helper: warn when not applying default helper assignment

[Joe Perches]

On Wed, 2017-01-25 at 21:43 +0100, Jiri Kosina wrote:
> Rewrite the code a little bit as suggested by Linus, so that we avoid
> spaghettiing the code even more -- namely the whole decision making
> process regarding helper selection (either automatic or not) is being
> separated, so that the whole logic can be simplified and code (condition)
> duplication reduced.
[]
> diff --git a/net/netfilter/nf_conntrack_helper.c 
> b/net/netfilter/nf_conntrack_helper.c
[]
> @@ -188,6 +188,39 @@ struct nf_conn_help *
>  }
>  EXPORT_SYMBOL_GPL(nf_ct_helper_ext_add);
>  
> +static struct nf_conntrack_helper *find_auto_helper(struct nf_conn *ct)
> +{
> + return __nf_ct_helper_find(>tuplehash[IP_CT_DIR_REPLY].tuple);
> +}
> +
> +static struct nf_conntrack_helper *ct_lookup_helper(struct nf_conn *ct, 
> struct net *net)
> +{
> + struct nf_conntrack_helper *ret;
> +
> + if (!net->ct.sysctl_auto_assign_helper) {
> + if (net->ct.auto_assign_helper_warned)
> + return NULL;
> + if (!find_auto_helper(ct))
> + return NULL;
> + pr_info("nf_conntrack: default automatic helper assignment "
> + "has been turned off for security reasons and CT-based "
> + " firewall rule not found. Use the iptables CT target "
> + "to attach helpers instead.\n");
> + net->ct.auto_assign_helper_warned = 1;
> + return NULL;
> + }
> +
> + ret = find_auto_helper(ct);
> + if (!ret || net->ct.auto_assign_helper_warned)
> + return ret;
> + pr_info("nf_conntrack: automatic helper assignment is deprecated and it 
> will "
> + "be removed soon. Use the iptables CT target to attach helpers "
> + " instead.\n");
> + net->ct.auto_assign_helper_warned = 1;
> + return ret;
> +}

There are whitespece defects concatenating these multi-line strings.

How about an exit block that emits the message like

{
[...]
const char *msg;

[...]

if (!net->ct.sysctl_auto_assign_helper) {
if (net->ct.auto_assign_helper_warned)
return NULL;
if (!find_auto_helper(ct))
return NULL;
msg = "default automatic helper assignment has been turned off 
for security reasons and CT-based firewall rule not found";
ret = NULL;
} else {
ret = find_auto_helper(ct);
if (!ret || net->ct.auto_assign_helper_warned)
return ret;
msg = "automatic helper assignment is deprecated and it will be 
removed soon";
net->ct.auto_assign_helper_warned = 1;
}

pr_info("nf_conntrack: %s.  Use the iptables CT target to attach 
helpers instead.\n", msg);
return ret;
}

Re: linux-next: Tree for Jan 19

[Stafford Horne]

On Wed, Jan 25, 2017 at 08:54:53PM -0800, Guenter Roeck wrote:
> On 01/25/2017 08:37 AM, Paul Gortmaker wrote:
> > [Re: linux-next: Tree for Jan 19] On 23/01/2017 (Mon 23:11) Stafford Horne 
> > wrote:
> > 
> > [...]
> > 
> > > 
> > > Are all of these builds using the tests from lkp-tests [0]?
> > 
> > Not using any specific tests, other than compiling allmodconfig and
> > defconfig.
> > 
> > > 
> > > If so and no one is working on openrisc toolchain updates I will package 
> > > up
> > > a modern toolchain for the cdn [1] and send patches for lkp-test.
> > > 
> > > If there is something else that needs to be done let me know.
> > > 
> > > [0] git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> > > [1] https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1/
> > 
> > If you could work with Tony (his email is at the bottom of the crosstool
> > front page in [1]) to get the or32 binutils updated, that would be
> > great.  With all the arch currrently in linux, I pretty much have to
> > just use what is available from kernel.org as prebuilts.
> > 
> 
> Different problem, but from the 0day info I thought you might be interested
> in the following breakage as well (seen in -next).
> 
> /opt/buildbot/slave/next-next/build/arch/score/kernel/traps.c: In function 
> 'do_adedata':
> /opt/buildbot/slave/next-next/build/arch/score/kernel/traps.c:185:2: error: 
> implicit declaration of function 'search_exception_tables'
> 
> Reported on kerneltests.org.

Thanks Guenter,

Is this for me of Paul?

You reported score above, but I think probably this is also impacting
openrisc.

Anyway,
I think this is due to Puals changes which separated out extable from
module.  traps.c in score and openrisc use search_exception_tables and
include  to get it.

I did see Paul post a patch to fix traps.c too,

This should be fixed by today.

-Stafford

Re: linux-next: Tree for Jan 19

[Stafford Horne]

On Wed, Jan 25, 2017 at 08:54:53PM -0800, Guenter Roeck wrote:
> On 01/25/2017 08:37 AM, Paul Gortmaker wrote:
> > [Re: linux-next: Tree for Jan 19] On 23/01/2017 (Mon 23:11) Stafford Horne 
> > wrote:
> > 
> > [...]
> > 
> > > 
> > > Are all of these builds using the tests from lkp-tests [0]?
> > 
> > Not using any specific tests, other than compiling allmodconfig and
> > defconfig.
> > 
> > > 
> > > If so and no one is working on openrisc toolchain updates I will package 
> > > up
> > > a modern toolchain for the cdn [1] and send patches for lkp-test.
> > > 
> > > If there is something else that needs to be done let me know.
> > > 
> > > [0] git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> > > [1] https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1/
> > 
> > If you could work with Tony (his email is at the bottom of the crosstool
> > front page in [1]) to get the or32 binutils updated, that would be
> > great.  With all the arch currrently in linux, I pretty much have to
> > just use what is available from kernel.org as prebuilts.
> > 
> 
> Different problem, but from the 0day info I thought you might be interested
> in the following breakage as well (seen in -next).
> 
> /opt/buildbot/slave/next-next/build/arch/score/kernel/traps.c: In function 
> 'do_adedata':
> /opt/buildbot/slave/next-next/build/arch/score/kernel/traps.c:185:2: error: 
> implicit declaration of function 'search_exception_tables'
> 
> Reported on kerneltests.org.

Thanks Guenter,

Is this for me of Paul?

You reported score above, but I think probably this is also impacting
openrisc.

Anyway,
I think this is due to Puals changes which separated out extable from
module.  traps.c in score and openrisc use search_exception_tables and
include  to get it.

I did see Paul post a patch to fix traps.c too,

This should be fixed by today.

-Stafford

Re: [PATCH] mm: vmscan: do not pass reclaimed slab to vmpressure

[vinayak menon]

Hi Minchan

On Thu, Jan 26, 2017 at 4:57 AM, Minchan Kim  wrote:
> Hello Vinayak,
>
> On Wed, Jan 25, 2017 at 05:08:38PM +0530, Vinayak Menon wrote:
>> It is noticed that during a global reclaim the memory
>> reclaimed via shrinking the slabs can sometimes result
>> in reclaimed pages being greater than the scanned pages
>> in shrink_node. When this is passed to vmpressure, the
>
> I don't know you are saying zsmalloc. Anyway, it's one of those which
> free larger pages than requested. I should fix that but was not sent
> yet, unfortunately.

As I understand, the problem is not related to a particular shrinker.
In shrink_node, when subtree's reclaim efficiency is passed to vmpressure,
the 4th parameter (sc->nr_scanned - nr_scanned) includes only the LRU
scanned pages, but the 5th parameter (sc->nr_reclaimed - nr_reclaimed) includes
the reclaimed slab pages also since in the previous step
"reclaimed_slab" is added
to it. i.e the slabs scanned are not included in scanned passed to vmpressure.
This results in reclaimed going higher than scanned in vmpressure resulting in
false events.

>
>> unsigned arithmetic results in the pressure value to be
>> huge, thus resulting in a critical event being sent to
>> root cgroup. Fix this by not passing the reclaimed slab
>> count to vmpressure, with the assumption that vmpressure
>> should show the actual pressure on LRU which is now
>> diluted by adding reclaimed slab without a corresponding
>> scanned value.
>
> I can't guess justfication of your assumption from the description.
> Why do we consider only LRU pages for vmpressure? Could you elaborate
> a bit?
>
When we encountered the false events from vmpressure, thought the problem
could be that slab scanned is not included in sc->nr_scanned, like it is done
for reclaimed. But later thought vmpressure works only on the scanned and
reclaimed from LRU. I can explain what I understand, let me know if this is
incorrect.
vmpressure is an index which tells the pressure on LRU, and thus an
indicator of thrashing. In shrink_node when we come out of the inner do-while
loop after shrinking the lruvec, the scanned and reclaimed corresponds to the
pressure felt on the LRUs which in turn indicates the pressure on VM. The
moment we add the slab reclaimed pages to the reclaimed, we dilute the
actual pressure felt on LRUs. When slab scanned/reclaimed is not included
in the vmpressure, the values will indicate the actual pressure and if there
were a lot of slab reclaimed pages it will result in lesser pressure
on LRUs in the next run which will again be indicated by vmpressure. i.e. the
pressure on LRUs indicate actual pressure on VM even if slab reclaimed is
not included. Moreover, what I understand from code is, the reclaimed_slab
includes only the inodesteals and the pages freed by slab allocator, and does
not include the pages reclaimed by other shrinkers like
lowmemorykiller, zsmalloc
etc. That means even now we are including only a subset of reclaimed pages
to vmpressure. Also, considering the case of a userspace lowmemorykiller
which works on vmpressure on root cgroup, if the slab reclaimed in included in
vmpressure, the lowmemorykiller will wait till most of the slab is
shrinked before
kicking in to kill a task. No ?

Thanks,
Vinayak

Re: [PATCH] mm: vmscan: do not pass reclaimed slab to vmpressure

[vinayak menon]

Hi Minchan

On Thu, Jan 26, 2017 at 4:57 AM, Minchan Kim  wrote:
> Hello Vinayak,
>
> On Wed, Jan 25, 2017 at 05:08:38PM +0530, Vinayak Menon wrote:
>> It is noticed that during a global reclaim the memory
>> reclaimed via shrinking the slabs can sometimes result
>> in reclaimed pages being greater than the scanned pages
>> in shrink_node. When this is passed to vmpressure, the
>
> I don't know you are saying zsmalloc. Anyway, it's one of those which
> free larger pages than requested. I should fix that but was not sent
> yet, unfortunately.

As I understand, the problem is not related to a particular shrinker.
In shrink_node, when subtree's reclaim efficiency is passed to vmpressure,
the 4th parameter (sc->nr_scanned - nr_scanned) includes only the LRU
scanned pages, but the 5th parameter (sc->nr_reclaimed - nr_reclaimed) includes
the reclaimed slab pages also since in the previous step
"reclaimed_slab" is added
to it. i.e the slabs scanned are not included in scanned passed to vmpressure.
This results in reclaimed going higher than scanned in vmpressure resulting in
false events.

>
>> unsigned arithmetic results in the pressure value to be
>> huge, thus resulting in a critical event being sent to
>> root cgroup. Fix this by not passing the reclaimed slab
>> count to vmpressure, with the assumption that vmpressure
>> should show the actual pressure on LRU which is now
>> diluted by adding reclaimed slab without a corresponding
>> scanned value.
>
> I can't guess justfication of your assumption from the description.
> Why do we consider only LRU pages for vmpressure? Could you elaborate
> a bit?
>
When we encountered the false events from vmpressure, thought the problem
could be that slab scanned is not included in sc->nr_scanned, like it is done
for reclaimed. But later thought vmpressure works only on the scanned and
reclaimed from LRU. I can explain what I understand, let me know if this is
incorrect.
vmpressure is an index which tells the pressure on LRU, and thus an
indicator of thrashing. In shrink_node when we come out of the inner do-while
loop after shrinking the lruvec, the scanned and reclaimed corresponds to the
pressure felt on the LRUs which in turn indicates the pressure on VM. The
moment we add the slab reclaimed pages to the reclaimed, we dilute the
actual pressure felt on LRUs. When slab scanned/reclaimed is not included
in the vmpressure, the values will indicate the actual pressure and if there
were a lot of slab reclaimed pages it will result in lesser pressure
on LRUs in the next run which will again be indicated by vmpressure. i.e. the
pressure on LRUs indicate actual pressure on VM even if slab reclaimed is
not included. Moreover, what I understand from code is, the reclaimed_slab
includes only the inodesteals and the pages freed by slab allocator, and does
not include the pages reclaimed by other shrinkers like
lowmemorykiller, zsmalloc
etc. That means even now we are including only a subset of reclaimed pages
to vmpressure. Also, considering the case of a userspace lowmemorykiller
which works on vmpressure on root cgroup, if the slab reclaimed in included in
vmpressure, the lowmemorykiller will wait till most of the slab is
shrinked before
kicking in to kill a task. No ?

Thanks,
Vinayak

Re: linux-next: Tree for Jan 19

[Guenter Roeck]

On 01/25/2017 08:37 AM, Paul Gortmaker wrote:

[Re: linux-next: Tree for Jan 19] On 23/01/2017 (Mon 23:11) Stafford Horne 
wrote:

[...]



Are all of these builds using the tests from lkp-tests [0]?


Not using any specific tests, other than compiling allmodconfig and
defconfig.



If so and no one is working on openrisc toolchain updates I will package up
a modern toolchain for the cdn [1] and send patches for lkp-test.

If there is something else that needs to be done let me know.

[0] git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
[1] https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1/


If you could work with Tony (his email is at the bottom of the crosstool
front page in [1]) to get the or32 binutils updated, that would be
great.  With all the arch currrently in linux, I pretty much have to
just use what is available from kernel.org as prebuilts.



Different problem, but from the 0day info I thought you might be interested
in the following breakage as well (seen in -next).

/opt/buildbot/slave/next-next/build/arch/score/kernel/traps.c: In function 
'do_adedata':
/opt/buildbot/slave/next-next/build/arch/score/kernel/traps.c:185:2: error: 
implicit declaration of function 'search_exception_tables'

Reported on kerneltests.org.

Guenter

Re: linux-next: Tree for Jan 19

[Guenter Roeck]

On 01/25/2017 08:37 AM, Paul Gortmaker wrote:

[Re: linux-next: Tree for Jan 19] On 23/01/2017 (Mon 23:11) Stafford Horne 
wrote:

[...]



Are all of these builds using the tests from lkp-tests [0]?


Not using any specific tests, other than compiling allmodconfig and
defconfig.



If so and no one is working on openrisc toolchain updates I will package up
a modern toolchain for the cdn [1] and send patches for lkp-test.

If there is something else that needs to be done let me know.

[0] git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
[1] https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1/


If you could work with Tony (his email is at the bottom of the crosstool
front page in [1]) to get the or32 binutils updated, that would be
great.  With all the arch currrently in linux, I pretty much have to
just use what is available from kernel.org as prebuilts.



Different problem, but from the 0day info I thought you might be interested
in the following breakage as well (seen in -next).

/opt/buildbot/slave/next-next/build/arch/score/kernel/traps.c: In function 
'do_adedata':
/opt/buildbot/slave/next-next/build/arch/score/kernel/traps.c:185:2: error: 
implicit declaration of function 'search_exception_tables'

Reported on kerneltests.org.

Guenter

Re: [PATCH v20 2/4] mailbox: mediatek: Add Mediatek CMDQ driver

[Jassi Brar]

On Wed, Jan 4, 2017 at 8:36 AM, HS Liao  wrote:

> diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c 
> b/drivers/mailbox/mtk-cmdq-mailbox.c
> new file mode 100644
> index 000..747bcd3
> --- /dev/null
> +++ b/drivers/mailbox/mtk-cmdq-mailbox.c

...

> +static void cmdq_task_exec(struct cmdq_pkt *pkt, struct cmdq_thread *thread)
> +{
> +   struct cmdq *cmdq;
> +   struct cmdq_task *task;
> +   unsigned long curr_pa, end_pa;
> +
> +   cmdq = dev_get_drvdata(thread->chan->mbox->dev);
> +
> +   /* Client should not flush new tasks if suspended. */
> +   WARN_ON(cmdq->suspended);
> +
> +   task = kzalloc(sizeof(*task), GFP_ATOMIC);
> +   task->cmdq = cmdq;
> +   INIT_LIST_HEAD(>list_entry);
> +   task->pa_base = dma_map_single(cmdq->mbox.dev, pkt->va_base,
> +  pkt->cmd_buf_size, DMA_TO_DEVICE);
>
You seem to parse the requests and responses, that should ideally be
done in client driver.
Also, we are here in atomic context, can you move it in client driver
(before the spin_lock)?
Maybe by adding a new 'pa_base' member as well in 'cmdq_pkt'.


> +
> +   cmdq->mbox.num_chans = CMDQ_THR_MAX_COUNT;
> +   cmdq->mbox.ops = _mbox_chan_ops;
> +   cmdq->mbox.of_xlate = cmdq_xlate;
> +
> +   /* make use of TXDONE_BY_ACK */
> +   cmdq->mbox.txdone_irq = false;
> +   cmdq->mbox.txdone_poll = false;
> +
> +   for (i = 0; i < ARRAY_SIZE(cmdq->thread); i++) {
>
You mean  i < CMDQ_THR_MAX_COUNT

> +   cmdq->thread[i].base = cmdq->base + CMDQ_THR_BASE +
> +   CMDQ_THR_SIZE * i;
> +   INIT_LIST_HEAD(>thread[i].task_busy_list);
>
You seem the queue mailbox requests in this controller driver? why not
use the mailbox api for that?

> +   init_timer(>thread[i].timeout);
> +   cmdq->thread[i].timeout.function = cmdq_thread_handle_timeout;
> +   cmdq->thread[i].timeout.data = (unsigned 
> long)>thread[i];
>
Here again... you seem to ignore the polling mechanism provided by the
mailbox api, and implement your own.


> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h 
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> new file mode 100644
> index 000..3433c64
> --- /dev/null
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h

> +
> +struct cmdq_pkt {
> +   void*va_base;
>
maybe add 'pa_base' here so you don't have to do dma_map_single() in send_data

> +   size_t  cmd_buf_size; /* command occupied size */
> +   size_t  buf_size; /* real buffer size */
> +   struct cmdq_task_cb cb;
> +};
> +
> +#endif /* __MTK_CMDQ_MAILBOX_H__ */
> --
> 1.9.1
>

Re: [PATCH v20 2/4] mailbox: mediatek: Add Mediatek CMDQ driver

[Jassi Brar]

On Wed, Jan 4, 2017 at 8:36 AM, HS Liao  wrote:

> diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c 
> b/drivers/mailbox/mtk-cmdq-mailbox.c
> new file mode 100644
> index 000..747bcd3
> --- /dev/null
> +++ b/drivers/mailbox/mtk-cmdq-mailbox.c

...

> +static void cmdq_task_exec(struct cmdq_pkt *pkt, struct cmdq_thread *thread)
> +{
> +   struct cmdq *cmdq;
> +   struct cmdq_task *task;
> +   unsigned long curr_pa, end_pa;
> +
> +   cmdq = dev_get_drvdata(thread->chan->mbox->dev);
> +
> +   /* Client should not flush new tasks if suspended. */
> +   WARN_ON(cmdq->suspended);
> +
> +   task = kzalloc(sizeof(*task), GFP_ATOMIC);
> +   task->cmdq = cmdq;
> +   INIT_LIST_HEAD(>list_entry);
> +   task->pa_base = dma_map_single(cmdq->mbox.dev, pkt->va_base,
> +  pkt->cmd_buf_size, DMA_TO_DEVICE);
>
You seem to parse the requests and responses, that should ideally be
done in client driver.
Also, we are here in atomic context, can you move it in client driver
(before the spin_lock)?
Maybe by adding a new 'pa_base' member as well in 'cmdq_pkt'.


> +
> +   cmdq->mbox.num_chans = CMDQ_THR_MAX_COUNT;
> +   cmdq->mbox.ops = _mbox_chan_ops;
> +   cmdq->mbox.of_xlate = cmdq_xlate;
> +
> +   /* make use of TXDONE_BY_ACK */
> +   cmdq->mbox.txdone_irq = false;
> +   cmdq->mbox.txdone_poll = false;
> +
> +   for (i = 0; i < ARRAY_SIZE(cmdq->thread); i++) {
>
You mean  i < CMDQ_THR_MAX_COUNT

> +   cmdq->thread[i].base = cmdq->base + CMDQ_THR_BASE +
> +   CMDQ_THR_SIZE * i;
> +   INIT_LIST_HEAD(>thread[i].task_busy_list);
>
You seem the queue mailbox requests in this controller driver? why not
use the mailbox api for that?

> +   init_timer(>thread[i].timeout);
> +   cmdq->thread[i].timeout.function = cmdq_thread_handle_timeout;
> +   cmdq->thread[i].timeout.data = (unsigned 
> long)>thread[i];
>
Here again... you seem to ignore the polling mechanism provided by the
mailbox api, and implement your own.


> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h 
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> new file mode 100644
> index 000..3433c64
> --- /dev/null
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h

> +
> +struct cmdq_pkt {
> +   void*va_base;
>
maybe add 'pa_base' here so you don't have to do dma_map_single() in send_data

> +   size_t  cmd_buf_size; /* command occupied size */
> +   size_t  buf_size; /* real buffer size */
> +   struct cmdq_task_cb cb;
> +};
> +
> +#endif /* __MTK_CMDQ_MAILBOX_H__ */
> --
> 1.9.1
>

Re: [git pull] drm fixes for 4.10-rc6 (just missed rc5 tagging :-)

[Lukas Wunner]

On Wed, Jan 25, 2017 at 01:54:32PM +0100, Daniel Vetter wrote:
> On Wed, Jan 25, 2017 at 06:10:57PM +0900, Michel Dänzer wrote:
> > On 25/01/17 05:33 PM, Markus Trippelsdorf wrote:
> > > On 2017.01.23 at 09:38 +1000, Dave Airlie wrote:
> > >> 
> > >> Alex Deucher (8):
> > >>   drm/radeon/si: load special ucode for certain MC configs
> > >>   drm/amdgpu/si: load special ucode for certain MC configs
> > >>   drm/amdgpu: drop oland quirks
> > >>   drm/amdgpu: drop the mclk quirk for hainan
> > >>   drm/radeon: drop oland quirks
> > >>   drm/radeon: drop the mclk quirk for hainan
> > >>   drm/radeon: add support for new hainan variants
> > >>   drm/amdgpu: add support for new hainan variants
> > > 
> > > Since the merge I get the following warning during boot:
> > 
> > [...]
> > 
> > > [2.627043] WARNING: CPU: 0 PID: 1 at ./include/drm/drm_crtc.h:857 
> > > drm_kms_helper_poll_init+0x127/0x140
> > 
> > This is likely due to
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3846fd9b86001bea171943cc3bb9222cb6da6b42
> > 
> > Daniel, please take a look.
> 
> Yup, I butchered this badly. The patch is correct, it also references the
> right commits and if those commits would all be in 4.10 it would even
> work. But the connector_list locking rework is only in drm-next, which
> means it's totally not working :(
> 
> Dave, can you pls revert this in drm-fixes and re-apply to drm-next, and
> then when you backmerge -fixes into -next make sure git doesn't drop it on
> the floor? Or maybe for safety do it the other way round:
> - first revert on drm-fixes
> - then backmerge
> - then reapply to drm-next.

It's not sufficient to only fix this in drm-next.  Without 3846fd9b8600,
certain Optimus laptops won't (runtime) resume:
https://bugzilla.kernel.org/show_bug.cgi?id=190861

Bjorn Helgaas therefore had queued up a revert for PCIe port runtime PM
and only dequeued it once 3846fd9b8600 landed in Linus' tree.

Please re-submit 3846fd9b8600 and its prerequisites for drm-fixes at
your earliest convenience.

Thanks,

Lukas

Re: [git pull] drm fixes for 4.10-rc6 (just missed rc5 tagging :-)

[Lukas Wunner]

On Wed, Jan 25, 2017 at 01:54:32PM +0100, Daniel Vetter wrote:
> On Wed, Jan 25, 2017 at 06:10:57PM +0900, Michel Dänzer wrote:
> > On 25/01/17 05:33 PM, Markus Trippelsdorf wrote:
> > > On 2017.01.23 at 09:38 +1000, Dave Airlie wrote:
> > >> 
> > >> Alex Deucher (8):
> > >>   drm/radeon/si: load special ucode for certain MC configs
> > >>   drm/amdgpu/si: load special ucode for certain MC configs
> > >>   drm/amdgpu: drop oland quirks
> > >>   drm/amdgpu: drop the mclk quirk for hainan
> > >>   drm/radeon: drop oland quirks
> > >>   drm/radeon: drop the mclk quirk for hainan
> > >>   drm/radeon: add support for new hainan variants
> > >>   drm/amdgpu: add support for new hainan variants
> > > 
> > > Since the merge I get the following warning during boot:
> > 
> > [...]
> > 
> > > [2.627043] WARNING: CPU: 0 PID: 1 at ./include/drm/drm_crtc.h:857 
> > > drm_kms_helper_poll_init+0x127/0x140
> > 
> > This is likely due to
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3846fd9b86001bea171943cc3bb9222cb6da6b42
> > 
> > Daniel, please take a look.
> 
> Yup, I butchered this badly. The patch is correct, it also references the
> right commits and if those commits would all be in 4.10 it would even
> work. But the connector_list locking rework is only in drm-next, which
> means it's totally not working :(
> 
> Dave, can you pls revert this in drm-fixes and re-apply to drm-next, and
> then when you backmerge -fixes into -next make sure git doesn't drop it on
> the floor? Or maybe for safety do it the other way round:
> - first revert on drm-fixes
> - then backmerge
> - then reapply to drm-next.

It's not sufficient to only fix this in drm-next.  Without 3846fd9b8600,
certain Optimus laptops won't (runtime) resume:
https://bugzilla.kernel.org/show_bug.cgi?id=190861

Bjorn Helgaas therefore had queued up a revert for PCIe port runtime PM
and only dequeued it once 3846fd9b8600 landed in Linus' tree.

Please re-submit 3846fd9b8600 and its prerequisites for drm-fixes at
your earliest convenience.

Thanks,

Lukas