[v9] clk: qcom: clk-rpmh: Add QCOM RPMh clock driver

[Taniya Das]

 [v9]
   * clean up recalc function to use integer division.
   * Add back type casting the desc data passed to "getter" function and
   added comment for the same.

 [v8]
   * cleanup code to remove of rpmh_client handle.
   * pass the hw_clks array to the devm_of_clk_add_hw_provider getter function.

 [v7]
   * Addressed comments from Stephen
- Keep only xo_board as clock parent.
- Associate divs from SoC specific clock listing to calculate
   the clock rate.
- Add back the recalc_rate clock ops to return the clock rate
   based on the parent rate and div associated with clock.
- void cast kept to avoid compiler warnings.

 [v6]
   * Addressed comments from Rob
   * Addressed comments from Stephen

 [v5]
   * Addressed comments from Stephen
   * Introduced a new DT property to take clock divs

 [v4]
  * Addressed comments from Stephen

 [v3]
  * Addressed documentation & code review comments from Bjorn
  * Addressed bindings comments from Rob
  * Updated the patch series order for bindings

 [v2]
  * Addressed comments from Stephen
  * Addressed comments from Evan

This patch series adds a driver and device tree documentation binding
for the clock control via Resource Power Manager-hardened (RPMh) on some
Qualcomm Technologies, Inc, SoCs such as SDM845. The clock RPMh driver
would send requests for the RPMh managed clock resources.

The RPMh clock driver depends upon the RPMh driver [1] and command DB
driver [2] which are both still undergoing review.

Thanks,
Taniya

[1]: https://lkml.org/lkml/2018/3/9/979
[2]: https://lkml.org/lkml/2018/3/14/787

Taniya Das (1):
  clk: qcom: clk-rpmh: Add QCOM RPMh clock driver

 drivers/clk/qcom/Kconfig|   9 ++
 drivers/clk/qcom/Makefile   |   1 +
 drivers/clk/qcom/clk-rpmh.c | 333 
 3 files changed, 343 insertions(+)
 create mode 100644 drivers/clk/qcom/clk-rpmh.c

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

[v9] clk: qcom: clk-rpmh: Add QCOM RPMh clock driver

[Taniya Das]

 [v9]
   * clean up recalc function to use integer division.
   * Add back type casting the desc data passed to "getter" function and
   added comment for the same.

 [v8]
   * cleanup code to remove of rpmh_client handle.
   * pass the hw_clks array to the devm_of_clk_add_hw_provider getter function.

 [v7]
   * Addressed comments from Stephen
- Keep only xo_board as clock parent.
- Associate divs from SoC specific clock listing to calculate
   the clock rate.
- Add back the recalc_rate clock ops to return the clock rate
   based on the parent rate and div associated with clock.
- void cast kept to avoid compiler warnings.

 [v6]
   * Addressed comments from Rob
   * Addressed comments from Stephen

 [v5]
   * Addressed comments from Stephen
   * Introduced a new DT property to take clock divs

 [v4]
  * Addressed comments from Stephen

 [v3]
  * Addressed documentation & code review comments from Bjorn
  * Addressed bindings comments from Rob
  * Updated the patch series order for bindings

 [v2]
  * Addressed comments from Stephen
  * Addressed comments from Evan

This patch series adds a driver and device tree documentation binding
for the clock control via Resource Power Manager-hardened (RPMh) on some
Qualcomm Technologies, Inc, SoCs such as SDM845. The clock RPMh driver
would send requests for the RPMh managed clock resources.

The RPMh clock driver depends upon the RPMh driver [1] and command DB
driver [2] which are both still undergoing review.

Thanks,
Taniya

[1]: https://lkml.org/lkml/2018/3/9/979
[2]: https://lkml.org/lkml/2018/3/14/787

Taniya Das (1):
  clk: qcom: clk-rpmh: Add QCOM RPMh clock driver

 drivers/clk/qcom/Kconfig|   9 ++
 drivers/clk/qcom/Makefile   |   1 +
 drivers/clk/qcom/clk-rpmh.c | 333 
 3 files changed, 343 insertions(+)
 create mode 100644 drivers/clk/qcom/clk-rpmh.c

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

[v9] clk: qcom: clk-rpmh: Add QCOM RPMh clock driver

[Taniya Das]

Add the RPMh clock driver to control the RPMh managed clock resources on
some of the Qualcomm Technologies, Inc. SoCs.

Signed-off-by: Taniya Das 
---
 drivers/clk/qcom/Kconfig|   9 ++
 drivers/clk/qcom/Makefile   |   1 +
 drivers/clk/qcom/clk-rpmh.c | 333 
 3 files changed, 343 insertions(+)
 create mode 100644 drivers/clk/qcom/clk-rpmh.c

diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index e42e1af..627e6e1 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -59,6 +59,15 @@ config QCOM_CLK_SMD_RPM
  Say Y if you want to support the clocks exposed by the RPM on
  platforms such as apq8016, apq8084, msm8974 etc.

+config QCOM_CLK_RPMH
+   tristate "RPMh Clock Driver"
+   depends on COMMON_CLK_QCOM && QCOM_RPMH
+   help
+RPMh manages shared resources on some Qualcomm Technologies, Inc.
+SoCs. It accepts requests from other hardware subsystems via RSC.
+Say Y if you want to support the clocks exposed by RPMh on
+platforms such as SDM845.
+
 config APQ_GCC_8084
tristate "APQ8084 Global Clock Controller"
select QCOM_GDSC
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 7c09ab1..246a721 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -37,5 +37,6 @@ obj-$(CONFIG_MSM_MMCC_8996) += mmcc-msm8996.o
 obj-$(CONFIG_QCOM_A53PLL) += a53-pll.o
 obj-$(CONFIG_QCOM_CLK_APCS_MSM8916) += apcs-msm8916.o
 obj-$(CONFIG_QCOM_CLK_RPM) += clk-rpm.o
+obj-$(CONFIG_QCOM_CLK_RPMH) += clk-rpmh.o
 obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o
 obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o
diff --git a/drivers/clk/qcom/clk-rpmh.c b/drivers/clk/qcom/clk-rpmh.c
new file mode 100644
index 000..64b371c
--- /dev/null
+++ b/drivers/clk/qcom/clk-rpmh.c
@@ -0,0 +1,333 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define CLK_RPMH_ARC_EN_OFFSET 0
+#define CLK_RPMH_VRM_EN_OFFSET 4
+
+/**
+ * struct clk_rpmh - individual rpmh clock data structure
+ * @hw:handle between common and hardware-specific 
interfaces
+ * @res_name:  resource name for the rpmh clock
+ * @div:   clock divider to compute the clock rate
+ * @res_addr:  base address of the rpmh resource within the RPMh
+ * @res_on_val:rpmh clock enable value
+ * @state: rpmh clock requested state
+ * @aggr_state:rpmh clock aggregated state
+ * @last_sent_aggr_state: rpmh clock last aggr state sent to RPMh
+ * @valid_state_mask:  mask to determine the state of the rpmh clock
+ * @dev:   device to which it is attached
+ * @peer:  pointer to the clock rpmh sibling
+ */
+struct clk_rpmh {
+   struct clk_hw hw;
+   const char *res_name;
+   u8 div;
+   u32 res_addr;
+   u32 res_on_val;
+   u32 state;
+   u32 aggr_state;
+   u32 last_sent_aggr_state;
+   u32 valid_state_mask;
+   struct device *dev;
+   struct clk_rpmh *peer;
+};
+
+struct clk_rpmh_desc {
+   struct clk_hw **clks;
+   size_t num_clks;
+};
+
+static DEFINE_MUTEX(rpmh_clk_lock);
+
+#define __DEFINE_CLK_RPMH(_platform, _name, _name_active, _res_name,   \
+ _res_en_offset, _res_on, _div)\
+   static struct clk_rpmh _platform##_##_name_active;  \
+   static struct clk_rpmh _platform##_##_name = {  \
+   .res_name = _res_name,  \
+   .res_addr = _res_en_offset, \
+   .res_on_val = _res_on,  \
+   .div = _div,\
+   .peer = &_platform##_##_name_active,\
+   .valid_state_mask = (BIT(RPMH_WAKE_ONLY_STATE) |\
+ BIT(RPMH_ACTIVE_ONLY_STATE) | \
+ BIT(RPMH_SLEEP_STATE)),   \
+   .hw.init = &(struct clk_init_data){ \
+   .ops = _rpmh_ops,   \
+   .name = #_name, \
+   .parent_names = (const char *[]){ "xo_board" }, \
+   .num_parents = 1,   \
+   },  \
+   };  \
+   static struct clk_rpmh _platform##_##_name_active = {   \
+   .res_name = _res_name,  \
+   .res_addr 

[v9] clk: qcom: clk-rpmh: Add QCOM RPMh clock driver

[Taniya Das]

Add the RPMh clock driver to control the RPMh managed clock resources on
some of the Qualcomm Technologies, Inc. SoCs.

Signed-off-by: Taniya Das 
---
 drivers/clk/qcom/Kconfig|   9 ++
 drivers/clk/qcom/Makefile   |   1 +
 drivers/clk/qcom/clk-rpmh.c | 333 
 3 files changed, 343 insertions(+)
 create mode 100644 drivers/clk/qcom/clk-rpmh.c

diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index e42e1af..627e6e1 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -59,6 +59,15 @@ config QCOM_CLK_SMD_RPM
  Say Y if you want to support the clocks exposed by the RPM on
  platforms such as apq8016, apq8084, msm8974 etc.

+config QCOM_CLK_RPMH
+   tristate "RPMh Clock Driver"
+   depends on COMMON_CLK_QCOM && QCOM_RPMH
+   help
+RPMh manages shared resources on some Qualcomm Technologies, Inc.
+SoCs. It accepts requests from other hardware subsystems via RSC.
+Say Y if you want to support the clocks exposed by RPMh on
+platforms such as SDM845.
+
 config APQ_GCC_8084
tristate "APQ8084 Global Clock Controller"
select QCOM_GDSC
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 7c09ab1..246a721 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -37,5 +37,6 @@ obj-$(CONFIG_MSM_MMCC_8996) += mmcc-msm8996.o
 obj-$(CONFIG_QCOM_A53PLL) += a53-pll.o
 obj-$(CONFIG_QCOM_CLK_APCS_MSM8916) += apcs-msm8916.o
 obj-$(CONFIG_QCOM_CLK_RPM) += clk-rpm.o
+obj-$(CONFIG_QCOM_CLK_RPMH) += clk-rpmh.o
 obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o
 obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o
diff --git a/drivers/clk/qcom/clk-rpmh.c b/drivers/clk/qcom/clk-rpmh.c
new file mode 100644
index 000..64b371c
--- /dev/null
+++ b/drivers/clk/qcom/clk-rpmh.c
@@ -0,0 +1,333 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define CLK_RPMH_ARC_EN_OFFSET 0
+#define CLK_RPMH_VRM_EN_OFFSET 4
+
+/**
+ * struct clk_rpmh - individual rpmh clock data structure
+ * @hw:handle between common and hardware-specific 
interfaces
+ * @res_name:  resource name for the rpmh clock
+ * @div:   clock divider to compute the clock rate
+ * @res_addr:  base address of the rpmh resource within the RPMh
+ * @res_on_val:rpmh clock enable value
+ * @state: rpmh clock requested state
+ * @aggr_state:rpmh clock aggregated state
+ * @last_sent_aggr_state: rpmh clock last aggr state sent to RPMh
+ * @valid_state_mask:  mask to determine the state of the rpmh clock
+ * @dev:   device to which it is attached
+ * @peer:  pointer to the clock rpmh sibling
+ */
+struct clk_rpmh {
+   struct clk_hw hw;
+   const char *res_name;
+   u8 div;
+   u32 res_addr;
+   u32 res_on_val;
+   u32 state;
+   u32 aggr_state;
+   u32 last_sent_aggr_state;
+   u32 valid_state_mask;
+   struct device *dev;
+   struct clk_rpmh *peer;
+};
+
+struct clk_rpmh_desc {
+   struct clk_hw **clks;
+   size_t num_clks;
+};
+
+static DEFINE_MUTEX(rpmh_clk_lock);
+
+#define __DEFINE_CLK_RPMH(_platform, _name, _name_active, _res_name,   \
+ _res_en_offset, _res_on, _div)\
+   static struct clk_rpmh _platform##_##_name_active;  \
+   static struct clk_rpmh _platform##_##_name = {  \
+   .res_name = _res_name,  \
+   .res_addr = _res_en_offset, \
+   .res_on_val = _res_on,  \
+   .div = _div,\
+   .peer = &_platform##_##_name_active,\
+   .valid_state_mask = (BIT(RPMH_WAKE_ONLY_STATE) |\
+ BIT(RPMH_ACTIVE_ONLY_STATE) | \
+ BIT(RPMH_SLEEP_STATE)),   \
+   .hw.init = &(struct clk_init_data){ \
+   .ops = _rpmh_ops,   \
+   .name = #_name, \
+   .parent_names = (const char *[]){ "xo_board" }, \
+   .num_parents = 1,   \
+   },  \
+   };  \
+   static struct clk_rpmh _platform##_##_name_active = {   \
+   .res_name = _res_name,  \
+   .res_addr = _res_en_offset, 

My name is BOVID EGAVI, a bank's manager in republic of TOGO. I have an abandoned unclaimed sum of thirty-six million euros only. can I trust you with this? if yes then contact me for full details thr

[BOVID EGAVI]

My name is BOVID EGAVI, a bank's manager in republic of TOGO. I have an abandoned unclaimed sum of thirty-six million euros only. can I trust you with this? if yes then contact me for full details thr

[BOVID EGAVI]

Re: BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_his

[Eric Biggers]

On Wed, May 09, 2018 at 07:23:41AM +0200, 'Dmitry Vyukov' via syzkaller-bugs 
wrote:
> On Wed, May 9, 2018 at 7:05 AM, Eric Biggers  wrote:
> > On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote:
> >> Hello,
> >>
> >> syzbot found the following crash on:
> >>
> >> HEAD commit:c1c07416cdd4 Merge tag 'kbuild-fixes-v4.17' of 
> >> git://git.k..
> >> git tree:   upstream
> >> console output: https://syzkaller.appspot.com/x/log.txt?x=13d5de4780
> >> kernel config:  https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27
> >> dashboard link: 
> >> https://syzkaller.appspot.com/bug?extid=99858724c0ba555a12ea
> >> compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> >> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=170afde780
> >> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=141b4be780
> >>
> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> >> Reported-by: syzbot+99858724c0ba555a1...@syzkaller.appspotmail.com
> >>
> >> random: sshd: uninitialized urandom read (32 bytes read)
> >> random: sshd: uninitialized urandom read (32 bytes read)
> >> random: sshd: uninitialized urandom read (32 bytes read)
> >> random: sshd: uninitialized urandom read (32 bytes read)
> >> BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at
> >> net/dccp/ccids/lib/packet_history.c:425/tfrc_rx_hist_sample_rtt()
> >> CPU: 0 PID: 4495 Comm: syz-executor551 Not tainted 4.17.0-rc3+ #34
> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >> Google 01/01/2011
> >> Call Trace:
> >>  
> >>  __dump_stack lib/dump_stack.c:77 [inline]
> >>  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
> >>  tfrc_rx_hist_sample_rtt.cold.3+0x54/0x5c
> >> net/dccp/ccids/lib/packet_history.c:422
> >>  ccid3_hc_rx_packet_recv+0x5c8/0xed0 net/dccp/ccids/ccid3.c:765
> >>  ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
> >>  dccp_deliver_input_to_ccids+0xf0/0x280 net/dccp/input.c:180
> >>  dccp_rcv_established+0x87/0xb0 net/dccp/input.c:378
> >>  dccp_v4_do_rcv+0x153/0x180 net/dccp/ipv4.c:654
> >>  sk_backlog_rcv include/net/sock.h:909 [inline]
> >>  __sk_receive_skb+0x3a2/0xd60 net/core/sock.c:513
> >>  dccp_v4_rcv+0x10e5/0x1f3f net/dccp/ipv4.c:875
> >>  ip_local_deliver_finish+0x2e3/0xd80 net/ipv4/ip_input.c:215
> >>  NF_HOOK include/linux/netfilter.h:288 [inline]
> >>  ip_local_deliver+0x1e1/0x720 net/ipv4/ip_input.c:256
> >>  dst_input include/net/dst.h:450 [inline]
> >>  ip_rcv_finish+0x81b/0x2200 net/ipv4/ip_input.c:396
> >>  NF_HOOK include/linux/netfilter.h:288 [inline]
> >>  ip_rcv+0xb70/0x143d net/ipv4/ip_input.c:492
> >>  __netif_receive_skb_core+0x26f5/0x3630 net/core/dev.c:4592
> >>  __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4657
> >>  process_backlog+0x219/0x760 net/core/dev.c:5337
> >>  napi_poll net/core/dev.c:5735 [inline]
> >>  net_rx_action+0x7b7/0x1930 net/core/dev.c:5801
> >>  __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
> >>  do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1046
> >>  
> >>  do_softirq.part.17+0x14d/0x190 kernel/softirq.c:329
> >>  do_softirq arch/x86/include/asm/preempt.h:23 [inline]
> >>  __local_bh_enable_ip+0x1ec/0x230 kernel/softirq.c:182
> >>  local_bh_enable include/linux/bottom_half.h:32 [inline]
> >>  rcu_read_unlock_bh include/linux/rcupdate.h:728 [inline]
> >>  ip_finish_output2+0xab2/0x1840 net/ipv4/ip_output.c:231
> >>  ip_finish_output+0x828/0xf80 net/ipv4/ip_output.c:317
> >>  NF_HOOK_COND include/linux/netfilter.h:277 [inline]
> >>  ip_output+0x21b/0x850 net/ipv4/ip_output.c:405
> >>  dst_output include/net/dst.h:444 [inline]
> >>  ip_local_out+0xc5/0x1b0 net/ipv4/ip_output.c:124
> >>  ip_queue_xmit+0x9d7/0x1f70 net/ipv4/ip_output.c:504
> >>  dccp_transmit_skb+0x999/0x12e0 net/dccp/output.c:142
> >>  dccp_xmit_packet+0x250/0x790 net/dccp/output.c:281
> >>  dccp_write_xmit+0x190/0x1f0 net/dccp/output.c:363
> >>  dccp_sendmsg+0x8c7/0x1020 net/dccp/proto.c:818
> >>  inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
> >>  sock_sendmsg_nosec net/socket.c:629 [inline]
> >>  sock_sendmsg+0xd5/0x120 net/socket.c:639
> >>  ___sys_sendmsg+0x525/0x940 net/socket.c:2117
> >>  __sys_sendmmsg+0x240/0x6f0 net/socket.c:2212
> >>  __do_sys_sendmmsg net/socket.c:2241 [inline]
> >>  __se_sys_sendmmsg net/socket.c:2238 [inline]
> >>  __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2238
> >>  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
> >>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >> RIP: 0033:0x445d09
> >> RSP: 002b:7f3c7eff5d88 EFLAGS: 0293 ORIG_RAX: 0133
> >> RAX: ffda RBX: 006dac40 RCX: 00445d09
> >> RDX: 0001 RSI: 00
> >>
> >>
> >> ---
> >> This bug is generated by a bot. It may contain errors.
> >> See https://goo.gl/tpsmEJ for more information about syzbot.
> >> syzbot engineers can be reached at syzkal...@googlegroups.com.
> >>
> >> syzbot will keep track of this bug report.
> >> If you forgot to add 

Re: BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_his

[Eric Biggers]

On Wed, May 09, 2018 at 07:23:41AM +0200, 'Dmitry Vyukov' via syzkaller-bugs 
wrote:
> On Wed, May 9, 2018 at 7:05 AM, Eric Biggers  wrote:
> > On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote:
> >> Hello,
> >>
> >> syzbot found the following crash on:
> >>
> >> HEAD commit:c1c07416cdd4 Merge tag 'kbuild-fixes-v4.17' of 
> >> git://git.k..
> >> git tree:   upstream
> >> console output: https://syzkaller.appspot.com/x/log.txt?x=13d5de4780
> >> kernel config:  https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27
> >> dashboard link: 
> >> https://syzkaller.appspot.com/bug?extid=99858724c0ba555a12ea
> >> compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> >> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=170afde780
> >> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=141b4be780
> >>
> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> >> Reported-by: syzbot+99858724c0ba555a1...@syzkaller.appspotmail.com
> >>
> >> random: sshd: uninitialized urandom read (32 bytes read)
> >> random: sshd: uninitialized urandom read (32 bytes read)
> >> random: sshd: uninitialized urandom read (32 bytes read)
> >> random: sshd: uninitialized urandom read (32 bytes read)
> >> BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at
> >> net/dccp/ccids/lib/packet_history.c:425/tfrc_rx_hist_sample_rtt()
> >> CPU: 0 PID: 4495 Comm: syz-executor551 Not tainted 4.17.0-rc3+ #34
> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >> Google 01/01/2011
> >> Call Trace:
> >>  
> >>  __dump_stack lib/dump_stack.c:77 [inline]
> >>  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
> >>  tfrc_rx_hist_sample_rtt.cold.3+0x54/0x5c
> >> net/dccp/ccids/lib/packet_history.c:422
> >>  ccid3_hc_rx_packet_recv+0x5c8/0xed0 net/dccp/ccids/ccid3.c:765
> >>  ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
> >>  dccp_deliver_input_to_ccids+0xf0/0x280 net/dccp/input.c:180
> >>  dccp_rcv_established+0x87/0xb0 net/dccp/input.c:378
> >>  dccp_v4_do_rcv+0x153/0x180 net/dccp/ipv4.c:654
> >>  sk_backlog_rcv include/net/sock.h:909 [inline]
> >>  __sk_receive_skb+0x3a2/0xd60 net/core/sock.c:513
> >>  dccp_v4_rcv+0x10e5/0x1f3f net/dccp/ipv4.c:875
> >>  ip_local_deliver_finish+0x2e3/0xd80 net/ipv4/ip_input.c:215
> >>  NF_HOOK include/linux/netfilter.h:288 [inline]
> >>  ip_local_deliver+0x1e1/0x720 net/ipv4/ip_input.c:256
> >>  dst_input include/net/dst.h:450 [inline]
> >>  ip_rcv_finish+0x81b/0x2200 net/ipv4/ip_input.c:396
> >>  NF_HOOK include/linux/netfilter.h:288 [inline]
> >>  ip_rcv+0xb70/0x143d net/ipv4/ip_input.c:492
> >>  __netif_receive_skb_core+0x26f5/0x3630 net/core/dev.c:4592
> >>  __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4657
> >>  process_backlog+0x219/0x760 net/core/dev.c:5337
> >>  napi_poll net/core/dev.c:5735 [inline]
> >>  net_rx_action+0x7b7/0x1930 net/core/dev.c:5801
> >>  __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
> >>  do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1046
> >>  
> >>  do_softirq.part.17+0x14d/0x190 kernel/softirq.c:329
> >>  do_softirq arch/x86/include/asm/preempt.h:23 [inline]
> >>  __local_bh_enable_ip+0x1ec/0x230 kernel/softirq.c:182
> >>  local_bh_enable include/linux/bottom_half.h:32 [inline]
> >>  rcu_read_unlock_bh include/linux/rcupdate.h:728 [inline]
> >>  ip_finish_output2+0xab2/0x1840 net/ipv4/ip_output.c:231
> >>  ip_finish_output+0x828/0xf80 net/ipv4/ip_output.c:317
> >>  NF_HOOK_COND include/linux/netfilter.h:277 [inline]
> >>  ip_output+0x21b/0x850 net/ipv4/ip_output.c:405
> >>  dst_output include/net/dst.h:444 [inline]
> >>  ip_local_out+0xc5/0x1b0 net/ipv4/ip_output.c:124
> >>  ip_queue_xmit+0x9d7/0x1f70 net/ipv4/ip_output.c:504
> >>  dccp_transmit_skb+0x999/0x12e0 net/dccp/output.c:142
> >>  dccp_xmit_packet+0x250/0x790 net/dccp/output.c:281
> >>  dccp_write_xmit+0x190/0x1f0 net/dccp/output.c:363
> >>  dccp_sendmsg+0x8c7/0x1020 net/dccp/proto.c:818
> >>  inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
> >>  sock_sendmsg_nosec net/socket.c:629 [inline]
> >>  sock_sendmsg+0xd5/0x120 net/socket.c:639
> >>  ___sys_sendmsg+0x525/0x940 net/socket.c:2117
> >>  __sys_sendmmsg+0x240/0x6f0 net/socket.c:2212
> >>  __do_sys_sendmmsg net/socket.c:2241 [inline]
> >>  __se_sys_sendmmsg net/socket.c:2238 [inline]
> >>  __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2238
> >>  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
> >>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >> RIP: 0033:0x445d09
> >> RSP: 002b:7f3c7eff5d88 EFLAGS: 0293 ORIG_RAX: 0133
> >> RAX: ffda RBX: 006dac40 RCX: 00445d09
> >> RDX: 0001 RSI: 00
> >>
> >>
> >> ---
> >> This bug is generated by a bot. It may contain errors.
> >> See https://goo.gl/tpsmEJ for more information about syzbot.
> >> syzbot engineers can be reached at syzkal...@googlegroups.com.
> >>
> >> syzbot will keep track of this bug report.
> >> If you forgot to add the Reported-by tag, 

[PATCH v4 7/7] ocxl: Document new OCXL IOCTLs

