[PATCH 00/12] Major code reorganization to make all i2c transfers working

[Abhishek Sahu]

The current driver is failing in following test case
1. Handling of failure cases is not working in long run for BAM
   mode. It generates error message “bam-dma-engine 7884000.dma: Cannot
   free busy channel” sometimes.
2. Following I2C transfers are failing
   a. Single transfer with multiple read messages
   b. Single transfer with multiple read/write message with maximum
  allowed length per message (65K) in BAM mode
   c. Single transfer with write greater than 32 bytes in QUP v1 and
  write greater than 64 bytes in QUP v2 for non-DMA mode.
3. No handling is present for Block/FIFO interrupts. Any non-error
   interrupts are being treated as the transfer completion and then
   polling is being done for available/free bytes in FIFO.

To fix all these issues, major code changes are required. This patch
series fixes all the above issues and makes the driver interrupt based
instead of polling based. After these changes, all the mentioned test
cases are working properly.

The code changes have been tested for QUP v1 (IPQ8064) and QUP
v2 (IPQ8074) with sample application written over i2c-dev.

Abhishek Sahu (12):
  i2c: qup: fixed releasing dma without flush operation completion
  i2c: qup: minor code reorganization for use_dma
  i2c: qup: remove redundant variables for BAM SG count
  i2c: qup: schedule EOT and FLUSH tags at the end of transfer
  i2c: qup: fix the transfer length for BAM rx EOT FLUSH tags
  i2c: qup: proper error handling for i2c error in BAM mode
  i2c: qup: use the complete transfer length to choose DMA mode
  i2c: qup: change completion timeout according to transfer length
  i2c: qup: fix buffer overflow for multiple msg of maximum xfer len
  i2c: qup: send NACK for last read sub transfers
  i2c: qup: reorganization of driver code to remove polling for qup v1
  i2c: qup: reorganization of driver code to remove polling for qup v2

 drivers/i2c/busses/i2c-qup.c | 1538 +-
 1 file changed, 924 insertions(+), 614 deletions(-)

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 02/12] i2c: qup: minor code reorganization for use_dma

[Abhishek Sahu]

1. Assigns use_dma in qup_dev structure itself which will
   help in subsequent patches to determine the mode in IRQ handler.
2. Does minor code reorganization for loops to reduce the
   unnecessary comparison and assignment.

Signed-off-by: Abhishek Sahu 
---
 drivers/i2c/busses/i2c-qup.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index 9faa26c41a..c68f433 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -190,6 +190,8 @@ struct qup_i2c_dev {
 
/* dma parameters */
boolis_dma;
+   /* To check if the current transfer is using DMA */
+   booluse_dma;
struct  dma_pool *dpool;
struct  qup_i2c_tag start_tag;
struct  qup_i2c_bam brx;
@@ -1297,7 +1299,7 @@ static int qup_i2c_xfer_v2(struct i2c_adapter *adap,
   int num)
 {
struct qup_i2c_dev *qup = i2c_get_adapdata(adap);
-   int ret, len, idx = 0, use_dma = 0;
+   int ret, len, idx = 0;
 
qup->bus_err = 0;
qup->qup_err = 0;
@@ -1326,13 +1328,12 @@ static int qup_i2c_xfer_v2(struct i2c_adapter *adap,
len = (msgs[idx].len > qup->out_fifo_sz) ||
  (msgs[idx].len > qup->in_fifo_sz);
 
-   if ((!is_vmalloc_addr(msgs[idx].buf)) && len) {
-   use_dma = 1;
-} else {
-   use_dma = 0;
+   if (is_vmalloc_addr(msgs[idx].buf) || !len)
break;
-   }
}
+
+   if (idx == num)
+   qup->use_dma = true;
}
 
idx = 0;
@@ -1356,15 +1357,17 @@ static int qup_i2c_xfer_v2(struct i2c_adapter *adap,
 
reinit_completion(>xfer);
 
-   if (use_dma) {
+   if (qup->use_dma) {
ret = qup_i2c_bam_xfer(adap, [idx], num);
+   qup->use_dma = false;
+   break;
} else {
if (msgs[idx].flags & I2C_M_RD)
ret = qup_i2c_read_one_v2(qup, [idx]);
else
ret = qup_i2c_write_one_v2(qup, [idx]);
}
-   } while ((idx++ < (num - 1)) && !use_dma && !ret);
+   } while ((idx++ < (num - 1)) && !ret);
 
if (!ret)
ret = qup_i2c_change_state(qup, QUP_RESET_STATE);
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 01/12] i2c: qup: fixed releasing dma without flush operation completion

[Abhishek Sahu]

The QUP BSLP BAM generates the following error sometimes if the
current I2C DMA transfer fails and the flush operation has been
scheduled

“bam-dma-engine 7884000.dma: Cannot free busy channel”

If any I2C error comes during BAM DMA transfer, then the QUP I2C
interrupt will be generated and the flush operation will be
carried out to make i2c consume all scheduled DMA transfer.
Currently, the same completion structure is being used for BAM
transfer which has already completed without reinit. It will make
flush operation wait_for_completion_timeout completed immediately
and will proceed for freeing the DMA resources where the
descriptors are still in process.

Signed-off-by: Abhishek Sahu 
---
 drivers/i2c/busses/i2c-qup.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index 08f8e01..9faa26c41a 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2009-2013, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2009-2013, 2016-2018, The Linux Foundation. All rights 
reserved.
  * Copyright (c) 2014, Sony Mobile Communications AB.
  *
  *
@@ -844,6 +844,8 @@ static int qup_i2c_bam_do_xfer(struct qup_i2c_dev *qup, 
struct i2c_msg *msg,
}
 
if (ret || qup->bus_err || qup->qup_err) {
+   reinit_completion(>xfer);
+
if (qup_i2c_change_state(qup, QUP_RUN_STATE)) {
dev_err(qup->dev, "change to run state timed out");
goto desc_err;
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 00/12] Major code reorganization to make all i2c transfers working

[Abhishek Sahu]

The current driver is failing in following test case
1. Handling of failure cases is not working in long run for BAM
   mode. It generates error message “bam-dma-engine 7884000.dma: Cannot
   free busy channel” sometimes.
2. Following I2C transfers are failing
   a. Single transfer with multiple read messages
   b. Single transfer with multiple read/write message with maximum
  allowed length per message (65K) in BAM mode
   c. Single transfer with write greater than 32 bytes in QUP v1 and
  write greater than 64 bytes in QUP v2 for non-DMA mode.
3. No handling is present for Block/FIFO interrupts. Any non-error
   interrupts are being treated as the transfer completion and then
   polling is being done for available/free bytes in FIFO.

To fix all these issues, major code changes are required. This patch
series fixes all the above issues and makes the driver interrupt based
instead of polling based. After these changes, all the mentioned test
cases are working properly.

The code changes have been tested for QUP v1 (IPQ8064) and QUP
v2 (IPQ8074) with sample application written over i2c-dev.

Abhishek Sahu (12):
  i2c: qup: fixed releasing dma without flush operation completion
  i2c: qup: minor code reorganization for use_dma
  i2c: qup: remove redundant variables for BAM SG count
  i2c: qup: schedule EOT and FLUSH tags at the end of transfer
  i2c: qup: fix the transfer length for BAM rx EOT FLUSH tags
  i2c: qup: proper error handling for i2c error in BAM mode
  i2c: qup: use the complete transfer length to choose DMA mode
  i2c: qup: change completion timeout according to transfer length
  i2c: qup: fix buffer overflow for multiple msg of maximum xfer len
  i2c: qup: send NACK for last read sub transfers
  i2c: qup: reorganization of driver code to remove polling for qup v1
  i2c: qup: reorganization of driver code to remove polling for qup v2

 drivers/i2c/busses/i2c-qup.c | 1538 +-
 1 file changed, 924 insertions(+), 614 deletions(-)

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 02/12] i2c: qup: minor code reorganization for use_dma

[Abhishek Sahu]

1. Assigns use_dma in qup_dev structure itself which will
   help in subsequent patches to determine the mode in IRQ handler.
2. Does minor code reorganization for loops to reduce the
   unnecessary comparison and assignment.

Signed-off-by: Abhishek Sahu 
---
 drivers/i2c/busses/i2c-qup.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index 9faa26c41a..c68f433 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -190,6 +190,8 @@ struct qup_i2c_dev {
 
/* dma parameters */
boolis_dma;
+   /* To check if the current transfer is using DMA */
+   booluse_dma;
struct  dma_pool *dpool;
struct  qup_i2c_tag start_tag;
struct  qup_i2c_bam brx;
@@ -1297,7 +1299,7 @@ static int qup_i2c_xfer_v2(struct i2c_adapter *adap,
   int num)
 {
struct qup_i2c_dev *qup = i2c_get_adapdata(adap);
-   int ret, len, idx = 0, use_dma = 0;
+   int ret, len, idx = 0;
 
qup->bus_err = 0;
qup->qup_err = 0;
@@ -1326,13 +1328,12 @@ static int qup_i2c_xfer_v2(struct i2c_adapter *adap,
len = (msgs[idx].len > qup->out_fifo_sz) ||
  (msgs[idx].len > qup->in_fifo_sz);
 
-   if ((!is_vmalloc_addr(msgs[idx].buf)) && len) {
-   use_dma = 1;
-} else {
-   use_dma = 0;
+   if (is_vmalloc_addr(msgs[idx].buf) || !len)
break;
-   }
}
+
+   if (idx == num)
+   qup->use_dma = true;
}
 
idx = 0;
@@ -1356,15 +1357,17 @@ static int qup_i2c_xfer_v2(struct i2c_adapter *adap,
 
reinit_completion(>xfer);
 
-   if (use_dma) {
+   if (qup->use_dma) {
ret = qup_i2c_bam_xfer(adap, [idx], num);
+   qup->use_dma = false;
+   break;
} else {
if (msgs[idx].flags & I2C_M_RD)
ret = qup_i2c_read_one_v2(qup, [idx]);
else
ret = qup_i2c_write_one_v2(qup, [idx]);
}
-   } while ((idx++ < (num - 1)) && !use_dma && !ret);
+   } while ((idx++ < (num - 1)) && !ret);
 
if (!ret)
ret = qup_i2c_change_state(qup, QUP_RESET_STATE);
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 01/12] i2c: qup: fixed releasing dma without flush operation completion

[Abhishek Sahu]

The QUP BSLP BAM generates the following error sometimes if the
current I2C DMA transfer fails and the flush operation has been
scheduled

“bam-dma-engine 7884000.dma: Cannot free busy channel”

If any I2C error comes during BAM DMA transfer, then the QUP I2C
interrupt will be generated and the flush operation will be
carried out to make i2c consume all scheduled DMA transfer.
Currently, the same completion structure is being used for BAM
transfer which has already completed without reinit. It will make
flush operation wait_for_completion_timeout completed immediately
and will proceed for freeing the DMA resources where the
descriptors are still in process.

Signed-off-by: Abhishek Sahu 
---
 drivers/i2c/busses/i2c-qup.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index 08f8e01..9faa26c41a 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2009-2013, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2009-2013, 2016-2018, The Linux Foundation. All rights 
reserved.
  * Copyright (c) 2014, Sony Mobile Communications AB.
  *
  *
@@ -844,6 +844,8 @@ static int qup_i2c_bam_do_xfer(struct qup_i2c_dev *qup, 
struct i2c_msg *msg,
}
 