[Alastair D'Silva]

From: Alastair D'Silva 

Signed-off-by: Alastair D'Silva 
---
 Documentation/accelerators/ocxl.rst | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/accelerators/ocxl.rst 
b/Documentation/accelerators/ocxl.rst
index ddcc58d01cfb..14cefc020e2d 100644
--- a/Documentation/accelerators/ocxl.rst
+++ b/Documentation/accelerators/ocxl.rst
@@ -157,6 +157,17 @@ OCXL_IOCTL_GET_METADATA:
   Obtains configuration information from the card, such at the size of
   MMIO areas, the AFU version, and the PASID for the current context.
 
+OCXL_IOCTL_ENABLE_P9_WAIT:
+
+  Allows the AFU to wake a userspace thread executing 'wait'. Returns
+  information to userspace to allow it to configure the AFU. Note that
+  this is only available on POWER9.
+
+OCXL_IOCTL_GET_FEATURES:
+
+  Reports on which CPU features that affect OpenCAPI are usable from
+  userspace.
+
 
 mmap
 
-- 
2.14.3

[PATCH v4 7/7] ocxl: Document new OCXL IOCTLs

[Alastair D'Silva]

From: Alastair D'Silva 

Signed-off-by: Alastair D'Silva 
---
 Documentation/accelerators/ocxl.rst | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/accelerators/ocxl.rst 
b/Documentation/accelerators/ocxl.rst
index ddcc58d01cfb..14cefc020e2d 100644
--- a/Documentation/accelerators/ocxl.rst
+++ b/Documentation/accelerators/ocxl.rst
@@ -157,6 +157,17 @@ OCXL_IOCTL_GET_METADATA:
   Obtains configuration information from the card, such at the size of
   MMIO areas, the AFU version, and the PASID for the current context.
 
+OCXL_IOCTL_ENABLE_P9_WAIT:
+
+  Allows the AFU to wake a userspace thread executing 'wait'. Returns
+  information to userspace to allow it to configure the AFU. Note that
+  this is only available on POWER9.
+
+OCXL_IOCTL_GET_FEATURES:
+
+  Reports on which CPU features that affect OpenCAPI are usable from
+  userspace.
+
 
 mmap
 
-- 
2.14.3

[PATCH v4 5/7] ocxl: Expose the thread_id needed for wait on POWER9

[Alastair D'Silva]

From: Alastair D'Silva 

In order to successfully issue as_notify, an AFU needs to know the TID
to notify, which in turn means that this information should be
available in userspace so it can be communicated to the AFU.

Signed-off-by: Alastair D'Silva 
---
 drivers/misc/ocxl/context.c   |  5 +++-
 drivers/misc/ocxl/file.c  | 53 +++
 drivers/misc/ocxl/link.c  | 36 ++
 drivers/misc/ocxl/ocxl_internal.h |  1 +
 include/misc/ocxl.h   |  9 +++
 include/uapi/misc/ocxl.h  | 10 
 6 files changed, 113 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/ocxl/context.c b/drivers/misc/ocxl/context.c
index 909e8807824a..95f74623113e 100644
--- a/drivers/misc/ocxl/context.c
+++ b/drivers/misc/ocxl/context.c
@@ -34,6 +34,8 @@ int ocxl_context_init(struct ocxl_context *ctx, struct 
ocxl_afu *afu,
mutex_init(>xsl_error_lock);
mutex_init(>irq_lock);
idr_init(>irq_idr);
+   ctx->tidr = 0;
+
/*
 * Keep a reference on the AFU to make sure it's valid for the
 * duration of the life of the context
@@ -65,6 +67,7 @@ int ocxl_context_attach(struct ocxl_context *ctx, u64 amr)
 {
int rc;
 
+   // Locks both status & tidr
mutex_lock(>status_mutex);
if (ctx->status != OPENED) {
rc = -EIO;
@@ -72,7 +75,7 @@ int ocxl_context_attach(struct ocxl_context *ctx, u64 amr)
}
 
rc = ocxl_link_add_pe(ctx->afu->fn->link, ctx->pasid,
-   current->mm->context.id, 0, amr, current->mm,
+   current->mm->context.id, ctx->tidr, amr, current->mm,
xsl_fault_error, ctx);
if (rc)
goto out;
diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
index 038509e5d031..eb409a469f21 100644
--- a/drivers/misc/ocxl/file.c
+++ b/drivers/misc/ocxl/file.c
@@ -5,6 +5,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "ocxl_internal.h"
 
 
@@ -123,11 +125,55 @@ static long afu_ioctl_get_metadata(struct ocxl_context 
*ctx,
return 0;
 }
 
+#ifdef CONFIG_PPC64
+static long afu_ioctl_enable_p9_wait(struct ocxl_context *ctx,
+   struct ocxl_ioctl_p9_wait __user *uarg)
+{
+   struct ocxl_ioctl_p9_wait arg;
+
+   memset(, 0, sizeof(arg));
+
+   if (cpu_has_feature(CPU_FTR_P9_TIDR)) {
+   enum ocxl_context_status status;
+
+   // Locks both status & tidr
+   mutex_lock(>status_mutex);
+   if (!ctx->tidr) {
+   if (set_thread_tidr(current))
+   return -ENOENT;
+
+   ctx->tidr = current->thread.tidr;
+   }
+
+   status = ctx->status;
+   mutex_unlock(>status_mutex);
+
+   if (status == ATTACHED) {
+   int rc;
+   struct link *link = ctx->afu->fn->link;
+
+   rc = ocxl_link_update_pe(link, ctx->pasid, ctx->tidr);
+   if (rc)
+   return rc;
+   }
+
+   arg.thread_id = ctx->tidr;
+   } else
+   return -ENOENT;
+
+   if (copy_to_user(uarg, , sizeof(arg)))
+   return -EFAULT;
+
+   return 0;
+}
+#endif
+
 #define CMD_STR(x) (x == OCXL_IOCTL_ATTACH ? "ATTACH" :
\
x == OCXL_IOCTL_IRQ_ALLOC ? "IRQ_ALLOC" :   \
x == OCXL_IOCTL_IRQ_FREE ? "IRQ_FREE" : \
x == OCXL_IOCTL_IRQ_SET_FD ? "IRQ_SET_FD" : \
x == OCXL_IOCTL_GET_METADATA ? "GET_METADATA" : \
+   x == OCXL_IOCTL_ENABLE_P9_WAIT ? "ENABLE_P9_WAIT" : 
\
"UNKNOWN")
 
 static long afu_ioctl(struct file *file, unsigned int cmd,
@@ -186,6 +232,13 @@ static long afu_ioctl(struct file *file, unsigned int cmd,
(struct ocxl_ioctl_metadata __user *) args);
break;
 
+#ifdef CONFIG_PPC64
+   case OCXL_IOCTL_ENABLE_P9_WAIT:
+   rc = afu_ioctl_enable_p9_wait(ctx,
+   (struct ocxl_ioctl_p9_wait __user *) args);
+   break;
+#endif
+
default:
rc = -EINVAL;
}
diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c
index 656e8610eec2..88876ae8f330 100644
--- a/drivers/misc/ocxl/link.c
+++ b/drivers/misc/ocxl/link.c
@@ -544,6 +544,42 @@ int ocxl_link_add_pe(void *link_handle, int pasid, u32 
pidr, u32 tidr,
 }
 EXPORT_SYMBOL_GPL(ocxl_link_add_pe);
 
+int ocxl_link_update_pe(void *link_handle, int pasid, __u16 tid)
+{
+   struct link *link = (struct link *) link_handle;
+   struct spa *spa = link->spa;
+   struct ocxl_process_element *pe;
+   int pe_handle, rc;
+
+   if 

[PATCH v4 1/7] powerpc: Add TIDR CPU feature for POWER9

[Alastair D'Silva]

From: Alastair D'Silva 

This patch adds a CPU feature bit to show whether the CPU has
the TIDR register available, enabling as_notify/wait in userspace.

Signed-off-by: Alastair D'Silva 
---
 arch/powerpc/include/asm/cputable.h | 3 ++-
 arch/powerpc/kernel/dt_cpu_ftrs.c   | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index 4e332f3531c5..54c4cbbe57b4 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -215,6 +215,7 @@ static inline void cpu_feature_keys_init(void) { }
 #define CPU_FTR_P9_TM_HV_ASSIST
LONG_ASM_CONST(0x1000)
 #define CPU_FTR_P9_TM_XER_SO_BUG   LONG_ASM_CONST(0x2000)
 #define CPU_FTR_P9_TLBIE_BUG   LONG_ASM_CONST(0x4000)
+#define CPU_FTR_P9_TIDR
LONG_ASM_CONST(0x8000)
 
 #ifndef __ASSEMBLY__
 
@@ -462,7 +463,7 @@ static inline void cpu_feature_keys_init(void) { }
CPU_FTR_CFAR | CPU_FTR_HVMODE | CPU_FTR_VMX_COPY | \
CPU_FTR_DBELL | CPU_FTR_HAS_PPR | CPU_FTR_ARCH_207S | \
CPU_FTR_TM_COMP | CPU_FTR_ARCH_300 | CPU_FTR_PKEY | \
-   CPU_FTR_P9_TLBIE_BUG)
+   CPU_FTR_P9_TLBIE_BUG | CPU_FTR_P9_TIDR)
 #define CPU_FTRS_POWER9_DD1 ((CPU_FTRS_POWER9 | CPU_FTR_POWER9_DD1) & \
 (~CPU_FTR_SAO))
 #define CPU_FTRS_POWER9_DD2_0 CPU_FTRS_POWER9
diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c 
b/arch/powerpc/kernel/dt_cpu_ftrs.c
index 11a3a4fed3fb..10f8b7f55637 100644
--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
+++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
@@ -722,6 +722,7 @@ static __init void cpufeatures_cpu_quirks(void)
if ((version & 0x) == 0x004e) {
cur_cpu_spec->cpu_features &= ~(CPU_FTR_DAWR);
cur_cpu_spec->cpu_features |= CPU_FTR_P9_TLBIE_BUG;
+   cur_cpu_spec->cpu_features |= CPU_FTR_P9_TIDR;
}
 }
 
-- 
2.14.3

[PATCH v4 5/7] ocxl: Expose the thread_id needed for wait on POWER9

[Alastair D'Silva]

From: Alastair D'Silva 

In order to successfully issue as_notify, an AFU needs to know the TID
to notify, which in turn means that this information should be
available in userspace so it can be communicated to the AFU.

Signed-off-by: Alastair D'Silva 
---
 drivers/misc/ocxl/context.c   |  5 +++-
 drivers/misc/ocxl/file.c  | 53 +++
 drivers/misc/ocxl/link.c  | 36 ++
 drivers/misc/ocxl/ocxl_internal.h |  1 +
 include/misc/ocxl.h   |  9 +++
 include/uapi/misc/ocxl.h  | 10 
 6 files changed, 113 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/ocxl/context.c b/drivers/misc/ocxl/context.c
index 909e8807824a..95f74623113e 100644
--- a/drivers/misc/ocxl/context.c
+++ b/drivers/misc/ocxl/context.c
@@ -34,6 +34,8 @@ int ocxl_context_init(struct ocxl_context *ctx, struct 
ocxl_afu *afu,
mutex_init(>xsl_error_lock);
mutex_init(>irq_lock);
idr_init(>irq_idr);
+   ctx->tidr = 0;
+
/*
 * Keep a reference on the AFU to make sure it's valid for the
 * duration of the life of the context
@@ -65,6 +67,7 @@ int ocxl_context_attach(struct ocxl_context *ctx, u64 amr)
 {
int rc;
 
+   // Locks both status & tidr
mutex_lock(>status_mutex);
if (ctx->status != OPENED) {
rc = -EIO;
@@ -72,7 +75,7 @@ int ocxl_context_attach(struct ocxl_context *ctx, u64 amr)
}
 
rc = ocxl_link_add_pe(ctx->afu->fn->link, ctx->pasid,
-   current->mm->context.id, 0, amr, current->mm,
+   current->mm->context.id, ctx->tidr, amr, current->mm,
xsl_fault_error, ctx);
if (rc)
goto out;
diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
index 038509e5d031..eb409a469f21 100644
--- a/drivers/misc/ocxl/file.c
+++ b/drivers/misc/ocxl/file.c
@@ -5,6 +5,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "ocxl_internal.h"
 
 
@@ -123,11 +125,55 @@ static long afu_ioctl_get_metadata(struct ocxl_context 
*ctx,
return 0;
 }
 
+#ifdef CONFIG_PPC64
+static long afu_ioctl_enable_p9_wait(struct ocxl_context *ctx,
+   struct ocxl_ioctl_p9_wait __user *uarg)
+{
+   struct ocxl_ioctl_p9_wait arg;
+
+   memset(, 0, sizeof(arg));
+
+   if (cpu_has_feature(CPU_FTR_P9_TIDR)) {
+   enum ocxl_context_status status;
+
+   // Locks both status & tidr
+   mutex_lock(>status_mutex);
+   if (!ctx->tidr) {
+   if (set_thread_tidr(current))
+   return -ENOENT;
+
+   ctx->tidr = current->thread.tidr;
+   }
+
+   status = ctx->status;
+   mutex_unlock(>status_mutex);
+
+   if (status == ATTACHED) {
+   int rc;
+   struct link *link = ctx->afu->fn->link;
+
+   rc = ocxl_link_update_pe(link, ctx->pasid, ctx->tidr);
+   if (rc)
+   return rc;
+   }
+
+   arg.thread_id = ctx->tidr;
+   } else
+   return -ENOENT;
+
+   if (copy_to_user(uarg, , sizeof(arg)))
+   return -EFAULT;
+
+   return 0;
+}
+#endif
+
 #define CMD_STR(x) (x == OCXL_IOCTL_ATTACH ? "ATTACH" :
\
x == OCXL_IOCTL_IRQ_ALLOC ? "IRQ_ALLOC" :   \
x == OCXL_IOCTL_IRQ_FREE ? "IRQ_FREE" : \
x == OCXL_IOCTL_IRQ_SET_FD ? "IRQ_SET_FD" : \
x == OCXL_IOCTL_GET_METADATA ? "GET_METADATA" : \
+   x == OCXL_IOCTL_ENABLE_P9_WAIT ? "ENABLE_P9_WAIT" : 
\
"UNKNOWN")
 
 static long afu_ioctl(struct file *file, unsigned int cmd,
@@ -186,6 +232,13 @@ static long afu_ioctl(struct file *file, unsigned int cmd,
(struct ocxl_ioctl_metadata __user *) args);
break;
 
+#ifdef CONFIG_PPC64
+   case OCXL_IOCTL_ENABLE_P9_WAIT:
+   rc = afu_ioctl_enable_p9_wait(ctx,
+   (struct ocxl_ioctl_p9_wait __user *) args);
+   break;
+#endif
+
default:
rc = -EINVAL;
}
diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c
index 656e8610eec2..88876ae8f330 100644
--- a/drivers/misc/ocxl/link.c
+++ b/drivers/misc/ocxl/link.c
@@ -544,6 +544,42 @@ int ocxl_link_add_pe(void *link_handle, int pasid, u32 
pidr, u32 tidr,
 }
 EXPORT_SYMBOL_GPL(ocxl_link_add_pe);
 
+int ocxl_link_update_pe(void *link_handle, int pasid, __u16 tid)
+{
+   struct link *link = (struct link *) link_handle;
+   struct spa *spa = link->spa;
+   struct ocxl_process_element *pe;
+   int pe_handle, rc;
+
+   if (pasid > SPA_PASID_MAX)
+   return 

[PATCH v4 1/7] powerpc: Add TIDR CPU feature for POWER9

[Alastair D'Silva]

From: Alastair D'Silva 

This patch adds a CPU feature bit to show whether the CPU has
the TIDR register available, enabling as_notify/wait in userspace.

Signed-off-by: Alastair D'Silva 
---
 arch/powerpc/include/asm/cputable.h | 3 ++-
 arch/powerpc/kernel/dt_cpu_ftrs.c   | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index 4e332f3531c5..54c4cbbe57b4 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -215,6 +215,7 @@ static inline void cpu_feature_keys_init(void) { }
 #define CPU_FTR_P9_TM_HV_ASSIST
LONG_ASM_CONST(0x1000)
 #define CPU_FTR_P9_TM_XER_SO_BUG   LONG_ASM_CONST(0x2000)
 #define CPU_FTR_P9_TLBIE_BUG   LONG_ASM_CONST(0x4000)
+#define CPU_FTR_P9_TIDR
LONG_ASM_CONST(0x8000)
 
 #ifndef __ASSEMBLY__
 
@@ -462,7 +463,7 @@ static inline void cpu_feature_keys_init(void) { }
CPU_FTR_CFAR | CPU_FTR_HVMODE | CPU_FTR_VMX_COPY | \
CPU_FTR_DBELL | CPU_FTR_HAS_PPR | CPU_FTR_ARCH_207S | \
CPU_FTR_TM_COMP | CPU_FTR_ARCH_300 | CPU_FTR_PKEY | \
-   CPU_FTR_P9_TLBIE_BUG)
+   CPU_FTR_P9_TLBIE_BUG | CPU_FTR_P9_TIDR)
 #define CPU_FTRS_POWER9_DD1 ((CPU_FTRS_POWER9 | CPU_FTR_POWER9_DD1) & \
 (~CPU_FTR_SAO))
 #define CPU_FTRS_POWER9_DD2_0 CPU_FTRS_POWER9
diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c 
b/arch/powerpc/kernel/dt_cpu_ftrs.c
index 11a3a4fed3fb..10f8b7f55637 100644
--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
+++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
@@ -722,6 +722,7 @@ static __init void cpufeatures_cpu_quirks(void)
if ((version & 0x) == 0x004e) {
cur_cpu_spec->cpu_features &= ~(CPU_FTR_DAWR);
cur_cpu_spec->cpu_features |= CPU_FTR_P9_TLBIE_BUG;
+   cur_cpu_spec->cpu_features |= CPU_FTR_P9_TIDR;
}
 }
 
-- 
2.14.3

[PATCH v4 4/7] ocxl: Rename pnv_ocxl_spa_remove_pe to clarify it's action

[Alastair D'Silva]

From: Alastair D'Silva 

The function removes the process element from NPU cache.

Signed-off-by: Alastair D'Silva 
---
 arch/powerpc/include/asm/pnv-ocxl.h   | 2 +-
 arch/powerpc/platforms/powernv/ocxl.c | 4 ++--
 drivers/misc/ocxl/link.c  | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/pnv-ocxl.h 
b/arch/powerpc/include/asm/pnv-ocxl.h
index f6945d3bc971..208b5503f4ed 100644
--- a/arch/powerpc/include/asm/pnv-ocxl.h
+++ b/arch/powerpc/include/asm/pnv-ocxl.h
@@ -28,7 +28,7 @@ extern int pnv_ocxl_map_xsl_regs(struct pci_dev *dev, void 
__iomem **dsisr,
 extern int pnv_ocxl_spa_setup(struct pci_dev *dev, void *spa_mem, int PE_mask,
void **platform_data);
 extern void pnv_ocxl_spa_release(void *platform_data);
-extern int pnv_ocxl_spa_remove_pe(void *platform_data, int pe_handle);
+extern int pnv_ocxl_spa_remove_pe_from_cache(void *platform_data, int 
pe_handle);
 
 extern int pnv_ocxl_alloc_xive_irq(u32 *irq, u64 *trigger_addr);
 extern void pnv_ocxl_free_xive_irq(u32 irq);
diff --git a/arch/powerpc/platforms/powernv/ocxl.c 
b/arch/powerpc/platforms/powernv/ocxl.c
index fa9b53af3c7b..8c65aacda9c8 100644
--- a/arch/powerpc/platforms/powernv/ocxl.c
+++ b/arch/powerpc/platforms/powernv/ocxl.c
@@ -475,7 +475,7 @@ void pnv_ocxl_spa_release(void *platform_data)
 }
 EXPORT_SYMBOL_GPL(pnv_ocxl_spa_release);
 
-int pnv_ocxl_spa_remove_pe(void *platform_data, int pe_handle)
+int pnv_ocxl_spa_remove_pe_from_cache(void *platform_data, int pe_handle)
 {
struct spa_data *data = (struct spa_data *) platform_data;
int rc;
@@ -483,7 +483,7 @@ int pnv_ocxl_spa_remove_pe(void *platform_data, int 
pe_handle)
rc = opal_npu_spa_clear_cache(data->phb_opal_id, data->bdfn, pe_handle);
return rc;
 }
-EXPORT_SYMBOL_GPL(pnv_ocxl_spa_remove_pe);
+EXPORT_SYMBOL_GPL(pnv_ocxl_spa_remove_pe_from_cache);
 
 int pnv_ocxl_alloc_xive_irq(u32 *irq, u64 *trigger_addr)
 {
diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c
index f30790582dc0..656e8610eec2 100644
--- a/drivers/misc/ocxl/link.c
+++ b/drivers/misc/ocxl/link.c
@@ -599,7 +599,7 @@ int ocxl_link_remove_pe(void *link_handle, int pasid)
 * On powerpc, the entry needs to be cleared from the context
 * cache of the NPU.
 */
-   rc = pnv_ocxl_spa_remove_pe(link->platform_data, pe_handle);
+   rc = pnv_ocxl_spa_remove_pe_from_cache(link->platform_data, pe_handle);
WARN_ON(rc);
 
pe_data = radix_tree_delete(>pe_tree, pe_handle);
-- 
2.14.3

[PATCH v4 0/7] ocxl: Implement Power9 as_notify/wait for OpenCAPI

[Alastair D'Silva]

From: Alastair D'Silva 

The Power 9 as_notify/wait feature provides a lower latency way to
signal a thread that work is complete. This series enables the use of
this feature from OpenCAPI adapters, as well as addressing a potential
starvation issue when allocating thread IDs.

Changelog:
v4:
  Remove the "unique" statement from the set_thread_tidr function and
move the text explaining why it is safe from the commit message
to the function description
v3:
  Fix references to POWER9
  Remove stray whitespace edit from docs
  Add more details to commit message for "use task_pid_nr()"
  Retitle patch 6 to indicate OCXL rather than CPU features
v2:
  Rename get_platform IOCTL to get_features
  Move stray edit from patch 1 to patch 3

Alastair D'Silva (7):
  powerpc: Add TIDR CPU feature for POWER9
  powerpc: Use TIDR CPU feature to control TIDR allocation
  powerpc: use task_pid_nr() for TID allocation
  ocxl: Rename pnv_ocxl_spa_remove_pe to clarify it's action
  ocxl: Expose the thread_id needed for wait on POWER9
  ocxl: Add an IOCTL so userspace knows what OCXL features are available
  ocxl: Document new OCXL IOCTLs

 Documentation/accelerators/ocxl.rst   |  11 
 arch/powerpc/include/asm/cputable.h   |   3 +-
 arch/powerpc/include/asm/pnv-ocxl.h   |   2 +-
 arch/powerpc/include/asm/switch_to.h  |   1 -
 arch/powerpc/kernel/dt_cpu_ftrs.c |   1 +
 arch/powerpc/kernel/process.c | 101 +-
 arch/powerpc/platforms/powernv/ocxl.c |   4 +-
 drivers/misc/ocxl/context.c   |   5 +-
 drivers/misc/ocxl/file.c  |  78 ++
 drivers/misc/ocxl/link.c  |  38 -
 drivers/misc/ocxl/ocxl_internal.h |   1 +
 include/misc/ocxl.h   |   9 +++
 include/uapi/misc/ocxl.h  |  14 +
 13 files changed, 163 insertions(+), 105 deletions(-)

-- 
2.14.3

[PATCH v4 4/7] ocxl: Rename pnv_ocxl_spa_remove_pe to clarify it's action

[Alastair D'Silva]

From: Alastair D'Silva 

The function removes the process element from NPU cache.

Signed-off-by: Alastair D'Silva 
---
 arch/powerpc/include/asm/pnv-ocxl.h   | 2 +-
 arch/powerpc/platforms/powernv/ocxl.c | 4 ++--
 drivers/misc/ocxl/link.c  | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/pnv-ocxl.h 
b/arch/powerpc/include/asm/pnv-ocxl.h
index f6945d3bc971..208b5503f4ed 100644
--- a/arch/powerpc/include/asm/pnv-ocxl.h
+++ b/arch/powerpc/include/asm/pnv-ocxl.h
@@ -28,7 +28,7 @@ extern int pnv_ocxl_map_xsl_regs(struct pci_dev *dev, void 
__iomem **dsisr,
 extern int pnv_ocxl_spa_setup(struct pci_dev *dev, void *spa_mem, int PE_mask,
void **platform_data);
 extern void pnv_ocxl_spa_release(void *platform_data);
-extern int pnv_ocxl_spa_remove_pe(void *platform_data, int pe_handle);
+extern int pnv_ocxl_spa_remove_pe_from_cache(void *platform_data, int 
pe_handle);
 
 extern int pnv_ocxl_alloc_xive_irq(u32 *irq, u64 *trigger_addr);
 extern void pnv_ocxl_free_xive_irq(u32 irq);
diff --git a/arch/powerpc/platforms/powernv/ocxl.c 
b/arch/powerpc/platforms/powernv/ocxl.c
index fa9b53af3c7b..8c65aacda9c8 100644
--- a/arch/powerpc/platforms/powernv/ocxl.c
+++ b/arch/powerpc/platforms/powernv/ocxl.c
@@ -475,7 +475,7 @@ void pnv_ocxl_spa_release(void *platform_data)
 }
 EXPORT_SYMBOL_GPL(pnv_ocxl_spa_release);
 
-int pnv_ocxl_spa_remove_pe(void *platform_data, int pe_handle)
+int pnv_ocxl_spa_remove_pe_from_cache(void *platform_data, int pe_handle)
 {
struct spa_data *data = (struct spa_data *) platform_data;
int rc;
@@ -483,7 +483,7 @@ int pnv_ocxl_spa_remove_pe(void *platform_data, int 
pe_handle)
rc = opal_npu_spa_clear_cache(data->phb_opal_id, data->bdfn, pe_handle);
return rc;
 }
-EXPORT_SYMBOL_GPL(pnv_ocxl_spa_remove_pe);
+EXPORT_SYMBOL_GPL(pnv_ocxl_spa_remove_pe_from_cache);
 
 int pnv_ocxl_alloc_xive_irq(u32 *irq, u64 *trigger_addr)
 {
diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c
index f30790582dc0..656e8610eec2 100644
--- a/drivers/misc/ocxl/link.c
+++ b/drivers/misc/ocxl/link.c
@@ -599,7 +599,7 @@ int ocxl_link_remove_pe(void *link_handle, int pasid)
 * On powerpc, the entry needs to be cleared from the context
 * cache of the NPU.
 */
-   rc = pnv_ocxl_spa_remove_pe(link->platform_data, pe_handle);
+   rc = pnv_ocxl_spa_remove_pe_from_cache(link->platform_data, pe_handle);
WARN_ON(rc);
 
pe_data = radix_tree_delete(>pe_tree, pe_handle);
-- 
2.14.3

[PATCH v4 0/7] ocxl: Implement Power9 as_notify/wait for OpenCAPI

[Alastair D'Silva]

From: Alastair D'Silva 

The Power 9 as_notify/wait feature provides a lower latency way to
signal a thread that work is complete. This series enables the use of
this feature from OpenCAPI adapters, as well as addressing a potential
starvation issue when allocating thread IDs.

Changelog:
v4:
  Remove the "unique" statement from the set_thread_tidr function and
move the text explaining why it is safe from the commit message
to the function description
v3:
  Fix references to POWER9
  Remove stray whitespace edit from docs
  Add more details to commit message for "use task_pid_nr()"
  Retitle patch 6 to indicate OCXL rather than CPU features
v2:
  Rename get_platform IOCTL to get_features
  Move stray edit from patch 1 to patch 3

Alastair D'Silva (7):
  powerpc: Add TIDR CPU feature for POWER9
  powerpc: Use TIDR CPU feature to control TIDR allocation
  powerpc: use task_pid_nr() for TID allocation
  ocxl: Rename pnv_ocxl_spa_remove_pe to clarify it's action
  ocxl: Expose the thread_id needed for wait on POWER9
  ocxl: Add an IOCTL so userspace knows what OCXL features are available
  ocxl: Document new OCXL IOCTLs

 Documentation/accelerators/ocxl.rst   |  11 
 arch/powerpc/include/asm/cputable.h   |   3 +-
 arch/powerpc/include/asm/pnv-ocxl.h   |   2 +-
 arch/powerpc/include/asm/switch_to.h  |   1 -
 arch/powerpc/kernel/dt_cpu_ftrs.c |   1 +
 arch/powerpc/kernel/process.c | 101 +-
 arch/powerpc/platforms/powernv/ocxl.c |   4 +-
 drivers/misc/ocxl/context.c   |   5 +-
 drivers/misc/ocxl/file.c  |  78 ++
 drivers/misc/ocxl/link.c  |  38 -
 drivers/misc/ocxl/ocxl_internal.h |   1 +
 include/misc/ocxl.h   |   9 +++
 include/uapi/misc/ocxl.h  |  14 +
 13 files changed, 163 insertions(+), 105 deletions(-)

-- 
2.14.3

[PATCH v4 3/7] powerpc: use task_pid_nr() for TID allocation

[Alastair D'Silva]

From: Alastair D'Silva 

The current implementation of TID allocation, using a global IDR, may
result in an errant process starving the system of available TIDs.
Instead, use task_pid_nr(), as mentioned by the original author. The
scenario described which prevented it's use is not applicable, as
set_thread_tidr can only be called after the task struct has been
populated.

In the unlikely event that 2 threads share the TID and are waiting,
all potential outcomes have been determined safe.

Signed-off-by: Alastair D'Silva 
---
 arch/powerpc/include/asm/switch_to.h |   1 -
 arch/powerpc/kernel/process.c| 122 ---
 2 files changed, 28 insertions(+), 95 deletions(-)

diff --git a/arch/powerpc/include/asm/switch_to.h 
b/arch/powerpc/include/asm/switch_to.h
index be8c9fa23983..5b03d8a82409 100644
--- a/arch/powerpc/include/asm/switch_to.h
+++ b/arch/powerpc/include/asm/switch_to.h
@@ -94,6 +94,5 @@ static inline void clear_task_ebb(struct task_struct *t)
 extern int set_thread_uses_vas(void);
 
 extern int set_thread_tidr(struct task_struct *t);
-extern void clear_thread_tidr(struct task_struct *t);
 
 #endif /* _ASM_POWERPC_SWITCH_TO_H */
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 3b00da47699b..c5b8e53acbae 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1496,103 +1496,41 @@ int set_thread_uses_vas(void)
 }
 
 #ifdef CONFIG_PPC64
-static DEFINE_SPINLOCK(vas_thread_id_lock);
-static DEFINE_IDA(vas_thread_ida);
-
-/*
- * We need to assign a unique thread id to each thread in a process.
+/**
+ * Assign a TIDR (thread ID) for task @t and set it in the thread
+ * structure. For now, we only support setting TIDR for 'current' task.
  *
- * This thread id, referred to as TIDR, and separate from the Linux's tgid,
- * is intended to be used to direct an ASB_Notify from the hardware to the
- * thread, when a suitable event occurs in the system.
+ * Since the TID value is a truncated form of it PID, it is possible
+ * (but unlikely) for 2 threads to have the same TID. In the unlikely event
+ * that 2 threads share the same TID and are waiting, one of the following
+ * cases will happen:
  *
- * One such event is a "paste" instruction in the context of Fast Thread
- * Wakeup (aka Core-to-core wake up in the Virtual Accelerator Switchboard
- * (VAS) in POWER9.
+ * 1. The correct thread is running, the wrong thread is not
+ * In this situation, the correct thread is woken and proceeds to pass it's
+ * condition check.
  *
- * To get a unique TIDR per process we could simply reuse task_pid_nr() but
- * the problem is that task_pid_nr() is not yet available copy_thread() is
- * called. Fixing that would require changing more intrusive arch-neutral
- * code in code path in copy_process()?.
+ * 2. Neither threads are running
+ * In this situation, neither thread will be woken. When scheduled, the waiting
+ * threads will execute either a wait, which will return immediately, followed
+ * by a condition check, which will pass for the correct thread and fail
+ * for the wrong thread, or they will execute the condition check immediately.
  *
- * Further, to assign unique TIDRs within each process, we need an atomic
- * field (or an IDR) in task_struct, which again intrudes into the arch-
- * neutral code. So try to assign globally unique TIDRs for now.
+ * 3. The wrong thread is running, the correct thread is not
+ * The wrong thread will be woken, but will fail it's condition check and
+ * re-execute wait. The correct thread, when scheduled, will execute either
+ * it's condition check (which will pass), or wait, which returns immediately
+ * when called the first time after the thread is scheduled, followed by it's
+ * condition check (which will pass).
  *
- * NOTE: TIDR 0 indicates that the thread does not need a TIDR value.
- *  For now, only threads that expect to be notified by the VAS
- *  hardware need a TIDR value and we assign values > 0 for those.
- */
-#define MAX_THREAD_CONTEXT ((1 << 16) - 1)
-static int assign_thread_tidr(void)
-{
-   int index;
-   int err;
-   unsigned long flags;
-
-again:
-   if (!ida_pre_get(_thread_ida, GFP_KERNEL))
-   return -ENOMEM;
-
-   spin_lock_irqsave(_thread_id_lock, flags);
-   err = ida_get_new_above(_thread_ida, 1, );
-   spin_unlock_irqrestore(_thread_id_lock, flags);
-
-   if (err == -EAGAIN)
-   goto again;
-   else if (err)
-   return err;
-
-   if (index > MAX_THREAD_CONTEXT) {
-   spin_lock_irqsave(_thread_id_lock, flags);
-   ida_remove(_thread_ida, index);
-   spin_unlock_irqrestore(_thread_id_lock, flags);
-   return -ENOMEM;
-   }
-
-   return index;
-}
-
-static void free_thread_tidr(int id)
-{
-   unsigned long flags;
-
-   spin_lock_irqsave(_thread_id_lock, flags);
-  

[PATCH v4 3/7] powerpc: use task_pid_nr() for TID allocation

[Alastair D'Silva]

From: Alastair D'Silva 

The current implementation of TID allocation, using a global IDR, may
result in an errant process starving the system of available TIDs.
Instead, use task_pid_nr(), as mentioned by the original author. The
scenario described which prevented it's use is not applicable, as
set_thread_tidr can only be called after the task struct has been
populated.

In the unlikely event that 2 threads share the TID and are waiting,
all potential outcomes have been determined safe.

Signed-off-by: Alastair D'Silva 
---
 arch/powerpc/include/asm/switch_to.h |   1 -
 arch/powerpc/kernel/process.c| 122 ---
 2 files changed, 28 insertions(+), 95 deletions(-)

diff --git a/arch/powerpc/include/asm/switch_to.h 
b/arch/powerpc/include/asm/switch_to.h
index be8c9fa23983..5b03d8a82409 100644
--- a/arch/powerpc/include/asm/switch_to.h
+++ b/arch/powerpc/include/asm/switch_to.h
@@ -94,6 +94,5 @@ static inline void clear_task_ebb(struct task_struct *t)
 extern int set_thread_uses_vas(void);
 
 extern int set_thread_tidr(struct task_struct *t);
-extern void clear_thread_tidr(struct task_struct *t);
 
 #endif /* _ASM_POWERPC_SWITCH_TO_H */
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 3b00da47699b..c5b8e53acbae 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1496,103 +1496,41 @@ int set_thread_uses_vas(void)
 }
 
 #ifdef CONFIG_PPC64
-static DEFINE_SPINLOCK(vas_thread_id_lock);
-static DEFINE_IDA(vas_thread_ida);
-
-/*
- * We need to assign a unique thread id to each thread in a process.
+/**
+ * Assign a TIDR (thread ID) for task @t and set it in the thread
+ * structure. For now, we only support setting TIDR for 'current' task.
  *
- * This thread id, referred to as TIDR, and separate from the Linux's tgid,
- * is intended to be used to direct an ASB_Notify from the hardware to the
- * thread, when a suitable event occurs in the system.
+ * Since the TID value is a truncated form of it PID, it is possible
+ * (but unlikely) for 2 threads to have the same TID. In the unlikely event
+ * that 2 threads share the same TID and are waiting, one of the following
+ * cases will happen:
  *
- * One such event is a "paste" instruction in the context of Fast Thread
- * Wakeup (aka Core-to-core wake up in the Virtual Accelerator Switchboard
- * (VAS) in POWER9.
+ * 1. The correct thread is running, the wrong thread is not
+ * In this situation, the correct thread is woken and proceeds to pass it's
+ * condition check.
  *
- * To get a unique TIDR per process we could simply reuse task_pid_nr() but
- * the problem is that task_pid_nr() is not yet available copy_thread() is
- * called. Fixing that would require changing more intrusive arch-neutral
- * code in code path in copy_process()?.
+ * 2. Neither threads are running
+ * In this situation, neither thread will be woken. When scheduled, the waiting
+ * threads will execute either a wait, which will return immediately, followed
+ * by a condition check, which will pass for the correct thread and fail
+ * for the wrong thread, or they will execute the condition check immediately.
  *
- * Further, to assign unique TIDRs within each process, we need an atomic
- * field (or an IDR) in task_struct, which again intrudes into the arch-
- * neutral code. So try to assign globally unique TIDRs for now.
+ * 3. The wrong thread is running, the correct thread is not
+ * The wrong thread will be woken, but will fail it's condition check and
+ * re-execute wait. The correct thread, when scheduled, will execute either
+ * it's condition check (which will pass), or wait, which returns immediately
+ * when called the first time after the thread is scheduled, followed by it's
+ * condition check (which will pass).
  *
- * NOTE: TIDR 0 indicates that the thread does not need a TIDR value.
- *  For now, only threads that expect to be notified by the VAS
- *  hardware need a TIDR value and we assign values > 0 for those.
- */
-#define MAX_THREAD_CONTEXT ((1 << 16) - 1)
-static int assign_thread_tidr(void)
-{
-   int index;
-   int err;
-   unsigned long flags;
-
-again:
-   if (!ida_pre_get(_thread_ida, GFP_KERNEL))
-   return -ENOMEM;
-
-   spin_lock_irqsave(_thread_id_lock, flags);
-   err = ida_get_new_above(_thread_ida, 1, );
-   spin_unlock_irqrestore(_thread_id_lock, flags);
-
-   if (err == -EAGAIN)
-   goto again;
-   else if (err)
-   return err;
-
-   if (index > MAX_THREAD_CONTEXT) {
-   spin_lock_irqsave(_thread_id_lock, flags);
-   ida_remove(_thread_ida, index);
-   spin_unlock_irqrestore(_thread_id_lock, flags);
-   return -ENOMEM;
-   }
-
-   return index;
-}
-
-static void free_thread_tidr(int id)
-{
-   unsigned long flags;
-
-   spin_lock_irqsave(_thread_id_lock, flags);
-   ida_remove(_thread_ida, id);
-   

[PATCH v4 6/7] ocxl: Add an IOCTL so userspace knows what OCXL features are available

[Alastair D'Silva]

From: Alastair D'Silva 

In order for a userspace AFU driver to call the POWER9 specific
OCXL_IOCTL_ENABLE_P9_WAIT, it needs to verify that it can actually
make that call.

Signed-off-by: Alastair D'Silva 
---
 drivers/misc/ocxl/file.c | 25 +
 include/uapi/misc/ocxl.h |  4 
 2 files changed, 29 insertions(+)

diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
index eb409a469f21..33ae46ce0a8a 100644
--- a/drivers/misc/ocxl/file.c
+++ b/drivers/misc/ocxl/file.c
@@ -168,12 +168,32 @@ static long afu_ioctl_enable_p9_wait(struct ocxl_context 
*ctx,
 }
 #endif
 
+
+static long afu_ioctl_get_features(struct ocxl_context *ctx,
+   struct ocxl_ioctl_features __user *uarg)
+{
+   struct ocxl_ioctl_features arg;
+
+   memset(, 0, sizeof(arg));
+
+#ifdef CONFIG_PPC64
+   if (cpu_has_feature(CPU_FTR_P9_TIDR))
+   arg.flags[0] |= OCXL_IOCTL_FEATURES_FLAGS0_P9_WAIT;
+#endif
+
+   if (copy_to_user(uarg, , sizeof(arg)))
+   return -EFAULT;
+
+   return 0;
+}
+
 #define CMD_STR(x) (x == OCXL_IOCTL_ATTACH ? "ATTACH" :
\
x == OCXL_IOCTL_IRQ_ALLOC ? "IRQ_ALLOC" :   \
x == OCXL_IOCTL_IRQ_FREE ? "IRQ_FREE" : \
x == OCXL_IOCTL_IRQ_SET_FD ? "IRQ_SET_FD" : \
x == OCXL_IOCTL_GET_METADATA ? "GET_METADATA" : \
x == OCXL_IOCTL_ENABLE_P9_WAIT ? "ENABLE_P9_WAIT" : 
\
+   x == OCXL_IOCTL_GET_FEATURES ? "GET_FEATURES" : \
"UNKNOWN")
 
 static long afu_ioctl(struct file *file, unsigned int cmd,
@@ -239,6 +259,11 @@ static long afu_ioctl(struct file *file, unsigned int cmd,
break;
 #endif
 
+   case OCXL_IOCTL_GET_FEATURES:
+   rc = afu_ioctl_get_features(ctx,
+   (struct ocxl_ioctl_features __user *) args);
+   break;
+
default:
rc = -EINVAL;
}
diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
index 8d2748e69c84..bb80f294b429 100644
--- a/include/uapi/misc/ocxl.h
+++ b/include/uapi/misc/ocxl.h
@@ -55,6 +55,9 @@ struct ocxl_ioctl_p9_wait {
__u64 reserved3[3];
 };
 
+#define OCXL_IOCTL_FEATURES_FLAGS0_P9_WAIT 0x01
+struct ocxl_ioctl_features {
+   __u64 flags[4];
 };
 
 struct ocxl_ioctl_irq_fd {
@@ -72,5 +75,6 @@ struct ocxl_ioctl_irq_fd {
 #define OCXL_IOCTL_IRQ_SET_FD  _IOW(OCXL_MAGIC, 0x13, struct ocxl_ioctl_irq_fd)
 #define OCXL_IOCTL_GET_METADATA _IOR(OCXL_MAGIC, 0x14, struct 
ocxl_ioctl_metadata)
 #define OCXL_IOCTL_ENABLE_P9_WAIT  _IOR(OCXL_MAGIC, 0x15, struct 
ocxl_ioctl_p9_wait)
+#define OCXL_IOCTL_GET_FEATURES _IOR(OCXL_MAGIC, 0x16, struct 
ocxl_ioctl_platform)
 
 #endif /* _UAPI_MISC_OCXL_H */
-- 
2.14.3

[PATCH v4 6/7] ocxl: Add an IOCTL so userspace knows what OCXL features are available

[Alastair D'Silva]

From: Alastair D'Silva 

In order for a userspace AFU driver to call the POWER9 specific
OCXL_IOCTL_ENABLE_P9_WAIT, it needs to verify that it can actually
make that call.

Signed-off-by: Alastair D'Silva 
---
 drivers/misc/ocxl/file.c | 25 +
 include/uapi/misc/ocxl.h |  4 
 2 files changed, 29 insertions(+)

diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
index eb409a469f21..33ae46ce0a8a 100644
--- a/drivers/misc/ocxl/file.c
+++ b/drivers/misc/ocxl/file.c
@@ -168,12 +168,32 @@ static long afu_ioctl_enable_p9_wait(struct ocxl_context 
*ctx,
 }
 #endif
 
+
+static long afu_ioctl_get_features(struct ocxl_context *ctx,
+   struct ocxl_ioctl_features __user *uarg)
+{
+   struct ocxl_ioctl_features arg;
+
+   memset(, 0, sizeof(arg));
+
+#ifdef CONFIG_PPC64
+   if (cpu_has_feature(CPU_FTR_P9_TIDR))
+   arg.flags[0] |= OCXL_IOCTL_FEATURES_FLAGS0_P9_WAIT;
+#endif
+
+   if (copy_to_user(uarg, , sizeof(arg)))
+   return -EFAULT;
+
+   return 0;
+}
+
 #define CMD_STR(x) (x == OCXL_IOCTL_ATTACH ? "ATTACH" :
\
x == OCXL_IOCTL_IRQ_ALLOC ? "IRQ_ALLOC" :   \
x == OCXL_IOCTL_IRQ_FREE ? "IRQ_FREE" : \
x == OCXL_IOCTL_IRQ_SET_FD ? "IRQ_SET_FD" : \
x == OCXL_IOCTL_GET_METADATA ? "GET_METADATA" : \
x == OCXL_IOCTL_ENABLE_P9_WAIT ? "ENABLE_P9_WAIT" : 
\
+   x == OCXL_IOCTL_GET_FEATURES ? "GET_FEATURES" : \
"UNKNOWN")
 
 static long afu_ioctl(struct file *file, unsigned int cmd,
@@ -239,6 +259,11 @@ static long afu_ioctl(struct file *file, unsigned int cmd,
break;
 #endif
 
+   case OCXL_IOCTL_GET_FEATURES:
+   rc = afu_ioctl_get_features(ctx,
+   (struct ocxl_ioctl_features __user *) args);
+   break;
+
default:
rc = -EINVAL;
}
diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
index 8d2748e69c84..bb80f294b429 100644
--- a/include/uapi/misc/ocxl.h
+++ b/include/uapi/misc/ocxl.h
@@ -55,6 +55,9 @@ struct ocxl_ioctl_p9_wait {
__u64 reserved3[3];
 };
 
+#define OCXL_IOCTL_FEATURES_FLAGS0_P9_WAIT 0x01
+struct ocxl_ioctl_features {
+   __u64 flags[4];
 };
 
 struct ocxl_ioctl_irq_fd {
@@ -72,5 +75,6 @@ struct ocxl_ioctl_irq_fd {
 #define OCXL_IOCTL_IRQ_SET_FD  _IOW(OCXL_MAGIC, 0x13, struct ocxl_ioctl_irq_fd)
 #define OCXL_IOCTL_GET_METADATA _IOR(OCXL_MAGIC, 0x14, struct 
ocxl_ioctl_metadata)
 #define OCXL_IOCTL_ENABLE_P9_WAIT  _IOR(OCXL_MAGIC, 0x15, struct 
ocxl_ioctl_p9_wait)
+#define OCXL_IOCTL_GET_FEATURES _IOR(OCXL_MAGIC, 0x16, struct 
ocxl_ioctl_platform)
 
 #endif /* _UAPI_MISC_OCXL_H */
-- 
2.14.3

[PATCH v4 2/7] powerpc: Use TIDR CPU feature to control TIDR allocation

[Alastair D'Silva]

From: Alastair D'Silva 

Switch the use of TIDR on it's CPU feature, rather than assuming it
is available based on architecture.

Signed-off-by: Alastair D'Silva 
---
 arch/powerpc/kernel/process.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 1237f13fed51..3b00da47699b 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1154,7 +1154,7 @@ static inline void restore_sprs(struct thread_struct 
*old_thread,
mtspr(SPRN_TAR, new_thread->tar);
}
 
-   if (cpu_has_feature(CPU_FTR_ARCH_300) &&
+   if (cpu_has_feature(CPU_FTR_P9_TIDR) &&
old_thread->tidr != new_thread->tidr)
mtspr(SPRN_TIDR, new_thread->tidr);
 #endif
@@ -1570,7 +1570,7 @@ void clear_thread_tidr(struct task_struct *t)
if (!t->thread.tidr)
return;
 
-   if (!cpu_has_feature(CPU_FTR_ARCH_300)) {
+   if (!cpu_has_feature(CPU_FTR_P9_TIDR)) {
WARN_ON_ONCE(1);
return;
}
@@ -1593,7 +1593,7 @@ int set_thread_tidr(struct task_struct *t)
 {
int rc;
 
-   if (!cpu_has_feature(CPU_FTR_ARCH_300))
+   if (!cpu_has_feature(CPU_FTR_P9_TIDR))
return -EINVAL;
 
if (t != current)
-- 
2.14.3

[PATCH v4 2/7] powerpc: Use TIDR CPU feature to control TIDR allocation

[Alastair D'Silva]

From: Alastair D'Silva 

Switch the use of TIDR on it's CPU feature, rather than assuming it
is available based on architecture.

Signed-off-by: Alastair D'Silva 
---
 arch/powerpc/kernel/process.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 1237f13fed51..3b00da47699b 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1154,7 +1154,7 @@ static inline void restore_sprs(struct thread_struct 
*old_thread,
mtspr(SPRN_TAR, new_thread->tar);
}
 
-   if (cpu_has_feature(CPU_FTR_ARCH_300) &&
+   if (cpu_has_feature(CPU_FTR_P9_TIDR) &&
old_thread->tidr != new_thread->tidr)
mtspr(SPRN_TIDR, new_thread->tidr);
 #endif
@@ -1570,7 +1570,7 @@ void clear_thread_tidr(struct task_struct *t)
if (!t->thread.tidr)
return;
 
-   if (!cpu_has_feature(CPU_FTR_ARCH_300)) {
+   if (!cpu_has_feature(CPU_FTR_P9_TIDR)) {
WARN_ON_ONCE(1);
return;
}
@@ -1593,7 +1593,7 @@ int set_thread_tidr(struct task_struct *t)
 {
int rc;
 
-   if (!cpu_has_feature(CPU_FTR_ARCH_300))
+   if (!cpu_has_feature(CPU_FTR_P9_TIDR))
return -EINVAL;
 
if (t != current)
-- 
2.14.3

Re: [PATCH] isdn: eicon: fix a missing-check bug

[Wenwen Wang]

Hello

Could you please review this patch? We need a confirmation because we
are working on an approaching deadline.

Thanks!
Wenwen

On Sat, May 5, 2018 at 2:32 PM, Wenwen Wang  wrote:
> In divasmain.c, the function divas_write() firstly invokes the function
> diva_xdi_open_adapter() to open the adapter that matches with the adapter
> number provided by the user, and then invokes the function diva_xdi_write()
> to perform the write operation using the matched adapter. The two functions
> diva_xdi_open_adapter() and diva_xdi_write() are located in diva.c.
>
> In diva_xdi_open_adapter(), the user command is copied to the object 'msg'
> from the userspace pointer 'src' through the function pointer 'cp_fn',
> which eventually calls copy_from_user() to do the copy. Then, the adapter
> number 'msg.adapter' is used to find out a matched adapter from the
> 'adapter_queue'. A matched adapter will be returned if it is found.
> Otherwise, NULL is returned to indicate the failure of the verification on
> the adapter number.
>
> As mentioned above, if a matched adapter is returned, the function
> diva_xdi_write() is invoked to perform the write operation. In this
> function, the user command is copied once again from the userspace pointer
> 'src', which is the same as the 'src' pointer in diva_xdi_open_adapter() as
> both of them are from the 'buf' pointer in divas_write(). Similarly, the
> copy is achieved through the function pointer 'cp_fn', which finally calls
> copy_from_user(). After the successful copy, the corresponding command
> processing handler of the matched adapter is invoked to perform the write
> operation.
>
> It is obvious that there are two copies here from userspace, one is in
> diva_xdi_open_adapter(), and one is in diva_xdi_write(). Plus, both of
> these two copies share the same source userspace pointer, i.e., the 'buf'
> pointer in divas_write(). Given that a malicious userspace process can race
> to change the content pointed by the 'buf' pointer, this can pose potential
> security issues. For example, in the first copy, the user provides a valid
> adapter number to pass the verification process and a valid adapter can be
> found. Then the user can modify the adapter number to an invalid number.
> This way, the user can bypass the verification process of the adapter
> number and inject inconsistent data.
>
> To avoid such issues, this patch adds a check after the second copy in the
> function diva_xdi_write(). If the adapter number is not equal to the one
> obtained in the first copy, (-4) will be returned to divas_write(), which
> will then return an error code -EINVAL.
>
> Signed-off-by: Wenwen Wang 
> ---
>  drivers/isdn/hardware/eicon/diva.c  | 6 +-
>  drivers/isdn/hardware/eicon/divasmain.c | 3 +++
>  2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/isdn/hardware/eicon/diva.c 
> b/drivers/isdn/hardware/eicon/diva.c
> index 944a7f3..46cbf76 100644
> --- a/drivers/isdn/hardware/eicon/diva.c
> +++ b/drivers/isdn/hardware/eicon/diva.c
> @@ -440,6 +440,7 @@ diva_xdi_write(void *adapter, void *os_handle, const void 
> __user *src,
>int length, divas_xdi_copy_from_user_fn_t cp_fn)
>  {
> diva_os_xdi_adapter_t *a = (diva_os_xdi_adapter_t *) adapter;
> +   diva_xdi_um_cfg_cmd_t *p;
> void *data;
>
> if (a->xdi_mbox.status & DIVA_XDI_MBOX_BUSY) {
> @@ -461,7 +462,10 @@ diva_xdi_write(void *adapter, void *os_handle, const 
> void __user *src,
>
> length = (*cp_fn) (os_handle, data, src, length);
> if (length > 0) {
> -   if ((*(a->interface.cmd_proc))
> +   p = (diva_xdi_um_cfg_cmd_t *) data;
> +   if (a->controller != (int)p->adapter) {
> +   length = -4;
> +   } else if ((*(a->interface.cmd_proc))
> (a, (diva_xdi_um_cfg_cmd_t *) data, length)) {
> length = -3;
> }
> diff --git a/drivers/isdn/hardware/eicon/divasmain.c 
> b/drivers/isdn/hardware/eicon/divasmain.c
> index b9980e8..a03c658 100644
> --- a/drivers/isdn/hardware/eicon/divasmain.c
> +++ b/drivers/isdn/hardware/eicon/divasmain.c
> @@ -614,6 +614,9 @@ static ssize_t divas_write(struct file *file, const char 
> __user *buf,
> case -3:
> ret = -ENXIO;
> break;
> +   case -4:
> +   ret = -EINVAL;
> +   break;
> }
> DBG_TRC(("write: ret %d", ret));
> return (ret);
> --
> 2.7.4
>

Re: [PATCH] isdn: eicon: fix a missing-check bug

[Wenwen Wang]

Hello

Could you please review this patch? We need a confirmation because we
are working on an approaching deadline.

Thanks!
Wenwen

On Sat, May 5, 2018 at 2:32 PM, Wenwen Wang  wrote:
> In divasmain.c, the function divas_write() firstly invokes the function
> diva_xdi_open_adapter() to open the adapter that matches with the adapter
> number provided by the user, and then invokes the function diva_xdi_write()
> to perform the write operation using the matched adapter. The two functions
> diva_xdi_open_adapter() and diva_xdi_write() are located in diva.c.
>
> In diva_xdi_open_adapter(), the user command is copied to the object 'msg'
> from the userspace pointer 'src' through the function pointer 'cp_fn',
> which eventually calls copy_from_user() to do the copy. Then, the adapter
> number 'msg.adapter' is used to find out a matched adapter from the
> 'adapter_queue'. A matched adapter will be returned if it is found.
> Otherwise, NULL is returned to indicate the failure of the verification on
> the adapter number.
>
> As mentioned above, if a matched adapter is returned, the function
> diva_xdi_write() is invoked to perform the write operation. In this
> function, the user command is copied once again from the userspace pointer
> 'src', which is the same as the 'src' pointer in diva_xdi_open_adapter() as
> both of them are from the 'buf' pointer in divas_write(). Similarly, the
> copy is achieved through the function pointer 'cp_fn', which finally calls
> copy_from_user(). After the successful copy, the corresponding command
> processing handler of the matched adapter is invoked to perform the write
> operation.
>
> It is obvious that there are two copies here from userspace, one is in
> diva_xdi_open_adapter(), and one is in diva_xdi_write(). Plus, both of
> these two copies share the same source userspace pointer, i.e., the 'buf'
> pointer in divas_write(). Given that a malicious userspace process can race
> to change the content pointed by the 'buf' pointer, this can pose potential
> security issues. For example, in the first copy, the user provides a valid
> adapter number to pass the verification process and a valid adapter can be
> found. Then the user can modify the adapter number to an invalid number.
> This way, the user can bypass the verification process of the adapter
> number and inject inconsistent data.
>
> To avoid such issues, this patch adds a check after the second copy in the
> function diva_xdi_write(). If the adapter number is not equal to the one
> obtained in the first copy, (-4) will be returned to divas_write(), which
> will then return an error code -EINVAL.
>
> Signed-off-by: Wenwen Wang 
> ---
>  drivers/isdn/hardware/eicon/diva.c  | 6 +-
>  drivers/isdn/hardware/eicon/divasmain.c | 3 +++
>  2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/isdn/hardware/eicon/diva.c 
> b/drivers/isdn/hardware/eicon/diva.c
> index 944a7f3..46cbf76 100644
> --- a/drivers/isdn/hardware/eicon/diva.c
> +++ b/drivers/isdn/hardware/eicon/diva.c
> @@ -440,6 +440,7 @@ diva_xdi_write(void *adapter, void *os_handle, const void 
> __user *src,
>int length, divas_xdi_copy_from_user_fn_t cp_fn)
>  {
> diva_os_xdi_adapter_t *a = (diva_os_xdi_adapter_t *) adapter;
> +   diva_xdi_um_cfg_cmd_t *p;
> void *data;
>
> if (a->xdi_mbox.status & DIVA_XDI_MBOX_BUSY) {
> @@ -461,7 +462,10 @@ diva_xdi_write(void *adapter, void *os_handle, const 
> void __user *src,
>
> length = (*cp_fn) (os_handle, data, src, length);
> if (length > 0) {
> -   if ((*(a->interface.cmd_proc))
> +   p = (diva_xdi_um_cfg_cmd_t *) data;
> +   if (a->controller != (int)p->adapter) {
> +   length = -4;
> +   } else if ((*(a->interface.cmd_proc))
> (a, (diva_xdi_um_cfg_cmd_t *) data, length)) {
> length = -3;
> }
> diff --git a/drivers/isdn/hardware/eicon/divasmain.c 
> b/drivers/isdn/hardware/eicon/divasmain.c
> index b9980e8..a03c658 100644
> --- a/drivers/isdn/hardware/eicon/divasmain.c
> +++ b/drivers/isdn/hardware/eicon/divasmain.c
> @@ -614,6 +614,9 @@ static ssize_t divas_write(struct file *file, const char 
> __user *buf,
> case -3:
> ret = -ENXIO;
> break;
> +   case -4:
> +   ret = -EINVAL;
> +   break;
> }
> DBG_TRC(("write: ret %d", ret));
> return (ret);
> --
> 2.7.4
>

Re: [PATCH V2 3/5] backlight: qcom-wled: Add support for short circuit handling

[kgunda]

On 2018-05-08 16:05, Daniel Thompson wrote:

On Thu, May 03, 2018 at 03:42:30PM +0530, Kiran Gunda wrote:

Handle the short circuit interrupt and check if the short circuit
interrupt is valid. Re-enable the module to check if it goes
away. Disable the module altogether if the short circuit event
persists.

Signed-off-by: Kiran Gunda 
---
 drivers/video/backlight/qcom-wled.c | 134 
++--

 1 file changed, 130 insertions(+), 4 deletions(-)

diff --git a/drivers/video/backlight/qcom-wled.c 
b/drivers/video/backlight/qcom-wled.c

index be8b8d3..2cfba77 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -10,6 +10,9 @@
  * GNU General Public License for more details.
  */

+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -23,7 +26,9 @@

 #define WLED3_SINK_REG_BRIGHT_MAX  0xFFF

-/* Control registers */
+/* WLED3 Control registers */
+#define WLED3_CTRL_REG_FAULT_STATUS0x08
+
 #define WLED3_CTRL_REG_MOD_EN  0x46
 #define  WLED3_CTRL_REG_MOD_EN_MASKBIT(7)

@@ -36,7 +41,17 @@
 #define WLED3_CTRL_REG_ILIMIT  0x4e
 #define  WLED3_CTRL_REG_ILIMIT_MASKGENMASK(2, 0)

-/* sink registers */
+/* WLED4 control registers */
+#define WLED4_CTRL_REG_SHORT_PROTECT   0x5e
+#define  WLED4_CTRL_REG_SHORT_EN_MASK  BIT(7)
+
+#define WLED4_CTRL_REG_SEC_ACCESS  0xd0
+#define  WLED4_CTRL_REG_SEC_UNLOCK 0xa5
+
+#define WLED4_CTRL_REG_TEST1   0xe2
+#define  WLED4_CTRL_REG_TEST1_EXT_FET_DTEST2   0x09
+
+/* WLED3 sink registers */
 #define WLED3_SINK_REG_SYNC0x47
 #define  WLED3_SINK_REG_SYNC_MASK  GENMASK(2, 0)
 #define  WLED4_SINK_REG_SYNC_MASK  GENMASK(3, 0)
@@ -130,17 +145,23 @@ struct wled_config {
bool cs_out_en;
bool ext_gen;
bool cabc;
+   bool external_pfet;
 };

 struct wled {
const char *name;
struct device *dev;
struct regmap *regmap;
+   struct mutex lock;  /* Lock to avoid race from ISR */
+   ktime_t last_short_event;
u16 ctrl_addr;
u16 sink_addr;
u32 brightness;
u32 max_brightness;
+   u32 short_count;
const int *version;
+   int short_irq;
+   bool force_mod_disable;

struct wled_config cfg;
int (*wled_set_brightness)(struct wled *wled, u16 brightness);
@@ -192,6 +213,9 @@ static int wled_module_enable(struct wled *wled, 
int val)

 {
int rc;

+   if (wled->force_mod_disable)
+   return 0;
+
rc = regmap_update_bits(wled->regmap, wled->ctrl_addr +
WLED3_CTRL_REG_MOD_EN,
WLED3_CTRL_REG_MOD_EN_MASK,
@@ -248,12 +272,13 @@ static int wled_update_status(struct 
backlight_device *bl)

bl->props.state & BL_CORE_FBBLANK)
brightness = 0;

+   mutex_lock(>lock);
if (brightness) {
rc = wled->wled_set_brightness(wled, brightness);
if (rc < 0) {
dev_err(wled->dev, "wled failed to set brightness 
rc:%d\n",
rc);
-   return rc;
+   goto unlock_mutex;
}

rc = wled->wled_sync_toggle(wled);
@@ -267,15 +292,60 @@ static int wled_update_status(struct 
backlight_device *bl)

rc = wled_module_enable(wled, !!brightness);
if (rc < 0) {
dev_err(wled->dev, "wled enable failed rc:%d\n", rc);
-   return rc;
+   goto unlock_mutex;
}
}

wled->brightness = brightness;

+unlock_mutex:
+   mutex_unlock(>lock);
+
return rc;
 }

+#define WLED_SHORT_DLY_MS  20
+#define WLED_SHORT_CNT_MAX 5
+#define WLED_SHORT_RESET_CNT_DLY_USHZ


So we think a short report every quarter second is harmless?


Yes. We wait for the short to report 5 times with in this time. If the 
short
still persists, we go and disable the WLED module to avoid the damage. 
This is

suggested by the HW team.


+static irqreturn_t wled_short_irq_handler(int irq, void *_wled)
+{
+   struct wled *wled = _wled;
+   int rc;
+   s64 elapsed_time;
+
+   wled->short_count++;
+   mutex_lock(>lock);
+   rc = wled_module_enable(wled, false);
+   if (rc < 0) {
+   dev_err(wled->dev, "wled disable failed rc:%d\n", rc);
+   goto unlock_mutex;
+   }
+
+   elapsed_time = ktime_us_delta(ktime_get(),
+ wled->last_short_event);
+   if (elapsed_time > WLED_SHORT_RESET_CNT_DLY_US)
+   

Re: [PATCH V2 3/5] backlight: qcom-wled: Add support for short circuit handling

[kgunda]

On 2018-05-08 16:05, Daniel Thompson wrote:

On Thu, May 03, 2018 at 03:42:30PM +0530, Kiran Gunda wrote:

Handle the short circuit interrupt and check if the short circuit
interrupt is valid. Re-enable the module to check if it goes
away. Disable the module altogether if the short circuit event
persists.

Signed-off-by: Kiran Gunda 
---
 drivers/video/backlight/qcom-wled.c | 134 
++--

 1 file changed, 130 insertions(+), 4 deletions(-)

diff --git a/drivers/video/backlight/qcom-wled.c 
b/drivers/video/backlight/qcom-wled.c

index be8b8d3..2cfba77 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -10,6 +10,9 @@
  * GNU General Public License for more details.
  */

+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -23,7 +26,9 @@

 #define WLED3_SINK_REG_BRIGHT_MAX  0xFFF

-/* Control registers */
+/* WLED3 Control registers */
+#define WLED3_CTRL_REG_FAULT_STATUS0x08
+
 #define WLED3_CTRL_REG_MOD_EN  0x46
 #define  WLED3_CTRL_REG_MOD_EN_MASKBIT(7)

@@ -36,7 +41,17 @@
 #define WLED3_CTRL_REG_ILIMIT  0x4e
 #define  WLED3_CTRL_REG_ILIMIT_MASKGENMASK(2, 0)

-/* sink registers */
+/* WLED4 control registers */
+#define WLED4_CTRL_REG_SHORT_PROTECT   0x5e
+#define  WLED4_CTRL_REG_SHORT_EN_MASK  BIT(7)
+
+#define WLED4_CTRL_REG_SEC_ACCESS  0xd0
+#define  WLED4_CTRL_REG_SEC_UNLOCK 0xa5
+
+#define WLED4_CTRL_REG_TEST1   0xe2
+#define  WLED4_CTRL_REG_TEST1_EXT_FET_DTEST2   0x09
+
+/* WLED3 sink registers */
 #define WLED3_SINK_REG_SYNC0x47
 #define  WLED3_SINK_REG_SYNC_MASK  GENMASK(2, 0)
 #define  WLED4_SINK_REG_SYNC_MASK  GENMASK(3, 0)
@@ -130,17 +145,23 @@ struct wled_config {
bool cs_out_en;
bool ext_gen;
bool cabc;
+   bool external_pfet;
 };

 struct wled {
const char *name;
struct device *dev;
struct regmap *regmap;
+   struct mutex lock;  /* Lock to avoid race from ISR */
+   ktime_t last_short_event;
u16 ctrl_addr;
u16 sink_addr;
u32 brightness;
u32 max_brightness;
+   u32 short_count;
const int *version;
+   int short_irq;
+   bool force_mod_disable;

struct wled_config cfg;
int (*wled_set_brightness)(struct wled *wled, u16 brightness);
@@ -192,6 +213,9 @@ static int wled_module_enable(struct wled *wled, 
int val)

 {
int rc;

+   if (wled->force_mod_disable)
+   return 0;
+
rc = regmap_update_bits(wled->regmap, wled->ctrl_addr +
WLED3_CTRL_REG_MOD_EN,
WLED3_CTRL_REG_MOD_EN_MASK,
@@ -248,12 +272,13 @@ static int wled_update_status(struct 
backlight_device *bl)

bl->props.state & BL_CORE_FBBLANK)
brightness = 0;

+   mutex_lock(>lock);
if (brightness) {
rc = wled->wled_set_brightness(wled, brightness);
if (rc < 0) {
dev_err(wled->dev, "wled failed to set brightness 
rc:%d\n",
rc);
-   return rc;
+   goto unlock_mutex;
}

rc = wled->wled_sync_toggle(wled);
@@ -267,15 +292,60 @@ static int wled_update_status(struct 
backlight_device *bl)

rc = wled_module_enable(wled, !!brightness);
if (rc < 0) {
dev_err(wled->dev, "wled enable failed rc:%d\n", rc);
-   return rc;
+   goto unlock_mutex;
}
}

wled->brightness = brightness;

+unlock_mutex:
+   mutex_unlock(>lock);
+
return rc;
 }

+#define WLED_SHORT_DLY_MS  20
+#define WLED_SHORT_CNT_MAX 5
+#define WLED_SHORT_RESET_CNT_DLY_USHZ


So we think a short report every quarter second is harmless?


Yes. We wait for the short to report 5 times with in this time. If the 
short
still persists, we go and disable the WLED module to avoid the damage. 
This is

suggested by the HW team.


+static irqreturn_t wled_short_irq_handler(int irq, void *_wled)
+{
+   struct wled *wled = _wled;
+   int rc;
+   s64 elapsed_time;
+
+   wled->short_count++;
+   mutex_lock(>lock);
+   rc = wled_module_enable(wled, false);
+   if (rc < 0) {
+   dev_err(wled->dev, "wled disable failed rc:%d\n", rc);
+   goto unlock_mutex;
+   }
+
+   elapsed_time = ktime_us_delta(ktime_get(),
+ wled->last_short_event);
+   if (elapsed_time > WLED_SHORT_RESET_CNT_DLY_US)
+   wled->short_count = 0;
+
+   

Re: [PATCH] scsi: mpt3sas: fix a missing-check bug

[Wenwen Wang]

Hello

Could you please review this patch? We need a confirmation because we
are working on an approaching deadline.

Thanks!
Wenwen

On Sat, May 5, 2018 at 1:31 AM, Wenwen Wang  wrote:
> In _ctl_ioctl_main(), 'ioctl_header' is first copied from the userspace
> pointer 'arg'. 'ioctl_header.ioc_number' is then verified by
> _ctl_verify_adapter(). If the verification is failed, an error code -ENODEV
> is returned. Otherwise, the verification result, i.e., the MPT3SAS adapter
> that matches with the 'ioctl_header.ioc_number', is saved to 'ioc'. Later
> on, if the 'cmd' is MPT3COMMAND, the whole ioctl command struct is copied
> again from the userspace pointer 'arg' and saved to 'karg'. Then the
> function _ctl_do_mpt_command() is invoked to execute the command with the
> adapter 'ioc' and 'karg' as inputs.
>
> Given that the pointer 'arg' resides in userspace, a malicious userspace
> process can race to change the 'ioc_number' between the two copies, which
> will cause inconsistency issues, potentially security issues since an
> inconsistent adapter could be used with the command struct 'karg' as inputs
> of _ctl_do_mpt_command(). Moreover, the user can potentially provide a
> valid 'ioc_number' to pass the verification, and then modify it to an
> invalid 'ioc_number'. That means, an invalid 'ioc_number' can potentially
> bypass the verification check.
>
> To fix this issue, we need to recheck the 'ioc_number' copied after the
> second copy to make sure it is not changed since the first copy.
>
> Signed-off-by: Wenwen Wang 
> ---
>  drivers/scsi/mpt3sas/mpt3sas_ctl.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c 
> b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
> index d3cb387..0c140c7 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
> @@ -2388,6 +2388,11 @@ _ctl_ioctl_main(struct file *file, unsigned int cmd, 
> void __user *arg,
> break;
> }
>
> +   if (karg.hdr.ioc_number != ioctl_header.ioc_number) {
> +   ret = -EINVAL;
> +   break;
> +   }
> +
> if (_IOC_SIZE(cmd) == sizeof(struct mpt3_ioctl_command)) {
> uarg = arg;
> ret = _ctl_do_mpt_command(ioc, karg, >mf);
> --
> 2.7.4
>

Re: [PATCH] scsi: mpt3sas: fix a missing-check bug

[Wenwen Wang]

Hello

Could you please review this patch? We need a confirmation because we
are working on an approaching deadline.

Thanks!
Wenwen

On Sat, May 5, 2018 at 1:31 AM, Wenwen Wang  wrote:
> In _ctl_ioctl_main(), 'ioctl_header' is first copied from the userspace
> pointer 'arg'. 'ioctl_header.ioc_number' is then verified by
> _ctl_verify_adapter(). If the verification is failed, an error code -ENODEV
> is returned. Otherwise, the verification result, i.e., the MPT3SAS adapter
> that matches with the 'ioctl_header.ioc_number', is saved to 'ioc'. Later
> on, if the 'cmd' is MPT3COMMAND, the whole ioctl command struct is copied
> again from the userspace pointer 'arg' and saved to 'karg'. Then the
> function _ctl_do_mpt_command() is invoked to execute the command with the
> adapter 'ioc' and 'karg' as inputs.
>
> Given that the pointer 'arg' resides in userspace, a malicious userspace
> process can race to change the 'ioc_number' between the two copies, which
> will cause inconsistency issues, potentially security issues since an
> inconsistent adapter could be used with the command struct 'karg' as inputs
> of _ctl_do_mpt_command(). Moreover, the user can potentially provide a
> valid 'ioc_number' to pass the verification, and then modify it to an
> invalid 'ioc_number'. That means, an invalid 'ioc_number' can potentially
> bypass the verification check.
>
> To fix this issue, we need to recheck the 'ioc_number' copied after the
> second copy to make sure it is not changed since the first copy.
>
> Signed-off-by: Wenwen Wang 
> ---
>  drivers/scsi/mpt3sas/mpt3sas_ctl.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c 
> b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
> index d3cb387..0c140c7 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
> @@ -2388,6 +2388,11 @@ _ctl_ioctl_main(struct file *file, unsigned int cmd, 
> void __user *arg,
> break;
> }
>
> +   if (karg.hdr.ioc_number != ioctl_header.ioc_number) {
> +   ret = -EINVAL;
> +   break;
> +   }
> +
> if (_IOC_SIZE(cmd) == sizeof(struct mpt3_ioctl_command)) {
> uarg = arg;
> ret = _ctl_do_mpt_command(ioc, karg, >mf);
> --
> 2.7.4
>

Re: BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_his

[Dmitry Vyukov]

On Wed, May 9, 2018 at 7:05 AM, Eric Biggers  wrote:
> On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:c1c07416cdd4 Merge tag 'kbuild-fixes-v4.17' of git://git.k..
>> git tree:   upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=13d5de4780
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27
>> dashboard link: https://syzkaller.appspot.com/bug?extid=99858724c0ba555a12ea
>> compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
>> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=170afde780
>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=141b4be780
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+99858724c0ba555a1...@syzkaller.appspotmail.com
>>
>> random: sshd: uninitialized urandom read (32 bytes read)
>> random: sshd: uninitialized urandom read (32 bytes read)
>> random: sshd: uninitialized urandom read (32 bytes read)
>> random: sshd: uninitialized urandom read (32 bytes read)
>> BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at
>> net/dccp/ccids/lib/packet_history.c:425/tfrc_rx_hist_sample_rtt()
>> CPU: 0 PID: 4495 Comm: syz-executor551 Not tainted 4.17.0-rc3+ #34
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>>  
>>  __dump_stack lib/dump_stack.c:77 [inline]
>>  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
>>  tfrc_rx_hist_sample_rtt.cold.3+0x54/0x5c
>> net/dccp/ccids/lib/packet_history.c:422
>>  ccid3_hc_rx_packet_recv+0x5c8/0xed0 net/dccp/ccids/ccid3.c:765
>>  ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
>>  dccp_deliver_input_to_ccids+0xf0/0x280 net/dccp/input.c:180
>>  dccp_rcv_established+0x87/0xb0 net/dccp/input.c:378
>>  dccp_v4_do_rcv+0x153/0x180 net/dccp/ipv4.c:654
>>  sk_backlog_rcv include/net/sock.h:909 [inline]
>>  __sk_receive_skb+0x3a2/0xd60 net/core/sock.c:513
>>  dccp_v4_rcv+0x10e5/0x1f3f net/dccp/ipv4.c:875
>>  ip_local_deliver_finish+0x2e3/0xd80 net/ipv4/ip_input.c:215
>>  NF_HOOK include/linux/netfilter.h:288 [inline]
>>  ip_local_deliver+0x1e1/0x720 net/ipv4/ip_input.c:256
>>  dst_input include/net/dst.h:450 [inline]
>>  ip_rcv_finish+0x81b/0x2200 net/ipv4/ip_input.c:396
>>  NF_HOOK include/linux/netfilter.h:288 [inline]
>>  ip_rcv+0xb70/0x143d net/ipv4/ip_input.c:492
>>  __netif_receive_skb_core+0x26f5/0x3630 net/core/dev.c:4592
>>  __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4657
>>  process_backlog+0x219/0x760 net/core/dev.c:5337
>>  napi_poll net/core/dev.c:5735 [inline]
>>  net_rx_action+0x7b7/0x1930 net/core/dev.c:5801
>>  __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
>>  do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1046
>>  
>>  do_softirq.part.17+0x14d/0x190 kernel/softirq.c:329
>>  do_softirq arch/x86/include/asm/preempt.h:23 [inline]
>>  __local_bh_enable_ip+0x1ec/0x230 kernel/softirq.c:182
>>  local_bh_enable include/linux/bottom_half.h:32 [inline]
>>  rcu_read_unlock_bh include/linux/rcupdate.h:728 [inline]
>>  ip_finish_output2+0xab2/0x1840 net/ipv4/ip_output.c:231
>>  ip_finish_output+0x828/0xf80 net/ipv4/ip_output.c:317
>>  NF_HOOK_COND include/linux/netfilter.h:277 [inline]
>>  ip_output+0x21b/0x850 net/ipv4/ip_output.c:405
>>  dst_output include/net/dst.h:444 [inline]
>>  ip_local_out+0xc5/0x1b0 net/ipv4/ip_output.c:124
>>  ip_queue_xmit+0x9d7/0x1f70 net/ipv4/ip_output.c:504
>>  dccp_transmit_skb+0x999/0x12e0 net/dccp/output.c:142
>>  dccp_xmit_packet+0x250/0x790 net/dccp/output.c:281
>>  dccp_write_xmit+0x190/0x1f0 net/dccp/output.c:363
>>  dccp_sendmsg+0x8c7/0x1020 net/dccp/proto.c:818
>>  inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
>>  sock_sendmsg_nosec net/socket.c:629 [inline]
>>  sock_sendmsg+0xd5/0x120 net/socket.c:639
>>  ___sys_sendmsg+0x525/0x940 net/socket.c:2117
>>  __sys_sendmmsg+0x240/0x6f0 net/socket.c:2212
>>  __do_sys_sendmmsg net/socket.c:2241 [inline]
>>  __se_sys_sendmmsg net/socket.c:2238 [inline]
>>  __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2238
>>  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
>>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
>> RIP: 0033:0x445d09
>> RSP: 002b:7f3c7eff5d88 EFLAGS: 0293 ORIG_RAX: 0133
>> RAX: ffda RBX: 006dac40 RCX: 00445d09
>> RDX: 0001 RSI: 00
>>
>>
>> ---
>> This bug is generated by a bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for more information about syzbot.
>> syzbot engineers can be reached at syzkal...@googlegroups.com.
>>
>> syzbot will keep track of this bug report.
>> If you forgot to add the Reported-by tag, once the fix for this bug is
>> merged
>> into any tree, please reply to this email with:
>> #syz fix: exact-commit-title
>> If you want to test a patch for this bug, please reply with:
>> #syz test: git://repo/address.git branch
>> and provide the patch inline or 

Re: BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_his

[Dmitry Vyukov]

On Wed, May 9, 2018 at 7:05 AM, Eric Biggers  wrote:
> On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:c1c07416cdd4 Merge tag 'kbuild-fixes-v4.17' of git://git.k..
>> git tree:   upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=13d5de4780
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27
>> dashboard link: https://syzkaller.appspot.com/bug?extid=99858724c0ba555a12ea
>> compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
>> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=170afde780
>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=141b4be780
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+99858724c0ba555a1...@syzkaller.appspotmail.com
>>
>> random: sshd: uninitialized urandom read (32 bytes read)
>> random: sshd: uninitialized urandom read (32 bytes read)
>> random: sshd: uninitialized urandom read (32 bytes read)
>> random: sshd: uninitialized urandom read (32 bytes read)
>> BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at
>> net/dccp/ccids/lib/packet_history.c:425/tfrc_rx_hist_sample_rtt()
>> CPU: 0 PID: 4495 Comm: syz-executor551 Not tainted 4.17.0-rc3+ #34
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>>  
>>  __dump_stack lib/dump_stack.c:77 [inline]
>>  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
>>  tfrc_rx_hist_sample_rtt.cold.3+0x54/0x5c
>> net/dccp/ccids/lib/packet_history.c:422
>>  ccid3_hc_rx_packet_recv+0x5c8/0xed0 net/dccp/ccids/ccid3.c:765
>>  ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
>>  dccp_deliver_input_to_ccids+0xf0/0x280 net/dccp/input.c:180
>>  dccp_rcv_established+0x87/0xb0 net/dccp/input.c:378
>>  dccp_v4_do_rcv+0x153/0x180 net/dccp/ipv4.c:654
>>  sk_backlog_rcv include/net/sock.h:909 [inline]
>>  __sk_receive_skb+0x3a2/0xd60 net/core/sock.c:513
>>  dccp_v4_rcv+0x10e5/0x1f3f net/dccp/ipv4.c:875
>>  ip_local_deliver_finish+0x2e3/0xd80 net/ipv4/ip_input.c:215
>>  NF_HOOK include/linux/netfilter.h:288 [inline]
>>  ip_local_deliver+0x1e1/0x720 net/ipv4/ip_input.c:256
>>  dst_input include/net/dst.h:450 [inline]
>>  ip_rcv_finish+0x81b/0x2200 net/ipv4/ip_input.c:396
>>  NF_HOOK include/linux/netfilter.h:288 [inline]
>>  ip_rcv+0xb70/0x143d net/ipv4/ip_input.c:492
>>  __netif_receive_skb_core+0x26f5/0x3630 net/core/dev.c:4592
>>  __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4657
>>  process_backlog+0x219/0x760 net/core/dev.c:5337
>>  napi_poll net/core/dev.c:5735 [inline]
>>  net_rx_action+0x7b7/0x1930 net/core/dev.c:5801
>>  __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
>>  do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1046
>>  
>>  do_softirq.part.17+0x14d/0x190 kernel/softirq.c:329
>>  do_softirq arch/x86/include/asm/preempt.h:23 [inline]
>>  __local_bh_enable_ip+0x1ec/0x230 kernel/softirq.c:182
>>  local_bh_enable include/linux/bottom_half.h:32 [inline]
>>  rcu_read_unlock_bh include/linux/rcupdate.h:728 [inline]
>>  ip_finish_output2+0xab2/0x1840 net/ipv4/ip_output.c:231
>>  ip_finish_output+0x828/0xf80 net/ipv4/ip_output.c:317
>>  NF_HOOK_COND include/linux/netfilter.h:277 [inline]
>>  ip_output+0x21b/0x850 net/ipv4/ip_output.c:405
>>  dst_output include/net/dst.h:444 [inline]
>>  ip_local_out+0xc5/0x1b0 net/ipv4/ip_output.c:124
>>  ip_queue_xmit+0x9d7/0x1f70 net/ipv4/ip_output.c:504
>>  dccp_transmit_skb+0x999/0x12e0 net/dccp/output.c:142
>>  dccp_xmit_packet+0x250/0x790 net/dccp/output.c:281
>>  dccp_write_xmit+0x190/0x1f0 net/dccp/output.c:363
>>  dccp_sendmsg+0x8c7/0x1020 net/dccp/proto.c:818
>>  inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
>>  sock_sendmsg_nosec net/socket.c:629 [inline]
>>  sock_sendmsg+0xd5/0x120 net/socket.c:639
>>  ___sys_sendmsg+0x525/0x940 net/socket.c:2117
>>  __sys_sendmmsg+0x240/0x6f0 net/socket.c:2212
>>  __do_sys_sendmmsg net/socket.c:2241 [inline]
>>  __se_sys_sendmmsg net/socket.c:2238 [inline]
>>  __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2238
>>  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
>>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
>> RIP: 0033:0x445d09
>> RSP: 002b:7f3c7eff5d88 EFLAGS: 0293 ORIG_RAX: 0133
>> RAX: ffda RBX: 006dac40 RCX: 00445d09
>> RDX: 0001 RSI: 00
>>
>>
>> ---
>> This bug is generated by a bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for more information about syzbot.
>> syzbot engineers can be reached at syzkal...@googlegroups.com.
>>
>> syzbot will keep track of this bug report.
>> If you forgot to add the Reported-by tag, once the fix for this bug is
>> merged
>> into any tree, please reply to this email with:
>> #syz fix: exact-commit-title
>> If you want to test a patch for this bug, please reply with:
>> #syz test: git://repo/address.git branch
>> and provide the patch inline or as an attachment.
>> 

Re: [PATCH] h8300: switch to NO_BOOTMEM

[Yoshinori Sato]

On Sat, 17 Mar 2018 06:33:06 +0900,
Rob Herring wrote:
> 
> Commit 0fa1c579349f ("of/fdt: use memblock_virt_alloc for early alloc")
> inadvertently switched the DT unflattening allocations from memblock to
> bootmem which doesn't work because the unflattening happens before
> bootmem is initialized. Swapping the order of bootmem init and
> unflattening could also fix this, but removing bootmem is desired. So
> enable NO_BOOTMEM on h8300 like other architectures have done.
> 
> Fixes: 0fa1c579349f ("of/fdt: use memblock_virt_alloc for early alloc")
> Cc: Yoshinori Sato 
> Cc: uclinux-h8-de...@lists.sourceforge.jp
> Signed-off-by: Rob Herring 
> ---
> I haven't seen any reports, but 4.16 is likely broken. This is compile 
> tested only.
> 
> Moving unflattening after bootmem_init should also work if a smaller 
> change for 4.16 is desired.

It's works fine.
Applied to h8300-next.

Thanks.

> Rob
> 
>  arch/h8300/Kconfig|  1 +
>  arch/h8300/kernel/setup.c | 36 
>  2 files changed, 9 insertions(+), 28 deletions(-)
> 
> diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
> index 091d6d04b5e5..efc602634064 100644
> --- a/arch/h8300/Kconfig
> +++ b/arch/h8300/Kconfig
> @@ -16,6 +16,7 @@ config H8300
>   select OF_IRQ
>   select OF_EARLY_FLATTREE
>   select HAVE_MEMBLOCK
> + select NO_BOOTMEM
>   select TIMER_OF
>   select H8300_TMR8
>   select HAVE_KERNEL_GZIP
> diff --git a/arch/h8300/kernel/setup.c b/arch/h8300/kernel/setup.c
> index a4d0470c10a9..33ed980e7aea 100644
> --- a/arch/h8300/kernel/setup.c
> +++ b/arch/h8300/kernel/setup.c
> @@ -71,10 +71,6 @@ void __init h8300_fdt_init(void *fdt, char *bootargs)
>  
>  static void __init bootmem_init(void)
>  {
> - int bootmap_size;
> - unsigned long ram_start_pfn;
> - unsigned long free_ram_start_pfn;
> - unsigned long ram_end_pfn;
>   struct memblock_region *region;
>  
>   memory_end = memory_start = 0;
> @@ -88,33 +84,17 @@ static void __init bootmem_init(void)
>   if (!memory_end)
>   panic("No memory!");
>  
> - ram_start_pfn = PFN_UP(memory_start);
> - /* free_ram_start_pfn is first page after kernel */
> - free_ram_start_pfn = PFN_UP(__pa(_end));
> - ram_end_pfn = PFN_DOWN(memblock_end_of_DRAM());
> + /* setup bootmem globals (we use no_bootmem, but mm still depends on 
> this) */
> + min_low_pfn = PFN_UP(memory_start);
> + max_low_pfn = PFN_DOWN(memblock_end_of_DRAM());
> + max_pfn = max_low_pfn;
>  
> - max_pfn = ram_end_pfn;
> + memblock_reserve(__pa(_stext), _end - _stext);
>  
> - /*
> -  * give all the memory to the bootmap allocator,  tell it to put the
> -  * boot mem_map at the start of memory
> -  */
> - bootmap_size = init_bootmem_node(NODE_DATA(0),
> -  free_ram_start_pfn,
> -  0,
> -  ram_end_pfn);
> - /*
> -  * free the usable memory,  we have to make sure we do not free
> -  * the bootmem bitmap so we then reserve it after freeing it :-)
> -  */
> - free_bootmem(PFN_PHYS(free_ram_start_pfn),
> -  (ram_end_pfn - free_ram_start_pfn) << PAGE_SHIFT);
> - reserve_bootmem(PFN_PHYS(free_ram_start_pfn), bootmap_size,
> - BOOTMEM_DEFAULT);
> + early_init_fdt_reserve_self();
> + early_init_fdt_scan_reserved_mem();
>  
> - for_each_memblock(reserved, region) {
> - reserve_bootmem(region->base, region->size, BOOTMEM_DEFAULT);
> - }
> + memblock_dump_all();
>  }
>  
>  void __init setup_arch(char **cmdline_p)
> -- 
> 2.14.1
> 

-- 
Yoshinori Sato

Re: [PATCH] h8300: switch to NO_BOOTMEM

[Yoshinori Sato]

On Sat, 17 Mar 2018 06:33:06 +0900,
Rob Herring wrote:
> 
> Commit 0fa1c579349f ("of/fdt: use memblock_virt_alloc for early alloc")
> inadvertently switched the DT unflattening allocations from memblock to
> bootmem which doesn't work because the unflattening happens before
> bootmem is initialized. Swapping the order of bootmem init and
> unflattening could also fix this, but removing bootmem is desired. So
> enable NO_BOOTMEM on h8300 like other architectures have done.
> 
> Fixes: 0fa1c579349f ("of/fdt: use memblock_virt_alloc for early alloc")
> Cc: Yoshinori Sato 
> Cc: uclinux-h8-de...@lists.sourceforge.jp
> Signed-off-by: Rob Herring 
> ---
> I haven't seen any reports, but 4.16 is likely broken. This is compile 
> tested only.
> 
> Moving unflattening after bootmem_init should also work if a smaller 
> change for 4.16 is desired.

It's works fine.
Applied to h8300-next.

Thanks.

> Rob
> 
>  arch/h8300/Kconfig|  1 +
>  arch/h8300/kernel/setup.c | 36 
>  2 files changed, 9 insertions(+), 28 deletions(-)
> 
> diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
> index 091d6d04b5e5..efc602634064 100644
> --- a/arch/h8300/Kconfig
> +++ b/arch/h8300/Kconfig
> @@ -16,6 +16,7 @@ config H8300
>   select OF_IRQ
>   select OF_EARLY_FLATTREE
>   select HAVE_MEMBLOCK
> + select NO_BOOTMEM
>   select TIMER_OF
>   select H8300_TMR8
>   select HAVE_KERNEL_GZIP
> diff --git a/arch/h8300/kernel/setup.c b/arch/h8300/kernel/setup.c
> index a4d0470c10a9..33ed980e7aea 100644
> --- a/arch/h8300/kernel/setup.c
> +++ b/arch/h8300/kernel/setup.c
> @@ -71,10 +71,6 @@ void __init h8300_fdt_init(void *fdt, char *bootargs)
>  
>  static void __init bootmem_init(void)
>  {
> - int bootmap_size;
> - unsigned long ram_start_pfn;
> - unsigned long free_ram_start_pfn;
> - unsigned long ram_end_pfn;
>   struct memblock_region *region;
>  
>   memory_end = memory_start = 0;
> @@ -88,33 +84,17 @@ static void __init bootmem_init(void)
>   if (!memory_end)
>   panic("No memory!");
>  
> - ram_start_pfn = PFN_UP(memory_start);
> - /* free_ram_start_pfn is first page after kernel */
> - free_ram_start_pfn = PFN_UP(__pa(_end));
> - ram_end_pfn = PFN_DOWN(memblock_end_of_DRAM());
> + /* setup bootmem globals (we use no_bootmem, but mm still depends on 
> this) */
> + min_low_pfn = PFN_UP(memory_start);
> + max_low_pfn = PFN_DOWN(memblock_end_of_DRAM());
> + max_pfn = max_low_pfn;
>  
> - max_pfn = ram_end_pfn;
> + memblock_reserve(__pa(_stext), _end - _stext);
>  
> - /*
> -  * give all the memory to the bootmap allocator,  tell it to put the
> -  * boot mem_map at the start of memory
> -  */
> - bootmap_size = init_bootmem_node(NODE_DATA(0),
> -  free_ram_start_pfn,
> -  0,
> -  ram_end_pfn);
> - /*
> -  * free the usable memory,  we have to make sure we do not free
> -  * the bootmem bitmap so we then reserve it after freeing it :-)
> -  */
> - free_bootmem(PFN_PHYS(free_ram_start_pfn),
> -  (ram_end_pfn - free_ram_start_pfn) << PAGE_SHIFT);
> - reserve_bootmem(PFN_PHYS(free_ram_start_pfn), bootmap_size,
> - BOOTMEM_DEFAULT);
> + early_init_fdt_reserve_self();
> + early_init_fdt_scan_reserved_mem();
>  
> - for_each_memblock(reserved, region) {
> - reserve_bootmem(region->base, region->size, BOOTMEM_DEFAULT);
> - }
> + memblock_dump_all();
>  }
>  
>  void __init setup_arch(char **cmdline_p)
> -- 
> 2.14.1
> 

-- 
Yoshinori Sato

Re: linux-next: build failure after merge of the drm-intel tree

[Stephen Rothwell]

Hi Christoph,

On Wed, 9 May 2018 07:08:55 +0200 Christoph Hellwig  wrote:
>
> FYI, because the dma_configure change touch so much code and the author
> wants to base more work on it it actually is in a guranteed stable
> branch with just those patches:
> 
> git://git.infradead.org/users/hch/dma-mapping.git dma-configure
> 
> Gitweb:
> 
> 
> http://git.infradead.org/users/hch/dma-mapping.git/shortlog/refs/heads/dma-configure
>   
> Feel free to pull this into the drm tree.

Thanks for that.

-- 
Cheers,
Stephen Rothwell


pgpn_jyXCyabz.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the drm-intel tree

[Stephen Rothwell]

Hi Christoph,

On Wed, 9 May 2018 07:08:55 +0200 Christoph Hellwig  wrote:
>
> FYI, because the dma_configure change touch so much code and the author
> wants to base more work on it it actually is in a guranteed stable
> branch with just those patches:
> 
> git://git.infradead.org/users/hch/dma-mapping.git dma-configure
> 
> Gitweb:
> 
> 
> http://git.infradead.org/users/hch/dma-mapping.git/shortlog/refs/heads/dma-configure
>   
> Feel free to pull this into the drm tree.

Thanks for that.

-- 
Cheers,
Stephen Rothwell


pgpn_jyXCyabz.pgp
Description: OpenPGP digital signature

Re: [RESEND PATCH] pinctrl: rockchip: Disable interrupt when changing it's capability

[Doug Anderson]

Hi,

On Tue, May 8, 2018 at 7:21 PM, JeffyChen  wrote:
> Hi Doug,
>
> On 05/09/2018 03:46 AM, Doug Anderson wrote:
>>
>> One note is that in the case Brian points at (where we need to
>> simulate EDGE_BOTH by swapping edges) we purposely ignored the TRM and
>> we needed to do that to avoid losing interrupts.  For details, see
>> commit 53b1bfc76df2 ("pinctrl: rockchip: Avoid losing interrupts when
>> supporting both edges").  We did this because:
>>
>> 1. We believed that the IP block in Rockchip SoCs has nearly the same
>> logic as "gpio-dwapb.c" and that's what "gpio-dwapb.c" did.
>>
>
> hmm, but i saw the gpio-dwapb.c actually toggle trigger after handle irq,
> which might avoid the race Brian mentioned:
> +   generic_handle_irq(gpio_irq);
> +   irq_status &= ~BIT(hwirq);
> +
> +   if ((irq_get_trigger_type(gpio_irq) & IRQ_TYPE_SENSE_MASK)
> +   == IRQ_TYPE_EDGE_BOTH)
> +   dwapb_toggle_trigger(gpio, hwirq);

The code you point at in dwapb_toggle_trigger() specifically is an
example of toggling the polarity _without_ disabling the interrupt in
between.  We took this as "working" code and as proof that it was OK
to change polarity without disabling the interrupt in-between.


> and i also saw ./qcom/pinctrl-msm.c do the
> toggle(msm_gpio_update_dual_edge_pos) at the end of msm_gpio_irq_set_type
> and msm_gpio_irq_ack, that seems can avoid the polarity races too.
>
>> 2. We were actually losing real interrupts and this was the only way
>> we could figure out how to fix it.
>>
>> When I tested that back in the day I was fairly convinced that we
>> weren't losing any interrupts in the EDGE_BOTH case after my fix, but
>> I certainly could have messed up.
>>
>>
>> For the EDGE_BOTH case it was important not to lose an interrupt
>> because, as you guys are talking about, we could end up configured the
>> wrong way.  I think in your case where you're just picking one
>> polarity losing an interrupt shouldn't matter since it's undefined
>> exactly if an edge happens while you're in the middle of executing
>> rockchip_irq_set_type().  Is that right?
>
>
> right, so we now have 2 cases: rockchip_irq_demux/ rockchip_irq_set_type
>
> if i'm right about the spurious irq(only happen when set rising for a high
> gpio, or set falling for a low gpio), then:
>
> 1/ rockchip_irq_demux
> it's important to not losing irqs in this case, maybe we can
>
> a) ack irq
> b) update polarity for edge both irq
>
> we don't need to disable irq in b), since we would not hit the spurious irq
> cases here(always check gpio level to toggle it)

Unless you have some sort of proof that rockchip_irq_demux(), I would
take it as an example of something that works.  I remember stress
testing the heck out of it.  Do you have some evidence that it's not
working?  I think Brian was simply speculating that there might be a
race here, but I don't think anyone has shown it have they?  Looking
back at my notes, the thing I really made sure to stress was that we
never got into a situation where we were losing an edge (AKA we were
never configured to look for a falling edge when the line was already
low).  I'm not sure I confirmed that we never got an extra interrupt.

I'm at home right now and I can't add prints and poke at things, but
as I understand it for edge interrupts the usual flow to make sure
interrupts aren't ever lost is:

1. See that the interrupt went off
2. Ack it (clear it)
3. Call the interrupt handler

...presumably in this case rockchip_irq_demux() is called after step
#2 (but I don't know if it's called before or after step #3).  If the
line is toggling like crazy while the 3 steps are going on, it's OK if
the interrupt handler is called more than once.  In general this could
be considered expected.  That's why you Ack before handling--any extra
edges that come in any time after the interrupt handler starts (even
after the very first instruction) need to cause the interrupt handler
to get called again.

This is different than Brian's understanding since he seemed to think
the Ack was happening later.  If you're in front of something where
you can add printouts, maybe you can tell us.  I tried to look through
the code and it was too twisted for me to be sure.


> 2/ rockchip_irq_set_type
> it's important to not having spurious irqs
>
> so we can disable irq during changing polarity only in these case:
> ((rising && gpio is heigh) || (falling && gpio is low))
>
> i'm still confirming the spurious irq with IC guys.

Hmmm, thinking about all this more, I'm curious how callers expect
this to work.  Certainly things are undefined if you have the
following situation:

Start: rising edge trigger, line is actually high
Request: change to falling edge trigger
Line falls during the request

In that case it's OK to throw the interrupt away because it can be
argued that the line could have fallen before the request actually
took place.  ...but 

Re: [RESEND PATCH] pinctrl: rockchip: Disable interrupt when changing it's capability

[Doug Anderson]

Hi,

On Tue, May 8, 2018 at 7:21 PM, JeffyChen  wrote:
> Hi Doug,
>
> On 05/09/2018 03:46 AM, Doug Anderson wrote:
>>
>> One note is that in the case Brian points at (where we need to
>> simulate EDGE_BOTH by swapping edges) we purposely ignored the TRM and
>> we needed to do that to avoid losing interrupts.  For details, see
>> commit 53b1bfc76df2 ("pinctrl: rockchip: Avoid losing interrupts when
>> supporting both edges").  We did this because:
>>
>> 1. We believed that the IP block in Rockchip SoCs has nearly the same
>> logic as "gpio-dwapb.c" and that's what "gpio-dwapb.c" did.
>>
>
> hmm, but i saw the gpio-dwapb.c actually toggle trigger after handle irq,
> which might avoid the race Brian mentioned:
> +   generic_handle_irq(gpio_irq);
> +   irq_status &= ~BIT(hwirq);
> +
> +   if ((irq_get_trigger_type(gpio_irq) & IRQ_TYPE_SENSE_MASK)
> +   == IRQ_TYPE_EDGE_BOTH)
> +   dwapb_toggle_trigger(gpio, hwirq);

The code you point at in dwapb_toggle_trigger() specifically is an
example of toggling the polarity _without_ disabling the interrupt in
between.  We took this as "working" code and as proof that it was OK
to change polarity without disabling the interrupt in-between.


> and i also saw ./qcom/pinctrl-msm.c do the
> toggle(msm_gpio_update_dual_edge_pos) at the end of msm_gpio_irq_set_type
> and msm_gpio_irq_ack, that seems can avoid the polarity races too.
>
>> 2. We were actually losing real interrupts and this was the only way
>> we could figure out how to fix it.
>>
>> When I tested that back in the day I was fairly convinced that we
>> weren't losing any interrupts in the EDGE_BOTH case after my fix, but
>> I certainly could have messed up.
>>
>>
>> For the EDGE_BOTH case it was important not to lose an interrupt
>> because, as you guys are talking about, we could end up configured the
>> wrong way.  I think in your case where you're just picking one
>> polarity losing an interrupt shouldn't matter since it's undefined
>> exactly if an edge happens while you're in the middle of executing
>> rockchip_irq_set_type().  Is that right?
>
>
> right, so we now have 2 cases: rockchip_irq_demux/ rockchip_irq_set_type
>
> if i'm right about the spurious irq(only happen when set rising for a high
> gpio, or set falling for a low gpio), then:
>
> 1/ rockchip_irq_demux
> it's important to not losing irqs in this case, maybe we can
>
> a) ack irq
> b) update polarity for edge both irq
>
> we don't need to disable irq in b), since we would not hit the spurious irq
> cases here(always check gpio level to toggle it)

Unless you have some sort of proof that rockchip_irq_demux(), I would
take it as an example of something that works.  I remember stress
testing the heck out of it.  Do you have some evidence that it's not
working?  I think Brian was simply speculating that there might be a
race here, but I don't think anyone has shown it have they?  Looking
back at my notes, the thing I really made sure to stress was that we
never got into a situation where we were losing an edge (AKA we were
never configured to look for a falling edge when the line was already
low).  I'm not sure I confirmed that we never got an extra interrupt.

I'm at home right now and I can't add prints and poke at things, but
as I understand it for edge interrupts the usual flow to make sure
interrupts aren't ever lost is:

1. See that the interrupt went off
2. Ack it (clear it)
3. Call the interrupt handler

...presumably in this case rockchip_irq_demux() is called after step
#2 (but I don't know if it's called before or after step #3).  If the
line is toggling like crazy while the 3 steps are going on, it's OK if
the interrupt handler is called more than once.  In general this could
be considered expected.  That's why you Ack before handling--any extra
edges that come in any time after the interrupt handler starts (even
after the very first instruction) need to cause the interrupt handler
to get called again.

This is different than Brian's understanding since he seemed to think
the Ack was happening later.  If you're in front of something where
you can add printouts, maybe you can tell us.  I tried to look through
the code and it was too twisted for me to be sure.


> 2/ rockchip_irq_set_type
> it's important to not having spurious irqs
>
> so we can disable irq during changing polarity only in these case:
> ((rising && gpio is heigh) || (falling && gpio is low))
>
> i'm still confirming the spurious irq with IC guys.

Hmmm, thinking about all this more, I'm curious how callers expect
this to work.  Certainly things are undefined if you have the
following situation:

Start: rising edge trigger, line is actually high
Request: change to falling edge trigger
Line falls during the request

In that case it's OK to throw the interrupt away because it can be
argued that the line could have fallen before the request actually
took place.  ...but it seems like there could 

Re: [PATCH V2 4/5] backlight: qcom-wled: Add support for OVP interrupt handling

[kgunda]

On 2018-05-08 16:09, Daniel Thompson wrote:

On Thu, May 03, 2018 at 03:42:31PM +0530, Kiran Gunda wrote:

WLED peripheral has over voltage protection(OVP) circuitry and the OVP
fault is notified through an interrupt. Though this fault condition 
rising
is due to an incorrect hardware configuration is mitigated in the 
hardware,

it still needs to be detected and handled. Add support for it.


Why detect and handle it? The interrupt handler doesn't appear to do
anything other than clear the interrupt... and it appears that the
interrupt can be masked.


Planing to squash this patch with the auto-string-detection patch in the 
next series,

where the OVP is used for the right string detection.
When WLED module is enabled, keep OVP fault interrupt disabled for 10 
ms to

account for soft start delay.

Signed-off-by: Kiran Gunda 
---
 drivers/video/backlight/qcom-wled.c | 118 
+++-

 1 file changed, 116 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/qcom-wled.c 
b/drivers/video/backlight/qcom-wled.c

index 2cfba77..80ae084 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -23,14 +23,20 @@

 /* From DT binding */
 #define WLED_DEFAULT_BRIGHTNESS2048
-
+#define WLED_SOFT_START_DLY_US 1
 #define WLED3_SINK_REG_BRIGHT_MAX  0xFFF

 /* WLED3 Control registers */
 #define WLED3_CTRL_REG_FAULT_STATUS0x08
+#define  WLED3_CTRL_REG_ILIM_FAULT_BIT BIT(0)
+#define  WLED3_CTRL_REG_OVP_FAULT_BIT  BIT(1)
+#define  WLED4_CTRL_REG_SC_FAULT_BIT   BIT(2)
+
+#define WLED3_CTRL_REG_INT_RT_STS  0x10

 #define WLED3_CTRL_REG_MOD_EN  0x46
 #define  WLED3_CTRL_REG_MOD_EN_MASKBIT(7)
+#define  WLED3_CTRL_REG_MOD_EN_BIT BIT(7)

 #define WLED3_CTRL_REG_FREQ0x4c
 #define  WLED3_CTRL_REG_FREQ_MASK  GENMASK(3, 0)
@@ -161,9 +167,12 @@ struct wled {
u32 short_count;
const int *version;
int short_irq;
+   int ovp_irq;
bool force_mod_disable;
+   bool ovp_irq_disabled;

struct wled_config cfg;
+   struct delayed_work ovp_work;
int (*wled_set_brightness)(struct wled *wled, u16 brightness);
int (*wled_sync_toggle)(struct wled *wled);
 };
@@ -209,6 +218,32 @@ static int wled4_set_brightness(struct wled 
*wled, u16 brightness)

return 0;
 }

+static void wled_ovp_work(struct work_struct *work)
+{
+   u32 val;
+   int rc;
+
+   struct wled *wled = container_of(work,
+struct wled, ovp_work.work);
+
+	rc = regmap_read(wled->regmap, wled->ctrl_addr + 
WLED3_CTRL_REG_MOD_EN,

+);
+   if (rc < 0)
+   return;
+
+   if (val & WLED3_CTRL_REG_MOD_EN_BIT) {
+   if (wled->ovp_irq > 0 && wled->ovp_irq_disabled) {
+   enable_irq(wled->ovp_irq);
+   wled->ovp_irq_disabled = false;
+   }
+   } else {
+   if (wled->ovp_irq > 0 && !wled->ovp_irq_disabled) {
+   disable_irq(wled->ovp_irq);
+   wled->ovp_irq_disabled = true;
+   }
+   }
+}
+
 static int wled_module_enable(struct wled *wled, int val)
 {
int rc;
@@ -220,7 +255,12 @@ static int wled_module_enable(struct wled *wled, 
int val)

WLED3_CTRL_REG_MOD_EN,
WLED3_CTRL_REG_MOD_EN_MASK,
WLED3_CTRL_REG_MOD_EN_MASK);
-   return rc;
+   if (rc < 0)
+   return rc;
+
+   schedule_delayed_work(>ovp_work, WLED_SOFT_START_DLY_US);
+
+   return 0;
 }

 static int wled3_sync_toggle(struct wled *wled)
@@ -346,6 +386,36 @@ static irqreturn_t wled_short_irq_handler(int 
irq, void *_wled)

return IRQ_HANDLED;
 }

+static irqreturn_t wled_ovp_irq_handler(int irq, void *_wled)
+{
+   struct wled *wled = _wled;
+   int rc;
+   u32 int_sts, fault_sts;
+
+   rc = regmap_read(wled->regmap,
+wled->ctrl_addr + WLED3_CTRL_REG_INT_RT_STS, _sts);
+   if (rc < 0) {
+   dev_err(wled->dev, "Error in reading WLED3_INT_RT_STS rc=%d\n",
+   rc);
+   return IRQ_HANDLED;
+   }
+
+   rc = regmap_read(wled->regmap, wled->ctrl_addr +
+WLED3_CTRL_REG_FAULT_STATUS, _sts);
+   if (rc < 0) {
+   dev_err(wled->dev, "Error in reading WLED_FAULT_STATUS rc=%d\n",
+   rc);
+   return IRQ_HANDLED;
+   }
+
+   if (fault_sts &
+   (WLED3_CTRL_REG_OVP_FAULT_BIT | WLED3_CTRL_REG_ILIM_FAULT_BIT))
+		dev_dbg(wled->dev, "WLED OVP fault detected, 

Re: [PATCH V2 4/5] backlight: qcom-wled: Add support for OVP interrupt handling

[kgunda]

On 2018-05-08 16:09, Daniel Thompson wrote:

On Thu, May 03, 2018 at 03:42:31PM +0530, Kiran Gunda wrote:

WLED peripheral has over voltage protection(OVP) circuitry and the OVP
fault is notified through an interrupt. Though this fault condition 
rising
is due to an incorrect hardware configuration is mitigated in the 
hardware,

it still needs to be detected and handled. Add support for it.


Why detect and handle it? The interrupt handler doesn't appear to do
anything other than clear the interrupt... and it appears that the
interrupt can be masked.


Planing to squash this patch with the auto-string-detection patch in the 
next series,

where the OVP is used for the right string detection.
When WLED module is enabled, keep OVP fault interrupt disabled for 10 
ms to

account for soft start delay.

Signed-off-by: Kiran Gunda 
---
 drivers/video/backlight/qcom-wled.c | 118 
+++-

 1 file changed, 116 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/qcom-wled.c 
b/drivers/video/backlight/qcom-wled.c

index 2cfba77..80ae084 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -23,14 +23,20 @@

 /* From DT binding */
 #define WLED_DEFAULT_BRIGHTNESS2048
-
+#define WLED_SOFT_START_DLY_US 1
 #define WLED3_SINK_REG_BRIGHT_MAX  0xFFF

 /* WLED3 Control registers */
 #define WLED3_CTRL_REG_FAULT_STATUS0x08
+#define  WLED3_CTRL_REG_ILIM_FAULT_BIT BIT(0)
+#define  WLED3_CTRL_REG_OVP_FAULT_BIT  BIT(1)
+#define  WLED4_CTRL_REG_SC_FAULT_BIT   BIT(2)
+
+#define WLED3_CTRL_REG_INT_RT_STS  0x10

 #define WLED3_CTRL_REG_MOD_EN  0x46
 #define  WLED3_CTRL_REG_MOD_EN_MASKBIT(7)
+#define  WLED3_CTRL_REG_MOD_EN_BIT BIT(7)

 #define WLED3_CTRL_REG_FREQ0x4c
 #define  WLED3_CTRL_REG_FREQ_MASK  GENMASK(3, 0)
@@ -161,9 +167,12 @@ struct wled {
u32 short_count;
const int *version;
int short_irq;
+   int ovp_irq;
bool force_mod_disable;
+   bool ovp_irq_disabled;

struct wled_config cfg;
+   struct delayed_work ovp_work;
int (*wled_set_brightness)(struct wled *wled, u16 brightness);
int (*wled_sync_toggle)(struct wled *wled);
 };
@@ -209,6 +218,32 @@ static int wled4_set_brightness(struct wled 
*wled, u16 brightness)

return 0;
 }

+static void wled_ovp_work(struct work_struct *work)
+{
+   u32 val;
+   int rc;
+
+   struct wled *wled = container_of(work,
+struct wled, ovp_work.work);
+
+	rc = regmap_read(wled->regmap, wled->ctrl_addr + 
WLED3_CTRL_REG_MOD_EN,

+);
+   if (rc < 0)
+   return;
+
+   if (val & WLED3_CTRL_REG_MOD_EN_BIT) {
+   if (wled->ovp_irq > 0 && wled->ovp_irq_disabled) {
+   enable_irq(wled->ovp_irq);
+   wled->ovp_irq_disabled = false;
+   }
+   } else {
+   if (wled->ovp_irq > 0 && !wled->ovp_irq_disabled) {
+   disable_irq(wled->ovp_irq);
+   wled->ovp_irq_disabled = true;
+   }
+   }
+}
+
 static int wled_module_enable(struct wled *wled, int val)
 {
int rc;
@@ -220,7 +255,12 @@ static int wled_module_enable(struct wled *wled, 
int val)

WLED3_CTRL_REG_MOD_EN,
WLED3_CTRL_REG_MOD_EN_MASK,
WLED3_CTRL_REG_MOD_EN_MASK);
-   return rc;
+   if (rc < 0)
+   return rc;
+
+   schedule_delayed_work(>ovp_work, WLED_SOFT_START_DLY_US);
+
+   return 0;
 }

 static int wled3_sync_toggle(struct wled *wled)
@@ -346,6 +386,36 @@ static irqreturn_t wled_short_irq_handler(int 
irq, void *_wled)

return IRQ_HANDLED;
 }

+static irqreturn_t wled_ovp_irq_handler(int irq, void *_wled)
+{
+   struct wled *wled = _wled;
+   int rc;
+   u32 int_sts, fault_sts;
+
+   rc = regmap_read(wled->regmap,
+wled->ctrl_addr + WLED3_CTRL_REG_INT_RT_STS, _sts);
+   if (rc < 0) {
+   dev_err(wled->dev, "Error in reading WLED3_INT_RT_STS rc=%d\n",
+   rc);
+   return IRQ_HANDLED;
+   }
+
+   rc = regmap_read(wled->regmap, wled->ctrl_addr +
+WLED3_CTRL_REG_FAULT_STATUS, _sts);
+   if (rc < 0) {
+   dev_err(wled->dev, "Error in reading WLED_FAULT_STATUS rc=%d\n",
+   rc);
+   return IRQ_HANDLED;
+   }
+
+   if (fault_sts &
+   (WLED3_CTRL_REG_OVP_FAULT_BIT | WLED3_CTRL_REG_ILIM_FAULT_BIT))
+		dev_dbg(wled->dev, "WLED OVP fault detected, int_sts=%x fault_sts= 

Re: [PATCH V1 2/5] backlight: qcom-wled: Add support for WLED4 peripheral

[kgunda]

On 2018-05-08 22:47, Bjorn Andersson wrote:

On Tue 08 May 03:25 PDT 2018, kgu...@codeaurora.org wrote:


On 2018-05-07 21:50, Bjorn Andersson wrote:
> On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:

[..]

> > +- qcom,ovp
> > + Usage:optional
> > + Value type:   
> > + Definition:   mV; Over-voltage protection limit;
>
> The existing users of qcom,pm8941-wled depends on this being in V, so
> you can't change the unit. I suggest that you add a new "qcom,ovp-mv"
> property and make the driver fall back to looking for qcom,ovp if that
> isn't specified.
>
> PS. This is a very good example of why it is a good idea to not
> restructure and make changes at the same time - I almost missed this.
>
Actually I have checked the current kernel and none of the properties 
are
being configured from the device tree node. Hence, i thought it is the 
right

time modify the units to mV to support the PMI8998.



arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts does.


You still want to have the qcom,ovp-mv, even though it is not being
configured from device tree ?


Yes, please.


Sure.

> > +   For pm8941:  one of 27000, 29000, 32000, 35000
> > +   Default: 29000 mV
> > +   For pmi8998: one of 18100, 19600, 29600, 31100
> > +   Default: 29600 mV
> > +


Regards,
Bjorn

Re: [PATCH V1 2/5] backlight: qcom-wled: Add support for WLED4 peripheral

[kgunda]

On 2018-05-08 22:47, Bjorn Andersson wrote:

On Tue 08 May 03:25 PDT 2018, kgu...@codeaurora.org wrote:


On 2018-05-07 21:50, Bjorn Andersson wrote:
> On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:

[..]

> > +- qcom,ovp
> > + Usage:optional
> > + Value type:   
> > + Definition:   mV; Over-voltage protection limit;
>
> The existing users of qcom,pm8941-wled depends on this being in V, so
> you can't change the unit. I suggest that you add a new "qcom,ovp-mv"
> property and make the driver fall back to looking for qcom,ovp if that
> isn't specified.
>
> PS. This is a very good example of why it is a good idea to not
> restructure and make changes at the same time - I almost missed this.
>
Actually I have checked the current kernel and none of the properties 
are
being configured from the device tree node. Hence, i thought it is the 
right

time modify the units to mV to support the PMI8998.



arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts does.


You still want to have the qcom,ovp-mv, even though it is not being
configured from device tree ?


Yes, please.


Sure.

> > +   For pm8941:  one of 27000, 29000, 32000, 35000
> > +   Default: 29000 mV
> > +   For pmi8998: one of 18100, 19600, 29600, 31100
> > +   Default: 29600 mV
> > +


Regards,
Bjorn

Re: [PATCH] nvme-rdma: clear NVME_RDMA_Q_LIVE before free the queue

[Christoph Hellwig]

Looks fine,

Reviewed-by: Christoph Hellwig 

Re: [PATCH] nvme-rdma: clear NVME_RDMA_Q_LIVE before free the queue

[Christoph Hellwig]

Looks fine,

Reviewed-by: Christoph Hellwig 

Re: bug in tag handling in blk-mq?

[Mike Galbraith]

On Tue, 2018-05-08 at 14:37 -0600, Jens Axboe wrote:
> 
> - sdd has nothing pending, yet has 6 active waitqueues.

sdd is where ccache storage lives, which that should have been the only
activity on that drive, as I built source in sdb, and was doing nothing
else that utilizes sdd.

-Mike

Re: bug in tag handling in blk-mq?

[Mike Galbraith]

On Tue, 2018-05-08 at 14:37 -0600, Jens Axboe wrote:
> 
> - sdd has nothing pending, yet has 6 active waitqueues.

sdd is where ccache storage lives, which that should have been the only
activity on that drive, as I built source in sdb, and was doing nothing
else that utilizes sdd.

-Mike

Re: [PATCH v6 2/6] ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set

[Oleksij Rempel]

On Tue, May 08, 2018 at 01:40:33PM +0100, Russell King - ARM Linux wrote:
> On Mon, Mar 05, 2018 at 11:25:19AM +0100, Oleksij Rempel wrote:
> > One of the Freescale recommended sequences for power off with external
> > PMIC is the following:
> > ...
> > 3.  SoC is programming PMIC for power off when standby is asserted.
> > 4.  In CCM STOP mode, Standby is asserted, PMIC gates SoC supplies.
> > 
> > See:
> > http://www.nxp.com/assets/documents/data/en/reference-manuals/IMX6DQRM.pdf
> > page 5083
> > 
> > This patch implements step 4. of this sequence.
> > 
> > Signed-off-by: Oleksij Rempel 
> > ---
> >  arch/arm/mach-imx/pm-imx6.c | 25 +
> >  1 file changed, 25 insertions(+)
> > 
> > diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-imx6.c
> > index ecdf071653d4..24689260a2a5 100644
> > --- a/arch/arm/mach-imx/pm-imx6.c
> > +++ b/arch/arm/mach-imx/pm-imx6.c
> > @@ -604,6 +604,28 @@ static void __init imx6_pm_common_init(const struct 
> > imx6_pm_socdata
> >IMX6Q_GPR1_GINT);
> >  }
> >  
> > +static void imx6_pm_stby_poweroff(void)
> > +{
> > +   imx6_set_lpm(STOP_POWER_OFF);
> > +   cpu_suspend(0, imx6q_suspend_finish);
> 
> Do you actually need to save the processor state etc here - the request
> is after all to power down the system and not to suspend.  Would calling
> imx6q_suspend_finish() directly work (and hence simplify the code) ?

yes you right. This will work as well.
I'll send changed version after Rafaels feedback for kernel/reboot.c
part.
Russell, can I expect your Signed-off-by for changed patch?

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


signature.asc
Description: PGP signature

Re: [PATCH v6 2/6] ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set

[Oleksij Rempel]

On Tue, May 08, 2018 at 01:40:33PM +0100, Russell King - ARM Linux wrote:
> On Mon, Mar 05, 2018 at 11:25:19AM +0100, Oleksij Rempel wrote:
> > One of the Freescale recommended sequences for power off with external
> > PMIC is the following:
> > ...
> > 3.  SoC is programming PMIC for power off when standby is asserted.
> > 4.  In CCM STOP mode, Standby is asserted, PMIC gates SoC supplies.
> > 
> > See:
> > http://www.nxp.com/assets/documents/data/en/reference-manuals/IMX6DQRM.pdf
> > page 5083
> > 
> > This patch implements step 4. of this sequence.
> > 
> > Signed-off-by: Oleksij Rempel 
> > ---
> >  arch/arm/mach-imx/pm-imx6.c | 25 +
> >  1 file changed, 25 insertions(+)
> > 
> > diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-imx6.c
> > index ecdf071653d4..24689260a2a5 100644
> > --- a/arch/arm/mach-imx/pm-imx6.c
> > +++ b/arch/arm/mach-imx/pm-imx6.c
> > @@ -604,6 +604,28 @@ static void __init imx6_pm_common_init(const struct 
> > imx6_pm_socdata
> >IMX6Q_GPR1_GINT);
> >  }
> >  
> > +static void imx6_pm_stby_poweroff(void)
> > +{
> > +   imx6_set_lpm(STOP_POWER_OFF);
> > +   cpu_suspend(0, imx6q_suspend_finish);
> 
> Do you actually need to save the processor state etc here - the request
> is after all to power down the system and not to suspend.  Would calling
> imx6q_suspend_finish() directly work (and hence simplify the code) ?

yes you right. This will work as well.
I'll send changed version after Rafaels feedback for kernel/reboot.c
part.
Russell, can I expect your Signed-off-by for changed patch?

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


signature.asc
Description: PGP signature

Re: bug in tag handling in blk-mq?

[Paolo Valente]

> Il giorno 09 mag 2018, alle ore 06:11, Mike Galbraith  ha 
> scritto:
> 
> On Tue, 2018-05-08 at 19:09 -0600, Jens Axboe wrote:
>> 
>> Alright, I managed to reproduce it. What I think is happening is that
>> BFQ is limiting the inflight case to something less than the wake
>> batch for sbitmap, which can lead to stalls. I don't have time to test
>> this tonight, but perhaps you can give it a go when you are back at it.
>> If not, I'll try tomorrow morning.
>> 
>> If this is the issue, I can turn it into a real patch. This is just to
>> confirm that the issue goes away with the below.
> 
> Confirmed.  Impressive high speed bug stomping.
> 

Great! It's a real relief that this ghost is gone.

Thank you both,
Paolo

>> diff --git a/lib/sbitmap.c b/lib/sbitmap.c
>> index e6a9c06ec70c..94ced15b6428 100644
>> --- a/lib/sbitmap.c
>> +++ b/lib/sbitmap.c
>> @@ -272,6 +272,7 @@ EXPORT_SYMBOL_GPL(sbitmap_bitmap_show);
>> 
>> static unsigned int sbq_calc_wake_batch(unsigned int depth)
>> {
>> +#if 0
>>  unsigned int wake_batch;
>> 
>>  /*
>> @@ -284,6 +285,9 @@ static unsigned int sbq_calc_wake_batch(unsigned int 
>> depth)
>>  wake_batch = max(1U, depth / SBQ_WAIT_QUEUES);
>> 
>>  return wake_batch;
>> +#else
>> +return 1;
>> +#endif
>> }
>> 
>> int sbitmap_queue_init_node(struct sbitmap_queue *sbq, unsigned int depth,
>> 

Re: bug in tag handling in blk-mq?

[Paolo Valente]

> Il giorno 09 mag 2018, alle ore 06:11, Mike Galbraith  ha 
> scritto:
> 
> On Tue, 2018-05-08 at 19:09 -0600, Jens Axboe wrote:
>> 
>> Alright, I managed to reproduce it. What I think is happening is that
>> BFQ is limiting the inflight case to something less than the wake
>> batch for sbitmap, which can lead to stalls. I don't have time to test
>> this tonight, but perhaps you can give it a go when you are back at it.
>> If not, I'll try tomorrow morning.
>> 
>> If this is the issue, I can turn it into a real patch. This is just to
>> confirm that the issue goes away with the below.
> 
> Confirmed.  Impressive high speed bug stomping.
> 

Great! It's a real relief that this ghost is gone.

Thank you both,
Paolo

>> diff --git a/lib/sbitmap.c b/lib/sbitmap.c
>> index e6a9c06ec70c..94ced15b6428 100644
>> --- a/lib/sbitmap.c
>> +++ b/lib/sbitmap.c
>> @@ -272,6 +272,7 @@ EXPORT_SYMBOL_GPL(sbitmap_bitmap_show);
>> 
>> static unsigned int sbq_calc_wake_batch(unsigned int depth)
>> {
>> +#if 0
>>  unsigned int wake_batch;
>> 
>>  /*
>> @@ -284,6 +285,9 @@ static unsigned int sbq_calc_wake_batch(unsigned int 
>> depth)
>>  wake_batch = max(1U, depth / SBQ_WAIT_QUEUES);
>> 
>>  return wake_batch;
>> +#else
>> +return 1;
>> +#endif
>> }
>> 
>> int sbitmap_queue_init_node(struct sbitmap_queue *sbq, unsigned int depth,
>> 

Re: [PATCH V1 4/5] backlight: qcom-wled: Add support for OVP interrupt handling

[kgunda]

On 2018-05-08 22:49, Bjorn Andersson wrote:

On Tue 08 May 05:26 PDT 2018, kgu...@codeaurora.org wrote:


On 2018-05-07 22:51, Bjorn Andersson wrote:
> On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:

[..]

> > @@ -220,7 +255,12 @@ static int wled_module_enable(struct wled
> > *wled, int val)
> >   WLED3_CTRL_REG_MOD_EN,
> >   WLED3_CTRL_REG_MOD_EN_MASK,
> >   WLED3_CTRL_REG_MOD_EN_MASK);
> > - return rc;
> > + if (rc < 0)
> > + return rc;
> > +
> > + schedule_delayed_work(>ovp_work, WLED_SOFT_START_DLY_US);
>
> Do you really want to delay the work on disable?
>
> Wouldn't it be better to use a delay worker for the enablement and in
> the disable case you cancel the work and just disable_irq() directly
> here.
>
Sure. Will do it in the next series.
> But more importantly, if this is only related to auto detection, do you
> really want to enable/disable the ovp_irq after you have detected the
> string configuration?
>
Ok. This is used for the genuine OVP detection and for the auto 
detection as

well.


What is the expected outcome of detecting an OVP condition, outside 
auto

detection?

Ok... Out side auto detection, it is used for information purpose. I 
think it is

okay to ignore enable/disable the ovp_irq after auto detection is done.

Regards,
Bjorn

Re: [PATCH V1 4/5] backlight: qcom-wled: Add support for OVP interrupt handling

[kgunda]

On 2018-05-08 22:49, Bjorn Andersson wrote:

On Tue 08 May 05:26 PDT 2018, kgu...@codeaurora.org wrote:


On 2018-05-07 22:51, Bjorn Andersson wrote:
> On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:

[..]

> > @@ -220,7 +255,12 @@ static int wled_module_enable(struct wled
> > *wled, int val)
> >   WLED3_CTRL_REG_MOD_EN,
> >   WLED3_CTRL_REG_MOD_EN_MASK,
> >   WLED3_CTRL_REG_MOD_EN_MASK);
> > - return rc;
> > + if (rc < 0)
> > + return rc;
> > +
> > + schedule_delayed_work(>ovp_work, WLED_SOFT_START_DLY_US);
>
> Do you really want to delay the work on disable?
>
> Wouldn't it be better to use a delay worker for the enablement and in
> the disable case you cancel the work and just disable_irq() directly
> here.
>
Sure. Will do it in the next series.
> But more importantly, if this is only related to auto detection, do you
> really want to enable/disable the ovp_irq after you have detected the
> string configuration?
>
Ok. This is used for the genuine OVP detection and for the auto 
detection as

well.


What is the expected outcome of detecting an OVP condition, outside 
auto

detection?

Ok... Out side auto detection, it is used for information purpose. I 
think it is

okay to ignore enable/disable the ovp_irq after auto detection is done.

Regards,
Bjorn

Re: linux-next: build failure after merge of the drm-intel tree

[Christoph Hellwig]

On Wed, May 09, 2018 at 03:02:55PM +1000, Stephen Rothwell wrote:
> > -   ret = of_dma_configure(dev, NULL);
> > +   ret = of_dma_configure(dev, NULL, true);
> > if (ret < 0) {
> > DRM_ERROR("Cannot setup DMA ops, ret %d", ret);
> > return ret;
> > -- 
> > 2.17.0
> 
> This is now needed for the merge of the drm and dma-mapping trees.

FYI, because the dma_configure change touch so much code and the author
wants to base more work on it it actually is in a guranteed stable
branch with just those patches:

git://git.infradead.org/users/hch/dma-mapping.git dma-configure

Gitweb:


http://git.infradead.org/users/hch/dma-mapping.git/shortlog/refs/heads/dma-configure
  
Feel free to pull this into the drm tree.

Re: linux-next: build failure after merge of the drm-intel tree

[Christoph Hellwig]

On Wed, May 09, 2018 at 03:02:55PM +1000, Stephen Rothwell wrote:
> > -   ret = of_dma_configure(dev, NULL);
> > +   ret = of_dma_configure(dev, NULL, true);
> > if (ret < 0) {
> > DRM_ERROR("Cannot setup DMA ops, ret %d", ret);
> > return ret;
> > -- 
> > 2.17.0
> 
> This is now needed for the merge of the drm and dma-mapping trees.

FYI, because the dma_configure change touch so much code and the author
wants to base more work on it it actually is in a guranteed stable
branch with just those patches:

git://git.infradead.org/users/hch/dma-mapping.git dma-configure

Gitweb:


http://git.infradead.org/users/hch/dma-mapping.git/shortlog/refs/heads/dma-configure
  
Feel free to pull this into the drm tree.

Re: linux-next: build failure after merge of the drm-intel tree

[Stephen Rothwell]

Hi all,

On Tue, 8 May 2018 11:07:16 +1000 Stephen Rothwell  
wrote:
>
> After merging the drm-intel tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/gpu/drm/xen/xen_drm_front.c: In function 'xen_drv_probe':
> drivers/gpu/drm/xen/xen_drm_front.c:740:10: error: 'struct bus_type' has no 
> member named 'force_dma'
>   dev->bus->force_dma = true;
>   ^~
> drivers/gpu/drm/xen/xen_drm_front.c:742:8: error: too few arguments to 
> function 'of_dma_configure'
>   ret = of_dma_configure(dev, NULL);
> ^~~~
> In file included from drivers/gpu/drm/xen/xen_drm_front.c:16:0:
> include/linux/of_device.h:58:5: note: declared here
>  int of_dma_configure(struct device *dev,
>  ^~~~
> 
> Caused by commit
> 
>   c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
> 
> interacting with commit
> 
>   3d6ce86ee794 ("drivers: remove force dma flag from buses")
> 
> from the dma-mapping tree.
> 
> I have added the following merge fix patch:
> 
> From: Stephen Rothwell 
> Date: Tue, 8 May 2018 11:02:24 +1000
> Subject: [PATCH] drm/xen-front: merge fix for "drivers: remove force dma flag 
> from buses"
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/gpu/drm/xen/xen_drm_front.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
> b/drivers/gpu/drm/xen/xen_drm_front.c
> index 1b0ea9ac330e..0e486cb1c10c 100644
> --- a/drivers/gpu/drm/xen/xen_drm_front.c
> +++ b/drivers/gpu/drm/xen/xen_drm_front.c
> @@ -737,9 +737,8 @@ static int xen_drv_probe(struct xenbus_device *xb_dev,
>* is not correct: to fix this call of_dma_configure() with a NULL
>* node to set default DMA ops.
>*/
> - dev->bus->force_dma = true;
>   dev->coherent_dma_mask = DMA_BIT_MASK(32);
> - ret = of_dma_configure(dev, NULL);
> + ret = of_dma_configure(dev, NULL, true);
>   if (ret < 0) {
>   DRM_ERROR("Cannot setup DMA ops, ret %d", ret);
>   return ret;
> -- 
> 2.17.0

This is now needed for the merge of the drm and dma-mapping trees.
-- 
Cheers,
Stephen Rothwell


pgpN2sD4JHkM8.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the drm-intel tree

[Stephen Rothwell]

Hi all,

On Tue, 8 May 2018 11:07:16 +1000 Stephen Rothwell  
wrote:
>
> After merging the drm-intel tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/gpu/drm/xen/xen_drm_front.c: In function 'xen_drv_probe':
> drivers/gpu/drm/xen/xen_drm_front.c:740:10: error: 'struct bus_type' has no 
> member named 'force_dma'
>   dev->bus->force_dma = true;
>   ^~
> drivers/gpu/drm/xen/xen_drm_front.c:742:8: error: too few arguments to 
> function 'of_dma_configure'
>   ret = of_dma_configure(dev, NULL);
> ^~~~
> In file included from drivers/gpu/drm/xen/xen_drm_front.c:16:0:
> include/linux/of_device.h:58:5: note: declared here
>  int of_dma_configure(struct device *dev,
>  ^~~~
> 
> Caused by commit
> 
>   c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
> 
> interacting with commit
> 
>   3d6ce86ee794 ("drivers: remove force dma flag from buses")
> 
> from the dma-mapping tree.
> 
> I have added the following merge fix patch:
> 
> From: Stephen Rothwell 
> Date: Tue, 8 May 2018 11:02:24 +1000
> Subject: [PATCH] drm/xen-front: merge fix for "drivers: remove force dma flag 
> from buses"
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/gpu/drm/xen/xen_drm_front.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
> b/drivers/gpu/drm/xen/xen_drm_front.c
> index 1b0ea9ac330e..0e486cb1c10c 100644
> --- a/drivers/gpu/drm/xen/xen_drm_front.c
> +++ b/drivers/gpu/drm/xen/xen_drm_front.c
> @@ -737,9 +737,8 @@ static int xen_drv_probe(struct xenbus_device *xb_dev,
>* is not correct: to fix this call of_dma_configure() with a NULL
>* node to set default DMA ops.
>*/
> - dev->bus->force_dma = true;
>   dev->coherent_dma_mask = DMA_BIT_MASK(32);
> - ret = of_dma_configure(dev, NULL);
> + ret = of_dma_configure(dev, NULL, true);
>   if (ret < 0) {
>   DRM_ERROR("Cannot setup DMA ops, ret %d", ret);
>   return ret;
> -- 
> 2.17.0

This is now needed for the merge of the drm and dma-mapping trees.
-- 
Cheers,
Stephen Rothwell


pgpN2sD4JHkM8.pgp
Description: OpenPGP digital signature

Re: BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_his

[Eric Biggers]

On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:c1c07416cdd4 Merge tag 'kbuild-fixes-v4.17' of git://git.k..
> git tree:   upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=13d5de4780
> kernel config:  https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27
> dashboard link: https://syzkaller.appspot.com/bug?extid=99858724c0ba555a12ea
> compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=170afde780
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=141b4be780
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+99858724c0ba555a1...@syzkaller.appspotmail.com
> 
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at
> net/dccp/ccids/lib/packet_history.c:425/tfrc_rx_hist_sample_rtt()
> CPU: 0 PID: 4495 Comm: syz-executor551 Not tainted 4.17.0-rc3+ #34
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
>  tfrc_rx_hist_sample_rtt.cold.3+0x54/0x5c
> net/dccp/ccids/lib/packet_history.c:422
>  ccid3_hc_rx_packet_recv+0x5c8/0xed0 net/dccp/ccids/ccid3.c:765
>  ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
>  dccp_deliver_input_to_ccids+0xf0/0x280 net/dccp/input.c:180
>  dccp_rcv_established+0x87/0xb0 net/dccp/input.c:378
>  dccp_v4_do_rcv+0x153/0x180 net/dccp/ipv4.c:654
>  sk_backlog_rcv include/net/sock.h:909 [inline]
>  __sk_receive_skb+0x3a2/0xd60 net/core/sock.c:513
>  dccp_v4_rcv+0x10e5/0x1f3f net/dccp/ipv4.c:875
>  ip_local_deliver_finish+0x2e3/0xd80 net/ipv4/ip_input.c:215
>  NF_HOOK include/linux/netfilter.h:288 [inline]
>  ip_local_deliver+0x1e1/0x720 net/ipv4/ip_input.c:256
>  dst_input include/net/dst.h:450 [inline]
>  ip_rcv_finish+0x81b/0x2200 net/ipv4/ip_input.c:396
>  NF_HOOK include/linux/netfilter.h:288 [inline]
>  ip_rcv+0xb70/0x143d net/ipv4/ip_input.c:492
>  __netif_receive_skb_core+0x26f5/0x3630 net/core/dev.c:4592
>  __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4657
>  process_backlog+0x219/0x760 net/core/dev.c:5337
>  napi_poll net/core/dev.c:5735 [inline]
>  net_rx_action+0x7b7/0x1930 net/core/dev.c:5801
>  __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
>  do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1046
>  
>  do_softirq.part.17+0x14d/0x190 kernel/softirq.c:329
>  do_softirq arch/x86/include/asm/preempt.h:23 [inline]
>  __local_bh_enable_ip+0x1ec/0x230 kernel/softirq.c:182
>  local_bh_enable include/linux/bottom_half.h:32 [inline]
>  rcu_read_unlock_bh include/linux/rcupdate.h:728 [inline]
>  ip_finish_output2+0xab2/0x1840 net/ipv4/ip_output.c:231
>  ip_finish_output+0x828/0xf80 net/ipv4/ip_output.c:317
>  NF_HOOK_COND include/linux/netfilter.h:277 [inline]
>  ip_output+0x21b/0x850 net/ipv4/ip_output.c:405
>  dst_output include/net/dst.h:444 [inline]
>  ip_local_out+0xc5/0x1b0 net/ipv4/ip_output.c:124
>  ip_queue_xmit+0x9d7/0x1f70 net/ipv4/ip_output.c:504
>  dccp_transmit_skb+0x999/0x12e0 net/dccp/output.c:142
>  dccp_xmit_packet+0x250/0x790 net/dccp/output.c:281
>  dccp_write_xmit+0x190/0x1f0 net/dccp/output.c:363
>  dccp_sendmsg+0x8c7/0x1020 net/dccp/proto.c:818
>  inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
>  sock_sendmsg_nosec net/socket.c:629 [inline]
>  sock_sendmsg+0xd5/0x120 net/socket.c:639
>  ___sys_sendmsg+0x525/0x940 net/socket.c:2117
>  __sys_sendmmsg+0x240/0x6f0 net/socket.c:2212
>  __do_sys_sendmmsg net/socket.c:2241 [inline]
>  __se_sys_sendmmsg net/socket.c:2238 [inline]
>  __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2238
>  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x445d09
> RSP: 002b:7f3c7eff5d88 EFLAGS: 0293 ORIG_RAX: 0133
> RAX: ffda RBX: 006dac40 RCX: 00445d09
> RDX: 0001 RSI: 00
> 
> 
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
> 
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address.git branch
> and provide the patch inline or as an attachment.
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report

There's already a bug report 

Re: BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_his

[Eric Biggers]

On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:c1c07416cdd4 Merge tag 'kbuild-fixes-v4.17' of git://git.k..
> git tree:   upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=13d5de4780
> kernel config:  https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27
> dashboard link: https://syzkaller.appspot.com/bug?extid=99858724c0ba555a12ea
> compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=170afde780
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=141b4be780
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+99858724c0ba555a1...@syzkaller.appspotmail.com
> 
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at
> net/dccp/ccids/lib/packet_history.c:425/tfrc_rx_hist_sample_rtt()
> CPU: 0 PID: 4495 Comm: syz-executor551 Not tainted 4.17.0-rc3+ #34
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
>  tfrc_rx_hist_sample_rtt.cold.3+0x54/0x5c
> net/dccp/ccids/lib/packet_history.c:422
>  ccid3_hc_rx_packet_recv+0x5c8/0xed0 net/dccp/ccids/ccid3.c:765
>  ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
>  dccp_deliver_input_to_ccids+0xf0/0x280 net/dccp/input.c:180
>  dccp_rcv_established+0x87/0xb0 net/dccp/input.c:378
>  dccp_v4_do_rcv+0x153/0x180 net/dccp/ipv4.c:654
>  sk_backlog_rcv include/net/sock.h:909 [inline]
>  __sk_receive_skb+0x3a2/0xd60 net/core/sock.c:513
>  dccp_v4_rcv+0x10e5/0x1f3f net/dccp/ipv4.c:875
>  ip_local_deliver_finish+0x2e3/0xd80 net/ipv4/ip_input.c:215
>  NF_HOOK include/linux/netfilter.h:288 [inline]
>  ip_local_deliver+0x1e1/0x720 net/ipv4/ip_input.c:256
>  dst_input include/net/dst.h:450 [inline]
>  ip_rcv_finish+0x81b/0x2200 net/ipv4/ip_input.c:396
>  NF_HOOK include/linux/netfilter.h:288 [inline]
>  ip_rcv+0xb70/0x143d net/ipv4/ip_input.c:492
>  __netif_receive_skb_core+0x26f5/0x3630 net/core/dev.c:4592
>  __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4657
>  process_backlog+0x219/0x760 net/core/dev.c:5337
>  napi_poll net/core/dev.c:5735 [inline]
>  net_rx_action+0x7b7/0x1930 net/core/dev.c:5801
>  __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
>  do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1046
>  
>  do_softirq.part.17+0x14d/0x190 kernel/softirq.c:329
>  do_softirq arch/x86/include/asm/preempt.h:23 [inline]
>  __local_bh_enable_ip+0x1ec/0x230 kernel/softirq.c:182
>  local_bh_enable include/linux/bottom_half.h:32 [inline]
>  rcu_read_unlock_bh include/linux/rcupdate.h:728 [inline]
>  ip_finish_output2+0xab2/0x1840 net/ipv4/ip_output.c:231
>  ip_finish_output+0x828/0xf80 net/ipv4/ip_output.c:317
>  NF_HOOK_COND include/linux/netfilter.h:277 [inline]
>  ip_output+0x21b/0x850 net/ipv4/ip_output.c:405
>  dst_output include/net/dst.h:444 [inline]
>  ip_local_out+0xc5/0x1b0 net/ipv4/ip_output.c:124
>  ip_queue_xmit+0x9d7/0x1f70 net/ipv4/ip_output.c:504
>  dccp_transmit_skb+0x999/0x12e0 net/dccp/output.c:142
>  dccp_xmit_packet+0x250/0x790 net/dccp/output.c:281
>  dccp_write_xmit+0x190/0x1f0 net/dccp/output.c:363
>  dccp_sendmsg+0x8c7/0x1020 net/dccp/proto.c:818
>  inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
>  sock_sendmsg_nosec net/socket.c:629 [inline]
>  sock_sendmsg+0xd5/0x120 net/socket.c:639
>  ___sys_sendmsg+0x525/0x940 net/socket.c:2117
>  __sys_sendmmsg+0x240/0x6f0 net/socket.c:2212
>  __do_sys_sendmmsg net/socket.c:2241 [inline]
>  __se_sys_sendmmsg net/socket.c:2238 [inline]
>  __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2238
>  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x445d09
> RSP: 002b:7f3c7eff5d88 EFLAGS: 0293 ORIG_RAX: 0133
> RAX: ffda RBX: 006dac40 RCX: 00445d09
> RDX: 0001 RSI: 00
> 
> 
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
> 
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address.git branch
> and provide the patch inline or as an attachment.
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report

There's already a bug report 

Re: [PATCH 2/4] pid: Export find_task_by_vpid for use in external modules

[Eric W. Biederman]

Kim Phillips  writes:

> This patch is in the context of allowing the Coresight h/w
> trace driver suite to be loaded as modules.  Coresight uses
> find_task_by_vpid when running in direct capture mode (via sysfs)
> when getting/setting the context ID comparator to trigger on
> (/sys/bus/coresight/devices/.etm/ctxid_pid).

Aside from my objection about how bad an interface a pid in sysfs is.
The implementation of coresight_vpid_to_pid is horrible.

The code should be just:

static inline pid_t coresight_vpid_to_pid(pid_t vpid)
{
rcu_read_lock();
pid = pid_nr(find_vpid(vpid));
rcu_read_unlock();

return pid;
}
Which takes find_task_by_vpid out of the picture.

But reading further I am seeing code writing a pid to hardware.  That is
broken.  That is a layering violation of the first order.  Giving
implementation details like that to hardware.

Any chance while you are working on this you can modify this code so
that it does something sensible and defensible instead of every line of
code I read be wrong in at least one detail?

Thank you,
Eric

Re: [PATCH 2/4] pid: Export find_task_by_vpid for use in external modules

[Eric W. Biederman]

Kim Phillips  writes:

> This patch is in the context of allowing the Coresight h/w
> trace driver suite to be loaded as modules.  Coresight uses
> find_task_by_vpid when running in direct capture mode (via sysfs)
> when getting/setting the context ID comparator to trigger on
> (/sys/bus/coresight/devices/.etm/ctxid_pid).

Aside from my objection about how bad an interface a pid in sysfs is.
The implementation of coresight_vpid_to_pid is horrible.

The code should be just:

static inline pid_t coresight_vpid_to_pid(pid_t vpid)
{
rcu_read_lock();
pid = pid_nr(find_vpid(vpid));
rcu_read_unlock();

return pid;
}
Which takes find_task_by_vpid out of the picture.

But reading further I am seeing code writing a pid to hardware.  That is
broken.  That is a layering violation of the first order.  Giving
implementation details like that to hardware.

Any chance while you are working on this you can modify this code so
that it does something sensible and defensible instead of every line of
code I read be wrong in at least one detail?

Thank you,
Eric

linux-next: build warning after merge of the mac80211-next tree

[Stephen Rothwell]

Hi Johannes,

After merging the mac80211-next tree, today's linux-next build (arm_multi
v7_defconfig) produced this warning:

drivers/net/wireless/marvell/mwifiex/uap_event.c: In function 
'mwifiex_process_uap_event':
drivers/net/wireless/marvell/mwifiex/uap_event.c:333:1: warning: the frame size 
of 1680 bytes is larger than 1024 bytes [-Wframe-larger-than=]
 }
 ^
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c: In function 
'brcmf_notify_connect_status_ap':
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:5530:1: warning: 
the frame size of 1680 bytes is larger than 1024 bytes [-Wframe-larger-than=]
 }
 ^

Maybe introduced by commit

  52539ca89f36 ("cfg80211: Expose TXQ stats and parameters to userspace")

-- 
Cheers,
Stephen Rothwell


pgpwfKYVnWqOq.pgp
Description: OpenPGP digital signature

linux-next: build warning after merge of the mac80211-next tree

[Stephen Rothwell]

Hi Johannes,

After merging the mac80211-next tree, today's linux-next build (arm_multi
v7_defconfig) produced this warning:

drivers/net/wireless/marvell/mwifiex/uap_event.c: In function 
'mwifiex_process_uap_event':
drivers/net/wireless/marvell/mwifiex/uap_event.c:333:1: warning: the frame size 
of 1680 bytes is larger than 1024 bytes [-Wframe-larger-than=]
 }
 ^
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c: In function 
'brcmf_notify_connect_status_ap':
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:5530:1: warning: 
the frame size of 1680 bytes is larger than 1024 bytes [-Wframe-larger-than=]
 }
 ^

Maybe introduced by commit

  52539ca89f36 ("cfg80211: Expose TXQ stats and parameters to userspace")

-- 
Cheers,
Stephen Rothwell


pgpwfKYVnWqOq.pgp
Description: OpenPGP digital signature

Re: [PATCH] Revert "cpufreq: schedutil: Don't restrict kthread to related_cpus unnecessarily"

[Viresh Kumar]

On 08-05-18, 08:33, Dietmar Eggemann wrote:
> This reverts commit e2cabe48c20efb174ce0c01190f8b9c5f3ea1d13.
> 
> Lifting the restriction that the sugov kthread is bound to the
> policy->related_cpus for a system with a slow switching cpufreq driver,
> which is able to perform DVFS from any cpu (e.g. cpufreq-dt), is not
> only not beneficial it also harms Enery-Aware Scheduling (EAS) on
> systems with asymmetric cpu capacities (e.g. Arm big.LITTLE).
> 
> The sugov kthread which does the update for the little cpus could
> potentially run on a big cpu. It could prevent that the big cluster goes
> into deeper idle states although all the tasks are running on the little
> cluster.
> 
> Example: hikey960 w/ 4.16.0-rc6-+
>  Arm big.LITTLE with per-cluster DVFS
> 
> root@h960:~# cat /proc/cpuinfo | grep "^CPU part"
> CPU part: 0xd03 (Cortex-A53, little cpu)
> CPU part: 0xd03
> CPU part: 0xd03
> CPU part: 0xd03
> CPU part: 0xd09 (Cortex-A73, big cpu)
> CPU part: 0xd09
> CPU part: 0xd09
> CPU part: 0xd09
> 
> root@h960:/sys/devices/system/cpu/cpufreq# ls
> policy0  policy4  schedutil
> 
> root@h960:/sys/devices/system/cpu/cpufreq# cat policy*/related_cpus
> 0 1 2 3
> 4 5 6 7
> 
> (1) w/o the revert:
> 
> root@h960:~# ps -eo pid,class,rtprio,pri,psr,comm | awk 'NR == 1 ||
> /sugov/'
>   PID CLS RTPRIO PRI PSR COMMAND
>   1489 #6  0 140   1 sugov:0
>   1490 #6  0 140   0 sugov:4
> 
> The sugov kthread sugov:4 responsible for policy4 runs on cpu0. (In this
> case both sugov kthreads run on little cpus).
> 
> cross policy (cluster) remote callback example:
> ...
> migration/1-14 [001] enqueue_task_fair: this_cpu=1 cpu_of(rq)=5
> migration/1-14 [001] sugov_update_shared: this_cpu=1 sg_cpu->cpu=5
>  sg_cpu->sg_policy->policy->related_cpus=4-7
>   sugov:4-1490 [000] sugov_work: this_cpu=0
>  sg_cpu->sg_policy->policy->related_cpus=4-7
> ...
> 
> The remote callback (this_cpu=1, target_cpu=5) is executed on cpu=0.
> 
> (2) w/ the revert:
> 
> root@h960:~# ps -eo pid,class,rtprio,pri,psr,comm | awk 'NR == 1 ||
> /sugov/'
>   PID CLS RTPRIO PRI PSR COMMAND
>   1491 #6  0 140   2 sugov:0
>   1492 #6  0 140   4 sugov:4
> 
> The sugov kthread sugov:4 responsible for policy4 runs on cpu4.
> 
> cross policy (cluster) remote callback example:
> ...
> migration/1-14 [001] enqueue_task_fair: this_cpu=1 cpu_of(rq)=7
> migration/1-14 [001] sugov_update_shared: this_cpu=1 sg_cpu->cpu=7
>  sg_cpu->sg_policy->policy->related_cpus=4-7
>   sugov:4-1492 [004] sugov_work: this_cpu=4
>  sg_cpu->sg_policy->policy->related_cpus=4-7
> ...
> 
> The remote callback (this_cpu=1, target_cpu=7) is executed on cpu=4.
> 
> Now the sugov kthread executes again on the policy (cluster) for which
> the Operating Performance Point (OPP) should be changed.
> It avoids the problem that an otherwise idle policy (cluster) is running
> schedutil (the sugov kthread) for another one.
> 
> Cc: Viresh Kumar 
> Cc: Rafael J. Wysocki 
> Cc: Peter Zijlstra 
> Cc: Ingo Molnar 
> Cc: Pavan Kondeti 
> Cc: Juri Lelli 
> Cc: Joel Fernandes 
> Cc: Patrick Bellasi 
> Cc: Quentin Perret 
> Signed-off-by: Dietmar Eggemann 
> ---
>  kernel/sched/cpufreq_schedutil.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/kernel/sched/cpufreq_schedutil.c 
> b/kernel/sched/cpufreq_schedutil.c
> index d2c6083304b4..63014cff76a5 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -523,11 +523,7 @@ static int sugov_kthread_create(struct sugov_policy 
> *sg_policy)
>   }
>  
>   sg_policy->thread = thread;
> -
> - /* Kthread is bound to all CPUs by default */
> - if (!policy->dvfs_possible_from_any_cpu)
> - kthread_bind_mask(thread, policy->related_cpus);
> -
> + kthread_bind_mask(thread, policy->related_cpus);
>   init_irq_work(_policy->irq_work, sugov_irq_work);
>   mutex_init(_policy->work_lock);
>  

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH] Revert "cpufreq: schedutil: Don't restrict kthread to related_cpus unnecessarily"

[Viresh Kumar]

On 08-05-18, 08:33, Dietmar Eggemann wrote:
> This reverts commit e2cabe48c20efb174ce0c01190f8b9c5f3ea1d13.
> 
> Lifting the restriction that the sugov kthread is bound to the
> policy->related_cpus for a system with a slow switching cpufreq driver,
> which is able to perform DVFS from any cpu (e.g. cpufreq-dt), is not
> only not beneficial it also harms Enery-Aware Scheduling (EAS) on
> systems with asymmetric cpu capacities (e.g. Arm big.LITTLE).
> 
> The sugov kthread which does the update for the little cpus could
> potentially run on a big cpu. It could prevent that the big cluster goes
> into deeper idle states although all the tasks are running on the little
> cluster.
> 
> Example: hikey960 w/ 4.16.0-rc6-+
>  Arm big.LITTLE with per-cluster DVFS
> 
> root@h960:~# cat /proc/cpuinfo | grep "^CPU part"
> CPU part: 0xd03 (Cortex-A53, little cpu)
> CPU part: 0xd03
> CPU part: 0xd03
> CPU part: 0xd03
> CPU part: 0xd09 (Cortex-A73, big cpu)
> CPU part: 0xd09
> CPU part: 0xd09
> CPU part: 0xd09
> 
> root@h960:/sys/devices/system/cpu/cpufreq# ls
> policy0  policy4  schedutil
> 
> root@h960:/sys/devices/system/cpu/cpufreq# cat policy*/related_cpus
> 0 1 2 3
> 4 5 6 7
> 
> (1) w/o the revert:
> 
> root@h960:~# ps -eo pid,class,rtprio,pri,psr,comm | awk 'NR == 1 ||
> /sugov/'
>   PID CLS RTPRIO PRI PSR COMMAND
>   1489 #6  0 140   1 sugov:0
>   1490 #6  0 140   0 sugov:4
> 
> The sugov kthread sugov:4 responsible for policy4 runs on cpu0. (In this
> case both sugov kthreads run on little cpus).
> 
> cross policy (cluster) remote callback example:
> ...
> migration/1-14 [001] enqueue_task_fair: this_cpu=1 cpu_of(rq)=5
> migration/1-14 [001] sugov_update_shared: this_cpu=1 sg_cpu->cpu=5
>  sg_cpu->sg_policy->policy->related_cpus=4-7
>   sugov:4-1490 [000] sugov_work: this_cpu=0
>  sg_cpu->sg_policy->policy->related_cpus=4-7
> ...
> 
> The remote callback (this_cpu=1, target_cpu=5) is executed on cpu=0.
> 
> (2) w/ the revert:
> 
> root@h960:~# ps -eo pid,class,rtprio,pri,psr,comm | awk 'NR == 1 ||
> /sugov/'
>   PID CLS RTPRIO PRI PSR COMMAND
>   1491 #6  0 140   2 sugov:0
>   1492 #6  0 140   4 sugov:4
> 
> The sugov kthread sugov:4 responsible for policy4 runs on cpu4.
> 
> cross policy (cluster) remote callback example:
> ...
> migration/1-14 [001] enqueue_task_fair: this_cpu=1 cpu_of(rq)=7
> migration/1-14 [001] sugov_update_shared: this_cpu=1 sg_cpu->cpu=7
>  sg_cpu->sg_policy->policy->related_cpus=4-7
>   sugov:4-1492 [004] sugov_work: this_cpu=4
>  sg_cpu->sg_policy->policy->related_cpus=4-7
> ...
> 
> The remote callback (this_cpu=1, target_cpu=7) is executed on cpu=4.
> 
> Now the sugov kthread executes again on the policy (cluster) for which
> the Operating Performance Point (OPP) should be changed.
> It avoids the problem that an otherwise idle policy (cluster) is running
> schedutil (the sugov kthread) for another one.
> 
> Cc: Viresh Kumar 
> Cc: Rafael J. Wysocki 
> Cc: Peter Zijlstra 
> Cc: Ingo Molnar 
> Cc: Pavan Kondeti 
> Cc: Juri Lelli 
> Cc: Joel Fernandes 
> Cc: Patrick Bellasi 
> Cc: Quentin Perret 
> Signed-off-by: Dietmar Eggemann 
> ---
>  kernel/sched/cpufreq_schedutil.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/kernel/sched/cpufreq_schedutil.c 
> b/kernel/sched/cpufreq_schedutil.c
> index d2c6083304b4..63014cff76a5 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -523,11 +523,7 @@ static int sugov_kthread_create(struct sugov_policy 
> *sg_policy)
>   }
>  
>   sg_policy->thread = thread;
> -
> - /* Kthread is bound to all CPUs by default */
> - if (!policy->dvfs_possible_from_any_cpu)
> - kthread_bind_mask(thread, policy->related_cpus);
> -
> + kthread_bind_mask(thread, policy->related_cpus);
>   init_irq_work(_policy->irq_work, sugov_irq_work);
>   mutex_init(_policy->work_lock);
>  

Acked-by: Viresh Kumar 

-- 
viresh

Re: [RFC PATCH] sched/cpufreq/schedutil: handling urgent frequency requests

[Joel Fernandes]

On Tue, May 08, 2018 at 12:24:35PM +0530, Viresh Kumar wrote:
> On 07-05-18, 16:43, Claudio Scordino wrote:
> > At OSPM, it was mentioned the issue about urgent CPU frequency requests
> > arriving when a frequency switch is already in progress.
> > 
> > Besides the various issues (physical time for switching frequency,
> > on-going kthread activity, etc.) one (minor) issue is the kernel
> > "forgetting" such request, thus waiting the next switch time for
> > recomputing the needed frequency and behaving accordingly.
> > 
> > This patch makes the kthread serve any urgent request occurred during
> > the previous frequency switch. It introduces a specific flag, only set
> > when the SCHED_DEADLINE scheduling class increases the CPU utilization,
> > aiming at decreasing the likelihood of a deadline miss.
> > 
> > Indeed, some preliminary tests in critical conditions (i.e.
> > SCHED_DEADLINE tasks with short periods) have shown reductions of more
> > than 10% of the average number of deadline misses. On the other hand,
> > the increase in terms of energy consumption when running SCHED_DEADLINE
> > tasks (not yet measured) is likely to be not negligible (especially in
> > case of critical scenarios like "ramp up" utilizations).
> > 
> > The patch is meant as follow-up discussion after OSPM.
> > 
> > Signed-off-by: Claudio Scordino 
> > CC: Viresh Kumar 
> > CC: Rafael J. Wysocki 
> > CC: Peter Zijlstra 
> > CC: Ingo Molnar 
> > CC: Patrick Bellasi 
> > CC: Juri Lelli 
> > Cc: Luca Abeni 
> > CC: Joel Fernandes 
> > CC: linux...@vger.kernel.org
> > ---
> >  kernel/sched/cpufreq_schedutil.c | 20 ++--
> >  1 file changed, 18 insertions(+), 2 deletions(-)
> > 
> > diff --git a/kernel/sched/cpufreq_schedutil.c 
> > b/kernel/sched/cpufreq_schedutil.c
> > index d2c6083..4de06b0 100644
> > --- a/kernel/sched/cpufreq_schedutil.c
> > +++ b/kernel/sched/cpufreq_schedutil.c
> > @@ -41,6 +41,7 @@ struct sugov_policy {
> > boolwork_in_progress;
> >  
> > boolneed_freq_update;
> > +   boolurgent_freq_update;
> >  };
> >  
> >  struct sugov_cpu {
> > @@ -92,6 +93,14 @@ static bool sugov_should_update_freq(struct sugov_policy 
> > *sg_policy, u64 time)
> > !cpufreq_can_do_remote_dvfs(sg_policy->policy))
> > return false;
> >  
> > +   /*
> > +* Continue computing the new frequency. In case of work_in_progress,
> > +* the kthread will resched a change once the current transition is
> > +* finished.
> > +*/
> > +   if (sg_policy->urgent_freq_update)
> > +   return true;
> > +
> > if (sg_policy->work_in_progress)
> > return false;
> >  
> > @@ -121,6 +130,9 @@ static void sugov_update_commit(struct sugov_policy 
> > *sg_policy, u64 time,
> > sg_policy->next_freq = next_freq;
> > sg_policy->last_freq_update_time = time;
> >  
> > +   if (sg_policy->work_in_progress)
> > +   return;
> > +
> > if (policy->fast_switch_enabled) {
> > next_freq = cpufreq_driver_fast_switch(policy, next_freq);
> > if (!next_freq)
> > @@ -274,7 +286,7 @@ static inline bool sugov_cpu_is_busy(struct sugov_cpu 
> > *sg_cpu) { return false; }
> >  static inline void ignore_dl_rate_limit(struct sugov_cpu *sg_cpu, struct 
> > sugov_policy *sg_policy)
> >  {
> > if (cpu_util_dl(cpu_rq(sg_cpu->cpu)) > sg_cpu->util_dl)
> > -   sg_policy->need_freq_update = true;
> > +   sg_policy->urgent_freq_update = true;
> >  }
> >  
> >  static void sugov_update_single(struct update_util_data *hook, u64 time,
> > @@ -383,8 +395,11 @@ static void sugov_work(struct kthread_work *work)
> > struct sugov_policy *sg_policy = container_of(work, struct 
> > sugov_policy, work);
> >  
> > mutex_lock(_policy->work_lock);
> > -   __cpufreq_driver_target(sg_policy->policy, sg_policy->next_freq,
> > +   do {
> > +   sg_policy->urgent_freq_update = false;
> > +   __cpufreq_driver_target(sg_policy->policy, sg_policy->next_freq,
> > CPUFREQ_RELATION_L);
> 
> If we are going to solve this problem, then maybe instead of the added
> complexity and a new flag we can look for need_freq_update flag at this 
> location
> and re-calculate the next frequency if required.

Just for discussion sake, is there any need for work_in_progress? If we can
queue multiple work say kthread_queue_work can handle it, then just queuing
works whenever they are available should be Ok and the kthread loop can
handle them. __cpufreq_driver_target is also protected by the work lock if
there is any concern that can have races... only thing is rate-limiting of
the requests, but we are doing a rate limiting, just not for the "DL
increased utilization" type 

Re: [RFC PATCH] sched/cpufreq/schedutil: handling urgent frequency requests

[Joel Fernandes]

On Tue, May 08, 2018 at 12:24:35PM +0530, Viresh Kumar wrote:
> On 07-05-18, 16:43, Claudio Scordino wrote:
> > At OSPM, it was mentioned the issue about urgent CPU frequency requests
> > arriving when a frequency switch is already in progress.
> > 
> > Besides the various issues (physical time for switching frequency,
> > on-going kthread activity, etc.) one (minor) issue is the kernel
> > "forgetting" such request, thus waiting the next switch time for
> > recomputing the needed frequency and behaving accordingly.
> > 
> > This patch makes the kthread serve any urgent request occurred during
> > the previous frequency switch. It introduces a specific flag, only set
> > when the SCHED_DEADLINE scheduling class increases the CPU utilization,
> > aiming at decreasing the likelihood of a deadline miss.
> > 
> > Indeed, some preliminary tests in critical conditions (i.e.
> > SCHED_DEADLINE tasks with short periods) have shown reductions of more
> > than 10% of the average number of deadline misses. On the other hand,
> > the increase in terms of energy consumption when running SCHED_DEADLINE
> > tasks (not yet measured) is likely to be not negligible (especially in
> > case of critical scenarios like "ramp up" utilizations).
> > 
> > The patch is meant as follow-up discussion after OSPM.
> > 
> > Signed-off-by: Claudio Scordino 
> > CC: Viresh Kumar 
> > CC: Rafael J. Wysocki 
> > CC: Peter Zijlstra 
> > CC: Ingo Molnar 
> > CC: Patrick Bellasi 
> > CC: Juri Lelli 
> > Cc: Luca Abeni 
> > CC: Joel Fernandes 
> > CC: linux...@vger.kernel.org
> > ---
> >  kernel/sched/cpufreq_schedutil.c | 20 ++--
> >  1 file changed, 18 insertions(+), 2 deletions(-)
> > 
> > diff --git a/kernel/sched/cpufreq_schedutil.c 
> > b/kernel/sched/cpufreq_schedutil.c
> > index d2c6083..4de06b0 100644
> > --- a/kernel/sched/cpufreq_schedutil.c
> > +++ b/kernel/sched/cpufreq_schedutil.c
> > @@ -41,6 +41,7 @@ struct sugov_policy {
> > boolwork_in_progress;
> >  
> > boolneed_freq_update;
> > +   boolurgent_freq_update;
> >  };
> >  
> >  struct sugov_cpu {
> > @@ -92,6 +93,14 @@ static bool sugov_should_update_freq(struct sugov_policy 
> > *sg_policy, u64 time)
> > !cpufreq_can_do_remote_dvfs(sg_policy->policy))
> > return false;
> >  
> > +   /*
> > +* Continue computing the new frequency. In case of work_in_progress,
> > +* the kthread will resched a change once the current transition is
> > +* finished.
> > +*/
> > +   if (sg_policy->urgent_freq_update)
> > +   return true;
> > +
> > if (sg_policy->work_in_progress)
> > return false;
> >  
> > @@ -121,6 +130,9 @@ static void sugov_update_commit(struct sugov_policy 
> > *sg_policy, u64 time,
> > sg_policy->next_freq = next_freq;
> > sg_policy->last_freq_update_time = time;
> >  
> > +   if (sg_policy->work_in_progress)
> > +   return;
> > +
> > if (policy->fast_switch_enabled) {
> > next_freq = cpufreq_driver_fast_switch(policy, next_freq);
> > if (!next_freq)
> > @@ -274,7 +286,7 @@ static inline bool sugov_cpu_is_busy(struct sugov_cpu 
> > *sg_cpu) { return false; }
> >  static inline void ignore_dl_rate_limit(struct sugov_cpu *sg_cpu, struct 
> > sugov_policy *sg_policy)
> >  {
> > if (cpu_util_dl(cpu_rq(sg_cpu->cpu)) > sg_cpu->util_dl)
> > -   sg_policy->need_freq_update = true;
> > +   sg_policy->urgent_freq_update = true;
> >  }
> >  
> >  static void sugov_update_single(struct update_util_data *hook, u64 time,
> > @@ -383,8 +395,11 @@ static void sugov_work(struct kthread_work *work)
> > struct sugov_policy *sg_policy = container_of(work, struct 
> > sugov_policy, work);
> >  
> > mutex_lock(_policy->work_lock);
> > -   __cpufreq_driver_target(sg_policy->policy, sg_policy->next_freq,
> > +   do {
> > +   sg_policy->urgent_freq_update = false;
> > +   __cpufreq_driver_target(sg_policy->policy, sg_policy->next_freq,
> > CPUFREQ_RELATION_L);
> 
> If we are going to solve this problem, then maybe instead of the added
> complexity and a new flag we can look for need_freq_update flag at this 
> location
> and re-calculate the next frequency if required.

Just for discussion sake, is there any need for work_in_progress? If we can
queue multiple work say kthread_queue_work can handle it, then just queuing
works whenever they are available should be Ok and the kthread loop can
handle them. __cpufreq_driver_target is also protected by the work lock if
there is any concern that can have races... only thing is rate-limiting of
the requests, but we are doing a rate limiting, just not for the "DL
increased utilization" type requests (which I don't think we are doing at the
moment for urgent DL requests anyway).

Following is an untested diff to show the idea. What do you think?

thanks,

- Joel

8<---
diff --git 

Re: [PATCH] Revert "cpufreq: schedutil: Don't restrict kthread to related_cpus unnecessarily"

[Viresh Kumar]

On 08-05-18, 22:36, Rafael J. Wysocki wrote:
> Because that makes things more complex and harder to debug in general.
> 
> What's the exact reason why non-policy CPUs should ever run the sugov
> kthread for the given policy?

The only benefit was to let the scheduler run the kthread on the best
CPU (according to the scheduler), which may help reducing the delay in
running the kthread. But given the way deadline scheduler works, I
don't see a reason why this should be done anymore.

-- 
viresh

Re: [PATCH] Revert "cpufreq: schedutil: Don't restrict kthread to related_cpus unnecessarily"

[Viresh Kumar]

On 08-05-18, 22:36, Rafael J. Wysocki wrote:
> Because that makes things more complex and harder to debug in general.
> 
> What's the exact reason why non-policy CPUs should ever run the sugov
> kthread for the given policy?

The only benefit was to let the scheduler run the kthread on the best
CPU (according to the scheduler), which may help reducing the delay in
running the kthread. But given the way deadline scheduler works, I
don't see a reason why this should be done anymore.

-- 
viresh

Re: [PATCH] Kirin-PCIe: Add kirin pcie msi feature.

[Shawn Guo]

Hi Bjorn,

On Tue, May 08, 2018 at 07:56:58AM -0500, Bjorn Helgaas wrote:
...
> > +   return ret;
> > +   }
> > +   }
> > +
> > +   pci->pp.root_bus_nr = -1;
> 
> Setting root_bus_nr looks like an unrelated change that should be in a
> separate patch.
> 
> But I'm not sure why you need to set root_bus_nr at all, since
> dw_pcie_host_init() always sets it.
> 
> Some other callers of dw_pcie_host_init() do set it:
> 
>   exynos_add_pcie_port()
>   imx6_add_pcie_port()
>   armada8k_add_pcie_port()
>   artpec6_add_pcie_port()
>   dw_plat_add_pcie_port()
>   histb_pcie_probe()
>   qcom_pcie_probe()
>   spear13xx_add_pcie_port()
> 
> But I don't see *why* any of these need to set it.  If they don't need to
> set it, they shouldn't.

Mostly it's a blind copy of unnecessary code.  I tested histb driver
by dropping the line, and did not see anything broken.  I will cook up
a series to remove the code from all above drivers, and copy
corresponding driver owner to comment.

> And it would be nice if histb and qcom followed the structure and naming
> conventions of the other drivers, i.e., they should have
> histb_add_pcie_port() and qcom_add_pcie_port().

I can create a patch for histb driver, but will leave qcom one to
Stanimir to decide.

Shawn

> 
> > pci->pp.ops = _pcie_host_ops;
> >  
> > return dw_pcie_host_init(>pp);
> > -- 
> > 1.9.1
> > 
> > 
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] Kirin-PCIe: Add kirin pcie msi feature.

[Shawn Guo]

Hi Bjorn,

On Tue, May 08, 2018 at 07:56:58AM -0500, Bjorn Helgaas wrote:
...
> > +   return ret;
> > +   }
> > +   }
> > +
> > +   pci->pp.root_bus_nr = -1;
> 
> Setting root_bus_nr looks like an unrelated change that should be in a
> separate patch.
> 
> But I'm not sure why you need to set root_bus_nr at all, since
> dw_pcie_host_init() always sets it.
> 
> Some other callers of dw_pcie_host_init() do set it:
> 
>   exynos_add_pcie_port()
>   imx6_add_pcie_port()
>   armada8k_add_pcie_port()
>   artpec6_add_pcie_port()
>   dw_plat_add_pcie_port()
>   histb_pcie_probe()
>   qcom_pcie_probe()
>   spear13xx_add_pcie_port()
> 
> But I don't see *why* any of these need to set it.  If they don't need to
> set it, they shouldn't.

Mostly it's a blind copy of unnecessary code.  I tested histb driver
by dropping the line, and did not see anything broken.  I will cook up
a series to remove the code from all above drivers, and copy
corresponding driver owner to comment.

> And it would be nice if histb and qcom followed the structure and naming
> conventions of the other drivers, i.e., they should have
> histb_add_pcie_port() and qcom_add_pcie_port().

I can create a patch for histb driver, but will leave qcom one to
Stanimir to decide.

Shawn

> 
> > pci->pp.ops = _pcie_host_ops;
> >  
> > return dw_pcie_host_init(>pp);
> > -- 
> > 1.9.1
> > 
> > 
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

linux-next: build warning after merge of the bpf-next tree

[Stephen Rothwell]

Hi all,

After merging the bpf-next tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

In file included from include/linux/dma-mapping.h:5:0,
 from include/linux/skbuff.h:34,
 from include/linux/if_ether.h:23,
 from include/uapi/linux/bpf.h:13,
 from include/linux/bpf-cgroup.h:6,
 from include/linux/cgroup-defs.h:22,
 from include/linux/cgroup.h:28,
 from include/linux/perf_event.h:57,
 from include/linux/trace_events.h:10,
 from include/trace/trace_events.h:20,
 from include/trace/define_trace.h:96,
 from drivers/android/binder_trace.h:387,
 from drivers/android/binder.c:5702:
include/linux/sizes.h:24:0: warning: "SZ_1K" redefined
 #define SZ_1K0x0400
drivers/android/binder.c:116:0: note: this is the location of the previous 
definition
 #define SZ_1K   0x400
In file included from include/linux/dma-mapping.h:5:0,
 from include/linux/skbuff.h:34,
 from include/linux/if_ether.h:23,
 from include/uapi/linux/bpf.h:13,
 from include/linux/bpf-cgroup.h:6,
 from include/linux/cgroup-defs.h:22,
 from include/linux/cgroup.h:28,
 from include/linux/perf_event.h:57,
 from include/linux/trace_events.h:10,
 from include/trace/trace_events.h:20,
 from include/trace/define_trace.h:96,
 from drivers/android/binder_trace.h:387,
 from drivers/android/binder.c:5702:
include/linux/sizes.h:37:0: warning: "SZ_4M" redefined
 #define SZ_4M0x0040
drivers/android/binder.c:120:0: note: this is the location of the previous 
definition
 #define SZ_4M   0x40
fs/ecryptfs/miscdev.c:206:0: warning: "PKT_TYPE_OFFSET" redefined
 #define PKT_TYPE_OFFSET  0
In file included from include/linux/if_ether.h:23:0,
 from include/uapi/linux/bpf.h:13,
 from include/linux/bpf-cgroup.h:6,
 from include/linux/cgroup-defs.h:22,
 from include/linux/cgroup.h:28,
 from include/linux/writeback.h:183,
 from include/linux/backing-dev.h:16,
 from fs/ecryptfs/ecryptfs_kernel.h:41,
 from fs/ecryptfs/miscdev.c:30:
include/linux/skbuff.h:753:0: note: this is the location of the previous 
definition
 #define PKT_TYPE_OFFSET() offsetof(struct sk_buff, __pkt_type_offset)

Introduced by commit

  9c38f3c8b153 ("bpf: Provide helper to do forwarding lookups in kernel FIB 
table")

-- 
Cheers,
Stephen Rothwell


pgp1Fsn88Ika_.pgp
Description: OpenPGP digital signature

linux-next: build warning after merge of the bpf-next tree

[Stephen Rothwell]

Hi all,

After merging the bpf-next tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

In file included from include/linux/dma-mapping.h:5:0,
 from include/linux/skbuff.h:34,
 from include/linux/if_ether.h:23,
 from include/uapi/linux/bpf.h:13,
 from include/linux/bpf-cgroup.h:6,
 from include/linux/cgroup-defs.h:22,
 from include/linux/cgroup.h:28,
 from include/linux/perf_event.h:57,
 from include/linux/trace_events.h:10,
 from include/trace/trace_events.h:20,
 from include/trace/define_trace.h:96,
 from drivers/android/binder_trace.h:387,
 from drivers/android/binder.c:5702:
include/linux/sizes.h:24:0: warning: "SZ_1K" redefined
 #define SZ_1K0x0400
drivers/android/binder.c:116:0: note: this is the location of the previous 
definition
 #define SZ_1K   0x400
In file included from include/linux/dma-mapping.h:5:0,
 from include/linux/skbuff.h:34,
 from include/linux/if_ether.h:23,
 from include/uapi/linux/bpf.h:13,
 from include/linux/bpf-cgroup.h:6,
 from include/linux/cgroup-defs.h:22,
 from include/linux/cgroup.h:28,
 from include/linux/perf_event.h:57,
 from include/linux/trace_events.h:10,
 from include/trace/trace_events.h:20,
 from include/trace/define_trace.h:96,
 from drivers/android/binder_trace.h:387,
 from drivers/android/binder.c:5702:
include/linux/sizes.h:37:0: warning: "SZ_4M" redefined
 #define SZ_4M0x0040
drivers/android/binder.c:120:0: note: this is the location of the previous 
definition
 #define SZ_4M   0x40
fs/ecryptfs/miscdev.c:206:0: warning: "PKT_TYPE_OFFSET" redefined
 #define PKT_TYPE_OFFSET  0
In file included from include/linux/if_ether.h:23:0,
 from include/uapi/linux/bpf.h:13,
 from include/linux/bpf-cgroup.h:6,
 from include/linux/cgroup-defs.h:22,
 from include/linux/cgroup.h:28,
 from include/linux/writeback.h:183,
 from include/linux/backing-dev.h:16,
 from fs/ecryptfs/ecryptfs_kernel.h:41,
 from fs/ecryptfs/miscdev.c:30:
include/linux/skbuff.h:753:0: note: this is the location of the previous 
definition
 #define PKT_TYPE_OFFSET() offsetof(struct sk_buff, __pkt_type_offset)

Introduced by commit

  9c38f3c8b153 ("bpf: Provide helper to do forwarding lookups in kernel FIB 
table")

-- 
Cheers,
Stephen Rothwell


pgp1Fsn88Ika_.pgp
Description: OpenPGP digital signature

RE: [External] Re: [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone

[Huaisheng HS1 Ye]

> 
> On Tue, May 08, 2018 at 02:59:40AM +, Huaisheng HS1 Ye wrote:
> > Currently in our mind, an ideal use scenario is that, we put all page 
> > caches to
> > zone_nvm, without any doubt, page cache is an efficient and common cache
> > implement, but it has a disadvantage that all dirty data within it would 
> > has risk
> > to be missed by power failure or system crash. If we put all page caches to 
> > NVDIMMs,
> > all dirty data will be safe.
> 
> That's a common misconception.  Some dirty data will still be in the
> CPU caches.  Are you planning on building servers which have enough
> capacitance to allow the CPU to flush all dirty data from LLC to NV-DIMM?
> 
Sorry for not being clear.
For CPU caches if there is a power failure, NVDIMM has ADR to guarantee an 
interrupt will be reported to CPU, an interrupt response function should be 
responsible to flush all dirty data to NVDIMM.
If there is a system crush, perhaps CPU couldn't have chance to execute this 
response.

It is hard to make sure everything is safe, what we can do is just to save the 
dirty data which is already stored to Pagecache, but not in CPU cache.
Is this an improvement than current?

> Then there's the problem of reconnecting the page cache (which is
> pointed to by ephemeral data structures like inodes and dentries) to
> the new inodes.
Yes, it is not easy.

> 
> And then you have to convince customers that what you're doing is safe
> enough for them to trust it ;-)
Sure. 

Sincerely,
Huaisheng Ye

RE: [External] Re: [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone

[Huaisheng HS1 Ye]

> 
> On Tue, May 08, 2018 at 02:59:40AM +, Huaisheng HS1 Ye wrote:
> > Currently in our mind, an ideal use scenario is that, we put all page 
> > caches to
> > zone_nvm, without any doubt, page cache is an efficient and common cache
> > implement, but it has a disadvantage that all dirty data within it would 
> > has risk
> > to be missed by power failure or system crash. If we put all page caches to 
> > NVDIMMs,
> > all dirty data will be safe.
> 
> That's a common misconception.  Some dirty data will still be in the
> CPU caches.  Are you planning on building servers which have enough
> capacitance to allow the CPU to flush all dirty data from LLC to NV-DIMM?
> 
Sorry for not being clear.
For CPU caches if there is a power failure, NVDIMM has ADR to guarantee an 
interrupt will be reported to CPU, an interrupt response function should be 
responsible to flush all dirty data to NVDIMM.
If there is a system crush, perhaps CPU couldn't have chance to execute this 
response.

It is hard to make sure everything is safe, what we can do is just to save the 
dirty data which is already stored to Pagecache, but not in CPU cache.
Is this an improvement than current?

> Then there's the problem of reconnecting the page cache (which is
> pointed to by ephemeral data structures like inodes and dentries) to
> the new inodes.
Yes, it is not easy.

> 
> And then you have to convince customers that what you're doing is safe
> enough for them to trust it ;-)
Sure. 

Sincerely,
Huaisheng Ye

Re: [PATCH v4 1/2] clk: x86: Add ST oscout platform clock

[Agrawal, Akshu]

On 5/8/2018 9:08 PM, Deucher, Alexander wrote:
>> -Original Message-
>> From: Agrawal, Akshu
>> Sent: Tuesday, May 8, 2018 12:04 AM
>> To: Deucher, Alexander 
>> Cc: djku...@chromium.org; mturque...@baylibre.com; sb...@kernel.org;
>> Koenig, Christian ; airl...@redhat.com; Liu,
>> Shaoyun ; linux-kernel@vger.kernel.org; linux-
>> c...@vger.kernel.org; r...@rjwysocki.net; l...@kernel.org; linux-
>> a...@vger.kernel.org
>> Subject: Re: [PATCH v4 1/2] clk: x86: Add ST oscout platform clock
>>
>>
>>
>> On 5/8/2018 3:14 AM, Deucher, Alexander wrote:
 -Original Message-
 From: Agrawal, Akshu
 Sent: Monday, May 7, 2018 6:14 AM
 Cc: djku...@chromium.org; Agrawal, Akshu ;
 Deucher, Alexander ;
 mturque...@baylibre.com; sb...@kernel.org; Koenig, Christian
 ; airl...@redhat.com; Liu, Shaoyun
 ; linux-kernel@vger.kernel.org; linux-
 c...@vger.kernel.org; r...@rjwysocki.net; l...@kernel.org; linux-
 a...@vger.kernel.org
 Subject: [PATCH v4 1/2] clk: x86: Add ST oscout platform clock

 Stoney SoC provides oscout clock. This clock can support 25Mhz and
 48Mhz of frequency.
 The clock is available for general system use.

 Signed-off-by: Akshu Agrawal 
 ---
 v2: config change, added SPDX tag and used clk_hw_register_.
 v3: Fix kbuild warning for checking of NULL pointer
 v4: unregister clk_hw in driver remove, add .suppress_bind_attrs
  drivers/clk/x86/Makefile |  3 +-
  drivers/clk/x86/clk-st.c | 85
 
  include/linux/platform_data/clk-st.h | 17 
  3 files changed, 104 insertions(+), 1 deletion(-)  create mode
 100644 drivers/clk/x86/clk-st.c  create mode 100644
 include/linux/platform_data/clk-st.h

 diff --git a/drivers/clk/x86/Makefile b/drivers/clk/x86/Makefile
 index 1367afb..00303bc 100644
 --- a/drivers/clk/x86/Makefile
 +++ b/drivers/clk/x86/Makefile
 @@ -1,3 +1,4 @@
 +obj-$(CONFIG_PMC_ATOM)+= clk-pmc-atom.o
 +obj-$(CONFIG_X86_AMD_PLATFORM_DEVICE) += clk-st.o
  clk-x86-lpss-objs := clk-lpt.o
  obj-$(CONFIG_X86_INTEL_LPSS)  += clk-x86-lpss.o
 -obj-$(CONFIG_PMC_ATOM)+= clk-pmc-atom.o
 diff --git a/drivers/clk/x86/clk-st.c b/drivers/clk/x86/clk-st.c new
 file mode
 100644 index 000..8a7795c
 --- /dev/null
 +++ b/drivers/clk/x86/clk-st.c
 @@ -0,0 +1,85 @@
 +// SPDX-License-Identifier: GPL-2.0
>>>
>>> Should this be MIT?  The original license was MIT.
>>>
>>> Alex
>>>
>>
>> We are adding SPDX tag, while license remains same GPL-2.0
>>
>> What I have read is this is "to provide license identifiers inside the source
>> code that could be easily parsed by machines and would allow checking for
>> license compliance of an open source project easier."
> 
> My point as just that the original license on the file that you first sent 
> out was MIT so the SPDX tag should be MIT rather than GPL.  E.g.,
> SPDX-License-Identifier: MIT
> 
Oh right it should be MIT, will change it.

Thanks,
Akshu

Re: [Ksummit-discuss] bug-introducing patches

[Willy Tarreau]

On Tue, May 08, 2018 at 08:29:14PM +, Sasha Levin wrote:
> What if, instead, Linus doesn't actually ever release a point release?
> We can make the merge window open more often, and since there's no
> actual release, people won't rush to push fixes in later -rc cycles.

And then what's the purpose of these later -rc cycles if you remove one
release ? You're just removing one step and shifting everything down by
one -rc but the issues are the same.

> We take away the incentive to push poorly tested code. Maintainers still
> free to commit anything they'd like, but there's no reason to commit
> code they're not confident of just to make it to a random release no one
> will use.
> 
> Merge window will happen more often, so there's no real reason to rush
> things in a particular window, and since -stable releases every week
> there's no rush to push a fix in since the next release is just a week
> away.

I'm not sure what model you're having in mind but the description above
reminds me of 2.5 which was constantly had something broken and which
used to be unusable for many developers. Many of us even bought some
SCSI cards and disks by then because for a long time IDE was broken.

The primary purpose of Linus' releases and -rc is to synchronise everyone
on the same goal at the same time. The merge window is "send me your crap,
it must be OK but we know problems happen and you'll be allowed to fix it
later". The -rc ones are there so that everyone fixes their crap in
parallel so that we converge towards something acceptable for everyone.

Your argument that the .0 release is useless is wrong in my opinion. It
is as wrong as saying "statistics show that less people use .3 than .7".
And comparing "stable kernels" to ".0" is wrong because there are roughly
10 times more stable kernels than releases so statistically you'll find
10 times more of them in field. The reality is that deploying .0 always
takes a bit more time for end users so statistically it should be a bit
less common in field :
  - you're never certain when the new version is going to be released
(will rc8/rc9 exist?)
  - when it's released, you have to update your config and it takes
some time.
  - by the time you find a quiet moment to do all this, it's not
unlikely that the end of the week is reached with .1 appearing.

And so what ? The .0 release is a stable release like any other one.
It doesn't deserve to be deployed more than any other specific stable
release. It serves as a reference. Before .0 the code experiences some
possibly breaking changes, even some reverts. After .0 it experiences
only small fixes according to the stable rules.

Overall I think the current model is not that bad, and that what is the
most needed is some education regarding how -stable works to encourage
developers to rush their fixes less (after more tests), and to ensure
that those who generally push good quality fixes can submit them at any
moment in the cycle so that we get them as fast as possible in -stable.

Willy

Re: [PATCH v4 1/2] clk: x86: Add ST oscout platform clock

[Agrawal, Akshu]

On 5/8/2018 9:08 PM, Deucher, Alexander wrote:
>> -Original Message-
>> From: Agrawal, Akshu
>> Sent: Tuesday, May 8, 2018 12:04 AM
>> To: Deucher, Alexander 
>> Cc: djku...@chromium.org; mturque...@baylibre.com; sb...@kernel.org;
>> Koenig, Christian ; airl...@redhat.com; Liu,
>> Shaoyun ; linux-kernel@vger.kernel.org; linux-
>> c...@vger.kernel.org; r...@rjwysocki.net; l...@kernel.org; linux-
>> a...@vger.kernel.org
>> Subject: Re: [PATCH v4 1/2] clk: x86: Add ST oscout platform clock
>>
>>
>>
>> On 5/8/2018 3:14 AM, Deucher, Alexander wrote:
 -Original Message-
 From: Agrawal, Akshu
 Sent: Monday, May 7, 2018 6:14 AM
 Cc: djku...@chromium.org; Agrawal, Akshu ;
 Deucher, Alexander ;
 mturque...@baylibre.com; sb...@kernel.org; Koenig, Christian
 ; airl...@redhat.com; Liu, Shaoyun
 ; linux-kernel@vger.kernel.org; linux-
 c...@vger.kernel.org; r...@rjwysocki.net; l...@kernel.org; linux-
 a...@vger.kernel.org
 Subject: [PATCH v4 1/2] clk: x86: Add ST oscout platform clock

 Stoney SoC provides oscout clock. This clock can support 25Mhz and
 48Mhz of frequency.
 The clock is available for general system use.

 Signed-off-by: Akshu Agrawal 
 ---
 v2: config change, added SPDX tag and used clk_hw_register_.
 v3: Fix kbuild warning for checking of NULL pointer
 v4: unregister clk_hw in driver remove, add .suppress_bind_attrs
  drivers/clk/x86/Makefile |  3 +-
  drivers/clk/x86/clk-st.c | 85
 
  include/linux/platform_data/clk-st.h | 17 
  3 files changed, 104 insertions(+), 1 deletion(-)  create mode
 100644 drivers/clk/x86/clk-st.c  create mode 100644
 include/linux/platform_data/clk-st.h

 diff --git a/drivers/clk/x86/Makefile b/drivers/clk/x86/Makefile
 index 1367afb..00303bc 100644
 --- a/drivers/clk/x86/Makefile
 +++ b/drivers/clk/x86/Makefile
 @@ -1,3 +1,4 @@
 +obj-$(CONFIG_PMC_ATOM)+= clk-pmc-atom.o
 +obj-$(CONFIG_X86_AMD_PLATFORM_DEVICE) += clk-st.o
  clk-x86-lpss-objs := clk-lpt.o
  obj-$(CONFIG_X86_INTEL_LPSS)  += clk-x86-lpss.o
 -obj-$(CONFIG_PMC_ATOM)+= clk-pmc-atom.o
 diff --git a/drivers/clk/x86/clk-st.c b/drivers/clk/x86/clk-st.c new
 file mode
 100644 index 000..8a7795c
 --- /dev/null
 +++ b/drivers/clk/x86/clk-st.c
 @@ -0,0 +1,85 @@
 +// SPDX-License-Identifier: GPL-2.0
>>>
>>> Should this be MIT?  The original license was MIT.
>>>
>>> Alex
>>>
>>
>> We are adding SPDX tag, while license remains same GPL-2.0
>>
>> What I have read is this is "to provide license identifiers inside the source
>> code that could be easily parsed by machines and would allow checking for
>> license compliance of an open source project easier."
> 
> My point as just that the original license on the file that you first sent 
> out was MIT so the SPDX tag should be MIT rather than GPL.  E.g.,
> SPDX-License-Identifier: MIT
> 
Oh right it should be MIT, will change it.

Thanks,
Akshu

Re: [Ksummit-discuss] bug-introducing patches

[Willy Tarreau]

On Tue, May 08, 2018 at 08:29:14PM +, Sasha Levin wrote:
> What if, instead, Linus doesn't actually ever release a point release?
> We can make the merge window open more often, and since there's no
> actual release, people won't rush to push fixes in later -rc cycles.

And then what's the purpose of these later -rc cycles if you remove one
release ? You're just removing one step and shifting everything down by
one -rc but the issues are the same.

> We take away the incentive to push poorly tested code. Maintainers still
> free to commit anything they'd like, but there's no reason to commit
> code they're not confident of just to make it to a random release no one
> will use.
> 
> Merge window will happen more often, so there's no real reason to rush
> things in a particular window, and since -stable releases every week
> there's no rush to push a fix in since the next release is just a week
> away.

I'm not sure what model you're having in mind but the description above
reminds me of 2.5 which was constantly had something broken and which
used to be unusable for many developers. Many of us even bought some
SCSI cards and disks by then because for a long time IDE was broken.

The primary purpose of Linus' releases and -rc is to synchronise everyone
on the same goal at the same time. The merge window is "send me your crap,
it must be OK but we know problems happen and you'll be allowed to fix it
later". The -rc ones are there so that everyone fixes their crap in
parallel so that we converge towards something acceptable for everyone.

Your argument that the .0 release is useless is wrong in my opinion. It
is as wrong as saying "statistics show that less people use .3 than .7".
And comparing "stable kernels" to ".0" is wrong because there are roughly
10 times more stable kernels than releases so statistically you'll find
10 times more of them in field. The reality is that deploying .0 always
takes a bit more time for end users so statistically it should be a bit
less common in field :
  - you're never certain when the new version is going to be released
(will rc8/rc9 exist?)
  - when it's released, you have to update your config and it takes
some time.
  - by the time you find a quiet moment to do all this, it's not
unlikely that the end of the week is reached with .1 appearing.

And so what ? The .0 release is a stable release like any other one.
It doesn't deserve to be deployed more than any other specific stable
release. It serves as a reference. Before .0 the code experiences some
possibly breaking changes, even some reverts. After .0 it experiences
only small fixes according to the stable rules.

Overall I think the current model is not that bad, and that what is the
most needed is some education regarding how -stable works to encourage
developers to rush their fixes less (after more tests), and to ensure
that those who generally push good quality fixes can submit them at any
moment in the cycle so that we get them as fast as possible in -stable.

Willy

Re: KASAN: out-of-bounds Read in ip6_xmit

[Eric Biggers]

On Sun, Jan 28, 2018 at 11:24:01AM -0800, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on net-next commit
> 6bb46bc57c8e9ce947cc605e555b7204b44d2b10 (Fri Jan 26 16:00:23 2018 +)
> Merge branch 'cxgb4-fix-dump-collection-when-firmware-crashed'
> 
> Unfortunately, I don't have any reproducer for this crash yet.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+c8e66da874feb11aa...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> ==
> BUG: KASAN: out-of-bounds in ip6_dst_idev include/net/ip6_fib.h:192 [inline]
> BUG: KASAN: out-of-bounds in ip6_xmit+0x1f76/0x2260
> net/ipv6/ip6_output.c:264
> Read of size 8 at addr 8801bcc8cc18 by task syz-executor2/11459
> 
> CPU: 0 PID: 11459 Comm: syz-executor2 Not tainted 4.15.0-rc9+ #212
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430
>  ip6_dst_idev include/net/ip6_fib.h:192 [inline]
>  ip6_xmit+0x1f76/0x2260 net/ipv6/ip6_output.c:264
>  inet6_csk_xmit+0x2fc/0x580 net/ipv6/inet6_connection_sock.c:139
>  l2tp_xmit_core net/l2tp/l2tp_core.c:1096 [inline]
>  l2tp_xmit_skb+0x105f/0x1410 net/l2tp/l2tp_core.c:1191
>  pppol2tp_sendmsg+0x470/0x670 net/l2tp/l2tp_ppp.c:341
>  sock_sendmsg_nosec net/socket.c:630 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:640
>  ___sys_sendmsg+0x767/0x8b0 net/socket.c:2046
>  __sys_sendmsg+0xe5/0x210 net/socket.c:2080
>  SYSC_sendmsg net/socket.c:2091 [inline]
>  SyS_sendmsg+0x2d/0x50 net/socket.c:2087
>  entry_SYSCALL_64_fastpath+0x29/0xa0
> RIP: 0033:0x453299
> RSP: 002b:7fcfef194c58 EFLAGS: 0212 ORIG_RAX: 002e
> RAX: ffda RBX: 0071bf58 RCX: 00453299
> RDX: 0081 RSI: 2037ffc8 RDI: 0014
> RBP: 036f R08:  R09: 
> R10:  R11: 0212 R12: 006f4308
> R13:  R14: 7fcfef1956d4 R15: 000b
> 
> Allocated by task 11466:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
>  kmem_cache_alloc+0x12e/0x760 mm/slab.c:3544
>  dst_alloc+0x11f/0x1a0 net/core/dst.c:104
>  rt_dst_alloc+0xe9/0x520 net/ipv4/route.c:1497
>  ip_route_input_slow net/ipv4/route.c:2006 [inline]
>  ip_route_input_rcu+0x1076/0x3200 net/ipv4/route.c:2137
>  ip_route_input_noref+0xf5/0x1e0 net/ipv4/route.c:2083
>  ip_rcv_finish+0x3a6/0x2040 net/ipv4/ip_input.c:348
>  NF_HOOK include/linux/netfilter.h:288 [inline]
>  ip_rcv+0xc5a/0x1840 net/ipv4/ip_input.c:493
>  __netif_receive_skb_core+0x1a41/0x3460 net/core/dev.c:4547
>  __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4612
>  netif_receive_skb_internal+0x10b/0x670 net/core/dev.c:4686
>  netif_receive_skb+0xae/0x390 net/core/dev.c:4710
>  tun_rx_batched.isra.53+0x5ee/0x870 drivers/net/tun.c:1558
>  tun_get_user+0x25de/0x3940 drivers/net/tun.c:1958
>  tun_chr_write_iter+0xb9/0x160 drivers/net/tun.c:1986
>  call_write_iter include/linux/fs.h:1772 [inline]
>  do_iter_readv_writev+0x525/0x7f0 fs/read_write.c:653
>  do_iter_write+0x154/0x540 fs/read_write.c:932
>  vfs_writev+0x18a/0x340 fs/read_write.c:977
>  do_writev+0xfc/0x2a0 fs/read_write.c:1012
>  SYSC_writev fs/read_write.c:1085 [inline]
>  SyS_writev+0x27/0x30 fs/read_write.c:1082
>  entry_SYSCALL_64_fastpath+0x29/0xa0
> 
> Freed by task 7176:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
>  __cache_free mm/slab.c:3488 [inline]
>  kmem_cache_free+0x83/0x2a0 mm/slab.c:3746
>  dst_destroy+0x257/0x370 net/core/dst.c:140
>  dst_destroy_rcu+0x16/0x20 net/core/dst.c:153
>  __rcu_reclaim kernel/rcu/rcu.h:195 [inline]
>  rcu_do_batch kernel/rcu/tree.c:2758 [inline]
>  invoke_rcu_callbacks kernel/rcu/tree.c:3012 [inline]
>  __rcu_process_callbacks kernel/rcu/tree.c:2979 [inline]
>  rcu_process_callbacks+0xd6c/0x17f0 kernel/rcu/tree.c:2996
>  __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
> 
> The buggy address belongs to the object at 8801bcc8cc00
>  which belongs to the cache ip_dst_cache of size 168
> The buggy address is located 24 bytes inside of
>  168-byte region [8801bcc8cc00, 8801bcc8cca8)
> The buggy address belongs to the page:
> 

Re: KASAN: out-of-bounds Read in ip6_xmit

[Eric Biggers]

On Sun, Jan 28, 2018 at 11:24:01AM -0800, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on net-next commit
> 6bb46bc57c8e9ce947cc605e555b7204b44d2b10 (Fri Jan 26 16:00:23 2018 +)
> Merge branch 'cxgb4-fix-dump-collection-when-firmware-crashed'
> 
> Unfortunately, I don't have any reproducer for this crash yet.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+c8e66da874feb11aa...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> ==
> BUG: KASAN: out-of-bounds in ip6_dst_idev include/net/ip6_fib.h:192 [inline]
> BUG: KASAN: out-of-bounds in ip6_xmit+0x1f76/0x2260
> net/ipv6/ip6_output.c:264
> Read of size 8 at addr 8801bcc8cc18 by task syz-executor2/11459
> 
> CPU: 0 PID: 11459 Comm: syz-executor2 Not tainted 4.15.0-rc9+ #212
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430
>  ip6_dst_idev include/net/ip6_fib.h:192 [inline]
>  ip6_xmit+0x1f76/0x2260 net/ipv6/ip6_output.c:264
>  inet6_csk_xmit+0x2fc/0x580 net/ipv6/inet6_connection_sock.c:139
>  l2tp_xmit_core net/l2tp/l2tp_core.c:1096 [inline]
>  l2tp_xmit_skb+0x105f/0x1410 net/l2tp/l2tp_core.c:1191
>  pppol2tp_sendmsg+0x470/0x670 net/l2tp/l2tp_ppp.c:341
>  sock_sendmsg_nosec net/socket.c:630 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:640
>  ___sys_sendmsg+0x767/0x8b0 net/socket.c:2046
>  __sys_sendmsg+0xe5/0x210 net/socket.c:2080
>  SYSC_sendmsg net/socket.c:2091 [inline]
>  SyS_sendmsg+0x2d/0x50 net/socket.c:2087
>  entry_SYSCALL_64_fastpath+0x29/0xa0
> RIP: 0033:0x453299
> RSP: 002b:7fcfef194c58 EFLAGS: 0212 ORIG_RAX: 002e
> RAX: ffda RBX: 0071bf58 RCX: 00453299
> RDX: 0081 RSI: 2037ffc8 RDI: 0014
> RBP: 036f R08:  R09: 
> R10:  R11: 0212 R12: 006f4308
> R13:  R14: 7fcfef1956d4 R15: 000b
> 
> Allocated by task 11466:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
>  kmem_cache_alloc+0x12e/0x760 mm/slab.c:3544
>  dst_alloc+0x11f/0x1a0 net/core/dst.c:104
>  rt_dst_alloc+0xe9/0x520 net/ipv4/route.c:1497
>  ip_route_input_slow net/ipv4/route.c:2006 [inline]
>  ip_route_input_rcu+0x1076/0x3200 net/ipv4/route.c:2137
>  ip_route_input_noref+0xf5/0x1e0 net/ipv4/route.c:2083
>  ip_rcv_finish+0x3a6/0x2040 net/ipv4/ip_input.c:348
>  NF_HOOK include/linux/netfilter.h:288 [inline]
>  ip_rcv+0xc5a/0x1840 net/ipv4/ip_input.c:493
>  __netif_receive_skb_core+0x1a41/0x3460 net/core/dev.c:4547
>  __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4612
>  netif_receive_skb_internal+0x10b/0x670 net/core/dev.c:4686
>  netif_receive_skb+0xae/0x390 net/core/dev.c:4710
>  tun_rx_batched.isra.53+0x5ee/0x870 drivers/net/tun.c:1558
>  tun_get_user+0x25de/0x3940 drivers/net/tun.c:1958
>  tun_chr_write_iter+0xb9/0x160 drivers/net/tun.c:1986
>  call_write_iter include/linux/fs.h:1772 [inline]
>  do_iter_readv_writev+0x525/0x7f0 fs/read_write.c:653
>  do_iter_write+0x154/0x540 fs/read_write.c:932
>  vfs_writev+0x18a/0x340 fs/read_write.c:977
>  do_writev+0xfc/0x2a0 fs/read_write.c:1012
>  SYSC_writev fs/read_write.c:1085 [inline]
>  SyS_writev+0x27/0x30 fs/read_write.c:1082
>  entry_SYSCALL_64_fastpath+0x29/0xa0
> 
> Freed by task 7176:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
>  __cache_free mm/slab.c:3488 [inline]
>  kmem_cache_free+0x83/0x2a0 mm/slab.c:3746
>  dst_destroy+0x257/0x370 net/core/dst.c:140
>  dst_destroy_rcu+0x16/0x20 net/core/dst.c:153
>  __rcu_reclaim kernel/rcu/rcu.h:195 [inline]
>  rcu_do_batch kernel/rcu/tree.c:2758 [inline]
>  invoke_rcu_callbacks kernel/rcu/tree.c:3012 [inline]
>  __rcu_process_callbacks kernel/rcu/tree.c:2979 [inline]
>  rcu_process_callbacks+0xd6c/0x17f0 kernel/rcu/tree.c:2996
>  __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
> 
> The buggy address belongs to the object at 8801bcc8cc00
>  which belongs to the cache ip_dst_cache of size 168
> The buggy address is located 24 bytes inside of
>  168-byte region [8801bcc8cc00, 8801bcc8cca8)
> The buggy address belongs to the page:
> 

Re: KASAN: use-after-free Read in ip6_xmit

[Eric Biggers]

On Thu, Jan 04, 2018 at 02:58:01AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 0e08c463db387a2adcb0243b15ab868a73f87807
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+56029fd3642567f39...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> audit: type=1400 audit(1514737122.010:7): avc:  denied  { map } for
> pid=3153 comm="syzkaller920384" path="/root/syzkaller920384627" dev="sda1"
> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> ==
> BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:189
> [inline]
> BUG: KASAN: use-after-free in ip6_xmit+0x1f92/0x1fc0
> net/ipv6/ip6_output.c:248
> Read of size 8 at addr 8801ca6f9f18 by task syzkaller920384/3153
> 
> CPU: 1 PID: 3153 Comm: syzkaller920384 Not tainted 4.15.0-rc4-next-20171221+
> #78
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430
>  ip6_dst_idev include/net/ip6_fib.h:189 [inline]
>  ip6_xmit+0x1f92/0x1fc0 net/ipv6/ip6_output.c:248
>  inet6_csk_xmit+0x2fc/0x580 net/ipv6/inet6_connection_sock.c:139
>  tcp_transmit_skb+0x1b12/0x38b0 net/ipv4/tcp_output.c:1176
>  tcp_send_syn_data net/ipv4/tcp_output.c:3456 [inline]
>  tcp_connect+0x1ed5/0x4090 net/ipv4/tcp_output.c:3495
>  tcp_v4_connect+0x15ef/0x1e70 net/ipv4/tcp_ipv4.c:257
>  __inet_stream_connect+0x2d4/0xf00 net/ipv4/af_inet.c:620
>  tcp_sendmsg_fastopen net/ipv4/tcp.c:1167 [inline]
>  tcp_sendmsg_locked+0x27e4/0x3b30 net/ipv4/tcp.c:1212
>  tcp_sendmsg+0x2f/0x50 net/ipv4/tcp.c:1459
>  inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:764
>  sock_sendmsg_nosec net/socket.c:628 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:638
>  SYSC_sendto+0x361/0x5c0 net/socket.c:1719
>  SyS_sendto+0x40/0x50 net/socket.c:1687
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x43fda9
> RSP: 002b:7ffc9b8bd818 EFLAGS: 0217 ORIG_RAX: 002c
> RAX: ffda RBX:  RCX: 0043fda9
> RDX:  RSI: 20aa1000 RDI: 0003
> RBP: 006ca018 R08: 20aa1000 R09: 0010
> R10: 23ff R11: 0217 R12: 00401710
> R13: 004017a0 R14:  R15: 
> 
> Allocated by task 3140:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
>  kmem_cache_alloc+0x12e/0x760 mm/slab.c:3545
>  dst_alloc+0x11f/0x1a0 net/core/dst.c:104
>  rt_dst_alloc+0xe9/0x520 net/ipv4/route.c:1500
>  __mkroute_output net/ipv4/route.c:2242 [inline]
>  ip_route_output_key_hash_rcu+0xa40/0x2c10 net/ipv4/route.c:2470
>  ip_route_output_key_hash+0x20b/0x370 net/ipv4/route.c:2299
>  __ip_route_output_key include/net/route.h:125 [inline]
>  ip_route_connect include/net/route.h:300 [inline]
>  __ip4_datagram_connect+0xa67/0x1240 net/ipv4/datagram.c:51
>  __ip6_datagram_connect+0x709/0xf90 net/ipv6/datagram.c:157
>  ip6_datagram_connect+0x2f/0x50 net/ipv6/datagram.c:274
>  inet_dgram_connect+0x16b/0x1f0 net/ipv4/af_inet.c:542
>  SYSC_connect+0x213/0x4a0 net/socket.c:1611
>  SyS_connect+0x24/0x30 net/socket.c:1592
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> 
> Freed by task 0:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
>  __cache_free mm/slab.c:3489 [inline]
>  kmem_cache_free+0x83/0x2a0 mm/slab.c:3747
>  dst_destroy+0x219/0x310 net/core/dst.c:140
>  dst_destroy_rcu+0x16/0x20 net/core/dst.c:153
>  __rcu_reclaim kernel/rcu/rcu.h:172 [inline]
>  rcu_do_batch kernel/rcu/tree.c:2675 [inline]
>  invoke_rcu_callbacks kernel/rcu/tree.c:2934 [inline]
>  __rcu_process_callbacks kernel/rcu/tree.c:2901 [inline]
>  rcu_process_callbacks+0xd6c/0x17f0 kernel/rcu/tree.c:2918
>  __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
> 
> The buggy address belongs to the object at 8801ca6f9f00
>  which belongs to the cache ip_dst_cache of size 168
> The buggy address is 

Re: KASAN: use-after-free Read in ip6_xmit

[Eric Biggers]

On Thu, Jan 04, 2018 at 02:58:01AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 0e08c463db387a2adcb0243b15ab868a73f87807
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+56029fd3642567f39...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> audit: type=1400 audit(1514737122.010:7): avc:  denied  { map } for
> pid=3153 comm="syzkaller920384" path="/root/syzkaller920384627" dev="sda1"
> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> ==
> BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:189
> [inline]
> BUG: KASAN: use-after-free in ip6_xmit+0x1f92/0x1fc0
> net/ipv6/ip6_output.c:248
> Read of size 8 at addr 8801ca6f9f18 by task syzkaller920384/3153
> 
> CPU: 1 PID: 3153 Comm: syzkaller920384 Not tainted 4.15.0-rc4-next-20171221+
> #78
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430
>  ip6_dst_idev include/net/ip6_fib.h:189 [inline]
>  ip6_xmit+0x1f92/0x1fc0 net/ipv6/ip6_output.c:248
>  inet6_csk_xmit+0x2fc/0x580 net/ipv6/inet6_connection_sock.c:139
>  tcp_transmit_skb+0x1b12/0x38b0 net/ipv4/tcp_output.c:1176
>  tcp_send_syn_data net/ipv4/tcp_output.c:3456 [inline]
>  tcp_connect+0x1ed5/0x4090 net/ipv4/tcp_output.c:3495
>  tcp_v4_connect+0x15ef/0x1e70 net/ipv4/tcp_ipv4.c:257
>  __inet_stream_connect+0x2d4/0xf00 net/ipv4/af_inet.c:620
>  tcp_sendmsg_fastopen net/ipv4/tcp.c:1167 [inline]
>  tcp_sendmsg_locked+0x27e4/0x3b30 net/ipv4/tcp.c:1212
>  tcp_sendmsg+0x2f/0x50 net/ipv4/tcp.c:1459
>  inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:764
>  sock_sendmsg_nosec net/socket.c:628 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:638
>  SYSC_sendto+0x361/0x5c0 net/socket.c:1719
>  SyS_sendto+0x40/0x50 net/socket.c:1687
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x43fda9
> RSP: 002b:7ffc9b8bd818 EFLAGS: 0217 ORIG_RAX: 002c
> RAX: ffda RBX:  RCX: 0043fda9
> RDX:  RSI: 20aa1000 RDI: 0003
> RBP: 006ca018 R08: 20aa1000 R09: 0010
> R10: 23ff R11: 0217 R12: 00401710
> R13: 004017a0 R14:  R15: 
> 
> Allocated by task 3140:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
>  kmem_cache_alloc+0x12e/0x760 mm/slab.c:3545
>  dst_alloc+0x11f/0x1a0 net/core/dst.c:104
>  rt_dst_alloc+0xe9/0x520 net/ipv4/route.c:1500
>  __mkroute_output net/ipv4/route.c:2242 [inline]
>  ip_route_output_key_hash_rcu+0xa40/0x2c10 net/ipv4/route.c:2470
>  ip_route_output_key_hash+0x20b/0x370 net/ipv4/route.c:2299
>  __ip_route_output_key include/net/route.h:125 [inline]
>  ip_route_connect include/net/route.h:300 [inline]
>  __ip4_datagram_connect+0xa67/0x1240 net/ipv4/datagram.c:51
>  __ip6_datagram_connect+0x709/0xf90 net/ipv6/datagram.c:157
>  ip6_datagram_connect+0x2f/0x50 net/ipv6/datagram.c:274
>  inet_dgram_connect+0x16b/0x1f0 net/ipv4/af_inet.c:542
>  SYSC_connect+0x213/0x4a0 net/socket.c:1611
>  SyS_connect+0x24/0x30 net/socket.c:1592
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> 
> Freed by task 0:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
>  __cache_free mm/slab.c:3489 [inline]
>  kmem_cache_free+0x83/0x2a0 mm/slab.c:3747
>  dst_destroy+0x219/0x310 net/core/dst.c:140
>  dst_destroy_rcu+0x16/0x20 net/core/dst.c:153
>  __rcu_reclaim kernel/rcu/rcu.h:172 [inline]
>  rcu_do_batch kernel/rcu/tree.c:2675 [inline]
>  invoke_rcu_callbacks kernel/rcu/tree.c:2934 [inline]
>  __rcu_process_callbacks kernel/rcu/tree.c:2901 [inline]
>  rcu_process_callbacks+0xd6c/0x17f0 kernel/rcu/tree.c:2918
>  __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
> 
> The buggy address belongs to the object at 8801ca6f9f00
>  which belongs to the cache ip_dst_cache of size 168
> The buggy address is 

Re: [PATCH V4] clk: at91: PLL recalc_rate() now using cached MUL and DIV values

[Marcin Ziemianowicz]

On Mon, Apr 30, 2018 at 07:58:47AM +0200, Boris Brezillon wrote:
> On Sun, 29 Apr 2018 15:01:11 -0400
> Marcin Ziemianowicz  wrote:
> 
> > When a USB device is connected to the USB host port on the SAM9N12 then
> > you get "-62" error which seems to indicate USB replies from the device
> > are timing out. Based on a logic sniffer, I saw the USB bus was running
> > at half speed.
> > 
> > The PLL code uses cached MUL and DIV values which get set in set_rate()
> > and applied in prepare(), but the recalc_rate() function instead
> > queries the hardware instead of using these cached values. Therefore,
> > if recalc_rate() is called between a set_rate() and prepare(), the
> > wrong frequency is calculated and later the USB clock divider for the
> > SAM9N12 SOC will be configured for an incorrect clock.
> > 
> > In my case, the PLL hardware was set to 96 Mhz before the OHCI
> > driver loads, and therefore the usb clock divider was being set
> > to /2 even though the OHCI driver set the PLL to 48 Mhz.
> > 
> > As an alternative explanation, I noticed this was fixed in the past by
> > 87e2ed338f1b ("clk: at91: fix recalc_rate implementation of PLL
> > driver") but the bug was later re-introduced by 1bdf02326b71 ("clk:
> > at91: make use of syscon/regmap internally").
> > 
> > Fixes: 1bdf02326b71 ("clk: at91: make use of syscon/regmap internally)
> > Cc: 
> > Signed-off-by: Marcin Ziemianowicz 
> 
> Acked-by: Boris Brezillon 

Apologies for being a bother, but since it's been a bit over a week,
should I do something with this now that it has been ACK'd? I was thinking
I would see it somewhere on the git group repo but am not seeing it there
yet. Googling says that there is a "review cycle" for some maintainers, but
I am not clear on if I need to initiate it manually or anything of the sort.

https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/ 

> 
> > ---
> > Thank you for bearing with me about this Boris.
> > 
> > Changes since V3:
> >   Fix for double returns found by kbluild test robot
> >   > Comments by Boris Brezillon about email formatting issues  
> > Changes since V2:
> >   Removed all logging/debug messages I added
> >   > Comment by Boris Brezillon about my fix being wrong addressed  
> > Changes since V1:
> >   Added patch set cover letter
> >   Shortened lines which were over >80 characters long
> >   > Comment by Greg Kroah-Hartman about "from" field in email addressed
> >   > Comment by Alan Stern about redundant debug lines addressed  
> > 
> >  drivers/clk/at91/clk-pll.c | 13 +
> >  1 file changed, 1 insertion(+), 12 deletions(-)
> > 
> > diff --git a/drivers/clk/at91/clk-pll.c b/drivers/clk/at91/clk-pll.c
> > index 7d3223fc..72b6091e 100644
> > --- a/drivers/clk/at91/clk-pll.c
> > +++ b/drivers/clk/at91/clk-pll.c
> > @@ -132,19 +132,8 @@ static unsigned long clk_pll_recalc_rate(struct clk_hw 
> > *hw,
> >  unsigned long parent_rate)
> >  {
> > struct clk_pll *pll = to_clk_pll(hw);
> > -   unsigned int pllr;
> > -   u16 mul;
> > -   u8 div;
> > -
> > -   regmap_read(pll->regmap, PLL_REG(pll->id), );
> > -
> > -   div = PLL_DIV(pllr);
> > -   mul = PLL_MUL(pllr, pll->layout);
> > -
> > -   if (!div || !mul)
> > -   return 0;
> >  
> > -   return (parent_rate / div) * (mul + 1);
> > +   return (parent_rate / pll->div) * (pll->mul + 1);
> >  }
> >  
> >  static long clk_pll_get_best_div_mul(struct clk_pll *pll, unsigned long 
> > rate,
> 

Re: [PATCH V4] clk: at91: PLL recalc_rate() now using cached MUL and DIV values

[Marcin Ziemianowicz]

On Mon, Apr 30, 2018 at 07:58:47AM +0200, Boris Brezillon wrote:
> On Sun, 29 Apr 2018 15:01:11 -0400
> Marcin Ziemianowicz  wrote:
> 
> > When a USB device is connected to the USB host port on the SAM9N12 then
> > you get "-62" error which seems to indicate USB replies from the device
> > are timing out. Based on a logic sniffer, I saw the USB bus was running
> > at half speed.
> > 
> > The PLL code uses cached MUL and DIV values which get set in set_rate()
> > and applied in prepare(), but the recalc_rate() function instead
> > queries the hardware instead of using these cached values. Therefore,
> > if recalc_rate() is called between a set_rate() and prepare(), the
> > wrong frequency is calculated and later the USB clock divider for the
> > SAM9N12 SOC will be configured for an incorrect clock.
> > 
> > In my case, the PLL hardware was set to 96 Mhz before the OHCI
> > driver loads, and therefore the usb clock divider was being set
> > to /2 even though the OHCI driver set the PLL to 48 Mhz.
> > 
> > As an alternative explanation, I noticed this was fixed in the past by
> > 87e2ed338f1b ("clk: at91: fix recalc_rate implementation of PLL
> > driver") but the bug was later re-introduced by 1bdf02326b71 ("clk:
> > at91: make use of syscon/regmap internally").
> > 
> > Fixes: 1bdf02326b71 ("clk: at91: make use of syscon/regmap internally)
> > Cc: 
> > Signed-off-by: Marcin Ziemianowicz 
> 
> Acked-by: Boris Brezillon 

Apologies for being a bother, but since it's been a bit over a week,
should I do something with this now that it has been ACK'd? I was thinking
I would see it somewhere on the git group repo but am not seeing it there
yet. Googling says that there is a "review cycle" for some maintainers, but
I am not clear on if I need to initiate it manually or anything of the sort.

https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/ 

> 
> > ---
> > Thank you for bearing with me about this Boris.
> > 
> > Changes since V3:
> >   Fix for double returns found by kbluild test robot
> >   > Comments by Boris Brezillon about email formatting issues  
> > Changes since V2:
> >   Removed all logging/debug messages I added
> >   > Comment by Boris Brezillon about my fix being wrong addressed  
> > Changes since V1:
> >   Added patch set cover letter
> >   Shortened lines which were over >80 characters long
> >   > Comment by Greg Kroah-Hartman about "from" field in email addressed
> >   > Comment by Alan Stern about redundant debug lines addressed  
> > 
> >  drivers/clk/at91/clk-pll.c | 13 +
> >  1 file changed, 1 insertion(+), 12 deletions(-)
> > 
> > diff --git a/drivers/clk/at91/clk-pll.c b/drivers/clk/at91/clk-pll.c
> > index 7d3223fc..72b6091e 100644
> > --- a/drivers/clk/at91/clk-pll.c
> > +++ b/drivers/clk/at91/clk-pll.c
> > @@ -132,19 +132,8 @@ static unsigned long clk_pll_recalc_rate(struct clk_hw 
> > *hw,
> >  unsigned long parent_rate)
> >  {
> > struct clk_pll *pll = to_clk_pll(hw);
> > -   unsigned int pllr;
> > -   u16 mul;
> > -   u8 div;
> > -
> > -   regmap_read(pll->regmap, PLL_REG(pll->id), );
> > -
> > -   div = PLL_DIV(pllr);
> > -   mul = PLL_MUL(pllr, pll->layout);
> > -
> > -   if (!div || !mul)
> > -   return 0;
> >  
> > -   return (parent_rate / div) * (mul + 1);
> > +   return (parent_rate / pll->div) * (pll->mul + 1);
> >  }
> >  
> >  static long clk_pll_get_best_div_mul(struct clk_pll *pll, unsigned long 
> > rate,
> 

Re: [PATCH v7 12/24] ASoC: qdsp6: q6afe: Add support to MI2S sysclks

[Banajit Goswami]

On 5/1/2018 5:08 AM, Srinivas Kandagatla wrote:

This patch adds support to LPASS Bit clock, LPASS Digital
core clock and OSR clock. These clocks are required for both
MI2S and PCM setup.

Signed-off-by: Srinivas Kandagatla 
Reviewed-and-tested-by: Rohit kumar 
---
  sound/soc/qcom/qdsp6/q6afe.c | 171 +--
  sound/soc/qcom/qdsp6/q6afe.h | 131 +
  2 files changed, 295 insertions(+), 7 deletions(-)



Acked-by: Banajit Goswami 

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

Re: [PATCH v7 12/24] ASoC: qdsp6: q6afe: Add support to MI2S sysclks

[Banajit Goswami]

On 5/1/2018 5:08 AM, Srinivas Kandagatla wrote:

This patch adds support to LPASS Bit clock, LPASS Digital
core clock and OSR clock. These clocks are required for both
MI2S and PCM setup.

Signed-off-by: Srinivas Kandagatla 
Reviewed-and-tested-by: Rohit kumar 
---
  sound/soc/qcom/qdsp6/q6afe.c | 171 +--
  sound/soc/qcom/qdsp6/q6afe.h | 131 +
  2 files changed, 295 insertions(+), 7 deletions(-)



Acked-by: Banajit Goswami 

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

[PATCH] ASoC: AMD: Change codec to channel link as per hardware redesign

[Akshu Agrawal]

This is a correction to match acutal hardware configuration.
The hardware configuration looks like:
I2S_BT -> SPK(Max) + DMIC(Adau)
I2S_SP -> DA7219 Headset

No actual products have been shipped with previous configuration.

Signed-off-by: Akshu Agrawal 
---
This patch is dependent on [V4,10/10] ASoC: amd: dma driver changes for bt i2s 
instance
https://patchwork.kernel.org/patch/10385381/

 sound/soc/amd/acp-da7219-max98357a.c | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/sound/soc/amd/acp-da7219-max98357a.c 
b/sound/soc/amd/acp-da7219-max98357a.c
index ccddc66..566bd26 100644
--- a/sound/soc/amd/acp-da7219-max98357a.c
+++ b/sound/soc/amd/acp-da7219-max98357a.c
@@ -148,7 +148,7 @@ static int cz_da7219_startup(struct snd_pcm_substream 
*substream)
snd_pcm_hw_constraint_list(runtime, 0, SNDRV_PCM_HW_PARAM_RATE,
   _rates);
 
-   machine->i2s_instance = I2S_BT_INSTANCE;
+   machine->i2s_instance = I2S_SP_INSTANCE;
return da7219_clk_enable(substream);
 }
 
@@ -163,7 +163,7 @@ static int cz_max_startup(struct snd_pcm_substream 
*substream)
struct snd_soc_card *card = rtd->card;
struct acp_platform_info *machine = snd_soc_card_get_drvdata(card);
 
-   machine->i2s_instance = I2S_SP_INSTANCE;
+   machine->i2s_instance = I2S_BT_INSTANCE;
return da7219_clk_enable(substream);
 }
 
@@ -178,7 +178,7 @@ static int cz_dmic_startup(struct snd_pcm_substream 
*substream)
struct snd_soc_card *card = rtd->card;
struct acp_platform_info *machine = snd_soc_card_get_drvdata(card);
 
-   machine->i2s_instance = I2S_SP_INSTANCE;
+   machine->i2s_instance = I2S_BT_INSTANCE;
return da7219_clk_enable(substream);
 }
 
@@ -204,16 +204,27 @@ static void cz_dmic_shutdown(struct snd_pcm_substream 
*substream)
 
 static struct snd_soc_dai_link cz_dai_7219_98357[] = {
{
-   .name = "amd-da7219-play-cap",
-   .stream_name = "Playback and Capture",
+   .name = "amd-da7219-play",
+   .stream_name = "Playback",
.platform_name = "acp_audio_dma.0.auto",
-   .cpu_dai_name = "designware-i2s.3.auto",
+   .cpu_dai_name = "designware-i2s.1.auto",
.codec_dai_name = "da7219-hifi",
.codec_name = "i2c-DLGS7219:00",
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
| SND_SOC_DAIFMT_CBM_CFM,
.init = cz_da7219_init,
.dpcm_playback = 1,
+   .ops = _da7219_cap_ops,
+   },
+   {
+   .name = "amd-da7219-cap",
+   .stream_name = "Capture",
+   .platform_name = "acp_audio_dma.0.auto",
+   .cpu_dai_name = "designware-i2s.2.auto",
+   .codec_dai_name = "da7219-hifi",
+   .codec_name = "i2c-DLGS7219:00",
+   .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
+   | SND_SOC_DAIFMT_CBM_CFM,
.dpcm_capture = 1,
.ops = _da7219_cap_ops,
},
@@ -221,7 +232,7 @@ static void cz_dmic_shutdown(struct snd_pcm_substream 
*substream)
.name = "amd-max98357-play",
.stream_name = "HiFi Playback",
.platform_name = "acp_audio_dma.0.auto",
-   .cpu_dai_name = "designware-i2s.1.auto",
+   .cpu_dai_name = "designware-i2s.3.auto",
.codec_dai_name = "HiFi",
.codec_name = "MX98357A:00",
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
@@ -233,7 +244,7 @@ static void cz_dmic_shutdown(struct snd_pcm_substream 
*substream)
.name = "dmic",
.stream_name = "DMIC Capture",
.platform_name = "acp_audio_dma.0.auto",
-   .cpu_dai_name = "designware-i2s.2.auto",
+   .cpu_dai_name = "designware-i2s.3.auto",
.codec_dai_name = "adau7002-hifi",
.codec_name = "ADAU7002:00",
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
-- 
1.9.1

[PATCH] ASoC: AMD: Change codec to channel link as per hardware redesign

[Akshu Agrawal]

This is a correction to match acutal hardware configuration.
The hardware configuration looks like:
I2S_BT -> SPK(Max) + DMIC(Adau)
I2S_SP -> DA7219 Headset

No actual products have been shipped with previous configuration.

Signed-off-by: Akshu Agrawal 
---
This patch is dependent on [V4,10/10] ASoC: amd: dma driver changes for bt i2s 
instance
https://patchwork.kernel.org/patch/10385381/

 sound/soc/amd/acp-da7219-max98357a.c | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/sound/soc/amd/acp-da7219-max98357a.c 
b/sound/soc/amd/acp-da7219-max98357a.c
index ccddc66..566bd26 100644
--- a/sound/soc/amd/acp-da7219-max98357a.c
+++ b/sound/soc/amd/acp-da7219-max98357a.c
@@ -148,7 +148,7 @@ static int cz_da7219_startup(struct snd_pcm_substream 
*substream)
snd_pcm_hw_constraint_list(runtime, 0, SNDRV_PCM_HW_PARAM_RATE,
   _rates);
 
-   machine->i2s_instance = I2S_BT_INSTANCE;
+   machine->i2s_instance = I2S_SP_INSTANCE;
return da7219_clk_enable(substream);
 }
 
@@ -163,7 +163,7 @@ static int cz_max_startup(struct snd_pcm_substream 
*substream)
struct snd_soc_card *card = rtd->card;
struct acp_platform_info *machine = snd_soc_card_get_drvdata(card);
 
-   machine->i2s_instance = I2S_SP_INSTANCE;
+   machine->i2s_instance = I2S_BT_INSTANCE;
return da7219_clk_enable(substream);
 }
 
@@ -178,7 +178,7 @@ static int cz_dmic_startup(struct snd_pcm_substream 
*substream)
struct snd_soc_card *card = rtd->card;
struct acp_platform_info *machine = snd_soc_card_get_drvdata(card);
 
-   machine->i2s_instance = I2S_SP_INSTANCE;
+   machine->i2s_instance = I2S_BT_INSTANCE;
return da7219_clk_enable(substream);
 }
 
@@ -204,16 +204,27 @@ static void cz_dmic_shutdown(struct snd_pcm_substream 
*substream)
 
 static struct snd_soc_dai_link cz_dai_7219_98357[] = {
{
-   .name = "amd-da7219-play-cap",
-   .stream_name = "Playback and Capture",
+   .name = "amd-da7219-play",
+   .stream_name = "Playback",
.platform_name = "acp_audio_dma.0.auto",
-   .cpu_dai_name = "designware-i2s.3.auto",
+   .cpu_dai_name = "designware-i2s.1.auto",
.codec_dai_name = "da7219-hifi",
.codec_name = "i2c-DLGS7219:00",
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
| SND_SOC_DAIFMT_CBM_CFM,
.init = cz_da7219_init,
.dpcm_playback = 1,
+   .ops = _da7219_cap_ops,
+   },
+   {
+   .name = "amd-da7219-cap",
+   .stream_name = "Capture",
+   .platform_name = "acp_audio_dma.0.auto",
+   .cpu_dai_name = "designware-i2s.2.auto",
+   .codec_dai_name = "da7219-hifi",
+   .codec_name = "i2c-DLGS7219:00",
+   .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
+   | SND_SOC_DAIFMT_CBM_CFM,
.dpcm_capture = 1,
.ops = _da7219_cap_ops,
},
@@ -221,7 +232,7 @@ static void cz_dmic_shutdown(struct snd_pcm_substream 
*substream)
.name = "amd-max98357-play",
.stream_name = "HiFi Playback",
.platform_name = "acp_audio_dma.0.auto",
-   .cpu_dai_name = "designware-i2s.1.auto",
+   .cpu_dai_name = "designware-i2s.3.auto",
.codec_dai_name = "HiFi",
.codec_name = "MX98357A:00",
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
@@ -233,7 +244,7 @@ static void cz_dmic_shutdown(struct snd_pcm_substream 
*substream)
.name = "dmic",
.stream_name = "DMIC Capture",
.platform_name = "acp_audio_dma.0.auto",
-   .cpu_dai_name = "designware-i2s.2.auto",
+   .cpu_dai_name = "designware-i2s.3.auto",
.codec_dai_name = "adau7002-hifi",
.codec_name = "ADAU7002:00",
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
-- 
1.9.1

RE: [External] [RFC PATCH v1 3/6] mm, zone_type: create ZONE_NVM and fill into GFP_ZONE_TABLE

[Huaisheng HS1 Ye]

> On 05/07/2018 07:33 PM, Huaisheng HS1 Ye wrote:
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index c782e8f..5fe1f63 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -687,6 +687,22 @@ config ZONE_DEVICE
> >
> > +config ZONE_NVM
> > +   bool "Manage NVDIMM (pmem) by memory management (EXPERIMENTAL)"
> > +   depends on NUMA && X86_64
> 
> Hi,
> I'm curious why this depends on NUMA. Couldn't it be useful in non-NUMA
> (i.e., UMA) configs?
> 
I wrote these patches with two sockets testing platform, and there are two DDRs 
and two NVDIMMs have been installed to it.
So, for every socket it has one DDR and one NVDIMM with it. Here is memory 
region from memblock, you can get its distribution.

 435 [0.00] Zone ranges:
 436 [0.00]   DMA  [mem 0x1000-0x00ff]
 437 [0.00]   DMA32[mem 0x0100-0x]
 438 [0.00]   Normal   [mem 0x0001-0x0046bfff]
 439 [0.00]   NVM  [mem 0x00044000-0x0046bfff]
 440 [0.00]   Device   empty
 441 [0.00] Movable zone start for each node
 442 [0.00] Early memory node ranges
 443 [0.00]   node   0: [mem 0x1000-0x0009]
 444 [0.00]   node   0: [mem 0x0010-0xa69c2fff]
 445 [0.00]   node   0: [mem 0xa7654000-0xa85eefff]
 446 [0.00]   node   0: [mem 0xab399000-0xaf3f6fff]
 447 [0.00]   node   0: [mem 0xaf429000-0xaf7f]
 448 [0.00]   node   0: [mem 0x0001-0x00043fff] 
Normal 0
 449 [0.00]   node   0: [mem 0x00044000-0x00237fff] 
NVDIMM 0
 450 [0.00]   node   1: [mem 0x00238000-0x00277fff] 
Normal 1
 451 [0.00]   node   1: [mem 0x00278000-0x0046bfff] 
NVDIMM 1

If we disable NUMA, there is a result as Normal an NVDIMM zones will be 
overlapping with each other.
Current mm treats all memory regions equally, it divides zones just by size, 
like 16M for DMA, 4G for DMA32, and others above for Normal.
The spanned range of all zones couldn't be overlapped.

If we enable NUMA, for every socket its DDR and NVDIMM are separated, you can 
find that NVDIMM region always behind Normal zone.

Sincerely,
Huaisheng Ye 

RE: [External] [RFC PATCH v1 3/6] mm, zone_type: create ZONE_NVM and fill into GFP_ZONE_TABLE

[Huaisheng HS1 Ye]

> On 05/07/2018 07:33 PM, Huaisheng HS1 Ye wrote:
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index c782e8f..5fe1f63 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -687,6 +687,22 @@ config ZONE_DEVICE
> >
> > +config ZONE_NVM
> > +   bool "Manage NVDIMM (pmem) by memory management (EXPERIMENTAL)"
> > +   depends on NUMA && X86_64
> 
> Hi,
> I'm curious why this depends on NUMA. Couldn't it be useful in non-NUMA
> (i.e., UMA) configs?
> 
I wrote these patches with two sockets testing platform, and there are two DDRs 
and two NVDIMMs have been installed to it.
So, for every socket it has one DDR and one NVDIMM with it. Here is memory 
region from memblock, you can get its distribution.

 435 [0.00] Zone ranges:
 436 [0.00]   DMA  [mem 0x1000-0x00ff]
 437 [0.00]   DMA32[mem 0x0100-0x]
 438 [0.00]   Normal   [mem 0x0001-0x0046bfff]
 439 [0.00]   NVM  [mem 0x00044000-0x0046bfff]
 440 [0.00]   Device   empty
 441 [0.00] Movable zone start for each node
 442 [0.00] Early memory node ranges
 443 [0.00]   node   0: [mem 0x1000-0x0009]
 444 [0.00]   node   0: [mem 0x0010-0xa69c2fff]
 445 [0.00]   node   0: [mem 0xa7654000-0xa85eefff]
 446 [0.00]   node   0: [mem 0xab399000-0xaf3f6fff]
 447 [0.00]   node   0: [mem 0xaf429000-0xaf7f]
 448 [0.00]   node   0: [mem 0x0001-0x00043fff] 
Normal 0
 449 [0.00]   node   0: [mem 0x00044000-0x00237fff] 
NVDIMM 0
 450 [0.00]   node   1: [mem 0x00238000-0x00277fff] 
Normal 1
 451 [0.00]   node   1: [mem 0x00278000-0x0046bfff] 
NVDIMM 1

If we disable NUMA, there is a result as Normal an NVDIMM zones will be 
overlapping with each other.
Current mm treats all memory regions equally, it divides zones just by size, 
like 16M for DMA, 4G for DMA32, and others above for Normal.
The spanned range of all zones couldn't be overlapped.

If we enable NUMA, for every socket its DDR and NVDIMM are separated, you can 
find that NVDIMM region always behind Normal zone.

Sincerely,
Huaisheng Ye 

Re: linux-next: manual merge of the bpf-next tree with the s390 tree

[Stephen Rothwell]

Hi all,

On Tue, 8 May 2018 10:26:38 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
> 
>   arch/s390/net/bpf_jit.S
> 
> between commit:
> 
>   de5cb6eb514e ("s390: use expoline thunks in the BPF JIT")
> 
> from the s390 tree and commit:
> 
>   e1cf4befa297 ("bpf, s390x: remove ld_abs/ld_ind")
> 
> from the bpf-next tree.
> 
> I fixed it up (I just removed the file as the latter does) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.

This is now a conflict between the net-next and s390 trees.

-- 
Cheers,
Stephen Rothwell


pgpDpSlpQ4uVG.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the bpf-next tree with the s390 tree

[Stephen Rothwell]

Hi all,

On Tue, 8 May 2018 10:26:38 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
> 
>   arch/s390/net/bpf_jit.S
> 
> between commit:
> 
>   de5cb6eb514e ("s390: use expoline thunks in the BPF JIT")
> 
> from the s390 tree and commit:
> 
>   e1cf4befa297 ("bpf, s390x: remove ld_abs/ld_ind")
> 
> from the bpf-next tree.
> 
> I fixed it up (I just removed the file as the latter does) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.

This is now a conflict between the net-next and s390 trees.

-- 
Cheers,
Stephen Rothwell


pgpDpSlpQ4uVG.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the net-next tree with the net tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  tools/testing/selftests/net/Makefile

between commit:

  1751eb42ddb5 ("selftests: net: use TEST_PROGS_EXTENDED")

from the net tree and commits:

  a7b15ab887e5 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc tools/testing/selftests/net/Makefile
index 3ff81a478dbe,73af45773938..
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@@ -5,10 -5,13 +5,13 @@@ CFLAGS =  -Wall -Wl,--no-as-needed -O2 
  CFLAGS += -I../../../../usr/include/
  
  TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh 
rtnetlink.sh
- TEST_PROGS += fib_tests.sh fib-onlink-tests.sh pmtu.sh
+ TEST_PROGS += fib_tests.sh fib-onlink-tests.sh in_netns.sh pmtu.sh udpgso.sh
+ TEST_PROGS += udpgso_bench.sh
 -TEST_GEN_PROGS_EXTENDED := in_netns.sh
 +TEST_PROGS_EXTENDED := in_netns.sh
  TEST_GEN_FILES =  socket
  TEST_GEN_FILES += psock_fanout psock_tpacket msg_zerocopy
+ TEST_GEN_FILES += tcp_mmap tcp_inq
+ TEST_GEN_FILES += udpgso udpgso_bench_tx udpgso_bench_rx
  TEST_GEN_PROGS = reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa
  TEST_GEN_PROGS += reuseport_dualstack reuseaddr_conflict
  


pgp5t9Syp1F4Q.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the net-next tree with the net tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  tools/testing/selftests/net/Makefile

between commit:

  1751eb42ddb5 ("selftests: net: use TEST_PROGS_EXTENDED")

from the net tree and commits:

  a7b15ab887e5 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc tools/testing/selftests/net/Makefile
index 3ff81a478dbe,73af45773938..
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@@ -5,10 -5,13 +5,13 @@@ CFLAGS =  -Wall -Wl,--no-as-needed -O2 
  CFLAGS += -I../../../../usr/include/
  
  TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh 
rtnetlink.sh
- TEST_PROGS += fib_tests.sh fib-onlink-tests.sh pmtu.sh
+ TEST_PROGS += fib_tests.sh fib-onlink-tests.sh in_netns.sh pmtu.sh udpgso.sh
+ TEST_PROGS += udpgso_bench.sh
 -TEST_GEN_PROGS_EXTENDED := in_netns.sh
 +TEST_PROGS_EXTENDED := in_netns.sh
  TEST_GEN_FILES =  socket
  TEST_GEN_FILES += psock_fanout psock_tpacket msg_zerocopy
+ TEST_GEN_FILES += tcp_mmap tcp_inq
+ TEST_GEN_FILES += udpgso udpgso_bench_tx udpgso_bench_rx
  TEST_GEN_PROGS = reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa
  TEST_GEN_PROGS += reuseport_dualstack reuseaddr_conflict
  


pgp5t9Syp1F4Q.pgp
Description: OpenPGP digital signature

[PATCH v2 2/2] perf cs-etm: Remove redundant space

[Leo Yan]

There have two spaces ahead function name cs_etm__set_pid_tid_cpu(), so
remove one space and correct indentation.

Signed-off-by: Leo Yan 
Acked-by: Mathieu Poirier 
---
 tools/perf/util/cs-etm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 69f21de..822ba91 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -611,8 +611,8 @@ cs_etm__get_trace(struct cs_etm_buffer *buff, struct 
cs_etm_queue *etmq)
return buff->len;
 }
 
-static void  cs_etm__set_pid_tid_cpu(struct cs_etm_auxtrace *etm,
-struct auxtrace_queue *queue)
+static void cs_etm__set_pid_tid_cpu(struct cs_etm_auxtrace *etm,
+   struct auxtrace_queue *queue)
 {
struct cs_etm_queue *etmq = queue->priv;
 
-- 
2.7.4

[PATCH v2 2/2] perf cs-etm: Remove redundant space

[Leo Yan]

There have two spaces ahead function name cs_etm__set_pid_tid_cpu(), so
remove one space and correct indentation.

Signed-off-by: Leo Yan 
Acked-by: Mathieu Poirier 
---
 tools/perf/util/cs-etm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 69f21de..822ba91 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -611,8 +611,8 @@ cs_etm__get_trace(struct cs_etm_buffer *buff, struct 
cs_etm_queue *etmq)
return buff->len;
 }
 
-static void  cs_etm__set_pid_tid_cpu(struct cs_etm_auxtrace *etm,
-struct auxtrace_queue *queue)
+static void cs_etm__set_pid_tid_cpu(struct cs_etm_auxtrace *etm,
+   struct auxtrace_queue *queue)
 {
struct cs_etm_queue *etmq = queue->priv;
 
-- 
2.7.4

[PATCH v2 1/2] perf cs-etm: Support unknown_thread in cs_etm_auxtrace

[Leo Yan]

CoreSight doesn't allocate thread structure for unknown_thread in etm
auxtrace, so unknown_thread is NULL pointer.  If the perf data doesn't
contain valid tid and then cs_etm__mem_access() uses unknown_thread
instead as thread handler, this results in segmentation fault when
thread__find_addr_map() accesses thread handler.

This commit creates new thread data which is used by unknown_thread, so
CoreSight tracing can roll back to use unknown_thread if perf data
doesn't include valid thread info.  This commit also releases thread
data for initialization failure case and for normal auxtrace free flow.

Signed-off-by: Leo Yan 
Acked-by: Mathieu Poirier 
---
 tools/perf/util/cs-etm.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 6533b1a..69f21de 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -239,6 +239,7 @@ static void cs_etm__free(struct perf_session *session)
for (i = 0; i < aux->num_cpu; i++)
zfree(>metadata[i]);
 
+   thread__zput(aux->unknown_thread);
zfree(>metadata);
zfree();
 }
@@ -1355,6 +1356,23 @@ int cs_etm__process_auxtrace_info(union perf_event 
*event,
etm->auxtrace.free = cs_etm__free;
session->auxtrace = >auxtrace;
 
+   etm->unknown_thread = thread__new(9, 9);
+   if (!etm->unknown_thread)
+   goto err_free_queues;
+
+   /*
+* Initialize list node so that at thread__zput() we can avoid
+* segmentation fault at list_del_init().
+*/
+   INIT_LIST_HEAD(>unknown_thread->node);
+
+   err = thread__set_comm(etm->unknown_thread, "unknown", 0);
+   if (err)
+   goto err_delete_thread;
+
+   if (thread__init_map_groups(etm->unknown_thread, etm->machine))
+   goto err_delete_thread;
+
if (dump_trace) {
cs_etm__print_auxtrace_info(auxtrace_info->priv, num_cpu);
return 0;
@@ -1369,16 +1387,18 @@ int cs_etm__process_auxtrace_info(union perf_event 
*event,
 
err = cs_etm__synth_events(etm, session);
if (err)
-   goto err_free_queues;
+   goto err_delete_thread;
 
err = auxtrace_queues__process_index(>queues, session);
if (err)
-   goto err_free_queues;
+   goto err_delete_thread;
 
etm->data_queued = etm->queues.populated;
 
return 0;
 
+err_delete_thread:
+   thread__zput(etm->unknown_thread);
 err_free_queues:
auxtrace_queues__free(>queues);
session->auxtrace = NULL;
-- 
2.7.4

[PATCH v2 1/2] perf cs-etm: Support unknown_thread in cs_etm_auxtrace

[Leo Yan]

CoreSight doesn't allocate thread structure for unknown_thread in etm
auxtrace, so unknown_thread is NULL pointer.  If the perf data doesn't
contain valid tid and then cs_etm__mem_access() uses unknown_thread
instead as thread handler, this results in segmentation fault when
thread__find_addr_map() accesses thread handler.

This commit creates new thread data which is used by unknown_thread, so
CoreSight tracing can roll back to use unknown_thread if perf data
doesn't include valid thread info.  This commit also releases thread
data for initialization failure case and for normal auxtrace free flow.

Signed-off-by: Leo Yan 
Acked-by: Mathieu Poirier 
---
 tools/perf/util/cs-etm.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 6533b1a..69f21de 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -239,6 +239,7 @@ static void cs_etm__free(struct perf_session *session)
for (i = 0; i < aux->num_cpu; i++)
zfree(>metadata[i]);
 
+   thread__zput(aux->unknown_thread);
zfree(>metadata);
zfree();
 }
@@ -1355,6 +1356,23 @@ int cs_etm__process_auxtrace_info(union perf_event 
*event,
etm->auxtrace.free = cs_etm__free;
session->auxtrace = >auxtrace;
 
+   etm->unknown_thread = thread__new(9, 9);
+   if (!etm->unknown_thread)
+   goto err_free_queues;
+
+   /*
+* Initialize list node so that at thread__zput() we can avoid
+* segmentation fault at list_del_init().
+*/
+   INIT_LIST_HEAD(>unknown_thread->node);
+
+   err = thread__set_comm(etm->unknown_thread, "unknown", 0);
+   if (err)
+   goto err_delete_thread;
+
+   if (thread__init_map_groups(etm->unknown_thread, etm->machine))
+   goto err_delete_thread;
+
if (dump_trace) {
cs_etm__print_auxtrace_info(auxtrace_info->priv, num_cpu);
return 0;
@@ -1369,16 +1387,18 @@ int cs_etm__process_auxtrace_info(union perf_event 
*event,
 
err = cs_etm__synth_events(etm, session);
if (err)
-   goto err_free_queues;
+   goto err_delete_thread;
 
err = auxtrace_queues__process_index(>queues, session);
if (err)
-   goto err_free_queues;
+   goto err_delete_thread;
 
etm->data_queued = etm->queues.populated;
 
return 0;
 
+err_delete_thread:
+   thread__zput(etm->unknown_thread);
 err_free_queues:
auxtrace_queues__free(>queues);
session->auxtrace = NULL;
-- 
2.7.4

linux-next: manual merge of the net-next tree with the net tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  net/tls/tls_main.c

between commit:

  98f0a39529e5 ("tls: fix use after free in tls_sk_proto_close")

from the net tree and commit:

  f66de3ee2c16 ("net/tls: Split conf to rx + tx")

from the net-next tree.

I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc net/tls/tls_main.c
index 20cd93be6236,4b57ddd72f34..
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@@ -254,8 -252,12 +254,9 @@@ static void tls_sk_proto_close(struct s
lock_sock(sk);
sk_proto_close = ctx->sk_proto_close;
  
-   if (ctx->conf == TLS_BASE || ctx->conf == TLS_HW_RECORD) {
 -  if (ctx->tx_conf == TLS_HW_RECORD && ctx->rx_conf == TLS_HW_RECORD)
 -  goto skip_tx_cleanup;
 -
 -  if (ctx->tx_conf == TLS_BASE && ctx->rx_conf == TLS_BASE) {
 -  kfree(ctx);
 -  ctx = NULL;
++  if ((ctx->tx_conf == TLS_BASE && ctx->rx_conf == TLS_BASE) ||
++  (ctx->tx_conf == TLS_HW_RECORD && ctx->rx_conf == TLS_HW_RECORD)) {
 +  free_ctx = true;
goto skip_tx_cleanup;
}
  


pgpRi66kO9OPS.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the net-next tree with the net tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  net/tls/tls_main.c

between commit:

  98f0a39529e5 ("tls: fix use after free in tls_sk_proto_close")

from the net tree and commit:

  f66de3ee2c16 ("net/tls: Split conf to rx + tx")

from the net-next tree.

I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc net/tls/tls_main.c
index 20cd93be6236,4b57ddd72f34..
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@@ -254,8 -252,12 +254,9 @@@ static void tls_sk_proto_close(struct s
lock_sock(sk);
sk_proto_close = ctx->sk_proto_close;
  
-   if (ctx->conf == TLS_BASE || ctx->conf == TLS_HW_RECORD) {
 -  if (ctx->tx_conf == TLS_HW_RECORD && ctx->rx_conf == TLS_HW_RECORD)
 -  goto skip_tx_cleanup;
 -
 -  if (ctx->tx_conf == TLS_BASE && ctx->rx_conf == TLS_BASE) {
 -  kfree(ctx);
 -  ctx = NULL;
++  if ((ctx->tx_conf == TLS_BASE && ctx->rx_conf == TLS_BASE) ||
++  (ctx->tx_conf == TLS_HW_RECORD && ctx->rx_conf == TLS_HW_RECORD)) {
 +  free_ctx = true;
goto skip_tx_cleanup;
}
  


pgpRi66kO9OPS.pgp
Description: OpenPGP digital signature