if (ret || qup->bus_err || qup->qup_err) {
+   reinit_completion(>xfer);
+
if (qup_i2c_change_state(qup, QUP_RUN_STATE)) {
dev_err(qup->dev, "change to run state timed out");
goto desc_err;
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH v2 2/2] HID: core: Fix size as type u32

[Marcus Folkesson]

Hi Aaron,

On Mon, Jan 08, 2018 at 10:41:41AM +0800, Aaron Ma wrote:
> When size is negative, calling memset will make segment fault.
> Declare the size as type u32 to keep memset safe.
> 
> size in struct hid_report is unsigned, fix return type of
> hid_report_len to u32.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Aaron Ma 
> ---
>  drivers/hid/hid-core.c | 10 +-
>  include/linux/hid.h|  6 +++---
>  2 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 0c3f608131cf..cf81c53e3b98 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1390,7 +1390,7 @@ u8 *hid_alloc_report_buf(struct hid_report *report, 
> gfp_t flags)
>* of implement() working on 8 byte chunks
>*/
>  
> - int len = hid_report_len(report) + 7;
> + u32 len = hid_report_len(report) + 7;
>  
>   return kmalloc(len, flags);
>  }
> @@ -1455,7 +1455,7 @@ void __hid_request(struct hid_device *hid, struct 
> hid_report *report,
>  {
>   char *buf;
>   int ret;
> - int len;
> + u32 len;
>  
>   buf = hid_alloc_report_buf(report, GFP_KERNEL);
>   if (!buf)
> @@ -1481,14 +1481,14 @@ void __hid_request(struct hid_device *hid, struct 
> hid_report *report,
>  }
>  EXPORT_SYMBOL_GPL(__hid_request);
>  
> -int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, int 
> size,
> +int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, u32 
> size,
>   int interrupt)
>  {
>   struct hid_report_enum *report_enum = hid->report_enum + type;
>   struct hid_report *report;
>   struct hid_driver *hdrv;
>   unsigned int a;
> - int rsize, csize = size;
> + u32 rsize, csize = size;
>   u8 *cdata = data;
>   int ret = 0;
>  
> @@ -1546,7 +1546,7 @@ EXPORT_SYMBOL_GPL(hid_report_raw_event);
>   *
>   * This is data entry for lower layers.
>   */
> -int hid_input_report(struct hid_device *hid, int type, u8 *data, int size, 
> int interrupt)
> +int hid_input_report(struct hid_device *hid, int type, u8 *data, u32 size, 
> int interrupt)
>  {
>   struct hid_report_enum *report_enum;
>   struct hid_driver *hdrv;
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index d491027a7c22..9bc296eebc98 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -841,7 +841,7 @@ extern int hidinput_connect(struct hid_device *hid, 
> unsigned int force);
>  extern void hidinput_disconnect(struct hid_device *);
>  
>  int hid_set_field(struct hid_field *, unsigned, __s32);
> -int hid_input_report(struct hid_device *, int type, u8 *, int, int);
> +int hid_input_report(struct hid_device *, int type, u8 *, u32, int);
>  int hidinput_find_field(struct hid_device *hid, unsigned int type, unsigned 
> int code, struct hid_field **field);
>  struct hid_field *hidinput_get_led_field(struct hid_device *hid);
>  unsigned int hidinput_count_leds(struct hid_device *hid);
> @@ -1088,13 +1088,13 @@ static inline void hid_hw_wait(struct hid_device 
> *hdev)
>   *
>   * @report: the report we want to know the length
>   */
> -static inline int hid_report_len(struct hid_report *report)
> +static inline u32 hid_report_len(struct hid_report *report)

hid_report_len() is used in several files.
If we think it is a good idea to change the return type, we should fix
these files as well.

[08:47:56]marcus@little:~/git/linux$ git grep -l hid_report_len
drivers/hid/hid-core.c
drivers/hid/hid-input.c
drivers/hid/hid-multitouch.c
drivers/hid/hid-rmi.c
drivers/hid/usbhid/hid-core.c
drivers/hid/wacom_sys.c
drivers/staging/greybus/hid.c
include/linux/hid.h

>  {
>   /* equivalent to DIV_ROUND_UP(report->size, 8) + !!(report->id > 0) */
>   return ((report->size - 1) >> 3) + 1 + (report->id > 0);
>  }
>  
> -int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, int 
> size,
> +int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, u32 
> size,
>   int interrupt);
>  
>  /* HID quirks API */
> -- 
> 2.14.3

Best regards
Marcus Folkesson
> 


signature.asc
Description: PGP signature

Re: [PATCH v2 2/2] HID: core: Fix size as type u32

[Marcus Folkesson]

Hi Aaron,

On Mon, Jan 08, 2018 at 10:41:41AM +0800, Aaron Ma wrote:
> When size is negative, calling memset will make segment fault.
> Declare the size as type u32 to keep memset safe.
> 
> size in struct hid_report is unsigned, fix return type of
> hid_report_len to u32.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Aaron Ma 
> ---
>  drivers/hid/hid-core.c | 10 +-
>  include/linux/hid.h|  6 +++---
>  2 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 0c3f608131cf..cf81c53e3b98 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1390,7 +1390,7 @@ u8 *hid_alloc_report_buf(struct hid_report *report, 
> gfp_t flags)
>* of implement() working on 8 byte chunks
>*/
>  
> - int len = hid_report_len(report) + 7;
> + u32 len = hid_report_len(report) + 7;
>  
>   return kmalloc(len, flags);
>  }
> @@ -1455,7 +1455,7 @@ void __hid_request(struct hid_device *hid, struct 
> hid_report *report,
>  {
>   char *buf;
>   int ret;
> - int len;
> + u32 len;
>  
>   buf = hid_alloc_report_buf(report, GFP_KERNEL);
>   if (!buf)
> @@ -1481,14 +1481,14 @@ void __hid_request(struct hid_device *hid, struct 
> hid_report *report,
>  }
>  EXPORT_SYMBOL_GPL(__hid_request);
>  
> -int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, int 
> size,
> +int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, u32 
> size,
>   int interrupt)
>  {
>   struct hid_report_enum *report_enum = hid->report_enum + type;
>   struct hid_report *report;
>   struct hid_driver *hdrv;
>   unsigned int a;
> - int rsize, csize = size;
> + u32 rsize, csize = size;
>   u8 *cdata = data;
>   int ret = 0;
>  
> @@ -1546,7 +1546,7 @@ EXPORT_SYMBOL_GPL(hid_report_raw_event);
>   *
>   * This is data entry for lower layers.
>   */
> -int hid_input_report(struct hid_device *hid, int type, u8 *data, int size, 
> int interrupt)
> +int hid_input_report(struct hid_device *hid, int type, u8 *data, u32 size, 
> int interrupt)
>  {
>   struct hid_report_enum *report_enum;
>   struct hid_driver *hdrv;
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index d491027a7c22..9bc296eebc98 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -841,7 +841,7 @@ extern int hidinput_connect(struct hid_device *hid, 
> unsigned int force);
>  extern void hidinput_disconnect(struct hid_device *);
>  
>  int hid_set_field(struct hid_field *, unsigned, __s32);
> -int hid_input_report(struct hid_device *, int type, u8 *, int, int);
> +int hid_input_report(struct hid_device *, int type, u8 *, u32, int);
>  int hidinput_find_field(struct hid_device *hid, unsigned int type, unsigned 
> int code, struct hid_field **field);
>  struct hid_field *hidinput_get_led_field(struct hid_device *hid);
>  unsigned int hidinput_count_leds(struct hid_device *hid);
> @@ -1088,13 +1088,13 @@ static inline void hid_hw_wait(struct hid_device 
> *hdev)
>   *
>   * @report: the report we want to know the length
>   */
> -static inline int hid_report_len(struct hid_report *report)
> +static inline u32 hid_report_len(struct hid_report *report)

hid_report_len() is used in several files.
If we think it is a good idea to change the return type, we should fix
these files as well.

[08:47:56]marcus@little:~/git/linux$ git grep -l hid_report_len
drivers/hid/hid-core.c
drivers/hid/hid-input.c
drivers/hid/hid-multitouch.c
drivers/hid/hid-rmi.c
drivers/hid/usbhid/hid-core.c
drivers/hid/wacom_sys.c
drivers/staging/greybus/hid.c
include/linux/hid.h

>  {
>   /* equivalent to DIV_ROUND_UP(report->size, 8) + !!(report->id > 0) */
>   return ((report->size - 1) >> 3) + 1 + (report->id > 0);
>  }
>  
> -int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, int 
> size,
> +int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, u32 
> size,
>   int interrupt);
>  
>  /* HID quirks API */
> -- 
> 2.14.3

Best regards
Marcus Folkesson
> 


signature.asc
Description: PGP signature

Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

[David Woodhouse]

On Fri, 2018-02-02 at 23:52 -0500, tedheadster wrote:
> I just tested the 4.15 kernel and it is reporting that my old i486
> (non-cpuid capable) cpu is vulnerable to all three issues: Meltdown,
> Spectre V1, and Spectre V2.
> 
> I find this to be _unlikely_.

This should be fixed in Linus' tree already by commit fec9434a1
("x86/pti: Do not enable PTI on CPUs which are not vulnerable to
Meltdown").

We'll make sure it ends up in the stable tree too, if it hasn't
already.

smime.p7s
Description: S/MIME cryptographic signature

Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

[David Woodhouse]

On Fri, 2018-02-02 at 23:52 -0500, tedheadster wrote:
> I just tested the 4.15 kernel and it is reporting that my old i486
> (non-cpuid capable) cpu is vulnerable to all three issues: Meltdown,
> Spectre V1, and Spectre V2.
> 
> I find this to be _unlikely_.

This should be fixed in Linus' tree already by commit fec9434a1
("x86/pti: Do not enable PTI on CPUs which are not vulnerable to
Meltdown").

We'll make sure it ends up in the stable tree too, if it hasn't
already.

smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH 1/3] net: stmmac: dwmac-sun8i: drop V3s compatible and add V3 one

[Icenowy Zheng]

于 2018年2月3日 GMT+08:00 上午6:13:01, Maxime Ripard  写到:
>On Sat, Feb 03, 2018 at 02:04:54AM +0800, Icenowy Zheng wrote:
>> The V3s is just a differently packaged version of the V3 chip, which
>has
>> a MAC with the same capability with H3. The V3s just doesn't wire out
>> the external MII/RMII/RGMII bus. (V3 wired out it).
>> 
>> Drop the compatible string of V3s in the dwmac-sun8i driver, and add
>a
>> V3 compatible string, which has all capabilities.
>> 
>> Signed-off-by: Icenowy Zheng 
>
>This breaks the DT ABI, so NAK.

I have asked this at IRC.

The V3s compatible string is never used in any mainline
kernel, even not in any RC version.

>
>Maxime

Re: Coccinelle: zalloc-simple: Checking consistency for SmPL rules

[SF Markus Elfring]

>> * Do we agree that a proper size determination is essential for every
>>   condition in the discussed SmPL rules together with forwarding
>>   this information?
> 
> No.  I don't mind a few false positives.

Do you care to split SmPL rules by their confidence category in such an use 
case?

Regards,
Markus

Re: [PATCH 1/3] net: stmmac: dwmac-sun8i: drop V3s compatible and add V3 one

[Icenowy Zheng]

于 2018年2月3日 GMT+08:00 上午6:13:01, Maxime Ripard  写到:
>On Sat, Feb 03, 2018 at 02:04:54AM +0800, Icenowy Zheng wrote:
>> The V3s is just a differently packaged version of the V3 chip, which
>has
>> a MAC with the same capability with H3. The V3s just doesn't wire out
>> the external MII/RMII/RGMII bus. (V3 wired out it).
>> 
>> Drop the compatible string of V3s in the dwmac-sun8i driver, and add
>a
>> V3 compatible string, which has all capabilities.
>> 
>> Signed-off-by: Icenowy Zheng 
>
>This breaks the DT ABI, so NAK.

I have asked this at IRC.

The V3s compatible string is never used in any mainline
kernel, even not in any RC version.

>
>Maxime

Re: Coccinelle: zalloc-simple: Checking consistency for SmPL rules

[SF Markus Elfring]

>> * Do we agree that a proper size determination is essential for every
>>   condition in the discussed SmPL rules together with forwarding
>>   this information?
> 
> No.  I don't mind a few false positives.

Do you care to split SmPL rules by their confidence category in such an use 
case?

Regards,
Markus

Re: [linux-sunxi] [PATCH 1/3] net: stmmac: dwmac-sun8i: drop V3s compatible and add V3 one

[Icenowy Zheng]

于 2018年2月3日 GMT+08:00 下午2:00:33, Julian Calaby  写到:
>Hi Icenowy,
>
>On Sat, Feb 3, 2018 at 5:04 AM, Icenowy Zheng  wrote:
>> The V3s is just a differently packaged version of the V3 chip, which
>has
>> a MAC with the same capability with H3. The V3s just doesn't wire out
>> the external MII/RMII/RGMII bus. (V3 wired out it).
>>
>> Drop the compatible string of V3s in the dwmac-sun8i driver, and add
>a
>> V3 compatible string, which has all capabilities.
>
>Aren't compatible strings technically API, so don't we need to support
>those that are out in the wild "forever"?
>
>Therefore shouldn't we leave the v3s variant around for compatibility
>with existing device trees?

You can run grep at arch/arm/boot/dts, this compatible
string is not used at all.

>
>Thanks,

Re: [linux-sunxi] [PATCH 1/3] net: stmmac: dwmac-sun8i: drop V3s compatible and add V3 one

[Icenowy Zheng]

于 2018年2月3日 GMT+08:00 下午2:00:33, Julian Calaby  写到:
>Hi Icenowy,
>
>On Sat, Feb 3, 2018 at 5:04 AM, Icenowy Zheng  wrote:
>> The V3s is just a differently packaged version of the V3 chip, which
>has
>> a MAC with the same capability with H3. The V3s just doesn't wire out
>> the external MII/RMII/RGMII bus. (V3 wired out it).
>>
>> Drop the compatible string of V3s in the dwmac-sun8i driver, and add
>a
>> V3 compatible string, which has all capabilities.
>
>Aren't compatible strings technically API, so don't we need to support
>those that are out in the wild "forever"?
>
>Therefore shouldn't we leave the v3s variant around for compatibility
>with existing device trees?

You can run grep at arch/arm/boot/dts, this compatible
string is not used at all.

>
>Thanks,

Re: clang warning: implicit conversion in intel_ddi.c:1481

[Knut Omang]

On Fri, 2018-02-02 at 16:50 +0100, Greg KH wrote:
> On Fri, Feb 02, 2018 at 04:37:55PM +0200, Jani Nikula wrote:
> > On Fri, 02 Feb 2018, Greg KH  wrote:
> > > On Fri, Feb 02, 2018 at 12:44:38PM +0200, Jani Nikula wrote:
> > >> 
> > >> +Knut, Fengguang
> > >> 
> > >> On Fri, 02 Feb 2018, Greg KH  wrote:
> > >> >- If clang now builds the kernel "cleanly", yes, I want to take
> > >> >  warning fixes in the stable tree.  And even better yet, if you
> > >> >  keep working to ensure the tree is "clean", that would be
> > >> >  wonderful.
> > >> 
> > >> So we can run sparse using 'make C=1' and friends, or other static
> > >> analysis tools using 'make CHECK=foo C=1', as long as the passed command
> > >> line params work. There was work by Knut to extend this make checker
> > >> stuff [1]. Since mixing different HOSTCC's in a single workdir seems
> > >> like a bad idea, I wonder how hard it would be to make clang work like
> > >> this:
> > >> 
> > >> $ make CHECK=clang C=1
> > >> 
> > >> Or using Knut's wrapper. Feels like that could increase the use of clang
> > >> for static analysis of patches.
> > >
> > > Why not just build with clang itself:
> > >   make CC=clang
> > 
> > Same as HOSTCC, mixing different CC's in a single build dir seems like a
> > bad idea. Sure, everyone can setup a separate build dir for clang, but
> > IMHO having 'make CHECK=clang C=1' work has least resistance. YMMV.
> 
> "O=some_output_dir" is your friend.  If you aren't doing that already
> for your test builds, you don't know what you are missing :)

I use O= a lot myself - so good not to have all the output files "pollute" the 
source
tree, and to be able to switch branches and compile without having to recompile 
everything
by having multiple O= set up.

I think what my runchecks wrapper script brings in addition is the ability to 
to a number
of checks which may or may not pass, even return error codes, from the same 
'make' command
and configure what errors to fix now and what to postpone/ignore (and thus not 
fail from).

As an example, I just tried clang (on v4.15-rc6) with:

cd $HOME/src/kernel
make O=$HOME/build/kernel/clang
cd $HOME/build/kernel/clang
make

and it fails to compile for me in arch/x86/xen/mmu_pv.o. 

If I'd want to just make sure that some patches did not introduce new errors 
with clang, 
I would waste some time with unrelated errors, and there will be noise in the 
output, also
consuming personal "cycles".

I haven't really looked at the details of much of what clang outputs of errors 
yet, but I
can imagine that specific errors reported by clang might be useful to correct 
even in old
kernels, where some files inevitably will fail to compile like this.

This would be easy to handle with runchecks using a few exceptions for those
problems/files not yet fixed, allowing a run to easily detect (while compiling 
with gcc as
the main compiler) that no new clang errors were introduced of any other kind 
than those
suppressed.

Thanks,
Knut

> 
> thanks,
> 
> greg k-h

Re: clang warning: implicit conversion in intel_ddi.c:1481

[Knut Omang]

On Fri, 2018-02-02 at 16:50 +0100, Greg KH wrote:
> On Fri, Feb 02, 2018 at 04:37:55PM +0200, Jani Nikula wrote:
> > On Fri, 02 Feb 2018, Greg KH  wrote:
> > > On Fri, Feb 02, 2018 at 12:44:38PM +0200, Jani Nikula wrote:
> > >> 
> > >> +Knut, Fengguang
> > >> 
> > >> On Fri, 02 Feb 2018, Greg KH  wrote:
> > >> >- If clang now builds the kernel "cleanly", yes, I want to take
> > >> >  warning fixes in the stable tree.  And even better yet, if you
> > >> >  keep working to ensure the tree is "clean", that would be
> > >> >  wonderful.
> > >> 
> > >> So we can run sparse using 'make C=1' and friends, or other static
> > >> analysis tools using 'make CHECK=foo C=1', as long as the passed command
> > >> line params work. There was work by Knut to extend this make checker
> > >> stuff [1]. Since mixing different HOSTCC's in a single workdir seems
> > >> like a bad idea, I wonder how hard it would be to make clang work like
> > >> this:
> > >> 
> > >> $ make CHECK=clang C=1
> > >> 
> > >> Or using Knut's wrapper. Feels like that could increase the use of clang
> > >> for static analysis of patches.
> > >
> > > Why not just build with clang itself:
> > >   make CC=clang
> > 
> > Same as HOSTCC, mixing different CC's in a single build dir seems like a
> > bad idea. Sure, everyone can setup a separate build dir for clang, but
> > IMHO having 'make CHECK=clang C=1' work has least resistance. YMMV.
> 
> "O=some_output_dir" is your friend.  If you aren't doing that already
> for your test builds, you don't know what you are missing :)

I use O= a lot myself - so good not to have all the output files "pollute" the 
source
tree, and to be able to switch branches and compile without having to recompile 
everything
by having multiple O= set up.

I think what my runchecks wrapper script brings in addition is the ability to 
to a number
of checks which may or may not pass, even return error codes, from the same 
'make' command
and configure what errors to fix now and what to postpone/ignore (and thus not 
fail from).

As an example, I just tried clang (on v4.15-rc6) with:

cd $HOME/src/kernel
make O=$HOME/build/kernel/clang
cd $HOME/build/kernel/clang
make

and it fails to compile for me in arch/x86/xen/mmu_pv.o. 

If I'd want to just make sure that some patches did not introduce new errors 
with clang, 
I would waste some time with unrelated errors, and there will be noise in the 
output, also
consuming personal "cycles".

I haven't really looked at the details of much of what clang outputs of errors 
yet, but I
can imagine that specific errors reported by clang might be useful to correct 
even in old
kernels, where some files inevitably will fail to compile like this.

This would be easy to handle with runchecks using a few exceptions for those
problems/files not yet fixed, allowing a run to easily detect (while compiling 
with gcc as
the main compiler) that no new clang errors were introduced of any other kind 
than those
suppressed.

Thanks,
Knut

> 
> thanks,
> 
> greg k-h

Re: [PATCH RESEND v3] perf/core: Fix installing cgroup event into cpu

[kbuild test robot]

Hi leilei.lin,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on tip/perf/core]
[also build test ERROR on v4.15 next-20180202]
[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/linxiulei-gmail-com/perf-core-Fix-installing-cgroup-event-into-cpu/20180203-133110
config: i386-randconfig-s0-201804 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   kernel/events/core.c: In function '__perf_install_in_context':
>> kernel/events/core.c:2332:10: error: implicit declaration of function 
>> 'perf_cgroup_from_task' [-Werror=implicit-function-declaration]
  cgrp = perf_cgroup_from_task(current, ctx);
 ^
   kernel/events/core.c:2332:8: warning: assignment makes pointer from integer 
without a cast [-Wint-conversion]
  cgrp = perf_cgroup_from_task(current, ctx);
   ^
   kernel/events/core.c:2333:40: error: dereferencing pointer to incomplete 
type 'struct perf_cgroup'
  reprogram = cgroup_is_descendant(cgrp->css.cgroup,
   ^~
   kernel/events/core.c:2334:11: error: 'struct perf_event' has no member named 
'cgrp'
 event->cgrp->css.cgroup);
  ^~
   cc1: some warnings being treated as errors

vim +/perf_cgroup_from_task +2332 kernel/events/core.c

  2284  
  2285  /*
  2286   * Cross CPU call to install and enable a performance event
  2287   *
  2288   * Very similar to remote_function() + event_function() but cannot 
assume that
  2289   * things like ctx->is_active and cpuctx->task_ctx are set.
  2290   */
  2291  static int  __perf_install_in_context(void *info)
  2292  {
  2293  struct perf_event *event = info;
  2294  struct perf_event_context *ctx = event->ctx;
  2295  struct perf_cpu_context *cpuctx = __get_cpu_context(ctx);
  2296  struct perf_event_context *task_ctx = cpuctx->task_ctx;
  2297  struct perf_cgroup *cgrp;
  2298  bool reprogram = true;
  2299  int ret = 0;
  2300  
  2301  raw_spin_lock(>ctx.lock);
  2302  if (ctx->task) {
  2303  raw_spin_lock(>lock);
  2304  task_ctx = ctx;
  2305  
  2306  reprogram = (ctx->task == current);
  2307  
  2308  /*
  2309   * If the task is running, it must be running on this 
CPU,
  2310   * otherwise we cannot reprogram things.
  2311   *
  2312   * If its not running, we don't care, ctx->lock will
  2313   * serialize against it becoming runnable.
  2314   */
  2315  if (task_curr(ctx->task) && !reprogram) {
  2316  ret = -ESRCH;
  2317  goto unlock;
  2318  }
  2319  
  2320  WARN_ON_ONCE(reprogram && cpuctx->task_ctx && 
cpuctx->task_ctx != ctx);
  2321  } else if (task_ctx) {
  2322  raw_spin_lock(_ctx->lock);
  2323  }
  2324  
  2325  if (is_cgroup_event(event)) {
  2326  /*
  2327   * Only care about cgroup events.
  2328   *
  2329   * If only the task belongs to cgroup of this event,
  2330   * we will continue the installment
  2331   */
> 2332  cgrp = perf_cgroup_from_task(current, ctx);
  2333  reprogram = cgroup_is_descendant(cgrp->css.cgroup,
  2334  event->cgrp->css.cgroup);
  2335  }
  2336  
  2337  if (reprogram) {
  2338  ctx_sched_out(ctx, cpuctx, EVENT_TIME);
  2339  add_event_to_ctx(event, ctx);
  2340  ctx_resched(cpuctx, task_ctx, get_event_type(event));
  2341  } else {
  2342  add_event_to_ctx(event, ctx);
  2343  }
  2344  
  2345  unlock:
  2346  perf_ctx_unlock(cpuctx, task_ctx);
  2347  
  2348  return ret;
  2349  }
  2350  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH RESEND v3] perf/core: Fix installing cgroup event into cpu

[kbuild test robot]

Hi leilei.lin,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on tip/perf/core]
[also build test ERROR on v4.15 next-20180202]
[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/linxiulei-gmail-com/perf-core-Fix-installing-cgroup-event-into-cpu/20180203-133110
config: i386-randconfig-s0-201804 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   kernel/events/core.c: In function '__perf_install_in_context':
>> kernel/events/core.c:2332:10: error: implicit declaration of function 
>> 'perf_cgroup_from_task' [-Werror=implicit-function-declaration]
  cgrp = perf_cgroup_from_task(current, ctx);
 ^
   kernel/events/core.c:2332:8: warning: assignment makes pointer from integer 
without a cast [-Wint-conversion]
  cgrp = perf_cgroup_from_task(current, ctx);
   ^
   kernel/events/core.c:2333:40: error: dereferencing pointer to incomplete 
type 'struct perf_cgroup'
  reprogram = cgroup_is_descendant(cgrp->css.cgroup,
   ^~
   kernel/events/core.c:2334:11: error: 'struct perf_event' has no member named 
'cgrp'
 event->cgrp->css.cgroup);
  ^~
   cc1: some warnings being treated as errors

vim +/perf_cgroup_from_task +2332 kernel/events/core.c

  2284  
  2285  /*
  2286   * Cross CPU call to install and enable a performance event
  2287   *
  2288   * Very similar to remote_function() + event_function() but cannot 
assume that
  2289   * things like ctx->is_active and cpuctx->task_ctx are set.
  2290   */
  2291  static int  __perf_install_in_context(void *info)
  2292  {
  2293  struct perf_event *event = info;
  2294  struct perf_event_context *ctx = event->ctx;
  2295  struct perf_cpu_context *cpuctx = __get_cpu_context(ctx);
  2296  struct perf_event_context *task_ctx = cpuctx->task_ctx;
  2297  struct perf_cgroup *cgrp;
  2298  bool reprogram = true;
  2299  int ret = 0;
  2300  
  2301  raw_spin_lock(>ctx.lock);
  2302  if (ctx->task) {
  2303  raw_spin_lock(>lock);
  2304  task_ctx = ctx;
  2305  
  2306  reprogram = (ctx->task == current);
  2307  
  2308  /*
  2309   * If the task is running, it must be running on this 
CPU,
  2310   * otherwise we cannot reprogram things.
  2311   *
  2312   * If its not running, we don't care, ctx->lock will
  2313   * serialize against it becoming runnable.
  2314   */
  2315  if (task_curr(ctx->task) && !reprogram) {
  2316  ret = -ESRCH;
  2317  goto unlock;
  2318  }
  2319  
  2320  WARN_ON_ONCE(reprogram && cpuctx->task_ctx && 
cpuctx->task_ctx != ctx);
  2321  } else if (task_ctx) {
  2322  raw_spin_lock(_ctx->lock);
  2323  }
  2324  
  2325  if (is_cgroup_event(event)) {
  2326  /*
  2327   * Only care about cgroup events.
  2328   *
  2329   * If only the task belongs to cgroup of this event,
  2330   * we will continue the installment
  2331   */
> 2332  cgrp = perf_cgroup_from_task(current, ctx);
  2333  reprogram = cgroup_is_descendant(cgrp->css.cgroup,
  2334  event->cgrp->css.cgroup);
  2335  }
  2336  
  2337  if (reprogram) {
  2338  ctx_sched_out(ctx, cpuctx, EVENT_TIME);
  2339  add_event_to_ctx(event, ctx);
  2340  ctx_resched(cpuctx, task_ctx, get_event_type(event));
  2341  } else {
  2342  add_event_to_ctx(event, ctx);
  2343  }
  2344  
  2345  unlock:
  2346  perf_ctx_unlock(cpuctx, task_ctx);
  2347  
  2348  return ret;
  2349  }
  2350  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH] media: cx25821: prevent out-of-bounds read on array card

[kbuild test robot]

Hi Colin,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.15 next-20180202]
[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/Colin-King/media-cx25821-prevent-out-of-bounds-read-on-array-card/20180203-130958
base:   git://linuxtv.org/media_tree.git master
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All warnings (new ones prefixed by >>):

   In file included from include/linux/printk.h:7:0,
from include/linux/kernel.h:14,
from include/linux/list.h:9,
from include/linux/kobject.h:20,
from include/linux/device.h:17,
from include/linux/i2c.h:30,
from drivers/media/pci/cx25821/cx25821-core.c:22:
   drivers/media/pci/cx25821/cx25821-core.c: In function 'cx25821_dev_setup':
>> include/linux/kern_levels.h:5:18: warning: format '%ld' expects argument of 
>> type 'long int', but argument 3 has type 'unsigned int' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   include/linux/kern_levels.h:14:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
  ^~~~
   include/linux/printk.h:308:9: note: in expansion of macro 'KERN_INFO'
 printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^
>> drivers/media/pci/cx25821/cx25821.h:380:2: note: in expansion of macro 
>> 'pr_info'
 pr_info("(%d): " fmt, dev->board, ##args)
 ^~~
>> drivers/media/pci/cx25821/cx25821-core.c:871:3: note: in expansion of macro 
>> 'CX25821_INFO'
  CX25821_INFO("dev->nr >= %ld", ARRAY_SIZE(card));
  ^~~~

vim +/pr_info +380 drivers/media/pci/cx25821/cx25821.h

02b20b0b drivers/staging/cx25821/cx25821.h Mauro Carvalho Chehab 2009-09-15  
374  
36d89f7d drivers/staging/cx25821/cx25821.h Joe Perches   2010-11-07  
375  #define CX25821_ERR(fmt, args...) \
36d89f7d drivers/staging/cx25821/cx25821.h Joe Perches   2010-11-07  
376pr_err("(%d): " fmt, dev->board, ##args)
36d89f7d drivers/staging/cx25821/cx25821.h Joe Perches   2010-11-07  
377  #define CX25821_WARN(fmt, args...)\
36d89f7d drivers/staging/cx25821/cx25821.h Joe Perches   2010-11-07  
378pr_warn("(%d): " fmt, dev->board, ##args)
36d89f7d drivers/staging/cx25821/cx25821.h Joe Perches   2010-11-07  
379  #define CX25821_INFO(fmt, args...)\
36d89f7d drivers/staging/cx25821/cx25821.h Joe Perches   2010-11-07 
@380pr_info("(%d): " fmt, dev->board, ##args)
02b20b0b drivers/staging/cx25821/cx25821.h Mauro Carvalho Chehab 2009-09-15  
381  

:: The code at line 380 was first introduced by commit
:: 36d89f7de4a4937848de86d9b35cb03a9f0357e1 [media] 
drivers/staging/cx25821: Use pr_fmt and pr_

:: TO: Joe Perches <j...@perches.com>
:: CC: Mauro Carvalho Chehab <mche...@redhat.com>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH] media: cx25821: prevent out-of-bounds read on array card

[kbuild test robot]

Hi Colin,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.15 next-20180202]
[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/Colin-King/media-cx25821-prevent-out-of-bounds-read-on-array-card/20180203-130958
base:   git://linuxtv.org/media_tree.git master
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All warnings (new ones prefixed by >>):

   In file included from include/linux/printk.h:7:0,
from include/linux/kernel.h:14,
from include/linux/list.h:9,
from include/linux/kobject.h:20,
from include/linux/device.h:17,
from include/linux/i2c.h:30,
from drivers/media/pci/cx25821/cx25821-core.c:22:
   drivers/media/pci/cx25821/cx25821-core.c: In function 'cx25821_dev_setup':
>> include/linux/kern_levels.h:5:18: warning: format '%ld' expects argument of 
>> type 'long int', but argument 3 has type 'unsigned int' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   include/linux/kern_levels.h:14:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
  ^~~~
   include/linux/printk.h:308:9: note: in expansion of macro 'KERN_INFO'
 printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^
>> drivers/media/pci/cx25821/cx25821.h:380:2: note: in expansion of macro 
>> 'pr_info'
 pr_info("(%d): " fmt, dev->board, ##args)
 ^~~
>> drivers/media/pci/cx25821/cx25821-core.c:871:3: note: in expansion of macro 
>> 'CX25821_INFO'
  CX25821_INFO("dev->nr >= %ld", ARRAY_SIZE(card));
  ^~~~

vim +/pr_info +380 drivers/media/pci/cx25821/cx25821.h

02b20b0b drivers/staging/cx25821/cx25821.h Mauro Carvalho Chehab 2009-09-15  
374  
36d89f7d drivers/staging/cx25821/cx25821.h Joe Perches   2010-11-07  
375  #define CX25821_ERR(fmt, args...) \
36d89f7d drivers/staging/cx25821/cx25821.h Joe Perches   2010-11-07  
376pr_err("(%d): " fmt, dev->board, ##args)
36d89f7d drivers/staging/cx25821/cx25821.h Joe Perches   2010-11-07  
377  #define CX25821_WARN(fmt, args...)\
36d89f7d drivers/staging/cx25821/cx25821.h Joe Perches   2010-11-07  
378pr_warn("(%d): " fmt, dev->board, ##args)
36d89f7d drivers/staging/cx25821/cx25821.h Joe Perches   2010-11-07  
379  #define CX25821_INFO(fmt, args...)\
36d89f7d drivers/staging/cx25821/cx25821.h Joe Perches   2010-11-07 
@380pr_info("(%d): " fmt, dev->board, ##args)
02b20b0b drivers/staging/cx25821/cx25821.h Mauro Carvalho Chehab 2009-09-15  
381  

:: The code at line 380 was first introduced by commit
:: 36d89f7de4a4937848de86d9b35cb03a9f0357e1 [media] 
drivers/staging/cx25821: Use pr_fmt and pr_

:: TO: Joe Perches 
:: CC: Mauro Carvalho Chehab 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [linux-sunxi] [PATCH 1/3] net: stmmac: dwmac-sun8i: drop V3s compatible and add V3 one

[Julian Calaby]

Hi Icenowy,

On Sat, Feb 3, 2018 at 5:04 AM, Icenowy Zheng  wrote:
> The V3s is just a differently packaged version of the V3 chip, which has
> a MAC with the same capability with H3. The V3s just doesn't wire out
> the external MII/RMII/RGMII bus. (V3 wired out it).
>
> Drop the compatible string of V3s in the dwmac-sun8i driver, and add a
> V3 compatible string, which has all capabilities.

Aren't compatible strings technically API, so don't we need to support
those that are out in the wild "forever"?

Therefore shouldn't we leave the v3s variant around for compatibility
with existing device trees?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [linux-sunxi] [PATCH 1/3] net: stmmac: dwmac-sun8i: drop V3s compatible and add V3 one

[Julian Calaby]

Hi Icenowy,

On Sat, Feb 3, 2018 at 5:04 AM, Icenowy Zheng  wrote:
> The V3s is just a differently packaged version of the V3 chip, which has
> a MAC with the same capability with H3. The V3s just doesn't wire out
> the external MII/RMII/RGMII bus. (V3 wired out it).
>
> Drop the compatible string of V3s in the dwmac-sun8i driver, and add a
> V3 compatible string, which has all capabilities.

Aren't compatible strings technically API, so don't we need to support
those that are out in the wild "forever"?

Therefore shouldn't we leave the v3s variant around for compatibility
with existing device trees?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [PATCH AUTOSEL for 3.18 36/40] powerpc/xmon: Avoid tripping SMP hardlockup watchdog

[Nicholas Piggin]

On Tue, 30 Jan 2018 15:35:54 +1100
Michael Ellerman  wrote:

> alexander.le...@verizon.com writes:
> 
> > On Thu, Dec 14, 2017 at 12:10:39AM +1100, Michael Ellerman wrote:  
> >>alexander.le...@verizon.com writes:
> >>  
> >>> From: Nicholas Piggin 
> >>>
> >>> [ Upstream commit 064996d62a33ffe10264b5af5dca92d54f60f806 ]
> >>>
> >>> The SMP hardlockup watchdog cross-checks other CPUs for lockups, which
> >>> causes xmon headaches because it's assuming interrupts hard disabled
> >>> means no watchdog troubles. Try to improve that by calling
> >>> touch_nmi_watchdog() in obvious places where secondaries are spinning.
> >>>
> >>> Also annotate these spin loops with spin_begin/end calls.  
> >>
> >>These macros didn't exist until 4.13, and haven't been backported AFAIK.  
> >
> > But the touch_nmi_watchdog() bits are something we want in stable, right?  
> 
> I don't think you need them unless you've also back ported
> arch/powerpc/kernel/watchdog.c, which I don't think you have.
> 
> Maybe Nick can confirm?

I'm not 100% sure. The CPUs only check themselves for lockups. They will
blow their threshold when in xmon, but when they come out of xmon, I think
by a quirk of our local_irq_enable() implementation that actually checks
timers explicitly and runs them first before re-enabling hard interrupts,
then our heartbeat starts up again just before the perf interrupt would
come in to report the lockup.

I think.

Given that we've had no reports of misbehaviour of the old perf watchdog,
I would say you can skip the backport.

Thanks,
Nick

Re: [PATCH AUTOSEL for 3.18 36/40] powerpc/xmon: Avoid tripping SMP hardlockup watchdog

[Nicholas Piggin]

On Tue, 30 Jan 2018 15:35:54 +1100
Michael Ellerman  wrote:

> alexander.le...@verizon.com writes:
> 
> > On Thu, Dec 14, 2017 at 12:10:39AM +1100, Michael Ellerman wrote:  
> >>alexander.le...@verizon.com writes:
> >>  
> >>> From: Nicholas Piggin 
> >>>
> >>> [ Upstream commit 064996d62a33ffe10264b5af5dca92d54f60f806 ]
> >>>
> >>> The SMP hardlockup watchdog cross-checks other CPUs for lockups, which
> >>> causes xmon headaches because it's assuming interrupts hard disabled
> >>> means no watchdog troubles. Try to improve that by calling
> >>> touch_nmi_watchdog() in obvious places where secondaries are spinning.
> >>>
> >>> Also annotate these spin loops with spin_begin/end calls.  
> >>
> >>These macros didn't exist until 4.13, and haven't been backported AFAIK.  
> >
> > But the touch_nmi_watchdog() bits are something we want in stable, right?  
> 
> I don't think you need them unless you've also back ported
> arch/powerpc/kernel/watchdog.c, which I don't think you have.
> 
> Maybe Nick can confirm?

I'm not 100% sure. The CPUs only check themselves for lockups. They will
blow their threshold when in xmon, but when they come out of xmon, I think
by a quirk of our local_irq_enable() implementation that actually checks
timers explicitly and runs them first before re-enabling hard interrupts,
then our heartbeat starts up again just before the perf interrupt would
come in to report the lockup.

I think.

Given that we've had no reports of misbehaviour of the old perf watchdog,
I would say you can skip the backport.

Thanks,
Nick

Re: [PATCH RESEND v3] perf/core: Fix installing cgroup event into cpu

[kbuild test robot]

Hi leilei.lin,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on tip/perf/core]
[also build test ERROR on v4.15 next-20180202]
[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/linxiulei-gmail-com/perf-core-Fix-installing-cgroup-event-into-cpu/20180203-133110
config: i386-randconfig-x071-201804 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   kernel/events/core.c: In function '__perf_install_in_context':
>> kernel/events/core.c:2332:10: error: implicit declaration of function 
>> 'perf_cgroup_from_task'; did you mean 'perf_cgroup_match'? 
>> [-Werror=implicit-function-declaration]
  cgrp = perf_cgroup_from_task(current, ctx);
 ^
 perf_cgroup_match
   kernel/events/core.c:2332:8: warning: assignment makes pointer from integer 
without a cast [-Wint-conversion]
  cgrp = perf_cgroup_from_task(current, ctx);
   ^
>> kernel/events/core.c:2333:40: error: dereferencing pointer to incomplete 
>> type 'struct perf_cgroup'
  reprogram = cgroup_is_descendant(cgrp->css.cgroup,
   ^~
>> kernel/events/core.c:2334:11: error: 'struct perf_event' has no member named 
>> 'cgrp'
 event->cgrp->css.cgroup);
  ^~
   cc1: some warnings being treated as errors

vim +2332 kernel/events/core.c

  2284  
  2285  /*
  2286   * Cross CPU call to install and enable a performance event
  2287   *
  2288   * Very similar to remote_function() + event_function() but cannot 
assume that
  2289   * things like ctx->is_active and cpuctx->task_ctx are set.
  2290   */
  2291  static int  __perf_install_in_context(void *info)
  2292  {
  2293  struct perf_event *event = info;
  2294  struct perf_event_context *ctx = event->ctx;
  2295  struct perf_cpu_context *cpuctx = __get_cpu_context(ctx);
  2296  struct perf_event_context *task_ctx = cpuctx->task_ctx;
  2297  struct perf_cgroup *cgrp;
  2298  bool reprogram = true;
  2299  int ret = 0;
  2300  
  2301  raw_spin_lock(>ctx.lock);
  2302  if (ctx->task) {
  2303  raw_spin_lock(>lock);
  2304  task_ctx = ctx;
  2305  
  2306  reprogram = (ctx->task == current);
  2307  
  2308  /*
  2309   * If the task is running, it must be running on this 
CPU,
  2310   * otherwise we cannot reprogram things.
  2311   *
  2312   * If its not running, we don't care, ctx->lock will
  2313   * serialize against it becoming runnable.
  2314   */
  2315  if (task_curr(ctx->task) && !reprogram) {
  2316  ret = -ESRCH;
  2317  goto unlock;
  2318  }
  2319  
  2320  WARN_ON_ONCE(reprogram && cpuctx->task_ctx && 
cpuctx->task_ctx != ctx);
  2321  } else if (task_ctx) {
  2322  raw_spin_lock(_ctx->lock);
  2323  }
  2324  
  2325  if (is_cgroup_event(event)) {
  2326  /*
  2327   * Only care about cgroup events.
  2328   *
  2329   * If only the task belongs to cgroup of this event,
  2330   * we will continue the installment
  2331   */
> 2332  cgrp = perf_cgroup_from_task(current, ctx);
> 2333  reprogram = cgroup_is_descendant(cgrp->css.cgroup,
> 2334  event->cgrp->css.cgroup);
  2335  }
  2336  
  2337  if (reprogram) {
  2338  ctx_sched_out(ctx, cpuctx, EVENT_TIME);
  2339  add_event_to_ctx(event, ctx);
  2340  ctx_resched(cpuctx, task_ctx, get_event_type(event));
  2341  } else {
  2342  add_event_to_ctx(event, ctx);
  2343  }
  2344  
  2345  unlock:
  2346  perf_ctx_unlock(cpuctx, task_ctx);
  2347  
  2348  return ret;
  2349  }
  2350  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH RESEND v3] perf/core: Fix installing cgroup event into cpu

[kbuild test robot]

Hi leilei.lin,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on tip/perf/core]
[also build test ERROR on v4.15 next-20180202]
[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/linxiulei-gmail-com/perf-core-Fix-installing-cgroup-event-into-cpu/20180203-133110
config: i386-randconfig-x071-201804 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   kernel/events/core.c: In function '__perf_install_in_context':
>> kernel/events/core.c:2332:10: error: implicit declaration of function 
>> 'perf_cgroup_from_task'; did you mean 'perf_cgroup_match'? 
>> [-Werror=implicit-function-declaration]
  cgrp = perf_cgroup_from_task(current, ctx);
 ^
 perf_cgroup_match
   kernel/events/core.c:2332:8: warning: assignment makes pointer from integer 
without a cast [-Wint-conversion]
  cgrp = perf_cgroup_from_task(current, ctx);
   ^
>> kernel/events/core.c:2333:40: error: dereferencing pointer to incomplete 
>> type 'struct perf_cgroup'
  reprogram = cgroup_is_descendant(cgrp->css.cgroup,
   ^~
>> kernel/events/core.c:2334:11: error: 'struct perf_event' has no member named 
>> 'cgrp'
 event->cgrp->css.cgroup);
  ^~
   cc1: some warnings being treated as errors

vim +2332 kernel/events/core.c

  2284  
  2285  /*
  2286   * Cross CPU call to install and enable a performance event
  2287   *
  2288   * Very similar to remote_function() + event_function() but cannot 
assume that
  2289   * things like ctx->is_active and cpuctx->task_ctx are set.
  2290   */
  2291  static int  __perf_install_in_context(void *info)
  2292  {
  2293  struct perf_event *event = info;
  2294  struct perf_event_context *ctx = event->ctx;
  2295  struct perf_cpu_context *cpuctx = __get_cpu_context(ctx);
  2296  struct perf_event_context *task_ctx = cpuctx->task_ctx;
  2297  struct perf_cgroup *cgrp;
  2298  bool reprogram = true;
  2299  int ret = 0;
  2300  
  2301  raw_spin_lock(>ctx.lock);
  2302  if (ctx->task) {
  2303  raw_spin_lock(>lock);
  2304  task_ctx = ctx;
  2305  
  2306  reprogram = (ctx->task == current);
  2307  
  2308  /*
  2309   * If the task is running, it must be running on this 
CPU,
  2310   * otherwise we cannot reprogram things.
  2311   *
  2312   * If its not running, we don't care, ctx->lock will
  2313   * serialize against it becoming runnable.
  2314   */
  2315  if (task_curr(ctx->task) && !reprogram) {
  2316  ret = -ESRCH;
  2317  goto unlock;
  2318  }
  2319  
  2320  WARN_ON_ONCE(reprogram && cpuctx->task_ctx && 
cpuctx->task_ctx != ctx);
  2321  } else if (task_ctx) {
  2322  raw_spin_lock(_ctx->lock);
  2323  }
  2324  
  2325  if (is_cgroup_event(event)) {
  2326  /*
  2327   * Only care about cgroup events.
  2328   *
  2329   * If only the task belongs to cgroup of this event,
  2330   * we will continue the installment
  2331   */
> 2332  cgrp = perf_cgroup_from_task(current, ctx);
> 2333  reprogram = cgroup_is_descendant(cgrp->css.cgroup,
> 2334  event->cgrp->css.cgroup);
  2335  }
  2336  
  2337  if (reprogram) {
  2338  ctx_sched_out(ctx, cpuctx, EVENT_TIME);
  2339  add_event_to_ctx(event, ctx);
  2340  ctx_resched(cpuctx, task_ctx, get_event_type(event));
  2341  } else {
  2342  add_event_to_ctx(event, ctx);
  2343  }
  2344  
  2345  unlock:
  2346  perf_ctx_unlock(cpuctx, task_ctx);
  2347  
  2348  return ret;
  2349  }
  2350  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH] audit: update bugtracker and source URIs

[Richard Guy Briggs]

Since the Linux Audit project has transitioned completely over to
github, update the MAINTAINERS file and the primary audit source file to
reflect that reality.

Signed-off-by: Richard Guy Briggs 
---
 MAINTAINERS| 1 -
 kernel/audit.c | 3 ++-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 845fc25..fba4875 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2479,7 +2479,6 @@ M:Paul Moore 
 M: Eric Paris 
 L: linux-au...@redhat.com (moderated for non-subscribers)
 W: https://github.com/linux-audit
-W: https://people.redhat.com/sgrubb/audit
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git
 S: Supported
 F: include/linux/audit.h
diff --git a/kernel/audit.c b/kernel/audit.c
index 227db99..5c25449 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -38,7 +38,8 @@
  *   6) Support low-overhead kernel-based filtering to minimize the
  *  information that must be passed to user-space.
  *
- * Example user-space utilities: http://people.redhat.com/sgrubb/audit/
+ * Audit userspace, documentation, tests, and bug/issue trackers:
+ * https://github.com/linux-audit
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-- 
1.8.3.1

[PATCH] audit: update bugtracker and source URIs

[Richard Guy Briggs]

Since the Linux Audit project has transitioned completely over to
github, update the MAINTAINERS file and the primary audit source file to
reflect that reality.

Signed-off-by: Richard Guy Briggs 
---
 MAINTAINERS| 1 -
 kernel/audit.c | 3 ++-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 845fc25..fba4875 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2479,7 +2479,6 @@ M:Paul Moore 
 M: Eric Paris 
 L: linux-au...@redhat.com (moderated for non-subscribers)
 W: https://github.com/linux-audit
-W: https://people.redhat.com/sgrubb/audit
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git
 S: Supported
 F: include/linux/audit.h
diff --git a/kernel/audit.c b/kernel/audit.c
index 227db99..5c25449 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -38,7 +38,8 @@
  *   6) Support low-overhead kernel-based filtering to minimize the
  *  information that must be passed to user-space.
  *
- * Example user-space utilities: http://people.redhat.com/sgrubb/audit/
+ * Audit userspace, documentation, tests, and bug/issue trackers:
+ * https://github.com/linux-audit
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-- 
1.8.3.1

[BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

[tedheadster]

I just tested the 4.15 kernel and it is reporting that my old i486
(non-cpuid capable) cpu is vulnerable to all three issues: Meltdown,
Spectre V1, and Spectre V2.

I find this to be _unlikely_.

/sys/devices/system/cpu/vulnerabilities/* reports the following:

meltdown: "Vulnerable"
spectre_v1: "Vulnerable"
spectre_v2: "Vulnerable: Minimal generic ASM retpoline"

The output of dmesg includes:

"Spectre V2 mitigation: Vulnerable: Minimal generic ASM retpoline"
"Spectre V2 mitigation: Filling RSB on context switch"

Also, /proc/cpuinfo reports the following:

cpuid level: -1
flags: fpu retpoline rsb_ctxsw
bugs: cpu_meltdown spectre_v1 spectre_v2

I have the hardware to test on. Send me your patches.

- Matthew Whitehead

[BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

[tedheadster]

I just tested the 4.15 kernel and it is reporting that my old i486
(non-cpuid capable) cpu is vulnerable to all three issues: Meltdown,
Spectre V1, and Spectre V2.

I find this to be _unlikely_.

/sys/devices/system/cpu/vulnerabilities/* reports the following:

meltdown: "Vulnerable"
spectre_v1: "Vulnerable"
spectre_v2: "Vulnerable: Minimal generic ASM retpoline"

The output of dmesg includes:

"Spectre V2 mitigation: Vulnerable: Minimal generic ASM retpoline"
"Spectre V2 mitigation: Filling RSB on context switch"

Also, /proc/cpuinfo reports the following:

cpuid level: -1
flags: fpu retpoline rsb_ctxsw
bugs: cpu_meltdown spectre_v1 spectre_v2

I have the hardware to test on. Send me your patches.

- Matthew Whitehead

Re: [PATCH] net: mlx5: remove pointless memcpy

[Saeed Mahameed]

On 02/02/2018 12:26 PM, Arnd Bergmann wrote:
> On Fri, Feb 2, 2018 at 8:06 PM, Jason Gunthorpe  wrote:
>> On Fri, Feb 02, 2018 at 04:46:30PM +0100, Arnd Bergmann wrote:
>>> gcc-8 notices that the memcpy in mlx5_core_query_xsrq() makes no
>>> sense because the source and destination variables are identical:
>>>
>>> drivers/net/ethernet/mellanox/mlx5/core/transobj.c: In function 
>>> 'mlx5_core_query_xsrq':
>>> drivers/net/ethernet/mellanox/mlx5/core/transobj.c:347:3: error: 'memcpy' 
>>> source argument is the same as destination [-Werror=restrict]
>>>
>>> Either one of the pointers should be something else, or the code is
>>> completely bogus. Removing the memcpy() won't change the behavior
>>> but gets rid of the warning.
>>>
>>> Fixes: 01949d0109ee ("net/mlx5_core: Enable XRCs and SRQs when using ISSI > 
>>> 0")
>>> Signed-off-by: Arnd Bergmann 
>>> Please review carefully, I have no idea what the author actually
>>> intended here.
>>
>> I think they intended to adjust the command return between
>> mlx5_ifc_query_srq_out_bits and mlx5_ifc_query_xrc_srq_out_bits?
>>
>>> index 9e38343a951f..75450f7d53bf 100644
>>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/transobj.c
>>> @@ -332,20 +332,12 @@ int mlx5_core_destroy_xsrq(struct mlx5_core_dev *dev, 
>>> u32 xsrqn)
>>>  int mlx5_core_query_xsrq(struct mlx5_core_dev *dev, u32 xsrqn, u32 *out)
>>>  {
>>>   u32 in[MLX5_ST_SZ_DW(query_xrc_srq_in)] = {0};
>>> - void *srqc;
>>> - void *xrc_srqc;
>>>   int err;
>>>
>>>   MLX5_SET(query_xrc_srq_in, in, opcode,   MLX5_CMD_OP_QUERY_XRC_SRQ);
>>>   MLX5_SET(query_xrc_srq_in, in, xrc_srqn, xsrqn);
>>>   err = mlx5_cmd_exec(dev, in, sizeof(in), out,
>>>   MLX5_ST_SZ_BYTES(query_xrc_srq_out));
>>> - if (!err) {
>>> - xrc_srqc = MLX5_ADDR_OF(query_xrc_srq_out, out,
>>> - xrc_srq_context_entry);
>>> - srqc = MLX5_ADDR_OF(query_srq_out, out, srq_context_entry);
>>> - memcpy(srqc, xrc_srqc, MLX5_ST_SZ_BYTES(srqc));
>>> - }

OMG!

>>
>> Probably should add a
>>
>> BUILD_BUG_ON(MLX5_BYTE_OFF(query_xrc_srq_out, xrc_srq_context_entry) == 
>> MLX5_BYTE_OFF(query_srq_out, srq_context_entry));
>>
>> Just for clarity that the SRQ and XRC_SRQ are being used interchangeably.
>>
>> and the 'err' variable can be eliminated.
>>
>> Curious though that I can't find a call site for it, and removing the
>> prototype doesn't break the build.. Seems like dead code.
> 
> I checked the git history and don't see any user ever added after the function
> first showed up in the kernel, same for a couple of other functions from
> commit 01949d0109ee ("net/mlx5_core: Enable XRCs and SRQs when
> using ISSI > 0").
> 
> Can you come up with a proper patch for this isse, either removing the
> dead code, or fixing it appropriately? You clearly understand what this
> file is about, and I don't ;-)

Simply this is just pointless dead code, will remove it, there is no point of 
trying to
figure out what the author was thinking the day he wrote that patch :)

Thank you Arnd for spotting this.

> 
>   Arnd
> 

Re: [PATCH] net: mlx5: remove pointless memcpy

[Saeed Mahameed]

On 02/02/2018 12:26 PM, Arnd Bergmann wrote:
> On Fri, Feb 2, 2018 at 8:06 PM, Jason Gunthorpe  wrote:
>> On Fri, Feb 02, 2018 at 04:46:30PM +0100, Arnd Bergmann wrote:
>>> gcc-8 notices that the memcpy in mlx5_core_query_xsrq() makes no
>>> sense because the source and destination variables are identical:
>>>
>>> drivers/net/ethernet/mellanox/mlx5/core/transobj.c: In function 
>>> 'mlx5_core_query_xsrq':
>>> drivers/net/ethernet/mellanox/mlx5/core/transobj.c:347:3: error: 'memcpy' 
>>> source argument is the same as destination [-Werror=restrict]
>>>
>>> Either one of the pointers should be something else, or the code is
>>> completely bogus. Removing the memcpy() won't change the behavior
>>> but gets rid of the warning.
>>>
>>> Fixes: 01949d0109ee ("net/mlx5_core: Enable XRCs and SRQs when using ISSI > 
>>> 0")
>>> Signed-off-by: Arnd Bergmann 
>>> Please review carefully, I have no idea what the author actually
>>> intended here.
>>
>> I think they intended to adjust the command return between
>> mlx5_ifc_query_srq_out_bits and mlx5_ifc_query_xrc_srq_out_bits?
>>
>>> index 9e38343a951f..75450f7d53bf 100644
>>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/transobj.c
>>> @@ -332,20 +332,12 @@ int mlx5_core_destroy_xsrq(struct mlx5_core_dev *dev, 
>>> u32 xsrqn)
>>>  int mlx5_core_query_xsrq(struct mlx5_core_dev *dev, u32 xsrqn, u32 *out)
>>>  {
>>>   u32 in[MLX5_ST_SZ_DW(query_xrc_srq_in)] = {0};
>>> - void *srqc;
>>> - void *xrc_srqc;
>>>   int err;
>>>
>>>   MLX5_SET(query_xrc_srq_in, in, opcode,   MLX5_CMD_OP_QUERY_XRC_SRQ);
>>>   MLX5_SET(query_xrc_srq_in, in, xrc_srqn, xsrqn);
>>>   err = mlx5_cmd_exec(dev, in, sizeof(in), out,
>>>   MLX5_ST_SZ_BYTES(query_xrc_srq_out));
>>> - if (!err) {
>>> - xrc_srqc = MLX5_ADDR_OF(query_xrc_srq_out, out,
>>> - xrc_srq_context_entry);
>>> - srqc = MLX5_ADDR_OF(query_srq_out, out, srq_context_entry);
>>> - memcpy(srqc, xrc_srqc, MLX5_ST_SZ_BYTES(srqc));
>>> - }

OMG!

>>
>> Probably should add a
>>
>> BUILD_BUG_ON(MLX5_BYTE_OFF(query_xrc_srq_out, xrc_srq_context_entry) == 
>> MLX5_BYTE_OFF(query_srq_out, srq_context_entry));
>>
>> Just for clarity that the SRQ and XRC_SRQ are being used interchangeably.
>>
>> and the 'err' variable can be eliminated.
>>
>> Curious though that I can't find a call site for it, and removing the
>> prototype doesn't break the build.. Seems like dead code.
> 
> I checked the git history and don't see any user ever added after the function
> first showed up in the kernel, same for a couple of other functions from
> commit 01949d0109ee ("net/mlx5_core: Enable XRCs and SRQs when
> using ISSI > 0").
> 
> Can you come up with a proper patch for this isse, either removing the
> dead code, or fixing it appropriately? You clearly understand what this
> file is about, and I don't ;-)

Simply this is just pointless dead code, will remove it, there is no point of 
trying to
figure out what the author was thinking the day he wrote that patch :)

Thank you Arnd for spotting this.

> 
>   Arnd
> 

Re: [PATCH 4.15 00/55] 4.15.1-stable review

[Dan Rue]

On Fri, Feb 02, 2018 at 05:58:18PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.15.1 release.
> There are 55 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Feb  4 14:07:50 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.1-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.15.y
> and the diffstat can be found below.

Results from Linaro’s test farm.

No regressions since 4.15 release, but you'll notice high failure counts
in kselftest. These are because it was the first RC and I ran the tests
multiple times - first without a skipfile, and then again with a partial
skipfile. All of the failures look like known issues that we also saw on
4.15 release.

Summary


kernel: 4.15.1-rc1
git repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.15.y
git commit: b01b3d9519f250398695c7cc6493ba1e8fb072f4
git describe: v4.15-56-gb01b3d9519f2
Test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.15-oe/build/v4.15-56-gb01b3d9519f2


No regressions (compared to build )

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 38,
* kselftest - pass: 98, skip: 14, fail: 12
* libhugetlbfs - pass: 180, skip: 2,
* ltp-cap_bounds-tests - pass: 4,
* ltp-containers-tests - pass: 128,
* ltp-fcntl-locktests-tests - pass: 4,
* ltp-filecaps-tests - pass: 4,
* ltp-fs-tests - pass: 120,
* ltp-fs_bind-tests - pass: 4,
* ltp-fs_perms_simple-tests - pass: 38,
* ltp-fsx-tests - pass: 4,
* ltp-hugetlb-tests - pass: 21, skip: 1,
* ltp-io-tests - pass: 6,
* ltp-ipc-tests - pass: 18,
* ltp-math-tests - pass: 22,
* ltp-nptl-tests - pass: 4,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 20,
* ltp-securebits-tests - pass: 8,
* ltp-syscalls-tests - pass: 1968, skip: 242,
* ltp-timers-tests - pass: 24,

juno-r2 - arm64
* boot - pass: 31,
* kselftest - pass: 111, skip: 28, fail: 12
* libhugetlbfs - pass: 90, skip: 1,
* ltp-cap_bounds-tests - pass: 4,
* ltp-containers-tests - pass: 128,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 4,
* ltp-fs-tests - pass: 120,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 38,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 44,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 18,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 4,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 987, skip: 121,
* ltp-timers-tests - pass: 24,

x15 - arm
* boot - pass: 41,
* kselftest - pass: 92, skip: 32, fail: 15
* libhugetlbfs - pass: 174, skip: 2,
* ltp-cap_bounds-tests - pass: 4,
* ltp-containers-tests - pass: 124, fail: 4
* ltp-fcntl-locktests-tests - pass: 4,
* ltp-filecaps-tests - pass: 4,
* ltp-fs-tests - pass: 120,
* ltp-fs_bind-tests - pass: 4,
* ltp-fs_perms_simple-tests - pass: 38,
* ltp-fsx-tests - pass: 4,
* ltp-hugetlb-tests - pass: 40, skip: 4,
* ltp-io-tests - pass: 6,
* ltp-ipc-tests - pass: 18,
* ltp-math-tests - pass: 22,
* ltp-nptl-tests - pass: 4,
* ltp-pty-tests - pass: 8,
* ltp-sched-tests - pass: 26, skip: 2,
* ltp-securebits-tests - pass: 8,
* ltp-syscalls-tests - pass: 2076, skip: 132,
* ltp-timers-tests - pass: 24,

x86_64
* boot - pass: 40,
* kselftest - pass: 121, skip: 16, fail: 14
* libhugetlbfs - pass: 180, skip: 2,
* ltp-cap_bounds-tests - pass: 4,
* ltp-containers-tests - pass: 128,
* ltp-fcntl-locktests-tests - pass: 4,
* ltp-filecaps-tests - pass: 4,
* ltp-fs-tests - pass: 122, skip: 2,
* ltp-fs_bind-tests - pass: 4,
* ltp-fs_perms_simple-tests - pass: 38,
* ltp-fsx-tests - pass: 4,
* ltp-hugetlb-tests - pass: 44,
* ltp-io-tests - pass: 6,
* ltp-ipc-tests - pass: 18,
* ltp-math-tests - pass: 22,
* ltp-nptl-tests - pass: 4,
* ltp-pty-tests - pass: 8,
* ltp-sched-tests - pass: 18, skip: 2,
* ltp-securebits-tests - pass: 8,
* ltp-syscalls-tests - pass: 2032, skip: 232,
* ltp-timers-tests - pass: 24,


--
Linaro QA (beta)
https://qa-reports.linaro.org

Re: [PATCH 4.15 00/55] 4.15.1-stable review

[Dan Rue]

On Fri, Feb 02, 2018 at 05:58:18PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.15.1 release.
> There are 55 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Feb  4 14:07:50 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.1-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.15.y
> and the diffstat can be found below.

Results from Linaro’s test farm.

No regressions since 4.15 release, but you'll notice high failure counts
in kselftest. These are because it was the first RC and I ran the tests
multiple times - first without a skipfile, and then again with a partial
skipfile. All of the failures look like known issues that we also saw on
4.15 release.

Summary


kernel: 4.15.1-rc1
git repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.15.y
git commit: b01b3d9519f250398695c7cc6493ba1e8fb072f4
git describe: v4.15-56-gb01b3d9519f2
Test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.15-oe/build/v4.15-56-gb01b3d9519f2


No regressions (compared to build )

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 38,
* kselftest - pass: 98, skip: 14, fail: 12
* libhugetlbfs - pass: 180, skip: 2,
* ltp-cap_bounds-tests - pass: 4,
* ltp-containers-tests - pass: 128,
* ltp-fcntl-locktests-tests - pass: 4,
* ltp-filecaps-tests - pass: 4,
* ltp-fs-tests - pass: 120,
* ltp-fs_bind-tests - pass: 4,
* ltp-fs_perms_simple-tests - pass: 38,
* ltp-fsx-tests - pass: 4,
* ltp-hugetlb-tests - pass: 21, skip: 1,
* ltp-io-tests - pass: 6,
* ltp-ipc-tests - pass: 18,
* ltp-math-tests - pass: 22,
* ltp-nptl-tests - pass: 4,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 20,
* ltp-securebits-tests - pass: 8,
* ltp-syscalls-tests - pass: 1968, skip: 242,
* ltp-timers-tests - pass: 24,

juno-r2 - arm64
* boot - pass: 31,
* kselftest - pass: 111, skip: 28, fail: 12
* libhugetlbfs - pass: 90, skip: 1,
* ltp-cap_bounds-tests - pass: 4,
* ltp-containers-tests - pass: 128,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 4,
* ltp-fs-tests - pass: 120,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 38,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 44,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 18,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 4,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 987, skip: 121,
* ltp-timers-tests - pass: 24,

x15 - arm
* boot - pass: 41,
* kselftest - pass: 92, skip: 32, fail: 15
* libhugetlbfs - pass: 174, skip: 2,
* ltp-cap_bounds-tests - pass: 4,
* ltp-containers-tests - pass: 124, fail: 4
* ltp-fcntl-locktests-tests - pass: 4,
* ltp-filecaps-tests - pass: 4,
* ltp-fs-tests - pass: 120,
* ltp-fs_bind-tests - pass: 4,
* ltp-fs_perms_simple-tests - pass: 38,
* ltp-fsx-tests - pass: 4,
* ltp-hugetlb-tests - pass: 40, skip: 4,
* ltp-io-tests - pass: 6,
* ltp-ipc-tests - pass: 18,
* ltp-math-tests - pass: 22,
* ltp-nptl-tests - pass: 4,
* ltp-pty-tests - pass: 8,
* ltp-sched-tests - pass: 26, skip: 2,
* ltp-securebits-tests - pass: 8,
* ltp-syscalls-tests - pass: 2076, skip: 132,
* ltp-timers-tests - pass: 24,

x86_64
* boot - pass: 40,
* kselftest - pass: 121, skip: 16, fail: 14
* libhugetlbfs - pass: 180, skip: 2,
* ltp-cap_bounds-tests - pass: 4,
* ltp-containers-tests - pass: 128,
* ltp-fcntl-locktests-tests - pass: 4,
* ltp-filecaps-tests - pass: 4,
* ltp-fs-tests - pass: 122, skip: 2,
* ltp-fs_bind-tests - pass: 4,
* ltp-fs_perms_simple-tests - pass: 38,
* ltp-fsx-tests - pass: 4,
* ltp-hugetlb-tests - pass: 44,
* ltp-io-tests - pass: 6,
* ltp-ipc-tests - pass: 18,
* ltp-math-tests - pass: 22,
* ltp-nptl-tests - pass: 4,
* ltp-pty-tests - pass: 8,
* ltp-sched-tests - pass: 18, skip: 2,
* ltp-securebits-tests - pass: 8,
* ltp-syscalls-tests - pass: 2032, skip: 232,
* ltp-timers-tests - pass: 24,


--
Linaro QA (beta)
https://qa-reports.linaro.org

Re: [PATCH 2/2] HID: i2c-hid: Fix resume issue on Raydium touchscreen device

[Aaron Ma]

Hi

Could anyone review an apply this single patch?

The 2nd patch had been sent as v2.

Regards,
Aaron

Re: [PATCH 2/2] HID: i2c-hid: Fix resume issue on Raydium touchscreen device

[Aaron Ma]

Hi

Could anyone review an apply this single patch?

The 2nd patch had been sent as v2.

Regards,
Aaron

Re: [PATCH v2 2/2] HID: core: Fix size as type u32

[Aaron Ma]

Hi:

Could anyone review and apply these 2 patch?

Regards,
Aaron

Re: [PATCH v2 2/2] HID: core: Fix size as type u32

[Aaron Ma]

Hi:

Could anyone review and apply these 2 patch?

Regards,
Aaron

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

[Frank Rowand]

On 02/01/18 21:53, Chintan Pandya wrote:
> 
> 
> On 2/2/2018 2:39 AM, Frank Rowand wrote:
>> On 02/01/18 06:24, Rob Herring wrote:
>>> And so
>>> far, no one has explained why a bigger cache got slower.
>>
>> Yes, I still find that surprising.
> 
> I thought a bit about this. And realized that increasing the cache size 
> should help improve the performance only if there are too many misses with 
> the smaller cache. So, from my experiments some time back, I looked up the 
> logs and saw the access pattern. Seems like, there is *not_too_much* juggling 
> during look up by phandles.
> 
> See the access pattern here: 
> https://drive.google.com/file/d/1qfAD8OsswNJABgAwjJf6Gr_JZMeK7rLV/view?usp=sharing

Thanks!  Very interesting.

I was somewhat limited at playing detective with this, because the phandle
values are not consistent with the dts file you are currently working
with (arch/arm64/boot/dts/qcom/sda670-mtp.dts).  For example, I could
not determine what the target nodes for the hot phandle values.  That
information _could_ possibly point at algorithms within the devicetree
core code that could be improved.  Or maybe not.  Hard to tell until
actually looking at the data.

Anyway, some observations were possible.

There are 485 unique phandle values searched for.

The ten phandle values most frequently referenced account for
3932 / 6745 (or 58%) of all references.

Without the corresponding devicetree I can not tell how many nodes
need to be scanned to locate each of these ten values (using the
existing algorithm).  Thus I can not determine how much scanning
would be eliminated by caching just the nodes corresponding to
these ten phandle values.

There are 89 phandle values that were searched for 10 times
or more, accounting for 86% of the searches.

Only 164 phandle values were searched for just one time.

303 phandle values were searched for just one or two times.

Here is a more complete picture:

  10 values each used 100 or more times; searches:  3932   58%
  11 values each used  90 or more times; searches:  3994   59%
  12 values each used  80 or more times; searches:  4045   60%
  13 values each used  70 or more times; searches:  4093   61%
  14 values each used  60 or more times; searches:  4136   61%
  15 values each used  50 or more times; searches:  4178   62%
  18 values each used  40 or more times; searches:  4300   64%
  32 values each used  30 or more times; searches:  4774   71%
  54 values each used  20 or more times; searches:  5293   78%
  89 values each used  10 or more times; searches:  5791   86%
  93 values each used   9 or more times; searches:  5827   86%
 117 values each used   8 or more times; searches:  6019   89%
 122 values each used   7 or more times; searches:  6054   90%
 132 values each used   6 or more times; searches:  6114   91%
 144 values each used   5 or more times; searches:  6174   92%
 162 values each used   4 or more times; searches:  6246   93%
 181 values each used   3 or more times; searches:  6303   93%
 320 values each used   2 or more times; searches:  6581   98%
 484 values each used   1 or more times; searches:  6746  100%

A single system does not prove anything.  It is possible that
other devicetrees would exhibit similarly long tailed behavior,
but that is just wild speculation on my part.

_If_ the long tail is representative of other systems, then
identifying a few hot spots could be useful, but fixing them
is not likely to significantly reduce the overhead of calls
to of_find_node_by_phandle().  Some method of reducing the
overhead of each call would be the answer for a system of
this class.


> Sample log is pasted below where number in the last is phandle value.
> Line 8853: [   37.425405] OF: want to search this 262
> Line 8854: [   37.425453] OF: want to search this 262
> Line 8855: [   37.425499] OF: want to search this 262
> Line 8856: [   37.425549] OF: want to search this 15
> Line 8857: [   37.425599] OF: want to search this 5
> Line 8858: [   37.429989] OF: want to search this 253
> Line 8859: [   37.430058] OF: want to search this 253
> Line 8860: [   37.430217] OF: want to search this 253
> Line 8861: [   37.430278] OF: want to search this 253
> Line 8862: [   37.430337] OF: want to search this 253
> Line 8863: [   37.430399] OF: want to search this 254
> Line 8864: [   37.430597] OF: want to search this 254
> Line 8865: [   37.430656] OF: want to search this 254
> 
> 
> Above explains why results with cache size 64 and 128 have almost similar 
> results. Now, for cache size 256 we have degrading performance. I don't have 
> a good theory here but I'm assuming that by making large SW cache, we miss 
> the benefits of real HW cache which is typically smaller than our array size. 
> Also, in my set up, I've set max_cpu=1 to reduce the variance. That again, 
> should affect the cache holding pattern in HW and affect the perf numbers.
> 
> 
> Chintan

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

[Frank Rowand]

On 02/01/18 21:53, Chintan Pandya wrote:
> 
> 
> On 2/2/2018 2:39 AM, Frank Rowand wrote:
>> On 02/01/18 06:24, Rob Herring wrote:
>>> And so
>>> far, no one has explained why a bigger cache got slower.
>>
>> Yes, I still find that surprising.
> 
> I thought a bit about this. And realized that increasing the cache size 
> should help improve the performance only if there are too many misses with 
> the smaller cache. So, from my experiments some time back, I looked up the 
> logs and saw the access pattern. Seems like, there is *not_too_much* juggling 
> during look up by phandles.
> 
> See the access pattern here: 
> https://drive.google.com/file/d/1qfAD8OsswNJABgAwjJf6Gr_JZMeK7rLV/view?usp=sharing

Thanks!  Very interesting.

I was somewhat limited at playing detective with this, because the phandle
values are not consistent with the dts file you are currently working
with (arch/arm64/boot/dts/qcom/sda670-mtp.dts).  For example, I could
not determine what the target nodes for the hot phandle values.  That
information _could_ possibly point at algorithms within the devicetree
core code that could be improved.  Or maybe not.  Hard to tell until
actually looking at the data.

Anyway, some observations were possible.

There are 485 unique phandle values searched for.

The ten phandle values most frequently referenced account for
3932 / 6745 (or 58%) of all references.

Without the corresponding devicetree I can not tell how many nodes
need to be scanned to locate each of these ten values (using the
existing algorithm).  Thus I can not determine how much scanning
would be eliminated by caching just the nodes corresponding to
these ten phandle values.

There are 89 phandle values that were searched for 10 times
or more, accounting for 86% of the searches.

Only 164 phandle values were searched for just one time.

303 phandle values were searched for just one or two times.

Here is a more complete picture:

  10 values each used 100 or more times; searches:  3932   58%
  11 values each used  90 or more times; searches:  3994   59%
  12 values each used  80 or more times; searches:  4045   60%
  13 values each used  70 or more times; searches:  4093   61%
  14 values each used  60 or more times; searches:  4136   61%
  15 values each used  50 or more times; searches:  4178   62%
  18 values each used  40 or more times; searches:  4300   64%
  32 values each used  30 or more times; searches:  4774   71%
  54 values each used  20 or more times; searches:  5293   78%
  89 values each used  10 or more times; searches:  5791   86%
  93 values each used   9 or more times; searches:  5827   86%
 117 values each used   8 or more times; searches:  6019   89%
 122 values each used   7 or more times; searches:  6054   90%
 132 values each used   6 or more times; searches:  6114   91%
 144 values each used   5 or more times; searches:  6174   92%
 162 values each used   4 or more times; searches:  6246   93%
 181 values each used   3 or more times; searches:  6303   93%
 320 values each used   2 or more times; searches:  6581   98%
 484 values each used   1 or more times; searches:  6746  100%

A single system does not prove anything.  It is possible that
other devicetrees would exhibit similarly long tailed behavior,
but that is just wild speculation on my part.

_If_ the long tail is representative of other systems, then
identifying a few hot spots could be useful, but fixing them
is not likely to significantly reduce the overhead of calls
to of_find_node_by_phandle().  Some method of reducing the
overhead of each call would be the answer for a system of
this class.


> Sample log is pasted below where number in the last is phandle value.
> Line 8853: [   37.425405] OF: want to search this 262
> Line 8854: [   37.425453] OF: want to search this 262
> Line 8855: [   37.425499] OF: want to search this 262
> Line 8856: [   37.425549] OF: want to search this 15
> Line 8857: [   37.425599] OF: want to search this 5
> Line 8858: [   37.429989] OF: want to search this 253
> Line 8859: [   37.430058] OF: want to search this 253
> Line 8860: [   37.430217] OF: want to search this 253
> Line 8861: [   37.430278] OF: want to search this 253
> Line 8862: [   37.430337] OF: want to search this 253
> Line 8863: [   37.430399] OF: want to search this 254
> Line 8864: [   37.430597] OF: want to search this 254
> Line 8865: [   37.430656] OF: want to search this 254
> 
> 
> Above explains why results with cache size 64 and 128 have almost similar 
> results. Now, for cache size 256 we have degrading performance. I don't have 
> a good theory here but I'm assuming that by making large SW cache, we miss 
> the benefits of real HW cache which is typically smaller than our array size. 
> Also, in my set up, I've set max_cpu=1 to reduce the variance. That again, 
> should affect the cache holding pattern in HW and affect the perf numbers.
> 
> 
> Chintan

Re: [RESEND RFC PATCH V3] sched: Improve scalability of select_idle_sibling using SMT balance

[Mike Galbraith]

On Fri, 2018-02-02 at 13:34 -0500, Steven Sistare wrote:
> On 2/2/2018 12:39 PM, Steven Sistare wrote:
> > On 2/2/2018 12:21 PM, Peter Zijlstra wrote:
> >> On Fri, Feb 02, 2018 at 11:53:40AM -0500, Steven Sistare wrote:
> >>> It might be interesting to add a tunable for the number of random choices 
> >>> to
> >>> make, and clamp it at the max nr computed from avg_cost in 
> >>> select_idle_cpu.
> >>
> >> This needs a fairly complicated PRNG for it would need to visit each
> >> possible CPU once before looping. A LFSR does that, but requires 2^n-1
> >> elements and we have topology masks that don't match that.. The trivial
> >> example is something with 6 cores.
> > 
> > Or keep it simple and accept the possibility of choosing the same candidate
> > more than once.
> > 
> >>> Or, choose a random starting point and then search for nr sequential 
> >>> candidates; possibly limited by a tunable.
> >>
> >> And this is basically what we already do. Except with the task-cpu
> >> instead of a per-cpu rotor.
> > 
> > Righto.  Disregard this suggestion.
> 
> Actually, I take back my take back.  I suspect the primary benefit
> of random selection is that it breaks up resonance states where
> CPUs that are busy tend to stay busy, and CPUs that are idle tend
> to stay idle, which is reinforced by starting the search at target =
> last cpu ran.

I suspect the primary benefit is reduction of bouncing.  The absolutely
maddening thing about SIS is that some stuff out there (like FB's load)
doesn't give a rats ass about anything other than absolute minimum
sched latency while other stuff notices cache going missing.  Joy.

-Mike

Re: [RESEND RFC PATCH V3] sched: Improve scalability of select_idle_sibling using SMT balance

[Mike Galbraith]

On Fri, 2018-02-02 at 13:34 -0500, Steven Sistare wrote:
> On 2/2/2018 12:39 PM, Steven Sistare wrote:
> > On 2/2/2018 12:21 PM, Peter Zijlstra wrote:
> >> On Fri, Feb 02, 2018 at 11:53:40AM -0500, Steven Sistare wrote:
> >>> It might be interesting to add a tunable for the number of random choices 
> >>> to
> >>> make, and clamp it at the max nr computed from avg_cost in 
> >>> select_idle_cpu.
> >>
> >> This needs a fairly complicated PRNG for it would need to visit each
> >> possible CPU once before looping. A LFSR does that, but requires 2^n-1
> >> elements and we have topology masks that don't match that.. The trivial
> >> example is something with 6 cores.
> > 
> > Or keep it simple and accept the possibility of choosing the same candidate
> > more than once.
> > 
> >>> Or, choose a random starting point and then search for nr sequential 
> >>> candidates; possibly limited by a tunable.
> >>
> >> And this is basically what we already do. Except with the task-cpu
> >> instead of a per-cpu rotor.
> > 
> > Righto.  Disregard this suggestion.
> 
> Actually, I take back my take back.  I suspect the primary benefit
> of random selection is that it breaks up resonance states where
> CPUs that are busy tend to stay busy, and CPUs that are idle tend
> to stay idle, which is reinforced by starting the search at target =
> last cpu ran.

I suspect the primary benefit is reduction of bouncing.  The absolutely
maddening thing about SIS is that some stuff out there (like FB's load)
doesn't give a rats ass about anything other than absolute minimum
sched latency while other stuff notices cache going missing.  Joy.

-Mike

Re: [PATCH v2 5/6] arm64: Detect current view of GIC priorities

[Yang Yingliang]

Hi, Julien

On 2018/1/17 19:54, Julien Thierry wrote:

The values non secure EL1 needs to use for priority registers depends on
the value of SCR_EL3.FIQ.

Since we don't have access to SCR_EL3, we fake an interrupt and compare the
GIC priority with the one present in the [re]distributor.

Also, add firmware requirements related to SCR_EL3.

Signed-off-by: Julien Thierry 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
---
  Documentation/arm64/booting.txt |  5 +++
  arch/arm64/include/asm/arch_gicv3.h |  5 +++
  arch/arm64/include/asm/irqflags.h   |  6 +++
  arch/arm64/include/asm/sysreg.h |  1 +
  drivers/irqchip/irq-gic-v3.c| 86 +
  5 files changed, 103 insertions(+)

diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt
index 8d0df62..e387938 100644
--- a/Documentation/arm64/booting.txt
+++ b/Documentation/arm64/booting.txt
@@ -188,6 +188,11 @@ Before jumping into the kernel, the following conditions 
must be met:
the kernel image will be entered must be initialised by software at a
higher exception level to prevent execution in an UNKNOWN state.

+  - SCR_EL3.FIQ must have the same value across all CPUs the kernel is
+executing on.
+  - The value of SCR_EL3.FIQ must be the same as the one present at boot
+time whenever the kernel is executing.
+
For systems with a GICv3 interrupt controller to be used in v3 mode:
- If EL3 is present:
  ICC_SRE_EL3.Enable (bit 3) must be initialiased to 0b1.
diff --git a/arch/arm64/include/asm/arch_gicv3.h 
b/arch/arm64/include/asm/arch_gicv3.h
index 490bb3a..ac7b7f6 100644
--- a/arch/arm64/include/asm/arch_gicv3.h
+++ b/arch/arm64/include/asm/arch_gicv3.h
@@ -124,6 +124,11 @@ static inline void gic_write_bpr1(u32 val)
write_sysreg_s(val, SYS_ICC_BPR1_EL1);
  }

+static inline u32 gic_read_rpr(void)
+{
+   return read_sysreg_s(SYS_ICC_RPR_EL1);
+}
+
  #define gic_read_typer(c) readq_relaxed(c)
  #define gic_write_irouter(v, c)   writeq_relaxed(v, c)
  #define gic_read_lpir(c)  readq_relaxed(c)
diff --git a/arch/arm64/include/asm/irqflags.h 
b/arch/arm64/include/asm/irqflags.h
index 3d5d443..d25e7ee 100644
--- a/arch/arm64/include/asm/irqflags.h
+++ b/arch/arm64/include/asm/irqflags.h
@@ -217,6 +217,12 @@ static inline int arch_irqs_disabled_flags(unsigned long 
flags)
!(ARCH_FLAGS_GET_PMR(flags) & ICC_PMR_EL1_EN_BIT);
  }

+/* Mask IRQs at CPU level instead of GIC level */
+static inline void arch_irqs_daif_disable(void)
+{
+   asm volatile ("msr daifset, #2" : : : "memory");
+}
+
  void maybe_switch_to_sysreg_gic_cpuif(void);

  #endif /* CONFIG_IRQFLAGS_GIC_MASKING */
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 08cc885..46fa869 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -304,6 +304,7 @@
  #define SYS_ICC_SRE_EL1   sys_reg(3, 0, 12, 12, 5)
  #define SYS_ICC_IGRPEN0_EL1   sys_reg(3, 0, 12, 12, 6)
  #define SYS_ICC_IGRPEN1_EL1   sys_reg(3, 0, 12, 12, 7)
+#define SYS_ICC_RPR_EL1sys_reg(3, 0, 12, 11, 3)

  #define SYS_CONTEXTIDR_EL1sys_reg(3, 0, 13, 0, 1)
  #define SYS_TPIDR_EL1 sys_reg(3, 0, 13, 0, 4)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index df51d96..58b5e89 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -63,6 +63,10 @@ struct gic_chip_data {
  static struct gic_chip_data gic_data __read_mostly;
  static struct static_key supports_deactivate = STATIC_KEY_INIT_TRUE;

+#ifdef CONFIG_USE_ICC_SYSREGS_FOR_IRQFLAGS
+DEFINE_STATIC_KEY_FALSE(have_non_secure_prio_view);
+#endif
+
  static struct gic_kvm_info gic_v3_kvm_info;
  static DEFINE_PER_CPU(bool, has_rss);

@@ -997,6 +1001,84 @@ static int partition_domain_translate(struct irq_domain 
*d,
.select = gic_irq_domain_select,
  };

+#ifdef CONFIG_USE_ICC_SYSREGS_FOR_IRQFLAGS
+/*
+ * The behaviours of RPR and PMR registers differ depending on the value of
+ * SCR_EL3.FIQ, while the behaviour of priority registers of the distributor
+ * and redistributors is always the same.
+ *
+ * If SCR_EL3.FIQ == 1, the values used for RPR and PMR are the same as the 
ones
+ * programmed in the distributor and redistributors registers.
+ *
+ * Otherwise, the value presented by RPR as well as the value which will be
+ * compared against PMR is: (GIC_(R)DIST_PRI[irq] >> 1) | 0x80;
+ *
+ * see GICv3/GICv4 Architecture Specification (IHI0069D):
+ * - section 4.8.1 Non-secure accesses to register fields for Secure interrupt
+ *   priorities.
+ * - Figure 4-7 Secure read of the priority field for a Non-secure Group 1
+ *   interrupt.
+ */

I think we 

Re: [PATCH v2 5/6] arm64: Detect current view of GIC priorities

[Yang Yingliang]

Hi, Julien

On 2018/1/17 19:54, Julien Thierry wrote:

The values non secure EL1 needs to use for priority registers depends on
the value of SCR_EL3.FIQ.

Since we don't have access to SCR_EL3, we fake an interrupt and compare the
GIC priority with the one present in the [re]distributor.

Also, add firmware requirements related to SCR_EL3.

Signed-off-by: Julien Thierry 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
---
  Documentation/arm64/booting.txt |  5 +++
  arch/arm64/include/asm/arch_gicv3.h |  5 +++
  arch/arm64/include/asm/irqflags.h   |  6 +++
  arch/arm64/include/asm/sysreg.h |  1 +
  drivers/irqchip/irq-gic-v3.c| 86 +
  5 files changed, 103 insertions(+)

diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt
index 8d0df62..e387938 100644
--- a/Documentation/arm64/booting.txt
+++ b/Documentation/arm64/booting.txt
@@ -188,6 +188,11 @@ Before jumping into the kernel, the following conditions 
must be met:
the kernel image will be entered must be initialised by software at a
higher exception level to prevent execution in an UNKNOWN state.

+  - SCR_EL3.FIQ must have the same value across all CPUs the kernel is
+executing on.
+  - The value of SCR_EL3.FIQ must be the same as the one present at boot
+time whenever the kernel is executing.
+
For systems with a GICv3 interrupt controller to be used in v3 mode:
- If EL3 is present:
  ICC_SRE_EL3.Enable (bit 3) must be initialiased to 0b1.
diff --git a/arch/arm64/include/asm/arch_gicv3.h 
b/arch/arm64/include/asm/arch_gicv3.h
index 490bb3a..ac7b7f6 100644
--- a/arch/arm64/include/asm/arch_gicv3.h
+++ b/arch/arm64/include/asm/arch_gicv3.h
@@ -124,6 +124,11 @@ static inline void gic_write_bpr1(u32 val)
write_sysreg_s(val, SYS_ICC_BPR1_EL1);
  }

+static inline u32 gic_read_rpr(void)
+{
+   return read_sysreg_s(SYS_ICC_RPR_EL1);
+}
+
  #define gic_read_typer(c) readq_relaxed(c)
  #define gic_write_irouter(v, c)   writeq_relaxed(v, c)
  #define gic_read_lpir(c)  readq_relaxed(c)
diff --git a/arch/arm64/include/asm/irqflags.h 
b/arch/arm64/include/asm/irqflags.h
index 3d5d443..d25e7ee 100644
--- a/arch/arm64/include/asm/irqflags.h
+++ b/arch/arm64/include/asm/irqflags.h
@@ -217,6 +217,12 @@ static inline int arch_irqs_disabled_flags(unsigned long 
flags)
!(ARCH_FLAGS_GET_PMR(flags) & ICC_PMR_EL1_EN_BIT);
  }

+/* Mask IRQs at CPU level instead of GIC level */
+static inline void arch_irqs_daif_disable(void)
+{
+   asm volatile ("msr daifset, #2" : : : "memory");
+}
+
  void maybe_switch_to_sysreg_gic_cpuif(void);

  #endif /* CONFIG_IRQFLAGS_GIC_MASKING */
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 08cc885..46fa869 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -304,6 +304,7 @@
  #define SYS_ICC_SRE_EL1   sys_reg(3, 0, 12, 12, 5)
  #define SYS_ICC_IGRPEN0_EL1   sys_reg(3, 0, 12, 12, 6)
  #define SYS_ICC_IGRPEN1_EL1   sys_reg(3, 0, 12, 12, 7)
+#define SYS_ICC_RPR_EL1sys_reg(3, 0, 12, 11, 3)

  #define SYS_CONTEXTIDR_EL1sys_reg(3, 0, 13, 0, 1)
  #define SYS_TPIDR_EL1 sys_reg(3, 0, 13, 0, 4)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index df51d96..58b5e89 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -63,6 +63,10 @@ struct gic_chip_data {
  static struct gic_chip_data gic_data __read_mostly;
  static struct static_key supports_deactivate = STATIC_KEY_INIT_TRUE;

+#ifdef CONFIG_USE_ICC_SYSREGS_FOR_IRQFLAGS
+DEFINE_STATIC_KEY_FALSE(have_non_secure_prio_view);
+#endif
+
  static struct gic_kvm_info gic_v3_kvm_info;
  static DEFINE_PER_CPU(bool, has_rss);

@@ -997,6 +1001,84 @@ static int partition_domain_translate(struct irq_domain 
*d,
.select = gic_irq_domain_select,
  };

+#ifdef CONFIG_USE_ICC_SYSREGS_FOR_IRQFLAGS
+/*
+ * The behaviours of RPR and PMR registers differ depending on the value of
+ * SCR_EL3.FIQ, while the behaviour of priority registers of the distributor
+ * and redistributors is always the same.
+ *
+ * If SCR_EL3.FIQ == 1, the values used for RPR and PMR are the same as the 
ones
+ * programmed in the distributor and redistributors registers.
+ *
+ * Otherwise, the value presented by RPR as well as the value which will be
+ * compared against PMR is: (GIC_(R)DIST_PRI[irq] >> 1) | 0x80;
+ *
+ * see GICv3/GICv4 Architecture Specification (IHI0069D):
+ * - section 4.8.1 Non-secure accesses to register fields for Secure interrupt
+ *   priorities.
+ * - Figure 4-7 Secure read of the priority field for a Non-secure Group 1
+ *   interrupt.
+ */

I think we can use write/read PMR to check if SCR_EL3.FIQ == 1.
Like this:

gic_write_pmr(0xf0);
if (gic_read_pmr() == 0xf0)// if SCR_EL3.FIQ 

[PATCH 2/2] f2fs: add GC_WRITTEN_PAGE to gc atomic file

[Yunlong Song]

This patch enables to gc atomic file by adding GC_WRITTEN_PAGE to
identify the gced pages of atomic file, which can avoid
register_inmem_page in set_page_dirty, so the gced pages will not mix
with the inmem pages.

Signed-off-by: Yunlong Song 
---
 fs/f2fs/data.c|  7 ++-
 fs/f2fs/gc.c  | 25 ++---
 fs/f2fs/segment.h |  3 +++
 3 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index edafcb6..5e1fc5d 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -120,6 +120,10 @@ static void f2fs_write_end_io(struct bio *bio)
 
dec_page_count(sbi, type);
clear_cold_data(page);
+   if (IS_GC_WRITTEN_PAGE(page)) {
+   set_page_private(page, 0);
+   ClearPagePrivate(page);
+   }
end_page_writeback(page);
}
if (!get_pages(sbi, F2FS_WB_CP_DATA) &&
@@ -2418,7 +2422,8 @@ static int f2fs_set_data_page_dirty(struct page *page)
if (!PageUptodate(page))
SetPageUptodate(page);
 
-   if (f2fs_is_atomic_file(inode) && !f2fs_is_commit_atomic_write(inode)) {
+   if (f2fs_is_atomic_file(inode) && !f2fs_is_commit_atomic_write(inode)
+   && !IS_GC_WRITTEN_PAGE(page)) {
if (!IS_ATOMIC_WRITTEN_PAGE(page)) {
register_inmem_page(inode, page);
return 1;
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 84ab3ff..9d54ddb 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -622,10 +622,6 @@ static void move_data_block(struct inode *inode, block_t 
bidx,
if (!check_valid_map(F2FS_I_SB(inode), segno, off))
goto out;
 
-   if (f2fs_is_atomic_file(inode) &&
-   !f2fs_is_commit_atomic_write(inode))
-   goto out;
-
if (f2fs_is_pinned_file(inode)) {
f2fs_pin_file_control(inode, true);
goto out;
@@ -680,6 +676,12 @@ static void move_data_block(struct inode *inode, block_t 
bidx,
goto put_page_out;
}
 
+   if (f2fs_is_atomic_file(inode) &&
+   !f2fs_is_commit_atomic_write(inode) &&
+   !IS_GC_WRITTEN_PAGE(fio.encrypted_page)) {
+   set_page_private(fio.encrypted_page, (unsigned 
long)GC_WRITTEN_PAGE);
+   SetPagePrivate(fio.encrypted_page);
+   }
set_page_dirty(fio.encrypted_page);
f2fs_wait_on_page_writeback(fio.encrypted_page, DATA, true);
if (clear_page_dirty_for_io(fio.encrypted_page))
@@ -730,9 +732,6 @@ static void move_data_page(struct inode *inode, block_t 
bidx, int gc_type,
if (!check_valid_map(F2FS_I_SB(inode), segno, off))
goto out;
 
-   if (f2fs_is_atomic_file(inode) &&
-   !f2fs_is_commit_atomic_write(inode))
-   goto out;
if (f2fs_is_pinned_file(inode)) {
if (gc_type == FG_GC)
f2fs_pin_file_control(inode, true);
@@ -742,6 +741,12 @@ static void move_data_page(struct inode *inode, block_t 
bidx, int gc_type,
if (gc_type == BG_GC) {
if (PageWriteback(page))
goto out;
+   if (f2fs_is_atomic_file(inode) &&
+   !f2fs_is_commit_atomic_write(inode) &&
+   !IS_GC_WRITTEN_PAGE(page)) {
+   set_page_private(page, (unsigned long)GC_WRITTEN_PAGE);
+   SetPagePrivate(page);
+   }
set_page_dirty(page);
set_cold_data(page);
} else {
@@ -762,6 +767,12 @@ static void move_data_page(struct inode *inode, block_t 
bidx, int gc_type,
int err;
 
 retry:
+   if (f2fs_is_atomic_file(inode) &&
+   !f2fs_is_commit_atomic_write(inode) &&
+   !IS_GC_WRITTEN_PAGE(page)) {
+   set_page_private(page, (unsigned long)GC_WRITTEN_PAGE);
+   SetPagePrivate(page);
+   }
set_page_dirty(page);
f2fs_wait_on_page_writeback(page, DATA, true);
if (clear_page_dirty_for_io(page)) {
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index f11c4bc..f0a6432 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -203,11 +203,14 @@ struct segment_allocation {
  */
 #define ATOMIC_WRITTEN_PAGE((unsigned long)-1)
 #define DUMMY_WRITTEN_PAGE ((unsigned long)-2)
+#define GC_WRITTEN_PAGE((unsigned long)-3)
 
 #define IS_ATOMIC_WRITTEN_PAGE(page)   \
(page_private(page) == (unsigned long)ATOMIC_WRITTEN_PAGE)
 #define IS_DUMMY_WRITTEN_PAGE(page)\
(page_private(page) == (unsigned long)DUMMY_WRITTEN_PAGE)
+#define IS_GC_WRITTEN_PAGE(page)   \
+   (page_private(page) == (unsigned 

[PATCH 2/2] f2fs: add GC_WRITTEN_PAGE to gc atomic file

[Yunlong Song]

This patch enables to gc atomic file by adding GC_WRITTEN_PAGE to
identify the gced pages of atomic file, which can avoid
register_inmem_page in set_page_dirty, so the gced pages will not mix
with the inmem pages.

Signed-off-by: Yunlong Song 
---
 fs/f2fs/data.c|  7 ++-
 fs/f2fs/gc.c  | 25 ++---
 fs/f2fs/segment.h |  3 +++
 3 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index edafcb6..5e1fc5d 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -120,6 +120,10 @@ static void f2fs_write_end_io(struct bio *bio)
 
dec_page_count(sbi, type);
clear_cold_data(page);
+   if (IS_GC_WRITTEN_PAGE(page)) {
+   set_page_private(page, 0);
+   ClearPagePrivate(page);
+   }
end_page_writeback(page);
}
if (!get_pages(sbi, F2FS_WB_CP_DATA) &&
@@ -2418,7 +2422,8 @@ static int f2fs_set_data_page_dirty(struct page *page)
if (!PageUptodate(page))
SetPageUptodate(page);
 
-   if (f2fs_is_atomic_file(inode) && !f2fs_is_commit_atomic_write(inode)) {
+   if (f2fs_is_atomic_file(inode) && !f2fs_is_commit_atomic_write(inode)
+   && !IS_GC_WRITTEN_PAGE(page)) {
if (!IS_ATOMIC_WRITTEN_PAGE(page)) {
register_inmem_page(inode, page);
return 1;
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 84ab3ff..9d54ddb 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -622,10 +622,6 @@ static void move_data_block(struct inode *inode, block_t 
bidx,
if (!check_valid_map(F2FS_I_SB(inode), segno, off))
goto out;
 
-   if (f2fs_is_atomic_file(inode) &&
-   !f2fs_is_commit_atomic_write(inode))
-   goto out;
-
if (f2fs_is_pinned_file(inode)) {
f2fs_pin_file_control(inode, true);
goto out;
@@ -680,6 +676,12 @@ static void move_data_block(struct inode *inode, block_t 
bidx,
goto put_page_out;
}
 
+   if (f2fs_is_atomic_file(inode) &&
+   !f2fs_is_commit_atomic_write(inode) &&
+   !IS_GC_WRITTEN_PAGE(fio.encrypted_page)) {
+   set_page_private(fio.encrypted_page, (unsigned 
long)GC_WRITTEN_PAGE);
+   SetPagePrivate(fio.encrypted_page);
+   }
set_page_dirty(fio.encrypted_page);
f2fs_wait_on_page_writeback(fio.encrypted_page, DATA, true);
if (clear_page_dirty_for_io(fio.encrypted_page))
@@ -730,9 +732,6 @@ static void move_data_page(struct inode *inode, block_t 
bidx, int gc_type,
if (!check_valid_map(F2FS_I_SB(inode), segno, off))
goto out;
 
-   if (f2fs_is_atomic_file(inode) &&
-   !f2fs_is_commit_atomic_write(inode))
-   goto out;
if (f2fs_is_pinned_file(inode)) {
if (gc_type == FG_GC)
f2fs_pin_file_control(inode, true);
@@ -742,6 +741,12 @@ static void move_data_page(struct inode *inode, block_t 
bidx, int gc_type,
if (gc_type == BG_GC) {
if (PageWriteback(page))
goto out;
+   if (f2fs_is_atomic_file(inode) &&
+   !f2fs_is_commit_atomic_write(inode) &&
+   !IS_GC_WRITTEN_PAGE(page)) {
+   set_page_private(page, (unsigned long)GC_WRITTEN_PAGE);
+   SetPagePrivate(page);
+   }
set_page_dirty(page);
set_cold_data(page);
} else {
@@ -762,6 +767,12 @@ static void move_data_page(struct inode *inode, block_t 
bidx, int gc_type,
int err;
 
 retry:
+   if (f2fs_is_atomic_file(inode) &&
+   !f2fs_is_commit_atomic_write(inode) &&
+   !IS_GC_WRITTEN_PAGE(page)) {
+   set_page_private(page, (unsigned long)GC_WRITTEN_PAGE);
+   SetPagePrivate(page);
+   }
set_page_dirty(page);
f2fs_wait_on_page_writeback(page, DATA, true);
if (clear_page_dirty_for_io(page)) {
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index f11c4bc..f0a6432 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -203,11 +203,14 @@ struct segment_allocation {
  */
 #define ATOMIC_WRITTEN_PAGE((unsigned long)-1)
 #define DUMMY_WRITTEN_PAGE ((unsigned long)-2)
+#define GC_WRITTEN_PAGE((unsigned long)-3)
 
 #define IS_ATOMIC_WRITTEN_PAGE(page)   \
(page_private(page) == (unsigned long)ATOMIC_WRITTEN_PAGE)
 #define IS_DUMMY_WRITTEN_PAGE(page)\
(page_private(page) == (unsigned long)DUMMY_WRITTEN_PAGE)
+#define IS_GC_WRITTEN_PAGE(page)   \
+   (page_private(page) == (unsigned long)GC_WRITTEN_PAGE)
 
 struct 

[PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

[Yunlong Song]

If inode has already started to atomic commit, then set_page_dirty will
not mix the gc pages with the inmem atomic pages, so the page can be
gced safely.

Signed-off-by: Yunlong Song 
---
 fs/f2fs/data.c | 5 ++---
 fs/f2fs/gc.c   | 6 --
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 7435830..edafcb6 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1580,14 +1580,13 @@ bool should_update_outplace(struct inode *inode, struct 
f2fs_io_info *fio)
return true;
if (S_ISDIR(inode->i_mode))
return true;
-   if (f2fs_is_atomic_file(inode))
-   return true;
if (fio) {
if (is_cold_data(fio->page))
return true;
if (IS_ATOMIC_WRITTEN_PAGE(fio->page))
return true;
-   }
+   } else if (f2fs_is_atomic_file(inode))
+   return true;
return false;
 }
 
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index b9d93fd..84ab3ff 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -622,7 +622,8 @@ static void move_data_block(struct inode *inode, block_t 
bidx,
if (!check_valid_map(F2FS_I_SB(inode), segno, off))
goto out;
 
-   if (f2fs_is_atomic_file(inode))
+   if (f2fs_is_atomic_file(inode) &&
+   !f2fs_is_commit_atomic_write(inode))
goto out;
 
if (f2fs_is_pinned_file(inode)) {
@@ -729,7 +730,8 @@ static void move_data_page(struct inode *inode, block_t 
bidx, int gc_type,
if (!check_valid_map(F2FS_I_SB(inode), segno, off))
goto out;
 
-   if (f2fs_is_atomic_file(inode))
+   if (f2fs_is_atomic_file(inode) &&
+   !f2fs_is_commit_atomic_write(inode))
goto out;
if (f2fs_is_pinned_file(inode)) {
if (gc_type == FG_GC)
-- 
1.8.5.2

[PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

[Yunlong Song]

If inode has already started to atomic commit, then set_page_dirty will
not mix the gc pages with the inmem atomic pages, so the page can be
gced safely.

Signed-off-by: Yunlong Song 
---
 fs/f2fs/data.c | 5 ++---
 fs/f2fs/gc.c   | 6 --
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 7435830..edafcb6 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1580,14 +1580,13 @@ bool should_update_outplace(struct inode *inode, struct 
f2fs_io_info *fio)
return true;
if (S_ISDIR(inode->i_mode))
return true;
-   if (f2fs_is_atomic_file(inode))
-   return true;
if (fio) {
if (is_cold_data(fio->page))
return true;
if (IS_ATOMIC_WRITTEN_PAGE(fio->page))
return true;
-   }
+   } else if (f2fs_is_atomic_file(inode))
+   return true;
return false;
 }
 
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index b9d93fd..84ab3ff 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -622,7 +622,8 @@ static void move_data_block(struct inode *inode, block_t 
bidx,
if (!check_valid_map(F2FS_I_SB(inode), segno, off))
goto out;
 
-   if (f2fs_is_atomic_file(inode))
+   if (f2fs_is_atomic_file(inode) &&
+   !f2fs_is_commit_atomic_write(inode))
goto out;
 
if (f2fs_is_pinned_file(inode)) {
@@ -729,7 +730,8 @@ static void move_data_page(struct inode *inode, block_t 
bidx, int gc_type,
if (!check_valid_map(F2FS_I_SB(inode), segno, off))
goto out;
 
-   if (f2fs_is_atomic_file(inode))
+   if (f2fs_is_atomic_file(inode) &&
+   !f2fs_is_commit_atomic_write(inode))
goto out;
if (f2fs_is_pinned_file(inode)) {
if (gc_type == FG_GC)
-- 
1.8.5.2

Re: [PATCH v4] Fix loading of module radeonfb on PowerMac

[kbuild test robot]

Hi Mathieu,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.15 next-20180202]
[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/Mathieu-Malaterre/Fix-loading-of-module-radeonfb-on-PowerMac/20180203-085907
config: x86_64-randconfig-x009-201804 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from drivers/video/fbdev/aty/radeon_base.c:91:0:
>> drivers/video/fbdev/aty/../edid.h:21:0: warning: "EDID_LENGTH" redefined
#define EDID_LENGTH0x80

   In file included from include/drm/drm_crtc.h:44:0,
from include/drm/drm_fb_helper.h:35,
from drivers/video/fbdev/aty/radeon_base.c:73:
   include/drm/drm_edid.h:32:0: note: this is the location of the previous 
definition
#define EDID_LENGTH 128

   Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls64
   Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u64
   Cyclomatic Complexity 1 include/asm-generic/getorder.h:__get_order
   Cyclomatic Complexity 1 include/linux/string.h:strnlen
   Cyclomatic Complexity 4 include/linux/string.h:strlen
   Cyclomatic Complexity 6 include/linux/string.h:strlcpy
   Cyclomatic Complexity 4 include/linux/string.h:memcpy
   Cyclomatic Complexity 1 
arch/x86/include/asm/paravirt.h:arch_local_irq_disable
   Cyclomatic Complexity 1 arch/x86/include/asm/paravirt.h:arch_local_irq_enable
   Cyclomatic Complexity 1 include/linux/spinlock.h:spinlock_check
   Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock_irqrestore
   Cyclomatic Complexity 1 include/linux/jiffies.h:_msecs_to_jiffies
   Cyclomatic Complexity 3 include/linux/jiffies.h:msecs_to_jiffies
   Cyclomatic Complexity 1 arch/x86/include/asm/io.h:readb
   Cyclomatic Complexity 1 arch/x86/include/asm/io.h:readw
   Cyclomatic Complexity 1 arch/x86/include/asm/io.h:readl
   Cyclomatic Complexity 1 arch/x86/include/asm/io.h:writeb
   Cyclomatic Complexity 1 arch/x86/include/asm/io.h:writel
   Cyclomatic Complexity 1 arch/x86/include/asm/io.h:ioremap
   Cyclomatic Complexity 1 include/linux/kobject.h:kobject_name
   Cyclomatic Complexity 2 include/linux/device.h:dev_name
   Cyclomatic Complexity 1 include/linux/device.h:dev_get_drvdata
   Cyclomatic Complexity 1 include/linux/device.h:dev_set_drvdata
   Cyclomatic Complexity 1 include/linux/io.h:arch_phys_wc_add
   Cyclomatic Complexity 1 include/linux/io.h:arch_phys_wc_del
   Cyclomatic Complexity 68 include/linux/slab.h:kmalloc_large
   Cyclomatic Complexity 3 include/linux/slab.h:kmalloc
   Cyclomatic Complexity 1 include/linux/slab.h:kzalloc
   Cyclomatic Complexity 1 include/linux/pci.h:pci_get_drvdata
   Cyclomatic Complexity 1 include/linux/pci.h:pci_set_drvdata
   Cyclomatic Complexity 1 include/linux/pci.h:pci_name
   Cyclomatic Complexity 2 include/linux/fb.h:alloc_apertures
   Cyclomatic Complexity 2 
drivers/video/fbdev/aty/radeonfb.h:radeon_pll_errata_after_index
   Cyclomatic Complexity 2 
drivers/video/fbdev/aty/radeonfb.h:radeon_pll_errata_after_data
   Cyclomatic Complexity 1 drivers/video/fbdev/aty/radeonfb.h:round_div
   Cyclomatic Complexity 3 drivers/video/fbdev/aty/radeonfb.h:var_to_depth
   Cyclomatic Complexity 5 drivers/video/fbdev/aty/radeonfb.h:radeon_get_dstbpp
   Cyclomatic Complexity 1 drivers/video/fbdev/aty/radeonfb.h:radeonfb_bl_init
   Cyclomatic Complexity 1 drivers/video/fbdev/aty/radeonfb.h:radeonfb_bl_exit
   Cyclomatic Complexity 1 
include/drm/drm_fb_helper.h:drm_fb_helper_remove_conflicting_framebuffers
   Cyclomatic Complexity 21 
drivers/video/fbdev/aty/radeon_base.c:radeon_calc_pll_regs
   Cyclomatic Complexity 1 drivers/video/fbdev/aty/radeon_base.c:radeonfb_exit
   Cyclomatic Complexity 6 
drivers/video/fbdev/aty/radeon_base.c:radeon_find_mem_vbios
   Cyclomatic Complexity 4 
drivers/video/fbdev/aty/radeon_base.c:radeon_kick_out_firmware_fb
   Cyclomatic Complexity 5 
drivers/video/fbdev/aty/radeon_base.c:radeonfb_pci_unregister
   Cyclomatic Complexity 1 
drivers/video/fbdev/aty/radeon_base.c:radeon_show_one_edid
   Cyclomatic Complexity 3 
drivers/video/fbdev/aty/radeon_base.c:radeon_show_edid2
   Cyclomatic Complexity 3 
drivers/video/fbdev/aty/radeon_base.c:radeon_show_edid1
   Cyclomatic Complexity 2 
drivers/video/fbdev/aty/radeon_base.c:radeon_set_fbinfo
   Cyclomatic Complexity 18 
drivers/video/fbdev/aty/radeon_base.c:radeonfb_check_var
   Cyclomatic Complexity 2 
drivers/video/fbdev/aty/radeon_base.c:radeon_unmap_ROM
   Cyclomatic Complexity 7 drivers/video/fbdev/aty/radeon_base.c:radeon_map_ROM
   Cyclomatic Complexity 16 drivers/video/fbdev/aty/radeon_base.c:radeonfb_setup
   Cyclomatic Complexity 2 drivers/video/fbdev/aty/radeo

Re: [PATCH v4] Fix loading of module radeonfb on PowerMac

[kbuild test robot]

Hi Mathieu,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.15 next-20180202]
[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/Mathieu-Malaterre/Fix-loading-of-module-radeonfb-on-PowerMac/20180203-085907
config: x86_64-randconfig-x009-201804 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from drivers/video/fbdev/aty/radeon_base.c:91:0:
>> drivers/video/fbdev/aty/../edid.h:21:0: warning: "EDID_LENGTH" redefined
#define EDID_LENGTH0x80

   In file included from include/drm/drm_crtc.h:44:0,
from include/drm/drm_fb_helper.h:35,
from drivers/video/fbdev/aty/radeon_base.c:73:
   include/drm/drm_edid.h:32:0: note: this is the location of the previous 
definition
#define EDID_LENGTH 128

   Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls64
   Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u64
   Cyclomatic Complexity 1 include/asm-generic/getorder.h:__get_order
   Cyclomatic Complexity 1 include/linux/string.h:strnlen
   Cyclomatic Complexity 4 include/linux/string.h:strlen
   Cyclomatic Complexity 6 include/linux/string.h:strlcpy
   Cyclomatic Complexity 4 include/linux/string.h:memcpy
   Cyclomatic Complexity 1 
arch/x86/include/asm/paravirt.h:arch_local_irq_disable
   Cyclomatic Complexity 1 arch/x86/include/asm/paravirt.h:arch_local_irq_enable
   Cyclomatic Complexity 1 include/linux/spinlock.h:spinlock_check
   Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock_irqrestore
   Cyclomatic Complexity 1 include/linux/jiffies.h:_msecs_to_jiffies
   Cyclomatic Complexity 3 include/linux/jiffies.h:msecs_to_jiffies
   Cyclomatic Complexity 1 arch/x86/include/asm/io.h:readb
   Cyclomatic Complexity 1 arch/x86/include/asm/io.h:readw
   Cyclomatic Complexity 1 arch/x86/include/asm/io.h:readl
   Cyclomatic Complexity 1 arch/x86/include/asm/io.h:writeb
   Cyclomatic Complexity 1 arch/x86/include/asm/io.h:writel
   Cyclomatic Complexity 1 arch/x86/include/asm/io.h:ioremap
   Cyclomatic Complexity 1 include/linux/kobject.h:kobject_name
   Cyclomatic Complexity 2 include/linux/device.h:dev_name
   Cyclomatic Complexity 1 include/linux/device.h:dev_get_drvdata
   Cyclomatic Complexity 1 include/linux/device.h:dev_set_drvdata
   Cyclomatic Complexity 1 include/linux/io.h:arch_phys_wc_add
   Cyclomatic Complexity 1 include/linux/io.h:arch_phys_wc_del
   Cyclomatic Complexity 68 include/linux/slab.h:kmalloc_large
   Cyclomatic Complexity 3 include/linux/slab.h:kmalloc
   Cyclomatic Complexity 1 include/linux/slab.h:kzalloc
   Cyclomatic Complexity 1 include/linux/pci.h:pci_get_drvdata
   Cyclomatic Complexity 1 include/linux/pci.h:pci_set_drvdata
   Cyclomatic Complexity 1 include/linux/pci.h:pci_name
   Cyclomatic Complexity 2 include/linux/fb.h:alloc_apertures
   Cyclomatic Complexity 2 
drivers/video/fbdev/aty/radeonfb.h:radeon_pll_errata_after_index
   Cyclomatic Complexity 2 
drivers/video/fbdev/aty/radeonfb.h:radeon_pll_errata_after_data
   Cyclomatic Complexity 1 drivers/video/fbdev/aty/radeonfb.h:round_div
   Cyclomatic Complexity 3 drivers/video/fbdev/aty/radeonfb.h:var_to_depth
   Cyclomatic Complexity 5 drivers/video/fbdev/aty/radeonfb.h:radeon_get_dstbpp
   Cyclomatic Complexity 1 drivers/video/fbdev/aty/radeonfb.h:radeonfb_bl_init
   Cyclomatic Complexity 1 drivers/video/fbdev/aty/radeonfb.h:radeonfb_bl_exit
   Cyclomatic Complexity 1 
include/drm/drm_fb_helper.h:drm_fb_helper_remove_conflicting_framebuffers
   Cyclomatic Complexity 21 
drivers/video/fbdev/aty/radeon_base.c:radeon_calc_pll_regs
   Cyclomatic Complexity 1 drivers/video/fbdev/aty/radeon_base.c:radeonfb_exit
   Cyclomatic Complexity 6 
drivers/video/fbdev/aty/radeon_base.c:radeon_find_mem_vbios
   Cyclomatic Complexity 4 
drivers/video/fbdev/aty/radeon_base.c:radeon_kick_out_firmware_fb
   Cyclomatic Complexity 5 
drivers/video/fbdev/aty/radeon_base.c:radeonfb_pci_unregister
   Cyclomatic Complexity 1 
drivers/video/fbdev/aty/radeon_base.c:radeon_show_one_edid
   Cyclomatic Complexity 3 
drivers/video/fbdev/aty/radeon_base.c:radeon_show_edid2
   Cyclomatic Complexity 3 
drivers/video/fbdev/aty/radeon_base.c:radeon_show_edid1
   Cyclomatic Complexity 2 
drivers/video/fbdev/aty/radeon_base.c:radeon_set_fbinfo
   Cyclomatic Complexity 18 
drivers/video/fbdev/aty/radeon_base.c:radeonfb_check_var
   Cyclomatic Complexity 2 
drivers/video/fbdev/aty/radeon_base.c:radeon_unmap_ROM
   Cyclomatic Complexity 7 drivers/video/fbdev/aty/radeon_base.c:radeon_map_ROM
   Cyclomatic Complexity 16 drivers/video/fbdev/aty/radeon_base.c:radeonfb_setup
   Cyclomatic Complexity 2 drivers/video/fbdev/aty/radeo

Re: bisected bd4c82c22c367e is the first bad commit (was [Bug 198617] New: zswap causing random applications to crash)

[Sergey Senozhatsky]

On (02/03/18 10:34), Sergey Senozhatsky wrote:
> so we are basically looking at 4.14-rc0+
[..]
> # first bad commit: [bd4c82c22c367e068acb1ec9ec02be2fac3e09e2] mm, THP, swap: 
> delay splitting THP after swapped out

To re-confirm, disabling CONFIG_TRANSPARENT_HUGEPAGE fixes my 4.15.0-next

-ss

Re: bisected bd4c82c22c367e is the first bad commit (was [Bug 198617] New: zswap causing random applications to crash)

[Sergey Senozhatsky]

On (02/03/18 10:34), Sergey Senozhatsky wrote:
> so we are basically looking at 4.14-rc0+
[..]
> # first bad commit: [bd4c82c22c367e068acb1ec9ec02be2fac3e09e2] mm, THP, swap: 
> delay splitting THP after swapped out

To re-confirm, disabling CONFIG_TRANSPARENT_HUGEPAGE fixes my 4.15.0-next

-ss

[PATCH v2] x86/perf : Add check for CPUID instruction before using

[Matthew Whitehead]

We still officially support the ancient i486 cpu. First generation
versions of this processor do not have the CPUID instruction, though
later versions do. Therefore you must check that the cpu supports
it before using it. At present it fails with an "Illegal Instruction"
signal on the early processors.

v1: cpuid detection code based on GCC gcc/config/i386/cpuid.h

https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=gcc/config/i386/cpuid.h;hb=HEAD
v2: cpuid detection code based on Linux kernel arch/x86/kernel/cpu/common.c

Signed-off-by: Matthew Whitehead 
---
 tools/perf/arch/x86/util/header.c | 54 +++
 tools/perf/util/header.h  |  2 ++
 2 files changed, 56 insertions(+)

diff --git a/tools/perf/arch/x86/util/header.c 
b/tools/perf/arch/x86/util/header.c
index fb0d71a..d2508b3 100644
--- a/tools/perf/arch/x86/util/header.c
+++ b/tools/perf/arch/x86/util/header.c
@@ -7,6 +7,57 @@
 
 #include "../../util/header.h"
 
+#ifndef __x86_64__
+
+/* This code based on arch/x86/kernel/cpu/common.c
+ * Standard macro to see if a specific flag is changeable.
+ */
+static inline int flag_is_changeable_p(u32 flag)
+{
+   u32 f1, f2;
+
+   /*
+* Cyrix and IDT cpus allow disabling of CPUID
+* so the code below may return different results
+* when it is executed before and after enabling
+* the CPUID. Add "volatile" to not allow gcc to
+* optimize the subsequent calls to this function.
+*/
+   asm volatile ("pushfl   \n\t"
+ "pushfl   \n\t"
+ "popl %0  \n\t"
+ "movl %0, %1  \n\t"
+ "xorl %2, %0  \n\t"
+ "pushl %0 \n\t"
+ "popfl\n\t"
+ "pushfl   \n\t"
+ "popl %0  \n\t"
+ "popfl\n\t"
+
+ : "=" (f1), "=" (f2)
+ : "ir" (flag));
+
+   return ((f1^f2) & flag) != 0;
+}
+
+#define X86_EFLAGS_ID 0x0020
+
+/* Probe for the CPUID instruction */
+int have_cpuid_p(void)
+{
+   return flag_is_changeable_p(X86_EFLAGS_ID);
+}
+
+#else  /* CONFIG_X86_64 */
+
+/* All X86_64 have cpuid instruction */
+int have_cpuid_p(void)
+{
+   return 1;
+}
+
+#endif /* CONFIG_X86_64 */
+
 static inline void
 cpuid(unsigned int op, unsigned int *a, unsigned int *b, unsigned int *c,
   unsigned int *d)
@@ -28,6 +79,9 @@
int nb;
char vendor[16];
 
+   if (!have_cpuid_p())
+   return -1;
+
cpuid(0, , , , );
strncpy([0], (char *)(), 4);
strncpy([4], (char *)(), 4);
diff --git a/tools/perf/util/header.h b/tools/perf/util/header.h
index f28..f4de656 100644
--- a/tools/perf/util/header.h
+++ b/tools/perf/util/header.h
@@ -171,6 +171,8 @@ int write_padded(struct feat_fd *fd, const void *bf,
 /*
  * arch specific callback
  */
+int have_cpuid_p(void);
+
 int get_cpuid(char *buffer, size_t sz);
 
 char *get_cpuid_str(struct perf_pmu *pmu __maybe_unused);
-- 
1.8.3.1

[PATCH v2] x86/perf : Add check for CPUID instruction before using

[Matthew Whitehead]

We still officially support the ancient i486 cpu. First generation
versions of this processor do not have the CPUID instruction, though
later versions do. Therefore you must check that the cpu supports
it before using it. At present it fails with an "Illegal Instruction"
signal on the early processors.

v1: cpuid detection code based on GCC gcc/config/i386/cpuid.h

https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=gcc/config/i386/cpuid.h;hb=HEAD
v2: cpuid detection code based on Linux kernel arch/x86/kernel/cpu/common.c

Signed-off-by: Matthew Whitehead 
---
 tools/perf/arch/x86/util/header.c | 54 +++
 tools/perf/util/header.h  |  2 ++
 2 files changed, 56 insertions(+)

diff --git a/tools/perf/arch/x86/util/header.c 
b/tools/perf/arch/x86/util/header.c
index fb0d71a..d2508b3 100644
--- a/tools/perf/arch/x86/util/header.c
+++ b/tools/perf/arch/x86/util/header.c
@@ -7,6 +7,57 @@
 
 #include "../../util/header.h"
 
+#ifndef __x86_64__
+
+/* This code based on arch/x86/kernel/cpu/common.c
+ * Standard macro to see if a specific flag is changeable.
+ */
+static inline int flag_is_changeable_p(u32 flag)
+{
+   u32 f1, f2;
+
+   /*
+* Cyrix and IDT cpus allow disabling of CPUID
+* so the code below may return different results
+* when it is executed before and after enabling
+* the CPUID. Add "volatile" to not allow gcc to
+* optimize the subsequent calls to this function.
+*/
+   asm volatile ("pushfl   \n\t"
+ "pushfl   \n\t"
+ "popl %0  \n\t"
+ "movl %0, %1  \n\t"
+ "xorl %2, %0  \n\t"
+ "pushl %0 \n\t"
+ "popfl\n\t"
+ "pushfl   \n\t"
+ "popl %0  \n\t"
+ "popfl\n\t"
+
+ : "=" (f1), "=" (f2)
+ : "ir" (flag));
+
+   return ((f1^f2) & flag) != 0;
+}
+
+#define X86_EFLAGS_ID 0x0020
+
+/* Probe for the CPUID instruction */
+int have_cpuid_p(void)
+{
+   return flag_is_changeable_p(X86_EFLAGS_ID);
+}
+
+#else  /* CONFIG_X86_64 */
+
+/* All X86_64 have cpuid instruction */
+int have_cpuid_p(void)
+{
+   return 1;
+}
+
+#endif /* CONFIG_X86_64 */
+
 static inline void
 cpuid(unsigned int op, unsigned int *a, unsigned int *b, unsigned int *c,
   unsigned int *d)
@@ -28,6 +79,9 @@
int nb;
char vendor[16];
 
+   if (!have_cpuid_p())
+   return -1;
+
cpuid(0, , , , );
strncpy([0], (char *)(), 4);
strncpy([4], (char *)(), 4);
diff --git a/tools/perf/util/header.h b/tools/perf/util/header.h
index f28..f4de656 100644
--- a/tools/perf/util/header.h
+++ b/tools/perf/util/header.h
@@ -171,6 +171,8 @@ int write_padded(struct feat_fd *fd, const void *bf,
 /*
  * arch specific callback
  */
+int have_cpuid_p(void);
+
 int get_cpuid(char *buffer, size_t sz);
 
 char *get_cpuid_str(struct perf_pmu *pmu __maybe_unused);
-- 
1.8.3.1

Re: [PATCH] locking/qspinlock: Ensure node is initialised before updating prev->next

[kbuild test robot]

Hi Will,

I love your patch! Yet something to improve:

[auto build test ERROR on v4.15]
[cannot apply to tip/locking/core tip/core/locking tip/auto-latest 
next-20180202]
[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/Will-Deacon/locking-qspinlock-Ensure-node-is-initialised-before-updating-prev-next/20180203-095222
config: x86_64-randconfig-x017-201804 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:9,
from include/linux/smp.h:12,
from kernel/locking/qspinlock.c:25:
   kernel/locking/qspinlock.c: In function 'queued_spin_lock_slowpath':
>> include/linux/compiler.h:264:8: error: conversion to non-scalar type 
>> requested
 union { typeof(x) __val; char __c[1]; } __u = \
   ^
>> arch/x86/include/asm/barrier.h:71:2: note: in expansion of macro 'WRITE_ONCE'
 WRITE_ONCE(*p, v);  \
 ^~
   include/asm-generic/barrier.h:157:33: note: in expansion of macro 
'__smp_store_release'
#define smp_store_release(p, v) __smp_store_release(p, v)
^~~
>> kernel/locking/qspinlock.c:419:3: note: in expansion of macro 
>> 'smp_store_release'
  smp_store_release(prev->next, node);
  ^
--
   In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:9,
from include/linux/smp.h:12,
from kernel//locking/qspinlock.c:25:
   kernel//locking/qspinlock.c: In function 'queued_spin_lock_slowpath':
>> include/linux/compiler.h:264:8: error: conversion to non-scalar type 
>> requested
 union { typeof(x) __val; char __c[1]; } __u = \
   ^
>> arch/x86/include/asm/barrier.h:71:2: note: in expansion of macro 'WRITE_ONCE'
 WRITE_ONCE(*p, v);  \
 ^~
   include/asm-generic/barrier.h:157:33: note: in expansion of macro 
'__smp_store_release'
#define smp_store_release(p, v) __smp_store_release(p, v)
^~~
   kernel//locking/qspinlock.c:419:3: note: in expansion of macro 
'smp_store_release'
  smp_store_release(prev->next, node);
  ^

vim +/WRITE_ONCE +71 arch/x86/include/asm/barrier.h

47933ad4 Peter Zijlstra 2013-11-06  66  
1638fb72 Michael S. Tsirkin 2015-12-27  67  #define __smp_store_release(p, v)   
\
47933ad4 Peter Zijlstra 2013-11-06  68  do {
\
47933ad4 Peter Zijlstra 2013-11-06  69  
compiletime_assert_atomic_type(*p); \
47933ad4 Peter Zijlstra 2013-11-06  70  barrier();  
\
76695af2 Andrey Konovalov   2015-08-02 @71  WRITE_ONCE(*p, v);  
\
47933ad4 Peter Zijlstra 2013-11-06  72  } while (0)
47933ad4 Peter Zijlstra 2013-11-06  73  

:: The code at line 71 was first introduced by commit
:: 76695af20c015206cffb84b15912be6797d0cca2 locking, arch: use 
WRITE_ONCE()/READ_ONCE() in smp_store_release()/smp_load_acquire()

:: TO: Andrey Konovalov <andreyk...@google.com>
:: CC: Ingo Molnar <mi...@kernel.org>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH] locking/qspinlock: Ensure node is initialised before updating prev->next

[kbuild test robot]

Hi Will,

I love your patch! Yet something to improve:

[auto build test ERROR on v4.15]
[cannot apply to tip/locking/core tip/core/locking tip/auto-latest 
next-20180202]
[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/Will-Deacon/locking-qspinlock-Ensure-node-is-initialised-before-updating-prev-next/20180203-095222
config: x86_64-randconfig-x017-201804 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:9,
from include/linux/smp.h:12,
from kernel/locking/qspinlock.c:25:
   kernel/locking/qspinlock.c: In function 'queued_spin_lock_slowpath':
>> include/linux/compiler.h:264:8: error: conversion to non-scalar type 
>> requested
 union { typeof(x) __val; char __c[1]; } __u = \
   ^
>> arch/x86/include/asm/barrier.h:71:2: note: in expansion of macro 'WRITE_ONCE'
 WRITE_ONCE(*p, v);  \
 ^~
   include/asm-generic/barrier.h:157:33: note: in expansion of macro 
'__smp_store_release'
#define smp_store_release(p, v) __smp_store_release(p, v)
^~~
>> kernel/locking/qspinlock.c:419:3: note: in expansion of macro 
>> 'smp_store_release'
  smp_store_release(prev->next, node);
  ^
--
   In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:9,
from include/linux/smp.h:12,
from kernel//locking/qspinlock.c:25:
   kernel//locking/qspinlock.c: In function 'queued_spin_lock_slowpath':
>> include/linux/compiler.h:264:8: error: conversion to non-scalar type 
>> requested
 union { typeof(x) __val; char __c[1]; } __u = \
   ^
>> arch/x86/include/asm/barrier.h:71:2: note: in expansion of macro 'WRITE_ONCE'
 WRITE_ONCE(*p, v);  \
 ^~
   include/asm-generic/barrier.h:157:33: note: in expansion of macro 
'__smp_store_release'
#define smp_store_release(p, v) __smp_store_release(p, v)
^~~
   kernel//locking/qspinlock.c:419:3: note: in expansion of macro 
'smp_store_release'
  smp_store_release(prev->next, node);
  ^

vim +/WRITE_ONCE +71 arch/x86/include/asm/barrier.h

47933ad4 Peter Zijlstra 2013-11-06  66  
1638fb72 Michael S. Tsirkin 2015-12-27  67  #define __smp_store_release(p, v)   
\
47933ad4 Peter Zijlstra 2013-11-06  68  do {
\
47933ad4 Peter Zijlstra 2013-11-06  69  
compiletime_assert_atomic_type(*p); \
47933ad4 Peter Zijlstra 2013-11-06  70  barrier();  
\
76695af2 Andrey Konovalov   2015-08-02 @71  WRITE_ONCE(*p, v);  
\
47933ad4 Peter Zijlstra 2013-11-06  72  } while (0)
47933ad4 Peter Zijlstra 2013-11-06  73  

:: The code at line 71 was first introduced by commit
:: 76695af20c015206cffb84b15912be6797d0cca2 locking, arch: use 
WRITE_ONCE()/READ_ONCE() in smp_store_release()/smp_load_acquire()

:: TO: Andrey Konovalov 
:: CC: Ingo Molnar 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH] locking/qspinlock: Ensure node is initialised before updating prev->next

[kbuild test robot]

Hi Will,

I love your patch! Perhaps something to improve:

[auto build test WARNING on v4.15]
[cannot apply to tip/locking/core tip/core/locking tip/auto-latest 
next-20180202]
[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/Will-Deacon/locking-qspinlock-Ensure-node-is-initialised-before-updating-prev-next/20180203-095222
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All warnings (new ones prefixed by >>):

   In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:9,
from include/linux/smp.h:12,
from kernel/locking/qspinlock.c:25:
   kernel/locking/qspinlock.c: In function 'queued_spin_lock_slowpath':
   include/linux/compiler.h:264:8: error: conversion to non-scalar type 
requested
 union { typeof(x) __val; char __c[1]; } __u = \
   ^
>> arch/sparc/include/asm/barrier_64.h:45:2: note: in expansion of macro 
>> 'WRITE_ONCE'
 WRITE_ONCE(*p, v);  \
 ^~
   include/asm-generic/barrier.h:157:33: note: in expansion of macro 
'__smp_store_release'
#define smp_store_release(p, v) __smp_store_release(p, v)
^~~
   kernel/locking/qspinlock.c:419:3: note: in expansion of macro 
'smp_store_release'
  smp_store_release(prev->next, node);
  ^
--
   In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:9,
from include/linux/smp.h:12,
from kernel//locking/qspinlock.c:25:
   kernel//locking/qspinlock.c: In function 'queued_spin_lock_slowpath':
   include/linux/compiler.h:264:8: error: conversion to non-scalar type 
requested
 union { typeof(x) __val; char __c[1]; } __u = \
   ^
>> arch/sparc/include/asm/barrier_64.h:45:2: note: in expansion of macro 
>> 'WRITE_ONCE'
 WRITE_ONCE(*p, v);  \
 ^~
   include/asm-generic/barrier.h:157:33: note: in expansion of macro 
'__smp_store_release'
#define smp_store_release(p, v) __smp_store_release(p, v)
^~~
   kernel//locking/qspinlock.c:419:3: note: in expansion of macro 
'smp_store_release'
  smp_store_release(prev->next, node);
  ^

vim +/WRITE_ONCE +45 arch/sparc/include/asm/barrier_64.h

d550bbd4 David Howells  2012-03-28  40  
45d9b859 Michael S. Tsirkin 2015-12-27  41  #define __smp_store_release(p, v)   
\
47933ad4 Peter Zijlstra 2013-11-06  42  do {
\
47933ad4 Peter Zijlstra 2013-11-06  43  
compiletime_assert_atomic_type(*p); \
47933ad4 Peter Zijlstra 2013-11-06  44  barrier();  
\
76695af2 Andrey Konovalov   2015-08-02 @45  WRITE_ONCE(*p, v);  
\
47933ad4 Peter Zijlstra 2013-11-06  46  } while (0)
47933ad4 Peter Zijlstra 2013-11-06  47  

:: The code at line 45 was first introduced by commit
:: 76695af20c015206cffb84b15912be6797d0cca2 locking, arch: use 
WRITE_ONCE()/READ_ONCE() in smp_store_release()/smp_load_acquire()

:: TO: Andrey Konovalov <andreyk...@google.com>
:: CC: Ingo Molnar <mi...@kernel.org>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH] locking/qspinlock: Ensure node is initialised before updating prev->next

[kbuild test robot]

Hi Will,

I love your patch! Perhaps something to improve:

[auto build test WARNING on v4.15]
[cannot apply to tip/locking/core tip/core/locking tip/auto-latest 
next-20180202]
[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/Will-Deacon/locking-qspinlock-Ensure-node-is-initialised-before-updating-prev-next/20180203-095222
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All warnings (new ones prefixed by >>):

   In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:9,
from include/linux/smp.h:12,
from kernel/locking/qspinlock.c:25:
   kernel/locking/qspinlock.c: In function 'queued_spin_lock_slowpath':
   include/linux/compiler.h:264:8: error: conversion to non-scalar type 
requested
 union { typeof(x) __val; char __c[1]; } __u = \
   ^
>> arch/sparc/include/asm/barrier_64.h:45:2: note: in expansion of macro 
>> 'WRITE_ONCE'
 WRITE_ONCE(*p, v);  \
 ^~
   include/asm-generic/barrier.h:157:33: note: in expansion of macro 
'__smp_store_release'
#define smp_store_release(p, v) __smp_store_release(p, v)
^~~
   kernel/locking/qspinlock.c:419:3: note: in expansion of macro 
'smp_store_release'
  smp_store_release(prev->next, node);
  ^
--
   In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:9,
from include/linux/smp.h:12,
from kernel//locking/qspinlock.c:25:
   kernel//locking/qspinlock.c: In function 'queued_spin_lock_slowpath':
   include/linux/compiler.h:264:8: error: conversion to non-scalar type 
requested
 union { typeof(x) __val; char __c[1]; } __u = \
   ^
>> arch/sparc/include/asm/barrier_64.h:45:2: note: in expansion of macro 
>> 'WRITE_ONCE'
 WRITE_ONCE(*p, v);  \
 ^~
   include/asm-generic/barrier.h:157:33: note: in expansion of macro 
'__smp_store_release'
#define smp_store_release(p, v) __smp_store_release(p, v)
^~~
   kernel//locking/qspinlock.c:419:3: note: in expansion of macro 
'smp_store_release'
  smp_store_release(prev->next, node);
  ^

vim +/WRITE_ONCE +45 arch/sparc/include/asm/barrier_64.h

d550bbd4 David Howells  2012-03-28  40  
45d9b859 Michael S. Tsirkin 2015-12-27  41  #define __smp_store_release(p, v)   
\
47933ad4 Peter Zijlstra 2013-11-06  42  do {
\
47933ad4 Peter Zijlstra 2013-11-06  43  
compiletime_assert_atomic_type(*p); \
47933ad4 Peter Zijlstra 2013-11-06  44  barrier();  
\
76695af2 Andrey Konovalov   2015-08-02 @45  WRITE_ONCE(*p, v);  
\
47933ad4 Peter Zijlstra 2013-11-06  46  } while (0)
47933ad4 Peter Zijlstra 2013-11-06  47  

:: The code at line 45 was first introduced by commit
:: 76695af20c015206cffb84b15912be6797d0cca2 locking, arch: use 
WRITE_ONCE()/READ_ONCE() in smp_store_release()/smp_load_acquire()

:: TO: Andrey Konovalov 
:: CC: Ingo Molnar 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

linux-next: Signed-off-by missing for commits in the s390 tree

[Stephen Rothwell]

Hi all,

Commits

  a39892ed47bf ("s390/runtime_instrumentation: re-add signum system call 
parameter")
  279d2cea3aad ("s390/cio: fix kernel-doc usage")

are missing a Signed-off-by from their committer.

-- 
Cheers,
Stephen Rothwell

linux-next: Signed-off-by missing for commits in the s390 tree

[Stephen Rothwell]

Hi all,

Commits

  a39892ed47bf ("s390/runtime_instrumentation: re-add signum system call 
parameter")
  279d2cea3aad ("s390/cio: fix kernel-doc usage")

are missing a Signed-off-by from their committer.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH bpf-next v8 0/5] libbpf: add XDP binding support

[Alexei Starovoitov]

On Wed, Jan 31, 2018 at 05:53:13PM +0100, Daniel Borkmann wrote:
> On 01/30/2018 09:50 PM, Eric Leblond wrote:
> > Hello Daniel,
> > 
> > No problem with the delay in the answer. I'm doing far worse.
> > 
> > Here is an updated version:
> > - add if_link.h in uapi and remove the definition
> > - fix a commit message
> > - remove uapi from a include
> 
> Fyi, this still needs to wait for a bit in the queue due to current
> merge window where bpf-next is closed during that time [0]. Thanks!
> 
>   [0] https://www.spinics.net/lists/netdev/msg481490.html

I've tested it and applied to bpf tree considering that
the series were practically ready long before bpf-next was closed.
Thank you Eric.
perf build was also fine, but please watch out for any unexpected
breakages, since perf has to be built on variety of distros.

Re: [PATCH bpf-next v8 0/5] libbpf: add XDP binding support

[Alexei Starovoitov]

On Wed, Jan 31, 2018 at 05:53:13PM +0100, Daniel Borkmann wrote:
> On 01/30/2018 09:50 PM, Eric Leblond wrote:
> > Hello Daniel,
> > 
> > No problem with the delay in the answer. I'm doing far worse.
> > 
> > Here is an updated version:
> > - add if_link.h in uapi and remove the definition
> > - fix a commit message
> > - remove uapi from a include
> 
> Fyi, this still needs to wait for a bit in the queue due to current
> merge window where bpf-next is closed during that time [0]. Thanks!
> 
>   [0] https://www.spinics.net/lists/netdev/msg481490.html

I've tested it and applied to bpf tree considering that
the series were practically ready long before bpf-next was closed.
Thank you Eric.
perf build was also fine, but please watch out for any unexpected
breakages, since perf has to be built on variety of distros.

Re: RFC(V3): Audit Kernel Container IDs

[Serge E. Hallyn]

On Fri, Feb 02, 2018 at 05:05:22PM -0500, Paul Moore wrote:
> On Tue, Jan 9, 2018 at 7:16 AM, Richard Guy Briggs  wrote:
> > Containers are a userspace concept.  The kernel knows nothing of them.
> >
> > The Linux audit system needs a way to be able to track the container
> > provenance of events and actions.  Audit needs the kernel's help to do
> > this.
> 
> Two small comments below, but I tend to think we are at a point where
> you can start cobbling together some prototype/RFC patches.  Surely

Agreed.

LGTM.

> there are going to be a few changes, and new comments, that come out
> once we see an initial implementation so let's see what those are.

thanks,
-serge

Re: RFC(V3): Audit Kernel Container IDs

[Serge E. Hallyn]

On Fri, Feb 02, 2018 at 05:05:22PM -0500, Paul Moore wrote:
> On Tue, Jan 9, 2018 at 7:16 AM, Richard Guy Briggs  wrote:
> > Containers are a userspace concept.  The kernel knows nothing of them.
> >
> > The Linux audit system needs a way to be able to track the container
> > provenance of events and actions.  Audit needs the kernel's help to do
> > this.
> 
> Two small comments below, but I tend to think we are at a point where
> you can start cobbling together some prototype/RFC patches.  Surely

Agreed.

LGTM.

> there are going to be a few changes, and new comments, that come out
> once we see an initial implementation so let's see what those are.

thanks,
-serge

bisected bd4c82c22c367e is the first bad commit (was [Bug 198617] New: zswap causing random applications to crash)

[Sergey Senozhatsky]

Hello,

On (01/30/18 11:48), Andrew Morton wrote:
> Subject: [Bug 198617] New: zswap causing random applications to crash
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=198617
> 
> Bug ID: 198617
>Summary: zswap causing random applications to crash
>Product: Memory Management
>Version: 2.5
> Kernel Version: 4.14.15
>   Hardware: x86-64
> OS: Linux
>   Tree: Mainline
> Status: NEW
>   Severity: normal
>   Priority: P1
>  Component: Page Allocator
>   Assignee: a...@linux-foundation.org
>   Reporter: kernel_...@dlk.pl
> Regression: No
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=104709
> https://bugs.kde.org/show_bug.cgi?id=389542
> 
> I did have zswap enabled for a long while, and a lot of wine games,
> plasmashell, xorg, kwin_x11 (and other) did crash randomly when reached 100% 
> of
> physical ram and swap was like almost never used.
> 
> I could esilly open a lot of browser tabs and the browser or xorg would fail
> every time.
> 
> After disabling zswap no crashes at all.
> 
> /etc/systemd/swap.conf
> zswap_enabled=1
> zswap_compressor=lz4  # lzo lz4
> zswap_max_pool_percent=25 # 1-99
> zswap_zpool=zbud  # zbud z3fold


So I did a number of tests and I confirm that under memory pressure
with frontswap enabled I do see segfaults and memory corruptions in
random user space applications.

kernel: urxvt[338]: segfault at 20 ip 7fc08889ae0d sp 7ffc73a7fc40 
error 6 in libc-2.26.so[7fc08881a000+1ae000]
 #0  0x7fc08889ae0d _int_malloc (libc.so.6)
 #1  0x7fc08889c2f3 malloc (libc.so.6)
 #2  0x560e6004bff7 _Z14rxvt_wcstoutf8PKwi (urxvt)
 #3  0x560e6005e75c n/a (urxvt)
 #4  0x560e6007d9f1 _ZN16rxvt_perl_interp6invokeEP9rxvt_term9hook_typez 
(urxvt)
 #5  0x560e6003d988 _ZN9rxvt_term9cmd_parseEv (urxvt)
 #6  0x560e60042804 _ZN9rxvt_term6pty_cbERN2ev2ioEi (urxvt)
 #7  0x560e6005c10f _Z17ev_invoke_pendingv (urxvt)
 #8  0x560e6005cb55 ev_run (urxvt)
 #9  0x560e6003b9b9 main (urxvt)
 #10 0x7fc08883af4a __libc_start_main (libc.so.6)
 #11 0x560e6003f9da _start (urxvt)

kernel: urxvt[343]: segfault at 10 ip 7fa56bd7d52b sp 7ffc09783a40 
error 4 in libc-2.26.so[7fa56bcfd000+1ae000]
 #0  0x7fa56bd7d52b _int_malloc (libc.so.6)
 #1  0x7fa56bd7f2f3 malloc (libc.so.6)
 #2  0x7fa56b3d6097 n/a (libxcb.so.1)
 #3  0x7fa56b3d64d8 n/a (libxcb.so.1)
 #4  0x7fa56c921b79 n/a (libX11.so.6)
 #5  0x7fa56c921ceb n/a (libX11.so.6)
 #6  0x7fa56c921fdd _XEventsQueued (libX11.so.6)
 #7  0x7fa56c913c49 XEventsQueued (libX11.so.6)
 #8  0x55b35cfc3262 _ZN12rxvt_display8flush_cbERN2ev7prepareEi (urxvt)
 #9  0x55b35cfc910f _Z17ev_invoke_pendingv (urxvt)
 #10 0x55b35cfc9c02 ev_run (urxvt)
 #11 0x55b35cfa89b9 main (urxvt)
 #12 0x7fa56bd1df4a __libc_start_main (libc.so.6)
 #13 0x55b35cfac9da _start (urxvt)

 Stack trace of thread 351:
 #0  0x7f5baaee7860 raise (libc.so.6)
 #1  0x7f5baaee8ec9 abort (libc.so.6)
 #2  0x7f5baaf30849 __malloc_assert (libc.so.6)
 #3  0x7f5baaf34011 _int_malloc (libc.so.6)
 #4  0x7f5baaf352f3 malloc (libc.so.6)
 #5  0x7f5baaf71cad __alloc_dir (libc.so.6)
 #6  0x7f5baaf71dbd opendir_tail (libc.so.6)
 #7  0x7f5bab5bbac4 Perl_pp_open_dir (libperl.so)
 #8  0x7f5bab55fec6 Perl_runops_standard (libperl.so)
 #9  0x7f5bab4d9390 Perl_call_sv (libperl.so)
 #10 0x5611f097e190 _ZN16rxvt_perl_interp6invokeEP9rxvt_term9hook_typez 
(urxvt)
 #11 0x5611f0947acb _ZN9rxvt_term14init_resourcesEiPKPKc (urxvt)
 #12 0x5611f0948da8 _ZN9rxvt_term5init2EiPKPKc (urxvt)
 #13 0x5611f097a0af n/a (urxvt)
 #14 0x7f5bab568259 Perl_pp_entersub (libperl.so)
 #15 0x7f5bab55fec6 Perl_runops_standard (libperl.so)
 #16 0x7f5bab4d9390 Perl_call_sv (libperl.so)
 #17 0x5611f097e190 _ZN16rxvt_perl_interp6invokeEP9rxvt_term9hook_typez 
(urxvt)
 #18 0x5611f0939a77 _ZN9rxvt_term9key_pressER9XKeyEvent (urxvt)
 #19 0x5611f093d77a _ZN9rxvt_term4x_cbER7_XEvent (urxvt)
 #20 0x5611f09572e8 _ZN12rxvt_display8flush_cbERN2ev7prepareEi (urxvt)
 #21 0x5611f095d10f _Z17ev_invoke_pendingv (urxvt)
 #22 0x5611f095dc02 ev_run (urxvt)
 #23 0x5611f093c9b9 main (urxvt)
 #24 0x7f5baaed3f4a __libc_start_main (libc.so.6)
 #25 0x5611f09409da _start (urxvt)


and so on.


However, the problem is not specific to 4.14.15 or 4.14.11.

I manages to track it down to 4.14 merge window, so we are basically
looking at 4.14-rc0+

The bisect log looks as follows:

git bisect start
# bad: [2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e] Linux 4.14-rc1
git bisect bad 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e
# good: [569dbb88e80deb68974ef6fdd6a13edb9d686261] Linux 4.13
git bisect good 569dbb88e80deb68974ef6fdd6a13edb9d686261
# good: [aae3dbb4776e7916b6cd442d00159bea27a695c1] Merge 

bisected bd4c82c22c367e is the first bad commit (was [Bug 198617] New: zswap causing random applications to crash)

[Sergey Senozhatsky]

Hello,

On (01/30/18 11:48), Andrew Morton wrote:
> Subject: [Bug 198617] New: zswap causing random applications to crash
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=198617
> 
> Bug ID: 198617
>Summary: zswap causing random applications to crash
>Product: Memory Management
>Version: 2.5
> Kernel Version: 4.14.15
>   Hardware: x86-64
> OS: Linux
>   Tree: Mainline
> Status: NEW
>   Severity: normal
>   Priority: P1
>  Component: Page Allocator
>   Assignee: a...@linux-foundation.org
>   Reporter: kernel_...@dlk.pl
> Regression: No
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=104709
> https://bugs.kde.org/show_bug.cgi?id=389542
> 
> I did have zswap enabled for a long while, and a lot of wine games,
> plasmashell, xorg, kwin_x11 (and other) did crash randomly when reached 100% 
> of
> physical ram and swap was like almost never used.
> 
> I could esilly open a lot of browser tabs and the browser or xorg would fail
> every time.
> 
> After disabling zswap no crashes at all.
> 
> /etc/systemd/swap.conf
> zswap_enabled=1
> zswap_compressor=lz4  # lzo lz4
> zswap_max_pool_percent=25 # 1-99
> zswap_zpool=zbud  # zbud z3fold


So I did a number of tests and I confirm that under memory pressure
with frontswap enabled I do see segfaults and memory corruptions in
random user space applications.

kernel: urxvt[338]: segfault at 20 ip 7fc08889ae0d sp 7ffc73a7fc40 
error 6 in libc-2.26.so[7fc08881a000+1ae000]
 #0  0x7fc08889ae0d _int_malloc (libc.so.6)
 #1  0x7fc08889c2f3 malloc (libc.so.6)
 #2  0x560e6004bff7 _Z14rxvt_wcstoutf8PKwi (urxvt)
 #3  0x560e6005e75c n/a (urxvt)
 #4  0x560e6007d9f1 _ZN16rxvt_perl_interp6invokeEP9rxvt_term9hook_typez 
(urxvt)
 #5  0x560e6003d988 _ZN9rxvt_term9cmd_parseEv (urxvt)
 #6  0x560e60042804 _ZN9rxvt_term6pty_cbERN2ev2ioEi (urxvt)
 #7  0x560e6005c10f _Z17ev_invoke_pendingv (urxvt)
 #8  0x560e6005cb55 ev_run (urxvt)
 #9  0x560e6003b9b9 main (urxvt)
 #10 0x7fc08883af4a __libc_start_main (libc.so.6)
 #11 0x560e6003f9da _start (urxvt)

kernel: urxvt[343]: segfault at 10 ip 7fa56bd7d52b sp 7ffc09783a40 
error 4 in libc-2.26.so[7fa56bcfd000+1ae000]
 #0  0x7fa56bd7d52b _int_malloc (libc.so.6)
 #1  0x7fa56bd7f2f3 malloc (libc.so.6)
 #2  0x7fa56b3d6097 n/a (libxcb.so.1)
 #3  0x7fa56b3d64d8 n/a (libxcb.so.1)
 #4  0x7fa56c921b79 n/a (libX11.so.6)
 #5  0x7fa56c921ceb n/a (libX11.so.6)
 #6  0x7fa56c921fdd _XEventsQueued (libX11.so.6)
 #7  0x7fa56c913c49 XEventsQueued (libX11.so.6)
 #8  0x55b35cfc3262 _ZN12rxvt_display8flush_cbERN2ev7prepareEi (urxvt)
 #9  0x55b35cfc910f _Z17ev_invoke_pendingv (urxvt)
 #10 0x55b35cfc9c02 ev_run (urxvt)
 #11 0x55b35cfa89b9 main (urxvt)
 #12 0x7fa56bd1df4a __libc_start_main (libc.so.6)
 #13 0x55b35cfac9da _start (urxvt)

 Stack trace of thread 351:
 #0  0x7f5baaee7860 raise (libc.so.6)
 #1  0x7f5baaee8ec9 abort (libc.so.6)
 #2  0x7f5baaf30849 __malloc_assert (libc.so.6)
 #3  0x7f5baaf34011 _int_malloc (libc.so.6)
 #4  0x7f5baaf352f3 malloc (libc.so.6)
 #5  0x7f5baaf71cad __alloc_dir (libc.so.6)
 #6  0x7f5baaf71dbd opendir_tail (libc.so.6)
 #7  0x7f5bab5bbac4 Perl_pp_open_dir (libperl.so)
 #8  0x7f5bab55fec6 Perl_runops_standard (libperl.so)
 #9  0x7f5bab4d9390 Perl_call_sv (libperl.so)
 #10 0x5611f097e190 _ZN16rxvt_perl_interp6invokeEP9rxvt_term9hook_typez 
(urxvt)
 #11 0x5611f0947acb _ZN9rxvt_term14init_resourcesEiPKPKc (urxvt)
 #12 0x5611f0948da8 _ZN9rxvt_term5init2EiPKPKc (urxvt)
 #13 0x5611f097a0af n/a (urxvt)
 #14 0x7f5bab568259 Perl_pp_entersub (libperl.so)
 #15 0x7f5bab55fec6 Perl_runops_standard (libperl.so)
 #16 0x7f5bab4d9390 Perl_call_sv (libperl.so)
 #17 0x5611f097e190 _ZN16rxvt_perl_interp6invokeEP9rxvt_term9hook_typez 
(urxvt)
 #18 0x5611f0939a77 _ZN9rxvt_term9key_pressER9XKeyEvent (urxvt)
 #19 0x5611f093d77a _ZN9rxvt_term4x_cbER7_XEvent (urxvt)
 #20 0x5611f09572e8 _ZN12rxvt_display8flush_cbERN2ev7prepareEi (urxvt)
 #21 0x5611f095d10f _Z17ev_invoke_pendingv (urxvt)
 #22 0x5611f095dc02 ev_run (urxvt)
 #23 0x5611f093c9b9 main (urxvt)
 #24 0x7f5baaed3f4a __libc_start_main (libc.so.6)
 #25 0x5611f09409da _start (urxvt)


and so on.


However, the problem is not specific to 4.14.15 or 4.14.11.

I manages to track it down to 4.14 merge window, so we are basically
looking at 4.14-rc0+

The bisect log looks as follows:

git bisect start
# bad: [2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e] Linux 4.14-rc1
git bisect bad 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e
# good: [569dbb88e80deb68974ef6fdd6a13edb9d686261] Linux 4.13
git bisect good 569dbb88e80deb68974ef6fdd6a13edb9d686261
# good: [aae3dbb4776e7916b6cd442d00159bea27a695c1] Merge 

[PATCH] pvcalls-back: do not return error on inet_accept EAGAIN

[Stefano Stabellini]

When the client sends a regular blocking accept request, the backend is
expected to return only when the accept is completed, simulating a
blocking behavior, or return an error.

Specifically, on EAGAIN from inet_accept, the backend shouldn't return
"EAGAIN" to the client. Instead, it should simply continue the wait.
Otherwise, the client will send another accept request, which will cause
another EAGAIN to be sent back, which is a waste of resources and not
conforming to the expected behavior. Change the behavior by turning the
"goto error" into a return.

Signed-off-by: Stefano Stabellini 

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index c7822d8..156e5ae 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -548,7 +548,7 @@ static void __pvcalls_back_accept(struct work_struct *work)
ret = inet_accept(mappass->sock, sock, O_NONBLOCK, true);
if (ret == -EAGAIN) {
sock_release(sock);
-   goto out_error;
+   return;
}
 
map = pvcalls_new_active_socket(fedata,

[PATCH] pvcalls-back: do not return error on inet_accept EAGAIN

[Stefano Stabellini]

When the client sends a regular blocking accept request, the backend is
expected to return only when the accept is completed, simulating a
blocking behavior, or return an error.

Specifically, on EAGAIN from inet_accept, the backend shouldn't return
"EAGAIN" to the client. Instead, it should simply continue the wait.
Otherwise, the client will send another accept request, which will cause
another EAGAIN to be sent back, which is a waste of resources and not
conforming to the expected behavior. Change the behavior by turning the
"goto error" into a return.

Signed-off-by: Stefano Stabellini 

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index c7822d8..156e5ae 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -548,7 +548,7 @@ static void __pvcalls_back_accept(struct work_struct *work)
ret = inet_accept(mappass->sock, sock, O_NONBLOCK, true);
if (ret == -EAGAIN) {
sock_release(sock);
-   goto out_error;
+   return;
}
 
map = pvcalls_new_active_socket(fedata,

Re: [PATCH 1/2] Documentation/memory-barriers.txt: cross-reference "tools/memory-model/"

[Paul E. McKenney]

On Fri, Feb 02, 2018 at 10:12:48AM +0100, Andrea Parri wrote:
> Recent efforts led to the specification of a memory consistency model
> for the Linux kernel [1], which "can (roughly speaking) be thought of
> as an automated version of memory-barriers.txt" and which is (in turn)
> "accompanied by extensive documentation on its use and its design".
> 
> Make sure that the (occasional) reader of memory-barriers.txt will be
> aware of these developments.
> 
> [1] https://marc.info/?l=linux-kernel=151687290114799=2
> 
> Signed-off-by: Andrea Parri 

I am inclined to pull in something along these lines, but would like
some feedback on the wording, especially how "official" we want to
make the memory model to be.

Thoughts?

If I don't hear otherwise in a couple of days, I will pull this as is.

Thanx, Paul

> ---
>  Documentation/memory-barriers.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/memory-barriers.txt 
> b/Documentation/memory-barriers.txt
> index a863009849a3b..8cc3f098f4a7d 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -17,7 +17,9 @@ meant as a guide to using the various memory barriers 
> provided by Linux, but
>  in case of any doubt (and there are many) please ask.
> 
>  To repeat, this document is not a specification of what Linux expects from
> -hardware.
> +hardware.  For such a specification, in the form of a memory consistency
> +model, and for documentation about its usage and its design, the reader is
> +referred to "tools/memory-model/".
> 
>  The purpose of this document is twofold:
> 
> -- 
> 2.7.4
> 

Re: [PATCH 1/2] Documentation/memory-barriers.txt: cross-reference "tools/memory-model/"

[Paul E. McKenney]

On Fri, Feb 02, 2018 at 10:12:48AM +0100, Andrea Parri wrote:
> Recent efforts led to the specification of a memory consistency model
> for the Linux kernel [1], which "can (roughly speaking) be thought of
> as an automated version of memory-barriers.txt" and which is (in turn)
> "accompanied by extensive documentation on its use and its design".
> 
> Make sure that the (occasional) reader of memory-barriers.txt will be
> aware of these developments.
> 
> [1] https://marc.info/?l=linux-kernel=151687290114799=2
> 
> Signed-off-by: Andrea Parri 

I am inclined to pull in something along these lines, but would like
some feedback on the wording, especially how "official" we want to
make the memory model to be.

Thoughts?

If I don't hear otherwise in a couple of days, I will pull this as is.

Thanx, Paul

> ---
>  Documentation/memory-barriers.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/memory-barriers.txt 
> b/Documentation/memory-barriers.txt
> index a863009849a3b..8cc3f098f4a7d 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -17,7 +17,9 @@ meant as a guide to using the various memory barriers 
> provided by Linux, but
>  in case of any doubt (and there are many) please ask.
> 
>  To repeat, this document is not a specification of what Linux expects from
> -hardware.
> +hardware.  For such a specification, in the form of a memory consistency
> +model, and for documentation about its usage and its design, the reader is
> +referred to "tools/memory-model/".
> 
>  The purpose of this document is twofold:
> 
> -- 
> 2.7.4
> 

[PATCH v4 4/5] irqchip/gic-v3-its: add ability to resend MAPC on resume

[Derek Basehore]

This adds functionality to resend the MAPC command to an ITS node on
resume. If the ITS is powered down during suspend and the collections
are not backed by memory, the ITS will lose that state. This just sets
up the known state for the collections after the ITS is restored.

This feature is enabled via Kconfig and a device tree entry.

Signed-off-by: Derek Basehore 
---
 arch/arm64/Kconfig   |  10 
 drivers/irqchip/irq-gic-v3-its.c | 101 ---
 2 files changed, 73 insertions(+), 38 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 53612879fe56..f38f1a7b4266 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -571,6 +571,16 @@ config HISILICON_ERRATUM_161600802
 
  If unsure, say Y.
 
+config ARM_GIC500_COLLECTIONS_RESET
+   bool "GIC-500 Collections: Workaround for GIC-500 Collections on 
suspend reset"
+   default y
+   help
+ The GIC-500 can store Collections state internally for the ITS. If
+ the ITS is reset on suspend (ie from power getting disabled), the
+ collections need to be reconfigured on resume.
+
+ If unsure, say Y.
+
 config QCOM_FALKOR_ERRATUM_E1041
bool "Falkor E1041: Speculative instruction fetches might cause errant 
memory access"
default y
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index e13515cdb68f..63764efa4dcc 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -48,6 +48,7 @@
 #define ITS_FLAGS_WORKAROUND_CAVIUM_22375  (1ULL << 1)
 #define ITS_FLAGS_WORKAROUND_CAVIUM_23144  (1ULL << 2)
 #define ITS_FLAGS_SAVE_SUSPEND_STATE   (1ULL << 3)
+#define ITS_FLAGS_WORKAROUND_GIC500_MAPC   (1ULL << 4)
 
 #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING(1 << 0)
 
@@ -1950,52 +1951,53 @@ static void its_cpu_init_lpis(void)
dsb(sy);
 }
 
-static void its_cpu_init_collection(void)
+static void its_cpu_init_collection(struct its_node *its)
 {
-   struct its_node *its;
-   int cpu;
-
-   spin_lock(_lock);
-   cpu = smp_processor_id();
-
-   list_for_each_entry(its, _nodes, entry) {
-   u64 target;
+   int cpu = smp_processor_id();
+   u64 target;
 
-   /* avoid cross node collections and its mapping */
-   if (its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_23144) {
-   struct device_node *cpu_node;
+   /* avoid cross node collections and its mapping */
+   if (its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_23144) {
+   struct device_node *cpu_node;
 
-   cpu_node = of_get_cpu_node(cpu, NULL);
-   if (its->numa_node != NUMA_NO_NODE &&
-   its->numa_node != of_node_to_nid(cpu_node))
-   continue;
-   }
+   cpu_node = of_get_cpu_node(cpu, NULL);
+   if (its->numa_node != NUMA_NO_NODE &&
+   its->numa_node != of_node_to_nid(cpu_node))
+   return;
+   }
 
+   /*
+* We now have to bind each collection to its target
+* redistributor.
+*/
+   if (gic_read_typer(its->base + GITS_TYPER) & GITS_TYPER_PTA) {
/*
-* We now have to bind each collection to its target
+* This ITS wants the physical address of the
 * redistributor.
 */
-   if (gic_read_typer(its->base + GITS_TYPER) & GITS_TYPER_PTA) {
-   /*
-* This ITS wants the physical address of the
-* redistributor.
-*/
-   target = gic_data_rdist()->phys_base;
-   } else {
-   /*
-* This ITS wants a linear CPU number.
-*/
-   target = gic_read_typer(gic_data_rdist_rd_base() + 
GICR_TYPER);
-   target = GICR_TYPER_CPU_NUMBER(target) << 16;
-   }
+   target = gic_data_rdist()->phys_base;
+   } else {
+   /* This ITS wants a linear CPU number. */
+   target = gic_read_typer(gic_data_rdist_rd_base() + GICR_TYPER);
+   target = GICR_TYPER_CPU_NUMBER(target) << 16;
+   }
 
-   /* Perform collection mapping */
-   its->collections[cpu].target_address = target;
-   its->collections[cpu].col_id = cpu;
+   /* Perform collection mapping */
+   its->collections[cpu].target_address = target;
+   its->collections[cpu].col_id = cpu;
 
-   its_send_mapc(its, >collections[cpu], 1);
-   its_send_invall(its, >collections[cpu]);
-   }
+   its_send_mapc(its, >collections[cpu], 1);
+   its_send_invall(its, >collections[cpu]);
+}
+
+static void 

[PATCH v4 4/5] irqchip/gic-v3-its: add ability to resend MAPC on resume

[Derek Basehore]

This adds functionality to resend the MAPC command to an ITS node on
resume. If the ITS is powered down during suspend and the collections
are not backed by memory, the ITS will lose that state. This just sets
up the known state for the collections after the ITS is restored.

This feature is enabled via Kconfig and a device tree entry.

Signed-off-by: Derek Basehore 
---
 arch/arm64/Kconfig   |  10 
 drivers/irqchip/irq-gic-v3-its.c | 101 ---
 2 files changed, 73 insertions(+), 38 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 53612879fe56..f38f1a7b4266 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -571,6 +571,16 @@ config HISILICON_ERRATUM_161600802
 
  If unsure, say Y.
 
+config ARM_GIC500_COLLECTIONS_RESET
+   bool "GIC-500 Collections: Workaround for GIC-500 Collections on 
suspend reset"
+   default y
+   help
+ The GIC-500 can store Collections state internally for the ITS. If
+ the ITS is reset on suspend (ie from power getting disabled), the
+ collections need to be reconfigured on resume.
+
+ If unsure, say Y.
+
 config QCOM_FALKOR_ERRATUM_E1041
bool "Falkor E1041: Speculative instruction fetches might cause errant 
memory access"
default y
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index e13515cdb68f..63764efa4dcc 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -48,6 +48,7 @@
 #define ITS_FLAGS_WORKAROUND_CAVIUM_22375  (1ULL << 1)
 #define ITS_FLAGS_WORKAROUND_CAVIUM_23144  (1ULL << 2)
 #define ITS_FLAGS_SAVE_SUSPEND_STATE   (1ULL << 3)
+#define ITS_FLAGS_WORKAROUND_GIC500_MAPC   (1ULL << 4)
 
 #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING(1 << 0)
 
@@ -1950,52 +1951,53 @@ static void its_cpu_init_lpis(void)
dsb(sy);
 }
 
-static void its_cpu_init_collection(void)
+static void its_cpu_init_collection(struct its_node *its)
 {
-   struct its_node *its;
-   int cpu;
-
-   spin_lock(_lock);
-   cpu = smp_processor_id();
-
-   list_for_each_entry(its, _nodes, entry) {
-   u64 target;
+   int cpu = smp_processor_id();
+   u64 target;
 
-   /* avoid cross node collections and its mapping */
-   if (its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_23144) {
-   struct device_node *cpu_node;
+   /* avoid cross node collections and its mapping */
+   if (its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_23144) {
+   struct device_node *cpu_node;
 
-   cpu_node = of_get_cpu_node(cpu, NULL);
-   if (its->numa_node != NUMA_NO_NODE &&
-   its->numa_node != of_node_to_nid(cpu_node))
-   continue;
-   }
+   cpu_node = of_get_cpu_node(cpu, NULL);
+   if (its->numa_node != NUMA_NO_NODE &&
+   its->numa_node != of_node_to_nid(cpu_node))
+   return;
+   }
 
+   /*
+* We now have to bind each collection to its target
+* redistributor.
+*/
+   if (gic_read_typer(its->base + GITS_TYPER) & GITS_TYPER_PTA) {
/*
-* We now have to bind each collection to its target
+* This ITS wants the physical address of the
 * redistributor.
 */
-   if (gic_read_typer(its->base + GITS_TYPER) & GITS_TYPER_PTA) {
-   /*
-* This ITS wants the physical address of the
-* redistributor.
-*/
-   target = gic_data_rdist()->phys_base;
-   } else {
-   /*
-* This ITS wants a linear CPU number.
-*/
-   target = gic_read_typer(gic_data_rdist_rd_base() + 
GICR_TYPER);
-   target = GICR_TYPER_CPU_NUMBER(target) << 16;
-   }
+   target = gic_data_rdist()->phys_base;
+   } else {
+   /* This ITS wants a linear CPU number. */
+   target = gic_read_typer(gic_data_rdist_rd_base() + GICR_TYPER);
+   target = GICR_TYPER_CPU_NUMBER(target) << 16;
+   }
 
-   /* Perform collection mapping */
-   its->collections[cpu].target_address = target;
-   its->collections[cpu].col_id = cpu;
+   /* Perform collection mapping */
+   its->collections[cpu].target_address = target;
+   its->collections[cpu].col_id = cpu;
 
-   its_send_mapc(its, >collections[cpu], 1);
-   its_send_invall(its, >collections[cpu]);
-   }
+   its_send_mapc(its, >collections[cpu], 1);
+   its_send_invall(its, >collections[cpu]);
+}
+
+static void 

[PATCH v4 2/5] irqchip/gic-v3-its: add ability to save/restore ITS state

[Derek Basehore]

Some platforms power off GIC logic in suspend, so we need to
save/restore state. The distributor and redistributor registers need
to be handled in platform code due to access permissions on those
registers, but the ITS registers can be restored in the kernel.

Signed-off-by: Derek Basehore 
---
 drivers/irqchip/irq-gic-v3-its.c | 101 +++
 1 file changed, 101 insertions(+)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 06f025fd5726..e13515cdb68f 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -46,6 +47,7 @@
 #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING  (1ULL << 0)
 #define ITS_FLAGS_WORKAROUND_CAVIUM_22375  (1ULL << 1)
 #define ITS_FLAGS_WORKAROUND_CAVIUM_23144  (1ULL << 2)
+#define ITS_FLAGS_SAVE_SUSPEND_STATE   (1ULL << 3)
 
 #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING(1 << 0)
 
@@ -83,6 +85,15 @@ struct its_baser {
u32 psz;
 };
 
+/*
+ * Saved ITS state - this is where saved state for the ITS is stored
+ * when it's disabled during system suspend.
+ */
+struct its_ctx {
+   u64 cbaser;
+   u32 ctlr;
+};
+
 struct its_device;
 
 /*
@@ -101,6 +112,7 @@ struct its_node {
struct its_collection   *collections;
struct fwnode_handle*fwnode_handle;
u64 (*get_msi_base)(struct its_device *its_dev);
+   struct its_ctx  its_ctx;
struct list_headits_device_list;
u64 flags;
unsigned long   list_nr;
@@ -3042,6 +3054,90 @@ static void its_enable_quirks(struct its_node *its)
gic_enable_quirks(iidr, its_quirks, its);
 }
 
+static int its_save_disable(void)
+{
+   struct its_node *its;
+   int err = 0;
+
+   spin_lock(_lock);
+   list_for_each_entry(its, _nodes, entry) {
+   struct its_ctx *ctx;
+   void __iomem *base;
+
+   if (!(its->flags & ITS_FLAGS_SAVE_SUSPEND_STATE))
+   continue;
+
+   ctx = >its_ctx;
+   base = its->base;
+   ctx->ctlr = readl_relaxed(base + GITS_CTLR);
+   err = its_force_quiescent(base);
+   if (err) {
+   pr_err("ITS failed to quiesce\n");
+   writel_relaxed(ctx->ctlr, base + GITS_CTLR);
+   goto err;
+   }
+
+   ctx->cbaser = gits_read_cbaser(base + GITS_CBASER);
+   }
+
+err:
+   if (err) {
+   list_for_each_entry_continue_reverse(its, _nodes, entry) {
+   if (its->flags & ITS_FLAGS_SAVE_SUSPEND_STATE) {
+   struct its_ctx *ctx = >its_ctx;
+   void __iomem *base = its->base;
+
+   writel_relaxed(ctx->ctlr, base + GITS_CTLR);
+   }
+   }
+   }
+
+   spin_unlock(_lock);
+
+   return err;
+}
+
+static void its_restore_enable(void)
+{
+   struct its_node *its;
+
+   spin_lock(_lock);
+   list_for_each_entry(its, _nodes, entry) {
+   if (its->flags & ITS_FLAGS_SAVE_SUSPEND_STATE) {
+   struct its_ctx *ctx = >its_ctx;
+   void __iomem *base = its->base;
+   /*
+* Only the lower 32 bits matter here since the upper 32
+* don't include any of the offset.
+*/
+   u32 creader = readl_relaxed(base + GITS_CREADR);
+   int i;
+
+   /*
+* Reset the write location to where the ITS is
+* currently at.
+*/
+   gits_write_cbaser(ctx->cbaser, base + GITS_CBASER);
+   gits_write_cwriter(creader, base + GITS_CWRITER);
+   its->cmd_write = >cmd_base[
+   creader / sizeof(struct its_cmd_block)];
+   /* Restore GITS_BASER from the value cache. */
+   for (i = 0; i < GITS_BASER_NR_REGS; i++) {
+   struct its_baser *baser = >tables[i];
+
+   its_write_baser(its, baser, baser->val);
+   }
+   writel_relaxed(ctx->ctlr, base + GITS_CTLR);
+   }
+   }
+   spin_unlock(_lock);
+}
+
+static struct syscore_ops its_syscore_ops = {
+   .suspend = its_save_disable,
+   .resume = its_restore_enable,
+};
+
 static int its_init_domain(struct fwnode_handle *handle, struct its_node *its)
 {
struct irq_domain *inner_domain;
@@ -3261,6 +3357,9 @@ static int __init its_probe_one(struct 

[PATCH v4 2/5] irqchip/gic-v3-its: add ability to save/restore ITS state

[Derek Basehore]

Some platforms power off GIC logic in suspend, so we need to
save/restore state. The distributor and redistributor registers need
to be handled in platform code due to access permissions on those
registers, but the ITS registers can be restored in the kernel.

Signed-off-by: Derek Basehore 
---
 drivers/irqchip/irq-gic-v3-its.c | 101 +++
 1 file changed, 101 insertions(+)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 06f025fd5726..e13515cdb68f 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -46,6 +47,7 @@
 #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING  (1ULL << 0)
 #define ITS_FLAGS_WORKAROUND_CAVIUM_22375  (1ULL << 1)
 #define ITS_FLAGS_WORKAROUND_CAVIUM_23144  (1ULL << 2)
+#define ITS_FLAGS_SAVE_SUSPEND_STATE   (1ULL << 3)
 
 #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING(1 << 0)
 
@@ -83,6 +85,15 @@ struct its_baser {
u32 psz;
 };
 
+/*
+ * Saved ITS state - this is where saved state for the ITS is stored
+ * when it's disabled during system suspend.
+ */
+struct its_ctx {
+   u64 cbaser;
+   u32 ctlr;
+};
+
 struct its_device;
 
 /*
@@ -101,6 +112,7 @@ struct its_node {
struct its_collection   *collections;
struct fwnode_handle*fwnode_handle;
u64 (*get_msi_base)(struct its_device *its_dev);
+   struct its_ctx  its_ctx;
struct list_headits_device_list;
u64 flags;
unsigned long   list_nr;
@@ -3042,6 +3054,90 @@ static void its_enable_quirks(struct its_node *its)
gic_enable_quirks(iidr, its_quirks, its);
 }
 
+static int its_save_disable(void)
+{
+   struct its_node *its;
+   int err = 0;
+
+   spin_lock(_lock);
+   list_for_each_entry(its, _nodes, entry) {
+   struct its_ctx *ctx;
+   void __iomem *base;
+
+   if (!(its->flags & ITS_FLAGS_SAVE_SUSPEND_STATE))
+   continue;
+
+   ctx = >its_ctx;
+   base = its->base;
+   ctx->ctlr = readl_relaxed(base + GITS_CTLR);
+   err = its_force_quiescent(base);
+   if (err) {
+   pr_err("ITS failed to quiesce\n");
+   writel_relaxed(ctx->ctlr, base + GITS_CTLR);
+   goto err;
+   }
+
+   ctx->cbaser = gits_read_cbaser(base + GITS_CBASER);
+   }
+
+err:
+   if (err) {
+   list_for_each_entry_continue_reverse(its, _nodes, entry) {
+   if (its->flags & ITS_FLAGS_SAVE_SUSPEND_STATE) {
+   struct its_ctx *ctx = >its_ctx;
+   void __iomem *base = its->base;
+
+   writel_relaxed(ctx->ctlr, base + GITS_CTLR);
+   }
+   }
+   }
+
+   spin_unlock(_lock);
+
+   return err;
+}
+
+static void its_restore_enable(void)
+{
+   struct its_node *its;
+
+   spin_lock(_lock);
+   list_for_each_entry(its, _nodes, entry) {
+   if (its->flags & ITS_FLAGS_SAVE_SUSPEND_STATE) {
+   struct its_ctx *ctx = >its_ctx;
+   void __iomem *base = its->base;
+   /*
+* Only the lower 32 bits matter here since the upper 32
+* don't include any of the offset.
+*/
+   u32 creader = readl_relaxed(base + GITS_CREADR);
+   int i;
+
+   /*
+* Reset the write location to where the ITS is
+* currently at.
+*/
+   gits_write_cbaser(ctx->cbaser, base + GITS_CBASER);
+   gits_write_cwriter(creader, base + GITS_CWRITER);
+   its->cmd_write = >cmd_base[
+   creader / sizeof(struct its_cmd_block)];
+   /* Restore GITS_BASER from the value cache. */
+   for (i = 0; i < GITS_BASER_NR_REGS; i++) {
+   struct its_baser *baser = >tables[i];
+
+   its_write_baser(its, baser, baser->val);
+   }
+   writel_relaxed(ctx->ctlr, base + GITS_CTLR);
+   }
+   }
+   spin_unlock(_lock);
+}
+
+static struct syscore_ops its_syscore_ops = {
+   .suspend = its_save_disable,
+   .resume = its_restore_enable,
+};
+
 static int its_init_domain(struct fwnode_handle *handle, struct its_node *its)
 {
struct irq_domain *inner_domain;
@@ -3261,6 +3357,9 @@ static int __init its_probe_one(struct resource *res,
  

[PATCH v4 5/5] DT/arm,gic-v3: add collections-reset-on-suspend property

[Derek Basehore]

This boolean property for the GIC-V3-ITS enables resending the MAP
COLLECTIONS commands when resuming for when the state is reset on
suspend.

Signed-off-by: Derek Basehore 
---
 Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt | 4 
 1 file changed, 4 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt 
b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
index a470147d4f14..adb958e046d2 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
@@ -81,6 +81,10 @@ Optional:
 - reset-on-suspend: Boolean property. Indicates that the ITS state is
   reset on suspend. The state is then saved on suspend and restored on
   resume.
+- collections-reset-on-suspend : Boolean property. If the collections for the
+  ITS are stored internally instead of externally, the state will be lost if 
the
+  GIC loses power. Setting this enables the kernel to reset the collections
+  state on resume for this ITS node.
 
 The main GIC node must contain the appropriate #address-cells,
 #size-cells and ranges properties for the reg property of all ITS
-- 
2.16.0.rc1.238.g530d649a79-goog

[PATCH v4 5/5] DT/arm,gic-v3: add collections-reset-on-suspend property

[Derek Basehore]

This boolean property for the GIC-V3-ITS enables resending the MAP
COLLECTIONS commands when resuming for when the state is reset on
suspend.

Signed-off-by: Derek Basehore 
---
 Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt | 4 
 1 file changed, 4 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt 
b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
index a470147d4f14..adb958e046d2 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
@@ -81,6 +81,10 @@ Optional:
 - reset-on-suspend: Boolean property. Indicates that the ITS state is
   reset on suspend. The state is then saved on suspend and restored on
   resume.
+- collections-reset-on-suspend : Boolean property. If the collections for the
+  ITS are stored internally instead of externally, the state will be lost if 
the
+  GIC loses power. Setting this enables the kernel to reset the collections
+  state on resume for this ITS node.
 
 The main GIC node must contain the appropriate #address-cells,
 #size-cells and ranges properties for the reg property of all ITS
-- 
2.16.0.rc1.238.g530d649a79-goog

[PATCH v4 3/5] DT/arm,gic-v3-its: add reset-on-suspend property

[Derek Basehore]

This adds documentation for the new reset-on-suspend property. This
property enables saving and restoring the ITS for when it loses state
in system suspend.

Signed-off-by: Derek Basehore 
---
 Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt 
b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
index 0a57f2f4167d..a470147d4f14 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
@@ -78,6 +78,9 @@ These nodes must have the following properties:
 Optional:
 - socionext,synquacer-pre-its: (u32, u32) tuple describing the untranslated
   address and size of the pre-ITS window.
+- reset-on-suspend: Boolean property. Indicates that the ITS state is
+  reset on suspend. The state is then saved on suspend and restored on
+  resume.
 
 The main GIC node must contain the appropriate #address-cells,
 #size-cells and ranges properties for the reg property of all ITS
-- 
2.16.0.rc1.238.g530d649a79-goog

[PATCH v4 3/5] DT/arm,gic-v3-its: add reset-on-suspend property

[Derek Basehore]

This adds documentation for the new reset-on-suspend property. This
property enables saving and restoring the ITS for when it loses state
in system suspend.

Signed-off-by: Derek Basehore 
---
 Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt 
b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
index 0a57f2f4167d..a470147d4f14 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
@@ -78,6 +78,9 @@ These nodes must have the following properties:
 Optional:
 - socionext,synquacer-pre-its: (u32, u32) tuple describing the untranslated
   address and size of the pre-ITS window.
+- reset-on-suspend: Boolean property. Indicates that the ITS state is
+  reset on suspend. The state is then saved on suspend and restored on
+  resume.
 
 The main GIC node must contain the appropriate #address-cells,
 #size-cells and ranges properties for the reg property of all ITS
-- 
2.16.0.rc1.238.g530d649a79-goog

[PATCH v4 1/5] cpu_pm: add syscore_suspend error handling

[Derek Basehore]

If cpu_cluster_pm_enter() fails, cpu_pm_exit() should be called. This
will put the CPU in the correct state to resume from the failure.

Signed-off-by: Derek Basehore 
---
 kernel/cpu_pm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/cpu_pm.c b/kernel/cpu_pm.c
index 67b02e138a47..03bcc0751a51 100644
--- a/kernel/cpu_pm.c
+++ b/kernel/cpu_pm.c
@@ -186,6 +186,9 @@ static int cpu_pm_suspend(void)
return ret;
 
ret = cpu_cluster_pm_enter();
+   if (ret)
+   cpu_pm_exit();
+
return ret;
 }
 
-- 
2.16.0.rc1.238.g530d649a79-goog

[PATCH v4 1/5] cpu_pm: add syscore_suspend error handling

[Derek Basehore]

If cpu_cluster_pm_enter() fails, cpu_pm_exit() should be called. This
will put the CPU in the correct state to resume from the failure.

Signed-off-by: Derek Basehore 
---
 kernel/cpu_pm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/cpu_pm.c b/kernel/cpu_pm.c
index 67b02e138a47..03bcc0751a51 100644
--- a/kernel/cpu_pm.c
+++ b/kernel/cpu_pm.c
@@ -186,6 +186,9 @@ static int cpu_pm_suspend(void)
return ret;
 
ret = cpu_cluster_pm_enter();
+   if (ret)
+   cpu_pm_exit();
+
return ret;
 }
 
-- 
2.16.0.rc1.238.g530d649a79-goog

[PATCH v4 0/5] GICv3 Save and Restore

[Derek Basehore]

A lot of changes in v2. The distributor and redistributor saving and
restoring is left to the PSCI/firmware implementation after
discussions with ARM. This reduces the line changes by a lot and
removes now unneeded patches.

Patches are verified on an RK3399 platform with pending patches in the
ARM-Trusted-Firmware project.

Just a couple minor changes in v3 to formatting.

Fixed a false ITS wedged detection due to the cmd_write and creadr
offsets not matching up on reset in v4. Also minor formatting changes.

Derek Basehore (5):
  cpu_pm: add syscore_suspend error handling
  irqchip/gic-v3-its: add ability to save/restore ITS state
  DT/arm,gic-v3-its: add reset-on-suspend property
  irqchip/gic-v3-its: add ability to resend MAPC on resume
  DT/arm,gic-v3: add collections-reset-on-suspend property

 .../bindings/interrupt-controller/arm,gic-v3.txt   |   7 +
 arch/arm64/Kconfig |  10 +
 drivers/irqchip/irq-gic-v3-its.c   | 202 +
 kernel/cpu_pm.c|   3 +
 4 files changed, 184 insertions(+), 38 deletions(-)

-- 
2.16.0.rc1.238.g530d649a79-goog

[PATCH v4 0/5] GICv3 Save and Restore

[Derek Basehore]

A lot of changes in v2. The distributor and redistributor saving and
restoring is left to the PSCI/firmware implementation after
discussions with ARM. This reduces the line changes by a lot and
removes now unneeded patches.

Patches are verified on an RK3399 platform with pending patches in the
ARM-Trusted-Firmware project.

Just a couple minor changes in v3 to formatting.

Fixed a false ITS wedged detection due to the cmd_write and creadr
offsets not matching up on reset in v4. Also minor formatting changes.

Derek Basehore (5):
  cpu_pm: add syscore_suspend error handling
  irqchip/gic-v3-its: add ability to save/restore ITS state
  DT/arm,gic-v3-its: add reset-on-suspend property
  irqchip/gic-v3-its: add ability to resend MAPC on resume
  DT/arm,gic-v3: add collections-reset-on-suspend property

 .../bindings/interrupt-controller/arm,gic-v3.txt   |   7 +
 arch/arm64/Kconfig |  10 +
 drivers/irqchip/irq-gic-v3-its.c   | 202 +
 kernel/cpu_pm.c|   3 +
 4 files changed, 184 insertions(+), 38 deletions(-)

-- 
2.16.0.rc1.238.g530d649a79-goog

cris-linux-ld: cannot open linker script file ./arch/cris/kernel/vmlinux.lds: No such file or directory

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   b89e32ccd1be92a3643df3908d3026b09e271616
commit: 0fbc0b67a89d756ae3a839be01440e54348159a0 cris: remove arch specific 
early DT functions
date:   3 days ago
config: cris-defconfig (attached as .config)
compiler: cris-linux-gcc (GCC) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 0fbc0b67a89d756ae3a839be01440e54348159a0
# save the attached .config to linux build tree
make.cross ARCH=cris 

All errors (new ones prefixed by >>):

>> cris-linux-ld: cannot open linker script file 
>> ./arch/cris/kernel/vmlinux.lds: No such file or directory

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

cris-linux-ld: cannot open linker script file ./arch/cris/kernel/vmlinux.lds: No such file or directory

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   b89e32ccd1be92a3643df3908d3026b09e271616
commit: 0fbc0b67a89d756ae3a839be01440e54348159a0 cris: remove arch specific 
early DT functions
date:   3 days ago
config: cris-defconfig (attached as .config)
compiler: cris-linux-gcc (GCC) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 0fbc0b67a89d756ae3a839be01440e54348159a0
# save the attached .config to linux build tree
make.cross ARCH=cris 

All errors (new ones prefixed by >>):

>> cris-linux-ld: cannot open linker script file 
>> ./arch/cris/kernel/vmlinux.lds: No such file or directory

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Inquiry about your product/ From exportersindia_ Awaiting your reply.

[noreply]

I am interested in your Product

i got your listing from exportersindia.com

we need large quantites of about 100pcs.

Pls send a mail for business discussions at kmike2...@gmail.com

so as to carryout orders and payment as soon as possibles.


Mike Kennedy
CEO
9037623258
USA
www.goodman.com

Inquiry about your product/ From exportersindia_ Awaiting your reply.

[noreply]

I am interested in your Product

i got your listing from exportersindia.com

we need large quantites of about 100pcs.

Pls send a mail for business discussions at kmike2...@gmail.com

so as to carryout orders and payment as soon as possibles.


Mike Kennedy
CEO
9037623258
USA
www.goodman.com

Re: [PATCH 2/2] MAINTAINERS: list file memory-barriers.txt within the LKMM entry

[Andrea Parri]

On Fri, Feb 02, 2018 at 03:51:02PM -0800, Paul E. McKenney wrote:
> On Fri, Feb 02, 2018 at 10:13:42AM +0100, Andrea Parri wrote:
> > Now that a formal specification of the LKMM has become available to
> > the developer, some concern about how to track changes to the model
> > on the level of the "high-level documentation" was raised.
> > 
> > A first "mitigation" to this issue, suggested by Will, is to assign
> > maintainership (and responsibility!!)  of such documentation (here,
> > memory-barriers.txt) to the maintainers of the LKMM themselves.
> > 
> > Suggested-by: Will Deacon 
> > Signed-off-by: Andrea Parri 
> 
> Very good, thank you, queued!  Please see below for the usual commit-log
> rework.  BTW, in future submissions, could you please capitalize the
> first word after the colon (":") in the subject line?  It is all too
> easy for me to forget to change this, as Ingo can attest.  ;-)

Sorry, I'll do my best! ;-)


> 
> If we are going to continue to use the LKMM acronym, should we make the
> first line of the MAINTAINERS block look something like this?

I've no strong opinion about whether we should, but it makes sense to me.
(The acronym is currently defined (and heavily used) in explanation.txt.)

Thanks,
  Andrea


> 
>   LINUX KERNEL MEMORY CONSISTENCY MODEL (LKMM)
> 
> One alternative would be to start calling it LKMCM, though that does
> look a bit like a Roman numeral.  ;-)
> 
>   Thanx, Paul
> 
> 
> 
> commit 2f80571625dc2d1977acdef79267ba1645b07c53
> Author: Andrea Parri 
> Date:   Fri Feb 2 10:13:42 2018 +0100
> 
> MAINTAINERS: List file memory-barriers.txt within the LKMM entry
> 
> We now have a shiny new Linux-kernel memory model (LKMM) and the old
> tried-and-true Documentation/memory-barrier.txt.  It would be good to
> keep these automatically synchronized, but in the meantime we need at
> least let people know that they are related.  Will suggested adding the
> Documentation/memory-barrier.txt file to the LKMM maintainership list,
> thus making the LKMM maintainers responsible for both the old and the new.
> This commit follows Will's excellent suggestion.
> 
> Suggested-by: Will Deacon 
> Signed-off-by: Andrea Parri 
> Signed-off-by: Paul E. McKenney 
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ba4dc08fbe95..e6ad9b44e8fb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8101,6 +8101,7 @@ L:  linux-kernel@vger.kernel.org
>  S:   Supported
>  T:   git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
>  F:   tools/memory-model/
> +F:   Documentation/memory-barriers.txt
>  
>  LINUX SECURITY MODULE (LSM) FRAMEWORK
>  M:   Chris Wright 
> 

Re: [PATCH 2/2] MAINTAINERS: list file memory-barriers.txt within the LKMM entry

[Andrea Parri]

On Fri, Feb 02, 2018 at 03:51:02PM -0800, Paul E. McKenney wrote:
> On Fri, Feb 02, 2018 at 10:13:42AM +0100, Andrea Parri wrote:
> > Now that a formal specification of the LKMM has become available to
> > the developer, some concern about how to track changes to the model
> > on the level of the "high-level documentation" was raised.
> > 
> > A first "mitigation" to this issue, suggested by Will, is to assign
> > maintainership (and responsibility!!)  of such documentation (here,
> > memory-barriers.txt) to the maintainers of the LKMM themselves.
> > 
> > Suggested-by: Will Deacon 
> > Signed-off-by: Andrea Parri 
> 
> Very good, thank you, queued!  Please see below for the usual commit-log
> rework.  BTW, in future submissions, could you please capitalize the
> first word after the colon (":") in the subject line?  It is all too
> easy for me to forget to change this, as Ingo can attest.  ;-)

Sorry, I'll do my best! ;-)


> 
> If we are going to continue to use the LKMM acronym, should we make the
> first line of the MAINTAINERS block look something like this?

I've no strong opinion about whether we should, but it makes sense to me.
(The acronym is currently defined (and heavily used) in explanation.txt.)

Thanks,
  Andrea


> 
>   LINUX KERNEL MEMORY CONSISTENCY MODEL (LKMM)
> 
> One alternative would be to start calling it LKMCM, though that does
> look a bit like a Roman numeral.  ;-)
> 
>   Thanx, Paul
> 
> 
> 
> commit 2f80571625dc2d1977acdef79267ba1645b07c53
> Author: Andrea Parri 
> Date:   Fri Feb 2 10:13:42 2018 +0100
> 
> MAINTAINERS: List file memory-barriers.txt within the LKMM entry
> 
> We now have a shiny new Linux-kernel memory model (LKMM) and the old
> tried-and-true Documentation/memory-barrier.txt.  It would be good to
> keep these automatically synchronized, but in the meantime we need at
> least let people know that they are related.  Will suggested adding the
> Documentation/memory-barrier.txt file to the LKMM maintainership list,
> thus making the LKMM maintainers responsible for both the old and the new.
> This commit follows Will's excellent suggestion.
> 
> Suggested-by: Will Deacon 
> Signed-off-by: Andrea Parri 
> Signed-off-by: Paul E. McKenney 
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ba4dc08fbe95..e6ad9b44e8fb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8101,6 +8101,7 @@ L:  linux-kernel@vger.kernel.org
>  S:   Supported
>  T:   git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
>  F:   tools/memory-model/
> +F:   Documentation/memory-barriers.txt
>  
>  LINUX SECURITY MODULE (LSM) FRAMEWORK
>  M:   Chris Wright 
> 

[GIT] Networking

[David Miller]

1) The bnx2x can hang if you give it a GSO packet with a segment size
   which is too big for the hardware, detect and drop in this case.
   From Daniel Axtens.

2) Fix some overflows and pointer leaks in xtables, from Dmitry
   Vyukov.

3) Missing RCU locking in igmp, from Eric Dumazet.

4) Fix RX checksum handling on r8152, it can only checksum UDP and
   TCP packets.  From Hayes Wang.

5) Minor pacing tweak to TCP BBR congestion control, from Neal
   Cardwell.

6) Missing RCU annotations in cls_u32, from Paolo Abeni.

Please pull, thanks a lot!
  

The following changes since commit 255442c93843f52b6891b21d0b485bf2c97f93c3:

  Merge tag 'docs-4.16' of git://git.lwn.net/linux (2018-01-31 19:25:25 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git 

for you to fetch changes up to edbe69ef2c90fc86998a74b08319a01c508bd497:

  Revert "defer call to mem_cgroup_sk_alloc()" (2018-02-02 19:49:31 -0500)


Alexander Monakov (1):
  net: pxa168_eth: add netconsole support

Arnd Bergmann (3):
  net: cxgb4: avoid memcpy beyond end of source buffer
  net: qed: use correct strncpy() size
  net: qlge: use memmove instead of skb_copy_to_linear_data

Christian Brauner (1):
  rtnetlink: remove check for IFLA_IF_NETNSID

Colin Ian King (4):
  be2net: remove redundant initialization of 'head' and pointer txq
  net: jme: remove unused initialization of 'rxdesc'
  lan78xx: remove redundant initialization of pointer 'phydev'
  vmxnet3: remove redundant initialization of pointer 'rq'

Daniel Axtens (2):
  net: create skb_gso_validate_mac_len()
  bnx2x: disable GSO where gso_size is too big for hardware

David S. Miller (3):
  Merge branch 'bnx2x-disable-GSO-on-too-large-packets'
  Merge git://git.kernel.org/.../pablo/nf
  Merge branch 'r8152-fix-rx-issues'

Desnes Augusto Nunes do Rosario (1):
  ibmvnic: fix firmware version when no firmware level has been provided by 
the VIOS server

Dmitry Vyukov (3):
  netfilter: x_tables: fix int overflow in xt_alloc_table_info()
  netfilter: x_tables: fix pointer leaks to userspace
  netfilter: ipt_CLUSTERIP: fix out-of-bounds accesses in 
clusterip_tg_check()

Ed Swierk (1):
  openvswitch: Remove padding from packet before L3+ conntrack processing

Edwin Peer (1):
  nfp: fix TLV offset calculation

Eric Dumazet (3):
  netfilter: x_tables: avoid out-of-bounds reads in 
xt_request_find_{match|target}
  net: igmp: add a missing rcu locking section
  soreuseport: fix mem leak in reuseport_add_sock()

Geert Uytterhoeven (2):
  net: bridge: Fix uninitialized error in br_fdb_sync_static()
  inet: Avoid unitialized variable warning in inet_unhash()

Hayes Wang (2):
  r8152: fix wrong checksum status for received IPv4 packets
  r8152: set rx mode early when linking on

Jiri Pirko (1):
  rocker: fix possible null pointer dereference in 
rocker_router_fib_event_work

Jozsef Kadlecsik (1):
  netfilter: ipset: Fix wraparound in hash:*net* types

Neal Cardwell (1):
  tcp_bbr: fix pacing_gain to always be unity when using lt_bw

Paolo Abeni (2):
  netfilter: on sockopt() acquire sock lock only in the required scope
  cls_u32: add missing RCU annotation.

Roman Gushchin (1):
  Revert "defer call to mem_cgroup_sk_alloc()"

 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c  | 18 ++
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h|  2 +-
 drivers/net/ethernet/emulex/benet/be_main.c   |  3 +--
 drivers/net/ethernet/ibm/ibmvnic.c|  6 +-
 drivers/net/ethernet/jme.c|  2 +-
 drivers/net/ethernet/marvell/pxa168_eth.c | 12 
 drivers/net/ethernet/netronome/nfp/nfp_net_ctrl.c |  2 +-
 drivers/net/ethernet/qlogic/qed/qed_debug.c   |  6 ++
 drivers/net/ethernet/qlogic/qlge/qlge_main.c  |  3 +--
 drivers/net/ethernet/rocker/rocker_main.c | 18 +-
 drivers/net/usb/lan78xx.c |  2 +-
 drivers/net/usb/r8152.c   | 13 ++---
 drivers/net/vmxnet3/vmxnet3_drv.c |  6 ++
 include/linux/skbuff.h| 16 
 mm/memcontrol.c   | 14 ++
 net/bridge/br_fdb.c   |  2 +-
 net/core/rtnetlink.c  |  3 ---
 net/core/skbuff.c | 63 
++-
 net/core/sock.c   |  5 +
 net/core/sock_reuseport.c | 35 
---
 net/ipv4/igmp.c   |  4 
 net/ipv4/inet_connection_sock.c   |  1 -
 net/ipv4/inet_hashtables.c|  6 ++
 

[GIT] Networking

[David Miller]

1) The bnx2x can hang if you give it a GSO packet with a segment size
   which is too big for the hardware, detect and drop in this case.
   From Daniel Axtens.

2) Fix some overflows and pointer leaks in xtables, from Dmitry
   Vyukov.

3) Missing RCU locking in igmp, from Eric Dumazet.

4) Fix RX checksum handling on r8152, it can only checksum UDP and
   TCP packets.  From Hayes Wang.

5) Minor pacing tweak to TCP BBR congestion control, from Neal
   Cardwell.

6) Missing RCU annotations in cls_u32, from Paolo Abeni.

Please pull, thanks a lot!
  

The following changes since commit 255442c93843f52b6891b21d0b485bf2c97f93c3:

  Merge tag 'docs-4.16' of git://git.lwn.net/linux (2018-01-31 19:25:25 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git 

for you to fetch changes up to edbe69ef2c90fc86998a74b08319a01c508bd497:

  Revert "defer call to mem_cgroup_sk_alloc()" (2018-02-02 19:49:31 -0500)


Alexander Monakov (1):
  net: pxa168_eth: add netconsole support

Arnd Bergmann (3):
  net: cxgb4: avoid memcpy beyond end of source buffer
  net: qed: use correct strncpy() size
  net: qlge: use memmove instead of skb_copy_to_linear_data

Christian Brauner (1):
  rtnetlink: remove check for IFLA_IF_NETNSID

Colin Ian King (4):
  be2net: remove redundant initialization of 'head' and pointer txq
  net: jme: remove unused initialization of 'rxdesc'
  lan78xx: remove redundant initialization of pointer 'phydev'
  vmxnet3: remove redundant initialization of pointer 'rq'

Daniel Axtens (2):
  net: create skb_gso_validate_mac_len()
  bnx2x: disable GSO where gso_size is too big for hardware

David S. Miller (3):
  Merge branch 'bnx2x-disable-GSO-on-too-large-packets'
  Merge git://git.kernel.org/.../pablo/nf
  Merge branch 'r8152-fix-rx-issues'

Desnes Augusto Nunes do Rosario (1):
  ibmvnic: fix firmware version when no firmware level has been provided by 
the VIOS server

Dmitry Vyukov (3):
  netfilter: x_tables: fix int overflow in xt_alloc_table_info()
  netfilter: x_tables: fix pointer leaks to userspace
  netfilter: ipt_CLUSTERIP: fix out-of-bounds accesses in 
clusterip_tg_check()

Ed Swierk (1):
  openvswitch: Remove padding from packet before L3+ conntrack processing

Edwin Peer (1):
  nfp: fix TLV offset calculation

Eric Dumazet (3):
  netfilter: x_tables: avoid out-of-bounds reads in 
xt_request_find_{match|target}
  net: igmp: add a missing rcu locking section
  soreuseport: fix mem leak in reuseport_add_sock()

Geert Uytterhoeven (2):
  net: bridge: Fix uninitialized error in br_fdb_sync_static()
  inet: Avoid unitialized variable warning in inet_unhash()

Hayes Wang (2):
  r8152: fix wrong checksum status for received IPv4 packets
  r8152: set rx mode early when linking on

Jiri Pirko (1):
  rocker: fix possible null pointer dereference in 
rocker_router_fib_event_work

Jozsef Kadlecsik (1):
  netfilter: ipset: Fix wraparound in hash:*net* types

Neal Cardwell (1):
  tcp_bbr: fix pacing_gain to always be unity when using lt_bw

Paolo Abeni (2):
  netfilter: on sockopt() acquire sock lock only in the required scope
  cls_u32: add missing RCU annotation.

Roman Gushchin (1):
  Revert "defer call to mem_cgroup_sk_alloc()"

 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c  | 18 ++
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h|  2 +-
 drivers/net/ethernet/emulex/benet/be_main.c   |  3 +--
 drivers/net/ethernet/ibm/ibmvnic.c|  6 +-
 drivers/net/ethernet/jme.c|  2 +-
 drivers/net/ethernet/marvell/pxa168_eth.c | 12 
 drivers/net/ethernet/netronome/nfp/nfp_net_ctrl.c |  2 +-
 drivers/net/ethernet/qlogic/qed/qed_debug.c   |  6 ++
 drivers/net/ethernet/qlogic/qlge/qlge_main.c  |  3 +--
 drivers/net/ethernet/rocker/rocker_main.c | 18 +-
 drivers/net/usb/lan78xx.c |  2 +-
 drivers/net/usb/r8152.c   | 13 ++---
 drivers/net/vmxnet3/vmxnet3_drv.c |  6 ++
 include/linux/skbuff.h| 16 
 mm/memcontrol.c   | 14 ++
 net/bridge/br_fdb.c   |  2 +-
 net/core/rtnetlink.c  |  3 ---
 net/core/skbuff.c | 63 
++-
 net/core/sock.c   |  5 +
 net/core/sock_reuseport.c | 35 
---
 net/ipv4/igmp.c   |  4 
 net/ipv4/inet_connection_sock.c   |  1 -
 net/ipv4/inet_hashtables.c|  6 ++
 

Re: [GIT PULL] pin control bulk changes for v4.16

[Linus Torvalds]

On Fri, Feb 2, 2018 at 4:44 PM, Linus Torvalds
 wrote:
>
> Stupid patch attached. I don't know how much this helps the insane
> dependency hell for , but it's bound to help
> _some_.

Testing it, that patch definitely cuts down on recompiles after

 touch include/linux/pinctrl/devinfo.h

a lot.

It still ends up rebuilding a fair amount of odd drivers, but now the
files it rebuilds at least make _some_ sense.

It used to really rebuild just about everything (because pretty much
everything includes ). Now it rebuilds various snd/soc
files,gpio stuff and mmc/mfc stuff.

I'm sure it could be improved upon still, but I think this is already
a fairly noticeable improvement.

One odd header include down. Ten million to go.

 Linus

Re: [GIT PULL] pin control bulk changes for v4.16

[Linus Torvalds]

On Fri, Feb 2, 2018 at 4:44 PM, Linus Torvalds
 wrote:
>
> Stupid patch attached. I don't know how much this helps the insane
> dependency hell for , but it's bound to help
> _some_.

Testing it, that patch definitely cuts down on recompiles after

 touch include/linux/pinctrl/devinfo.h

a lot.

It still ends up rebuilding a fair amount of odd drivers, but now the
files it rebuilds at least make _some_ sense.

It used to really rebuild just about everything (because pretty much
everything includes ). Now it rebuilds various snd/soc
files,gpio stuff and mmc/mfc stuff.

I'm sure it could be improved upon still, but I think this is already
a fairly noticeable improvement.

One odd header include down. Ten million to go.

 Linus

[PATCH v7 5/5] iommu/vt-d: Add debugfs support for Interrupt remapping

[Sohil Mehta]

Debugfs extension for Intel IOMMU to dump Interrupt remapping table
entries for Interrupt remapping and Interrupt posting.

The file /sys/kernel/debug/intel_iommu/ir_translation_struct provides
detailed information, such as Index, Source Id, Destination Id, Vector
and the IRTE values for entries with the present bit set, in the format
shown.

Remapped Interrupt supported on IOMMU: dmar7
 IR table address:85e50
 Index  SrcID DstIDVct IRTE_highIRTE_low
 1  f0f8  0100 30  0004f0f8 013d
 7  f0f8  0400 22  0004f0f8 0422000d

Posted Interrupt supported on IOMMU: dmar5
 IR table address:85ec0
 Index  SrcID PDA_high PDA_low  Vct IRTE_high   IRTE_low
 4  4300  000f ff765980 41  000f00044300ff76598000418001
 5  4300  000f ff765980 51  000f00044300ff76598000518001

Cc: Jacob Pan 
Cc: Fenghua Yu 
Cc: Ashok Raj 
Co-Developed-by: Gayatri Kammela 
Signed-off-by: Gayatri Kammela 
Signed-off-by: Sohil Mehta 
---

v7: Print the IR table physical base address
Simplify IR table formatting

v6: Change a couple of seq_puts to seq_putc

v5: Fix seq_puts formatting and remove leading '\n's

v4: Remove the unused function parameter
Fix checkpatch.pl warnings
Remove error reporting for debugfs_create_file function
Remove redundant IOMMU null check under for_each_active_iommu

v3: Use a macro for seq file operations 
Change the intel_iommu_interrupt_remap file name to ir_translation_struct

v2: Handle the case when IR is not enabled. Fix seq_printf formatting

 drivers/iommu/intel-iommu-debug.c | 94 +++
 1 file changed, 94 insertions(+)

diff --git a/drivers/iommu/intel-iommu-debug.c 
b/drivers/iommu/intel-iommu-debug.c
index a9a99aa..b66a073 100644
--- a/drivers/iommu/intel-iommu-debug.c
+++ b/drivers/iommu/intel-iommu-debug.c
@@ -229,6 +229,96 @@ static int iommu_regset_show(struct seq_file *m, void 
*unused)
 }
 DEFINE_SHOW_ATTRIBUTE(iommu_regset);
 
+#ifdef CONFIG_IRQ_REMAP
+static void ir_tbl_remap_entry_show(struct seq_file *m,
+   struct intel_iommu *iommu)
+{
+   struct irte *ri_entry;
+   int idx;
+
+   seq_puts(m, " Index  SrcID DstIDVct IRTE_high\t\tIRTE_low\n");
+
+   for (idx = 0; idx < INTR_REMAP_TABLE_ENTRIES; idx++) {
+   ri_entry = >ir_table->base[idx];
+   if (!ri_entry->present || ri_entry->p_pst)
+   continue;
+
+   seq_printf(m, " %d\t%04x  %08x %02x  %016llx\t%016llx\n", idx,
+  ri_entry->sid, ri_entry->dest_id, ri_entry->vector,
+  ri_entry->high, ri_entry->low);
+   }
+}
+
+static void ir_tbl_posted_entry_show(struct seq_file *m,
+struct intel_iommu *iommu)
+{
+   struct irte *pi_entry;
+   int idx;
+
+   seq_puts(m, " Index  SrcID PDA_high PDA_low  Vct 
IRTE_high\t\tIRTE_low\n");
+
+   for (idx = 0; idx < INTR_REMAP_TABLE_ENTRIES; idx++) {
+   pi_entry = >ir_table->base[idx];
+   if (!pi_entry->present || !pi_entry->p_pst)
+   continue;
+
+   seq_printf(m, " %d\t%04x  %08x %08x %02x  %016llx\t%016llx\n",
+  idx, pi_entry->sid, pi_entry->pda_h,
+  pi_entry->pda_l << 6, pi_entry->vector,
+  pi_entry->high, pi_entry->low);
+   }
+}
+
+/*
+ * For active IOMMUs go through the Interrupt remapping
+ * table and print valid entries in a table format for
+ * Remapped and Posted Interrupts.
+ */
+static int ir_translation_struct_show(struct seq_file *m, void *unused)
+{
+   struct dmar_drhd_unit *drhd;
+   struct intel_iommu *iommu;
+   u64 irta;
+
+   rcu_read_lock();
+   for_each_active_iommu(iommu, drhd) {
+   if (!ecap_ir_support(iommu->ecap))
+   continue;
+
+   irta = dmar_readq(iommu->reg + DMAR_IRTA_REG) & VTD_PAGE_MASK;
+   seq_printf(m, "Remapped Interrupt supported on IOMMU: %s\n"
+ " IR table address:%llx\n", iommu->name, irta);
+
+   if (iommu->ir_table && irta)
+   ir_tbl_remap_entry_show(m, iommu);
+   else
+   seq_puts(m, "Interrupt Remapping is not enabled\n");
+   seq_putc(m, '\n');
+   }
+
+   seq_puts(m, "\n\n");
+
+   for_each_active_iommu(iommu, drhd) {
+   if (!cap_pi_support(iommu->cap))
+   continue;
+
+   irta = dmar_readq(iommu->reg + DMAR_IRTA_REG) & VTD_PAGE_MASK;
+   seq_printf(m, "Posted Interrupt supported on IOMMU: %s\n"
+ " IR table 

[PATCH v7 5/5] iommu/vt-d: Add debugfs support for Interrupt remapping

[Sohil Mehta]

Debugfs extension for Intel IOMMU to dump Interrupt remapping table
entries for Interrupt remapping and Interrupt posting.

The file /sys/kernel/debug/intel_iommu/ir_translation_struct provides
detailed information, such as Index, Source Id, Destination Id, Vector
and the IRTE values for entries with the present bit set, in the format
shown.

Remapped Interrupt supported on IOMMU: dmar7
 IR table address:85e50
 Index  SrcID DstIDVct IRTE_highIRTE_low
 1  f0f8  0100 30  0004f0f8 013d
 7  f0f8  0400 22  0004f0f8 0422000d

Posted Interrupt supported on IOMMU: dmar5
 IR table address:85ec0
 Index  SrcID PDA_high PDA_low  Vct IRTE_high   IRTE_low
 4  4300  000f ff765980 41  000f00044300ff76598000418001
 5  4300  000f ff765980 51  000f00044300ff76598000518001

Cc: Jacob Pan 
Cc: Fenghua Yu 
Cc: Ashok Raj 
Co-Developed-by: Gayatri Kammela 
Signed-off-by: Gayatri Kammela 
Signed-off-by: Sohil Mehta 
---

v7: Print the IR table physical base address
Simplify IR table formatting

v6: Change a couple of seq_puts to seq_putc

v5: Fix seq_puts formatting and remove leading '\n's

v4: Remove the unused function parameter
Fix checkpatch.pl warnings
Remove error reporting for debugfs_create_file function
Remove redundant IOMMU null check under for_each_active_iommu

v3: Use a macro for seq file operations 
Change the intel_iommu_interrupt_remap file name to ir_translation_struct

v2: Handle the case when IR is not enabled. Fix seq_printf formatting

 drivers/iommu/intel-iommu-debug.c | 94 +++
 1 file changed, 94 insertions(+)

diff --git a/drivers/iommu/intel-iommu-debug.c 
b/drivers/iommu/intel-iommu-debug.c
index a9a99aa..b66a073 100644
--- a/drivers/iommu/intel-iommu-debug.c
+++ b/drivers/iommu/intel-iommu-debug.c
@@ -229,6 +229,96 @@ static int iommu_regset_show(struct seq_file *m, void 
*unused)
 }
 DEFINE_SHOW_ATTRIBUTE(iommu_regset);
 
+#ifdef CONFIG_IRQ_REMAP
+static void ir_tbl_remap_entry_show(struct seq_file *m,
+   struct intel_iommu *iommu)
+{
+   struct irte *ri_entry;
+   int idx;
+
+   seq_puts(m, " Index  SrcID DstIDVct IRTE_high\t\tIRTE_low\n");
+
+   for (idx = 0; idx < INTR_REMAP_TABLE_ENTRIES; idx++) {
+   ri_entry = >ir_table->base[idx];
+   if (!ri_entry->present || ri_entry->p_pst)
+   continue;
+
+   seq_printf(m, " %d\t%04x  %08x %02x  %016llx\t%016llx\n", idx,
+  ri_entry->sid, ri_entry->dest_id, ri_entry->vector,
+  ri_entry->high, ri_entry->low);
+   }
+}
+
+static void ir_tbl_posted_entry_show(struct seq_file *m,
+struct intel_iommu *iommu)
+{
+   struct irte *pi_entry;
+   int idx;
+
+   seq_puts(m, " Index  SrcID PDA_high PDA_low  Vct 
IRTE_high\t\tIRTE_low\n");
+
+   for (idx = 0; idx < INTR_REMAP_TABLE_ENTRIES; idx++) {
+   pi_entry = >ir_table->base[idx];
+   if (!pi_entry->present || !pi_entry->p_pst)
+   continue;
+
+   seq_printf(m, " %d\t%04x  %08x %08x %02x  %016llx\t%016llx\n",
+  idx, pi_entry->sid, pi_entry->pda_h,
+  pi_entry->pda_l << 6, pi_entry->vector,
+  pi_entry->high, pi_entry->low);
+   }
+}
+
+/*
+ * For active IOMMUs go through the Interrupt remapping
+ * table and print valid entries in a table format for
+ * Remapped and Posted Interrupts.
+ */
+static int ir_translation_struct_show(struct seq_file *m, void *unused)
+{
+   struct dmar_drhd_unit *drhd;
+   struct intel_iommu *iommu;
+   u64 irta;
+
+   rcu_read_lock();
+   for_each_active_iommu(iommu, drhd) {
+   if (!ecap_ir_support(iommu->ecap))
+   continue;
+
+   irta = dmar_readq(iommu->reg + DMAR_IRTA_REG) & VTD_PAGE_MASK;
+   seq_printf(m, "Remapped Interrupt supported on IOMMU: %s\n"
+ " IR table address:%llx\n", iommu->name, irta);
+
+   if (iommu->ir_table && irta)
+   ir_tbl_remap_entry_show(m, iommu);
+   else
+   seq_puts(m, "Interrupt Remapping is not enabled\n");
+   seq_putc(m, '\n');
+   }
+
+   seq_puts(m, "\n\n");
+
+   for_each_active_iommu(iommu, drhd) {
+   if (!cap_pi_support(iommu->cap))
+   continue;
+
+   irta = dmar_readq(iommu->reg + DMAR_IRTA_REG) & VTD_PAGE_MASK;
+   seq_printf(m, "Posted Interrupt supported on IOMMU: %s\n"
+ " IR table address:%llx\n", iommu->name, irta);
+
+   if (iommu->ir_table && irta)
+   ir_tbl_posted_entry_show(m, iommu);
+   else

[PATCH v7 3/5] iommu/vt-d: Add debugfs support to show register contents

[Sohil Mehta]

From: Gayatri Kammela 

Debugfs extension to dump all the register contents for each IOMMU
device to the user space via debugfs.

Example:
root@OTC-KBLH-01:~# cat /sys/kernel/debug/intel_iommu/iommu_regset
DMAR: dmar0: Register Base Address fed9
NameOffset  Contents
VER 0x000x0010
CAP 0x080x01cc40660462
ECAP0x100x00f0101a
GCMD0x180x
GSTS0x1c0xc700
RTADDR  0x200x0004071d3800
CCMD0x280x0800
FSTS0x340x
FECTL   0x380x
FEDATA  0x3c0xfee010044021

Cc: Fenghua Yu 
Cc: Jacob Pan 
Cc: Ashok Raj 
Co-Developed-by: Sohil Mehta 
Signed-off-by: Sohil Mehta 
Signed-off-by: Gayatri Kammela 
---

v7: Use macro for register set definitions
Fix compiler warning for readq with 32bit architecture
Remove leading '\n'

v6: No change

v5: No change

v4: Fix checkpatch.pl warnings
Remove error reporting for debugfs_create_file function
Remove redundant IOMMU null check under for_each_active_iommu

v3: Use a macro for seq file operations 
Change the intel_iommu_regset file name to iommu_regset
Add information for MTRR registers

v2: Fix seq_printf formatting

 drivers/iommu/intel-iommu-debug.c | 84 +++
 include/linux/intel-iommu.h   |  2 +
 2 files changed, 86 insertions(+)

diff --git a/drivers/iommu/intel-iommu-debug.c 
b/drivers/iommu/intel-iommu-debug.c
index 8253503..38651ad 100644
--- a/drivers/iommu/intel-iommu-debug.c
+++ b/drivers/iommu/intel-iommu-debug.c
@@ -38,6 +38,49 @@ static const struct file_operations __name ## _fops =
\
.owner  = THIS_MODULE,  \
 }
 
+struct iommu_regset {
+   int offset;
+   const char *regs;
+};
+
+#define IOMMU_REGSET_ENTRY(_reg_)  \
+   { DMAR_##_reg_##_REG, __stringify(_reg_) }
+static const struct iommu_regset iommu_regs[] = {
+   IOMMU_REGSET_ENTRY(VER),
+   IOMMU_REGSET_ENTRY(CAP),
+   IOMMU_REGSET_ENTRY(ECAP),
+   IOMMU_REGSET_ENTRY(GCMD),
+   IOMMU_REGSET_ENTRY(GSTS),
+   IOMMU_REGSET_ENTRY(RTADDR),
+   IOMMU_REGSET_ENTRY(CCMD),
+   IOMMU_REGSET_ENTRY(FSTS),
+   IOMMU_REGSET_ENTRY(FECTL),
+   IOMMU_REGSET_ENTRY(FEDATA),
+   IOMMU_REGSET_ENTRY(FEADDR),
+   IOMMU_REGSET_ENTRY(FEUADDR),
+   IOMMU_REGSET_ENTRY(AFLOG),
+   IOMMU_REGSET_ENTRY(PMEN),
+   IOMMU_REGSET_ENTRY(PLMBASE),
+   IOMMU_REGSET_ENTRY(PLMLIMIT),
+   IOMMU_REGSET_ENTRY(PHMBASE),
+   IOMMU_REGSET_ENTRY(PHMLIMIT),
+   IOMMU_REGSET_ENTRY(IQH),
+   IOMMU_REGSET_ENTRY(IQT),
+   IOMMU_REGSET_ENTRY(IQA),
+   IOMMU_REGSET_ENTRY(ICS),
+   IOMMU_REGSET_ENTRY(IRTA),
+   IOMMU_REGSET_ENTRY(PQH),
+   IOMMU_REGSET_ENTRY(PQT),
+   IOMMU_REGSET_ENTRY(PQA),
+   IOMMU_REGSET_ENTRY(PRS),
+   IOMMU_REGSET_ENTRY(PECTL),
+   IOMMU_REGSET_ENTRY(PEDATA),
+   IOMMU_REGSET_ENTRY(PEADDR),
+   IOMMU_REGSET_ENTRY(PEUADDR),
+   IOMMU_REGSET_ENTRY(MTRRCAP),
+   IOMMU_REGSET_ENTRY(MTRRDEF)
+};
+
 static void ctx_tbl_entry_show(struct seq_file *m, struct intel_iommu *iommu,
   int bus, bool ext)
 {
@@ -116,6 +159,45 @@ static int dmar_translation_struct_show(struct seq_file 
*m, void *unused)
 }
 DEFINE_SHOW_ATTRIBUTE(dmar_translation_struct);
 
+static int iommu_regset_show(struct seq_file *m, void *unused)
+{
+   struct dmar_drhd_unit *drhd;
+   struct intel_iommu *iommu;
+   unsigned long long base;
+   int i, ret = 0;
+   u64 value;
+
+   rcu_read_lock();
+   for_each_active_iommu(iommu, drhd) {
+   if (!drhd->reg_base_addr) {
+   seq_puts(m, "IOMMU: Invalid base address\n");
+   ret = -EINVAL;
+   goto out;
+   }
+
+   base = drhd->reg_base_addr;
+   seq_printf(m, "DMAR: %s: Register Base Address %llx\n",
+  iommu->name, base);
+   seq_puts(m, "Name\t\t\tOffset\t\tContents\n");
+   /*
+* Publish the contents of the 64-bit hardware registers
+* by adding the offset to the pointer (virtual address).
+*/
+   for (i = 0 ; i < ARRAY_SIZE(iommu_regs); i++) {
+   value = dmar_readq(iommu->reg + iommu_regs[i].offset);
+   seq_printf(m, "%-8s\t\t0x%02x\t\t0x%016llx\n",
+  iommu_regs[i].regs, 

[PATCH v7 3/5] iommu/vt-d: Add debugfs support to show register contents

[Sohil Mehta]

From: Gayatri Kammela 

Debugfs extension to dump all the register contents for each IOMMU
device to the user space via debugfs.

Example:
root@OTC-KBLH-01:~# cat /sys/kernel/debug/intel_iommu/iommu_regset
DMAR: dmar0: Register Base Address fed9
NameOffset  Contents
VER 0x000x0010
CAP 0x080x01cc40660462
ECAP0x100x00f0101a
GCMD0x180x
GSTS0x1c0xc700
RTADDR  0x200x0004071d3800
CCMD0x280x0800
FSTS0x340x
FECTL   0x380x
FEDATA  0x3c0xfee010044021

Cc: Fenghua Yu 
Cc: Jacob Pan 
Cc: Ashok Raj 
Co-Developed-by: Sohil Mehta 
Signed-off-by: Sohil Mehta 
Signed-off-by: Gayatri Kammela 
---

v7: Use macro for register set definitions
Fix compiler warning for readq with 32bit architecture
Remove leading '\n'

v6: No change

v5: No change

v4: Fix checkpatch.pl warnings
Remove error reporting for debugfs_create_file function
Remove redundant IOMMU null check under for_each_active_iommu

v3: Use a macro for seq file operations 
Change the intel_iommu_regset file name to iommu_regset
Add information for MTRR registers

v2: Fix seq_printf formatting

 drivers/iommu/intel-iommu-debug.c | 84 +++
 include/linux/intel-iommu.h   |  2 +
 2 files changed, 86 insertions(+)

diff --git a/drivers/iommu/intel-iommu-debug.c 
b/drivers/iommu/intel-iommu-debug.c
index 8253503..38651ad 100644
--- a/drivers/iommu/intel-iommu-debug.c
+++ b/drivers/iommu/intel-iommu-debug.c
@@ -38,6 +38,49 @@ static const struct file_operations __name ## _fops =
\
.owner  = THIS_MODULE,  \
 }
 
+struct iommu_regset {
+   int offset;
+   const char *regs;
+};
+
+#define IOMMU_REGSET_ENTRY(_reg_)  \
+   { DMAR_##_reg_##_REG, __stringify(_reg_) }
+static const struct iommu_regset iommu_regs[] = {
+   IOMMU_REGSET_ENTRY(VER),
+   IOMMU_REGSET_ENTRY(CAP),
+   IOMMU_REGSET_ENTRY(ECAP),
+   IOMMU_REGSET_ENTRY(GCMD),
+   IOMMU_REGSET_ENTRY(GSTS),
+   IOMMU_REGSET_ENTRY(RTADDR),
+   IOMMU_REGSET_ENTRY(CCMD),
+   IOMMU_REGSET_ENTRY(FSTS),
+   IOMMU_REGSET_ENTRY(FECTL),
+   IOMMU_REGSET_ENTRY(FEDATA),
+   IOMMU_REGSET_ENTRY(FEADDR),
+   IOMMU_REGSET_ENTRY(FEUADDR),
+   IOMMU_REGSET_ENTRY(AFLOG),
+   IOMMU_REGSET_ENTRY(PMEN),
+   IOMMU_REGSET_ENTRY(PLMBASE),
+   IOMMU_REGSET_ENTRY(PLMLIMIT),
+   IOMMU_REGSET_ENTRY(PHMBASE),
+   IOMMU_REGSET_ENTRY(PHMLIMIT),
+   IOMMU_REGSET_ENTRY(IQH),
+   IOMMU_REGSET_ENTRY(IQT),
+   IOMMU_REGSET_ENTRY(IQA),
+   IOMMU_REGSET_ENTRY(ICS),
+   IOMMU_REGSET_ENTRY(IRTA),
+   IOMMU_REGSET_ENTRY(PQH),
+   IOMMU_REGSET_ENTRY(PQT),
+   IOMMU_REGSET_ENTRY(PQA),
+   IOMMU_REGSET_ENTRY(PRS),
+   IOMMU_REGSET_ENTRY(PECTL),
+   IOMMU_REGSET_ENTRY(PEDATA),
+   IOMMU_REGSET_ENTRY(PEADDR),
+   IOMMU_REGSET_ENTRY(PEUADDR),
+   IOMMU_REGSET_ENTRY(MTRRCAP),
+   IOMMU_REGSET_ENTRY(MTRRDEF)
+};
+
 static void ctx_tbl_entry_show(struct seq_file *m, struct intel_iommu *iommu,
   int bus, bool ext)
 {
@@ -116,6 +159,45 @@ static int dmar_translation_struct_show(struct seq_file 
*m, void *unused)
 }
 DEFINE_SHOW_ATTRIBUTE(dmar_translation_struct);
 
+static int iommu_regset_show(struct seq_file *m, void *unused)
+{
+   struct dmar_drhd_unit *drhd;
+   struct intel_iommu *iommu;
+   unsigned long long base;
+   int i, ret = 0;
+   u64 value;
+
+   rcu_read_lock();
+   for_each_active_iommu(iommu, drhd) {
+   if (!drhd->reg_base_addr) {
+   seq_puts(m, "IOMMU: Invalid base address\n");
+   ret = -EINVAL;
+   goto out;
+   }
+
+   base = drhd->reg_base_addr;
+   seq_printf(m, "DMAR: %s: Register Base Address %llx\n",
+  iommu->name, base);
+   seq_puts(m, "Name\t\t\tOffset\t\tContents\n");
+   /*
+* Publish the contents of the 64-bit hardware registers
+* by adding the offset to the pointer (virtual address).
+*/
+   for (i = 0 ; i < ARRAY_SIZE(iommu_regs); i++) {
+   value = dmar_readq(iommu->reg + iommu_regs[i].offset);
+   seq_printf(m, "%-8s\t\t0x%02x\t\t0x%016llx\n",
+  iommu_regs[i].regs, iommu_regs[i].offset,
+  value);
+   }
+   seq_putc(m, '\n');
+   }
+out:
+   rcu_read_unlock();
+
+   

[PATCH v7 0/5] Add Intel IOMMU debugfs support

[Sohil Mehta]

Hi All,

This series aims to add debugfs support for Intel IOMMU. It exposes IOMMU
registers, internal context and dumps individual table entries to help debug
Intel IOMMUs.

The first patch does the ground work for the following patches by reorganizing
some Intel IOMMU data structures. The following patches create a new Kconfig
option - INTEL_IOMMU_DEBUG and add debugfs support for IOMMU context internals,
register contents, PASID internals, and Interrupt remapping in that order. The
information can be accessed in sysfs at '/sys/kernel/debug/intel_iommu/'.


Regards,
Sohil
 
Changes since v6:
 - Split patch 1/5 and 2/5 differently
 - Simplify and improve code formatting
 - Use macro for register set definitions
 - Fix compiler warning for readq
 - Add Co-Developed-by tag to commit messages

Changes since v5:
 - Change the order of includes to an alphabetical order
 - Change seq_printf and seq_puts formatting

Changes since v4:
 - Change to a SPDX license tag
 - Fix seq_printf formatting and remove leading '\n's

Changes since v3:
 - Remove an unused function parameter from some of the functions
 - Fix checkpatch.pl warnings
 - Remove error reporting for debugfs_create_file functions
 - Fix unnecessary reprogramming of the context entries
 - Simplify and merge the show context and extended context patch into one
 - Remove redundant IOMMU null check under for_each_active_iommu
 - Update the commit title to be consistent

Changes since v2:
 - Added a macro for seq file operations based on recommendation by Andy 
   Shevchenko. The marco can be moved to seq_file.h at a future point
 - Changed the debugfs file names to more relevant ones
 - Added information for MTRR registers in the regset file

Changes since v1:
 - Fixed seq_printf formatting
 - Handled the case when Interrupt remapping is not enabled

Gayatri Kammela (4):
  iommu/vt-d: Relocate struct/function declarations to its header files
  iommu/vt-d: Enable debugfs support to show context internals
  iommu/vt-d: Add debugfs support to show register contents
  iommu/vt-d: Add debugfs support to show Pasid table contents

Sohil Mehta (1):
  iommu/vt-d: Add debugfs support for Interrupt remapping

 drivers/iommu/Kconfig |   8 +
 drivers/iommu/Makefile|   1 +
 drivers/iommu/intel-iommu-debug.c | 338 ++
 drivers/iommu/intel-iommu.c   |  34 +---
 drivers/iommu/intel-svm.c |   8 -
 include/linux/intel-iommu.h   |  39 +
 include/linux/intel-svm.h |  10 +-
 7 files changed, 400 insertions(+), 38 deletions(-)
 create mode 100644 drivers/iommu/intel-iommu-debug.c

-- 
2.7.4

[PATCH v7 0/5] Add Intel IOMMU debugfs support

[Sohil Mehta]

Hi All,

This series aims to add debugfs support for Intel IOMMU. It exposes IOMMU
registers, internal context and dumps individual table entries to help debug
Intel IOMMUs.

The first patch does the ground work for the following patches by reorganizing
some Intel IOMMU data structures. The following patches create a new Kconfig
option - INTEL_IOMMU_DEBUG and add debugfs support for IOMMU context internals,
register contents, PASID internals, and Interrupt remapping in that order. The
information can be accessed in sysfs at '/sys/kernel/debug/intel_iommu/'.


Regards,
Sohil
 
Changes since v6:
 - Split patch 1/5 and 2/5 differently
 - Simplify and improve code formatting
 - Use macro for register set definitions
 - Fix compiler warning for readq
 - Add Co-Developed-by tag to commit messages

Changes since v5:
 - Change the order of includes to an alphabetical order
 - Change seq_printf and seq_puts formatting

Changes since v4:
 - Change to a SPDX license tag
 - Fix seq_printf formatting and remove leading '\n's

Changes since v3:
 - Remove an unused function parameter from some of the functions
 - Fix checkpatch.pl warnings
 - Remove error reporting for debugfs_create_file functions
 - Fix unnecessary reprogramming of the context entries
 - Simplify and merge the show context and extended context patch into one
 - Remove redundant IOMMU null check under for_each_active_iommu
 - Update the commit title to be consistent

Changes since v2:
 - Added a macro for seq file operations based on recommendation by Andy 
   Shevchenko. The marco can be moved to seq_file.h at a future point
 - Changed the debugfs file names to more relevant ones
 - Added information for MTRR registers in the regset file

Changes since v1:
 - Fixed seq_printf formatting
 - Handled the case when Interrupt remapping is not enabled

Gayatri Kammela (4):
  iommu/vt-d: Relocate struct/function declarations to its header files
  iommu/vt-d: Enable debugfs support to show context internals
  iommu/vt-d: Add debugfs support to show register contents
  iommu/vt-d: Add debugfs support to show Pasid table contents

Sohil Mehta (1):
  iommu/vt-d: Add debugfs support for Interrupt remapping

 drivers/iommu/Kconfig |   8 +
 drivers/iommu/Makefile|   1 +
 drivers/iommu/intel-iommu-debug.c | 338 ++
 drivers/iommu/intel-iommu.c   |  34 +---
 drivers/iommu/intel-svm.c |   8 -
 include/linux/intel-iommu.h   |  39 +
 include/linux/intel-svm.h |  10 +-
 7 files changed, 400 insertions(+), 38 deletions(-)
 create mode 100644 drivers/iommu/intel-iommu-debug.c

-- 
2.7.4